Differences

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

--- faq [2021/02/26 09:55] – Add "real physical units" tabatkins
+++ 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 307: / Line 237: @@
 === 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
@@ Line 331: / Line 284: @@
 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.
+  - 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).
+  - 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.
+  - 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))'';.
+  - 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.
@@ Line 343: / Line 296: @@
 * 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