This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Things like the left-to-right mark (‎) and other such numbered escape characters should be supported in WebVTT cue text because they are the easy way to author UTF-8 characters.
I guess you mean to support both ‎ and ‎?
Why not just generally &#zzzz; ? Is there any need to restrict which hex values we support?
This sounds like a good idea. However, we can't manually convert every escape character to the character it represents like we're doing now with &, <, >, etc. So would we stop converting them all and let the browser handle it or would only convert certain ones?
(In reply to Silvia Pfeiffer from comment #2) > Why not just generally &#zzzz; ? Is there any need to restrict which hex > values we support? I was pointing out that there are two forms of escapes, decimal (‎) and hexadecimal (‎).
(In reply to Philip Jägenstedt from comment #4) > (In reply to Silvia Pfeiffer from comment #2) > > Why not just generally &#zzzz; ? Is there any need to restrict which hex > > values we support? > > I was pointing out that there are two forms of escapes, decimal (‎) > and hexadecimal (‎). Ah! Ha! Sure, both makes sense to me.
WebVTT now has ‎ and ‏, which was the case this was opened for. I'm taking the liberty of setting this to v2, but we can move it back to v1 if we have people in the trenches requesting more specific escapes than we want to add.
Relevant Blink review: https://codereview.chromium.org/150413005/
Why would anyone write decimal or hexadecimal escapes and not mean them to be resolved? IMHO we can move this to v1 and fix it now.
(In reply to Silvia Pfeiffer from comment #8) > Why would anyone write decimal or hexadecimal escapes and not mean them to > be resolved? The same can be said for *all* escapes that are allowed in HTML. I'll ask Anjali to comment on what prompted him to add this.
(In reply to Philip Jägenstedt from comment #9) > (In reply to Silvia Pfeiffer from comment #8) > > Why would anyone write decimal or hexadecimal escapes and not mean them to > > be resolved? > > The same can be said for *all* escapes that are allowed in HTML. Right. Limiting the supported entity names just made sense for authoring tools and non-browsers, IMHO.
*** Bug 28264 has been marked as a duplicate of this bug. ***
(adding www-international to this issue, which duplicates I18N-ISSUE-430)
(added widereview as it's a dup of 28264)
PR prepared https://github.com/w3c/webvtt/pull/198
Do we have concrete implementor support for this? I would accept it in Blink, but it's unlikely I'll get around to implementing it myself. Rick, interest in Gecko? Eric, Jer, interest in WebKit?
(In reply to Philip Jägenstedt from comment #15) > Do we have concrete implementor support for this? I would accept it in > Blink, but it's unlikely I'll get around to implementing it myself. > > Rick, interest in Gecko? > > Eric, Jer, interest in WebKit? Sure, seems reasonable.
https://github.com/w3c/webvtt/pull/253
we now rely on HTML character reference