Emphasize null style semantics in context of ruby container spans (#1100).

[skynavga]

Closes #1100.

[skynavga]

Although I am generally against repeating the same text when the reader has access to a common declaration, I have, by way of a compromise, added (in https://github.com/w3c/ttml2/pull/1101/commits/9e2fe63da0b92285f70ebc40edccc13475b6bc03) the text "; and see Note" to each of 15 style property's applies to declaration, where "Note" is a link to the note added by this PR to 10.2.35.1.

Note that three style properties that Pierre had proposed constraining cannot be constrained because these properties apply to ruby container spans as well:

• tts:direction
• tts:unicodeBidi
• tts:wrapOption

Therefore, I did not qualify the applies to declaration for these properties.

[skynavga]

@palemieux Re: https://github.com/w3c/ttml2/pull/1101#pullrequestreview-247160031, this is not a legitimate request as applied to editorial PRs, at least as far as our standing protocol applies. If you need more time to review a specific PR that may subject to early merger, then please state your reasons as to why more time is required. Thanks.

[palemieux]

@skynavga The standing protocol only applies to those changes that are determined editorial by consensus, not by unilateral action. In any case, this PR as a much larger deficiency, as discussed at https://github.com/w3c/ttml2/pull/1101#pullrequestreview-243028113 .

[skynavga]

@palemieux if there is an approval on an issue marked as editorial, and there is no objection to it being marked as editorial, then it falls under the early merger policy; if you would like to review this policy, please raise it to the group in session; regarding this particular PR (#1101), I have no intention to merge it early, whether or not an approval has been given;

[palemieux]

@skynavga I think you have two choices: take your time now to gather consensus over proposed resolutions, or faced potentially lengthy delays sooner or later.

[skynavga]

@palemieux qui tacit consentire videtur; if I have an approval on an editorial PR, I apply my own judgment as to whether sufficient time has passed and the level of potential controversy on a case by case basis; I believe this is consistent with this WGs operating policy and past history; if you want to propose a change to that policy, then feel free to do so;

[skynavga]

@palemieux I will leave your blocker in place for this issue; however, a simple request as a comment to allow this PR to go to full term would have sufficed, and would have been the more collegial approach

[nigelmegitt]

It seems like now might be a good time to summarise, because the current state and the original direction may seem surprising (they do to me).

In response to a request to be more specific about the elements to which the style attributes apply, by changing the text in the Applies To column, @skynavga fought hard against doing that on the basis that (summarising from memory, apologies if this is inaccurate) it would add maintenance, and also that it is unnecessary.

It seems like everyone is agreed that the application of the relevant style attributes to the "ruby containers" (shorthand term) has no effect, so it is academic whether they are included in the "applies to" or not, except that the original issue said that it is helpful to implementers to know from the beginning that some style attributes never apply to those "ruby containers", because then they can be excluded from processing.

This pull request has now got to the point where there is additional text on the "applies to" rows (so the maintenance requirement has not been avoided) and the text it points to says that they "have no semantic affect" during presentation processing, confirming that we are all in agreement on that point.

The decision we need to make as a group is whether we want to express this non-effect as:

1. an informative consequence of other normative text (as in this pull request) or
2. as an additional normative categorisation as in #1071.

For myself, I'm not sure that there is any significant difference between these approaches, or that there is anything testable that would result from either one or the other approach being taken (which suggests the informative approach is adequate). As always, views welcome. I would like us to come to a conclusion on this fairly rapidly in Thursday's call.

[skynavga]

@nigelmegitt thanks for that summary, with which I largely agree; I would merely add the following remarks:

it is helpful to implementers to know from the beginning that some style attributes never apply to those "ruby containers", because then they can be excluded from processing

• It is important to note that this "helpful" statement takes the form of suggesting an optimization that an implementer may or may not choose to employ. That is to say, an implementation would be fully compliant if it completely ignores such an optimization. This point is at the core of why adding a normative constraint to applies to is untestable.

This pull request has now got to the point where there is additional text on the "applies to" rows (so the maintenance requirement has not been avoided)

• My preference is to add nothing to the applies to entries; however, I proposed the current text "see also Note" as a compromise in the case that the group feels something is needed. I can live with this note, but I do believe it has a (possibly unwarranted) maintenance overhead; for example, do we need to add the same note to other properties, such as tts:color? or future tts:font* or tts:text* properties?

[cconcolato]

@nigelmegitt you seem to indicate that the "applies to" row would be informative? Is that the case?

[skynavga]

@cconcolato the "applies to" item of style property definition tables as a whole is normative; however, adding comments of the form "see also Note" to the "applies to" item is by itself informative, since Notes do not carry normative content;

[nigelmegitt]

@cconcolato : what @skynavga said - the proposed addition here to the Applies row is informative; the row itself is normative.

[css-meeting-bot]

The Timed Text Working Group just discussed Emphasize null style semantics in context of ruby container spans.

The full IRC log of that discussion

<cyril> topic: Emphasize null style semantics in context of ruby container spans
<cyril> github: https://github.com/w3c/ttml2/pull/1101
<cyril> nigel: I summarized it
<cyril> ... it adds a note to all the "applies to"
<cyril> ... my summary of the debate is whether we need to do it normatively or informatively
<cyril> ... Pierre how do you feel about that at the moment?
<cyril> pal: I feel like day 1
<cyril> ... the practice is to list what a property applies to in this line
<cyril> ... and in the prose to add text
<cyril> ... I don't see any reasons to not list the span that it does not apply to
<cyril> nigel: you don't see any difference in making it normative/informative
<cyril> pal: the practice is so loose in TTML2 that it does not make any difference
<cyril> nigel: can you live with the proposal?
<cyril> pal: it could be expressed more clearly
<cyril> nigel: glenn, if we said "spans except ..." with an editorial way
<cyril> glenn: 1) a span that serves as a ruby container, base container or text container is not an element
<cyril> ... it is no different than a span that is empty
<cyril> ... we do not say these properties do not apply to spans that are empty
<cyril> ... 2) a span that serves a ruby container is not an element by the definition that we use or that CSS uses
<cyril> ... until we introduced ruby align and ruby position, we did not have any case that called out a qualified version of an element
<cyril> ... we went off-track in my opinion when I wrote that text
<cyril> ... if we had not done so (I believe it was an error) we would not have that conversation
<nigel> q+ to say that elements are not necessarily only defined by their qualified name alone
<cyril> 3) there is no normative impact and it's not testable to say that it does not apply to
<cyril> ... so it's strictly an informative advice for the reader
<cyril> ... that we can deal with through a note
<cyril> ... it's not different to other parts of the spec where you have to follow the text
<cyril> 4) the issue about optimization
<cyril> ... we don't document premature optimizations that could turn out to be false
<cyril> ... out of the 18 properties that Pierre wanted to modify I've determined that 3 do apply
<cyril> ... the other 15 are somewhat arbitrary
<cyril> ... because for example color could follow the same logic
<cyril> ... my original opinion was not to write anything
<cyril> ... the note is a compromise
<cyril> ... I do not accept Pierre's proposal
<cyril> ... we already have a definition of ruby container in the text, defined in 10-1
<nigel> ack ni
<Zakim> nigel, you wanted to say that elements are not necessarily only defined by their qualified name alone
<cyril> nigel: it seems reasonable to me to specify elements not only by name but qualifying the selection
<cyril> s/but/but by/
<cyril> ... you say that CSS does not talk about qualified elements
<cyril> ... but actually CSS uses whatever is meaningful even if it's not an element
<cyril> ... there is a precedent in CSS
<cyril> ... I take your point that there is no normative impact
<cyril> nigel: do these arguments work for you?
<cyril> pal: I'm all for finding a compromise
<cyril> ... we are very close, because Glenn's latest proposal adds text to "applies to
<cyril> ... we are in the right direction
<cyril> ... if that link linked to a specific note not a generic one, and that note listed those elements to which the style property does not apply
<cyril> ... that might be wordy but explicit and not ambiguous
<nigel> scribe: nigel
<nigel> scribe: cyril
<cyril> glenn: what I hear you are proposing is to copy the note 15 times in the text with exact wording
<cyril> ... or with just the name of the property substituted
<cyril> ... we try to use generic languages
<cyril> ... it creates a maintenance issue
<cyril> pal: I don't disagree, it's wordier
<cyril> ... I'm trying to find a compromise
<cyril> nigel: why do we need those specific notes?
<cyril> pal: it has to be very clear for everybody whether or not by reading the applies to line it applies to or not
<cyril> ... a generic note does not do that
<cyril> ... just like unicodeBidi does not apply to div
<nigel> scribe: nigel
<nigel> Cyril: Q about the text in Glenn's pull request.
<nigel> s/Cyril: Q about the text in Glenn's pull request.//
<nigel> scribe: cyril
<cyril> glenn: I definitely do not agree with the intent that pierre stated
<cyril> ... that the applies to line be definitive and complete
<cyril> ... with respect to the application semantics
<cyril> ... I'm convinced that the information in the applies to line has to be taken in context of the full prose of each style
<cyril> ... in XSL-FO appendix B.4
<cyril> ... there is generic language
<cyril> ... that says that further clarification may appear in the text
<nigel> [[ For each property the formatting objects it applies to is listed. It should be noted, however, that for some formatting objects there are qualifications on applicability or values permitted. ]]
<cyril> ... that's why I'm disagreeing in part with Pierre's original premice
<cyril> pal: thanks for highlighting the crux of the issue
<cyril> ... past practice in TTML and CSS has been to be exhaustive in the applies to line
<cyril> ... that's the intention of my proposal
<cyril> ... it's clear in CSS and TTML that that line has been exhaustive
<cyril> ... e.g. unicodeBidi
<cyril> ... div is not listed under unicodeBidi
<cyril> ... because it cannot apply to div so it cannot be listed there
<cyril> pal: if glenn's note would list the exact properties that "might not" apply, that would work for me
<cyril> ... I'm not fine with leaving a vague note
<cyril> glenn: I objected to that because of the maintenance effor
<nigel> scribe: nigel
<nigel> Nigel: if you're not happy with the note propose a change
<nigel> Pierre: I've proposed alternate text in a separately maintained PR, or would accept a specific note on each
<nigel> .. style property.
<nigel> Glenn: Here's a suggestion: if we put a note in each of those 15 properties that points to the generic note and says
<nigel> .. it applies to this specific property, would that satisfy you, and have the Applies to line point to that?
<nigel> Pierre: Yes, I think that would satisfy me. I don't like it editorially.
<nigel> Glenn: I'm proposing instead of the "See also" note I could add a note in each of the 15,
<nigel> .. and I would say the generic note applies to this property.
<nigel> Pierre: Yes
<nigel> Glenn: That would give you something explicit in each of the properties
<nigel> Pierre: Yes and then the note can be more definite
<nigel> Glenn: I'll tweak this PR to make those changes and we'll see if we can accept that, and maybe all the related pull requests too.
<nigel> Pierre: Sounds good to me.
<nigel> Nigel: Thank you both for working constructively towards a solution.

[skynavga]

@nigelmegitt re: https://github.com/w3c/ttml2/pull/1101#pullrequestreview-249881080, I am already extremely uncomfortable with repeating the new comment I have added 15 times, and now you want to expand that text; what I implemented in this recent change is exactly what we agreed to do yesterday; why are you modifying that agreement? if the agreed approach is open for revision, I would prefer going back to my original position, where the applies to entry point directly to (and only to) the generic note;

[nigelmegitt]

@skynavga This is the benefit of having proposed text to review - it did not match my understanding of the agreement (because the 2nd-down-the-line note still says "might" in it and I thought we agreed to reword it), and seeing how it looks in reality gives something concrete to respond to.

Rather than threatening to retrench your position, perhaps you could consider my proposal on its merits on behalf of the reader rather than the Editor? I think they are:

1. There's only one note to dereference for each style attribute, so it is easier to navigate.
2. Overall there is one fewer note in the document.
3. The text of the (now duplicated) note is simpler than the removed long note.

I do agree with you that having duplicated text is not ideal, but given the conversation yesterday it seems that @palemieux would not be able to accept the previous proposal of a single generic note and duplicated pointer text.

[skynavga]

@nigelmegitt we did not agree to take out the "that might apply" from the generic note yesterday; we agreed to add more concrete binding to that generic note so that "might" is effectively turned into "does"; the new notes do that by explicitly saying that the generic note "holds for this attribute"; again, if you want to insist on incorporating the entire text of the generic note into each of the 15 locations, then I will back out of the compromise agreement, which I am already uncomfortable with; I would rather see NO spec change for this entire suite of related PRs than copy the generic note 15 times.

[palemieux]

I agree with @nigelmegitt that the indirection in the current proposal is not ideal. What about the following approach?

In tts:fontWeight:

Applies to: span; see also Note related to the applicability of certain style properties to ruby container spans.

In Terms and Definition:

Add definition for ruby container spans: ruby container, ruby base container, or ruby text container

In 10.2.35.1 Special Semantics of Ruby Annotations:

Simplify the Note to state: Style properties that affect glyph areas have no semantic affect during presentation processing of a ruby container span since no significant text node appears as a child of a ruby container span. For example, if a tts:fontStyle attribute is specified on a ruby container span, then it has no significant text node in scope to which it may be applied; however, a value specified for tts:fontStyle on such a ruby container span is still inherited by other (non-anonymous) span element children of the ruby container span.

[skynavga]

@palemieux I can agree to that; I will update this PR accordingly in the next few days; [I'm departing for Manila today]

[skynavga]

@palemieux see https://github.com/w3c/ttml2/pull/1101/commits/a9025fed6d93a9b6c69b485171f5b65cc5b4fe9c

[skynavga]

@palemieux found time to implement https://github.com/w3c/ttml2/pull/1101#issuecomment-503430680; please check

[palemieux]

LGTM. Can all the other PRs that clarify application of style properties be merged into this one, so that we can make that the NOTE is present in all relevant style properties?

[skynavga]

There is no need to merge them. Their changes do not intersect. All you need to do is drop your change requests on the other PRs and I will merge all into master.

On Wed, Jun 19, 2019 at 8:37 PM Pierre-Anthony Lemieux < notifications@github.com> wrote:

LGTM. Can all the other PRs that clarify application of style properties be merged into this one, so that we can make that the NOTE is present in all relevant style properties?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/ttml2/pull/1101?email_source=notifications&email_token=AAC4E32EHSSDUEIWPWG2LG3P3L3RHA5CNFSM4HPXMJ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYD5BBI#issuecomment-503828613, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC4E36X23GPBWPE447ABFTP3L3RHANCNFSM4HPXMJ5Q .

[palemieux]

@skynavga I would like to review them together since all these changes were prompted by the same issue.

[skynavga]

I am not going to merge them into one PR just to satisfy your review preferences. You already gave approval to each of the other PRs during last week’s call. Feel free to merge them into a local branch if you want to review them as a whole.

On Wed, Jun 19, 2019 at 9:17 PM Pierre-Anthony Lemieux < notifications@github.com> wrote:

@skynavga https://github.com/skynavga I would like to review them together since all these changes were prompted by the same issue.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/w3c/ttml2/pull/1101?email_source=notifications&email_token=AAC4E3ZIW3OKD45GSMGVKKLP3MAGPA5CNFSM4HPXMJ52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYD6VPY#issuecomment-503835327, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC4E3ZQWDJ3L3CAN4REII3P3MAGPANCNFSM4HPXMJ5Q .

[palemieux]

@skynavga What is the effect of applying tts:direction on a ruby container span?

[palemieux]

@skynavga What is the semantic affect of tts:color on a ruby container span?

[palemieux]

@skynavga What is the semantic affect of tts:unicodeBidi on a ruby container span?

[palemieux]

@skynavga What is the semantic affect of tts:wrapOption on a ruby container span?

[skynavga]

@palemieux for all of your four previous comments the answer is the same, which is "the same semantic affects of applying X to a span that is not a ruby container span"

[palemieux]

@skynavga To be more specific by way of an example: what is the impact of applying tts:color, which modifies the color of text marks, on a ruby container span, given that the ruby container span does not contain text nodes?

[skynavga]

@palemieux I think you mean specifying tts:color rather than applying; in any case, it means what I said, that it applies to the ruby container span no differently than it would apply to a span that is not a ruby container span, which means it applies to any glyph area in scope (of which there are none since there are no text nodes to which it might apply) and it is inherited by descendent spans;

what other interpretation is possible?

[palemieux]

@skynavga in which circumstances would different computed values of tts:color on a given ruby container span yield different rendering results?

[skynavga]

@palemieux if you are asking what the semantic affects of changing the value of tts:color on a ruby container span are, then the answer is that it affects what tts:color is inherited by descendent spans; is there something else you think might be affected?

[palemieux]

then the answer is that it affects what tts:color is inherited by descendent spans;

@skynavga "inherits" is not the same as "applies", which is why the two concepts are treated differently for each style property and in 10.4.4.2 Specified Style Set Processing.

For instance, tts:fontWeight does not apply to div because, in the following scenario, no value of the tts:fontWeight attribute on div can yield a different rendering result. In other words, changing the computed value of a style property on an element to which it does not apply can never yield a different results.

<div tts:fontWeight=XXX>
<p tts:fontWeight="bold">hello</p>
</div>

[skynavga]

@palemieux of course it can produce different presentation results:

<div tts:fontWeight='bold'>
  <p>hello</p>
</div>

produces different results than

<div tts:fontWeight='normal'>
  <p>hello</p>
</div>

I'm failing to understand what point you are trying to make here or what information you are asking about. Is there an actual problem you are suggesting needs to be addressed?

[palemieux]

@skynavga The example you provided above is different than the one I had provided (you removed tts:fontWeight on <p>).

Ask yourself, can modifying the computed value of tts:fontWeight on div after style resolution processing change rendering? If not, then tts:fontWeight does not apply to div.

[skynavga]

@palemieux Why are you even asking about whether tts:fontWeight applies to div? Is div listed in the applies to line? No. So what point/problem are you attempting to resolve here?

[palemieux]

@skynavga Ask yourself, can modifying the computed value of tts:color on a ruby container span after style resolution processing ever change rendering? If not, then tts:color does not apply to ruby container span.

[skynavga]

@palemieux I should also add that you are making a false assumption that presentation semantics is predicated wholly on applies to statements in the property definition tables. It is clear that different visual renderings result from making changes to what style attributes are specified on what elements irregardless of whether the presentation semantics associated with those style attributes is said to apply to an element.

[palemieux]

@skynavga I am literally asking you: can modifying the computed value of tts:color on a ruby container span after style resolution processing ever change rendering?

[palemieux]

It is clear that different visual renderings result from making changes to what style attributes are specified on what elements irregardless of whether the presentation semantics associated with those style attributes is said to apply to an element.

Yes, but this is the result of inheritance, and regardless of whether the style property applies to the element.

[skynavga]

@palemieux and I keep answering the same: yes it can change rendering, because a change in the computed value results in a change to inherited values

[palemieux]

because a change in the computed value results in a change to inherited values

My question is: can modifying the computed value of tts:color on a ruby container span after style resolution processing ever change rendering?

(edit: emphasis on the after style resolution processing)

[skynavga]

@palemieux the computed value cannot change after style resolution processing, which means that inheritance can be performed once and only once; however, animation can cause changes to the used value, and, hence, the actual value, after style resolution processing

[palemieux]

@skynavga Please focus on the question: can modifying the computed value of tts:color on a ruby container span after style resolution processing ever change rendering?

[skynavga]

@palemieux the question is a non-sequitur: there is no mechanism for changing the computed value of a style property after style resolution processing

[skynavga]

@palemieux regarding animation, though we don't explicitly say it in TTML2, the animation sandwich model applies regarding continuous animations via the animate element; in particular, as described in [1] continuous animations change the presentation value, which, for us, translates to used value, so continuous animations do not cause changes to inheritance or the result of the style resolution processing procedure;

[1] https://www.w3.org/TR/2001/REC-smil-animation-20010904/#AnimationSandwichModel

[palemieux]

@skynavga My objective is not to litigate resolution processing and/or animation processing, but instead develop a criteria to determine whether a style property applies to an element.

Rephrasing my question to make it palatable to you: can modifying the actual value of tts:color on a ruby container span ever change rendering?

[skynavga]

@palemieux re:

Rephrasing my question to make it palatable to you: can modifying the actual value of tts:color on a ruby container span ever change rendering?

No.

However, re:

develop a criteria to determine whether a style property applies to an element

I do not consider it necessary to develop, articulate, or otherwise publish such a criteria, even if we could all agree to what that criteria might be, and I expect we would never reach such an agreement in the first place. If you want to develop such a criteria for your own thinking, that is a different matter, but I do not consider doing such a thing to be part or parcel of resolving any of the current outstanding issues on TTML2.

[palemieux]

I do not consider doing such a thing to be part or parcel of resolving any of the current outstanding issues on TTML2.

Well, I do, since the issue is specifically about whether some style properties apply to ruby span containers, and you have not succeeded in developing a consistent approach to making this determination.