- From: Xidorn Quan <quanxunzhen@gmail.com>
- Date: Sat, 24 May 2014 11:23:02 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: James Craig <jcraig@apple.com>, www-style list <www-style@w3.org>
- Message-ID: <CAMdq69-5=QCT-E=3Dw_GvCEGYxA4Vv+qtKsDwgGBMTk6BWaVfw@mail.gmail.com>
On Sat, May 24, 2014 at 4:29 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > On Thu, May 22, 2014 at 2:09 AM, James Craig <jcraig@apple.com> wrote: > > On May 22, 2014, at 12:44 AM, Tab Atkins Jr. <jackalmage@gmail.com> > wrote: > > > >> On Wed, May 21, 2014 at 1:22 AM, James Craig <jcraig@apple.com> wrote: > >>>> On May 19, 2014, at 11:18 PM, "Tab Atkins Jr." <jackalmage@gmail.com> > wrote: > >>>> If you want to provide "alt text" for the 'symbols' values, > >>>> instead make a separate counter style with the words you want in > >>>> 'symbols' and "speak-as: words", then set "speak-as: > >>>> your-spoken-style;" in the real counter style. Xidorn provided > >>>> several examples of this. > >>> > >>> This strikes me as somewhat convoluted, but mostly sufficient. > >>> > >>> One question I didn’t see answered (apologies if I missed it) was > whether one could apply the lang selector to a counter style. For example, > I want (>/<) symbols displayed in all locales, but I want the alt text > (input/output) localized. > >>> > >>> If I’m reading Tab’s summary correctly, we’d have to have duplicate > symbolic counter styles in order to use the localized speak-as value. > >>> > >>> @counter-style symbols-de { speak-as: alt-de; } > >>> @counter-style symbols-en { speak-as: alt-en; } > >>> @counter-style symbols-es { speak-as: alt-es; } > >>> > >>> Is that the intention? > >> > >> Yes. > > > > No one will use this technique. It would mean at least three blocks per > language per list type, purely for the purposes of localizing alt text. In > reality, most major products localize in dozens of languages, if not more. > The following example demonstrates the minimum required CSS to localize in > only three (3) languages: English, Spanish, and German. Let's use the i/o > example again. > > > > Markup: > > > > <ul class="io"> > > <li>2+2</li> > > <li>4</li> > > </ul> > > > > To recap, we want the console input/output list to visually display as: > > > > ⋗ 2+2 > > ⋖ 4 > > > > And be spoken as: > > > > Input: 2+2 > > Output: 4 > > > > In order to localize the previous lists using the techniques outlined in > this thread, this is the minimum amount of CSS required. > [snip CSS] > > This CSS is pretty wrong. Here's how you'd do it with correct syntax: > > /* Shared system for all the non-speak-as details of the counter style */ > @counter-style io { system: cyclic; symbols: '⋗' '⋖'; suffix: " "; } > > /* Localized systems */ > @counter-style io-en { system: extends io; speak-as: io-en-spoken; } > @counter-style io-es { system: extends io; speak-as: io-es-spoken; } > @counter-style io-de { system: extends io; speak-as: io-de-spoken; } > > /* Spoken systems */ > @counter-style io-en-spoken { system: cyclic; symbols: "Input: ", > "Output: "; speak-as: words; } > @counter-style io-es-spoken { system: cyclic; symbols: "Entrada: ", > "Salida: "; speak-as: words; } > @counter-style io-de-spoken { system: cyclic; symbols: "Eingang: ", > "Ausgang: "; speak-as: words; } > > /* Selectors to actually assign the counter styles */ > ul.io:lang(en) { counter-style: io-en; } > ul.io:lang(es) { counter-style: io-es; } > ul.io:lang(de) { counter-style: io-de; } > > (In particular, note that you can't use comma-separation for > @counter-style preludes, and @counter-styles of the same name replace > each other; the descriptors don't individually cascade.) > > > If you're really saying the above is the minimum necessary, I'd > respectfully ask the CSS WG to try harder to come up with a better solution. > > > > Here's a variant of my original 'alt' proposal again, adding the :lang() > selector applied to the counter styles. This example is one-third the size > of the previous, and only requires one additional line of CSS per > localization. It's also easier to read, more likely to be implemented by > browsers, and *much* more likely to be understood and used by web authors. > > > > ul.io { counter-style: io; } > > > > @counter-style io { > > system: cyclic; > > symbols: '⋗' '⋖'; > > speak-as: alt; /* speak-as could be implicit if alt is defined. */ > > alt: 'Input: ' 'Output: '; > > } > > @counter-style io:lang(es) { alt: 'Entrada: ' 'Salida: '; } > > @counter-style io:lang(de) { alt: 'Eingang: ' 'Ausgang: '; } > > As Xidorn says, mixing in a lang-selector like that is kinda awkward. > > If we were going to address this directly, my thought would be to add > a class of 'alt-*' descriptors that must match up index-for-index with > the 'symbols' or 'additive-symbols' descriptor. Then you could do: > > @counter-style io { > system: cyclic; > symbols: '⋗' '⋖'; > speak-as: words; > alt-en: "Input: ", "Output"; > alt-es: "Entrada: ", "Salida: "; > alt-de: "Eingang: ", "Ausgang: "; > } > > When speaking a counter-style, if an appropriate alt-* descriptor > exists whose language descriptor matches the element's language (using > the standard :lang() matching rules), it uses those symbols for > reading rather than the ones specified in 'symbols'. That's pretty > simple to deal with. > If we truly want to add "alt", I don't think we need to make it a class of descriptors. Simply using "alt" with "extends" system like what we currently do is sufficient. It has simplified the case to: @counter-style io-en { system: extends io; alt: "Input: " "Output: " } @counter-style io-es { system: extends io; alt: "Entrada: " "Salida: "; } @counter-style io-de { system: extends io; alt: "Eingang: " "Ausgang: "; } As Reece said, authors may also want to have different prefix/suffix/negative for different languages. I don't see any difference from usecase between the proposed "alt" and those descriptors. The only problem of this form is that, we cannot drop an "alt" descriptor which has different number of symbols during parsing stage. However, we can make it a shorten form of a spoken style with the same system, so that we don't need to define one in addition. In this way, the only left problem would be "additive" system. Thoughts? - Xidorn
Received on Saturday, 24 May 2014 01:24:09 UTC