- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 21 Sep 2016 07:40:37 +1000
- To: Thierry Michel <tmichel@w3.org>
- Cc: Public TTWG List <public-tt@w3.org>, David Ronca <dronca@netflix.com>, Nigel Megitt <nigel.megitt@bbc.co.uk>
- Message-ID: <CAHp8n2n8MfJ1ZS8O6LCDiReoMg-Eg0jba=o6pNz_HKafJS4wmA@mail.gmail.com>
Comments are in the bug tracker and in emails. All the information is
available. It's a matter of collating it all together.
Best Regards,
Silvia.
On 20 Sep 2016 6:57 PM, "Thierry MICHEL" <tmichel@w3.org> wrote:
>
>
> Le 20/09/2016 à 00:07, Silvia Pfeiffer a écrit :
>
>> Yes, agreed.
>>
>> Wide review had been shown and feedback been received.
>>
>
>
> I am not aware of this.
>
> We indeed received comments/issues on the WebVTT spec. Some of these
> comments have been discussed by the CG.
> When and where was the wide review shown ? and feedback received from
> commenters on the group resolution.
> Is there a disposition of comments you could point to ?
>
> Best,
>
> Thierry.
>
>
> I think it's with
>
>> the WG to make the next move.
>>
>> Best Regards,
>> Silvia.
>>
>>
>> On 20 Sep 2016 7:30 AM, "Thierry MICHEL" <tmichel@w3.org
>> <mailto:tmichel@w3.org>> wrote:
>>
>> Sylvia, David,
>>
>> To clarify the W3C Process ...
>>
>> To *enter CR*, the TTWG must show that there is a wide review.
>> About a year ago, different groups (I18N, WAI, CCS, etc.) have
>> raised their issues on the WD. Each comment needs to be adressed
>> (some have been by the CG) get consensus and resolution from the
>> TTWG, and get agreement from the commenters.
>> So currently the TTWG can't request CR publication of WebVVT.
>>
>> Once this task is done, the TTWG may request CR publication to the
>> Director.
>>
>> Then, to *exit CR*, it requires to have 2 implementations of every
>> feature in the specification.
>>
>> Best,
>>
>> Thierry.
>>
>>
>>
>> Le 19/09/2016 à 22:50, David Ronca a écrit :
>>
>> CR requires 2 implementations of every feature in the
>> specification,
>> correct?
>>
>> D
>>
>> On Mon, Sep 19, 2016 at 1:30 PM, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com <mailto:silviapfeiffer1@gmail.com>
>> <mailto:silviapfeiffer1@gmail.com
>> <mailto:silviapfeiffer1@gmail.com>>> wrote:
>>
>> There's nothing stopping the group to decide to move WebVTT
>> to CR
>> right now. Why not just get it done?
>>
>> Best Regards,
>> Silvia.
>>
>>
>> On 20 Sep 2016 3:33 AM, "Nigel Megitt"
>> <nigel.megitt@bbc.co.uk <mailto:nigel.megitt@bbc.co.uk>
>> <mailto:nigel.megitt@bbc.co.uk
>> <mailto:nigel.megitt@bbc.co.uk>>> wrote:
>>
>> Thanks all for a very productive first day of our Lisbon
>> TPAC
>> face to face meeting. Minutes can be found in html format
>> at https://www.w3.org/2016/09/19-tt-minutes.html
>> <https://www.w3.org/2016/09/19-tt-minutes.html>
>> <https://www.w3.org/2016/09/19-tt-minutes.html
>> <https://www.w3.org/2016/09/19-tt-minutes.html>>
>>
>> We made 1 resolution:
>>
>> *RESOLUTION: If we do not move WebVTT to CR in this
>> Charter
>> period then we will not include it in any new Charter.*
>>
>>
>> The review period for this resolution under our Decision
>> Process
>> ends on Monday 3rd October.
>>
>> Minutes in text format:
>>
>> [1]W3C
>>
>> [1] http://www.w3.org/
>>
>> Timed Text Working Group Teleconference
>>
>> 19 Sep 2016
>>
>> See also: [2]IRC log
>>
>> [2] http://www.w3.org/2016/09/19-tt-irc
>> <http://www.w3.org/2016/09/19-tt-irc>
>> <http://www.w3.org/2016/09/19-tt-irc
>> <http://www.w3.org/2016/09/19-tt-irc>>
>>
>> Attendees
>>
>> Present
>> Rohit, Nigel, Glenn, Thierry, Dae, Andreas,
>> David,
>> Pierre
>>
>> Regrets
>> Chair
>> Nigel
>>
>> Scribe
>> nigel
>>
>> Contents
>>
>> * [3]Topics
>> 1. [4]Agenda bash
>> 2. [5]Plan for Joint Meeting with Web & TV IG
>> 3. [6]WebVTT stuff
>> 4. [7]Tagging
>> 5. [8]TTML1 Errata
>> 6. [9]TTML2 Pull Requests
>> 7. [10]IMSC 2
>> 8. [11]Agenda bash
>> 9. [12]TTML2 implementation work
>> * [13]Summary of Action Items
>> * [14]Summary of Resolutions
>>
>> __________________________________________________________
>>
>> <scribe> scribe: nigel
>>
>> Agenda bash
>>
>> group: [discusses topics on meeting page
>>
>> [15]https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>>
>>
>> [15]
>> https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule
>> <https://www.w3.org/wiki/TimedText/tpac2016#Schedule>>
>>
>> <glenn> +Present Glenn
>>
>> nigel: Seems like the topics list is pretty close to
>> the order
>> we want to cover stuff in.
>>
>> Plan for Joint Meeting with Web & TV IG
>>
>> nigel: We are meeting the Web & TV IG at 11, so need
>> to provide
>> an update etc.
>> ... Discusses proposal for Web & TV IG consisting of
>> update on
>> our work in TTML,
>> ... audio description requirements, issue of
>> relationship
>> between encoded video, media player
>> ... and timed text presentation; live contribution
>> and BBC
>> subtitle guidelines. (last two points from Nigel with a
>> different hat on!)
>>
>> andreas: I have some slides to discuss on TextTrackCue
>> interface support for different formats in HTML5.
>> ... I would also point to the unconference session on
>> this on
>> Wednesday. They may also
>> ... want to log this as work that needs doing by a
>> Web & TV IG
>> task force.
>>
>> nigel: Good idea, let's do that ahead of my stuff on
>> AD, live
>> contribution etc.
>>
>> andreas: [Previews slides] including missing MIME
>> type on track
>> element in HTML5
>>
>> nigel: Thanks, let's do that after the TTWG update and
>> if
>> there's time to hand back to me for the other parts
>> then let's
>> do that.
>>
>> WebVTT stuff
>>
>> david: Number one priority is to find a new Chair to
>> cover this
>> topic - I've indicated already to
>> ... plh etc that I don't have the time to devote to
>> this.
>>
>> glenn: What's the status of implementation work?
>>
>> david: At Apple it's bug fixing, keeping up with
>> customers.
>>
>> glenn: On the Chrome and webkit list I don't see much
>> activity.
>> I am not following mozilla or Edge.
>> ... What's the status in other groups e.g. MPEG
>> referencing
>> WebVTT?
>>
>> david: The Chair does need to make progress on moving
>> it to Rec
>> so it can be normatively referenced.
>> ... There is implementation work excluding region
>> support in
>> many implementations.
>>
>> andreas: I think there have been updates to the
>> specification
>> that have not been reflected in
>> ... implementations so this is a problem.
>>
>> nigel: I've noticed that too - Simon made some really
>> good
>> changes around 10-11 months ago,
>> ... which i suspect have not been implemented. I'm
>> not sure
>> about the status of editing to
>> ... address the readability review feedback.
>>
>> david: Apple's implementations predate those changes.
>>
>> andreas: It's hard to know if those changes will ever
>> make it
>> into implementations.
>>
>> nigel: From a BBC perspective there are features that
>> are
>> essential for accessibility that look
>> ... like they would have to be put at risk for CR due
>> to lack
>> of implementation, so that would
>> ... be a "red flag" for me.
>> ... For example the BBC's editorial guidelines at
>> [16]http://bbc.github.io/subtitle-guidelines/
>> <http://bbc.github.io/subtitle-guidelines/>
>> <http://bbc.github.io/subtitle-guidelines/
>> <http://bbc.github.io/subtitle-guidelines/>>
>> ... cannot I believe be met by most implementations
>> of WebVTT
>> right now.
>>
>> [16] http://bbc.github.io/subtitle-guidelines/
>> <http://bbc.github.io/subtitle-guidelines/>
>> <http://bbc.github.io/subtitle-guidelines/
>> <http://bbc.github.io/subtitle-guidelines/>>
>>
>> action-475?
>>
>> <trackbot> action-475 -- Nigel Megitt to Contact the
>> chair of
>> the web & tv ig to ask about schedule and joint
>> meeting time.
>> -- due 2016-07-28 -- OPEN
>>
>> <trackbot>
>>
>> [17]http://www.w3.org/AudioVideo/TT/tracker/actions/475
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475>>
>>
>> [17]
>> http://www.w3.org/AudioVideo/TT/tracker/actions/475
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/475>>
>>
>> nigel: oops I meant:
>>
>> action-473?
>>
>> <trackbot> action-473 -- Thierry Michel to Contact
>> co-chairs
>> and essential parties on how to move forward on vtt;
>> need an
>> action plan -- due 2016-06-30 -- OPEN
>>
>> <trackbot>
>>
>> [18]http://www.w3.org/AudioVideo/TT/tracker/actions/473
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473>>
>>
>> [18]
>> http://www.w3.org/AudioVideo/TT/tracker/actions/473
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/473>>
>>
>> nigel: Thierry did this, but I don't believe we have
>> an action
>> plan.
>>
>> david: We need a suitable volunteer to go through the
>> review
>> comments and respond.
>>
>> thierry: The Community Group has looked into the review
>> feedback - about 30 comments
>> ... have been discussed: that's the current status.
>> Now those
>> comments need to be approved
>> ... by the TTWG (and discussed) and then we should
>> send those
>> responses to the commenters.
>> ... At some point we need to coordinate between the
>> CG and the
>> WG to progress those.
>> ... This has not changed for more than a year,
>> probably because
>> some people involved have
>> ... left and Simon does not participate actively in
>> the WG. We
>> are experiencing joint work with
>> ... a CG and a WG and we need to invent a process to
>> deal with
>> this.
>>
>> nigel: This works both ways - the WG also has not
>> scheduled any
>> effort to work on this.
>>
>> andreas: I'm not really convinced that the CG exists
>> as a
>> traditionally defined group.
>>
>> nigel: Shall we close the action? The "contact the
>> chairs" part
>> is done, we're missing an action plan.
>>
>> david: Leave it open.
>>
>> action-473: Discussed in TTWG F2F 2016-09-19 - need a
>> volunteer
>> to progress this, possibly a new Chair.
>>
>> <trackbot> Notes added to action-473 Contact
>> co-chairs and
>> essential parties on how to move forward on vtt; need
>> an action
>> plan.
>>
>> action-396?
>>
>> <trackbot> action-396 -- David Singer to Produce
>> evidence of
>> request for wide review for webvtt, for the archive
>> -- due
>> 2015-04-17 -- OPEN
>>
>> <trackbot>
>>
>> [19]http://www.w3.org/AudioVideo/TT/tracker/actions/396
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396>>
>>
>> [19]
>> http://www.w3.org/AudioVideo/TT/tracker/actions/396
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396>
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396
>> <http://www.w3.org/AudioVideo/TT/tracker/actions/396>>
>>
>> david: I have not yet done this.
>>
>> action-396: TTWG F2F meeting 2016-09-19: David has
>> not been
>> able to do this yet.
>>
>> <trackbot> Notes added to action-396 Produce evidence
>> of
>> request for wide review for webvtt, for the archive.
>>
>> nigel: TO be controversial/challenging, WebVTT has
>> been on our
>> Charter since 2013 and we
>> ... have made very little progress. Should we drop it?
>>
>> david: If we don't complete it in this Charter period
>> [end
>> March 2018] then we should not
>> ... recharter it - I propose that as a resolution.
>>
>> PROPOSAL: If we do not make progress on moving WebVTT
>> to
>> Recommendation in this Charter period we do not intend
>> to
>> include it on any rechartering.
>>
>> thierry: That's a final step - I think we should be
>> aiming to
>> move to CR well before that.
>>
>> david: I agree.
>>
>> glenn: We could publish it as a WG Note, to make it
>> easier for
>> external people to reference.
>>
>> nigel: This is a lot easier.
>>
>> thierry: That would probably be a final step to that
>> work.
>>
>> nigel: In fact publishing a Note is a process
>> requirement if we
>> stop working on it.
>>
>> thierry: We would do that if we removed it from the
>> Charter.
>>
>> glenn: It would be helpful to have a document that
>> does not
>> have the word "Draft" in it.
>>
>> thierry: I'm happy to help with the wide review;
>> that's one
>> thing. The second thing is the CR.
>> ... We could stay in CR for a couple of years and
>> monitor
>> implementation work, or we could
>> ... remove non-implemented features. Right now there
>> are a lot
>> of features that are not
>> ... implemented. That's something we could do in
>> parallel.
>> Maybe it is not useful to have
>> ... comments on features that we are likely to drop.
>>
>> nigel: I want to signal that if we have to drop
>> features that
>> are essential for accessibility then
>> ... I will have to object to it progressing.
>>
>> thierry: There's also a lack of specification text on
>> integrating CSS. We could maybe save time
>> ... by not addressing issues that we know are
>> unlikely to be
>> implemented in the next two years.
>>
>> group: discussion about who is interested in
>> contributing to
>> implementation work etc and therefore progressing
>> responses to
>> comments.
>>
>> RESOLUTION: If we do not move WebVTT to CR in this
>> Charter
>> period then we will not include it in any new Charter.
>>
>> andreas: We could mention the TTML to WebVTT mapping
>> document
>> in the Web & TV IG meeting.
>> ... We published it last year and are awaiting
>> implementation
>> comments. We are waiting for a
>> ... stable reference for WebVTT in order to proceed.
>>
>> thierry: You would expect to see at least a CR
>> document?
>>
>> andreas: CR would clearly indicate a stable set of
>> features you
>> can map against.
>>
>> Tagging
>>
>> david: DASH and the MP4 file format have a way to tag
>> the kind
>> of role of a track, using a URI
>> ... to identify the vocabulary used, and then a term
>> from that
>> vocabulary. I need a URI to
>> ... refer to the @kind vocabulary in the HTML5
>> specification,
>> and there isn't one.
>>
>> pierre: There is one but it is not complete,
>> specified in DASH.
>>
>> david: It is not specified in the HTML document itself.
>>
>> pierre: That's correct. As long as we can reference
>> the one in
>> DASH that can be used.
>>
>> david: Agreed there is a DASH vocabulary.
>>
>> pierre: So the request to add one to HTML is not
>> required for
>> MPEG CMAF because the DASH one can be used.
>>
>> david: I got agreement from WHATWG and the Web
>> Platform WG for
>> about:html-kind as the URI
>> ... that refers to the @kind vocabulary in the HTML
>> specification.
>> ... And I have registered that with IANA.
>> ... I'm waiting for that URI to appear in a revision
>> of the Web
>> Platform docs. When it is then
>> ... I will update the IANA form.
>>
>> nigel: It's good to have that but I would note that
>> in my view
>> the kind vocabulary is terrible.
>>
>> glenn: There are some semantics associated, such as
>> prevention
>> of display of metadata tracks by the UA.
>>
>> david: I would agree that the HTML vocabulary is both
>> under-
>> and over-specified simultaneously! (in different ways)
>>
>> nigel: In my view it is insufficiently rich to
>> describe the
>> purpose and intent of the track data.
>>
>> pierre: It would be great if as making the HTML
>> vocabulary more
>> official we could also fix it.
>>
>> david: I support that.
>> ... CMAF does prefer DASH at the moment - it says to
>> use the
>> DASH term if it supports what you want to do.
>>
>> nigel: I also note that we have not addressed how to
>> extract
>> something equivalent to kind
>> ... within a timed text document so that it can be
>> extracted
>> and used to embed into a host HTML page.
>> ... We did address language recently, but not kind.
>>
>> david: Some people want to manage external manifest
>> files, but
>> I'm in favour of self describing documents.
>> ... I'm also aware of ongoing discussions about tags
>> for easy
>> to read captions (mandated by FCC) and karaoke.
>>
>> pierre: There is a very specific definition of those
>> two terms
>> in karaoke.
>>
>> glenn: In TTML2 we have a named metadata item for
>> easy reader.
>> There's nothing on karaoke per se.
>> ... nothing that uses that term in TTML2.
>>
>> nigel: [adjourns for a break] - let's meet in
>> Auditorium IV at
>> 1100 for our update to Web & TV IG.
>>
>> <nigel_> nigel: Joint meeting - see #webtv
>>
>> TTML1 Errata
>>
>> nigel: Are there any other errata other than for
>> backgrounds on
>> spans and lines?
>>
>> pierre: The only thing I'd mention is that the
>> computed style
>> resolution for % is very well defined
>> ... but the computed style for em is not so clear
>> when you say
>> e.g. tts:fontSize="2em" but
>> ... that is with respect to the current font size but
>> that is
>> not well defined in TTML1. I assume
>> ... it is relative to the parent element's font size
>> but it
>> does not say that clearly.
>>
>> glenn: I would consult TTML1 and then go back and
>> reference
>> XSL-FO which would take me
>> ... to CSS2. Without having done a recent review of
>> that I
>> don't know off the top of my head
>> ... but I'm pretty sure you're right - it would have
>> to make
>> use of the computed font size of
>> ... the parent element.
>>
>> pierre: Notice that we already have issue #206 on the
>> ttml1
>> repo which is a bug about
>> ... specifying em units for fontSize on region.
>>
>> nigel: That sounds very similar.
>>
>> glenn: Right now there are 23 open issues on TTML1 so
>> I would
>> expect that there are some
>> ... errata to be written for those and they probably
>> also need
>> to be fixed in TTML 2 also.
>>
>> pierre: I can go ahead and create an issue for this.
>>
>> glenn: Go ahead - also refer to #206 - it may be
>> related but
>> more general.
>> ... I think I propose that it should be in relation
>> to 1c.
>>
>> pierre: That was my first thought, but looking at
>> XSL-FO I
>> think it is probably more like %.
>>
>> nigel: Okay, so the one on the agenda is:
>> [20]https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>
>> <https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>>
>>
>> [20] https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>
>> <https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>>
>>
>> andreas: I think there has not been much progress
>> since we last
>> discussed it. We said we need
>> ... more investigation to find a good solution. I
>> want to point
>> to something related.
>> ... This problem about gaps between lines has been
>> addressed by
>> the HbbTV 2.0.1 spec
>> ... which a lot of televisions will implement. At the
>> moment
>> that is not really interoperable
>> ... and compatible with IMSC 1 so we should pay
>> attention to
>> it.
>> ... References spec text from HbbTV 2.0.1 that,
>> specific to
>> EBU-TT-D 1.0 defines that
>> ... where the lineHeight is "normal" or <125% the
>> background of
>> each generated inline area
>> ... shall be rendered such that there are no gaps
>> between the
>> rendered backgrounds of
>> ... adjacent lines.
>>
>> glenn: We have a quasi default of doing what CSS
>> does, which is
>> different from what this suggests.
>> ... This mandates behaviour that is at variance with
>> the XSL-FO
>> and CSS behaviour.
>>
>> andreas: Yes.
>>
>> glenn: By the way issue #209 on the TTML spec has a
>> length
>> discussion on this.
>> ... The bottom line in my reading is that the height
>> of an
>> inline area in CSS is implementation defined.
>> ... Different implementations have fine tuned
>> themselves to be
>> consistent with each other, outside of any spec.
>>
>> nigel: You can see an editorial requirement example
>> of this at
>>
>> [21]http://bbc.github.io/subtitle-guidelines/#Background-size
>> <http://bbc.github.io/subtitle-guidelines/#Background-size>
>>
>> <http://bbc.github.io/subtitle-guidelines/#Background-size
>> <http://bbc.github.io/subtitle-guidelines/#Background-size>>
>>
>> [21]
>> http://bbc.github.io/subtitle-guidelines/#Background-size
>> <http://bbc.github.io/subtitle-guidelines/#Background-size>
>>
>> <http://bbc.github.io/subtitle-guidelines/#Background-size
>> <http://bbc.github.io/subtitle-guidelines/#Background-size>>
>>
>> glenn: I agree that we need to nail this down - also
>> see issue
>> #212 in TTML1.
>>
>> nigel: [22]https://github.com/w3c/ttml1/issues/212
>> <https://github.com/w3c/ttml1/issues/212>
>> <https://github.com/w3c/ttml1/issues/212
>> <https://github.com/w3c/ttml1/issues/212>>
>> ... [23]https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>
>> <https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>>
>>
>> [22] https://github.com/w3c/ttml1/issues/212
>> <https://github.com/w3c/ttml1/issues/212>
>> <https://github.com/w3c/ttml1/issues/212
>> <https://github.com/w3c/ttml1/issues/212>>
>> [23] https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>
>> <https://github.com/w3c/ttml1/issues/209
>> <https://github.com/w3c/ttml1/issues/209>>
>>
>> pierre: A browser based CSS implementation would
>> display a gap?
>>
>> glenn: Correct
>>
>> andreas: There are scripting techniques for getting
>> around
>> this.
>>
>> pierre: If we feel this is a common requirement for
>> accessibility then it needs to be addressed in the CSS
>> WG
>>
>> glenn: I've had a detailed offline discussion with
>> Bert Bos
>> about this and he pointed out that
>> ... one of the advanced level 4 modules might at some
>> point be
>> able to deal with this.
>> ... There are a whole bunch of assumptions in CSS on
>> inline
>> non-replaceable areas, for example
>> ... you cannot specify the content height manually.
>> The height
>> property explicitly does not
>> ... apply. That was the first problem we ran into,
>> because we
>> wanted the height of the content
>> ... box to extend to the line area. Somewhere I
>> proposed a mode
>> for the style engine to use
>> ... different semantics for the height of content
>> areas. The
>> question is can you have a profile
>> ... that defaults the parameter to a particular value.
>>
>> nigel: The pressing need here is to issue some
>> statement on
>> this for TTML1.
>>
>> piere: I recall that some people use a style where
>> they do
>> actually want the gap.
>>
>> andreas: yes, for example if you have the lineheight
>> at 200%
>> you don't want such a big background area.
>>
>> pierre: In CSS can you always add padding to every
>> line?
>>
>> glenn: You can but the problem is you cannot determine
>> at
>> authoring time what value to add.
>> ... At first order we should document more carefully
>> what the
>> current situation is in TTML1.
>> ... That may allow people to come up with no-gap
>> semantics. We
>> could define the default
>> ... semantics to be the no-gap scenario but if we do
>> that we
>> need to allow the author to define
>> ... the other behaviour. If we change the default now
>> what
>> would that break?
>>
>> nigel: I understand that the content rectangle is not
>> well
>> defined?
>>
>> glenn: It is not, but all the browser implementations
>> do it
>> roughly the same way.
>>
>> nigel: Could we add an informative note via an
>> erratum to say
>> that the content rectangle is
>> ... not well defined but is commonly implemented so
>> that it
>> does not go to the line height?
>>
>> pierre: That's not what I'm hearing. I think CSS needs
>> to
>> address this.
>>
>> glenn: I'm worried that we cannot easily go back and
>> retroactively define the content height
>> ... to never show a gap.
>>
>> pierre: It would be easier to do that if it were not
>> that some
>> folk like the gap.
>>
>> glenn: In TTML2 we can add a new mode that drives
>> that, but in
>> TTML1 what can we do?
>>
>> andreas: This requirement for no gaps came from
>> accessibility
>> guidelines to get proper presentation.
>> ... The minimum we could say is that some
>> specifications could
>> define this.
>>
>> pierre: If someone is overriding that rendering it
>> needs to be
>> flagged.
>>
>> andreas: That will not change, I think this is more of
>> an
>> interoperability problem.
>> ... There is an initial step e.g. for an IMSC 1.1,
>> and then a
>> long term TTML2 solution.
>> ... For now we should say something about this in
>> TTML1.
>>
>> pierre: +1
>>
>> andreas: I would also hope for a liaison to respond
>> to this.
>>
>> glenn: We can note that the algorithm for content
>> height is not
>> concretely defined and that
>> ... browsers do behave the same with current CSS
>> implementations and will introduce a gap.
>> ... If we do want a new TTML1 feature we could write
>> a short
>> specification introducing a
>> ... ttsx namespace style that is interpreted in a
>> particular
>> way.
>>
>> andreas: Ideally if there is a proper parameter to
>> control this
>> it should be defined in this group.
>>
>> nigel: +1
>>
>> glenn: That would be an official extension to TTML1,
>> which we
>> could say maps to a particular
>> ... syntax and semantic in TTML2.
>> ... That might be an approach.
>>
>> pierre: If there is an urgent need to address real
>> problems we
>> should address it in IMSC 1.1.
>>
>> glenn: I've heard 3 things: 1. Clarify TTML1 with an
>> errata -
>> we can do that non-controversially.
>> ... 2. We can define new mechanisms in TTML2 - we can
>> do that
>> no problem.
>> ... 3. More controversially, define a new extension
>> style for
>> TTML1. That creates another fork
>> ... in the implementation space.
>>
>> andreas: The target when this was discussed was an
>> IMSC 1.1
>> version. If that is possible we
>> ... should do that.
>>
>> pierre: Absolutely. The question is if there is an
>> urgent need
>> to resolve an industry problem now.
>> ... The worst thing would be to make a change that
>> does not
>> solve the problem.
>>
>> andreas: HbbTV has solved this for now - it would be
>> interesting to know if this breaks
>> ... current implementations.
>>
>> pierre: it would be good to have a formal
>> communication with
>> HbbTV about this issue.
>> ... It is essential that HbbTV is encouraged to
>> communicate
>> their requirements to this group and we should be
>> welcoming of
>> this, even if we make the initial communication.
>>
>> andreas: We should also be clear that it is needed for
>> interoperability to establish this communication
>> channel.
>>
>> nigel: Notes that independent of HbbTV the BBC raised
>> this
>> issue on TTML2 and andreas opened the equivalent on
>> TTML1.
>> ... I want to come back to what we can do here.
>>
>> andreas: There's the formal comms with HbbTV, an
>> errata for
>> TTML1, and a discussion about
>> ... how to fix for TTML2. If there is no formal
>> requirement for
>> this then it will not happen in IMSC 1.
>>
>> pierre: BBC has raised this for TTML2, but the
>> timescale for
>> that is very different than for TTML1.
>> ... To make a change on TTML1 requires a higher
>> threshold, so
>> if there is a group such as
>> ... HbbTV that needs this in the short term then we
>> should do
>> it.
>>
>> <scribe> ACTION: nigel Draft a liaison to HbbTV
>> requesting
>> further information and proposing an option e.g. to
>> extend IMSC
>> 1 to allow signalling of background height on span,
>> and request
>> timelines etc. [recorded in
>>
>> [24]http://www.w3.org/2016/09/19-tt-minutes.html#action01
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01>>]
>>
>> [24]
>> http://www.w3.org/2016/09/19-tt-minutes.html#action01
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01>
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01
>> <http://www.w3.org/2016/09/19-tt-minutes.html#action01>>]
>>
>> <trackbot> Created ACTION-478 - Draft a liaison to
>> hbbtv
>> requesting further information and proposing an
>> option e.g. to
>> extend imsc 1 to allow signalling of background
>> height on span,
>> and request timelines etc. [on Nigel Megitt - due
>> 2016-09-26].
>>
>> nigel: Okay, that works; I would also still like to
>> see the
>> erratum on TTML1 to provide the context
>> ... for any update to IMSC 1 to allow signalling this
>> behaviour.
>>
>> glenn: I have added a comment on the issue at
>>
>> [25]https://github.com/w3c/ttml1/issues/209#issuecomment-247973
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973>
>>
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973>>
>> 673
>>
>> [25]
>> https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973673>
>>
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973673
>> <https://github.com/w3c/ttml1/issues/209#issuecomment-247973673>>
>>
>> nigel: Thank you!
>>
>> glenn: Of course that doesn't explain what to do
>> about it, but
>> that's for
>> [26]https://github.com/w3c/ttml2/issues/150
>> <https://github.com/w3c/ttml2/issues/150>
>> <https://github.com/w3c/ttml2/issues/150
>> <https://github.com/w3c/ttml2/issues/150>>
>> ... We have consensus in TTLM2 to solve this?
>>
>> [26] https://github.com/w3c/ttml2/issues/150
>> <https://github.com/w3c/ttml2/issues/150>
>> <https://github.com/w3c/ttml2/issues/150
>> <https://github.com/w3c/ttml2/issues/150>>
>>
>> nigel: Yes please!
>>
>> glenn: I have a bpd content proposal where I define 7
>> possible
>> values.
>>
>> nigel: That may be more than we need - let's review.
>> ... Thanks for the good discussion everyone, let's
>> adjourn for
>> lunch and return at 1400.
>>
>> TTML2 Pull Requests
>>
>> nigel: First up,
>> [27]https://github.com/w3c/ttml2/pull/177
>> <https://github.com/w3c/ttml2/pull/177>
>> <https://github.com/w3c/ttml2/pull/177
>> <https://github.com/w3c/ttml2/pull/177>> Add
>> tts:background{Clip,Extent,Origin}
>>
>> [27] https://github.com/w3c/ttml2/pull/177
>> <https://github.com/w3c/ttml2/pull/177>
>> <https://github.com/w3c/ttml2/pull/177
>> <https://github.com/w3c/ttml2/pull/177>>
>>
>> glenn: This is for image rendering support - I missed
>> a couple
>> of items from CSS: there is
>> ... an editorial note to add them.
>> ... I ended up using backgroundExtent rather than
>> backgroundSize for consistency.
>>
>> nigel: Just a note on reviewing the PRs - they don't
>> include
>> the built HTML so it's hard to
>> ... review or diff. I'd like a CI tool to build the
>> HTML
>> automatically so we can review it.
>>
>> glenn: I could do the build and check in the built
>> HTML but
>> then on pulling I would have to
>> ... remove it and build it again for gh-pages.
>> ... I'll go ahead and make a change to make these
>> easier to
>> review.
>>
>> <glenn>
>>
>> [28]https://www.w3.org/TR/css3-background/#the-background-origi
>> <https://www.w3.org/TR/css3-background/#the-background-origi>
>>
>> <https://www.w3.org/TR/css3-background/#the-background-origi
>> <https://www.w3.org/TR/css3-background/#the-background-origi>>
>> n
>>
>> [28]
>> https://www.w3.org/TR/css3-background/#the-background-origin
>> <https://www.w3.org/TR/css3-background/#the-background-origin>
>>
>> <https://www.w3.org/TR/css3-background/#the-background-origin
>> <https://www.w3.org/TR/css3-background/#the-background-origin>>
>>
>> nigel: So now we have backgroundOrigin as well as
>> backgroundPosition?
>>
>> glenn: We may want to rename these!
>>
>> nigel: (notes that this looks analogous to origin and
>> position
>> but is not)
>>
>> glenn: backgroundOrigin defines where the background
>> is drawn
>> relative to the content.
>> ... This is as defined in CSS3 backgrounds and
>> borders - it's
>> the same semantic.
>> ... I took off the -box suffix that's on CSS3.
>>
>> nigel: I sense that there are some changes needed
>> here to clear
>> up the names and make them
>> ... less potentially confusing. Also I'd encourage
>> review of
>> this in the context of IMSC 2
>> ... if we want to support image placement in more
>> detail.
>>
>> pierre: This does not express how you would use SMPTE
>> background image in IMSC 1.
>>
>> glenn: That's actually mapped to the image element.
>>
>> pierre: yes.
>>
>> glenn: However we did define background image also in
>> TTML2 and
>> these attributes
>> ... I believe fully define the semantics for
>> background images.
>> ... In the case of a foreground image these don't come
>> up
>> because they define the content
>> ... rectangle. There's never a box in which to
>> position it -
>> that only applies when the image
>> ... is used for the background. Also bear in mind that
>> background images may be repeated
>> ... in x and y directions, which can never happen with
>> foreground images.
>> ... For foreground image size you would use bpd and
>> ipd rather
>> than backgroundExtent.
>> ... I need to think if it would ever be applicable to
>> have the
>> same semantic as backgroundExtent
>> ... on a foreground image. I want to see if CSS
>> allows that
>> property on the image element
>> ... in HTML and what does it mean.
>>
>> nigel: Just considering the use cases for this - one
>> that comes
>> to mind is the use of a
>> ... graduated fill background image that is animated
>> to move
>> along behind foreground text
>> ... for karaoke usage. Do these semantics support that?
>>
>> glenn: Yes I think you could animate the x and y
>> positions,
>> either discretely or continuous.
>>
>> nigel: The conclusions for the time being are 1) that
>> more
>> thinking is needed for the names
>> ... and 2) whether backgroundExtent can apply to
>> foreground
>> images.
>> ... For the hard of thinking, some example images etc
>> would
>> really help, since the terminology
>> ... has a lot of repetition that makes it hard to
>> understand
>> the differences.
>> ... I've added some notes to the issue.
>> ... Moving on to Add support for rounded borders by
>> introducing
>> <border-radii> compone…
>> ... [29]https://github.com/w3c/ttml2/pull/179
>> <https://github.com/w3c/ttml2/pull/179>
>> <https://github.com/w3c/ttml2/pull/179
>> <https://github.com/w3c/ttml2/pull/179>>
>>
>> [29] https://github.com/w3c/ttml2/pull/179
>> <https://github.com/w3c/ttml2/pull/179>
>> <https://github.com/w3c/ttml2/pull/179
>> <https://github.com/w3c/ttml2/pull/179>>
>>
>> nigel_and_glenn: [discussion of single value processor
>> semantics for border radii without consensus emerging]
>>
>> glenn: The more interesting case is the one raised in
>> the issue
>> [30]https://github.com/w3c/ttml2/issues/176
>> <https://github.com/w3c/ttml2/issues/176>
>> <https://github.com/w3c/ttml2/issues/176
>> <https://github.com/w3c/ttml2/issues/176>>
>>
>> [30] https://github.com/w3c/ttml2/issues/176
>> <https://github.com/w3c/ttml2/issues/176>
>> <https://github.com/w3c/ttml2/issues/176
>> <https://github.com/w3c/ttml2/issues/176>>
>>
>>
>
> ...
Received on Tuesday, 20 September 2016 21:41:16 UTC