What's the standard way to deal with unsupported CSS expressions? - css

What does the CSS standard say about unsupported expressions? How should a browser deal with them? How do actual browser implementations deal with them?
I'm implementing a CSS property optimizer (for a minifier project), and we want to leave CSS fallbacks intact. Our goal is to optimize the CSS as much as possible but in such a way that it should render exactly the same as the original.
This is why it's essential for me to understand how these things work.
Simple properties
For simple properties, it's really easy.
Let's say we have this:
div {
color: #f00;
color: rgba(1,2,3,.4);
}
In this case, if the browser doesn't support rgba then the first declaration #f00 wins. There is no question here.
Shorthands
However, how does it work with shorthand properties?
Here's some code:
div {
background: #f00;
background: rgba(1,2,3,.4);
}
How does the browser render this if it doesn't understand rgba? As you know, the syntax of background is: background: <color> <image> <repeat> <attachment> <position>; and such a shorthand declaration overrides any of the 5 fine-grained declarations that came before it; so the difficulty lies in which one of the 5 fine-grained properties the browser tries to assign the unknown token to. I have several possibilities in mind:
the browser decides it doesn't understand the latter declaration at all and drops it entirely
the browser thinks that rgba(...) represents a background-image and even though it doesn't know what to do with it, clears out the previous background-color as well
the browser thinks that rgba(...) represents a background-color and since it doesn't understand it, falls back to using #f00 instead
Let's make it even more interesting, say we have this:
div {
background: #fff url(...) no-repeat;
background: rgba(1,2,3,.4) linear-gradient(...) repeat-y;
}
How does a browser interpret this CSS snippet, ...
if the browser doesn't understand rgba?
if the browser doesn't understand linear-gradient?
if the browser doesn't understand repeat-y?
if the browser doesn't understand any two of the three?
if the browser doesn't understand any of the three?

The parsing rules in section 4.2 of the CSS2.1 spec speaks in terms of declarations, which refer to entire property-value pairs, regardless of whether the properties are shorthand or not:
Illegal values. User agents must ignore a declaration with an illegal value. For example:
img { float: left } /* correct CSS 2.1 */
img { float: left here } /* "here" is not a value of 'float' */
img { background: "red" } /* keywords cannot be quoted */
img { border-width: 3 } /* a unit must be specified for length values */
A CSS 2.1 parser would honor the first rule and ignore the rest, as if the style sheet had been:
img { float: left }
img { }
img { }
img { }
A user agent conforming to a future CSS specification may accept one or more of the other rules as well.
Notice that the third example shows the use of an illegal value for the background shorthand property resulting in the entire declaration being ignored.
Although the spec speaks of illegal values, as far as an implementation is concerned an unrecognized value and an illegal value are the same thing, since either way the implementation doesn't know what to do with such a value.
So the answer to the first part of your question is
the browser decides it doesn't understand the latter declaration at all and drops it entirely
And the answers to the second part are all the same: the latter declaration is ignored entirely.

As far as I know, if a browser cannot understand even a part of an expression, then it handles the property as syntactically wrong, and ignores the whole line.

Related

how to base a css rule on inherited value of dir attribute

I know I can use [dir='ltr'] or [dir='rtl'] to select elements that have a dir attribute with a specific value.
so I can define for example
[dir='ltr'] .float-end {float:right}
[dir='rtl'] .float-end {float:left}
to get a .float-end class that floats right or left when inside an element with ltr or rtl respectively.
The problem starts when I have an ltr sub part of a document that is rtl.
<div dir="rtl">
<div dir="ltr">
<div class="float-end"></div>
</div>
</div>
What happens is that both rules match... and I only want to match the 'ltr' case in this scenario.
The problem gets worse if I want to create classes such as start-20px and end-20px to provide left:20px and right:20px and vice versa depending on context.
Would result in both left:20px and right:20px being applied....
I am looking for suggestions on how to overcome this.
Is there a way to depend on the nearest value of an attribute of any given type of element?
This is all done within the context of LESS mixins if it helps some how...
Thanks
The problem lies in the fact that the attribute selectors currently available in CSS have no document semantics. For example, you can't use attribute selectors to express some attribute value that is inherited from some other element. This is because as far as an attribute selector is concerned, if an element's attribute doesn't have a certain value specified on the element itself in the document tree, then it will not match the selector, even if the value is derived from elsewhere.
As mentioned, you could limit selection to the closest ancestor using the > combinator, but this requires the immediate ancestor to have the specified attribute, which of course you won't be able to guarantee is the case unless you make sure of it yourself. But if you are able to modify your markup, then that really is the best way to do this, even if it means a little bit of redundancy in your markup. I don't think even LESS by itself would be able to help you, as it still depends on the structure of your markup, which it cannot anticipate.
For what it's worth, Selectors 4 introduces a :dir() pseudo-class which carries semantics of element directionality based on the rules of the document language, something that attribute selectors alone cannot accomplish. For example, both the div and the p in the following example would match :dir(ltr), but only the div is [dir='ltr'] because the p has no dir attribute specified:
<div dir="ltr">
<p>Left-to-right text</p>
</div>
In your case, you would be able to just use .float-end:dir(ltr) and .float-end:dir(rtl) respectively; you wouldn't even need to have the pseudo-class on an ancestor.
The :dir() pseudo-class compared with the [dir=] attribute selector is similar to :lang() and [lang|=], which I explain here.
Of course, being a new proposal, :dir() isn't implemented anywhere (with the curious exception of Firefox — I'm guessing Mozilla thought of the idea, implemented it, then proposed for it to be standardized). In the meantime, you'll have to work around it by going the route I des
There is now a proposed solution for this in the CSS spec: Logical Properties. Basically instead of applying different property values based on some other element's dir attribute, browsers are going to start having property values that are directionally aware.
So in a perfect world, once these have full support you could write:
.float-end {
float: inline-end;
}
These new values will exist for lots of properties, not just float. Support as of July 2019 is pretty much everybody but Microsoft (IE/Edge), go figure.
Well, I can not give a solution to your first question (about floats), but I can give you one about the second (left / right properties).
As stated by the w3c
If neither 'left' nor 'right' is 'auto', the position is
over-constrained, and one of them has to be ignored. If the
'direction' property of the containing block is 'ltr', the value of
'left' wins and 'right' becomes -'left'. If 'direction' of the
containing block is 'rtl', 'right' wins and 'left' is ignored.
O.k.
So having learned that what I expected just does not work (at least not as of now [June 2014]),
I ended up with the following LESS based solution:
// provide a mixin to use two different rule sets depending on the current direction.
.ltr(#ltrRules) {
body[dir="ltr"] & , body[dir="rtl"] [dir="ltr"] &, body[dir="rtl"] [dir="ltr"]& { #ltrRules(); }
}
.rtl (#rtlRules) {
body[dir="rtl"] & , body[dir="ltr"] [dir="rtl"] &, body[dir="ltr"] [dir="rtl"]& { #rtlRules(); }
}
.bidi(#ltrRules,#rtlRules) {
.ltr(#ltrRules);
.rtl(#rtlRules);
}
// padding
// ------------------------------------------
.padding-start(#p) {
.bidi(
{ padding-left: #p } ,
{ padding-right: #p }
)
}
so using .padding-start(10;) on some SELECTOR
.my .selector {
.padding-start(10px);
}
will eventually generate the following CSS:
body[dir="ltr"] .my .selector,
body[dir="rtl"] [dir="ltr"] .my .selector,
body[dir="rtl"] [dir="ltr"].my .selector {
padding-left: 10px;
}
body[dir="rtl"] .my .selector,
body[dir="ltr"] [dir="trl"] .my .selector,
body[dir="ltr"] [dir="trl"].my .selector {
padding-right: 10px;
}
The compromise is that I can not change the direction multiple times going into the depth of the document and that the initial seeing of the direction must be on the body tag.
That siad, if for some absurd reason I WILL get to some point in the future when I will have to change the dir more then twice I can just use the same method and add handling for body[dir="ltr"] [dir="rtl"] [dir="ltr"] & and so on...
With some luck in a few years someone will understand that it is important to add the semantics of start and end that get interpreted as left and right respectively in LTR contexts and vice versa in TRL contexts making all my macros redundant... [as has already been done in text-align for example].
I know this is a very late reply but it could help someone if I got the question right.
Does this make sense?
[dir="ltr"] *:not([dir="rtl"]) .float-end,
[dir="ltr"] > .float-end{
float: right;
}
[dir="rtl"] *:not([dir="ltr"]) .float-end,
[dir="rtl"] > .float-end{
float: left;
}
JSFiddle here

Is it possible to detect broken/unloaded (error) images with CSS?

I'd like to give broken/errored images some extra CSS:
img:error {
max-width: 20px;
max-height: 20px;
}
but that doesn't work. Is there a way with pure CSS to do this? Is there an img pseudo selector for this? Or even better: a dirty hack that works?
I've looked around, but nobody seems to be wondering =)
(Yes, I know JS can do it and I know how; no need to mention it.)
There is no way in CSS specs or drafts, but Firefox has a proprietary selector (pseudo-class) :-moz-broken. Its documentation is very concise and it says “intended for use mainly by theme developers”, but it can be used e.g. as follows:
:-moz-broken { outline: solid red }
:-moz-broken:after { content: " (broken image)" }
Although the documentation says that it “matches elements representing broken image links”, it actually matches broken images (an img element where the src attribute does not refer to an image), whether they are links or not. Presumably, “links” really means “references” here.
CSS 2.1 says: “This specification does not fully define the interaction of :before and :after with replaced elements (such as IMG in HTML). This will be defined in more detail in a future specification.” But Selectors Level 3 (CSS3 Selectors) just says about them: “They are explained in CSS 2.1.” In practice, browsers handle them differently. Oddly enough, Firefox supports :-moz-broken:after but ignores :-moz-broken:before. It does not support either of these pseudo-elements for normal images, but img:after, too, is supported for a broken image (i.e., the specified content appears after the alt attribute value).
For this, you should use the alt attribute, wich shows up if link is broken and you can as well style background of image :
example:
img {
display:inline-block;
vertical-align:top;
min-height:50px;
min-width:300px;
line-height:50px;
text-align:center;
background:
linear-gradient(to bottom,
blue,
orange,
green);
font-size:2em;
box-shadow:inset 0 0 0 3px;
}
These style will be hidden when image is shown.
http://codepen.io/anon/pen/Kxipq
As you can see, we do not check for broken links, but offer alternative , usefull for blind people , searchengines, whatever , and some extra styles finishes it :)
some extra Image alt attribute best practices
<img src="not_found_image.png" onerror='this.style.display = "none"' />
from:
https://www.geeksforgeeks.org/how-to-hide-image-not-found-icon-when-source-image-is-not-found/
NO there is no :error pseudo class. This is a good site for a comprehensive list of what is available:
http://reference.sitepoint.com/css/css3psuedoclasses
July, 2015 EDIT/ADDITION:
(Thank you Rudie)
https://developer.mozilla.org/en-US/docs/Web/CSS/Pseudo-classes
No. There is nothing in CSS selectors level 2.1 or level 3 that allows targeting an image like that.
This is close:
<style>
img[data-broken="true"] {
visibility: hidden;
}
</style>
<img src="none.webp" onerror="this.setAttribute('data-broken', 'true')">
Strictly speaking, it sill uses JavaScript. But the JS is self contained in the image HTML code.

Why is the use of `!important` discouraged?

Several answers tagged css discourage the use of !important in favor of specificity. Why?
There is actual math you can use to predict, control, and reverse-engineer the impact of CSS rules. By using !important you're breaking that. Look at this JS fiddle for example, which doesn't use !important: http://jsfiddle.net/hXPk7/
If you use Firebug or Chrome dev tools to inspect the title element where it says "Richard", you should see these rules, in this order:
/**************************/
/* /hXPk7/show/ (line 20) */
/**************************/
#myExample #title .name {
color: yellow;
}
/********************************************************/
/* /hXPk7/show/ (line 14) - Inherited fromdiv#myExample */
/********************************************************/
#myExample {
color: blue;
}
Note that this is not the order in which they appear in the CSS stylesheet - instead they are ordered in decreasing order of their specificity. The ones which take precedence are listed first, and the others (whose rules are overridden by more specific rules) probably have a property crossed out. This demonstrates that specificity makes it easy to trace (debug?) where an element is getting its CSS properties from.
Now, compare with this JS fiddle - which is effectively the same, but has a single new rule which now uses !important: http://jsfiddle.net/hXPk7/1/
Inspect the same element using Firebug or Chrome dev tools, and you'll see something like this:
/**************************/
/* /hXPk7/1/show/ (line 20) */
/**************************/
#myExample #title .name {
color: yellow;
}
/**************************/
/* /hXPk7/1/show/ (line 26) */
/**************************/
span {
color: black !important;
}
/********************************************************/
/* /hXPk7/1/show/ (line 14) - Inherited fromdiv#myExample */
/********************************************************/
#myExample {
color: blue;
}
Again, the rules are ordered according to their specificity - but note that this time, while the most specific rule which is listed first specifies a color of yellow, the browser instead renders the text as black! This is because the !important declaration has broken the normal behavior of specificity, taking precedence in a way which can be challenging to trace. Imagine a more realistic web site, with potentially hundreds of rules, and the one controlling the color isn't obvious to find, or to change.
Now, maybe this is a problem with the developer tools, but I think it reflects the fact that !important takes a normally easy-to-predict system of precedence and makes it more challenging. Maybe there are times to use it, but it should not be the first tool you reach for when writing CSS.

How do you read !important in CSS? [duplicate]

This question already has answers here:
What does !important mean in CSS?
(5 answers)
Closed 3 years ago.
How is the CSS attribute property !important read?
Is it really important, exclamation mark important, ...?
Answer: From the answers below, it seems to be read simply important, or bang important.
an "!important" declaration (the delimiter token "!" and keyword
"important" follow the declaration) takes precedence over a normal
declaration.
http://www.w3.org/TR/CSS2/cascade.html#important-rules
Basically, where two style rules are the same... it gives the one marked !important greater importance and will apply those styles.
Example
div{
opacity:0 !important;
}
div.jason{
opacity:1;
}
The first rule would be applied even though the second rule is more specific (one element + one class as opposed to one element)
Note: IE6 ignores !important when you have two of the same property and one of them is important - it'll always apply the last declaration, whether or not it was marked important. **Added from #BoltClock's comment below.
Warning: !important is a hammer that should only be used when absolutely necessary. Almost always, it is better to use more specific selectors to achieve greater specificity and have your styles applied the way you want. !important can make it very difficult for future developers to find and make changes to your code.
One good use case: !important is great for user-defined styles, where a user wants to manipulate Web site pages in specific way in his browser (say make all the backgrounds black and the text yellow). Without having to worry about specificity, the user can add styles to certain elements (like body) and make the styles render.
Just "important" or "bang important." The ! is definitely not a negation in this case.
It's not a tag, it's a keyword.
body { color: red !important; } means, in English, "The text-color of red is important".
In terms of how CSS sees it, it applies more "weight" to that declaration, so it will be (far) more likely to be the applied style.
For an example of this, we can use
p { color: red; }
p.blue { color: blue; }
Now, any p with a class of blue will show blue text, all the others will show red text.
If we change it to this...
p { color: red !important; }
p.blue { color: blue; }
They will all show red text (even if they have a class of blue), as we've given more important to the first selector.
I like to think of it as "NOT important".
p {
color: red !important; /* The rest is NOT important for this CSS property. */
}
Meaning that everything else from that declaration and on is NOT important and should not be taken into account. The idea came from the usage of the "!" character as a boolean NOT in many programming languages. This way the !important makes sense as you read it.
I guess I read the ! as "very".
p { color: red !important }
I read as "Paragraphs have the color red, which is very important.

What does a star-preceded property mean in CSS?

I was looking at a css file today and found the following rule set:
div.with-some-class {
display:block;
margin:0;
padding:2px 0 0 0;
*padding:1px 0 0 0;
font-size:11px;
font-weight:normal;
*line-height:13px;
color:#3D9AD0;
}
What does the star mean in *padding and *line-height?
Thanks.
This is the "star property hack" along the same lines as the "underscore hack." It includes junk before the property that IE ignores (the * works up to IE 7, the _ up to IE 6).
In CSS? Nothing; it is an error.
Due to bugs in some versions of Internet Explorer, they won't correctly ignore the invalid property name, so this is one way of providing CSS that is specific to those browsers.
Using conditional comments is clearer and safer though.
The asteriks character is a valid wildcard in CSS. Use of it alone means the following CSS properties will be used against all element nodes in the DOM. Example:
*{color:#000;}
The above property will be applied to all DOM elements, thereby defeating the natural cascading in CSS. It can only be overridden by specifically tageting DOM elements where that targeting begins a unique identifier reference. Example:
#uniqueValue div strong{color:#f00;}
The above property will override the wildcard and make the text of all strong elements that occur in a div inside an element with an id attribute value of "uniqueValue".
Using a universally applied wildcard, such as the first example, can be a quick and dirty method for writing a reset stylesheet. It is quick and dirty because granular definition of presentation after the wildcard will likely create an extremely bloated stylesheet. If you are going to use the wildcard I would suggest using it more specifically, such as:
* strong{color:#f00;}
The above example will make the text of all strong elements color red regardless of other CSS properties not specified with a unique identifier. This is considered much safer than using the "!important" declaration as that declaration is known to cause interference with natural functionality of the intended behaviors and is a maintanence nightmare.
The asteriks in your example are in the wrong place as they seem to occur inside the property declarations, the code that goes inside curly braces, and that will likely cause an error.
This is a hack for IE7.
If you write this:
.test {
z-index: 1;
*z-index: 2;
}
on all navigator which respect the W3C Standard <div class="test"></div> HTMLElement have a z-index: 1 but for IE7, this element have a z-index: 2.
This is not standard.
To achieve same thing with W3C Standard, follow this steps:
Add some Internet Explorer Conditional Comment (this is a simple HTML Comment for all other navigateur so, it's a standard way).
<!--[if IE 7]><html lang="fr" class="ie7"><![endif]-->
<!--[if gt IE 7]><!--><html lang="fr"><!--<![endif]-->
And use the previous rules like this:
.test {
z-index: 1;
}
.ie7 .test {
z-index: 2;
}

Resources