CSS3 added the <column-token> operator as follow:
<column-token>: ||
It also says:
<column-token> has been added, to keep Selectors parsing in single-token lookahead.
So, is that just an artifact of the lexer, or is that an actual operator used for something I do not know about yet?
CSS level 4 does in fact have a column operator (used to select table cells of a column).
No idea if that's related and the token was added to CSS3 to be forward-compatile - it would be strange, but then the naming does not sound coincidental. The argument for the new token was indeed parsing convenience:
I just added a COLUMN token to the Syntax draft, matching "||". It's
needed for Selectors, so it can maintain LL(1). (Otherwise, seeing
"*" followed by "|" is ambiguous until you look at the next token.)
Which I admit I don't quite understand. What else could *| be interpreted as, even in CSS4? There is no other valid use of | in a selector (except inside an attribute matcher, but there there is no valid use for ||). CSS4 Values uses both *, | and || but that's not the spec the email was referring to.
This is not strictly a CSS3 feature, column-token is just one of many tokens used to parse currently interpreted CSS stylesheet by CSS parser. So it has no use for you unless you're implementing a CSS parser.
Related
According the CSS Level 3 specification, for parsing the start of an identifier, you:
Check if three code points would start an identifier
Look at the first code point:
If the first character is -, then we have a valid identifier if:
The second code point is an identifier-start code point ([a-zA-Z_] or non-ASCII).
The second code point is -.
The second and third character form a valid escape.
Otherwise, we do not have a valid identifier start. After determining if we have a valid identifier start, the only requirements to have a valid <ident-token> is we have 0 or more of any combination of the following:
Escape tokens
ASCII letters
Digits
_ or -
Non-ASCII characters
Since we do not require any characters following an identifier start token, this would suggest that -- is a valid identifier, even if never supported by any browser or framework. However, even official CSS validation services (maintained by those that design the CSS specifications) do not consider this a valid identifier. Is this merely a bug in the validation service?
Yes it's valid and it works. It's the shortest custom property (aka CSS variable) that you can define:
body {
--:red;
background:var(--);
}
Related: Can a css variable name start with a number?
The -- custom property identifier is reserved for future use, but current browsers incorrectly treat it as a valid custom property.
See also
w3c/csswg-drafts#6313
I am using Handlebars templates. If I want to insert a variable in an hbs file, I add it as {{var_name}}.
The issue is, I have a large object with its keys taking formats similar to:
{
"stats.name":"John",
"stats.performance.day":123,
"stats.performance.month":4567,
"company":"My LLC"
}
If I try to add these to the Handlebars file as {{company}}, {{stats.name}}, {{stats.performance.day}}, {{stats.performance.month}} then only the {{company}} will be displayed. All other values come out blank, I assume because "." is a special character in Handlebars.
My question is, is there a way to override this, or do I actually need to iterate through this object and change every "." to a "_" or something before passing it to Handlebars to make it work?
I would recommend renaming your properties. Dot Notation is one of the two ways to access object properties in JavaScript. Typical code would look like: obj.prop. If your object's keys are not valid identifiers, then you must use Bracket Notation: obj['my-prop']. Since a dot is a property accessor, it is very unusual to see one in a property name. If I were to come across code written as obj['stats.performance.date'], I would assume it was a mistake and that obj.stats.performance.date was intended.
With that said, Handlebars does support referencing properties that are not valid identifiers. This is called "segment-literal-notation", and it is as simple as wrapping square brackets around your identifier:
{{[stats.performance.day]}}
The documentation also states that:
JavaScript-style strings, " and ', may also be used vs. [ pairs.
So the following alternatives are valid:
{{"stats.performance.day"}}
{{'stats.performance.day'}}
In BEM, I understand that with modifiers, two dashes makes sense so that you can distinguish the modifier in my-block-my-modifier with my-block--my-modifier.
But why use block__element instead of block_element?
Double Underscore is used to define sub element of a block.
i.e:
<nav class="main-nav">
<a class="main-nav__item" href="#">Text</a>
</nav>
Where main-nav is a block & main-nav__item is a sub element.
This is done because some people might name their block like this main_nav which will create confusion with single underscore like this : main_nav_item
Therefore double underscore will clarify stuff like this: main_nav__item.
I'm going to 2nd #Imran Bughio's answer, but I'm trying to further clarify the issue.
In standard BEM style, single underscores are reserved for modifiers. Also, they usually represent a combination of key/value pairs. E.g.
.block_align_vertical
.block_align_horizontal
.block__element_size_big
.block__element_size_small
This is in contrast to the modified BEM syntax championed by inuit.css for example, which are boolean.
.block--vertical
.block--horizontal
.block__element--big
.block__element--small
From my experience when using the modified syntax, you quickly run into expression limitations. E.g. if you would write
.block--align-vertical
.block--align-horizontal
.block__element--size-big
.block__element--size-small
The key/value relation would not be unique, if you would try to describe a key such as background-attachment which would result in
.block__element--background-attachment-fixed
Another added benefit is, that you can use the libraries based on the standard naming convention for added productivity in your workflow:
http://bem.info/tools/bem/bem-tools/
https://github.com/hoho/jquery-bem
It's also worth mentioning that the BEM syntax is not forced upon us and if you find another syntax that you find more readable then by all means go with that. The important thing is consistency, ensuring other developers work to the same syntax.
An example of an alternative syntax used is in SUIT CSS by Nicolas Gallagher. Which uses the following syntax.
ComponentName
ComponentName--modifierName
ComponentName-elementName
ComponentName.is-stateOfComponent
You can read more here SUIT CSS naming conventions
Because whose blocks can be hyphen or underscore delimited, for example:
.site-search {} /* Block */
.site-search__field {} /* Element */
.site-search--full {} /* Modifier */
or
.site_search {} /* Block */
.site_search__field {} /* Element */
.site_search--full {} /* Modifier */
According to BEM naming convention, single underscore has two other usages,
The modifier name is separated from the block or element name by a single underscore (_).
The modifier value is separated from the modifier name by a single underscore (_).
So for separating element name from the block name is done by a double underscore.
The element name is separated from the block name by a double underscore (__).
Let's look at this CSS rule:
#foo { color: red; }
As you can see, the declaration block of the above rule contains one declaration, namely color: red. However, according to my interpretation of the CSS standard, the above declaration block also contains a second, empty declaration, which is located between the chars ; and }.
#foo { color: red; }
^ --- an empty declaration is located here
I'm asking this question on Stack Overflow to determine if my interpretation is correct, i.e. if there indeed exists a second, empty declaration in the above CSS rule.
Btw, I'm using the CSS 2.1 standard, specifically "Chapter 4: Syntax", since the "CSS Syntax" module is outdated, and not safe to use.
OK, let me explain. I base my interpretation on these definitions:
The standard states that, within a declaration block, a semi-colon is a separator which appears between individual declarations:
A declaration block starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more semicolon-separated (;) declarations.
So, according to the above definition, a semi-colon my only appear between two declarations, i.e. a semi-colon must be both preceded, and followed by a declaration.
The standard defines a declaration as:
A declaration is either empty or consists of a property name, followed by a colon (:), followed by a property value.
The above definition states that a declaration can be empty. Unfortunately, the standard does not define the term "empty declaration", nor is that term mentioned anywhere else in the standard.
Let's go back to the example:
#foo { color: red; }
The above rule is valid CSS. By applying the definition for semi-colons (from above), the semi-colon in this rule must both be preceded, and followed by a declaration. However, the semi-colon is followed by the closing curly brace (which ends the declaration). In order to explain this contradiction, I insert an empty declaration between ; and }, and provide this definition:
An empty declaration is the absence of a declaration in a position within a declaration block where a declaration i required, but not found.
Is this interpretation of the standard correct, and does the declaration block indeed contain two declarations?
Yes, this is normal in computer languages that define the semicolon as a separator and not part of a statement (or declaration or whatever). There is no other possible interpretation, and the issue has no practical impact, as an empty declaration has no effect.
I agree with you that the reading states it such that your situation shows an empty declaration. Indeed, your reference page in most cases has no final ; before the end brace in its examples. I think your definition is close, but did not quite hit on the idea of "empty." Instead:
An empty declaration is a declaration without any content
within a declaration block where a declaration is required.
or perhaps, given the note here, this...
An empty declaration is a declaration with no more than white-space as content
within a declaration block where a declaration is required.
Contra Jukka's comment about "no practical impact ... no effect," I would tend to think that there would be an ever so slight impact in that their is one additional parse to do for such a code block (realizing, as some seem to think I was arguing when I was not, that it has no functional effect). The page states:
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.
While an empty declaration is not illegal, I believe the parser would need to perform one extra step to determine it is empty before realizing it was at the end of the declaration block.
At first glance, the specification seems slightly inconsistent in this respect; despite the passages that you quote, the formal grammar defines the declaration production as property ':' S* expr prio?, which is never empty. However, whenever declaration appears in any other production, it is always followed by ?, marking it as optional; in other words, anywhere that the grammar allows declaration, it also allows [nothing].
We can resolve the inconsistency by saying that the term "declaration", where appearing in the specification's English prose, refers to declaration? (declaration-or-[nothing]) rather than to declaration; but I think the main take-home point is that it doesn't matter. The specification is written in such a way that an empty declaration truly has no effect.
(And hey, it could be worse. Standard ML allows empty declarations, and allows semicolons to be omitted between declarations; so something like val a = 7 val b = 20 can be parsed as a sequence of arbitrarily many empty declarations, with two non-empty declarations mixed in.)
There seems to be a breaking (i.e. backwards-incompatible) change in the CSS Syntax Module Level 3 specification upcoming draft: trailing semicolon after the last declaration in a block is now perhaps required.
Compare the old wording (W3C Working Draft 13 August 2003):
4.8. Rule sets, declaration blocks, and selectors
A declaration-block (also called a {}-block in the following text) starts with a left curly brace ({) and ends with the matching right curly brace (}). In between there must be a list of zero or more semicolon-separated (;) declarations.
with the new one (Editor's Draft 14 June 2012):
2. Description of CSS's Syntax
A rule starts with a selector (defined by the Selectors specification), then has a {}-wrapped block containing a sequence of declarations. The selector specifies which elements the declarations will apply to. Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.
(emphasis mine).
So that nifty short forms, e.g.:
em { color: lime }
(this is currently given as valid example in the CSS Color Module Level 3 recommendation) will no longer validate.
Could someone more knowledgeable about the whole Level 3 drafts collection please verify? To future-proof stylesheets, do we really have to overhaul existing CSS files (and insert semicolons if missing) before the specification gets finalized or did I misunderstand something?
Looks like there currently is an ambiguity in the spec.
You correctly pointed out that 2. Syntax Description section prescribes ending every rule with a semicolon:
Each declaration has a property name, followed by a colon and the property value, and finished with a semicolon.
And at the same time, description of the parsing automaton in section 3.6.8. Declaration-value mode reads that a closing brace without a semicolon correctly ends a declaration and current rule at the same time:
} token
Append the current declaration to the value of the current rule. Pop the current rule from the stack of open rules, and append it to the value of the new current rule. Switch to the current rule's content mode.
So according to 3.6.8 trailing semicolon is optional.
I can't say about actual intention of the specification authors. But current situation should probably be reported and fixed. Most certainly they don't have intention of breaking the compatibility with CSS 2.1 and will reword their Syntax Description section in the final version.
I think that it's just a mistake when writing the specifications, and that the real intention was to have it as a separator, just as in previous versions. I expect this to be adjusted in later drafts.
The W3C validation service says that the example without the trailing semicolon is valid CSS level 3.
I will however, as I have always done, end each declaration with a semicolon. This is a good practice, so that you don't forget the separator when you add more declarations.
This is an example of the 'separator-terminator' problem. Evidently CSS 3 has moved from the semicolon being a separator to the semicolon being a terminator. That means it is required after every element, not just between the elements. Pascal (separator) and C (terminator) provide other examples. This leads to apparent anomalies in Pascal such as semicolon being illegal before 'else' or 'until'. Why CSS 3 adopted a CSS-2-incompatible rule is beyond me, and whether implementations will insist on it is another matter, but the intent of the quotation is clear: it's a terminator and must therefore be present on all entries including the last.