See also: IRC log
<cyril> scribe: cyril
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?
<nigel> 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
github: w3c/ttml2#1054
glenn: I'm working on that, stay tuned
nigel: same answer as last time
<nigel> github: 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
github: 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> 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
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.
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]