Fix #260: Add a non-CSS UA conformance class #261
Conversation
|
FWIW WFM |
zcorpan
force-pushed
the
css-optional
branch
from
6c20a61
to
bd60d2f
Compare
| agents, except that they are exempt from the requirements in [[#api]].</p></dd> | ||
|
|
||
| <dt>User agents with no CSS support</dt> | ||
| <dd><p>User agents with no CSS support must comply to the same conformance criteria as user agents, |
There was a problem hiding this comment.
I might be losing context due to github's summary of the diffs here but it looks like we have two orthogonal dimensions for UA support: Scripting/non-scripting and CSS/non-CSS. So I'm expecting to see 4 types of UA for conformance not 3, and "must comply to the same conformance criteria as user agents" is now ambiguous.
There was a problem hiding this comment.
If you don't support scripting and you don't support CSS, then both conformance classes apply to you (actually I suppose all three apply). I don't want to have 4 classes for these permutations since if we add more things that are optional, it quickly explodes. I can tweak the text to make it clearer though. Would it help to just say "Such and such user agents are exempt from X", i.e. omitting the first part of the paragraph?
There was a problem hiding this comment.
I agree,m if we can phrase it as
if you claim VTT conformance, then this class applies
if you claim scripting conformance, then this class ALSO applies
if you claim CSS/styling conformance, then this class ALSO applies
and so on. To avoid the explosion of combinations.
On Nov 16, 2015, at 5:14 , Simon Pieters notifications@github.com wrote:
In index.bs:
All processing requirements in this specification apply. The user agent must also be conforming implementations of the IDL fragments in this specification, as described in the Web IDL specification. [[!WEBIDL]]
User agents with no scripting support -- All processing requirements in this specification apply, except those in [[#api]].
+ - User agents with no scripting support must comply to the same conformance criteria as user - agents, except that they are exempt from the requirements in [[#api]].
User agents with no CSS support -User agents with no CSS support must comply to the same conformance criteria as user agents,
If you don't support scripting and you don't support CSS, then both conformance classes apply to you (actually I suppose all three apply). I don't want to have 4 classes for these permutations since if we add more things that are optional, it quickly explodes. I can tweak the text to make it clearer though. Would it help to just say "Such and such user agents are exempt from X", i.e. omitting the first part of the paragraph?
—
Reply to this email directly or view it on GitHub.
David Singer
Manager, Software Standards, Apple Inc.
There was a problem hiding this comment.
Works for me. Just want clarity over exactly which conformance classes apply in any given scenario.
|
I can see why the new conformance class is added but I am worried that this gives the wrong signal. A User agent with no CSS support will be very restricted. Because important styling features (like color) can only be applied through CSS such an agent will not be suitable for a lot of caption services. Especially color and background color should actually be a core feature of WebVTT because they are used in a lot of countries for speaker identification. Until these are not WebVTT features there should be a note for this new conformance class that such a user agent may not meet the accessibility guidelines in some regions/countries. |
Understood. Yes, we should say that the reduced user experience might not meet the needs of the author, the user, or applicable regulations. One important use-case for VTT was in systems that are not full-on browsers and don’t have a full styling engine. We shouldn’t needlessly cut those off. (Or we leave CEA x08 as the only specs standing, and they are truly awful). David Singer |
|
I don't see any reason to worry about captioning services stopping supporting colors just because VTT has a conformance class for user agents that wish to not support CSS. |
|
I don't think we should explicitly specify a permissible VTT conformance class that is known to be non-accessible in the global context. It would be simpler to state that VTT presentation implementations (as opposed to validators) that do not support the specified styling semantics are non-conformant. That's different from saying that they must support those semantics by implementing CSS. In other words, the styling semantics can be defined by CSS even if the implementation doesn't claim to be CSS-based. |
|
If you want to support colors, you need to support CSS, even if just the subset that is used by WebVTT. I don't see what the problem is here. There might be user agents that really don't want to support colors. For example, a tool that converts VTT to another format is a user agent as far as the VTT spec is concerned. If the other format does not support colors, it makes little sense to say that it is non-conforming because it doesn't implement CSS. |
|
I think it makes complete sense to say that if converting to another format requires loss of styling required for accessibility then it is non-conformant. That's not to say that it is prohibited, just that in doing so the implementor needs to recognise that full conformance is not possible. Sorry if I've taken us down a semantic rabbit-hole re CSS support - clearly the syntax and color renditions of CSS need to be supported by any implementation that shows colors, for example. I just meant that a full CSS implementation is not a pre-requisite. |
|
On Tue, Nov 17, 2015 at 11:59 AM, dwsinger notifications@github.com wrote:
We should make sure to mention that the rendering of color, fonts and |
|
For example, if VLC support the rendering of color, positioning and fonts for WebVTT, then they won't be using a CSS engine, but do it natively. That would still be conformant to the spec. |
|
Thanks @silviapfeiffer that's what I was trying to say but much more simply put! |
|
Thanks for the fruitfull discussion. I agree with Silvia that the support of important accesibility features like color do not necessarily require a full flown up CSS engine. I also agree with Nigel that a VTT rendering user agent that does not support important accesiblitly features like color should be considered non-conformant. I have a different view from Simon regarding following statement.
I have a different experience. There are devices and browsers with significant market share that currently do support VTT but not CSS styling. This is actually a reason to not use some of the technology for live streaming with VTT captions and hence excludes a group from using this streaming service. In some other cases implementation (not necessarily VTT) that do not support colors are used nontheless for captions but this is also bad because this means a less accesible service. In general the discussion about the conformance is just the pointer to the problem that some important features that make VTT usable for access services are not tightly enough integrated in VTT. |
|
OK so what I hear is that we should remove the non-CSS conformance class again, but clarify that user agents don't need to have a full CSS implementation to be a conforming WebVTT user agent. |
|
This would be one option. This would of course be a very substantial change in respect to the original change proposal. My biggest concern is about color because the lack of support would be such an obvious issue for accesiblity. But I have also no better idea to separate it from the other CSS properties (e.g. ruby position which seems to me a very advanced feature). |
well, possibly, but … I hear what Andreas is saying. But I am also concerned that defining ‘how much’ CSS one has to support may be very hard — it may be that we start pulling one thread of spaghetti on the plate, and end up with all of it and the sauce in our lap. But maybe we can say that there is a conformance class without full CSS support, but that directly specified colors (i.e. not specified via a style, cascading/inheritance, etc.) must still be supported …. and probably one or two other things. Does this work? What are the other things? David Singer |
|
How are colors directly specified? On Wed, Nov 18, 2015 at 9:27 AM, dwsinger notifications@github.com wrote:
|
I was afraid you’d ask that. ‘well-known’ class names is the usual way (e.g. c.red), but formally that’s CSS.
David Singer |
|
You can't get away from cascade and inheritance even if using "just" class names. What if the element has children, does the color inherit? What if two declarations specify the color for a class name, which one wins? Since this turned out to be controversial, I have reverted the change and reopened #260. |
|
I agree with @dwsinger that it hard to subset the VTT CSS subset. But the proposal...
...would work for me. Regarding...
The support of the color property with the support of the hexadecimal notation and color keywords would be already a very good step forward. The other properties (like font-size) are all debatable but have not from my perspective the same importance...as long as the default values set by the VTT are supported for font-size and background color (font-size relative to the video viewport and a non-transparent background color). |
|
@dwsinger @lorettaguarino Regarding directly specified color values: I assumed this was related to the (upcoming?) support for "in VTT document styles"? |
|
No, since I believe the in-document styles are still CSS. David's proposal was to allow directly specified color values, and I didn't On Wed, Nov 18, 2015 at 9:53 AM, Andreas Tai notifications@github.com
|
|
Thanks, this is going to take thought. We’ve always had a vague “you can do VTT without doing CSS” but never really worked out what we meant by that. I think the earlier discussions on color meant using “well-known” class names “as if there were a style sheet that specified c.red etc.”, but I think it’ll take thought on how to make that formal. I suspect another possible direction is to define conformance and utility separately; there is a conformance class for no CSS at all, but to be usable, a user-agent needs to manage at least some coloring…
David Singer |
|
I think we should take a step back and think about what the requirements are. For example, if the requirement is only that different voices should have different colors, and not necessarily that the author has control over which colors, then we can say that user agents can assign different colors to different voices by default (CSS UAs could do this, too). But I suppose that is not sufficient? |
No, I do not think that this is sufficient. The author needs to have control over which color is rendered. First not all colors are equally accesible and second there may be a specific color schemes that are used not only for specific piece of content but over across a group of content. |
Isn't that an argument for letting the UA control the colors? The UA is in a better position to know which colors are accessible for the user than the author, no?
Can you elaborate? What is a group of content? |
|
Dredging in my memory, I seem to recall that we ended up before saying something like this: If the user-agent does not support CSS, it must nonetheless behave as if the following style-sheet were in effect: (and then declarations for the standard color classes, as used in e.g. x08, and so on). would that be a way out of the dilemma? David Singer |
|
That works for me. On Wed, Nov 18, 2015 at 12:36 PM, dwsinger notifications@github.com wrote:
|
|
FYI: the well-known colors are already specified in: https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#browsers |
|
maybe we could elevate the status of this document and say that UAs that don’t support CSS should nonetheless behave as if the style sheets at the end of that report were present, built-in? would that give enough coverage of basic features? If we go this way, I would strongly suggest making the stylesheet available under a stable URL, so VTT files could @import it explicitly.
David Singer |
Providers of access services should have control to apply the color for their services and they normally choose the right color scheme. They are in communication with their users and organisation that represent their users (e.g. organisations for the deaf and hard of hearing). They also do a lot of research and user tests to get the right styling (including color and background color). It will be hard for a UA manufacturer to get the same expertise especially for the target group of specific content which could be region based.
It could be for example the news on one channel where the news presenter get a color, the voice over and the original audio from another person. These colors are usually the same in one news program of one channel. |
|
@dwsinger @lorettaguarino @silviapfeiffer I can see the use of predefined "color keywords" that map to CSS properties with values is a workaround. But currently I am not really convinced that this is a solution. First you limit the choice of colors although the device would most possibly support a wider range of colors (I think this is true for a lot of devices that do currently only support VTT without CSS). Second this will be inconsistent if the same file is presented by a UA with CSS support and the author did overwrite a classname e.g. bg_white. I agree with @dwsinger that this needs probably a bit more thought. One solution could be to have a special tag for color like this was defined for bold and italics ( Extensions of SRT did/do support color and WebVTT did adopt the bold and italics tag from these extensions but not the solution for color (http://www.visualsubsync.org/help/srt). I will also try to get advice from other experts on this issue. |
#260