This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
faq [2018/02/03 01:38] – [Versioning CSS, Fixing Design Mistakes] Add some hyphens fantasai | faq [2023/09/21 04:23] – Added "Adding British variants for names" SebastianZ | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Frequently Asked Questions ====== | ====== Frequently Asked Questions ====== | ||
- | |||
- | ===== 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:// | ||
- | |||
- | |||
===== Selectors that Depend on Layout ===== | ===== Selectors that Depend on Layout ===== | ||
Line 137: | 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 147: | 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 274: | Line 217: | ||
=== References === | === References === | ||
TBD | 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' | ||
+ | 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:// | ||
+ | |||
+ | |||