- From: Sean Hayes <Sean.Hayes@microsoft.com>
- Date: Wed, 23 Mar 2011 10:18:46 +0000
- To: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
Placement of multiple captions that overlap in time in a single source is of course definitely required. Provided the author has a way to turn this behavior off and provide typical pop on and rollup type captioning, then I'd have no issue with this behavior within an individual formats layout rules and could see it getting used as a caption format. If not then I think it would be seriously deficient and unlikely to be adopted for that purpose. I simply don’t think it should be the behavior for combining multiple sources. It's confusing and inefficient for the end reader. -----Original Message----- From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Philip Jägenstedt Sent: 23 March 2011 09:53 To: public-html@w3.org Subject: Re: Change proposals for issue-152 On Tue, 22 Mar 2011 21:47:05 +0100, Sean Hayes <Sean.Hayes@microsoft.com> wrote: > Philip: "Having one caption jump around because another becomes visible > or is hidden would be rather annoying, don't you think? As far as I can > tell, the example you provided would suffer from this problem." > > -- right, as I said I think the 80%+ use case is a fixed rectangle in a > fixed place, and probably the majority of the remaining cases a fixed > size rectangle in a flow layout, I only offered the example to show it > could be done, not that it was an example of best practice; I will note > that rollup captioning is "captions jumping around" so there is > something of a precedent, although that would be for a single source. Note that the rendering section is not just for handling overlapping captions between different tracks, it also does the same for overlapping cues within the same track. When two speakers are talking at the same time but the start and end times of their cues are not exactly aligned, having the cues jump around wouldn't be very nice. Do you consider that to also not be a use case worth solving? > Philip: "I somewhat agree with this. To the fullest extent possible, we > should reuse CSS. However, I'm not convinced that it's actually > possible in this case, given that CSS is stateless and can have no > memory of captions that are no longer showing." > > I think you need to distinguish between using style to position the area > where the captions will appear, and the style applied to the cues > themselves within that area. I'm really only talking about the first > case here, The style applied to position the rendering area for the cues > does not need to know the state. The state is only required in the > second case and that is down to the rules for rendering the captions > within the given rectangle, and avoiding overlap there is pretty much > orthogonal to this discussion. > > I don’t think there is a lot of merit in designing a complicated layout > system that combines two or more caption sources into a single display, > as that seems like an edge case to me. In cases where it was actually > necessary the author could use getCuesAsHTML and combine the contents > manually. See above, it does the same for overlapping cues in a single track, that it is also able to do something nice for multiple tracks comes as an added bonus with little additional implementation complexity. -- Philip Jägenstedt Core Developer Opera Software
Received on Wednesday, 23 March 2011 10:19:23 UTC