- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 22 Nov 2011 08:34:03 -0800
- To: Christoph Päper <christoph.paeper@crissov.de>
- Cc: W3C Style <www-style@w3.org>
On Tue, Nov 22, 2011 at 3:35 AM, Christoph Päper <christoph.paeper@crissov.de> wrote: > Peter Moulder: >> On Mon, Nov 21, 2011 at 06:59:25PM +0100, Christoph Päper wrote: >> >>> foo {list-style-type: hexadecimal;) >>> foo::marker {text-transform: uppercase;} >> >> That works OK for list markers, but not so well for use of counters in >> 'content' values, where the counter is sometimes mixed with text that shouldn't >> be uppercased. > > Okay, I forgot about very valid usecases like > > h1 { > counter-increment: chapter; > counter-reset: table; > } > table { > counter-increment: table; > } > caption::before { > content: "Table " counter(chapter, upper-roman) > "–" counter(table, decimal) ": "; > } > > So let me rephrase the question: Should ‘text-transform’ work on counters (and markers or generated content in general)? I just tried the attached test document in Safari and it doesn’t work. ::marker is not yet supported by any browser, so all of the tests involving that wouldn't work. Of the remaining, in Chrome the manual ::before-based ones respect text-transform. The ones that use normal markers and put text-transform on the list or list-item don't, but I suspect that's because we manually reference a shortlist of properties when generating the markers manually, and text-transform isn't on that list. When they become "real" pseudo-elements as ::marker, they should receive all the properties through inheritance like normal. Firefox and Opera are the same, but IE honors text-transform in all the cases it can (just not when it's specified on ::marker, again because that's not yet recognized). > I guess it’s way too late to change the ‘counter()’ pseudo function grammar to > > ‘counter(’ identifier > [ ‘,’ <list-style-type> > [ ‘,’ <text-transform> ]? > ]?‘)’ > > and I’m pretty sure I don’t want to suggest a ‘transform()’ function for generated content, because before we know it we would have proposals for ‘color()’, ‘style()’ or ‘font()’. Exactly. We already have properties for this stuff. That's somewhat limited when using them as part of a larger string, but shrug. The use-case seems pretty minor. ~TJ
Received on Tuesday, 22 November 2011 16:35:01 UTC