- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 23 Mar 2011 00:02:07 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Sean Hayes <Sean.Hayes@microsoft.com>, Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
On Tue, Mar 22, 2011 at 11:28 PM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 23 Mar 2011, Sean Hayes wrote: >> >> Since it is marked as destined for a CSS editor, it seems that at least >> in the past this idea of "fix at time of layout and avoid overlaps" was >> deemed to be in scope for CSS. > > Where in the platform it is specified seems irrelevant to the technical > aspects of what it says. > > >> There is no indication that A and C are from different caption sources > > They're not, they're just overlapping cues from the same source. The setup > I describe is very common in anime subtitling and is one of the commen > forms of karaoke display. > > > (FWIW, it would also make sense to support scrolling cues in this kind of > scenario -- in fact this is the style prevailing in US TV captioning > systems -- but the same arguments against your proposal apply with that > kind of overlap-handling too.) For the record: I think when cues overlap in time and are on the same track, they should be scrolled in from the bottom. That's what roll-up captions do and it's also the natural reading-direction of users. I agree, I have seen it done differently for Karaoke, but not all Karaoke works that way and not everyone agrees that it's a good user experience. In fact, most people get confused by it the first time they see that happen (I speak from anecdotal personal experience here). An alternative approach to scrolling - if we want to avoid overlapping - would be to replace the captions that are there with the new ones. That's in fact what pop-up captions do - there is no time overlap in pop-up captions and therefore no movement. But I would leave this functionality to the authors, who need to decide whether they want scrolling (and therefore time-overlap) or not (and therefore cannot have time-overlap). Cheers, Silvia.
Received on Wednesday, 23 March 2011 07:02:59 UTC