Skip to content
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

Compatible with stylus-like syntax #761

Closed
leecade opened this issue May 2, 2017 · 6 comments
Closed

Compatible with stylus-like syntax #761

leecade opened this issue May 2, 2017 · 6 comments

Comments

@leecade
Copy link

leecade commented May 2, 2017

const Title = styled.h1`
  font-size: 1.5em;
  text-align: center;
  color: palevioletred;
`;

const Wrapper = styled.section`
  padding: 4em;
  background: papayawhip;
`;

Compare with below:

const Title = styled.h1`
  font-size 1.5em
  text-align center
  color palevioletred
`

const Wrapper = styled.section`
  padding 4em
  background papayawhip
`

Painful to write a ; at the end of the line, hope stylus-like syntax is supported here.

I guess it is possible to be serialized through some simple rules: adding a ; by line; adding : by first space.

ref: http://stylus-lang.com/

@geelen
Copy link
Member

geelen commented May 3, 2017

Sorry, but I want to keep the CSS in Styled Components as close to vanilla CSS as possible, with the exception of nesting and autoprefixing. Anything else could potentially lead to very confusing behaviour, particularly when it comes to interpolations.

If you're finding things like : and ; painful potentially you're writing too much CSS. Try breaking out snippets and bringing them in with interpolations, that should make things a little nicer to work with.

@geelen geelen closed this as completed May 3, 2017
@nuragic
Copy link

nuragic commented Jun 12, 2017

@geelen Hi, I was just wondering the same as @leecade... Even if there will be no chance to support stylus-like syntax out of the box, is there any other way that you would suggest (apart from forking the lib and implementing it) to achieve the same? Could be the parser configured in some way, at some point, in the future?

Thanks!

@nuragic
Copy link

nuragic commented Jun 12, 2017

If you're finding things like : and ; painful potentially you're writing too much CSS.

Or you just realize that not having them is quite better for readability! 😄 Also keep in mind that in Stylus they're basically optional and writing plain CSS is actually valid Stylus.

@thysultan
Copy link

thysultan commented Jun 12, 2017

The parser supports no-semicolons when enabled, the next patch version might enable this which would make... possible

const Title = styled.h1`
  font-size: 1.5em
  text-align: center
  color: palevioletred
`

Strictly from a technical POV, parsing the stylus pattern without colons color red is harder when your aiming for a small parser, taking into account false positives between selectors and properties – i.e how do you diff between

<h1 h2>
{

}

vs

<color red>

When all you know about the two is the parts in xml brackets.

@nuragic
Copy link

nuragic commented Jun 12, 2017

@thysultan I can go to sleep right now knowing that soon we can at least get rid of the ; ! 👏 😄

Regarding your question, I guess with Indentation? Maybe I was wrong when I stated:

writing plain CSS is actually valid Stylus.

Maybe I need to amend that to say:

writing plain indented CSS is actually valid Stylus. 😬

Anyway, I agree about trying to keep the parser as small as possible; I'd just buy that argument against the possibility of just being able to remove : TBH.

@thysultan
Copy link

thysultan commented Jun 13, 2017

Explored this a bit when working on the no-semicolon options though for different reasons – since i wanted to try and monkey-patch some common syntax errors i.e color red;.

So it is possible, you just have to do a lot more book keeping to avoid false positives since there are many valid ways you can write css selectors(involving whitespace) and properties that look syntactical similar without the colon.

Though it might not make it into s-c – but if you do have some ideas on the subject i'm open to input on implementations, the one i came up with at the time involved a 100% in/out approach to one format over the other.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants