On Wed, 18 Aug 2010 00:42:04 +0200, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
On Thu, Aug 12, 2010 at 6:09 PM, Philip Jägenstedt
<phil...@opera.com>wrote:
On Thu, 12 Aug 2010 02:11:55 +0200, Silvia Pfeiffer <
silviapfeiff...@gmail.com> wrote:
On Thu, Aug 12, 2010 at 1:26 AM, Philip Jägenstedt <phil...@opera.com
>wrote:
On Wed, 11 Aug 2010 15:38:32 +0200, Silvia Pfeiffer <
silviapfeiff...@gmail.com> wrote:
On Wed, Aug 11, 2010 at 10:30 PM, Philip Jägenstedt
<phil...@opera.com
>wrote:
On Wed, 11 Aug 2010 01:43:01 +0200, Silvia Pfeiffer <
silviapfeiff...@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.
So, it seems clear that in order to use an HTML parser we have to
sacrifice some features or make them more verbose. The whole of the WebSRT
parser isn't very big or complicated, so I don't think implementation cost
is a strong argument for reusing the HTML parser, especially since at
least the timing syntax needs a separate parser.
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.
SRT as it is today can and does contain broken timestamps, missing
linebreaks and at least <i>, <b>, <u> and <font ...> markup, some of which
is broken. If anyone is able to to rely on their input as being
well-formed enough as to be put through automatic but costly processes,
they'd have to have very good control of where their input comes from. I
can't see how WebSRT would change that.
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.
I've collected some statistics on existing SRT content that I intend to
publish soonish. For now, I'll just note that >50% contain some form of
markup. Adding to this various ways in which the files could be broken, it
seems to me that SRT as deployed is neither really simple nor reliable.
Private use of SRT is of course simple and reliable, but that will be true
in the future too.
Aside: WebSRT can't contain binary data, only UTF-8 encoded text.
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.
As long as WebSRT is similar enough to SRT that software developers can
use the same parser for both, they will effectively become the same
format. If we define WebSRT in a way that can handle >99% of existing
content and degrade gracefully (enough) when using new features in old
software, it seems reasonable to do. If lots of software developers cry
foul, then perhaps we should reconsider. It seems to me, though, that
actually researching and defining a good algorithm for parsing SRT would
be of use to others than just browsers.
I'll be back with some statistics this weekend, hopefully.
--
Philip Jägenstedt
Core Developer
Opera Software
