CODEWITHSUNDEEP
css
Ionică Bizău
Ionică Bizău

Reputation: 113455

How are the invalid CSS lines interpreted?

I spent about 30 minutes to debug a font loading problem in a page and I finally found that I was using wrong comment:

// this is a comment
@font-face {
   /* is this ignored? */
   ...
}

.box {
  border: ... /* this was not ignored */
}

After changing // in /* ... */ the fonts are correctly loaded.

So, my question is: How are the invalid CSS lines interpreted? Are they just ignored or the other CSS properties are affected?

The example above is just an example. The question is about general invalid lines.

A good official reference is welcome.

Upvotes: 7

Views: 582

Answers (4)

BoltClock
BoltClock

Reputation: 724302

The thing about / is that it doesn't appear anywhere in the CSS2.1 grammar outside of a comment delimiter or a string, so if you're looking at the grammar, it's hard to tell how it'd affect stylesheet parsing exactly.

It could count as a malformed selector, because the basic building block of CSS consists of a selector and a declaration block (collectively a rule set), but since / does not appear in the Selectors grammar except in string values, which selectors are not, I would hesitate to consider it as a selector.

I would say that in this specific case, it's just a generic statement that's malformed:

  • Malformed statements. User agents must handle unexpected tokens encountered while parsing a statement by reading until the end of the statement, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes. For example, a malformed statement may contain an unexpected closing brace or at-keyword. E.g., the following lines are all ignored:

    p @here {color: red}     /* ruleset with unexpected at-keyword "@here" */
@foo @bar;               /* at-rule with unexpected at-keyword "@bar" */
}} {{ - }}               /* ruleset with unexpected right brace */
) ( {} ) p {color: red } /* ruleset with unexpected right parenthesis */

A statement is defined as either a rule set, or an at-rule, which usually consist of some token, followed by a pair of curly braces ({}) or anything up to the next semicolon (;). Note again that none of the examples here have /, but since it is an unexpected character in a generic statement, it's expected that it'd cause your entire @font-face "rule" to be ignored.

Upvotes: 4

Mr. Alien
Mr. Alien

Reputation: 157384

From W3C :

Comments begin with the characters "/*" and end with the characters "*/". They may occur anywhere outside other tokens, and their contents have no influence on the rendering. Comments may not be nested.

Further, Section 4.2 Rules for handling parsing errors

In some cases, user agents must ignore part of an illegal style sheet. This specification defines ignore to mean that the user agent parses the illegal part (in order to find its beginning and end), but otherwise acts as if it had not been there.

So not only //, even if you have an invalid selector, it will skip the next block entirely and will move to second one.

Demo Stray a selector, and the second property block just fails as there are no {} after

Demo 2 a selector with braces {}

So in general, it's not the invalid comment there, but it's an invalid statement which causes an issue to parse your stylesheet correctly..

Upvotes: 4

Deepu Sasidharan
Deepu Sasidharan

Reputation: 5309

load the page on browser and then right click->inspect element.You get a window bottom of browser, right side of that window in style section all style attributes for corresponding control are specified.Invalid style attributes are cross lined.

Upvotes: 0

Paul Butcher
Paul Butcher

Reputation: 6956

From the Official Reference

This rule is what you are seeing:

  • At the "top level" of a stylesheet, an at-keyword-token starts an at-rule. Anything else starts a qualified rule, and is included in the rule’s prelude. This may produce an invalid selector, but that’s not the concern of the CSS parser — at worst, it means the selector will match nothing.

That is to say, your "//" is treated as introducing a qualified rule, so the interpreter is trying to match nodes using the selector "// this is a comment @font-face", which it will obviously fail to do, because that makes no sense.

This is another rule that you are very likely to experience:

  • When interpreting a list of declarations, unknown syntax at any point causes the parser to throw away whatever declaration it’s currently building, and seek forward until it finds a semicolon (or the end of the block). It then starts fresh, trying to parse a declaration again.

Upvotes: 3

Related Questions