Just to get this started:

Markdown

• Use GitHub Flavored Markdown
• For code examples, use fenced code blocks with language definitions, versus indentation
• Use hashes for headings (###), not dashes

Resources

• Markdown Cheatsheet
• http://github.github.com/github-flavored-markdown/

LESS code examples

• All code in examples is indented by 2 spaces
• Always spaces, never tabs
• Always end lines with a semicolon
• One property per line
• Add a space after colons, do this color: #900, not this color:#900

Resources

• https://github.com/twbs/bootstrap/blob/3.0.0-wip/CONTRIBUTING.md

Here is a trick I use to define variables and keep them in some private scope, avoiding them leaking to the global space.

& {
  // Vars
  @height: 100px;
  @width: 20px;
  // Don't define any prop:value on this scope (as doing so will generate (wrong) output).

  .test {
    height: @height;
   width: @width;
  }
}

.rest {
  height: @height; // Name error: variable @height is undefined
}

Here, @height and @width are only defined for the scope created by & { ... }
You can also nest an scope inside a rule:

.some-module {
  @height: 200px;
  @width: 200px;
  text-align: left;
  line-height: @height; // 200px

  & {
    // Override original values
    @height: 100px;
    @width: auto;

    .some-module__element {
      height: @height; // 100px
      width: @width; // 200px
    }

    .some-module__element .text {
      line-height: (@height / 2); // 50px
    }
  }

  & {
    // Override original values
    @height: 50px;

    .some-module__another-element {
      height: @height; // 50px
      width: @width; // 200px
    }

    .some-module__another-element .text {
      line-height: (@height / 2); // 25px
    }
  }
}

less/less.js#1542

Are we planning to have an API for individual pieces of documentation? (So that someone can, say, look up a function in an editor?) ;-)

I see questions like "where can I quickly test my less code w/o installing anything?" are quite popular at SO.
Perhaps the docs might answer that too? (not incl. too outdated versions):

• http://less2css.org/
• http://winless.org/online-less-compiler
• http://lesstester.com/
• http://www.dopefly.com/less-converter/less-converter.html
• http://lessphp.gpeasy.com/demo
• http://leafo.net/lessphp/editor.html

and maybe organise usage a bit.

Options
Advanced Server Side
How to use sourcemaps
Advanced Client Side

This feature is not documented yet: less/less.js#413

Examples: pleas use lessfor LESS, andcss for CSS. Change it to please. Markdown Standards

• extract function less/less.js#1112

Linking to the LESS site on Facebook or Google+ both yield a generic link. This means that no thumbnail is displayed and the title, description and URL are whatever is defined in the main metadata.

This can be easily tuned by adding metadata to target Facebook's OpenGraph, Google+ and Twitter Cards.

http://ogp.me/

https://developers.google.com/+/web/snippet/

https://dev.twitter.com/docs/cards

A number of questions come up for creating custom file handlers (like pulling less files from a DB backend, or a different file retrieval system). However, I can't seem to find any documentation or Github threads on how to create a file loader or an importer (and what the difference between these two actually is).

I found a note from @lukeapage on one thread saying he'd refactored parsing and added fileLoader, but I'm still not quite sure what it does, or when to override it instead of overriding importer.

This could be part of a documentation section on extending Less, or the Less "API".

Since less/less.js#1706 came up at least four times, it might be reasonable to document it in some king of tips/common use cases/whatever page.

E.g. #1242

Can we mention Visual Studio's Web Essentials extension under GUI compilers that use LESS.js?

I was almost about to add it to GUI-compilers-that-use-LESS but then I thought "Hey! These days almost every less or more popular IDE/editor supports LESS natively or via plugins/extensions, should we add them all? There're a lot!" (and most of them do that via lessc or less.js).

So far the list contains almost only less or more "less/sass/css dedicated" GUI editors/compilers. So I wonder if we need some special rules on what may be added there and what might be not.

"Named Parameters" are not documented.

Well, not every function there is actually an adjustment one (e.g. contrast) but most are. This is subjective of course but for me "operations" always looked a bit weird (confusing with some kind of arithmetic operations or so). I came to this idea when I was doing some coding for future PRs (e.g. not ready yet) and there those functions just scream "rename us!" :) (though the internal naming in the code is no way related to the docs so this is just a source of inspiration).

Mis-linked here: http://less.github.io/less-docs/about.html

The following options/functionality seems to be undocumented:

• globalVars - less/less.js#1479
• errorReporting - less/less.js#792
• style tags with "text/less" or "text/x-less" - less/less.js#104

I don't know whether any of these are deprecated (or not) but still think there should be a mention of it on lesscss.org or on the project wiki.

Given how easy it is to do inline media queries in LESS, the site is not responsive and requires tedious pinch-zooming on mobile.

There really should be a mobile styles.

See #34. I don't think my English will let me to finish it so please do not hesitate to take over.

To compliment the proposed improved contributing docs, it might be a good idea to have annotated source code. For example:

CoffeeScript: http://coffeescript.org/documentation/docs/grammar.html
Underscore: http://underscorejs.org/docs/underscore.html

Both use Docco to process the source and produce this beautiful documentation.

http://jashkenas.github.io/docco/

There's also Python, Ruby, shell and .NET versions.

http://fitzgen.github.com/pycco
https://github.com/rtomayko/rocco
http://rtomayko.github.com/shocco/
http://dontangg.github.com/nocco/

(Most of these suggestions are based on #1 from @ChrisCinelli)

• add CHANGELOG to website
• Move release update from the top to a new section called "Changelog". Possibly at the end of the page. The focus of the content of the site should always be related to the most current version. All mention of other versions should be in the changelog or "release history" section.
• Bonus: put for each version number in changelog a link to the documentation of that version. Unfortunately https://github.com/cloudhead/lesscss.org does not have tag for different version but I think they could be retrieved with a little work. From now on I would tag the new versions of the page.

@cloudhead do you have .psd or .ai or something like that for the logo?

See #34. I don't think my English will let me to finish it so please do not hesitate to take over.
Maybe http://meri-stuff.blogspot.ru/2013/03/less-css-tips-and-trics.html#TricksandWorkaroundsLooping?

• less
• css
• inline
• reference

less/less.js#129

If you know of a project that uses Less.js/LESS in some way, please add a comment!

• [http://mateuszkocz.github.io/3l/](Lots of Love for LESS) - mixins library,
• https://github.com/danielkatz/less-bidi - mixins to help with bi-directional styling
• https://github.com/mrkrupski/LESS-Dynamic-Stylesheet - mixins library.
• Twitter Bootstrap
• http://lesshat.com/

• setup virtual page views and events for tracking behavior -- assuming we stick with a single page for most of the docs.

The analytics would be easier easier to maintain (for others in the future) if we split up the site into multiple pages. Visits on multiple pages are straightforward and easy to track (something like http://assemble.io/docs/Home.html). I suppose we'll just see how it goes...

• add @cloudhead as admin on analytics repo. (or, @cloudhead if you have an account you'd like to use, I'm good with whatever you want to do)

document that you can now use

& when() {
}

as a way of essentially doing if's as syntactic sugar for

.if() when () {
}
.if();

Badly in need of documentation.

I still think this is misleading on the website:

LESS runs on both the server-side (with Node.js and Rhino) or client-side (modern browsers only).

Everyone I know in web-development would assume that saying "LESS runs client-side" means it's good to go for production, when what we (currently) mean here is that you can test it in the browser.

How about:

LESS compiles on the server-side (with Node.js, Rhino, and others), or you can easily try it client-side (on modern browsers).

"Try" implying "testing"

Per this comment less/less.js#1050 (comment), let's get some stuff written down about this awesome new feature. What do Less.js users need to know!

Make cdn and object here: https://github.com/less/less-docs/blob/master/_config.yml#L27

and add the different CDN's as properties below:

cdn:
  max: // url
  cloudflare: // url

less/less.js#1465 (comment)

When pasting to LinkedIn, lesscss.org auto-generated this description text:

Are some elements in your style sheet proportional to other elements? Operations let you add, subtract, divide and multiply property values and colors, giving you the power to create complex relationships between properties. Operations should only be performed within parentheses in order to ensure compatibility with CSS.

I recommend we clean up meta tags on the site (and add appropriate ones for Twitter cards and Facebook posts) to make the site more friendly to pasting on various social platforms.

Moved from less.js issue less/less.js#1652 Original description:

Until recently I didn't knew about && as a placeholder for selectors. It seems that this feature isn't documented anywhere.

Update extract() documentation as per this issue:

less/less.js#1465 (comment)

It should state that extracting can be used to create array and loops when used in conjunction with a when() clause.

I've wanted to contribute to LESS plenty of times but while I'm a good programmer with a strong understanding of CSS, it isn't easy to digest a compiler.

I propose updated documentation that explains how to dive into different parts of the project. How to add functions, new syntax, fix bugs, etc.

The process is somewhat documented already but the page will soon be out of date as make is replaced with grunt builds. A clear set of instructions for setting up an environment, and clear entry points for common tasks are the only way contribution from anyone but the most dedicated will happen.

Some documentation around less.logLevel and logging.

Related commit: less/less.js@3a4a207

things to do, add etc. From the extend documentation

I wanted to leave the extend documentation releasable, however the following are notes that I removed which it may make sense to add later once they have been expanded upon.

Most of this is from @jonschlinkert

Examples for when "extend" will be valuable, and when it won't

The purpose of this section is to better understand how the :extend feature ought be used, thinking in terms of best practices, in order to help prioritize development decisions, and to qualify or disqualify feature requests related to this feature.

Repetitious Code

The :extend feature seems to hold the most promise as a device for:

1. Selector Inheritance: which means you can add the styles of one selector to other selectors, but without having to manually hunt down and directly edit each of the selectors you wish to extend. Clearly, this is advantageous at the time of need, but it's also helpful with code maintenance.
   2.

:extend directive to a selector (or ruleset of a selector) allows you to add the styles of that selector to any other selectors,

.widget {
  &:extend(ul li, .blob, .kitchensink, .sanity, .willtolive, .questions, .etc);
  background: blue;
}

.widget {
  &:extend(.answers, .blob, .kitchensink, .sanity, .willtolive, .nav, .navbar, .etc);
  background: blue;
}

Don't understand:
Notice that the Extending selector was grouped before the Extended selector. This was chosen not for stylistic reasons, but to be behaviorally consistent with the expected order of inherited declarations within the block.

TODOs:
Specificity
Order of Inherited Declarations
Mixins <-- just do later?

Selectors
Type Selectors
Simple Selectors
Combinators
Pseudo-Elements

Extends with Mixins

TODO: that it is planned

.clearfix():extend() {
  // declarations
}

Extends, Mixins, "Empty" Mixins, and Placeholders

TODO
We want :extend to make our lives easier by DRYing up our stylesheets, but only when :extend cannot "pierce the context barrier" of the selector you wish to extend. So within the same context the goal is to prevent order to prevent :extend from poluting styles

After "To do this, you must add all to the selector in the extend expression.", there are two examples, which should show some differences, but they are the same.

We'll need to replace the old ribbon with something that goes with the new theme.

Moving this issue here.

Example output of the last example for the color multiply function should be

multiply(#ff6600, #0000ff); => #000000

• port existing docs from lesscss.org over to use assemble
• build system: Grunt.js, clean, jshint, assemble, assemble-less for starters
• add site scaffold
• start updating with new documentation that has already been created
• sync up docs with wiki
• remove wiki pages and put a link to the site. It will be easier to maintain everything in one place, and it will help keep traffic from the community directed to the site.
• update theme

@jonschlinkert @matthew-dean @cloudhead

I think we've already given @SomMeri rights on less.js? so, if you'd like, I'd like to add you to the list on the about page if you are okay with that?

@seven-phases-max you've made significant contributions to the code and docs over the last months, I'd like to add you too, if thats okay? I'd also like to give you push access, on the understanding you still create pull requests if its a large / breaking / contraversial change.

@Synchro same question to you?

I assume everyone else is okay with this?

Just getting this started.

In broad strokes, the site will be:

• Mobile (#8)
• Responsive

One of my "design" goals for the new site is to look for opportunities to make data more reusable, whenever possible. For example, our CHANGELOG will be formatted as YAML so that it can be parsed and used in templates. This allows the changelog to be rendered as markdown, HTML, or even pulled down from the GitHub API and consumed by some other application or lib.

I also believe that - if executed well - this will make the site more accessible, scalable and maintainable.

• changelog: version (object|key), date (string), changes (associative array)
• language features (todo)

Related

• Docs API: #3