You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe I raised that informally somewhere but thought I'd capture it in a dedicated issue. WebVTT might seem to be using XML for cue text, but actually it does not! WebVTT defines its own syntax and parsing rules.
If I understood things correctly, this was done on purpose for multiple reasons, including ease of support on constrained devices (not having to include an XML parser library, not having to parse repeated XML fragments that may each define their own entities), ease of authoring (use of plain text whenever possible, use of tags only when needed), and security. People involved in WebVTT can probably clarify these reasons.
These reasons seem to apply to WebVMT as well. Unless you want a pure XML format (à la TTML), it may not be such as good idea to mix XML with plain text as currently written. In short, I'm wondering whether it wouldn't be better to use JSON instead of an XML-based structure for cue content.
Also, if WebVMT support remains up to Web applications, with cue content provided as a blob, XML makes web developers' life slightly more complex. In contrast, JSON is both easier to parse and process (just pass the text to JSON.parse to get a JS object that has the same structure).
The text was updated successfully, but these errors were encountered:
@tidoust Thanks for raising this. I'm thinking along similar lines after Monday's meeting.
My current feeling is that JSON is a better solution than XML for exactly the reasons you cite. The proposed WebVMT data structures can be implemented in JSON and read using JSON.parse as you suggest. I notice that WebVTT's metadata example uses JSON, so its designers also had this in mind.
I've considered a VMTML idea too (akin to TTML), but I'm shelving this for now to keep the original aim of mirroring WebVTT's design with a file linked to the <track> element.
It's important that we resolve this quickly and correctly, as I'm just about to start writing the file format in the Editor's Draft so that early adopters can begin to implement it.
I believe I raised that informally somewhere but thought I'd capture it in a dedicated issue. WebVTT might seem to be using XML for cue text, but actually it does not! WebVTT defines its own syntax and parsing rules.
If I understood things correctly, this was done on purpose for multiple reasons, including ease of support on constrained devices (not having to include an XML parser library, not having to parse repeated XML fragments that may each define their own entities), ease of authoring (use of plain text whenever possible, use of tags only when needed), and security. People involved in WebVTT can probably clarify these reasons.
These reasons seem to apply to WebVMT as well. Unless you want a pure XML format (à la TTML), it may not be such as good idea to mix XML with plain text as currently written. In short, I'm wondering whether it wouldn't be better to use JSON instead of an XML-based structure for cue content.
Also, if WebVMT support remains up to Web applications, with cue content provided as a blob, XML makes web developers' life slightly more complex. In contrast, JSON is both easier to parse and process (just pass the text to
JSON.parse
to get a JS object that has the same structure).The text was updated successfully, but these errors were encountered: