Home Specs Ideas Testing About
You are here: CSS Working Group Wiki » Frequently Asked Questions

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
faq [2018/02/01 19:44] – [Frequently Asked Questions] florianfaq [2020/07/29 20:05] – [Adding more named colors] florian
Line 1: Line 1:
 ====== Frequently Asked Questions ====== ====== Frequently Asked Questions ======
  
-===== Styling <sup> and <sub> using font-variant-position =====+===== Styling <sup> And <sub> Using font-variant-position =====
  
 === Question === === Question ===
Line 64: Line 64:
 </code> </code>
  
-== References ==+=== References ===
   * https://github.com/w3c/csswg-drafts/issues/1888   * https://github.com/w3c/csswg-drafts/issues/1888
   * https://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html   * https://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html
   * https://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html   * https://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
  
-===== Selectors that depend on layout =====+ 
 + 
 +===== Selectors that Depend on Layout =====
  
 === Question === === Question ===
Line 135: Line 137:
 then we can never add another selector that would depend on other properties ever. then we can never add another selector that would depend on other properties ever.
 Which one goes first? Which one goes first?
 +Something that we can only do once, ever,
 +and that will affect our ability to evolve CSS in the future,
 +is probably a bad idea for the language.
  
 Yet another way you could try to remediate all this Yet another way you could try to remediate all this
Line 145: Line 150:
  
 Instead of doing all of this, so far we've just short-circuited the entire debate and disallowed selectors from being affected by properties. Instead of doing all of this, so far we've just short-circuited the entire debate and disallowed selectors from being affected by properties.
 +
 +== Why Doesn't This Argument Apply To :hover? ==
 +
 +A common retort to the above is "we already have :hover, which has circularity issues, why can't we add this?".
 +
 +First, the fact that we've made one mistake isn't an argument for repeating the mistake. :hover *is* problematic in implementations, and we'd prefer not to add more things like it.
 +
 +Second, and more important, the circularity of :hover is very "wide" - when you apply :hover rules, you get all the way thru styling, then layout, then painting, and finally to hit-testing before you realize the element isn't hovered anymore and have to go re-style.  The user gets to at least see the full results of hovering before the engine has to figure things out again.  This is different from most other circular pseudo-classes, which circle around after just styling or layout, before the old results are even presented to the user.  This would effectively freeze the page, as the layout engine isn't even allowed to complete a single full run before it gets restarted.
 +
 +Furthermore, hit-testing is easy to for UAs to "tweak" to mostly get around the hover problems - UAs generally don't rerun hit-testing until the user moves their pointer, so as soon as they stop moving it, it settles on one rendering or the other.  Again, this isn't the case for other circular pseudo-classes.
  
 === References === === References ===
Line 150: Line 165:
   * https://github.com/w3c/csswg-drafts/issues/1656   * https://github.com/w3c/csswg-drafts/issues/1656
   * https://lists.w3.org/Archives/Public/www-style/2016Jan/0255.html / https://lists.w3.org/Archives/Public/www-style/2016Jan/0282.html   * https://lists.w3.org/Archives/Public/www-style/2016Jan/0255.html / https://lists.w3.org/Archives/Public/www-style/2016Jan/0282.html
 +
 +
 +
 +
 +===== Versioning CSS, Fixing Design Mistakes =====
 +
 +=== Question ===
 +
 +  * There are quite a few things in CSS that are [[https://wiki.csswg.org/ideas/mistakes | considered design mistakes]], and that would be done differently if they were being designed to today. Can't we just fix these?
 +  * CSS is terrible; we need to change FOO, BAR and BLAH, to work differently.
 +  * Can we introduce a ''@css 3;'' or ''@css 3 { }'' rule to instruct the browser to switch to a different processing model? The old one has lots of flaws.
 +
 +=== Answer ===
 +
 +CSS is a widely successful technology so it's probably not **that** bad,
 +but there have certainly been a number of decisions that in hindsight were wrong.
 +Unfortunately, we are mostly stuck with these.
 +
 +The point of a web browser is not to have a beautiful architecture,
 +it is to browse the web as it exists,
 +not as we would like it to be.
 +Whether authors correctly used well-designed features,
 +correctly used poorly-designed features,
 +used features in creative or weird ways,
 +or even accidentally depended on some bizarre behavior,
 +is mostly irrelevant.
 +Sites that work today need to continue to work.
 +
 +For all the web's quirks, the fact that new web pages can work in old browsers (with some
 +graceful degradation) and old web pages work in new browsers is a huge strength
 +of the web, even if it does have the downside that we have to live
 +with the mistakes of the past.
 +
 +Occasionally, it is possible to make breaking change, when the problem it solves is major,
 +and the breakage is very limited. But that's the exception, not the rule, and it is very hard to do,
 +because nobody is the boss of the web and can order everyone to update. Unless everybody
 +is convinced that breaking existing sites is a good idea, the change will not happen.
 +
 +== More details ==
 +
 +Occasionally, people accept that the current model cannot be changed,
 +but suggest that we could introduce a different model if we told the browser about it using
 +some versioning scheme, like a ''@css: 3;'' or ''@css 3 { }'' rule.
 +
 +Things along this line have been suggested and considered multiple times
 +over the years, but ultimately rejected, as that would not work.
 +
 +Any page without ''@css: 3;'' will be interpreted as css21. But initially,
 +so will any page that has ''@css: 3'', because browsers that don't know
 +about it (currently all of them) will just drop this line, an render the page
 +as usual, and so even browsers who would want to use special css3
 +semantics would have to render it using css21 rules, otherwise the 
 +pages would work differently in different browsers, which would be
 +terrible.
 +
 +We could instead have ''@css3 { /*put your stylesheet with new semantics here*/ }'', as that
 +would be ignored by old browsers, but even then every (new) browser
 +would have to support both the old way and the new way forever, which
 +is quite costly. For authors, it would be costly as well, as they would
 +have to write their stylesheet twice: once using ''@css3{}'' for new browsers
 +and once without it for old ones.
 +
 +Even though everybody recognizes that some decisions made in the past
 +are not ideal and that this causes some pain,
 +the pain is not nearly enough to justify making everybody do twice the work.
 +
 +=== References ===
 +  * https://lists.w3.org/Archives/Public/www-style/2018Jan/0061.html
 +  * https://lists.w3.org/Archives/Public/www-style/2018Jan/0062.html
 +
 +===== Error Handling in Selectors, aka Breaking Pages by Making Them Work =====
 +
 +=== Question ===
 +
 +When a selector has a syntax error in it, or when it has new syntax that old browsers don't know about, the entire selector is dropped. CSS would be more robust and maintainable if the browser only dropped to the next comma.
 +
 +Take this code:
 +
 +<code css>
 +#sensible .selector,
 +syntax = !error,
 +:new-feature {
 +  background: red;
 +}
 +</code>
 +
 +Because of how selectors are parsed, this is not applied at all.
 +Wouldn't it be nicer if it could apply to elements that match ''#sensible .selector'',
 +also apply in up to date browsers to elements that match '':new-feature'',
 +and just skip the syntax error?
 +
 +=== Answer ===
 +
 +Broadly speaking, this is impossible for the reasons explained in [[https://wiki.csswg.org/faq#versioning-css-fixing-design-mistakes | Versioning CSS, Fixing Design Mistakes]]:
 +changing how CSS works breaks existing content,
 +and that goes against everybody's interests.
 +
 +== more details ==
 +However, this particular case it interesting. If we did this change, all previously valid pages would continue to work, so what's the problem?
 +
 +It turns out that since mistyping a selector is an easy mistake to make,
 +lots of people have made it.
 +Moreover, when a page doesn't quite look the way the author expected,
 +a common strategy is to write more CSS rules until it does,
 +rather than trying to understand why the existing rules do not create the expected result.
 +
 +Then, when the page looks good, the author ships it,
 +including all mistaken cruft that doesn't do anything.
 +This dead code might even survive later redesigns.
 +
 +Effectively, even though it is not intentional,
 +many pages which have been fixed through additional css declarations
 +now depend on this sort of cruft not to work.
 +More often than not, “randomly“ changing the background,
 +the size, the borders, or the display value of some elements in the page will break it badly.
 +It doesn't matter that the source of the “randomness“ is the author's previous mistakes.
 +
 +And so, even though most people agree that error handling at commas in selectors would be nicer,
 +this is not something that can be changed.
 +
 +=== References ===
 + TBD
 +
 +===== Adding more named colors =====
 +
 +=== Question ===
 +
 +Can we add new named colors to CSS?
 +
 +
 +=== Answer ===
 +
 +No.
 +
 +== more details ==
 +
 +The built-in set of named colors in CSS is weird and bad, and we keep them mainly for legacy interop reasons. There's very little utility to adding to a set of colors where you have to look up the proper spelling and remember what actual colors the names map to.
 +
 +Naming colors can be done in stylesheets using custom properties. It is not likely we will ever add more names to the built-in set.
 +
 +=== References ===
 +
 +  * https://github.com/w3c/csswg-drafts/issues/3192#issuecomment-427132614
 +  * https://www.youtube.com/watch?v=HmStJQzclHc
 
faq.txt · Last modified: 2023/09/21 04:45 by SebastianZ
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki