<scribe> scribe: nigel
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]
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> ACTION-511: Generate a list of ttml2 issues to discuss at a f2f
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.
github: 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> https://codepen.io/palemieux/pen/pdXgaN
<atai2> 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.
github: 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.
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]
ACTION-511: Generate a list of ttml2 issues to discuss at a f2f