- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 18 Aug 2010 08:42:04 +1000
On Thu, Aug 12, 2010 at 6:09 PM, Philip J?genstedt <philipj at opera.com>wrote: > On Thu, 12 Aug 2010 02:11:55 +0200, Silvia Pfeiffer < > silviapfeiffer1 at gmail.com> wrote: > > On Thu, Aug 12, 2010 at 1:26 AM, Philip J?genstedt <philipj at opera.com >> >wrote: >> >> On Wed, 11 Aug 2010 15:38:32 +0200, Silvia Pfeiffer < >>> silviapfeiffer1 at gmail.com> wrote: >>> >>> On Wed, Aug 11, 2010 at 10:30 PM, Philip J?genstedt <philipj at opera.com >>> >>>> >wrote: >>>> >>>> On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer < >>>> >>>>> silviapfeiffer1 at gmail.com> wrote: >>>>> >>>>> >>>>> Going with HTML in the cues, we either have to drop voices and inner >>>> >>>>> timestamps or invent new markup, as HTML can't express either. I don't >>>>> think >>>>> either of those are really good solutions, so right now I'm not >>>>> convinced >>>>> that reusing the innerHTML parser is a good way forward. >>>>> >>>>> >>>> >>>> I don't see a need for the voices - they already have markup in HTML, >>>> see >>>> above. But I do wonder about the timestamps. I'd much rather keep the >>>> innerHTML parser if we can, but I don't know enough about how the >>>> timestamps >>>> could be introduced in a non-breakable manner. Maybe with a data- >>>> attribute? >>>> Maybe <span data-t="00:00:02.100">...</span>? >>>> >>>> >>> data- attributes are reserved for use by scripts on the same page, but we >>> *could* of course introduce new elements or attributes for this purpose. >>> However, adding features to HTML only for use in WebSRT seems a bit odd. >>> >> >> >> I'd rather avoid adding features to HTML only for WebSRT. Ian turned the >> <timestamps> into ProcessingInstructions >> >> http://www.whatwg.org/specs/web-apps/current-work/websrt.html#websrt-cue-text-dom-construction-rules >> . >> Could we introduce something like <?t at="00:00:02.100"?> without >> breaking >> the innerHTML parser? >> > > It appears that the innerHTML parser in at least Opera and Firefox handles > PIs in some manner, see test at < > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/587> > Chrome and Safari don't though. > > However, it isn't valid HTML, validator.nu says "Saw <?. Probable cause: > Attempt to use an XML processing instruction in HTML. (XML processing > instructions are not supported in HTML.)" Yeah, so the only conforming solution is probably to use CSS3 transition-delay property. That may not be the most elegant solution, but it works. > OTOH, if you say that it will take a short time for popular software to >> start ignoring the extra WebSRT stuff, well, in this case they have >> implemented WebSRT support in its most basic form and then there is no >> problem any more anyway. They will then accept the new files and their >> extensions and mime types and there is explicit support rather than the >> dodgy question of whether these SRT files will provide crap or not. During >> a >> transition period, we will make all software that currently supports SRT >> become unstable and unreliable. I don't think that's the right way to deal >> with an existing ecosystem. Coming in as the big brother, claiming their >> underspecified format, throwing in incompatible features, and saying: just >> deal with it. It's just not the cavalier thing to do. >> > > I agree that it seems (and is) quite selfish, but am not sure the > alternatives are any better, see below. About "unstable and unreliable", I > think there are really only two kind of errors we will see: > > 1. Some cues being ignored due to trailing settings after the timestamp. > Some files may decide at this point that the files are not conformant and fail. > > 2. Markup being interpreted as plain text. > > Both already can and do happen with existing use of SRT, which is annoying > but better than no subtitles at all. It's a bit more than just annoying to users. If there are automated processes involved that print that stuff on tape for example, you can burn through a lot of material and money before realising that your input files are "broken" and if you cannot get software support for the new files implemented, you may need to implement costly manual checking of the files. > > The core "problem" is that WebSRT is far too compatible with existing SRT > usage. Regardless of the file extension and MIME type used, it's quite > improbable that anyone will have different parsers for the same format. Once > media players have been forced to handle the extra markup in WebSRT (e.g. by > ignoring it, as many already do) the two formats will be the same, and using > WebSRT markup in .srt files will just work, so that's what people will do. > We may avoid being seen as arrogant format-hijackers, but the end result is > two extensions and two different MIME types that mean exactly the same > thing. It actually burns down to the question: do we want the simple SRT format to survive as its own format and be something that people can rely upon as not having "weird stuff" in it - or do we not. I believe that it's important that it survives. WebSRT can have absolutely anything in it, including code and binary data, even if that stuff would not be interpreted in a browser, but handed on to the JavaScript API for a JavaScript routine to do something with it. It is a great extensible platform. But the advantage of SRT is that it is simple and reliably simple. We completely remove this option by stealing the format. > > > Since browser vendors get all the benefits and none of the problems it >>> would be a mistake to only listen to us, of course. It might be >>> worthwhile >>> contacting developers of applications like VLC, Totem or MPlayer and ask >>> precisely how annoyed they would be if suddenly one day they had to tweak >>> their SRT parser because of WebSRT. >>> >> >> >> Some of them have already spoken: >> http://forum.doom9.org/showthread.php?p=1396576 "Extending SRT is a very >> bad >> idea" etc etc. Also, I've had feedback from other subtitle professionals >> that are also against extending SRT, the main reasons being to break >> existing working software environments. >> > > The only way to really avoid messing with the ecosystem is to invent a > completely new format. The choice is between something that won't work at > all in non-browsers and something that will mostly work. If you look at it realistically, we *are* inventing a completely new format. WebSRT only on the surface has some resemblance with SRT. When you dig deeper, it is a completely different format with different aims and applications. Yes, it covers all the SRT aims and applications, but it does so much more! Only some of it will work in non-browsers, others will utterly fail and will completely disrupt an already working ecosystem. I think it may even have a really bad effect if we introduce WebSRT as SRT in that authoring software will refrain from implementing support for the richer features in order not to disrupt the existing software ecosystem. In the end we might end up with a lot of unsupported features in WebSRT an no real progress. I much prefer having progress with a transition period with conscious decisions to support the extra features. Cheers, Silvia. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100818/5720bcde/attachment-0001.htm>
Received on Tuesday, 17 August 2010 15:42:04 UTC