{Minutes} TTWG meeting 2019-05-23

Thanks all for attending today’s meeting. Minutes can be found in HTML format at https://www.w3.org/2019/05/23-tt-minutes.html

In text format:


   [1]W3C

      [1] http://www.w3.org/

                Timed Text Working Group Teleconference

23 May 2019

   [2]Agenda

      [2] https://github.com/w3c/ttwg/issues/39

   See also: [3]IRC log

      [3] https://www.w3.org/2019/05/23-tt-irc

Attendees

   Present
          cyril, gary, glenn, nigel, pierre

   Regrets
          Andreas, Thierry

   Chair
          nigel

   Scribe
          cyril, nigel

Contents

     * [4]Topics
         1. [5]This meeting
         2. [6]WebVTT Implementation Report
         3. [7]TTML2 and TTML3
         4. [8]Clarify relative profile designator does not use
            xml:base (#1033). ttml2#1054
         5. [9]Character-related style properties should not apply
            to ruby containers.
         6. [10]Meeting close
     * [11]Summary of Action Items
     * [12]Summary of Resolutions
     __________________________________________________________

   <cyril> scribe: cyril

This meeting

   nigel: we'll talk about WebVTT IR and 2 issues for TTML2
   ... one for TTML profile registry
   ... in AOB an update from Philippe on the charter
   ... anything else?

WebVTT Implementation Report

   <nigel> [13]WebVTT Implementation Report

     [13] https://www.w3.org/wiki/TimedText/WebVTT_Implementation_Report

   nigel: this was discussed a little bit
   ... I raised concern that there was not enough evidence to make
   a decision
   ... I don't think the group has seen enough that the exit
   criteria are met

   gkatsev: I discussed offline with Nigel
   ... about what should be done
   ... I did not have a chance to snapshot the spreadsheet
   ... some tests are still showing 0
   ... the test is old and it was not expectin gthe API to throw
   ... it sounds like the spec calls the lines to be unsigned long
   ... but if the value is too big it throws
   ... that sounds like an implementation issue, not a spec issue

   nigel: the point of the IR is to show that whatever is
   specified is implemented
   ... so the tests are doing their job showing that impl. don't
   implement the spec

   gkatsev: for this particular test, the test is out of date
   ... if you take the negative test, it shows that it is working
   otherwise

   nigel: if you update the test to match the spec, the test will
   pass?

   gkatsev: no, because implementation only allow integer
   ... to me that looks like an incredibly minor difference
   ... we could change the spec
   ... the other big thing is the HTML character entities
   ... and it seems a impl bug that they don't support all of them
   ... there is a bug filed against Safari
   ... and I have a proof of concept showing that it's
   implementable

   nigel: in terms of steps to take to show the evidence that exit
   criteria are met
   ... one is showing it on the wiki
   ... and showing that everything is implemented
   ... is it worth doing a planning for that

   gkatsev: I can just keep working through it
   ... is there a document describing exit criteria

   nigel: it's in the status of the document part of the CR

   gkatsev: I think we're pretty much there

   nigel: this assessment is based on your spreadsheet
   ... but you told us some of the tests are problematic
   ... and a bunch of the tests are red

   gkatsev: safari has a slightly non-conformant implementation of
   regions

   nigel: to be clear, we are testing against the spec

   gkatsev: it sounds like this is an implementation bug
   ... with a minor tweak everything does work

   nigel: sure but the exit criteria says it's based on the test
   results
   ... if there is a story to be told about the significance of
   the test failure, maybe
   ... you need to highlight that in the IR

   gkatsev: that totally makes sense
   ... there are a couple of tests like this
   ... I'll have a more detailed list of tests when the IR is more
   complete

   nigel: in terms of spec edits, you have a PR open, Silvia
   approved it

   gkatsev: it'll stay open until we request to go to PR

   nigel: makes sense

TTML2 and TTML3

   github: w3c/ttml2#1054

   glenn: I'm working on that, stay tuned

   nigel: same answer as last time

Clarify relative profile designator does not use xml:base (#1033).
ttml2#1054

   <nigel> github: [14]https://github.com/w3c/ttml2/pull/1054

     [14] https://github.com/w3c/ttml2/pull/1054

   nigel: the reason you are working on it is because you think
   changes are needed

   glenn: yes, I'll have an update before the next meeting

   nigel: is it worth sharing your initial thoughts

   glenn: no
   ... I'll reach out to you separately if I need

Character-related style properties should not apply to ruby
containers.

   github: [15]https://github.com/w3c/ttml2/issues/1043

     [15] https://github.com/w3c/ttml2/issues/1043

   nigel: can we get a resolution?

   glenn: the big picture I see is "applies to" is a CSS notion,
   formally defined in the CSS spec

   <glenn>
   [16]https://www.w3.org/TR/2011/REC-CSS2-20110607/about.html#app
   lies-to

     [16] https://www.w3.org/TR/2011/REC-CSS2-20110607/about.html#applies-to

   glenn: it lists the elements to which the property applies
   ... we must note that a ruby container is not an element
   ... it is a specific span
   ... and then in CSS, all elements have all properties
   ... but some properties have no effect
   ... that's the guidance we get from CSS
   ... XSL-FO and TTML follow that
   ... applies to refers to element types and deals with rendering
   effect
   ... the question here is to add language to the 18 style
   properties to say that it does not apply to ruby containers
   ... ie. the top level container, the ruby container and the
   text container
   ... my position is that we should not add this language
   ... the semantics depend on the content of the element
   ... the issue of rendering effect may or may not apply
   depending on other semantics
   ... having renderable text in it
   ... we added some language in my PR then in his PR
   ... we both seem to have agreed on language to say that it does
   not apply
   ... the only disagreement is whether or not to add language
   ... to the properties
   ... there are 3 properties to which it applies
   ... direction, unicode bidi and XXXX
   ... for the other 15, the semantics only apply to glyph areas
   ... the bottom line is that there was no case of a ruby
   container producing glyph areas to which these 15 properties
   could apply
   ... there is a semantic no-op
   ... in the interest of giving readers a clue, I did add a note
   to the PR
   ... in the 10.2.35.1
   ... that highlights for the reader that there is no
   significance to the fact that a property can apply
   ... I think my PR covers all the case
   ... with the exception of tweaking properties regarding the
   notion of glyph areas

   nigel: you described very clearly your thoughts process, which
   makes sense

   <Zakim> nigel, you wanted to note that TTML2 doesn't say that
   "applies to" is as per the CSS convention

   nigel: the need to clarify "applies to" is because there is
   some ambiguity
   ... for something like ruby-align, the "applies to" sets a
   precedent
   ... in giving more information
   ... the CSS spec is a bit interesting
   ... because it refers to conceptual things that are elements in
   HTML
   ... but not elements in TTML
   ... that makes me think we should be clearer in the spec
   ... we did it for ruby align
   ... we should be helpful for the other properties
   ... I wouldn't do that for tts:color saying that it applies to
   character content of an element, that's too obvious

   glenn: so raised 3 things
   ... we don't explicitly refer to the CSS definition of "applies
   to"
   ... that's true
   ... XSL-FO uses it without referring to it explicitly
   ... we have to balance use of references with clutter in the
   spec
   ... I could add a formal reference
   ... the 2nd point about ruby-align's precedence
   ... is a bad way to go
   ... my preference would be to remove the existing text in
   ruby-align (and the other one)
   ... we can embellish the prose to make it clear
   ... maybe that's part of why we are where we are
   ... turning 2 into 17 is a bad way to go
   ... it complicates tracking that semantics
   ... it clutters the table in my opinion
   ... the 3rd point is about clear to implementers
   ... the spec is not an implementation guide
   ... somebody can write one
   ... if you look at MPEG-2 systems spec, there is no information
   about implementation
   ... we are in good company when we don't put implementation
   details
   ... what I'm willing to do is add some text to conventions
   ... remove text from ruby align
   ... but not more

   pal: let's keep it simple
   ... "applies to" is extremely useful to implementers
   ... if a particular element is not on that list
   ... implementation can bypass it for rendering
   ... for instance that text-decoration is not on applies to for
   div, is already there and useful
   ... I see no reason not to continue on the path of listing
   things to what elements a property applies
   ... to the point that the ruby-containers are not "elements",
   that's knit-picking
   ... I think it's consistent and useful to list ruby containers
   on the list things to which a property applies or not applies

   cyril: I agree with listing them

   nigel: under the ruby attributes, there is a CSS mapping
   ... that's useful
   ... let's not forget that it's there

   glenn: even if we were to add something, we want to not repeat
   text
   ... style properties cannot apply to nothing

   pal: what about text-decoration?

   glenn: [explains underline and box model
   ... we have consistently done that in the spec
   ... they apply to span because applying to div is for
   inheritance

   pal: that's different, there is an inheritance line

   glenn: it's because it applies to the most nested glyph area

   pal: your logic doesn't work
   ... you say text decoration cannot apply to div because it
   would be confusing
   ... but you're saying the opposite for ruby container

   [scribe having problems following and scribing]

   glenn: when I reviewed all the 18 styles that are proposed to
   be changes
   ... both the text-decoration and text-emphasis properties have
   applies to glyph areas or inline ares
   ... the 15 properties do not have the same text
   ... my conclusion was that all 15 style properties, the
   semantics of those relate to glyph areas
   ... generated by anonymous spans or spans

   nigel: on the point of removing inline areas from text
   decoration
   ... CSS spec says, applies to all elements
   ... but there is specific text that says that underline only
   applies to text
   ... for example not on images
   ... but the difference between CSS and TTML is that CSS has
   blink

   glenn: I agree
   ... and I should handle that with a separate issue
   ... one could fathom having blink apply to a box
   ... in the CSS semantics
   ... so since we don't have blink, we could remove that
   ... I'll do that in another PR
   ... but that means that the 15 properties have languages that
   say that they apply to glyph area
   ... and since it's not possible to generate glyph areas in the
   ruby containers
   ... there is no logical way that it applies
   ... so it would be redundant and clutter
   ... that's the basis of my objection
   ... that's what I added in the note

   nigel: pal are you satisfied?

   pal: no
   ... text decoration is not on applies to for div, the same
   should apply to ruby containers
   ... I'm even more convinced

   nigel: as a chair, I see several people thinking additional
   text is needed and I see a single voice (glenn) thinking it is
   not needed

   glenn: for text decoration, I could add language or note in the
   prose
   ... and if pierre sees other properties where that is
   confusing, I could add text

   pal: I don't understand why we don't want to reuse the "applies
   to" line
   ... cyril suggested to use definitions to avoid wordy lines
   ... that's a good idea
   ... we shouldn't use prose gymnastics for that

   glenn: one cannot avoid reading the prose to understand the
   effect
   ... of rendering

   pal: right, but "applies to" is a bypass

   [17]https://www.w3.org/TR/css-regions-1/#the-region-fragment-pr
   operty

     [17] https://www.w3.org/TR/css-regions-1/#the-region-fragment-property

   <nigel> scribe: nigel

   post-conversation-summary: The group was not able to find
   consensus at this time on how
   ... to progress, either procedurally or editorially.
   ... Glenn stated his willingness to adjust the prose for
   tts:textDecoration specifically and
   ... no other style attribute, to clarify that it does not have
   any effect on inline areas, but
   ... only on text.
   ... The group does have consensus on the handling of LWSP and
   for defining the usage of
   ... "applies to" as per CSS2's convention, and that style
   attributes that have rendering
   ... effects only on text content can be excluded from
   consideration by those ruby
   ... containers that are not permitted to contain text content.
   ... The remaining disagreement is whether or not to add
   qualifying text to those style
   ... attributes (normatively in the Applies to row of the style
   table) to describe this exclusion, with Glenn opposed, Cyril,
   Nigel and Pierre in favour.
   ... No clear path forward to resolve this at this time.

Meeting close

   Nigel: Reminder that I'm not available to chair next week so if
   the meeting is to go ahead
   ... then we need an alternative volunteer chair.
   ... [adjourns meeting]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [18]scribe.perl version 1.154 ([19]CVS log)
    $Date: 2019/05/23 16:54:31 $

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/