This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
faq [2018/02/02 23:53] – florian | faq [2023/09/21 04:45] (current) – Added note about author's burden of name variants SebastianZ | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Frequently Asked Questions ====== | ====== Frequently Asked Questions ====== | ||
- | ===== Styling <sup> and <sub> using font-variant-position ===== | + | ===== Selectors that Depend |
- | + | ||
- | === 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:// | + | |
- | + | ||
- | ===== Selectors that depend | + | |
=== Question === | === Question === | ||
Line 135: | Line 67: | ||
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 80: | ||
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 150: | Line 95: | ||
* https:// | * 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:// | ||
+ | |||
+ | |||
+ |