Sneak Peek Into The Future: Selectors, Level 4 (CSS4) is here(coding.smashingmagazine.com)
coding.smashingmagazine.com
Sneak Peek Into The Future: Selectors, Level 4 (CSS4) is here
http://coding.smashingmagazine.com/2013/01/21/sneak-peek-future-selectors-level-4/
7 comments
> This will highlight the word being spoken in yellow.
I must be missing something here. What's the point of making something yellow if the user is using a screen reader?
I must be missing something here. What's the point of making something yellow if the user is using a screen reader?
One idea: Video + scrolling transcript. Current phrase is highlighted in yellow, future stuff is hidden (let's say this is an online lecture and users shouldn't be able to skip ahead), and past content that's already been watched is faded out.
It's just an example of :past, :current, :future the time dimensional pseudo-classes. There is a lot of scope for creative usage.
Especially the :future looks exciting and can be fun to play with.
Especially the :future looks exciting and can be fun to play with.
anyone know what the #important does in this selector from the article?
article:matches(.active, .visible, #important) {
background: red;
}
It continues to do what it normally does:
article#important {ha, never-mind. I was confusing myself thinking it was some special case a la !important. Just an ID of important.
so confused at "input.checkbox:indeterminate"
1. how does it know an unchecked checkbox has not been used? 2. why was a class of 'checkbox' added to the checkbox?
1. how does it know an unchecked checkbox has not been used? 2. why was a class of 'checkbox' added to the checkbox?
Oh boy this got me excited. Just to quote from the article:
"PARENT SELECTOR!"
I've been wanting this for years. One quibble is that it shouldn't be an exclamation, it should be a < character. A ! doesn't semantically make sense. Alternatively, perhaps ! keeps its current designation, but < means immediate ancestor. This would match with > meaning direct descendant.
Many of the other things, I don't see much point. They can be easily done with CSS as it is now. But, it's good to have new things coming up so lets withhold judgment till then.
"PARENT SELECTOR!"
I've been wanting this for years. One quibble is that it shouldn't be an exclamation, it should be a < character. A ! doesn't semantically make sense. Alternatively, perhaps ! keeps its current designation, but < means immediate ancestor. This would match with > meaning direct descendant.
Many of the other things, I don't see much point. They can be easily done with CSS as it is now. But, it's good to have new things coming up so lets withhold judgment till then.
> A ! doesn't semantically make sense.
Makes as much sense as the rest. ! is an operator of selected element in a selector, not a "parent selector". You can combine `!` with children selectors (`E! > F` will select any E with F children, it's equivalent to `xpath(E[F])` no use of the ancestor:: axis), they don't conflict. You don't actually go "back up" the selection chain, the matching engine simply changes which elements are "kept" during the selection process.
> Many of the other things, I don't see much point. They can be easily done with CSS as it is now.
For highly varying values of "easily". :matches requires a preprocessor or lots of repetition; :local-link is pretty much impossible without markup processing; time-dimensional elements emulation require a fair bit of markup and scripting; :indeterminate simply isn't available; and grid-structural pseudo-classes require markup support (and potentially scripting as well if the tables are dynamic)
Makes as much sense as the rest. ! is an operator of selected element in a selector, not a "parent selector". You can combine `!` with children selectors (`E! > F` will select any E with F children, it's equivalent to `xpath(E[F])` no use of the ancestor:: axis), they don't conflict. You don't actually go "back up" the selection chain, the matching engine simply changes which elements are "kept" during the selection process.
> Many of the other things, I don't see much point. They can be easily done with CSS as it is now.
For highly varying values of "easily". :matches requires a preprocessor or lots of repetition; :local-link is pretty much impossible without markup processing; time-dimensional elements emulation require a fair bit of markup and scripting; :indeterminate simply isn't available; and grid-structural pseudo-classes require markup support (and potentially scripting as well if the tables are dynamic)
I remember reading that the reason preventing this before was the performance on the css rendering engines, does anyone know if that was the case?
I really wish people would stop getting so hung up on version numbers and just call the languages what they are - HTML and CSS. These aren't video game consoles or apple products.
Disappointed. We don't need any parent, local link, n-th selector. Give us a lightweight scripting language where we can define these.
Isn't Javascript a lightweight scripting language? Plus I've seen some scripting done with CSS3, what exactly is missing?
I remember when the parent selector was taboo - this should be handled by javascript, yet here we are, because javascript serves a different purpose. It can be ok as well but not embedded in its current form. I'm not saying that IE got it right with its proprietary inline javascript properties or htc files, but we have css variables. How about we take it to the next step?
Would CSS4 (much prefer) consider stuff like luminance media queries [1], better contrast/color controls to the designer etc.?
[1] http://fremycompany.com/BG/2012/Ambient-light-sensors-and-CS...