[whatwg] SRT research: separating cues
I wanted to research how common it is to fail to separate cues in SRT, and for what reason. SRT parsers usually interpret a timings line as a new cue, while WebVTT wants two blank lines for a new cue. I took the 65k SRT files we've got, replaced comma with dot and prepended WEBVTT\n\n, then ran them in Opera's track impl, looking for '--' in cue data. There were 840 files with -- in cue data. This is 1.3% of the files. Looking at the cue data, there were 11,118 lines that contained --. There were 8830 lines of only whitespace. In the cue data, if I look at valid-looking timing lines (/^\d\d:\d\d:\d\d\.\d\d\d\s*--\s*\d\d:\d\d:\d\d\.\d\d\d(\s|$)/) and check the line before that, or the line before *that* if it looks like an SRT id (/^\d+\s*$/), then I see 7030 lines of only whitespace and 3761 lines of something else. Failing to separate cues results in an unpleasant experience for the user, since basically the screen is filled with several cues including their IDs and timing lines. Some files had most or all of their cues parsed as a single cue with the WebVTT parser, e.g. because all lines ended with one or more spaces. Looking at such a file in a text editor, it's not immediately obvious that there's an error, because the spaces are not visible. Moreover, the file is not non-conforming, so a validator wouldn't help either. So what about the cases that aren't whitespace? It seems to be mostly just missing the newline completely. Some omitted the ID also. One file had a | between all cues. -- Simon Pieters Opera Software
Re: [whatwg] Fullscreen revision I
On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com wrote: On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? Why should we allow this if nobody intents on implementing it? However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. I made this change for now to keep the initial version simple. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Fullscreen and event dispatch
Hi. The requestFullscreen steps tells to dispatch a fullscreenchange event on the context object, and all containing objects (frames). First, there should be a better clarification of 'context object'. While is remarked that it is the object used for the last requestFullScreen call which was allowed, it should also refer that for ancestor browsing contexts, it should be the containing frame. This way, fullscreening a contained document will work just as fine as any other kind of element reusing the same css, while for the containing document, it's transparent. Second, the requestFullscreen steps do not cope well if there is already a previous fullscreen element, either in the same document, or in a descendant, ancestor or sibling document. The steps tell to loop all the way up to the top level document and dispatch fullscreenchange events. I would suggest dispatching it *only* for elements and documents where there was a fullscreen change, so if we have a top level document A and a child B, B has two elements, a' and b'. Changing fullscreen from a' to b' would result in two fullscreenchange events, one for each element, inside B, while A should not get a event. I have some doubts if the spec allows this use case though, because the steps for requestFullscreen also mention that if an ancestor browsing context has a non-null fullscreen element, then it should not be allowed to proceed, but this restriction does not apply, again, to sibling elements, or sibling/descendant documents. Third, perhaps fullscreenchange should be split into fullscreenon and fullscreenoff events ?
Re: [whatwg] Fullscreen revision I
On Mon, Oct 24, 2011 at 6:38 AM, Anne van Kesteren ann...@opera.com wrote: On Fri, 21 Oct 2011 06:44:05 +0900, Chris Pearce cpea...@mozilla.com wrote: On 21/10/2011 4:10 a.m., Glenn Maynard wrote: The current spec doesn't seem to allow asking permission to fullscreen in advance, since the fullscreen element is set synchronously. This should be supported; there are a lot of potential problems with the ask-after model and it shouldn't be the only model supported. I agree, the spec should definitely allow this. We could make requestFullScreen()'s entire body run in a synchronous section, after any permission has been granted? Why should we allow this if nobody intents on implementing it? Doing this synchronously means nobody can ever implement ask-first. Don't permanently lock everyone into a permission scheme with known problems. It also seems odd that fullscreenElement is set synchronously, but fullscreenchange events are fired asynchronously. It would make more sense to do them together, from the same task (set all fullscreenElements first, then fire all fullscreenchange events). However, if we do end up not having requestFullscreen() while fullscreen swap the fullscreen element, then we need to ensure document.fullscreenEnabled returns false while any document is fullscreen. Otherwise video controls won't know to hide their (non-functioning) fullscreen buttons while their document/parent/ancestor documents are fullscreen. I made this change for now to keep the initial version simple. This is much more complicated for developers. If fullscreenEnabled can change, you have to monitor it to change UI (eg. show/hide fullscreen buttons). How is this simpler than just making requestFullscreen switch the fullscreen element? -- Glenn Maynard
Re: [whatwg] NUL characters in CDATA?
I'm responding to my own email here... Please disregard this thread: the bug was in my code, not the tests or the spec. (The tokenizer leaves the NUL characters in CDATA sections, but when those characters are inserted into foreign content (as they always are) the NUL characters are transformed as the tests expect. My code wasn't doing the transformation correctly.) David On 10/14/11 9:19 PM, David Flanagan wrote: The HTML parsing spec says this about tokenizing CDATA sections: Consume every character up to the next occurrence of the three character sequence U+005D RIGHT SQUARE BRACKET U+005D RIGHT SQUARE BRACKET U+003E GREATER-THAN SIGN (|]]|), or the end of the file (EOF), whichever comes first. Emit a series of character tokens consisting of all the characters consumed except the matching three character sequence at the end (if one was found before the end of the file). By my reading, if there are NUL \u characters in the input inside a CDATA section they will be left unchanged. But the html5lib test suite includes this test case testdata/tree-construction/plain-text-unsafe.dat: #data svg![CDATA[\ufiller\utext\u]] #errors #document | html | head | body | svg svg | \uFFFDfiller\uFFFDtext\uFFFD In order to copy this test into my email window, I had to change the non-printing characters to Unicode \u escapes, but this is the basic test data and it seems to contradict the spec. Which is right? Should the spec be modified so that the CDATA section state is like the bogus comment state and includes the text with any U+ NULL characters replaced by U+FFFD REPLACEMENT CHARACTER characters.? Thanks, David
Re: [whatwg] Suggestion for HTML5 context menus
On Mon, Oct 24, 2011 at 5:50 AM, Mark Callow callow_m...@hicorp.co.jpwrote: On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). Is there a way for the user to access the regular context menu? I could imagine it being extremely irritating and even frustrating if one can't access familiar and useful items like Copy link location, Bookmark this page or Select all because the author of some element on the page has decided to redesign the context menu. Regards -Mark In firefox you can Shift+Right-Click to show the default context menu. So you are given multiple options: 1. Disallow websites to change and hide the contextmenu at all 2. Show the default context menu with a Shift+Right-Click So I don't see what is the problem? other UA's must face this in a way they choose and any complaints about this is to them. On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). I don't see this in firefox, I tried the nodefault=true as in the w3 bug tracker but that doesn't do anything. Are you sure that it was really added and if so why isn't it in this example: https://bug617528.bugzilla.mozilla.org/attachment.cgi?id=554309 Regards, Eric
Re: [whatwg] Normalization of user selections
On Tue, Jun 28, 2011 at 1:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: I've updated the spec to require this: https://bitbucket.org/ms2ger/dom-range/changeset/b9ca1640aeee http://html5.org/specs/dom-range.html#apis-for-the-browsing-context-selection:-the-selection-interface The boundary points of a selection's range must now always be a Text or Element node that descends from a Document. Trying to call collapse(), extend(), selectAllChildren(), or addRange() in a way that would make a boundary point not a Text or Element node will throw INVALID_NODE_TYPE_ERR, and trying to make it a node that doesn't descend from a Document will throw INVALID_MODIFICATION_ERR. I'll add more specific constraints on user-created selections later. Does anyone think this is a bad approach? If so, feedback would be appreciated. I eventually reverted this change: http://dvcs.w3.org/hg/editing/rev/f8c262d61ccc The reasons are explained in the commit diff. I couldn't get away with saying Selection endpoints can't be Comments or such unless I defined what to do to the Selection if one of its Ranges changed, such as due to a DOM mutation. That would be a lot more complicated than just speccing the IE/Gecko behavior, it wouldn't match any browsers, and it would add only dubious utility. So now the spec matches IE/Gecko again -- any Range can be passed to addRange(), and a reference to that Range will be added to the Selection.
Re: [whatwg] Suggestion for HTML5 context menus
On Mon, Oct 24, 2011 at 10:14 AM, Eric Sh. shedok...@gmail.com wrote: On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). I don't see this in firefox, I tried the nodefault=true as in the w3 bug tracker but that doesn't do anything. Are you sure that it was really added and if so why isn't it in this example: https://bug617528.bugzilla.mozilla.org/attachment.cgi?id=554309 My memory could be wrong. cc'ing Jan who implemented what we currently have. / Jonas
Re: [whatwg] SRT research: separating cues
So, in your opinion, should there be a change to the WebVTT spec that separates cues differently? Is there a recommendation you have from your analysis? Cheers, Silvia. On Mon, Oct 24, 2011 at 6:26 PM, Simon Pieters sim...@opera.com wrote: I wanted to research how common it is to fail to separate cues in SRT, and for what reason. SRT parsers usually interpret a timings line as a new cue, while WebVTT wants two blank lines for a new cue. I took the 65k SRT files we've got, replaced comma with dot and prepended WEBVTT\n\n, then ran them in Opera's track impl, looking for '--' in cue data. There were 840 files with -- in cue data. This is 1.3% of the files. Looking at the cue data, there were 11,118 lines that contained --. There were 8830 lines of only whitespace. In the cue data, if I look at valid-looking timing lines (/^\d\d:\d\d:\d\d\.\d\d\d\s*--\s*\d\d:\d\d:\d\d\.\d\d\d(\s|$)/) and check the line before that, or the line before *that* if it looks like an SRT id (/^\d+\s*$/), then I see 7030 lines of only whitespace and 3761 lines of something else. Failing to separate cues results in an unpleasant experience for the user, since basically the screen is filled with several cues including their IDs and timing lines. Some files had most or all of their cues parsed as a single cue with the WebVTT parser, e.g. because all lines ended with one or more spaces. Looking at such a file in a text editor, it's not immediately obvious that there's an error, because the spaces are not visible. Moreover, the file is not non-conforming, so a validator wouldn't help either. So what about the cases that aren't whitespace? It seems to be mostly just missing the newline completely. Some omitted the ID also. One file had a | between all cues. -- Simon Pieters Opera Software
Re: [whatwg] Suggestion for HTML5 context menus
On Mon, Oct 24, 2011 at 12:22 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Oct 24, 2011 at 10:14 AM, Eric Sh. shedok...@gmail.com wrote: On 23/10/2011 08:35, Jonas Sicking wrote: We added support for this in firefox, so you can get the behavior you want there in the meantime (I forget what we called the attribute though). I don't see this in firefox, I tried the nodefault=true as in the w3 bug tracker but that doesn't do anything. Are you sure that it was really added and if so why isn't it in this example: https://bug617528.bugzilla.mozilla.org/attachment.cgi?id=554309 My memory could be wrong. cc'ing Jan who implemented what we currently have. In case his email didn't go through to the list. Apparently this feature was removed before landing the patch due to not being in spec. And the spec writer has marked the bug as LATER waiting for implementation experience. So it appears that we're dead-locked currently. / Jonas
Re: [whatwg] Fullscreen and event dispatch
On Mon, 24 Oct 2011 20:42:18 +0900, João Eiras jo...@opera.com wrote: The requestFullscreen steps tells to dispatch a fullscreenchange event on the context object, and all containing objects (frames). Actually, it says on the context object and all ancestor browsing context's documents. We could change it to always dispatch on the fullscreen element, I guess that might be better. First, there should be a better clarification of 'context object'. While is remarked that it is the object used for the last requestFullScreen call which was allowed, it should also refer that for ancestor browsing contexts, it should be the containing frame. This way, fullscreening a contained document will work just as fine as any other kind of element reusing the same css, while for the containing document, it's transparent. No, context object is the object on which the method is called. The others objects are defined separately. Second, the requestFullscreen steps do not cope well if there is already a previous fullscreen element, either in the same document, or in a descendant, ancestor or sibling document. The steps tell to loop all the way up to the top level document and dispatch fullscreenchange events. Actually, if there a fullscreen element already you will get a fullscreenerror event. I would suggest dispatching it *only* for elements and documents where there was a fullscreen change, so if we have a top level document A and a child B, B has two elements, a' and b'. Changing fullscreen from a' to b' would result in two fullscreenchange events, one for each element, inside B, while A should not get a event. I have some doubts if the spec allows this use case though, because the steps for requestFullscreen also mention that if an ancestor browsing context has a non-null fullscreen element, then it should not be allowed to proceed, but this restriction does not apply, again, to sibling elements, or sibling/descendant documents. Why would it not? The top-level browsing context will always have a non-null fullscreen element if something is fullscreen. Third, perhaps fullscreenchange should be split into fullscreenon and fullscreenoff events? What are the use cases to distinguish them? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fullscreen revision I
On Tue, 25 Oct 2011 00:32:43 +0900, Glenn Maynard gl...@zewt.org wrote: Doing this synchronously means nobody can ever implement ask-first. Don't permanently lock everyone into a permission scheme with known problems. Since the events are not dispatched synchronously I think we should always be able to change. It also seems odd that fullscreenElement is set synchronously, but fullscreenchange events are fired asynchronously. It would make more sense to do them together, from the same task (set all fullscreenElements first, then fire all fullscreenchange events). 1) You want them to be set so when the UA does its transition it knows what to transition to. 2) You cannot set them all from the same task because that would not work for non same-origin documents. This is much more complicated for developers. If fullscreenEnabled can change, you have to monitor it to change UI (eg. show/hide fullscreen buttons). How is this simpler than just making requestFullscreen switch the fullscreen element? If you allow changing the fullscreen element you need to track what documents changed, dispatch events as appropriate, and you keep the problem that exiting exits everything which is quite odd. -- Anne van Kesteren http://annevankesteren.nl/
