[whatwg] Spec should require UAs to have control to mute/ pause audio/ video
This may already be in the spec, but I couldn't find it. I think the spec should explicity require UAs to provide a mehanism to mute audio and to pause video, even if the controls attribute is not set. This will be of great benefit to screenreader users, as well as to people who work in shared environments and who may not be expecting noise. (There is a precedent for worrying about mere annoyance: User agents should not provide a public API to cause videos to be shown full-screen. A script, combined with a carefully crafted video file, could trick the user into thinking a system-modal dialog had been shown, and prompt the user for a password. There is also the danger of mere annoyance, with pages launching full-screen videos when links are clicked or pages navigated.) Should autoplay be removed as an attribute of audio and video, precisely to remove such annoyance from people who rely on aural browsing? While there are video sites such as youTube that do play videos automatically, others such as vimeo don't. Is there an archive that lists the use-cases for autoplay and contrasts it with the annoyance and accessibility issues?. (see http://www.brucelawson.co.uk/2009/accessibility-of-html5-video-and-audio-elements/) -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
Re: [whatwg] Spec should require UAs to have control to mute/ pause audio/ video
Bruce Lawson wrote: This may already be in the spec, but I couldn't find it. I think the spec should explicity require UAs to provide a mehanism to mute audio and to pause video, even if the controls attribute is not set. This would not make sense in some situations e.g. for a UA designed to play in-store video adverts (which I hate by the way :) ). In general the spec does not and should not mandate or constrain UI, although it does sometimes make suggestions (in general I am rather against this because the people that are good at writing technical specifications are rarely the same people who are good at designing UI, so such suggestions are often not that great. And UI is an area in which browsers should be allowed to compete).
Re: [whatwg] Question on (new) header and hgroup
On Thu, May 7, 2009 at 5:15 PM, Bruce Lawson bru...@opera.com wrote: I'm struggling to understand the reasons for hgroup: wouldn't one or more h1..h6 elements wrapped in the same header imply just such a grouping without the need for such an element? No longer, as header is not a sectioning element (IIUC). To illustrate my query, what is the difference between header h1HTML 5/h1 h2a new era of loveliness/h2 nav ... /nav /header and header hgroup h1HTML 5/h1 h2a new era of loveliness/h2 /hgroup nav ... /nav /header ? The answer is in the second example of header (copied thereafter for convenience): http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#the-header-element In this example, the page has a page heading given by the h1 element, and two subsections whose headings are given by h2 elements. The content after the header element is still part of the last subsection started in the header element, because the header element doesn't take part in the outline algorithm. body header h1Little Green Guys With Guns/h1 nav ul lia href=/gamesGames/a | lia href=/forumForum/a | lia href=/downloadDownload/a /ul /nav h2Important News/h2 !-- this starts a second subsection -- !-- this is part of the subsection entitled Important News -- pTo play today's games you will need to update your client./p h2Games/h2 !-- this starts a third subsection -- /header pYou have three active games:/p !-- this is still part of the subsection entitled Games -- ... -- Thomas Broyer
Re: [whatwg] Question on (new) header and hgroup
On Thu, 07 May 2009 16:34:21 +0100, James Graham jgra...@opera.com wrote: So, in the first example A new era of loveliness is a real section heading and the navigation becomes a subsection of that section. In the second example the hgroup element tells us that the h1 and h2 elements form a heading-subheading pair and that the navigation is a subsection of the section headed by this heading/subheading pair. Is that any clearer? much, thanks. Does your sectioning outliner utility now take these changes into account, by the way? -- Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
[whatwg] MessagePorts in Web Workers: implementation feedback
Hi all, I've been hashing through a bunch of the design issues around using MessagePorts within Workers with IanH and the Chrome/WebKit teams and I wanted to follow up with the list with my progress. The problems we've encountered are all solveable, but I've been surprised at the amount of work involved in implementing worker MessagePorts (and the resulting implications that MessagePorts have on worker lifecycles/reachability). My concern is that the amount of work to implement MessagePorts within Worker context may be so high that it will prevent vendors from implementing the SharedWorker API. Have other implementers started working on this part of the spec yet? Let me quickly run down some of the implementation issues I've run into - some of these may be WebKit/Chrome specific, but other browsers may run into some of them as well: 1) MessagePort reachability is challenging in the context of separate Worker heaps In WebKit, each worker has its own heap (in Chrome, they will have their own process as well). The spec reads: User agents must act as if MessagePorthttp://www.w3.org/TR/html5/comms.html#messageportobjects have a strong reference to their entangled MessagePort http://www.w3.org/TR/html5/comms.html#messageport object. Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained. Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other. Furthermore, a MessagePorthttp://www.w3.org/TR/html5/comms.html#messageportobject must not be garbage collected while there exists a message in a task queue http://www.w3.org/TR/html5/browsers.html#task-queue that is to be dispatched on that MessagePorthttp://www.w3.org/TR/html5/comms.html#messageportobject, or while the MessagePort http://www.w3.org/TR/html5/comms.html#messageport object's port message queue http://www.w3.org/TR/html5/comms.html#port-message-queue is open and there exists a messagehttp://www.w3.org/TR/html5/comms.html#event-messageevent in that queue. The end result of this is the need to track some common state across an entangled MessagePort pair such as: number of outstanding messages, open state of each end, and number of active references to each port (zero or non-zero). Turns out this last bit will require adding new hooks to the JavaScriptCore garbage collector to detect transitioning between 1 and 0 references without actually freeing the object - not that difficult, but possibly something that other implementers should keep in mind. 2) MessagePorts dramatically change the worker lifecycle Having MessagePorts in worker context means that Workers can outlive their parent window(s) - I can create a worker, pass off an entangled MessagePort to another window (say, to a different domain), then close the original window, and the worker should stay alive. In the case of WebKit, this causes some problems for things like worker-initiated network requests - if workers can continue to run even though there are no open windows for that origin, then it becomes problematic to perform network requests (part of this is due to the architecture of WebKit which requires proxying network requests to window context, but part of this is just a general problem of how do you handle things like HTTP Auth when there are no open windows for that origin?) Finally, the spec defines a fairly broad definition of what makes a worker reachable - here's an excerpt from my WebKit Shared Worker design doc, where I summarize the spec (possibly incorrectly - feel free to correct any misconceptions): PermissibleThe spec specifies that a worker is *permissible* based on whether it has a reachable MessagePort that has been entangled *at some point in the past* with an active window (or with a worker who is itself permissible). Basically, if a worker has *ever* been entangled with an active window, or if it's ever been entangled with a worker who is itself permissible (i.e. it's associated with an active window via a chain of workers that have been entangled at some point in the past) then it's permissible. The reason why the at some point in the past language is present is to allow a page to create a fire-and-forget worker (for example, a worker that does a set of long network operations) without having to keep a reference to that worker around. Once the referent windows close, the worker should also close, as being permissible is a necessary (but not sufficient) criteria for being runnable. Active neededA permissible worker is *active needed* if: 1. it has pending timers/network requests/DB activity, or 2. it is currently entangled with an active window, or another active needed worker. The intent behind #1 is to enable fire-and-forget workers that don't exit until they are
Re: [whatwg] Micro-data/Microformats/RDFa InteroperabilityRequirement
The main problem with prefixes is that the meaning of prefixes is not preserved when a code fragment is pasted elsewhere, so that prefixed names can end up meaningless or having an entirely different meaning from what the author had intended. A similar problem arises with DTD entities (indeed, DTD entities could be used instead of prefixes). HTH, Chris
Re: [whatwg] rel=license example
The rel=license example in http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#li nk-type-license looks like: body h1Kissat/h1 nav a href=../Return to photo index/a /nav img src=/pix/39627052_fd8dcd98b5.jpg pOne of them has six toes!/p ... /body I would say that this particular example represents a figure with caption. IMHO, Chris
Re: [whatwg] MessagePorts in Web Workers: implementation feedback
On Thu, 7 May 2009, Drew Wilson wrote: Having MessagePorts in worker context means that Workers can outlive their parent window(s) - I can create a worker, pass off an entangled MessagePort to another window (say, to a different domain), then close the original window, and the worker should stay alive. In the case of WebKit, this causes some problems for things like worker-initiated network requests - if workers can continue to run even though there are no open windows for that origin, then it becomes problematic to perform network requests (part of this is due to the architecture of WebKit which requires proxying network requests to window context, but part of this is just a general problem of how do you handle things like HTTP Auth when there are no open windows for that origin?) How does WebKit handle this case for regular Windows? (e.g. if a script does x=window.open(), grabs the x.XMLHttpRequest constructor, calls x.close(), and then invokes the constructor.) The thing we'd give up is the capabilities-based API that MessagePorts provide, but I'd argue that the workaround is simple: the creating window can just act as a proxy for the worker. That's a rather poor workaround. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MessagePorts in Web Workers: implementation feedback
On May 7, 2009, at 2:47 PM, Ian Hickson wrote: On Thu, 7 May 2009, Drew Wilson wrote: Having MessagePorts in worker context means that Workers can outlive their parent window(s) - I can create a worker, pass off an entangled MessagePort to another window (say, to a different domain), then close the original window, and the worker should stay alive. In the case of WebKit, this causes some problems for things like worker-initiated network requests - if workers can continue to run even though there are no open windows for that origin, then it becomes problematic to perform network requests (part of this is due to the architecture of WebKit which requires proxying network requests to window context, but part of this is just a general problem of how do you handle things like HTTP Auth when there are no open windows for that origin?) How does WebKit handle this case for regular Windows? (e.g. if a script does x=window.open(), grabs the x.XMLHttpRequest constructor, calls x.close(), and then invokes the constructor.) I believe what would happen is: the UI would be thrown up by the window in which the script doing x.XMLHttpRequest runs, rather than the home window. - Maciej The thing we'd give up is the capabilities-based API that MessagePorts provide, but I'd argue that the workaround is simple: the creating window can just act as a proxy for the worker. That's a rather poor workaround. :-) -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] MessagePorts in Web Workers: implementation feedback
It looks like WebKit binds the XMLHttpRequest object to its parent document at instantiation time, so the source of the constructor doesn't make a difference. And it looks like that binding is cleared when the document is closed so invoking xhr.send() on an XHR object whose parent document is no longer open fails silently. I'm basing this on code inspection, not on extensive knowledge of the codebase, so the webkit folks should feel free to correct me here. Why is having the window proxy on behalf of its workers a poor workaround for worker MessagePorts? I totally understand the utility of MessagePorts for things like cross-window and cross-iframe communication, but it seems like the use cases for external access to workers are far more obscure. -atw On Thu, May 7, 2009 at 2:47 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 7 May 2009, Drew Wilson wrote: Having MessagePorts in worker context means that Workers can outlive their parent window(s) - I can create a worker, pass off an entangled MessagePort to another window (say, to a different domain), then close the original window, and the worker should stay alive. In the case of WebKit, this causes some problems for things like worker-initiated network requests - if workers can continue to run even though there are no open windows for that origin, then it becomes problematic to perform network requests (part of this is due to the architecture of WebKit which requires proxying network requests to window context, but part of this is just a general problem of how do you handle things like HTTP Auth when there are no open windows for that origin?) How does WebKit handle this case for regular Windows? (e.g. if a script does x=window.open(), grabs the x.XMLHttpRequest constructor, calls x.close(), and then invokes the constructor.) The thing we'd give up is the capabilities-based API that MessagePorts provide, but I'd argue that the workaround is simple: the creating window can just act as a proxy for the worker. That's a rather poor workaround. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] MessagePorts in Web Workers: implementation feedback
I agree with Drew's assessment that MessagePorts in combination with Workers are extremely complicated to implement correctly, as currently specified. In fact, the design seems to push towards having lockable shared state, even though one potential advantage of the message passing design is to avoid locking and shared state. Besides removing MessagePorts as a way to communicate with workers, another possibility is simplifying the life cycle requirements. For example, getting rid of the keepalive rule, whereby both MessagePorts remain live so long as either is otherwise live, would remove the majority of the complexity. I don't think the slight convenience of that rule is worth the extra implementation cost. On May 7, 2009, at 1:39 PM, Drew Wilson wrote: Hi all, I've been hashing through a bunch of the design issues around using MessagePorts within Workers with IanH and the Chrome/WebKit teams and I wanted to follow up with the list with my progress. The problems we've encountered are all solveable, but I've been surprised at the amount of work involved in implementing worker MessagePorts (and the resulting implications that MessagePorts have on worker lifecycles/reachability). My concern is that the amount of work to implement MessagePorts within Worker context may be so high that it will prevent vendors from implementing the SharedWorker API. Have other implementers started working on this part of the spec yet? Let me quickly run down some of the implementation issues I've run into - some of these may be WebKit/Chrome specific, but other browsers may run into some of them as well: 1) MessagePort reachability is challenging in the context of separate Worker heaps In WebKit, each worker has its own heap (in Chrome, they will have their own process as well). The spec reads: User agents must act as if MessagePort objects have a strong reference to their entangled MessagePort object. Thus, a message port can be received, given an event listener, and then forgotten, and so long as that event listener could receive a message, the channel will be maintained. Of course, if this was to occur on both sides of the channel, then both ports would be garbage collected, since they would not be reachable from live code, despite having a strong reference to each other. Furthermore, a MessagePort object must not be garbage collected while there exists a message in a task queue that is to be dispatched on that MessagePort object, or while the MessagePort object's port message queue is open and there exists a message event in that queue. The end result of this is the need to track some common state across an entangled MessagePort pair such as: number of outstanding messages, open state of each end, and number of active references to each port (zero or non-zero). Turns out this last bit will require adding new hooks to the JavaScriptCore garbage collector to detect transitioning between 1 and 0 references without actually freeing the object - not that difficult, but possibly something that other implementers should keep in mind. 2) MessagePorts dramatically change the worker lifecycle Having MessagePorts in worker context means that Workers can outlive their parent window(s) - I can create a worker, pass off an entangled MessagePort to another window (say, to a different domain), then close the original window, and the worker should stay alive. In the case of WebKit, this causes some problems for things like worker-initiated network requests - if workers can continue to run even though there are no open windows for that origin, then it becomes problematic to perform network requests (part of this is due to the architecture of WebKit which requires proxying network requests to window context, but part of this is just a general problem of how do you handle things like HTTP Auth when there are no open windows for that origin?) Finally, the spec defines a fairly broad definition of what makes a worker reachable - here's an excerpt from my WebKit Shared Worker design doc, where I summarize the spec (possibly incorrectly - feel free to correct any misconceptions): Permissible The spec specifies that a worker is permissible based on whether it has a reachable MessagePort that has been entangled at some point in the past with an active window (or with a worker who is itself permissible). Basically, if a worker has ever been entangled with an active window, or if it's ever been entangled with a worker who is itself permissible (i.e. it's associated with an active window via a chain of workers that have been entangled at some point in the past) then it's permissible. The reason why the at some point in the past language is present is to allow a page to create a fire-and-forget worker (for example, a worker that does a set of long network operations) without having to keep a
Re: [whatwg] Question on (new) header and hgroup
On Thu, May 7, 2009 at 3:34 PM, jgra...@opera.com wrote: Quoting Smylers smyl...@stripey.com: James Graham writes: Bruce Lawson wrote: I'm struggling to understand the reasons for hgroup: wouldn't one or more h1..h6 elements wrapped in the same header imply just such a grouping without the need for such an element? hgroup affects the document structure, header does not. That explains _how_ they are different (as does the spec), but not _why_ it is like that. More specifically: * Are there significant cases where header needs _not_ to imply hgroup? Consider wrapping an hgroup inside every header; how many places has that broken the semantics? I could believe that most of the cases where a pager header appropriately contains multiple headings they are subtitles rather than subsections. The semantic that authors seem to want from an element named header is All the top matter of my page before the main content. That could include headers, subheaders, navigation, asides (at least per the current definition of aside which I think is silly, but I digress) and almost anything else. Since the header can contain multiple distinct logical sections of the document, each with their own headers, it makes no sense to implicitly wrap its contents in hgroup. James got it exactly. I, as an author, want an element that fills a role analogous to article in semantics, so I can trivially and obviously mark up that the section is just a prelude to my main content. In my own pages, when I use a div #header, it usually contains, in addition to the heading itself, some non-heading text and a nav or two. That latter bit especially would be inappropriate within an (implicit) hgroup. * Are there significant cases where hgroup will be useful outside of header? hgroup exists to allow for subtitles and the like. It's fairly common for documents to have these -- where it's likely there's use for a header element anyway. It's much less common for a mere section of a document to warrant a multi-part title; is that a case which is worth solving? If it is, would it be problematic to force authors to use header there? It seems highly odd to have header perform a dual role where sometimes it means section header and sometimes it means group of heading/subheading elements. Much more confusing than one element per role. Section headers with subtitles lower down in the document hierarchy occur with a decent frequency in my pages. The document itself would have a complex header (possibly with an hgroup), then the article would have an hgroup of its own. ~TJ
[whatwg] Suitable video codec
H.264 was advocated here for the video element as higher quality than competing codecs such as Theora could ever manage. The Thusnelda coder is outdoing H.,264 in current tests: http://web.mit.edu/xiphmont/Public/theora/demo7.html This is of course developmental work. I'm sure the advocates of H. 264 can also tune its encoders to keep up, and not make Theora the only reasonable candidate for the video element. - d.
Re: [whatwg] Suitable video codec
On Thu, May 7, 2009 at 5:51 PM, David Gerard dger...@gmail.com wrote: The Thusnelda coder is outdoing H.,264 in current tests: Be careful how glowing you make this sound -- this is on a particular objective test (not subjective, and thus perversely less accurate in reflecting how good do people think this looks), and only based on one video clip. That's not to diminish the Theora work at all -- the results are also subjectively better IMO, and Theora getting better is a win no matter what. PK
[whatwg] keygen - competitor update
I don't know how far you have gotten with keygen. You may be interested in knowing what the competition is doing :-) From a provisioning point of view smart cards have a long way to go. From the SKS paper: even if you buy a $100 card; it still doesn't enable an on-line issuer to verify that keys were actually created in the card! Since on-line provisioning is the norm for Information Cards, mobile device keys, etc, I have added something which I call Air-tight Provisioning to the USB memory stick design I'm working with. Air-tight provisioning, the basics: http://webpki.org/papers/keygen2/secure-key-store.pdf If you take a look at Dual-use Device IDs, you will find a novel (?) use of device certificates. Air-tight provisioning, core facility: http://webpki.org/papers/keygen2/session-key-establishment--security-element-2-server.pdf The most important conclusion drawn so far is that provisioning must be an integral part of a cryptographic sub-system, otherwise it will be full with quirks, security holes, and interoperability issues. A good thing is that nothing prevents designs like the above to be used with conventional cryptographic APIs for the execution part of a key's life; it is only the provisioning and management operations that need a major overhaul. Is this standardization? Not really. After talking to literally hundreds of people, it is fairly clear that standardization takes too long time, is riddled by politics, and very often lacks real-world testing. XKMS is an example of a standard that failed on the market in spite of being supported by all he big guns. Open design, free code, and a community seems to be the most realistic way ahead. Anders Rundgren
