New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SugarSS syntax #495

Closed
ai opened this Issue Aug 17, 2015 · 129 comments

Comments

Projects
None yet
@ai
Member

ai commented Aug 17, 2015

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 ai added the question label Aug 17, 2015

@ai ai referenced this issue Aug 17, 2015

Closed

Custom parsers #140

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

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 }
Member

ai commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

Second suggestion:

// Comment

@charset "UTF-8"

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

Pros:

  • No :, { and }

Cons:

  • \ before \n in multilines values.
Member

ai commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@azat-io

azat-io Aug 17, 2015

Contributor

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

Contributor

azat-io commented Aug 17, 2015

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

@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.

Member

ai commented Aug 17, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

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?

Member

ai commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@azat-io

azat-io Aug 17, 2015

Contributor

@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. 😃

Contributor

azat-io commented Aug 17, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

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

Member

ai commented Aug 17, 2015

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

@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Aug 17, 2015

@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"

1j01 commented Aug 17, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 17, 2015

Member

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

Member

ai commented Aug 17, 2015

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

@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Aug 18, 2015

@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.)

1j01 commented Aug 18, 2015

@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.)

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Aug 18, 2015

Contributor

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.

Contributor

jedmao commented Aug 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 19, 2015

Member

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

Member

ai commented Aug 19, 2015

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

@alwillis

This comment has been minimized.

Show comment
Hide comment
@alwillis

alwillis Aug 19, 2015

@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.

alwillis commented Aug 19, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@mojereliev

mojereliev Aug 19, 2015

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

mojereliev commented Aug 19, 2015

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

@urec

This comment has been minimized.

Show comment
Hide comment
@urec

urec Aug 19, 2015

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

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

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

urec commented Aug 19, 2015

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

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

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 19, 2015

Member

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

Member

ai commented Aug 19, 2015

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

@gazay

This comment has been minimized.

Show comment
Hide comment
@gazay

gazay Aug 19, 2015

Member

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
Member

gazay commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gazay

gazay Aug 19, 2015

Member

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

Member

gazay commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 19, 2015

Member

@gazay nested styles is important

Member

ai commented Aug 19, 2015

@gazay nested styles is important

@gazay

This comment has been minimized.

Show comment
Hide comment
@gazay

gazay Aug 19, 2015

Member

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

Member

gazay commented Aug 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kezzbracey

kezzbracey Aug 20, 2015

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.

kezzbracey commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@talgautb

talgautb Aug 20, 2015

Contributor

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

Contributor

talgautb commented Aug 20, 2015

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

@azat-io

This comment has been minimized.

Show comment
Hide comment
@azat-io

azat-io Aug 20, 2015

Contributor

Best suggestion @talgautb

Contributor

azat-io commented Aug 20, 2015

Best suggestion @talgautb

@andrejsm

This comment has been minimized.

Show comment
Hide comment
@andrejsm

andrejsm Aug 20, 2015

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!

andrejsm commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@kezzbracey

kezzbracey Aug 20, 2015

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.

kezzbracey commented Aug 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@andrejsm

andrejsm Aug 20, 2015

@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.

andrejsm commented Aug 20, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@kezzbracey

kezzbracey Aug 20, 2015

@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.

kezzbracey commented Aug 20, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@akella

akella Aug 20, 2015

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.

akella commented Aug 20, 2015

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.

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 20, 2015

Member

@andrejsm nope, flexibility had really bad history in Stylus. It has very complicated parser with unexpected behaviour.

@talgautb I am not against 2 parsers, but I will write only one ;). It is not only : or not-: question. If we remove : it will hcange many other aspects of syntax.

Member

ai commented Aug 20, 2015

@andrejsm nope, flexibility had really bad history in Stylus. It has very complicated parser with unexpected behaviour.

@talgautb I am not against 2 parsers, but I will write only one ;). It is not only : or not-: question. If we remove : it will hcange many other aspects of syntax.

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 20, 2015

Member

@gazay your Haskell suggestion is awesome. Main question, do it will be understanded by users without reading a docs?

Member

ai commented Aug 20, 2015

@gazay your Haskell suggestion is awesome. Main question, do it will be understanded by users without reading a docs?

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 20, 2015

Member

@akella what about multiline values and multiline selectors?

Member

ai commented Aug 20, 2015

@akella what about multiline values and multiline selectors?

@akella

This comment has been minimized.

Show comment
Hide comment
@akella

akella Aug 20, 2015

@ai in sass they proved to be useless for setting css values, this is just uncomfortable to type. If you mean arrays or some other things - we can have some magic symbol at start, like {}. Multiline arrays are possible in Sass syntax too.

akella commented Aug 20, 2015

@ai in sass they proved to be useless for setting css values, this is just uncomfortable to type. If you mean arrays or some other things - we can have some magic symbol at start, like {}. Multiline arrays are possible in Sass syntax too.

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 20, 2015

Member

@akella i mean very long values like gradients. It is better to write each gradient on new line to keep it clear.

Member

ai commented Aug 20, 2015

@akella i mean very long values like gradients. It is better to write each gradient on new line to keep it clear.

@akella

This comment has been minimized.

Show comment
Hide comment
@akella

akella Aug 20, 2015

@ai understood you point, but i think this case is not that important, mostly all the gradients are hidden inside mixins now. I do it like +g($color1,$color2), so typing smthlike:

.block
    background: g($color1,$color2), g($color3,$color4)

is not that hard at all for me. And multiple gradients is not a common situation in code, to consider it for syntax, imho.

I mean, you can have 2-3 rules like that for a website, and than a couple of thousands ':' and '{}'. The latter is more important imho.

akella commented Aug 20, 2015

@ai understood you point, but i think this case is not that important, mostly all the gradients are hidden inside mixins now. I do it like +g($color1,$color2), so typing smthlike:

.block
    background: g($color1,$color2), g($color3,$color4)

is not that hard at all for me. And multiple gradients is not a common situation in code, to consider it for syntax, imho.

I mean, you can have 2-3 rules like that for a website, and than a couple of thousands ':' and '{}'. The latter is more important imho.

@gazay

This comment has been minimized.

Show comment
Hide comment
@gazay

gazay Aug 20, 2015

Member

@ai in Haskell it solved by good, very clear explained compilation time error messages

Member

gazay commented Aug 20, 2015

@ai in Haskell it solved by good, very clear explained compilation time error messages

@kezzbracey

This comment has been minimized.

Show comment
Hide comment
@kezzbracey

kezzbracey Aug 20, 2015

@akella There are still many workflows where gradients aren't hidden inside mixins. For example, people use software to grab CSS out of Sketch / Photoshop / Reflow designs and drop it straight into code. Multiline gradients are common in these cases.

Also, plugins where several arguments are passed might be more easily used with multiline values.

kezzbracey commented Aug 20, 2015

@akella There are still many workflows where gradients aren't hidden inside mixins. For example, people use software to grab CSS out of Sketch / Photoshop / Reflow designs and drop it straight into code. Multiline gradients are common in these cases.

Also, plugins where several arguments are passed might be more easily used with multiline values.

@akella

This comment has been minimized.

Show comment
Hide comment
@akella

akella Aug 20, 2015

@kezzbracey agree on that, but i think the most important thing, that : and {} are way more common inside our CSSs than those multiple gradients.

akella commented Aug 20, 2015

@kezzbracey agree on that, but i think the most important thing, that : and {} are way more common inside our CSSs than those multiple gradients.

@kezzbracey

This comment has been minimized.

Show comment
Hide comment
@kezzbracey

kezzbracey commented Aug 20, 2015

@akella Fair point.

@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Jan 26, 2016

@ai That's ridiculous and tendentious. We should support any indentation, just not mixed.

1j01 commented Jan 26, 2016

@ai That's ridiculous and tendentious. We should support any indentation, just not mixed.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

I'm inclined to agree with @1j01. All about tabs here.

Contributor

jedmao commented Jan 26, 2016

I'm inclined to agree with @1j01. All about tabs here.

@corysimmons

This comment has been minimized.

Show comment
Hide comment
@corysimmons

corysimmons Jan 26, 2016

Contributor

I hate tabs, but my company uses them. They're pretty much everywhere. Is there some technical limitation or is this just a "screw tabs" kinda thing?

Contributor

corysimmons commented Jan 26, 2016

I hate tabs, but my company uses them. They're pretty much everywhere. Is there some technical limitation or is this just a "screw tabs" kinda thing?

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

tabs-vs-spaces

Contributor

jedmao commented Jan 26, 2016

tabs-vs-spaces

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 26, 2016

Member

Mixing tabs and spaces for indent-based languages is very dangerous. This is why it is better to deny tabs abd solve problem at the beginning.

For example, YAML denies tabs too.

Member

ai commented Jan 26, 2016

Mixing tabs and spaces for indent-based languages is very dangerous. This is why it is better to deny tabs abd solve problem at the beginning.

For example, YAML denies tabs too.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

I like the Python approach where all indentation is supported, but MIXED indentation is denied.

Contributor

jedmao commented Jan 26, 2016

I like the Python approach where all indentation is supported, but MIXED indentation is denied.

@corysimmons

This comment has been minimized.

Show comment
Hide comment
@corysimmons

corysimmons Jan 26, 2016

Contributor

PostCSS users aren't idiots. We figured out the whole tab/space thing a long time ago. Just let a few people make mistakes that they'll quickly figure out, and let everyone else pick their preferred syntax.

Basically what @jedmao said. Deny mixed indentation.

Contributor

corysimmons commented Jan 26, 2016

PostCSS users aren't idiots. We figured out the whole tab/space thing a long time ago. Just let a few people make mistakes that they'll quickly figure out, and let everyone else pick their preferred syntax.

Basically what @jedmao said. Deny mixed indentation.

@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Jan 26, 2016

@ai "Mixing tabs and spaces for indent-based languages is very dangerous. This is why it is better to deny spaces and solve problem at the beginning."

Broken logic.

1j01 commented Jan 26, 2016

@ai "Mixing tabs and spaces for indent-based languages is very dangerous. This is why it is better to deny spaces and solve problem at the beginning."

Broken logic.

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Jan 26, 2016

Member

OK, I will try to add spaces-tabs mixing logic. But it is uch harder, than just add tab-check in tokenizer.

Member

ai commented Jan 26, 2016

OK, I will try to add spaces-tabs mixing logic. But it is uch harder, than just add tab-check in tokenizer.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

Too many people are not aware of what "mixing" tabs and spaces actually means. It's perfectly OK to have leading tabs, followed by spaces. What you want to flag is two scenarios:

  1. Leading spaces, followed by tabs.
  2. Leading tabs, followed by spaces, followed by more tabs.

What you do NOT want to flag are the following scenarios:

  1. Leading tabs (indentation), followed by spaces (alignment).
  2. Anything that happens after indentation (you shouldn't be concerned about it).
Contributor

jedmao commented Jan 26, 2016

Too many people are not aware of what "mixing" tabs and spaces actually means. It's perfectly OK to have leading tabs, followed by spaces. What you want to flag is two scenarios:

  1. Leading spaces, followed by tabs.
  2. Leading tabs, followed by spaces, followed by more tabs.

What you do NOT want to flag are the following scenarios:

  1. Leading tabs (indentation), followed by spaces (alignment).
  2. Anything that happens after indentation (you shouldn't be concerned about it).
@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Jan 26, 2016

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 commented Jan 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Jan 26, 2016

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}"

1j01 commented Jan 26, 2016

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}"
@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

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

Contributor

jedmao commented Jan 26, 2016

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

@1j01

This comment has been minimized.

Show comment
Hide comment
@1j01

1j01 Jan 26, 2016

@jedmao I suppose so. Not inherently, anyway.

1j01 commented Jan 26, 2016

@jedmao I suppose so. Not inherently, anyway.

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jan 26, 2016

Contributor

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

Contributor

jedmao commented Jan 26, 2016

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Feb 6, 2016

Member

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

Member

ai commented Feb 6, 2016

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

@corysimmons

This comment has been minimized.

Show comment
Hide comment
@corysimmons

corysimmons Feb 6, 2016

Contributor

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

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

Contributor

corysimmons commented Feb 6, 2016

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

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

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Feb 7, 2016

Contributor

Thank you @ai!

Contributor

jedmao commented Feb 7, 2016

Thank you @ai!

@lalomartins

This comment has been minimized.

Show comment
Hide comment
@lalomartins

lalomartins Feb 9, 2016

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.

lalomartins commented Feb 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Feb 9, 2016

Member

@lalomartins yeap it will support nesting

Member

ai commented Feb 9, 2016

@lalomartins yeap it will support nesting

@lalomartins

This comment has been minimized.

Show comment
Hide comment
@lalomartins

lalomartins commented Feb 9, 2016

👍

@danielbayley

This comment has been minimized.

Show comment
Hide comment
@danielbayley

danielbayley Mar 5, 2016

Contributor

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?

Contributor

danielbayley commented Mar 5, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 5, 2016

Member

@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

Member

ai commented Mar 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@whaaaley

whaaaley Mar 6, 2016

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

whaaaley commented Mar 6, 2016

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 7, 2016

Member

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

Member

ai commented Mar 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@jescalan

jescalan Mar 7, 2016

@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 😁

jescalan commented Mar 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 7, 2016

Member

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

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

Member

ai commented Mar 7, 2016

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

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

@danielbayley

This comment has been minimized.

Show comment
Hide comment
@danielbayley

danielbayley Mar 7, 2016

Contributor

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…

Contributor

danielbayley commented Mar 7, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 8, 2016

Member

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

I am writing a docs and converting tool right now.

Member

ai commented Mar 8, 2016

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

I am writing a docs and converting tool right now.

@dbox

This comment has been minimized.

Show comment
Hide comment
@dbox

dbox Mar 8, 2016

Thanks for the all the work @ai!

dbox commented Mar 8, 2016

Thanks for the all the work @ai!

@corysimmons

This comment has been minimized.

Show comment
Hide comment
@corysimmons

corysimmons Mar 8, 2016

Contributor

🎉

Contributor

corysimmons commented Mar 8, 2016

🎉

@danielbayley

This comment has been minimized.

Show comment
Hide comment
@danielbayley

danielbayley Mar 8, 2016

Contributor

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.

Contributor

danielbayley commented Mar 8, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 9, 2016

Member

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

Member

ai commented Mar 9, 2016

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

@ai

This comment has been minimized.

Show comment
Hide comment
@ai

ai Mar 9, 2016

Member

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

Member

ai commented Mar 9, 2016

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

@aazcast

This comment has been minimized.

Show comment
Hide comment
@aazcast

aazcast Aug 30, 2017

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

aazcast commented Aug 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ai

ai Aug 31, 2017

Member

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

Member

ai commented Aug 31, 2017

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

@aazcast

This comment has been minimized.

Show comment
Hide comment
@aazcast

aazcast Aug 31, 2017

@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.

aazcast commented Aug 31, 2017

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment