Skip to content
This repository has been archived by the owner on Mar 28, 2019. It is now read-only.

Non-error when missing a semi-colon in CSS #21

Closed
Pomax opened this issue Apr 24, 2012 · 2 comments
Closed

Non-error when missing a semi-colon in CSS #21

Pomax opened this issue Apr 24, 2012 · 2 comments

Comments

@Pomax
Copy link
Contributor

Pomax commented Apr 24, 2012

This is currently not an error:

font-weight: 200
font-size: hmm;

technically css doesn't care about newlines (as far as I know) so without permitted-values-for-properties parsing we either keep this in, or we add a soft-rule that newlines break up values. Which would have the most educational value?

@toolness
Copy link

I think that adding the soft rule provides the least educational value for a few reasons:

  • If you put a valid value for font-size in your example, like 30px, it doesn't actually get applied, because the browser's own CSS parser gets confused when it doesn't see the semicolon after the previous CSS value. So that's a very clear case of the user intending something, the browser silently failing, and the user having no feedback to tell them about what needs fixing. It'd be okay for our own soft rules to mimick those of a real browser--for instance, the way we silently ignore invalid character entity references--but in this case our soft rule wouldn't mirror the soft rules of "the real world", thus providing no value.
  • Because Slowparse sees font-size as a CSS value rather than a CSS property, it becomes hard for the editor to provide context-sensitive help on it.

Oh, wait, maybe I misinterpreted your suggestion. Are you suggesting that we throw an error if we see a newline in a CSS property value? I'd actually be okay with that; I don't think I've ever seen newlines in CSS property values "in the wild", so it seems okay to assume that the user has forgotten a semicolon rather than assuming that they are putting a newline in their CSS property value for code formatting purposes. Once we add the ability for slowparse to issue non-fatal warnings rather than errors, we can turn this into a warning.

How does that sound?

@Pomax
Copy link
Contributor Author

Pomax commented May 4, 2012

for the moment we can leave it as "works as intended" but it might be nice, in the future, to improve on this. closing it for now, though.

@Pomax Pomax closed this as completed May 4, 2012
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants