Re: [css3-lists] Should some properties not inherit into markers?

On Thu, Nov 24, 2011 at 2:04 AM, Christoph Päper
<christoph.paeper@crissov.de> wrote:
> Tab Atkins Jr.:
>
>> text-transform and font-variant.
>>
>> I think it's reasonable to block text-transform.  It converts between glyphs,
>
> ‘font-variant’ changes glyphs, too. Some values of ‘text-transform’ change characters (but keep letters intact).
>
> A, a, ɑ: three glyphs*, two characters†, one letter
>       * only two in OS X’s Monaco font, though
>       † at least in the roman script, not counting IPA; and don’t get me started on graphemes
> Ａ, ａ:   another (East-Asian) letter – graphematically equivalent, typographically different

font-variant changes glyphs, but only to stylistic variants.  There's
rarely a semantic difference.  On the other hand, in bicameral
scripts, the case of a marker is often important.

I agree that the fullwidth variants are generally a stylistic variant
only, but I believe that's a minor casualty.  One can always just set
"::marker{ text-transform:inherit; }" to return it to the default
inheritance behavior.


> I agree with John Daggett that the ‘glyphs’ descriptor is badly named. It probably also can (and then should) be merged with the ‘additive-glyphs’ descriptor.
>
> The letter case can indeed be used to distinguish ordinal hierarchy levels, but it can be irrelevant, too (e.g. in hexadecimal digits). Therefore I propose what I prematurely dismissed in an earlier mail:
>
> 1. Predefined counter values with any of the prefixes ‘upper-’, ‘lower-’
>   or ‘fullwidth-’ are not affected by the ‘text-transform’ property.
> 2. There is a predefined counter value without any of these prefixes.
>   It usually is a near-alias of the ‘lower-’ variant. The only
>   difference is that it is affected by the ‘text-transform’ property.
> 3. The ‘@counter-style’ at-rule either gets another descriptor to
>   facilitate the case protection described above or in the ‘type’
>   descriptor the ‘alphabetic’ value becomes case-bound and a new
>   ‘letter’ value reacts to ‘text-transform’.
> 4. [optional:] The prefixed values are deprecated.
>   Instead the ‘counter()’ pseudo function gets an optional third
>   parameter which accepts any valid ‘text-transform’ value.
>
> This way everything can inherit to ‘::marker’, but implementors have to somehow protect some counters from ‘text-transform’.

#1 seems too magical to me.  I don't think we should have special
behavior based on prefixes.  I don't believe there's a significant
problem to address that needs #2, #3, or #4.

~TJ

Received on Thursday, 24 November 2011 15:12:43 UTC