[whatwg] JavaScript function for closing tags

[Silvia Pfeiffer]

We could specify that WebVTT cues of type metadata should contain valid
JSON - that would make sense to me.

Cues of type captions or subtitles stupid get parsed dune by the addCue()
function of the texttrack API - but not all browsers implement this yet.
Would be worth registering bugs on browsers.

Cheers,
Silvia.

Best Regards,
Silvia.

On 18 Oct. 2017 2:51 am, "Michael A. Peters" <mpeters at domblogger.net> wrote:

> On 10/16/2017 10:08 AM, Roger Hågensen wrote:
>
>> On 2017-10-14 10:13, Michael A. Peters wrote:
>>
>>> I use TextTrack API but it's documention does not specify that it
>>> closes open tags within a cue, in fact I'm fairly certain it doesn't
>>> because some people use it for json and other related none tag related
>>> content.
>>>
>> Looking at https://www.html5rocks.com/en/tutorials/track/basics/
>> it seems JSON can be used, no idea if content type is different or not
>> for that.
>>
>> Some errors using the tracks in XML were solved by the innerHTML trick
>>> where I create a separate html document, append the cue, and then grab
>>> the innerHTML but that doesn't always work to close tags when html
>>> entities are part of the cue string.
>>>
>>
>> Mixing XML and HTML is not a good idea. Would it not be easier to have
>> the server send out proper XML instead of hTML? Valid XML is also valid
>> HTML (the reverse is not always true).
>>
>
> I agree, but what I was using an html document for - when using JS
> innerHTML it has closing tags so the only issue would be tags that html
> itself does not close (e.g. br) but those are not applicable with a WebVTT
> cue - which is only suppose to support a very small number of tags, all
> which have closing tags.
>
> The problem is WebVTT does not require tags be closed in a cue, e.g.
>
> 04:05.000 --> 04:07.250
> <c.foo>This is a cue.
>
> That's allowed in WebVTT
>
> I convert c.foo into
>
> <span class="foo">This is a cue.
>
> and when I add that to the html document and use innerHTML it then has the
> closing </span> on it.
>
> While it seems to work with some html entities, it breaks with others like
>  
>
> So for now I have to just make sure all my WebVTT are closed and not use
> the hack that adds closing tags - but since WebVTT cues do not have to have
> closing tags, but the cues need to work in XML documents, a built-in parser
> in JS that can add missing closing tags I think would be a good thing.
>
>
> And if XML and HTML is giving you issues then use JSON instead.
>> I did not see JSON mentioned in the W3C spec though.
>>
>
> I think the JSON in WebVTT cues is not spec but some are using it.
>
> Basically the textrack API seems to allow almost any string, it really has
> to as WebVTT is not static and the spec changes. I wouldn't mind JSON being
> added to WebVTT as it would be a handy way to encode metadata about the
> media but that's another topic.
>
> A built in JS HTML parser may also be of benefit in preventing code
> injection, e.g. stripping out tags from a WebVTT cue that a website does
> not allow.
>
> The TextTrack API doesn't filter out things like script or other tags that
> aren't part of WebVTT which means any site that allows users to upload
> WebVTT files is creating a potential code injection vulnerability.
>
> Server-side code should filter it on upload, but it would be nice to
> *someday* be able to pass a string through a native JS filter much the same
> way we can with htmltidy server-side and remove all but white-listed tags
> and attributes and get back a cleaned string with all tags closed.
>
> It looks like Google has a library that does that but it isn't intended
> for client-side JS and may not be fast enough for things like phones to
> process time-sensitive cues (I don't know).
>
> I might be wrong but it looked like the google library I found was
> intended for server-side Node.js use.
>
>