I disagree. Fonts normally contain metrics for proper positioning of the superscript and subscript baselines and relative heights. They "may" provide additional features to overide the glyphs or relative positioning if this is needded for the coherence with the preencoded superscripts/superscripts that are mapped in the font, or to adjust the visual weights of strokesand adjust some angles, or for correct hinting on low resolution displays.
These specific features do not need to be enabled explicitly in CSS, they should be enabled by default. Problems only occur with defective fonts that have incomplete data, and for which browsers (in fact their internal text renderers) are attempting to define some reasonnable defaults. This may for some time produce some incoherent styles but this is temporary. Slowly but surely, these defects are being corrected. As Unicode encodes things for the long term, there's no need to define temporary workaround by encoding new variants. The existing superscript/subscripts have then been encoded for other prupose: preserve separate semantics of letter modifiers in plain text or in IPA as **distinct** symbols. Any other use is still possible by people hacing these characters as if it was a general way for writing superscript/subscript, but these are just hacks that break the identity of the represented text. They have also been encoded for roundtrip compatibiluty with older standards where it is impossible to determine what is the intended semantics, but also because these old characters were used in low resolution displays or monospaced displays (where more exact font metrics needed for maths formulas could not be respected at all). Even in TeX or math formulas in general, all symbols used in superscript/subscript are preserving their own identity: this is just a question of layout where the applied style adds (but does not replaces or removes) more semantics. In summary, we should use the normal characters including in Tex/Maths. Then the layout engine will do its best with the fonts they have, will honor their suggested metrics (if they are defined), will attempt to alias some missing character mappings in fonts, or will synthetize these styles using the best metrics available in font or computed with reasonnable defaults for the scripts. And for all this you do not need more than a "sub" or "sup" element in HTML, and in TeX/MathML you just use its standard "^" or "_" layout operators. Only at this time, if authors are seeing that the current implementations are still not what they expected, they will attempt to hack a bit the presentaiton by adding some specific styles (but only as a temporary workaround, which will no longer be needed in the long term and that could cause incoherences later with updated fonts or updated text engines that would produce better and more coherent results). 2016-10-01 14:00 GMT+02:00 Jukka K. Korpela <jkorp...@cs.tut.fi>: > 1.10.2016, 11:29, Khaled Hosny wrote: > > On Fri, Sep 30, 2016 at 07:31:58PM +0300, Jukka K. Korpela wrote: >> > [...] > >> What I was pointing at was that when using > >> rich text or markup, it is complicated or impossible to have >>> typographically >>> correct glyphs used (even when they exist), whereas the use of Unicode >>> codepoints for subscript or superscript characters may do that in a much >>> simpler way. >>> >> >> That is not generally true. >> > > It is generally true, but not without exceptions. > > In TeX you get true superscript glyphs by default. >> > > I suppose you’re right, though I don’t know exactly how TeX implements > superscripts. I suspect the fonts that TeX normally uses do not contain > (many) superscript or subscript glyph variants, but TeX might actually map > e.g. ^2 in math mode to a superscript glyph for 2 (identical with to the > glyph for ²). > > On the web you can use font features in CSS to get them as >> well, provided that you are using a font that supports them. >> > > This is a good example of my general statement. If you use the simple way > in CSS, you use vertical-align set to sub or super together with a > font-size setting. This is simple and “works”, but it does not use > subscript or superscript glyphs but algorithmically operates on normal > glyphs (and produces different results in different browsers etc.). The > newer way, setting font features, is a) much less widely known, 2) much > less supported in browsers, 3) requires extra settings to deal with > browser-specific names of the relevant properties. > > Yucca > > > >