W3C home > Mailing lists > Public > public-tt@w3.org > December 2017

{minutes} TTWG Meeting 2017-12-07

From: Nigel Megitt <nigel.megitt@bbc.co.uk>
Date: Thu, 7 Dec 2017 17:12:35 +0000
To: TTWG <public-tt@w3.org>
Message-ID: <D64F1B49.501F7%nigel.megitt@bbc.co.uk>
Thanks all for attending today's TTWG meeting. Minutes can be found in HTML format at https://www.w3.org/2017/12/07-tt-minutes.html


In text format:


   [1]W3C

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


                Timed Text Working Group Teleconference

07 Dec 2017

Attendees

   Present
          Cyril, Nigel, Pierre, Glenn, Andreas

   Regrets
          Thierry

   Chair
          Nigel

   Scribe
          nigel

Contents

     * [2]Topics
         1. [3]This meeting
         2. [4]Next Face to Face meeting
         3. [5]tts:overflow does not apply to the region area #239
         4. [6]Clarify that the computed value of
            tts:lineHeight='normal' is 'normal' ttml1#260
         5. [7]Meeting close
     * [8]Summary of Action Items
     * [9]Summary of Resolutions
     __________________________________________________________

   <scribe> scribe: nigel

This meeting

   Nigel: Today, we have F2F, anything further on IMSC 1.1, TTML2
   features, compatibility etc;
   ... TTML2 processor behaviour vs TTML1;
   ... and IMSC and TTML issues and pull requests.

   Andreas: Add TTML2 publication timeline please

   Nigel: Ok, thank you for the reminder.
   ... Any other business?

   group: [no other business]

Next Face to Face meeting

   Pierre: The agenda items I sent through should be covered at
   the F2F if we cannot resolve
   ... them beforehand.
   ... If you look through the list, the "sticky" ones are related
   to the Netflix objection, so that
   ... would be the primary objective for the F2F for IMSC 1.1.
   ... Any other topics that anyone wants for IMSC 1.1 and IMSC
   vNext Requirements for a F2F?

   group: [no]

   Pierre: Then the goal should be to close all issues on IMSC 1.1
   and TTML1 including the
   ... Netflix objection at the F2F.

   Glenn: I would expect to spend some time on TTML2 at a F2F
   also.
   ... I'll come up with a first pass list of the issues that we
   could usefully cover, before our next meeting.

   <scribe> ACTION: gadams Generate a list of TTML2 issues to
   discuss at a F2F

   <trackbot> Error creating an ACTION: could not connect to
   Tracker. Please mail <sysreq@w3.org> with details about what
   happened.

   <inserted> [10]ACTION-511: Generate a list of ttml2 issues to
   discuss at a f2f

     [10] https://www.w3.org/AudioVideo/TT/tracker/actions/511


   Nigel: Anyone think we should not go ahead with a F2F on 8-10
   Jan?

   group: [nobody]

   Cyril: Can we finalise the actual dates?

   Nigel: If it were up to me I would say 9th and 10th - any other
   views?
   ... [following discussion] Confirmed 9th and 10th January 2018,
   venue to be confirmed following offline discussion.

tts:overflow does not apply to the region area #239

   github: [11]https://github.com/w3c/ttml1/issues/239


     [11] https://github.com/w3c/ttml1/issues/239


   Pierre: To confirm my understanding, text is wrapped according
   to the inset rectangle, so
   ... it does not include the padding - is that correct?

   Glenn: The content rectangle of the element undergoing layout
   defines the available measure
   ... and the content rectangle is inset from the allocation
   rectangle of the area assigned to
   ... that element by the padding area and the border area. In
   TTML1 we don't have padding
   ... and border on content elements so the body element, being
   the outermost area being
   ... laid out in TTML1, doesn't have padding or border. Padding
   can only be set on the region,
   ... and then what's left after taking the inset forms the
   allocation area for the body element area.

   Pierre: Right, so that's how it's wrapped. If there is no
   wrapping and overflow is visible then there's no
   ... - characters will show up on the padding, if it's there on
   the region?

   Glenn: Correct.
   ... The TTML1 example on region did not include padding,
   perhaps we should add that example.

   Pierre: Now if there is wrapping and overflow is hidden, then
   the characters will still show
   ... on the padding but they won't extend past the region - is
   that your understanding too?

   Glenn: The allocation rectangle would be the region rectangle
   minus the padding insets,
   ... so if you did not have line wrap enabled ...

   Andreas: I checked this with CSS with an example. Concrete
   example: a limited size region
   ... with a super long 100 character word. Although wrapping is
   activated overflow is hidden,
   ... the long word won't fit in the block container extent, and
   the clipping at least in CSS in
   ... Mozilla will be clipped to the padding edge. Even if the
   padding is added to the content
   ... rectangle the clipping goes to the padding edge. I think
   there is no issue here, though
   ... maybe we should check that it is the same in XSL-FO.

   Glenn: Does it mean the text appears over the top of the
   padding?

   Andreas: No, if overflow is hidden then it only shows within
   the outer edge of the padding rectangle.

   Glenn: So text might appear on top of the padding?

   Andreas: Yes, it will be in this padding area.

   Glenn: Could you provide a codepen or something similar?

   <pal> [12]https://codepen.io/palemieux/pen/pdXgaN


     [12] https://codepen.io/palemieux/pen/pdXgaN


   <atai2> [13]https://jsbin.com/teyebupeki/edit?html,css,output


     [13] https://jsbin.com/teyebupeki/edit?html,css,output


   Cyril: I agree we should have an example and this would be a
   good candidate to add to the test suite.

   Andreas: The jsbin above shows the situation I explained. You
   can try to expand the padding,
   ... and then you'll see more content is showing.
   ... [need to add more letters to the long word in the jsbin]

   Pierre: Or you can set white space: nowrap;

   Glenn: It looks like in Pierre's example the text is drawn over
   the padding area.

   Pierre: Yes, my question is if that is the expected behaviour.

   Glenn: Hmm, in a no-wrap scenario. Part of the problem here is
   region in TTML1 is defined
   ... a little differently to a content area.

   Pierre: Exactly, I'm just trying to discover the correct
   outcome according to TTML1.

   Glenn: I'm not actually sure how to answer this - I'd have to
   look at implementations and
   ... see what was done. It seems like the easiest thing from an
   implementation perspective
   ... is what these demos show.

   Pierre: No, it's subtly different in TTML1 because the padding
   applies to the region and not
   ... the p. It's certainly different in CSS and TTML1. My
   intuition would be that the clipping
   ... happens on the boundary of the p, and so it would not
   overwrite the padding on the region.

   Nigel: +1

   Andreas: The overflow property is applied to the region.

   Pierre: This is why I raised the issue! It's not clear.

   Glenn: I'm pretty sure that in TTPE when overflow is hidden I
   use the boundary of the content rectangle and not the padding
   rectangle for clipping.

   Pierre: It sounds like this is worth more investigations to see
   what implementations do.

   Glenn: It is probably ambiguous right now. Let's investigate
   further.

   Andreas: There's a general question of the overflow property
   for a p container. It is not a
   ... problem of hidden or visible but what the property is for a
   p. If for a p it is always visible
   ... then it will extend the boundary whatever. It's a general
   clarification how this is handled
   ... with the various content elements.

   Pierre: I totally agree. I'll create an example and add it to
   the issue.

   SUMMARY: Pierre will create an example for implementation
   testing and add to the issue.

   Glenn: Note that TTML1 doesn't have padding on p elements.
   ... It doesn't have overflow on p either.

   Andreas: OK, it is still good to investigate.

Clarify that the computed value of tts:lineHeight='normal' is
'normal' ttml1#260

   github: [14]https://github.com/w3c/ttml1/issues/220


     [14] https://github.com/w3c/ttml1/issues/220


   Pierre: My philosophy on this one is to make as little change
   to TTML1 as possible.
   ... In that case the overall consensus is that what's really
   inherited is the value "normal" of
   ... tts:lineHeight rather than the computed value.
   ... Since the algorithm in TTML1 states that values being
   computed before inheritance only
   ... applies to relative values, the dumb way of dealing with
   this was to state that the value
   ... normal is not relative. I thought this would minimise the
   changes and be in the spirit of TTML1.
   ... I thought the reader would be able to accept that.
   ... It sounds like Glenn disagrees.

   Glenn: I agree with the general direction with the caveat that
   what is inherited is what is
   ... in the computed style set of the parent, so we have to
   focus on what is in that set. If we
   ... declare that it is not relative upto the point where it is
   applied, then for inheritance purposes
   ... I think that does what is required. We're in agreement
   there, and that's how I wrote the
   ... slightly different formulation. However I think that when
   you get to the paragraph element
   ... itself, which is where it applies, it must be treated as
   relative because
   ... it has to be related as a percentage of the font etc.

   Andreas: Just to confirm what Glenn said, I also had the
   problem distinguishing between
   ... the inheritance issue and when the value is applied. At the
   end, at the p level, it is relative
   ... to the font size, so it is confusing to say it is not
   relative. I see where you are coming from
   ... to get the inheritance.
   ... Would it be possible to clarify this is just for
   inheritance?

   Pierre: In TTML1 "relative" is only used in relation to
   inheritance.

   Glenn: No that's untrue it is used for computed style set
   processing. One use is inheritance,
   ... the other is in application.

   Pierre: That's an implementation matter.

   Glenn: Let's look at the current height for lineHeight in
   TTML1.
   ... The statement about "computed value must be no less
   than..." and it does not mention
   ... using the token "normal" as a computed value. Previously we
   didn't say where the resolution
   ... occurs, on the applied element or further up the
   inheritance tree. But now we are saying
   ... that it is not relative for inheritance.

   Pierre: look at the step in 8.44.3 step 4 [relative value
   resolution]
   ... I agree the computed value of "normal" is not "normal". The
   key is how this is worded.
   ... It says that computed values are computed values are
   inherited only if they are relative.

   Glenn: This section is not to do with inheritance.

   Pierre: That's right, so at the end of 8.4.4.3 you'll get a mix
   of specified and computed
   ... properties.

   Glenn: That's correct.

   Pierre: So it can remain as a specified value in that set.

   Andreas: I see the problem here. We do want "normal" to be
   inherited. In 8.4.4.3 you can
   ... make the exception as in the PR but not make the additional
   statement that it is not
   ... relative. It would be confusing. You also use the word
   relative in lineHeight and say that
   ... percentage is relative to font size. If you just say step 4
   does not apply to "normal" you
   ... have the same result without the debate about "relative".

   Glenn: We can't take out the word "relative" for lineHeight so
   we still have the generic problem.
   ... We're all in agreement about what is inherited, we just
   need to agree how to characterise
   ... the value in the CSS at the computed value. Everything
   above that needs to be treated
   ... as non-relative, that's clear to me. If we think of the
   original CSS specification it had a
   ... syntax called <number> which we did not introduce in TTML1,
   and is defined to be
   ... inherited as is until the point of application. Somehow we
   need to distinguish between
   ... how to characterise the value in the computed style sets of
   ancestors of p, and declaring
   ... it to be the specified category on ancestors work, but on
   the p you have to compute a
   ... length value, otherwise it doesn't work. That is resolved
   relative to font size. There's a
   ... more elaborate algorithm in TTML2 for specifying that. We
   have the challenge of tweaking
   ... this property so we don't mangle the properties too badly.
   I think it's the right track to
   ... declare it as non-relative but we need to work out what
   happens on the p.
   ... Also in XSL-FO "auto" is defined as non-relative.
   ... In TTML1 we have no line for each style property explaining
   the computed value.
   ... We also don't have "used values" which is in CSS2.1 but not
   in XSL-FO and not in TTML yet.
   ... If we had "used value" we could make use of it. We might
   want to think about that in TTML2,
   ... but we can't do it in TTML1.

   Nigel: Why not?

   Glenn: That would be a massive change, in excess of our mandate
   for a Third Edition.
   ... It would be a borderline substantive change, because it
   might end up fixing a semantic
   ... that is implemented in the field that is currently
   ambiguous.

   Nigel: Why could we not introduce "used value"?

   Pierre: Then we would have to define it in TTML1 and it would
   add a lot of text.
   ... Everything we add introduces potential bugs.
   ... If you look at, for example fontStyle, nowhere does it say
   that normal, oblique and italic
   ... are not relative, but clearly the tokens are inherited. For
   that style value, the token is
   ... always inherited. My proposal was really dumb, to say
   "normal" is like "oblique".

   Glenn: I understand but I don't think it works. In CSS a number
   gets computed at the point of application.
   ... You have to distinguish between inherited values and the
   point of application.
   ... If for example in TTML2 you wanted to set lineHeight on
   inline elements, and convert
   ... "normal" to a computed value on a p, and then a child
   inline block, you would need to
   ... inherit the computed value on the inline element. If we had
   the luxury of used value we
   ... could resolve that.

   Nigel: Why is there no step in 8.4.4.3 that checks if the style
   property is applied to the element?

   Pierre: It does not need to because it contains both specified
   and computed values.

   Glenn: It does not contain the same style property in two
   different categories.

   Pierre: Exactly. Replace a specified value by a computed value
   only if it is relative.
   ... My proposal is to compute the style property but not to put
   it in CSS(E).

   Glenn: We could do that if we didn't have the paragraph under
   lineHeight about the computed value.

   Nigel: Time out on this issue - we've gone round in circles.

Meeting close

   Pierre: I need to drop off now.

   Andreas: Me too.

   Cyril: Just a couple of points since Glenn is still on the call
   - I'm waiting for a reply from Glenn
   ... about ttp:version.

   Glenn: I saw your questions.

   Cyril: I'm trying to understand if the implementation behaviour
   needs to be in the spec or
   ... should be implementation specific.

   Glenn: I would have to sit and look at the code for a few hours
   to determine that.

   Cyril: The other question is, there was an issue where Glenn
   said he would respond over
   ... the weekend but I did not see the response.

   Nigel: I recall that too.

   Cyril: It's w3c/ttml1#214, about the computation of font size.

   Glenn: There's also w3c/ttml1#206 which may be somewhat
   related.

   Nigel: Thanks all. [adjourns meeting]

   [15]ACTION-511: Generate a list of ttml2 issues to discuss at a
   f2f

     [15] https://www.w3.org/AudioVideo/TT/tracker/actions/511


Summary of Action Items

   [NEW] ACTION: gadams Generate a list of TTML2 issues to discuss
   at a F2F

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [16]scribe.perl version
    1.152 ([17]CVS log)
    $Date: 2017/12/07 17:10:06 $

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

     [17] http://dev.w3.org/cvsweb/2002/scribe/





----------------------------

http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------
Received on Thursday, 7 December 2017 17:13:07 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 7 December 2017 17:13:08 UTC