Re: File headers

On Mon, Mar 18, 2013 at 1:39 PM, David Singer <singer@apple.com> wrote:

>  agreed.  if we don't like escaping blank lines, don't have them. it's no
> harder to remove them than it is to insert the escape.
>

I've explained why supporting blank lines is useful.  It's something the
world will live with and tolerate if we force it on them, but the UX (or
perhaps AX--authoring experience) will be poor.

A) All headers are single-line.  Result: you want a short file-specific
> style sheet, either write it on one line, or put it in a separate file.
>

Forcing people to write stylesheets on a single line is a painful option to
consider.  In my opinion, the options are either 1: don't allow inline
stylesheets of any kind, or 2: allow them and don't force them to be
flattened to a single line.  If inline stylesheets are useful enough to
support, they're useful enough to support without obfuscation.


> C) Headers are multi-line, and blank lines and lines that emulate the
> terminator are escaped.  Result: when you in-line something, you have to
> look at it and maybe fix it up (or have a tool that does that
> automatically).
>

Again, if you paste text into a WebVTT header that might contain blank
lines, you will always have to fix it up.

&escapes; are needed to allow the string --> anyway (I hope we're not
seriously considering creating a file format that can't represent that
series of characters in a header --> at all <--), and it means that when
users enter text into a WebVTT editor, newlines don't obnoxiously disappear.

On Tue, Mar 19, 2013 at 4:23 PM, David Singer <singer@apple.com> wrote:

> Right.  If we go with only single-line headers, and leave multi-line until
> we Know How to Do It Right, can we still do inline CSS?  Yes, we can.  A
> syntactically valid CSS file can have its line breaks replaced by other
> whitespace.  (An invalid one might become valid, but that doesn't worry us.)
>

If we can't find a better method now, we won't in the future, since it'll
only become exponentially harder as legacy data and parsers show up in the
wild and the options become restricted.  I think in this case "we'll solve
this later" means "we'll never do this at all", so let's make the right
decision now while we can.

-- 
Glenn Maynard