Re: hyperlinks

On Sun, Nov 12, 2017 at 7:13 PM, Alice Wonder <alice@domblogger.net> wrote:

> On 11/12/2017 09:53 AM, Fredrik Söderquist wrote:
>
>> On Sun, Nov 12, 2017 at 5:42 PM, Alice Wonder <alice@domblogger.net
>> <mailto:alice@domblogger.net>> wrote:
>>
>>     On 11/12/2017 08:27 AM, Fredrik Söderquist wrote:
>>     *snip*
>>
>>
>>
>>         This is what should happen already per the "cue text parsing
>>         rules" [1].
>>         ("<a ...>" will be tokenized as a start tag 'a' with the
>> annotation
>>         'href="https://www.example.com"', and "</a>" as an end tag 'a'.
>> Both
>>         tokens will then be ignored by the parsing steps in [1].)
>>         This can be verified quite easily by checking what
>>         VTTCue.getCueAsHTML()
>>         returns. (If implementation don't show the text at all it would
>> seem
>>         they have a bug.)
>>
>>
>>     https://w3c.github.io/webvtt/#types-of-webvtt-cue-payload
>>     <https://w3c.github.io/webvtt/#types-of-webvtt-cue-payload>
>>
>>     does not indicate <a> is valid in a cue, an no online WebVTT
>>     validator I have used will validate a WebVTT file with an <a> in any
>>     of the cues.
>>
>>
>> What is valid (cue text) is orthogonal to what the cue text parser
>> considers - the WebVTT cue text parser is defined by a series of
>> algorithmic steps that produce those "zero or more WebVTT cue
>> components" that one can read about in the section you reference. Much
>> like HTML, for a WebVTT parser, input needn't be well-formed to produce
>> output. So "validity" would be an external requirement brought on by an
>> author, generator or similar.
>>
>>     Also, is VTTCue an API that is valid outside the scope of a browser
>>     page?
>>
>>
>> It's certainly "valid", but I wouldn't really expect to see it
>> implemented outside browser UAs. There should theoretically be nothing
>> preventing such an implementation though.
>>
>>
>> /fs
>>
>
> Web applications that accept user uploaded WebVTT files really need to
> stick to what is specified as allowed or they risk XSS and other code
> injection methods.
>

If a Web Application were to accept an "extended set" of cue components
they could indeed be susceptible to XSS and similar. This is, if possible,
even more important for "metadata" tracks where the cue payload is "free
format".

So if the specification doesn't specify hyperlinks then they really
> shouldn't be used. I don't see hyperlinks as part of the specification
> anywhere.
>

Being considered "bad practice" doesn't in any way prevent their use, and
as mentioned above, if following the WebVTT cue text parsing rules then the
text content will be preserved - which would seem to be a decent fallback.
Maybe hyperlinks will be part of a future version of the specification - it
seems very unlikely that it will do so using HTML attribute syntax. You can
raise a feature request at the WebVTT GitHub:
https://github.com/w3c/webvtt/issues/new


/fs