Re: [whatwg] eventsource/RemoteEventSource wierdness
On Tue, 17 Feb 2009, Jonas Sicking wrote: So it was brought to my attention that the RemoteEventTarget interface is intended to be implemented on all objects that implement EventTarget. This seems like it's adding a high level of complexity to me. [...] Finally, I do question the need for this API at all. Originally it was developed to allow for the messaging channel to be things like SMS or iPhone-push type channels. I.e. in environments where it's very expensive to keep a channel open, but where two-way communication already exists, it would be great to be able to use that existing channel to push messages from the server to the web page. However as far as I know no-one has taken the time to make RemoteEventTarget or eventsource work with neither SMS or iPhone push. If I'm wrong please do let us know so that this information can be added to the spec. So I would recommend the following: 1. Remove the whole feature unless someone can show how to make it work for SMS or iPhone push. 2. If we're really keeping it, remove eventsource and the requirement that RemoteEventTarget be implemented by all EventTargets. Instead create a dedicated object that implements RemoteEventTarget. On Wed, 18 Feb 2009, Kornel Lesinski wrote: I like the concept and find it useful. I think existence of Comet[1] is a proof that such feature is desired, even without support for SMS. Implementation of Comet via XHR is tricky, especially robust error handling is difficult. JS libraries can't have best implementation of event streams, because JS doesn't have enough control over network connections (e.g. can't bypass proxy if it doesn't handle long-lived connections well). Native browser implementations can excel here. One key feature that IMHO is needed in this area is sharing of events between pages/windows - e.g. page with stock ticker doesn't need separate stream for every page in every window. One permanent connection shared between windows and kept alive between page reloads would be sufficient, and would save both client and server resources and wouldn't have problems with HTTP/1.1 connections limit. 1. I think that such feature is needed and event source should be kept in some form. 2. I wouldn't mind if event source API was redesigned, made JS-only (without DOM), moved to separate specification or merged with XHR/web sockets. 3. Connection sharing is needed to make it a killer feature. Based on the above feedback and other feedback not quoted above, I've redesigned the event source feature to use an object instead of an element and a generic API. As always, feedback on this is welcome! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Synchronized play/seek of multiple audio elements?
On Thu, 19 Feb 2009, Biju g...@il wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. I wish this exist for VIDEO tag also. On Firefox nightly the situation is even worse due to https://bugzilla.mozilla.org/show_bug.cgi?id=476371 One solution is watching timeupdate event on all items and .pause() and .play() to make every thing in sync. This really isn't a supported use case right now -- for this kind of thing, SMIL (e.g. in SVG) is the expected way to do it. It's on the list of things to consider in the future, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media load algorithm feedback
On Wed, 25 Feb 2009, Chris Pearce wrote: We now have three things called load. The load() method, the load algorithm, and the resource-load algorithm. It might be clearer if they were called the load() method, the resource selection algorithm, and the resource fetch algorithm. Done and done. From the using source elements load algorithm sub-step: /Search loop:/ Run these substeps atomically (so that the DOM cannot change while they are running): 1. If the node after pointer is the end of the list, then jump to the step below labeled /waiting/. [...] 7. Waiting: Set the error attribute to a new MediaError object whose code attribute is set to MEDIA_ERR_NONE_SUPPORTED. 8. Set the element's networkState attribute to the NETWORK_NO_SOURCE value 9. Queue a task to fire a progress event called error at the media element. 10. Set the element's delaying-the-load-event flag to false. This stops delaying the load event. 11. Wait until the node after pointer is a node other than the end of the list. (This step might wait forever.) There's no step 12; I think the intention is that we return to the Search loop, but it's not documented. Oops. Fixed. Step 1 of the load algorithm: 1. While the media element has neither a src attribute nor any source element children, wait. (This steps might wait forever.) And further down it says: If a media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element whose |networkState http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-networkstate| has the value |NETWORK_EMPTY http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-media-network_empty| is inserted into a document http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#insert-an-element-into-a-document, the user agent must asynchronously invoke the media element http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#media-element's load algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-algorithm. I think that should be invoke the load() method? If it's invoke the load() method, running load() will cancel any already running instance of the load algorithm - e.g. any load which is waiting at step 1 of the load algorithm. As it's written, the load /algorithm /will be invoked, which will not cancel any waiting loads, and it could in fact it create another instance of the load algorithm waiting at step 1 of the load algorithm. So we would create two concurrent instances of the load algorithm, both waiting at step 1 of the load algorithm by doing the following: var v = document.createVideo(); v.load(); document.body.appendElement(v); Setting v.src or adding a source child element to v will awaken two instances of the load /algorithm. Oops. The resource selection algorithm (previously, load algorithm) was supposed to immediately set the readyState to something other than NETWORK_EMPTY so that this couldn't happen, but I added the spin loop step late in the process to handle the case where there was neither src= nor source so as to not preclude either being added later, and forgot to keep that invariant. I've fixed it now -- if the spin loop is to run, it first sets the readyState to NETWORK_NO_SOURCE as if it had run through and failed to find a media resource. /Other than that, the media load spec seems sensible. Cool. Thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Author control over media preloading/buffering
On Wed, 25 Feb 2009, Robert O'Callahan wrote: Under Once enough of the media data has been fetched to determine the duration of the media resource, its dimensions, and other metadata, after setting the state to HAVE_METADATA, steps 7 and 8 say 7. Set the element's delaying-the-load-event flag to false. This stops delaying the load event. 8. This is the point at which a user agent that is attempting to reduce network usage while still fetching the metadata for each media resource would stop buffering, causing the networkState attribute to switch to the NETWORK_IDLE value, if the media element did not have an autobuffer or autoplay attribute. I suggested HAVE_CURRENT_DATA would be a better state for these actions, and I still think so. These actions should not occur until the UA is able to display the first frame of the video. Authors would want the first frame of a non-autobuffered video to be visible, and the document load event should fire after the first frame is available by analogy with images. I've updated the note as per your suggestion. Is there a particular reason why you think these things should happen at HAVE_METADATA? It was an oversight. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking mark III
Apologies in advance if this covers old ground, it appears I missed some e-mails in the last round of e-mails about this topic. On Tue, 30 Dec 2008, Anne van Kesteren wrote: Opera wants to support this feature as well in due course, so I don't think we would mind it being added to HTML5. Does it being in Chrome mean it is also WebKit? If so, together with Firefox support, seems like a compelling reason to add the feature. On Tue, 30 Dec 2008, Maciej Stachowiak wrote: The Google Chrome team has not submitted patches for such a feature to WebKit. I am not sure if they plan to eventually submit it to mainline WebKit. In fact, this is the first I've heard about Chrome having such an extension. It's not clear to me whether the feature is useful without seeing some motivating examples. WebKit by default spellchecks (and grammar checks) all editable parts of the document, and it is not obvious to me why one would want to force it off for particular form controls or editable HTML areas. On Tue, 30 Dec 2008, Tab Atkins Jr. wrote: Agreed. This feature lives purely in user-space. It can be convenient for a user to be able to turn off spellchecking globally, or perhaps even locally (FF exposes this currently through a right-click option on editable areas), but I cannot see any reason for an author to have control over this. If I want to spellcheck an area, I want to spellcheck it. If I don't, I don't. On Tue, 30 Dec 2008, Kornel Lesi�~Dski wrote: It's useful for fields that contain non-textual content, e.g. product ID, license plate number, CAPTCHA answer, etc. Browser would mark these as misspelt, which might be confusing or at least distracting. [snip more discussion back and forth about whether it's a good idea or not, or whether we could come up with some heuristics for it instead] Based on the interest (not uniform interest, but interest nonetheless) on this topic, I've left the feature in the spec. I don't think that heuristics would work -- in practice, little distinguishes the subject line from the To: line in GMail, for instance, but one wants spell checking and the other does not. On Wed, 31 Dec 2008, Maciej Stachowiak wrote: The proposal Hixie linked seems way overengineered for this purpose. Yeah, it's certainly not the simplest thing that could have been invented, I'll give you that. First, it allows spellchecking to be explicitly turned on, potentially overriding normal defaults, but that seems wrong; an input type=email should never spellcheck regardless of the page author says. The user agent is allowed to override the author here, if desired. The applicability to input type=email fields is mostly just a side-effect of the attribute applying to everything, which is because we want it to apply to contentEditable. The true state is so that subparts of contentEditable fields can have checking enabled when outer parts have it disabled. I can't see any valid use case for the author turning spellchecking on regardless of UA defaults or user preferences. Second, it allows spellchecking to be controlled at a finer granularity than editability, for which again I think there is no valid use case. Both of these aspects make the feature more complicated to implement and harder to understand, compared to just having a way to only disable spellchecking at the same granularity as editing. In contentEditable, it's easy to imagine that some parts shouldn't be spellchecked when others should, e.g. the editor might introduce a URL and not want that checked. On Wed, 31 Dec 2008, Kornel Lesi�~Dski wrote: I don't like current proposal either, because true/false value is inconsistent with other boolean attributes in HTML. It's consistent with contentEditable, which it's intended to be used with. IMHO it should be nospellcheck=nospellcheck (which also solves problem of forcing spellchecking where it doesn't make sense). That's a pretty ugly attribute name, though. On Thu, 1 Jan 2009, Robert O'Callahan wrote: A use case is editable program code, where spellchecking is disabled, but where spellchecking is enabled inside comments. Maybe that sounds a little far-fetched for today's Web applications, but some IDEs (e.g. Eclipse) support this so it seems like something we'd want in the future. BeSpin, for instance, might want this, if they ever switch from canvas to contentEditable. On Wed, 31 Dec 2008, Maciej Stachowiak wrote: So I don't think this makes for a very compelling use case. It's like arguing for a page layout feature based on something only WordPerfect does. I agree that it seems a bit overpowerful. Experience from Gecko suggests it's not all that bad though. On Sat, 14 Feb 2009, Kristof Zelechovski wrote: The following sentences are *commands* that refer to browser actions: Let automatic completion be turned _on_. (command) Let spell checking be turned
Re: [whatwg] Synchronized play/seek of multiple audio elements?
On Thu, 19 Feb 2009 01:43:22 -, David Singer sin...@apple.com wrote: At 10:20 + 18/02/09, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. Yes. We felt it would be a major complication to the spec., and wanted to keep things simple for the first iteration. A problem arises for accessibility, when you extend this to video and need to synchronise captions / subtitles / audio descriptions, if they are not included in the original resource. There are various use cases for having the resource be stand-alone, and also for compound resources that HTML5 can pull together. At the FOMS discussion of accessibility, I believe the end result was an understanding (no formal resolution) that both approaches needed to be supported. This could be done in HTML5 by recommending something like a SMIL resource to deal with the second use case, shifting the implementation requirement to support (at least some of) SMIL for playing video. Or by adding some simple timing stuff to HTML itself, although that makes for backwards incompatibility even with current browsers having native video support. Or using SVG and pegging its timeline to the enclosing video, or ... These are not ready-made solutions, they are thoughts about possible approaches. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Synchronized play/seek of multiple audio elements?
On Thu, 26 Feb 2009, Charles McCathieNevile wrote: A problem arises for accessibility, when you extend this to video and need to synchronise captions / subtitles / audio descriptions, if they are not included in the original resource. Actually those should be handled pretty well by the current cue range mechanism. It's an easier problem than syncing video because you can be one or two frames off without any serious consequences. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
