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

On Thu, Nov 24, 2011 at 4:24 AM, Peter Moulder <> wrote:
> On Thu, Nov 24, 2011 at 12:07:19PM +0100, √ėyvind Stenhaug wrote:
>> On Thu, 24 Nov 2011 01:38:06 +0100, Peter Moulder
>> <> wrote:
>> >On Wed, Nov 23, 2011 at 09:44:19AM -0800, Tab Atkins Jr. wrote:
>> >
>> >>So, I propose adding "::marker { text-transform: initial; }" to the
>> >>Lists 3 UA stylesheet.  Thoughts?
>> >
>> >That approach won't have any effect on 'content' use.  A use case where
>> >this might matter is for page headings, when one might grab a section
>> >heading and its number for an <h2> element and uppercase it for purposes
>> >of the page heading (while the h2 use displays it in mixed case).
>> You mean e.g. for
>> h2:before {
>>     content: counter(subsection, lower-alpha);
>>     [...]
>> ?
>> None of the browsers I tested currently suppress text-transform in
>> that case. Authors can of course accomplish this by adding the
>> appropriate declaration themselves.
> The case I was trying to convey is where the 'content' value has a mix of
> text that should be transformed and a counter value that shouldn't be
> transformed.
> In this case, authors can't accomplish this by adding the appropriate
> declaration, because there's no way to apply different text-transform
> values to different components of the 'content' value.

I believe this is a rare corner-case, and can be hacked around as it
arises.  For now, that might mean adding an empty <span> to the page.
In the future, it might mean multiple ::before elements or some other
solution for adding more structure than a single pseudo-element can

> The question, then, is how often one wants counter values to be
> transformed with the rest of the content value, and how often one wants
> counter values remain untransformed when applying text-transform to the
> rest of the content value.
> If there are no significant situations where one wants counters to remain
> untransformed when the (non-empty) rest of 'content' is transformed, then
> nothing needs to be done.
> If there are significant cases where one wants counter values to be
> unaffected by text-transform while other parts of 'content' are affected,
> and there are no significant cases where one wants both to be
> transformed, then the relatively simple approach I suggested in the
> message should be considered.

I don't believe there are significant cases for this.  Given the
context, where you have control over both the text (via the 'content'
property) and the transform, for there to be a significant case would
require a situation where you want to text-transform *some* pseudos
composed of counters and non-counters, but not all of them.  One could
hack around the situation without much difficulty by simply specifying
a different 'content' for some of them.

> Otherwise, I think another proposal someone made recently was for
> counter() and counters() functions to allow specifying a
> <'text-transform'>.  A more costly but more powerful approach would be
> to provide a text-transform() function for 'content'.
> In trying to think of an example where one might want to apply
> text-transform to 'content', I suggested the case where part of
> the used text for 'content' comes from the source document, such as
> with css3-gcpm's named string facility.  Named strings are used for
> page headings, and it's fairly common to want to apply
> text-transform:uppercase to a page heading.  Whether it's common
> to want to leave counter values in that page heading untransformed,
> I don't know.
> (If it's not common, then great, there's nothing to do: I'm not making a
> feature request, I'm just checking whether the mixed-content case is a
> problem we want to address, and giving one possible resolution depending
> on what the needs are.)

I haven't thought about named strings much, but off the top of my head
I suspect it to be very unlikely that you wouldn't want text-transform
to apply if it was applying to a page-heading or the like.  In similar
print examples, you want the text to be consistent with the heading


Received on Thursday, 24 November 2011 15:04:46 UTC