Open nigelmegitt opened 5 years ago
We should not consider a backward compatible breaking change unless there is a extremely good reason to do so; otherwise, we won't be able to make the claims that we currently do in §3.4.2.
Notwithstanding the above proscription (which I think has been a consistent design principle for this WG), what are the industry needs that argue for such a change? We have had no report (to my knowledge) of complaint about the current prescribed behavior since it was added as a clarification in TTML 2e in September 2013. What has changed now?
If the only reason for suggesting this change is that CSS does things a bit differently, then that is no cause for action as far as I'm concerned.
Good questions @skynavga . @palemieux as an implementor of a CSS based TTML renderer, how did you handle font family name matching?
Switch to case-insensitive font family name matching for consistency with CSS https://www.w3.org/TR/css-fonts-3/#font-family-casing.
This arises from w3c/ttml2#1042.
Also to match CSS, can we introduce the concept of quoted family names being different to unquoted ones, especially for generic family names, so that
tts:fontFamily="'default'"
would match afont
whosefamily
attribute isdefault
instead of the generic default family?Both of these would be compatibility breaking with TTML1 and TTML2 specifications; I'm not sure about the impact on implementations.