Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
faq [2018/02/06 23:22]
florian [Selectors that Depend on Layout]
faq [2018/10/04 12:09]
astearns
Line 150: 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 278: Line 288:
  TBD  TBD
  
 +===== Adding more named colors =====
 +
 +=== Question ===
 +
 +The named colors in CSS are fairly arbitrary and incomplete. Could we add a better system of named colors? Or could we add these specific named colors?
 +
 +
 +=== 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
 
faq.txt · Last modified: 2018/10/04 16:21 by tabatkins
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki