This shows you the differences between two versions of the page.
Previous revision | |||
— | faq [2023/09/21 04:45] (current) – Added note about author's burden of name variants SebastianZ | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Frequently Asked Questions ====== | ||
+ | |||
+ | ===== Selectors that Depend on Layout ===== | ||
+ | |||
+ | === Question === | ||
+ | * I would like an : | ||
+ | * I would like a :stuck pseudo class to select elements with position: | ||
+ | * I would like a :on-screen pseudo class to select elements which are currently in the viewport | ||
+ | |||
+ | === Answer === | ||
+ | |||
+ | This falls into a class of problems that unlikely to be solvable in CSS: | ||
+ | selectors in general, and pseudo classes in particular, cannot depend on layout, | ||
+ | because otherwise they could be used to modify layout in a way that made them no longer match, | ||
+ | which would modify the layout back to where it was, | ||
+ | so they match again, | ||
+ | and we get stuck in an infinite loop of contradictions. | ||
+ | |||
+ | For a simple example: | ||
+ | |||
+ | <code css> | ||
+ | :stuck { position: static; } | ||
+ | </ | ||
+ | |||
+ | Now what? | ||
+ | |||
+ | Some of the changes web developers might want to apply with a :stuck pseudo class may be safe | ||
+ | and not trigger such loops, | ||
+ | but selectors are a generic mechanism, | ||
+ | and would enable this kind of contradictions. | ||
+ | |||
+ | So even though many of the problem people are trying to address using such pseudo classes are legitimate, | ||
+ | selectors are unlikely to be the answer. | ||
+ | |||
+ | == More details == | ||
+ | |||
+ | It may seem that we could simply disallow/ | ||
+ | but that doesn' | ||
+ | |||
+ | Say we did this, and explicitly disallowed setting position | ||
+ | — as well as other properties that can change the position of the element and therefore whether it gets stuck or not, such as display, margin, float, clear, flex… — | ||
+ | in a rule targeting a :stuck element. | ||
+ | This is already more restrictive than many potential users of :stuck would be happy with, | ||
+ | but this works for this case. | ||
+ | |||
+ | Next week, someone comes up with a similar circularity they want to allow (like [[https:// | ||
+ | |||
+ | Now someone writes | ||
+ | |||
+ | <code css> | ||
+ | .foo { toggle-states: | ||
+ | :checked { position: sticky; } | ||
+ | :stuck { toggle-states: | ||
+ | </ | ||
+ | |||
+ | When it's checked, it becomes sticky. (Assume the page is scrolled such that it becomes stuck immediately.) | ||
+ | |||
+ | If you add a third selector/ | ||
+ | |||
+ | The only way around this is to define that *none* of the properties that affect selectors can be used in rules using *any* of the selectors affected by properties. | ||
+ | |||
+ | Worse than being confusing, this is also breaking compatibility. | ||
+ | Setting position: | ||
+ | but adding that other new feature means it would no longer be, | ||
+ | so we cannot do that. | ||
+ | In effect, if we ever add a selector that can depend on properties, | ||
+ | then we can never add another selector that would depend on other properties ever. | ||
+ | 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 | ||
+ | would be to do a run-time detection | ||
+ | of whether there is a loop in that particular page | ||
+ | and disable all the selectors (or properties) involved in that loop. | ||
+ | However, this check would have a performance impact, | ||
+ | would still have the confusing and hard to debug " | ||
+ | on top of which it would require significant changes in browser architecture. | ||
+ | |||
+ | 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 === | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Versioning CSS, Fixing Design Mistakes ===== | ||
+ | |||
+ | === Question === | ||
+ | |||
+ | * There are quite a few things in CSS that are [[https:// | ||
+ | * CSS is terrible; we need to change FOO, BAR and BLAH, to work differently. | ||
+ | * Can we introduce a '' | ||
+ | |||
+ | === 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, | ||
+ | |||
+ | 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, | ||
+ | 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, | ||
+ | but suggest that we could introduce a different model if we told the browser about it using | ||
+ | some versioning scheme, like a '' | ||
+ | |||
+ | 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 '' | ||
+ | so will any page that has '' | ||
+ | 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 '' | ||
+ | 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 '' | ||
+ | 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:// | ||
+ | * 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:// | ||
+ | |||
+ | |||
+ | ===== Adding British variants for names ===== | ||
+ | |||
+ | === Question === | ||
+ | |||
+ | Can we add British English variants for names in CSS? | ||
+ | |||
+ | === Answer === | ||
+ | |||
+ | While there are color names using British English spelling like `grey` in addition to the American English versions, those are considered to be legacy. Actually, the [[https:// | ||
+ | Everything new introduced into CSS //only// uses American English spelling. So there' | ||
+ | |||
+ | == more details == | ||
+ | |||
+ | While, from an author' | ||
+ | For authors introducing aliases may cause some confusion and cognitive load, as they may expect a different spelling or even a completely different word. They require precedence and de-duplicating rules in case both are specified in implementations. Also, every new feature would require specification work regarding the alias. And also there would need to be [[https:// | ||
+ | |||
+ | === References === | ||
+ | |||
+ | * https:// | ||
+ | * 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:// | ||
+ | |||
+ | ===== Styling <sup> And <sub> Using font-variant-position ===== | ||
+ | |||
+ | === Question === | ||
+ | HTML currently specifies the following default styles for sup and sub: | ||
+ | |||
+ | <code css> | ||
+ | sub { vertical-align: | ||
+ | sup { vertical-align: | ||
+ | sub, sup { line-height: | ||
+ | </ | ||
+ | |||
+ | This works, but this is not very good typography. The following uses fonts the way they' | ||
+ | |||
+ | <code css> | ||
+ | sub { font-variant-position: | ||
+ | sup { font-variant-position: | ||
+ | </ | ||
+ | |||
+ | === Answer === | ||
+ | It is indeed better typography, | ||
+ | and even if the font does not have the dedicated glyphs, | ||
+ | the browser is required to synthesize them, | ||
+ | so this is look encouraging. | ||
+ | However, we cannot switch the default rendering to that. | ||
+ | It has issues in terms of compatibility, | ||
+ | and more importantly, | ||
+ | due the possibility of nested sub/sup. | ||
+ | While these are not overly common it does exist, | ||
+ | and this style change would induce a rendering with an apparently different meaning. | ||
+ | |||
+ | Consider the following: | ||
+ | <code html> | ||
+ | 2< | ||
+ | </ | ||
+ | |||
+ | Even if the typography isn't great, | ||
+ | This correctly looks like 2^2^2 = 16 with the legacy styling, | ||
+ | but would look like 2^22=16 with the proposed change, | ||
+ | which is wrong. | ||
+ | |||
+ | == More details == | ||
+ | |||
+ | There were various attempts to define font-variant-position differently to make it handle such situations, | ||
+ | but they were rejected for being either too complex, not solving the problem correctly, or both. | ||
+ | |||
+ | The following code comes reasonably close to giving good typography in the base case, | ||
+ | and handling some cases of nesting as well, | ||
+ | so web page authors may want to use it if it works for their content, | ||
+ | but was not judged sufficiently robust in the general case to be accepted as a new default styling, | ||
+ | in part because fonts with inaccurate metrics (which are unfortunately reasonably common) may break it, | ||
+ | and in part because it does not handle images and other non textual content in the sub/ | ||
+ | |||
+ | <code css> | ||
+ | sub { font-variant-position: | ||
+ | sup { font-variant-position: | ||
+ | |||
+ | : | ||
+ | /* Not using :matches() on the parent in the following 2 rules is intentional, | ||
+ | it would shift too much. */ | ||
+ | sub sub { vertical-align: | ||
+ | sup sup { vertical-align: | ||
+ | </ | ||
+ | |||
+ | === References === | ||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | |||
+ | |||