search

w3c / ttml1

Timed Text Markup Language 1 (TTML1)
http://w3c.github.io/ttml1/
Other
13 stars 12 forks source link

Chained Referential Styling spec vs example mismatch #275

Closed cconcolato closed 6 years ago

cconcolato commented 6 years ago

While reading TTML1 I came on the following sentence in "8.4.1.3 Chained Referential Styling": "If the same style property is specified in more than one referenced style set, then the last referenced style set applies, where the order of application starts from the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets."

It talks about the "last" style applying. I wondered what "last" meant, according to which order. The next sentence says the order starts from the element to referenced style sets. This seems to me contradicting the example below in the spec.

I checked the rendering of IMSC.js and TTPE and both render the following code with: "Yellow Monospace" (in yellow) and "White Monospace" (in white).

<tt xml:lang="" xmlns="http://www.w3.org/ns/ttml">
<head>
<styling xmlns:tts="http://www.w3.org/ns/ttml#styling">
<style xml:id="s1" tts:color="white" tts:fontFamily="monospaceSerif"/>
<style xml:id="s2" style="s1" tts:color="yellow"/>
</styling>
</head>
<body>
<div>
<p style="s1">White Monospace</p>
<p style="s2">Yellow Monospace</p>
</div>
</body>
</tt>

This seems contradictory also to the algorithm specified in "8.4.4.2 Specified Style Set Processing", which says (removing unnecessary parts):

1. [initialization] initialize the specified style set SSS of E to the empty set;
2. [referential and chained referential styling] for each style element SREF referenced by a style attribute specified on E, and in the order specified in the style attribute, then, if SREF is a descendant of a styling element, merge the specified style set of SREF, SSS(SREF), into the specified style set of E, SSS(E);
4. [inline styling] for each style property P expressed as a specified styling attribute of E, merge P into the specified style set of E, SSS(E);

I interpret this as follows:

1. SSS(<p style="s2">) = empty
2. get the SSS(s2), i.e:
  1. SSS(s2) = empty
  2. get SSS(s1), i.e.:
     1. SSS(s1) = empty
     4. SSS(s1) = color:white
     merge SSS(s1) into SSS(s2): SSS(s2) = color:white
  4. merge inline property: SSS(s2) = color:yellow
  merge SSS(s2) into SSS(<p style="s2">):  SSS(<p style="s2">) = color:yellow

Conclusion: I think the example is correct. The sentence in 8.4.1.3 is wrong. Given that it is duplicating the algorithm of 8.4.4.2, I would suggest removing the sentence in 8.1.4.3. There is no need to duplicate text.

cconcolato commented 6 years ago

Note that I would also recommend removing the second paragraphs of 8.4.1.1, 8.4.1.2 and 8.4.1.4 as they duplicate in words the algorithms given in 8.4.4.4

nigelmegitt commented 6 years ago

@cconcolato Concerning removing things in 8.4.1 in favour of 8.4.4, did you spot that the the top of 8.4.1 Style Association says:

Style association is a sub-process of 8.4.4 Style Resolution Processing ...

Either that is true, and 8.4.4.x needs to refer to 8.4.1.x, in which case removing sentences would have an impact, or it is false and 8.4.1.x is only informative. It does not look as though there are any explicit references from 8.4.4 to 8.4.1 so I think that 8.4.1 is informative only. (disclaimer: I might have missed them, but I did look twice!)

Having said that, I don't see the problem. All the statements seem to agree with each other to me. 8.4.1.3 is only talking about referenced style sets, and merging the tts:color="yellow" from s2 in your example is an inline style, so gets merged later and therefore takes priority.

palemieux commented 6 years ago

so I think that 8.4.1 is informative only.

I have assumed as much. Same for 8.4.2.

nigelmegitt commented 6 years ago

By the way, this is a separate issue entirely but I think the order of precedence of chained referential styling is non-intuitive and the wrong way round. Rather than the last style property in the chain of references winning, it should be the first, in my opinion. That would fit with the principle of "the closer the stronger" (my words) implied by both inline style properties taking precedence over referenced ones, and the way that inherited styles work.

Although that's how I feel about it, I feel even more strongly that it is important that the order is well defined, and it would be a really significant and breaking change to alter it now, so I believe we're stuck with it, and I don't intend to raise an issue about it, unless there's a general opinion in the WG that the current order is wrong and needs to be changed.

Plus, there may be use cases or implementation issues I haven't considered.

cconcolato commented 6 years ago

@nigelmegitt About "Style association": there is a difference between specifying how the association is made (inline, referential, chained, nested) and how the different types of association interact. 8.4.1 (and 8.4.2 and others) indicates the former (typically the first paragraphs of each section) but also the latter (the second paragraphs) and that is redundant with the algorithm in 8.4.4.

Regarding the nature (informative/normative) of 8.4.1 (and 8.4.2, and others), I agree that given that 8.4.4 is precise and does not refer to 8.4.1, probably 8.4.1 is only informative. The problem is that the text in 8.4.1 seems normative:

Style properties associated by inline styling are afforded a higher priority than all other forms of style association.

and sometimes wrong:

If the same style property is specified in more than one referenced style set, then the last referenced style set applies, where the order of application starts from the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets.

I agree it should be first and not last (that's what TTPE and IMSC implement, that's what 8.4.4 specifies) but instead of changing the word, I propose to remove those sentences entirely.

nigelmegitt commented 6 years ago

Removing the sentences wouldn't make any difference though - the normative algorithm in 8.4.4 appears to require that the last is chosen. Have you tried TTPE and IMSC with an example that doesn't use inline styles at the same time as chained referential styles? Something like this ought to demonstrate the point:

<tt xml:lang="" xmlns="http://www.w3.org/ns/ttml">
<head>
<styling xmlns:tts="http://www.w3.org/ns/ttml#styling">
<style xml:id="s0" tts:fontFamily="monospaceSerif"/>
<style xml:id="s1" style="s0" tts:color="white"/>
<style xml:id="s2" style="s0" tts:color="yellow"/>
<style xml:id="s3" style="s2 s1"/>
<style xml:id="s4" style="s1 s2"/>
</styling>
</head>
<body>
<div>
<p style="s3">White Monospace</p>
<p style="s4">Yellow Monospace</p>
</div>
</body>
</tt>
cconcolato commented 6 years ago

I think we are talking about two different things:

Indeed, it is the last one that prevails and this is consistent with the algorithm in 8.4.4.4

Now regarding your example:

I still think we would better without the sentences duplicating the algorithm behavior.

skynavga commented 6 years ago

A couple of points:

I agree we can improve the non-algorithmic, descriptive prose so that it is more consistent with the algorithmic form; and we can also note that the relevant prose is descriptive and not intended to code the formal semantics.

cconcolato commented 6 years ago

Isn't it simpler and less error-prone to remove the redundant descriptive prose?

skynavga commented 6 years ago

@cconcolato I prefer improving the prose (as required) and marking the sub-section as non-normative;

nigelmegitt commented 6 years ago

@cconcolato As I understand it Chained Referential styling is just referential styling applied to style elements, i.e. there can be a chain of references from one style element to the next. Since you raised this issue about 8.4.1.3 specifically I think we need a test case that covers it without bringing in inline styles as well, which in this case are processed after the chained referential styling.

I think your point is that to test the order of application in chained referential styling we need two styles in the chain that both specify a value for the same property, and where those values differ from each other. I see what you mean. In my example if we added tts:color="red" to the style s0 would that suffice? The text should never look red in any of the cases.

@skynavga I understood it in the same way as you describe in your "couple of points".

cconcolato commented 6 years ago

@nigelmegitt the example in the spec already tests that: s2 specifies yellow and links to s2 which specifies white. Yellow is meant (by the algorithm) to win.

nigelmegitt commented 6 years ago

@cconcolato I think there's a subtle difference. That example in the spec shows a referential style being merged with an inline style (inline on the style element), and then the result being referenced by a p element, so it does include chained referential styling (p -> s2 -> s1) but the section you're worried about specifies something not demonstrated by the example, i.e. the order dependency when resolving chained referential styles.

It needs a more complex example to demonstrate that, hence my earlier attempt.

cconcolato commented 6 years ago

As I said, there are 2 parts:

I think it means "more than one in the chain", not "more than one in the same @style". The part covering more than one reference in the same @style is in 8.4.1.2.

palemieux commented 6 years ago

Since Section 8.4.1 already states that style association is a sub-process of 8.4.4 Style Resolution Processing, I believe it is safe to remove the sentence If the same style property is specified in more than one referenced style set, then the last referenced style set applies, where the order of application starts from the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets.

nigelmegitt commented 6 years ago

it is safe to remove the sentence

@palemieux @cconcolato I still don't think there's anything wrong with the sentence, and none of the discussion so far has demonstrated to me that there is anything wrong with it.

If anything is wrong it is the example itself, which subtly mixes inline styling in s2 with referential styling from s1, and so suggests that inline styling somehow forms part of referential styling, whereas in fact we are all agreed that it applies later, and overrides referential styling.

palemieux commented 6 years ago

@nigelmegitt Given the following, do you agree that the algorithm of Section 8.4.4 yields tts:color="blue" on the p?

<style xml:id="s1" tts:color="black"/>
<style xml:id="s2" style="s1" tts:color="blue"/>
<style xml:id="s3" style="s2"/>
<p style="s3">

If so, to what set do you think the sentence if the same style property is specified in more than one referenced style set refers to?

I think set refers to {s1, s2, s3}, do you agree?

[ed.: multiple editorial edits]

nigelmegitt commented 6 years ago

@palemieux Yes, it does yield blue, but this is a confusing example from the perspective of chained referential styling and the ordering constraint, in exactly the same way as the current example is. This is because when you resolve the styles for s2 you first resolve the referential (and chained referential) styles, so you get black, then you merge the inline styles, which overrides the black so you get blue. Adding the additional referential step from s3 to s2 doesn't make any difference here.

I think set refers to {s1, s2, s3}, do you agree?

Yes, perhaps better written as {s3, s2, s1} depending how you are planning to treat the ordering.

However this discussion all raises the point that although the algorithm is fully specified, in practice it isn't possible to construct an example with single style references where the chained referential styling rules carry any meaningful impact, because of inline styles overriding referential styles.

I think the rules do come into play meaningfully when multiple style references are made. Hence the example at https://github.com/w3c/ttml1/issues/275#issuecomment-348605189 which demonstrates that point.

palemieux commented 6 years ago

@nigelmegitt It sounds like, in your opinion, in more than one referenced style set refers to {s2, s1} in the case of style s3 in https://github.com/w3c/ttml1/issues/275#issuecomment-348605189 . Do you agree?

nigelmegitt commented 6 years ago

@palemieux Almost - actually it is {s2, s0, s1, s0} since both s2 and s1 reference s0.

cconcolato commented 6 years ago

@nigelmegitt As highlighted by this thread, I do think the sentence is at the very least misleading if not wrong with regards to the word "last". I can be interpreted as:

I do think the spec would be better without that sentence.

palemieux commented 6 years ago

@nigelmegitt Thanks for providing an interpretation, which is evidently different than mine :) The challenge I see here is that the referential rules are hierarchical (and interact with specified styling rules), but the sentence uses vague terms like more than one referenced style set and last. Instead of expanding the sentence and/or introducing a more complex example, I believe it is simpler to simply remove the potentially ambiguous sentence, without which Section 8.4.1.3 still effectively conveys the possibility that styles can reference styles. Let me know if your disagreement reaches the level of objection. If so, please provide specific text and example that would resolve the ambiguities.

nigelmegitt commented 6 years ago

@cconcolato Surely "last in the chain that starts with the element itself" and "last in the merging operation" are the same? Is the confusion that (inline) styles specified on the element itself are applied afterwards and don't count? I don't understand how you could conclude that styles specified on an element somehow are part of the referenced styles.

@palemieux I don't think there's anything vague about "more than one referenced style set", and the ordering for "last" is defined. I also haven't seen any examples where your and my different understanding has resulted in a different outcome, which again makes me think there's no problem.

Sorry both, I'm still not getting what the problem is. Plus, I actively think the sentence you wish to remove is helpful and useful. Please do not delete it.

palemieux commented 6 years ago

@nigelmegitt Looking back at https://github.com/w3c/ttml1/issues/275#issuecomment-352398582 , I agree with you that the set is {s3, s2, s1}. A reader would then conclude that, because the last referenced style set applies, the color would be "black". This is where the confusion is.

cconcolato commented 6 years ago

@nigelmegitt

Surely "last in the chain that starts with the element itself" and "last in the merging operation" are the same?

Precisely not. They are exact opposite. I don't understand why you bring the styles on the element in the discussion. I think this thread is too long and we should add it to the F2F agenda. It will probably be solved in 5min once we are in the same room.

nigelmegitt commented 6 years ago

@palemieux in that case the reader would have processed SSS(s2) incorrectly by failing to bring in the locally defined (inline) blue colour style after processing the referential styles.

palemieux commented 6 years ago

in that case the reader would have processed SSS(s2) incorrectly by failing to bring in the locally defined (inline) blue colour style after processing the referential styles.

@nigelmegitt I think most readers will interpret last incorrectly and will use the last style element in the list.

[ed.: corrected typo]

nigelmegitt commented 6 years ago

I think most readers will interpret last incorrectly and will use the last set element in the list.

@palemieux why bring set elements into this?

palemieux commented 6 years ago

@nigelmegitt oops. I meant style. Corrected.

nigelmegitt commented 6 years ago

I think most readers will interpret last incorrectly and will use the last style element in the list.

@palemieux yes I can see that such confusion could arise. Two alternatives:

  1. Add a note to the section on chained referential styling pointing out that properties defined inline on any style in the chain effectively override the chain from that point on.
  2. OR refactor the whole descriptive informative section categorising style resolution to reflect the algorithm accurately, targeting document authors and implementers as the key audience. Possibly move to an appendix also.

Easiest thing is to do 1 now and if anyone has the editorial effort available to do 2, consider that later.

nigelmegitt commented 6 years ago

I'll try to come up with a modified wording for the sentence in question here to make clear that when evaluating referenced styles, if they themselves reference other styles, then they must be fully evaluated before the normal referential styling rules apply. This is a recursive algorithm, and takes into account that inline style attributes on referenced styles override referential style attributes.

nigelmegitt commented 6 years ago

Okay, here's a first bash - feel free to improve it:

Current text:

If the same style property is specified in more than one referenced style set, then the last referenced style set applies, where the order of application starts from the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets.

Proposed text:

Referenced styles are evaluated recursively: each referenced style set S is evaluated in turn (referential styling), including any styles referenced in turn by S and then any inline style attributes specified directly by S; finally any inline style attributes are applied. Inline style attributes have higher priority than referenced styles when evaluating each style.

cconcolato commented 6 years ago

It removes the ambiguous "last" which is a good thing, but there are several parts that I don't like:

What about:

If the same style property is specified in more than one referenced style set, the algorithm given in 8.4.4.2 determines which value is used. Intuitively, the style property that is specified 'closer' to the affected element is used, as shown in the example below.

nigelmegitt commented 6 years ago

@cconcolato I think the point of this section is to be informative especially to document authors about how specified styles will be understood, not just to refer to the algorithm, so I'd rather not replace the sentence with an unhelpful "go and read something else". I may well not have done the best job there from the document author's perspective.

I agree implementers should read the algorithm.

If the same style property is specified in more than one referenced style set, the algorithm given in 8.4.4.2 determines which value is used. Intuitively, the style property that is specified 'closer' to the affected element is used, as shown in the example below.

"intuitive" is subjective, so I'd remove it. Also I think the rule of thumb that the closer style property is used gives the wrong impression. In the style tree:

s1
  -> s2 (sets tts:color="red")
s3
  -> s4
       -> s5 (sets tts:color="blue")

most readers would consider that s2 is "closer" to an element with style="s1 s3" since it is 2 steps away but the blue color actually applies despite being 3 steps away, because it is specified later.

the previous text was focused on a given "style property", the new text looses that and is too complex.

Here's a rewrite:

The specified value of each style property is given by evaluating the referenced styles recursively: each referenced style set S is evaluated in turn (referential styling), including any styles referenced in turn by S. When evaluating each style, if the property is defined by an inline style attribute, that takes priority over any referenced styles; otherwise the value from the last referenced style applies, in the order specified in the style attribute. This algorithm is specified in 8.4.4.2 Specified Style Set Processing.

cconcolato commented 6 years ago

replace the sentence with an unhelpful "go and read something else"

My proposed text was not simply adding "go and read something else". The "go and read something else" was added for implementers because it might not be easy to find. The rest of the text is meant for "document authors".

"intuitive" is subjective, so I'd remove it

May not be the best word, but I wanted to indicate that the behavior described after is not very precise (if one wants exact behavior, they should go to the algorithm). You could replace it with "As a first approximation" or "Without detailing the algorithm" or "A simplified version" ...

I think the rule of thumb that the closer style property is used gives the wrong impression

Your example mixes "chained referential styling" with 'simple' "referential styling" with multiple references. The latter part is already covered in previous section 8.4.1.2. The 'closer' rule works for chained referenced styling.

The specified value of each style property is given by evaluating the referenced styles recursively: each referenced style set S is evaluated in turn (referential styling), including any styles referenced in turn by S. When evaluating each style, if the property is defined by an inline style attribute, that takes priority over any referenced styles; otherwise the value from the last referenced style applies, in the order specified in the style attribute. This algorithm is specified in 8.4.4.2 Specified Style Set Processing.

It's better. We could still work on the wording. Again, this is paraphrasing the algorithm. This is not necessary. Also it covers more than "chained referenced styling" as it talks about inline styling, multiple references in referenced styling. Remember we already have these two sentences:

8.4.1.1: Style properties associated by inline styling are afforded a higher priority than all other forms of style association.

8.4.1.2: If a style attribute specifies multiple references, then those references are evaluated in the specified order, and that order applies to resolution of the value of a style property in the case that it is specified along multiple reference paths.

8.4.1.4: Style properties associated by nested styling are afforded a lower priority than inline styling but with higher priority than referential styling.

The options for me are (in decreasing preference order):

nigelmegitt commented 6 years ago

replace 'last' by 'first' in 8.4.1.3

I still maintain that would be incorrect. I think that we need to go through that at the f2f if it's still unresolved.

move all these sentences in a single place somewhere in 8.4.4

I wouldn't be against that.

The specified value of each style property is given by evaluating the referenced styles recursively: each referenced style set S is evaluated in turn (referential styling), including any styles referenced in turn by S. When evaluating each style, if the property is defined by an inline style attribute, that takes priority over any referenced styles; otherwise the value from the last referenced style applies, in the order specified in the style attribute. This algorithm is specified in 8.4.4.2 Specified Style Set Processing. It's better. We could still work on the wording.

Agreed - I see I forgot to remove an "in turn", so it should have been:

The specified value of each style property is given by evaluating the referenced styles recursively: each referenced style set S is evaluated in turn (referential styling), including any styles referenced by S. When evaluating each style, if the property is defined by an inline style attribute, that takes priority over any referenced styles; otherwise the value from the last referenced style applies, in the order specified in the style attribute. This algorithm is specified in 8.4.4.2 Specified Style Set Processing.

Also it covers more than "chained referenced styling" as it talks about inline styling

I thought this was the problem you wanted to resolve, that the existing sentence omits recognition that inline styling takes precedence. Otherwise there would be nothing wrong with the existing wording at all.

palemieux commented 6 years ago

@cconcolato @nigelmegitt Could we simply say that chained referential styling is resolved by processing the tree of references through post-order traversal?

andreastai commented 6 years ago

I support the request from @cconcolato to remove the following sentence from 8.4.1.3:

If the same style property is specified in more than one referenced style set, then the last referenced style set applies, where the order of application starts from the affected element and proceeds to referenced style sets, and, in turn, to subsequent referenced style sets.

I read the specification text multiple times before reading through this thread. As assumed by @cconcolato (comment)and @palemieux (comment) my conclusion was that the last style in the chain applies (which is the wrong conclusion). As @cconcolato says the sentence is not only misleading but it also mixes concerns. The handling of multiple refs in an style attribute is defined in 8.4.1.2.

I also support the following suggestion by @cconcolato for the exact reason he provided:

Note that I would also recommend removing the second paragraphs of 8.4.1.1, 8.4.1.2 and 8.4.1.4 as they duplicate in words the algorithms given in 8.4.4.4

If there is no consensus on the latter this has lower priority for me because it at least not misleading.

I have strong concerns to re-word the text. The reason is given by this thead itself: it will take a lot of time and this time could be invested better to resolve other issues so we meet publication timelines.

If it helps a short informative note could go under the example in 8.4.1.3 saying that "White Monospace" will render as "white" and "Yellow Monospace" will render as "Yellow".

nigelmegitt commented 6 years ago

Could we simply say that chained referential styling is resolved by processing the tree of references through post-order traversal?

@palemieux Yes except I don't think it's a tree in this sense. More simply, each referenced style's specified style set is resolved prior to being merged into the referring style. In other words, chained referential styling is no different from referential styling except that referenced styles can themselves reference other styles.

css-meeting-bot commented 6 years ago

The Working Group just discussed Chained Referential Styling spec vs example mismatch ttml1#275, and agreed to the following resolutions:

The full IRC log of that discussion <nigel> Topic: Chained Referential Styling spec vs example mismatch ttml1#275
<nigel> github: https://github.com/w3c/ttml1/issues/275
<nigel> Glenn: I relented a bit and agreed to remove that second paragraph that causes confusion.
<nigel> .. I decided that trying to reword it would be too complicated. I proposed some text under
<nigel> .. the example to explain the result.
<atai2> q+
<cyril> q+
<nigel> Nigel: I could accept that but would like a statement to explain that when chained referential
<nigel> .. styling is used then each style is resolved in itself before being referenced.
<nigel> Glenn: The algorithm is already specified in 8.4.4.2 and I think writing that weak paraphrase would be too difficult.
<nigel> ack atai2
<nigel> Andreas: I agree and also refer to Cyril's comment that trying to rewrite this will take too
<nigel> .. long and is not needed.
<nigel> ack cyril
<nigel> cyril: I agree with Glenn and Andreas. I am fine with removing the misleading paragraph
<nigel> .. and adding a note. I would like to note that we have similar sentences to the second
<nigel> .. paragraph in 8.4.1.1 and 8.4.1.2 and 8.4.1.4. The second paragraph is always rephrasing
<nigel> .. the algorithm. It would be strange to remove it here and not there.
<atai2> q+
<nigel> Glenn: There's no issue on those though, so we shouldn't do that.
<nigel> ack atai2
<nigel> Andreas: Can we agree with Glenn's proposal and open another issue?
<nigel> Nigel: There's already work to be done on this pull request so I would like to ask for a day
<nigel> .. to propose a useful sentence that I think is not contentious.
<nigel> Pierre: I'm kindly asking the Chair to allow us to move forward leaving the door open to
<nigel> .. add further clarification in additional issues.
<nigel> Nigel: By the way I already made a proposal and nobody commented on it. Perhaps we can use that.
<nigel> group: [universal dislike of the proposal from 15 days ago]
<nigel> Pierre: I've just pushed a change to make Glenn's change.
<nigel> Nigel: Just to be clear, I think that this change alone is fine but insufficient to resolve the
<nigel> .. issue to my satisfaction.
<nigel> RESOLUTION: Merge pull request as edited in this meeting; Nigel to open new issue for remaining part.
<cyril> q+
<nigel> github: end topic
<nigel> gitub-bot, end topic
<nigel> gitub-bot: end topic