SugarSS syntax

[ai]

Many users asked about some compact syntax like Sass or Styles. In PostCSS 5.0 we can make it, it is good time to find the best compact syntax.

My requirements:

• No ;.
• Short syntax for comments.
• Allows multiline values.
• Consistency (not like Stylus, when you can write in different syntax).

[ai]

First suggestion:

// Comment

@charset "UTF-8"

a {
  color: black
  background: white,
              linear-gradient(black, white)
}

Pros:

• Intuitive multi-line values
• Do not use indents

Cons:

• We still have :, { and }

[ai]

Second suggestion:

// Comment

@charset "UTF-8"

a
  color black
  background white, \
             linear-gradient(black, white)

Pros:

• No :, { and }

Cons:

• \ before \n in multilines values.

[azat-io]

The first suggestion is better. The second suggestion is not supported in any text editor and looks difficult for reading CSS code.

[ai]

@azat-io can you describe objective, why indent-based is hard to read? Because many Sass developers said, that CSS syntax is harder. So I think it is question of time.

[ai]

The main problem with first syntax is that it has only one benefit, no ;. Compact comments and nesting are already possible with SCSS syntax for PostCSS.

@azat-io what do you think?

[azat-io]

@ai Hmm.. Don't know. Maybe it's just my habit. But in my personal opinion the first suggestion looks better for my code understanding. The second benefit of the first suggestion is compact comments. 😃

[ai]

@azat-io SCSS syntax for PostCSS already supports compact comments.

[1j01]

@charset "UTF-8"

// Braces are for noobs
p
  // Colons make a lot of sense
  color: #555
  font-family:
    "Helvetica" // Newlines imply commas
    sans-serif // within indented lists

// Newlines in selectors imply commas as well
.good button
.okay button
  background: greenish bluey black // TODO: write PostCSS plugin

h1, h2, h3, h4, h5, h6
  commas-are: "always allowed", "of course"

[ai]

@1j01 we have a problem with some plugins with : in selector. Like https://github.com/jedmao/postcss-nested-props

[1j01]

@ai Wouldn't that then be parsed as a value? Might need to be changed in the normal parser, to treat what are now selectors with trailing colons as properties. (You don't really want selectors ending in colons, you just want it to parse as something plugins can use.)

[jednano]

For the record, postcss-nested-props is aligned with Sass syntax and I would be happy to update it to whatever new requirements we define.

[ai]

@jedmao yeap, other solution, we can deny unbracket : in selector. But I think there is a few plugins with : in selectors anyway.

[alwillis]

@ai I like the second version—pretty much the same as the original Sass syntax, which I really enjoyed using back in the day.

I like the direction this is going in—no semicolons or curly braces, which adds lots of visual noise.

[mojereliev]

I like second version. Stylus minimal syntax + multiline write ( / ), must be very cool.

[urec]

1j01 предложил хороший вариант ,можно писать мультилайновые значения(на разных строках)

p
  // Colons make a lot of sense
  color: #555
  font-family:
    "Helvetica" // Newlines imply commas
    sans-serif // within indented lists

возможность задавать мультилайновые значения только если после свойства стоит " : "(двоеточие) stylus синтаксис +++

[ai]

@urec сейчас есть плагины, которые используют : в селекторе. Да и от : тоже хотелось бы избавиться

[gazay]

Closer to Sass syntax – is for the win as I think. The second variant is cleaner. Also \ is really necessary? Because we can match all related to property by first property indentation as in Haskell:

.square
  background: white,
              linear-gradient(white, black)

// And in this case maybe we can omit brackets in arguments too
// It allows us to write clean code with 80 column rule =)
.square
  background: white,
              linear-gradient to bottom right,
                              white,
                              black

[gazay]

I understand about multiline selectors, but if here will be no nested styles, there is no problem, right? All selectors strat only from first column

[ai]

@gazay nested styles is important

[gazay]

But they aren't finish with :?

I mean that there not so many selectors with : possible in standard as I found and other matches for something:property we can treat as properties

[kezzbracey]

My vote is also for the second version. I know a few people who are using Stylus before PostCSS right now purely so they don't have to type curly braces or semicolons.

I can't speak as to the practicality of including colons, but I do know a lot of people who like terse syntax always use colons to make code more readable.

Re. text editor support / highlighting for terse syntax, any Stylus plugin should handle that, e.g. for Sublime Text or Atom.

[talgautb]

may be we need 2 plugins ? I need use : but i don't like brackets

[azat-io]

Best suggestion @talgautb

[andrejsm]

There should be (1) distinct parsers for one or another style. Or make all configurable and allow to (2) explicitly set each option. Or to set more general (3) configuration preset.

Example 1

let parser = require('postcss-parser-stylus-alike')
postcss([...]).process(input, { parser }).then(...)

Example 2

let options = {
  parser: {
    braces: false,
    colons: false,
    semicolons: false,
  }
}
postcss([...]).process(input, { options }).then(...)

or event go for .postcssrc

parser:
  braces: 0
  colons: 0
  semicolons: 0

Example 3

let options = {
  preset: 'noBracesSemicolons',
}
postcss([...]).process(input, { options }).then(...)

If omitting braces or colons will be optional, then should go for max!

[kezzbracey]

Flexibility is definitely great from the user side, but from the developer side it makes it difficult because it means many more tests have to be done for every possible combination of syntax options.

It's one of the reasons the Stylus devs have talking about removing the options to code with different syntaxes and settling on one approach.

I'm getting ready to release a few plugins, and I can imagine that having to make them work with multiple syntax options could be pretty painful.

[andrejsm]

@kezzbracey I fully agree with you. Therefore I prefer my first suggestion - distinct parsers. And seems at v5 PostCSS will have such a option.
To vote for proposed styles I will go with @ai's first suggestion as it is semantically similar to JS I write

let style = {
  color: 'red',
  fontSize: '1.6em',
}

div {
  color: red
  font-size: 1.6em
}

I just don't want to type semicolons. Braces and colons I want to retain. They are used in JS, but semicolons mainly are redundant. Currently I have minor issues with forgetting to type semicolons in css.

[kezzbracey]

@andrejsm Even though I prefer not to use curly braces, you do make a good point that keeping things semantically similar to JS would give consistency.

Using Emmet can make it feel like you're barely writing curly brackets, but semicolons are always a slow down and a pain.

So in short, I think you might have just bought be around to agreeing the first option might be the better one.

[akella]

I think the best approach is in Sass, it is also heavily tested by a lot of teams now.

.l
    +clr
    .l-col1
        float: left
        width: 20%
    .l-col2
        float: right
        width: 70%

Leaving ':' for readability, removing {} like noise, using indentation to parse.

[1j01]

e.g. Strict indentation checking that @jedmao wouldn't like:

used_tabs = false
used_spaces = false
for line, lineno in code.replace(/\r/g, "").split("\n")
  for char, colno in line
    if char is "\t"
      used_tabs = true
      if used_spaces
        throw new Error "Mixed indentation, unexpected tab on line #{lineno + 1}, column #{colno + 1}"
    else if char is " "
      used_spaces = true
      if used_tabs
        throw new Error "Mixed indentation, unexpected space on line #{lineno + 1}, column #{colno + 1}"
    else
      break

CoffeeScript handles it nicely.

[1j01]

Minimally strict checking that only looks for ambiguities:

previous_indentation = ""
for line, lineno in code.replace(/\r/g, "").split("\n")
  indentation = line.match(/^\s*/)[0]
  for previous_indentation_char, colno in previous_indentation when indentation[colno]
    if indentation[colno] isnt previous_indentation_char
      char_name = switch indentation[colno]
        when "\t" then "tab"
        when " " then "space"
        else JSON.stringify(indentation[colno])
      # throw new Error "Mixed indentation, unexpected #{char_name} on line #{lineno + 1}, column #{colno + 1}"
      throw new Error "Mixed indentation between lines #{lineno} and #{lineno + 1} on column #{colno + 1}"
  previous_indentation = indentation

Could add a check for spaces followed by tabs:

  if indentation.match /\ \t/
    throw new Error "Mixed indentation on line #{lineno + 1}"

[jednano]

@1j01 to be clear, there's nothing wrong with spaces followed by tabs unless they are then followed by more tabs.

[1j01]

@jedmao I suppose so. Not inherently, anyway.

[jednano]

@1j01 spaces followed by tabs are considered alignment is my point, which some people do (not me), but some do.

[ai]

@jedmao I remove tab deny code postcss/sugarss@489a87f

[corysimmons]

@ai So happy to hear you're working on this. :^) 👍 💯

Can't wait for the day I can drop preprocessors all together.

[jednano]

Thank you @ai!

[lalomartins]

Sorry, it's unclear to me — will there be nesting? With what syntax? @akella's sass-redux?

It could also be an option to just detect them insofar as not breaking the parser, then outputting them again to be handled by something like postcss/postcss-nested IMO.

[ai]

@lalomartins yeap it will support nesting

[lalomartins]

👍

[danielbayley]

How about allowing # comments?

This would be nice with CoffeeScript together with this terse sass-like syntax.

I appreciate that # is for #ids in CSS, but hashes followed by a space could easily be comments instead. Besides, the use of #ids seem to be mostly discouraged anyway.

Something like /#\s+/ to match them? or maybe this should be a plugin?

[ai]

@danielbayley Yeap. I was thought about # comments too.

But having #\s is too tricky. Most of languages with #-comments allow to miss a space between # and text. Look for example to bang comment #!/usr/bin/bash.

This is why I think having # comments will not be a good idea

[whaaaley]

I agree that # comments would conflict with CSS. Are we still stuck on the multi-line indents problem?

[ai]

@dustindowell22 nope, everything fine. Right now .sss to .css complication is finished. I need just .sss to .sss conversion (for tools like postcss-sorting).

[jescalan]

@ai for real? is there a beta release we can try out if we are just going for straight compilation? can't wait to get my hands on this 😁

[ai]

@Jenius You can try it from GitHub https://github.com/postcss/sugarss

I think SugarSS will be finished on this or next week.

[danielbayley]

I think SugarSS will be finished on this or next week.

👍

Hopefully I can figure out how to get this into atom-language-postcss-sugarss asap…

[ai]

SugarSS code base was finished: https://github.com/postcss/sugarss

I am writing a docs and converting tool right now.

[dbox]

Thanks for the all the work @ai!

[corysimmons]

🎉

[danielbayley]

atom-language-postcss-sugarss is up now. It's really just scaffolding at this point though as it just extends the existing Sass syntax highlighting. Any help is welcome…

We are working on syntax highlight support in text editors.

[ai]

@danielbayley you are fast :). Awesome work. I added it to SugarSS README.md and installed to local machine for test highlights :).

[ai]

SugarSS 0.1 was released. Please try and post your feedbpack: https://github.com/postcss/sugarss

[aazcast]

Hi i modify a SASS Syntax Highlight to work with .SSS files.
You can find it in Package Control or https://github.com/aazcast/Syntax-SugarSS-SublimeText

[ai]

@aazcast wow! Could you send PR with your highlighter to SugarSS docs?

[aazcast]

@ai Hi i just send PR. This is the packagecontrol link: https://packagecontrol.io/packages/Syntax%20Highlighting%20for%20SSS%20SugarSS

is available to install using packagecontrol.