This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
faq [2018/02/03 00:24] – [Selectors that depend on layout] florian | faq [2021/02/26 10:23] – [Real Physical Lengths] tabatkins | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Frequently Asked Questions ====== | ====== Frequently Asked Questions ====== | ||
- | ===== Styling < | + | ===== Styling < |
=== Question === | === Question === | ||
Line 71: | Line 71: | ||
- | ===== Selectors that depend | + | ===== Selectors that Depend |
=== Question === | === Question === | ||
Line 137: | 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 147: | 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' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Second, and more important, the circularity of :hover is very " | ||
+ | |||
+ | Furthermore, | ||
=== References === | === References === | ||
Line 173: | Line 186: | ||
it is to browse the web as it exists, | it is to browse the web as it exists, | ||
not as we would like it to be. | not as we would like it to be. | ||
- | Whether authors correctly used well designed features, | + | Whether authors correctly used well-designed features, |
- | correctly used poorly designed features, | + | correctly used poorly-designed features, |
used features in creative or weird ways, | used features in creative or weird ways, | ||
or even accidentally depended on some bizarre behavior, | or even accidentally depended on some bizarre behavior, | ||
Line 221: | Line 234: | ||
* https:// | * https:// | ||
* https:// | * https:// | ||
+ | |||
+ | ===== 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, | ||
+ | : | ||
+ | background: red; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Because of how selectors are parsed, this is not applied at all. | ||
+ | Wouldn' | ||
+ | also apply in up to date browsers to elements that match '': | ||
+ | and just skip the syntax error? | ||
+ | |||
+ | === Answer === | ||
+ | |||
+ | Broadly speaking, this is impossible for the reasons explained in [[https:// | ||
+ | changing how CSS works breaks existing content, | ||
+ | and that goes against everybody' | ||
+ | |||
+ | == 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' | ||
+ | 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' | ||
+ | This dead code might even survive later redesigns. | ||
+ | |||
+ | Effectively, | ||
+ | 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' | ||
+ | |||
+ | 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' | ||
+ | |||
+ | 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:// | ||
+ | * https:// | ||
+ | |||
+ | |||
+ | ===== Real Physical Lengths ===== | ||
+ | |||
+ | === Question === | ||
+ | |||
+ | A ' | ||
+ | |||
+ | === Answer === | ||
+ | |||
+ | Currently, no. | ||
+ | |||
+ | This has been tried in the past, in several variants. Originally, all the "real world" units were meant to be accurate physical measurements. | ||
+ | |||
+ | Later, Mozilla attempted to address this again, by adding a separate " | ||
+ | |||
+ | The overall conclusion is that trying to present accurate real-world units is a failure; browsers can't do it reliably, and authors often misuse them anyway, giving users a bad experience. | ||
+ | |||
+ | === Workarounds === | ||
+ | |||
+ | There' | ||
+ | |||
+ | - Have a calibration page, where you ask the user to measure the distance between two lines that are some CSS distance apart (say, 10cm), and input the value they get. | ||
+ | - Use this to find the scaling factor necessary for that screen (CSS length divided by user-provided length), and store it locally (via localStorage, | ||
+ | - On the pages where you need the accurate length, fetch it from local storage, and set a '' | ||
+ | - Anywhere you use a length that needs to be accurate, instead of '' | ||
+ | |||
+ | This is a robust and minimal scheme that is guaranteed to give correct results on a given device, and "fails open" - if the user hasn't calibrated yet, or has cleared their local storage, etc, the '' | ||
+ | |||
+ | (Note: a common follow-up request is to bake this unit-scale-factor into a CSS property that auto-scales all lengths for you. You don't actually want this - calibrating a ruler shouldn' | ||
+ | |||
+ | === References === | ||
+ | |||
+ | * https:// |