Add a paragraph about the reasons why limiting styles. #410
Conversation
|
@dwsinger need a review |
index.bs
Outdated
| <p>Only a limited set of CSS styles is allowed in WebVTT because user agents that do not support CSS | ||
| will need to implement CSS functionality equivalents. Browsers therefore also have to be limited in | ||
| what CSS styles they support for WebVTT so as to enable identical rendering in browsers and | ||
| non-browsers.</p> |
There was a problem hiding this comment.
I am not clear that this is a genuine requirement, that rendering is identical in browsers and non-browsers. If I recall correctly WebVTT has no requirements document. Pointer to a WG resolution that this is important?
There was a problem hiding this comment.
Actually this sentence is subtly wrong; user agents that don't support CSS (a conformance class as Andreas notes), well, do not support CSS. UAs that DO support CSS can use a full CSS engine but can also implement this restricted subset of CSS.
There was a problem hiding this comment.
OK, I'll reformulate.
|
review again :-) |
index.bs
Outdated
| what CSS styles they support for WebVTT so as to enable identical rendering in browsers and | ||
| non-browsers.</p> | ||
| will need to implement CSS functionality equivalents. User agents that support a full CSS engine | ||
| must limited the CSS styles they interpret for WebVTT so as to enable identical rendering without |
There was a problem hiding this comment.
It's not clear what the "identical rendering" is referring to here - identical to what?
There was a problem hiding this comment.
Identical to what is rendered when you follow the spec and have CSS functionality.
|
I think this is still wrong. User agents that don't support CSS don't support CSS, that's why we had to do the colour work. This is about UAs that DO support CSS but DON'T have a full engine; they are only required to support this subset of CSS. Please stay silent on what happens if you have a full engine; I think requiring those implementations to be sure to limit themselves to that subset is adding unneeded pain. |
|
@dwsinger No, this paragraph is not about UAs that support CSS partially. I don't think such a class exists. It's about the difference between UAs that support CSS and those that don't support CSS (like VLC). It says that those that support CSS (like Web browsers) must not allow the full capability of their CSS support in WebVTT and this is something I am not going to budge on. It is extremely important that we disallow full engines to allow all their functionality in WebVTT, because if we do, then everyone has to implement the full CSS engine for WebVTT. Remember the times when Internet Explorer was the dominant Web browser and they implemented functionality that was not in the HTML&CSS standards? What did that do to the other browsers? This paragraph is about avoiding that situation, so we get compatible implementations. |
|
OK, there are two problems here, and we should disentangle them. (a) your text talks about non-CSS UAs that only implement a subset. Those are NOT non-CSS UAs, non-CSS UAs don't implement any CSS. (b) then there is the question of what CSS you are allowed to use and the UA is required to support, and whether the UA has to ignore anything else. I'm OK with a parse-time discard on (b). So, the text needs to talk about CSS-supporting UAs only supporting the CSS we document. |
|
@dwsinger re (a) Read that sentence properly please. It says: "Only a limited set of CSS styles is allowed in WebVTT because user agents that do not support CSS this is referring to: It does not say that these UAs implement a subpart of CSS. It says they have to implement functionality equivalents of the limited CSS subset defined in WebVTT. ad (c) The second sentence says exactly what you are suggesting. Could you please provide proposed wording changes that make it clearer for you? I really don't know how else to say it more clearly. |
|
OK, sounds to me like we need to define our conformance classes better: one that has no CSS support, one that supports the CSS parts that WebVTT uses (see #391) and UAs with a full CSS engine. |
|
Is also relate to #389 |
|
possibly, but I think you argued that the reduced CSS and full CSS engines had to give the same result, so probably only two |
|
Not quite. "WebVTT CSS" supporting UAs behave differently, since they don't follow the rendering section to the word. So, it needs an out from some of the spec. I think we need three levels. 1/ No CSS: non-CSS UAs that ignore all CSS 2/ WebVTT CSS: non-CSS UAs that implement functional equivalents to the WebVTT CSS features and therefore are allowed to not follow the text of the specification in the rendering section 3/ Full CSS: CSS-supporting UAs (mostly browsers) that implement the WebVTT CSS functionality as specified |
Be very specific that this class has to only support the limited set of CSS styles specified in WebVTT explicitly.
|
Since #389 landed, I have now updated this PR. I decided to move the paragraph out of an example section into a normative space and it made sense to explicitly define the "Full CSS engine" conformance class for this. Please re-review. |
index.bs
Outdated
| <dd><p>All processing requirements in this specification apply. However, only a limited set of CSS | ||
| styles is allowed because <a>user agents that do not support a full HTML CSS engine</a> will need | ||
| to implement CSS functionality equivalents. User agents that support a full CSS engine must | ||
| therefore limited the CSS styles they interpret for WebVTT so as to enable identical rendering |
There was a problem hiding this comment.
typo: s/limited/limit
Is "interpret" the right term here, addressing your concerns @dwsinger ? Seems to me that "apply" would be better.
There was a problem hiding this comment.
yes, s/limited/limit/ and "limit the CSS they apply" might be better
Damned, I thought to interpret was an English word! ;-)
|
Please re-review |
|
I'm (still) OK |
closes #373