Differences

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

--- faq [2018/02/06 23:22] – [Selectors that Depend on Layout] 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 ======
-===== 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: sub; }
-sup { vertical-align: super; }
-sub, sup { line-height: normal; font-size: smaller; }
-</code>
-This works, but this is not very good typography. The following uses fonts the way they're meant to be, wouldn't it be much better?
-<code css>
-sub { font-variant-position: sub; }
-sup { font-variant-position: sup; }
-</code>
-=== 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, it does not handle all cases,
-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>
-<sup>2<sup>2</sup></sup> = 16
-</code>
-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/superscripts.
-<code css>
-sub { font-variant-position: sub; }
-sup { font-variant-position: super; }
-:matches(sub, sup) :matches(sub, sup) {  font-size: smaller; }
-/* Not using :matches() on the parent in the following 2 rules is intentional,
-   it would shift too much. */
-sub sub { vertical-align: sub; }
-sup sup { vertical-align: super; }
-</code>
-=== References ===
-  * https://github.com/w3c/csswg-drafts/issues/1888
-  * https://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html
-  * https://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html
 ===== Selectors that Depend on Layout =====
@@ Line 150: / 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.
+== 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 ===
@@ Line 277: / Line 217: @@
 === 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'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
+  * https://www.youtube.com/watch?v=HmStJQzclHc
+===== 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://wiki.csswg.org/faq#adding-more-named-colors|whole built-in set of named colors is considered to be legacy]]. See [[https://www.youtube.com/watch?v=HmStJQzclHc|Alex Sexton's talk about the history of these colors]].
+Everything new introduced into CSS //only// uses American English spelling. So there's only one variant of names for properties, keywords, functions, etc. like in other programming languages.
+== more details ==
+While, from an author's perspective it may seem to be just another name for something, introducing aliases for feature names comes with a cost.
+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://wpt.fyi/results/css|Web Platform Tests]] covering those variations. And all that for very little author benefit.
+=== References ===
+  * https://github.com/w3c/csswg-drafts/issues/3298#issuecomment-437089314
+  * https://github.com/w3c/csswg-drafts/issues/3192#issuecomment-427132614
+  * https://www.youtube.com/watch?v=HmStJQzclHc
+===== Real Physical Lengths =====
+=== Question ===
+A '1in' length usually isn't actually 1 inch. Can we get physical units that are the correct size, so we can create rulers/etc on webpages that actually work?
+=== 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.  However, in practice most people authored content for 96dpi screens (the de facto standard at the time of early CSS, at least on PCs) which gave a ratio of 1in = 96px, and when browsers changed that ratio because they were displaying on different types of screens, webpages that implicitly assumed the ratio was static had their layouts broken. This led us to fixing a precise 1in:96px ratio in the specs, and the rest of the physical units maintained their correct ratios with inches.
+Later, Mozilla attempted to address this again, by adding a separate "mozmm" unit that represented real physical millimeters. This ran into the second problem with real physical units - it relies on the browser accurately knowing the actual size and resolution of your display. Some devices don't give that information; others lie and give info that's only approximately correct. Some displays literally *cannot* give this sort of information, such as displaying on a projector where the scale depends on the projection distance. Authors also used mozmm for things that didn't actually want or need to be in accurate physical units, so when mozmm and mm diverged, they were sized badly.
+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's a reasonable workaround strategy, however. If you are writing a webpage that does need accurate real-world units, such as a webapp that wants to help people measure things, you need to do per-device calibration:
+  - 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, or a cookie, etc).
+  - On the pages where you need the accurate length, fetch it from local storage, and set a ''--unit-scale: 1.07;'' (subbing in the real value) property on the html element.
+  - Anywhere you use a length that needs to be accurate, instead of ''width: 5cm;'', write ''width: calc(5cm * var(--unit-scale, 1))'';.
+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 ''var()'' will fall back to 1 and you'll just get the standard browser units.
+(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't rescale your UI as well.)
+=== References ===
+* https://github.com/w3c/csswg-drafts/issues/614
+===== 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: sub; }
+sup { vertical-align: super; }
+sub, sup { line-height: normal; font-size: smaller; }
+</code>
+This works, but this is not very good typography. The following uses fonts the way they're meant to be, wouldn't it be much better?
+<code css>
+sub { font-variant-position: sub; }
+sup { font-variant-position: sup; }
+</code>
+=== 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, it does not handle all cases,
+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>
+<sup>2<sup>2</sup></sup> = 16
+</code>
+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/superscripts.
+<code css>
+sub { font-variant-position: sub; }
+sup { font-variant-position: super; }
+:matches(sub, sup) :matches(sub, sup) {  font-size: smaller; }
+/* Not using :matches() on the parent in the following 2 rules is intentional,
+   it would shift too much. */
+sub sub { vertical-align: sub; }
+sup sup { vertical-align: super; }
+</code>
+=== References ===
+  * https://github.com/w3c/csswg-drafts/issues/1888
+  * https://lists.w3.org/Archives/Public/www-style/2011Jun/0329.html
+  * https://lists.w3.org/Archives/Public/www-style/2011Apr/0391.html