- 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