Reference CSS color semantic

[nigelmegitt]

Part of umbrella #406

Current semantic based on: XSL 1.1 §7.18.1 https://www.w3.org/TR/2006/REC-xsl11-20061205/#color Current CSS snapshot version of this semantic: CSS 2.1 §14.1 https://www.w3.org/TR/CSS2/colors.html#colors

The XSL spec references the CSS spec to define the semantic.

Action to take: replace XSL spec reference with CSS spec reference.

[skynavga]

This is a frivolous and unnecessary change. I will not make it.

[nigelmegitt]

I noticed while doing this that the named color orange in CSS is not supported in TTML. @skynavga any idea why not? Seems like a bizarre and arbitrary omission.

[mikedo]

And brown, and probably others...

[nigelmegitt]

No, the list is at https://www.w3.org/TR/CSS2/syndata.html#value-def-color and brown isn't in it. I guess there may be a larger set of named colors in some other spec, but if we're on CSS 2.1 there are 17 of them.

[mikedo]

The TTML2 reference for the source of the chosen named colors is SVG 1.1, section 4.2 which has an extended named color set:

SVG supports all of the syntax alternatives for defined in CSS2 syntax and basic data types ([CSS2], section 4.3.6), with the exception that SVG allows an expanded list of recognized color keywords names.

which is defined here: http://www.w3.org/TR/2011/REC-SVG11-20110816/types.html#ColorKeywords Maybe the intent of TTML1 years ago was to constraint it to CSS2, but that's clearly not what the draft says today. If you want to reject brown, I don't really care, except that is just as arbitrary without also changing the named color citation to be only the CSS2 named colors.

[skynavga]

When we designed DFXP we decided to limit named colors to the list in CSS2 1998 which were the HTML4.0 colors, namely

The list of keyword color names is: aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, and yellow. These 16 colors are defined in HTML 4.0 ([HTML40]).

to which we added transparent, magenta, and cyan, the first from SVG, and the last two as aliases for fuschia and aqua.

At this point, I think we should not add any more named colors.

[nigelmegitt]

@mikedo I didn't realise that the Note under <named-color> was a reference to the source; I read it as a useful hint. The derivation for tts:color is listed as XSL.

I don't have a strong view on adding new named colors, but it does seem generally like a good idea to match the CSS named color set where possible, if only to avoid author confusion - for example, author sees that named colors can be used, looks up the normal set of web named colors, finds that "orange" is ideal for their purposes, but then it doesn't work. There doesn't seem to be a good argument for persisting this "not working" when the cost of adding a new named color seems low.

[css-meeting-bot]

The Working Group just discussed Reference CSS color semantic #413, and agreed to the following resolutions:

• SUMMARY: We will not add "orange" now but ask CSS WG to align named colors with SVG and then look at this again.

The full IRC log of that discussion

<nigel> Topic: Reference CSS color semantic #413
<nigel> github: https://github.com/w3c/ttml2/issues/413
<nigel> Nigel: It looks like Glenn doesn't want to add anything, but I don't know why we don't
<nigel> .. just align with the CSS set while also keeping the additions already defined in TTML1.
<nigel> Cyril: Eventually we should have the same list as in CSS, so we may need to ask CSS to add some new names.
<nigel> Mike: I don't see any harm, and would be happy to get to alignment.
<nigel> .. Taking out named colors would have no benefit. It's trivial enough to translate the
<nigel> .. handful of named colors into the sRGB hex representation.
<nigel> Mike: §4.2 of the SVG 1.1 spec has a big table of named colors.
<nigel> Nigel: I think it doesn't include transparent.
<nigel> Mike: It would be a disservice to remove named colors in TTML2.
<nigel> Nigel: +1
<nigel> Mike: It would make TTML1 documents non-conformant that would be a bad idea.
<nigel> Cyril: SVG supports CSS2 plus an expanded list of names. I think it should not be too difficult
<nigel> .. to have the CSS WG adopt the SVG color keywords. I might be wrong!
<nigel> .. On top of these we're just defining transparent, because there's no alpha channel defined
<nigel> .. in the SVG keywords.
<nigel> Mike: We have to be careful about defining transparent because it is the initial value of the
<nigel> .. tts:backgroundCOlor.
<nigel> Nigel: I think we have consensus to get align with the CSS color set while not removing any existing colors.
<nigel> Mike: I'm okay with that, if the goal is to better align with CSS.
<nigel> Pierre: I'm not against it but I see no advantage in adding "orange'.
<nigel> .. Recall that as long as there is a delta between CSS and TTML a lookup table is still needed.
<nigel> .. I would rather not touch it.
<nigel> Nigel: I think it's about direction of travel.
<nigel> Pierre: Adding "orange" now would cost implementors time for no benefit, because we still
<nigel> .. wouldn't be aligned with CSS, so that's no benefit now.
<nigel> Nigel: I can see that, maybe we should go to CSS WG and ask them to align named colors
<nigel> .. with SVG, and then defer any change to TTML until that decision has been made.
<nigel> Cyril: I like that.
<nigel> Pierre: +1
<nigel> SUMMARY: We will not add "orange" now but ask CSS WG to align named colors with SVG and then look at this again.

[nigelmegitt]

Regarding orange, another unexpected data point: https://www.w3.org/TR/css3-color/#valuea-def-color omits orange! However in §4.3 the extended color keywords include cyan and magenta, so in fact the alignment we wanted with SVG already exists, and implementations can simply copy across any valid named color from TTML into CSS and it should work. This is easier for implementers working in CSS.

[skynavga]

Fixed in 924d6cd47f0e36daa5b13fef95c6aa9ac6b88d72.