mapped onto a sphere, with operational hit testing etc). > * Webkit's implementation of CSS does not remove 3D-ified elements > from the document flow, the perspective of that flow is merely changed > only for the affected elements. 3D and 2D elements can exist > side-by-side that way as well. Simon From shadow2531 at gmail.com Tue Nov 3 00:26:05 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 03:26:05 -0500 Subject: [whatwg] focus change inside keypress event handler In-Reply-To: References:

<4AE9A352.2060001@mit.edu> <4AEA38A4.8020401@mit.edu> Message-ID: On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II wrote: > I'll put together a new description with the changes to see if sounds > good. O.K., this description might be better and sounds more like what Firefox does for compat with the net: ------- Fire 'keydown' first. The default action for 'keydown' is to set the acceptKeypress flag to true. Using preventDefault() (either explicitly or implicitly through return false) prevents the default action and results in the acceptKeypress flag remaining false. Changing the focus from one object to another inside the 'keydown' handler changes the current Context Object (what the action will be performed on) for the following 'keypress' handler. After the 'keydown' handler runs, fire 'keypress'. The default action for 'keypress' is to allow the keypress if the acceptKeypress flag is true. If acceptKeypress is not true or if preventDefault() is called in the 'keypress' handler (either explicitly or implicitly through return false), then the keypress is not allowed. If the keypress is allowed then perform the action on the current Context Object. The action could be text insertion, text deletion, scrolling etc. If the keypress is not allowed, then do not perform the action unless the UA does not allow preventing the action, which in that case, perform the action. Note that a focus change inside a 'keypress' handler does not change the current Context Object for the keypress. If the a key is being held down and Repeat Processing is supported, process the above over and over. (e.g. keydown -> keyup -> keydown -> keyup) When the key is finally released, fire 'keyup'. However, note that if alert(), confirm() or prompt() is used inside a 'keydown' handler and or inside a 'keypress' handler, whether 'keyup' fires varies between implementations. Also note that alert(), confirm(), prompt(), setTimeout and setInterval() inside the 'keydown' , 'keypress' and 'keyup' handlers may result in some code inside the handlers running in a different order than 'keydown' -> 'keypress' -> 'keyup'. ------- That's how Firefox appears to work, in my words, from the outside looking in. Again though, even if that's not right, I still want the spec to go into details like that. -- Michael From derernst at gmx.ch Tue Nov 3 00:55:52 2009 From: derernst at gmx.ch (Markus Ernst) Date: Tue, 03 Nov 2009 09:55:52 +0100 Subject: [whatwg] WebStandrd for theme In-Reply-To: References: <4AEF1A37.2000001@ni-po.com> Message-ID: <4AEFF018.2070904@gmx.ch> narendra sisodiya schrieb: > On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov wrote: >> narendra sisodiya schrieb: >>> Many blogging site like posterous has theme editor for their >>> blog/website. It is a xml file looks more like html. Following file >>> was a long file which I have edited and deleted the unnecessary >>> content. I think this is a non-standard way to design theme. Do we >>> have any standard to such requirement ? OR we do not need any standard >>> at all for such requirement. >>> >>> PS: I have searched on FBML too. Google says, It is a propri. standard >>> of facebook. >> In the document you provided I couldn't find any tag using the fb-namespace. > The deleted content was having fb markups, My concern was more on > {{something}} type of things. To me it looks highly non-standard. Yes. Re-read the next part of Nikitas Answer: >> All the other things, like {something}, are a typical method to mark up >> things to be inserted in Templates. They are processed by a templating >> engine. And I really do think that things like this don't belong to HTML, >> they are many templating systems, many PHP developers have their own (as I >> do) using markup that's convenient for them. This means that the {something} type of things are processed by a template application on the web server; they will typically be replaced by the appropriate HTML output, before the code is sent to the client (your browser). Check the source code in the browser to verify this. There is no standard for server-side template systems; HTML covers the client side. From narendra.sisodiya at gmail.com Tue Nov 3 01:00:35 2009 From: narendra.sisodiya at gmail.com (narendra sisodiya) Date: Tue, 3 Nov 2009 14:30:35 +0530 Subject: [whatwg] WebStandrd for theme In-Reply-To: <4AEFF018.2070904@gmx.ch> References: <4AEF1A37.2000001@ni-po.com> <4AEFF018.2070904@gmx.ch> Message-ID: On Tue, Nov 3, 2009 at 2:25 PM, Markus Ernst wrote: > narendra sisodiya schrieb: >> >> On Mon, Nov 2, 2009 at 12:43 PM, Nikita Popov wrote: >>> >>> narendra sisodiya schrieb: >>>> >>>> Many blogging site like posterous has theme editor for their >>>> blog/website. It is a xml file looks more like html. Following file >>>> was a long file which I have edited and deleted the unnecessary >>>> content. I think this is a non-standard way to design theme. Do we >>>> have any standard to such requirement ? OR we do not need any standard >>>> at all for such requirement. >>>> >>>> PS: I have searched on FBML too. Google says, It is a propri. standard >>>> of facebook. >>> >>> In the document you provided I couldn't find any tag using the >>> fb-namespace. >> >> The deleted content was having fb markups, My concern was more on >> {{something}} type of things. To me it looks highly non-standard. > > Yes. Re-read the next part of Nikitas Answer: > >>> All the other things, like {something}, are a typical method to mark up >>> things to be inserted in Templates. They are processed by a templating >>> engine. And I really do think that things like this don't belong to HTML, >>> they are many templating systems, many PHP developers have their own (as >>> I >>> do) using markup that's convenient for them. > > This means that the {something} type of things are processed by a template > application on the web server; they will typically be replaced by the > appropriate HTML output, before the code is sent to the client (your > browser). Check the source code in the browser to verify this. There is no > standard for server-side template systems; HTML covers the client side. Thanks , I got my answer. Sorry for little noice. From shadow2531 at gmail.com Tue Nov 3 01:23:28 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 04:23:28 -0500 Subject: [whatwg] focus change inside keypress event handler In-Reply-To: References:

<4AE9A352.2060001@mit.edu> <4AEA38A4.8020401@mit.edu>

Message-ID: On Tue, 03 Nov 2009 03:26:05 -0500, Michael A. Puls II wrote: > On Thu, 29 Oct 2009 21:58:29 -0400, Michael A. Puls II > wrote: > >> I'll put together a new description with the changes to see if sounds >> good. > > O.K., this description might be better and sounds more like what Firefox > does for compat with the net: > > ------- > Fire 'keydown' first. > > The default action for 'keydown' is to set the acceptKeypress flag to > true. Using preventDefault() (either explicitly or implicitly through > return false) prevents the default action and results in the > acceptKeypress flag remaining false. > > Changing the focus from one object to another inside the 'keydown' > handler changes the current Context Object (what the action will be > performed on) for the following 'keypress' handler. > > After the 'keydown' handler runs, fire 'keypress'. > > The default action for 'keypress' is to allow the keypress if the > acceptKeypress flag is true. > > If acceptKeypress is not true or if preventDefault() is called in the > 'keypress' handler (either explicitly or implicitly through return > false), then the keypress is not allowed. > > If the keypress is allowed then perform the action on the current > Context Object. The action could be text insertion, text deletion, > scrolling etc. > > If the keypress is not allowed, then do not perform the action unless > the UA does not allow preventing the action, which in that case, perform > the action. > > Note that a focus change inside a 'keypress' handler does not change the > current Context Object for the keypress. > > If the a key is being held down and Repeat Processing is supported, > process the above over and over. (e.g. keydown -> keyup -> keydown -> > keyup) > > When the key is finally released, fire 'keyup'. > > However, note that if alert(), confirm() or prompt() is used inside a > 'keydown' handler and or inside a 'keypress' handler, whether 'keyup' > fires varies between implementations. > > Also note that alert(), confirm(), prompt(), setTimeout and > setInterval() inside the 'keydown' , 'keypress' and 'keyup' handlers > may result in some code inside the handlers running in a different order > than 'keydown' -> 'keypress' -> 'keyup'. > ------- > > That's how Firefox appears to work, in my words, from the outside > looking in. I should also note that in the 'keydown' handler, if a focus change happens *after* an alert(), the focus change will not change the context for 'keypress' as 'keypress' will have already fired before the focus change happens, which probably makes my "After the 'keydown' handler runs, fire 'keypress'" part not entire accurate as far as "After" goes. -- Michael From anewpage.media at gmail.com Tue Nov 3 06:37:33 2009 From: anewpage.media at gmail.com (Brian Blakely) Date: Tue, 3 Nov 2009 09:37:33 -0500 Subject: [whatwg] : A 3D Equivalent to In-Reply-To: Message-ID: <4af04033.0d0bca0a.1733.0896@mx.google.com> Hi Simon, These concerns are a part of this proposal, but if we collaborate without dissent, a file format can be chosen/devised, and browser vendors will implement the spec over time, and find different solutions to the same end, I am sure. I see it as a case of the chicken or the egg. ?If all these perpheral technologies existed, we likely would not be having this discussion because it would be a non-issue. Mapping content onto the 3D media is a feature I have thought about also and do need desperately in my design work. ?However, that is not appropriate for HTML to handle. You'll probably find it in CSS, something to the tune of 'div { map-model: url(sphere.xml) stretch etc etc }' and associated properties. Though this is a bit tangential to the goal of this proposal, a definition language for 3D models could define faces which are content mappable. ?Speaking totally of-the-cuff for the sake of clarity: <face id="content-face" etc etc /> ..and in CSS: map-model: url(cube.xml) content-face stretch etc etc; -Brian Simon Fraser wrote: On Nov 2, 2009, at 4:26 PM, Brian Blakely wrote: > * Though it does not have properties for clipping, Webkit's proposed > implementation of 3D CSS does have them for perspective. Clipping, > lighting, texture stretching and additional considerations could also > be a part of that spec, but those are discussions for the CSS WG. > > Without a 3D media element, none of that work can be done. Implementing your proposal would require that the model and surrounding CSS-transformed content be implemented via the same 3D engine, sharing a common coordinate system. That vastly increases the burden placed on an implementor of 3D transforms: suddenly wafers in space are non longer sufficient, and you need a new engine with support for all the features required by your <model /> content (which also needs to be specified somewhere). You can't just glue a 3D-rendered model into an environment with CSS-3D-transformed HTML elements and expect them to share a common 3D space. > * This proposal of a model can be considered a direct 3D analog to a > PNG, and its height and width could certainly be modified in the X-Y > axes on which 2D elements live, affecting document flow in that > fashion. A 3D analog for <img /> is a fine goal, but the primary issue is that there is no 3D file format which is accepted as a standard for this kind of use. Even if there were, the analogy breaks down because 3D is structured data; the author wants to be able to address certain objects in the 3D scene in order to animate them, or do click handling on them, or whatever. There is much more complexity here than there is with images. In this sense, <model> is as much a black box for 3D as WebGL on a <canvas> is. A further issue with this proposal is that it doesn't address another request, which is to integrate HTML content into a true 3D scene (e.g. a <div> mapped onto a sphere, with operational hit testing etc). > * Webkit's implementation of CSS does not remove 3D-ified elements > from the document flow, the perspective of that flow is merely changed > only for the affected elements. 3D and 2D elements can exist > side-by-side that way as well. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonp at opera.com Tue Nov 3 08:07:44 2009 From: simonp at opera.com (Simon Pieters) Date: Tue, 03 Nov 2009 17:07:44 +0100 Subject: [whatwg] Web Workers: "SyntaxError exception"? Message-ID: Web Workers says "If it failed to parse, then throw a SyntaxError exception and abort all these steps." Shouldn't that be SYNTAX_ERR exception? -- Simon Pieters Opera Software From tjeddo at gmail.com Tue Nov 3 08:51:56 2009 From: tjeddo at gmail.com (tjeddo) Date: Tue, 3 Nov 2009 08:51:56 -0800 Subject: [whatwg] the cite element In-Reply-To: References: Message-ID: On Thu, Oct 15, 2009 at 4:51 PM, Ian Hickson wrote: > Now, if we do in fact conclude that the use case for \cite{} is already > handled by , that leaves us with the choice of what to do for > titles of works. We could make obsolete and introduce a new > element, with the same default styles, and with a better name, like > or or or something. However, support for the element would > take years to be deployed enough to be usable, and in the meantime > browsers would still have the support of , so this would not be a > cheap solution. On the other hand, if we just reuse , by slightly > adjusting the definition in HTML4, we end up with a solution more or less > for free. I concede, given portions of your previous arguments, that is sufficient for citing bibliographic entries represented in HTML. Redefining the element for the purpose of supporting bibliographic citations (according to the scheme I previously proposed) probably adds too much additional complexity that would likely go underused by page authors. I am at least happy that the current HTML5 definition of cite for marking up the "titles of works" has been refined from the HTML4 version. However, I do have a small proposal that I would be interested in hearing feedback on. What if a standard link type called "citation" was added to the HTML5 specification? For example, [Jones, p. 88] After reviewing all the other link types and their corresponding definitions in current draft specification this seems like a consistent addition. The value proposition here is that a standardized way to explicitly indicate a "bibliographic citation" is available to authors that can be exploited by search engines to improve the relevance of searches. I acknowledge that I do not speak for the makers of major commercial search engines but I do have some experience in the area of structured search. I'd wager that providing this standardized semantic hook (i.e., rel="citation") could only open up opportunities for new functionality at little cost to the HTML5 specification. >> By the way, what is the reasoning in the HTML5 spec for stating that >> ship names should not be marked up with but should use >> instead? >> >> I guess I'm saying, why are ships not considered "works?" > > I suppose one could indeed make a somewhat convincing argument that a ship > is a work. I'm not sure I'd want to try to sell that though. I've removed > the sentence that says a ship isn't a work, but I haven't added ships to > the list works. Thanks. I believe not going out of your way to indicate that a ship name is not the title of a work is a safe decision. The definition I have in mind when I think of a "work" is along the lines of "something produced or accomplished by effort, exertion, or the exercise of skill " - Merriam Webster Dictionary (http://www.aolsvc.merriam-webster.aol.com/dictionary/work). Which I believe would include a ship as well as sculptures and books. Although, I agree it is more common to reference works from literature or art than engineering as their primary purpose is to convey information through observation/analysis. tjeddo From darin at chromium.org Tue Nov 3 09:51:33 2009 From: darin at chromium.org (Darin Fisher) Date: Tue, 3 Nov 2009 09:51:33 -0800 Subject: [whatwg] localStorage feedback In-Reply-To: <11e306600911021546wdc2e241ua29b307c10507b2a@mail.gmail.com> References: <03ba01ca386b$37104630$0a01a8c0@mikedeskxp> <11e306600910300136v770b485bhb7fbc143f4435a27@mail.gmail.com> <11e306600911020128i60dc9de3yd85394ad5b46a3ca@mail.gmail.com> <11e306600911021546wdc2e241ua29b307c10507b2a@mail.gmail.com> Message-ID: On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan wrote: > On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher wrote: > >> 1a) Given a page (domain A) containing an iframe (domain B), have the >> outer page navigate the inner frame to "about:blank". This navigation >> completes synchronously, and the unload handler for the iframe runs before >> the navigation request completes. This is true of all browsers. >> >> 1b) Suppose the inner page has a pending XMLHttpRequest when the outer >> frame navigates the inner frame. The XHR's onabort handler would run before >> the navigation to "about:blank" completes. >> > > These are really the same problem: synchronous cross-domain about:blank > navigation. If navigation to about:blank has to be synchronous, then I guess > it needs to drop the lock, at least in the cross-domain case. > That's correct. My point is simple: Here is another case where nesting can happen that hadn't been foreseen. Trying to foresee all such issues is difficult. Will we just keep amending the spec each time we find such a possible case? I think it is far saner to say that any nesting leads to unlocking the storage mutex. The spec can then list cases where this nesting might occur. > > 2) Set a break point in the Mozilla JS debugger. This runs a nested event >> loop each time you single step so that it can drive the rest of the browser >> UI. >> >> 3) Install a Firefox extension that runs a nested event loop in response >> to an event generated by content. I debugged many Firefox crashes resulting >> from extensions that do this kind of thing for various reasons. >> > > These are internal Mozilla issues and should not be allowed to influence > the design of the Web platform. They'll probably change for multi-process > anyway. > OK, but my point is that the spec should afford implementors with the ability to unlock the storage mutex at other times for reasons not mentioned in the spec. > > I'm not convinced. Look at Google Maps and street view. Gmail uses more >> Flash now than it used to. >> > > For new features, sure. But are they reimplementing existing browser-based > functionality to use plugins instead? > I think it is sufficient to just talk in the context of new features. A JS library or component grows a new feature that suddenly starts using a plugin. Now, API calls that were not supposed to touch plugins start touching plugins, and the storage mutex gets dropped. > > >> >>> What will you do for Gecko when it supports content processes? >>>> >>> >>> Implement the spec, I hope! >> >> >> It seems odd to me that this behavior was put into the spec without any >> implementation experience to guide it. The only multi-process >> implementations that I know of do not have a storage mutex. >> > > Lots of things are in the spec without implementation experience. I think > we have time to collect more experience on this issue with multi-process > browsers and revise the spec in light of it. > > OK. Please note my objection to the storage mutex. -Darin -------------- next part -------------- An HTML attachment was scrubbed... URL: From svartman95 at gmail.com Tue Nov 3 10:46:54 2009 From: svartman95 at gmail.com (Bjartur Thorlacius) Date: Tue, 3 Nov 2009 18:46:54 +0000 Subject: [whatwg] elemen.onFocus instead of window.onhashcange ? Message-ID: Wouldn't it make more sense to fire a focus event on a element whose id is that of the new hash instead of firing hashchange on the whole window? In most cases script authors will check the hash against a few options and then act upon with actions such as loading a new body (or div). It would make sense to have the new elements in the HTML but hidden (or out of view, but scrollable to -- though that's hard to implement) and when the focus is thrown on the element it's scrollIntoView()d. Maybe click or some new 'scrolledTo' event might be used instead of focus, I don't know, but my point is the event should fire on the element not window and it would be best to do so using an already supported event. Importantly this would encourage authors to use real HTML elements as targets for their #references so UAs which don't support HTML 5 scripting interfaces and/or CSS will render all the content (though likely some of it'll be out of the screen or not-yet rendered) but when a user follows a link to it it'll simply scrollIntoView(). This won't always be exactly what supposed but often close enough. But then the scrollIntoView function definition should make clear that non-visual UAs should also support the top argument, by only rendering the referenced element when applicable (scrollIntoView(false)). BTW: What happens when scrollIntoView is callod on hidden element? Or when it's invisible because of styling? PS: Please ease on the JavaScripting on the WHATWG version of the spec. I've got a quite old computer and Firefox freezes on me when I visit that page too often. Is all of that needed? Or don't old UAs matter to such an backwards compatible spec? ------------------------------------------------------- Switch over to Linux today -------------------------------------------------- http://www.linux.org From jorlow at chromium.org Tue Nov 3 11:37:36 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Tue, 3 Nov 2009 11:37:36 -0800 Subject: [whatwg] localStorage feedback In-Reply-To: References: <03ba01ca386b$37104630$0a01a8c0@mikedeskxp> <11e306600910300136v770b485bhb7fbc143f4435a27@mail.gmail.com> <11e306600911020128i60dc9de3yd85394ad5b46a3ca@mail.gmail.com> <11e306600911021546wdc2e241ua29b307c10507b2a@mail.gmail.com> Message-ID: <5dd9e5c50911031137g3336ab81n30698324fa42bb9b@mail.gmail.com> On Tue, Nov 3, 2009 at 9:51 AM, Darin Fisher wrote: > On Mon, Nov 2, 2009 at 3:46 PM, Robert O'Callahan wrote: > >> On Tue, Nov 3, 2009 at 6:36 AM, Darin Fisher wrote: >> >>> 1a) Given a page (domain A) containing an iframe (domain B), have the >>> outer page navigate the inner frame to "about:blank". This navigation >>> completes synchronously, and the unload handler for the iframe runs before >>> the navigation request completes. This is true of all browsers. >>> >>> 1b) Suppose the inner page has a pending XMLHttpRequest when the outer >>> frame navigates the inner frame. The XHR's onabort handler would run before >>> the navigation to "about:blank" completes. >>> >> >> These are really the same problem: synchronous cross-domain about:blank >> navigation. If navigation to about:blank has to be synchronous, then I guess >> it needs to drop the lock, at least in the cross-domain case. >> > > That's correct. My point is simple: Here is another case where nesting > can happen that hadn't been foreseen. Trying to foresee all such issues is > difficult. > > Will we just keep amending the spec each time we find such a possible case? > > I think it is far saner to say that any nesting leads to unlocking the > storage mutex. The spec can then list cases where this nesting might occur. > > > >> >> 2) Set a break point in the Mozilla JS debugger. This runs a nested event >>> loop each time you single step so that it can drive the rest of the browser >>> UI. >>> >>> 3) Install a Firefox extension that runs a nested event loop in response >>> to an event generated by content. I debugged many Firefox crashes resulting >>> from extensions that do this kind of thing for various reasons. >>> >> >> These are internal Mozilla issues and should not be allowed to influence >> the design of the Web platform. They'll probably change for multi-process >> anyway. >> > > OK, but my point is that the spec should afford implementors with the > ability to unlock the storage mutex at other times for reasons not mentioned > in the spec. > If we do this, we need to re-visit ways that scripts can tell whether the lock has been dropped. I can't remember which idea was most in favor last time we talked about it, but a counter that increments every time LocalStorage is unlocked sticks out in my mind. (Scripts can check the counter, do something that could cause unlocking, and then verify the counter is still the same after.) Another option that just came to mind is to have some flag that says "throw an exception whenever there's been a serialization violation". Just to be clear for those following along at home: If we (Chrome) implement the storage mutex for the next version of Chrome, it'll have to be the way Darin's describing (mainly for schedule based reasons). It would be nice to eventually fix all the cases that cause unnecessary unlocking, but that's going to take a while. I'm not convinced. Look at Google Maps and street view. Gmail uses more >>> Flash now than it used to. >>> >> >> For new features, sure. But are they reimplementing existing browser-based >> functionality to use plugins instead? >> > > I think it is sufficient to just talk in the context of new features. A JS > library or component grows a new feature that suddenly starts using a > plugin. Now, API calls that were not supposed to touch plugins start > touching plugins, and the storage mutex gets dropped. > > > >> >> >>> >>>> What will you do for Gecko when it supports content processes? >>>>> >>>> >>>> Implement the spec, I hope! >>> >>> >>> It seems odd to me that this behavior was put into the spec without any >>> implementation experience to guide it. The only multi-process >>> implementations that I know of do not have a storage mutex. >>> >> >> Lots of things are in the spec without implementation experience. I think >> we have time to collect more experience on this issue with multi-process >> browsers and revise the spec in light of it. >> >> > OK. Please note my objection to the storage mutex. > And mine. :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ocallahan.org Tue Nov 3 11:52:46 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 4 Nov 2009 08:52:46 +1300 Subject: [whatwg] localStorage feedback In-Reply-To: References: <03ba01ca386b$37104630$0a01a8c0@mikedeskxp> <11e306600910300136v770b485bhb7fbc143f4435a27@mail.gmail.com> <11e306600911020128i60dc9de3yd85394ad5b46a3ca@mail.gmail.com> <11e306600911021546wdc2e241ua29b307c10507b2a@mail.gmail.com> Message-ID: <11e306600911031152t240ed5b7ob04e6d7fea31ba6e@mail.gmail.com> On Wed, Nov 4, 2009 at 6:51 AM, Darin Fisher wrote: > That's correct. My point is simple: Here is another case where nesting > can happen that hadn't been foreseen. Trying to foresee all such issues is > difficult. > Yes. Will we just keep amending the spec each time we find such a possible case? > I would. > OK, but my point is that the spec should afford implementors with the > ability to unlock the storage mutex at other times for reasons not mentioned > in the spec. > I disagree, because this gives implementors freedom to drop the mutex in situations that might really just be fixable implementation bugs. I think our positions are clear now so we'll just have to agree to disagree. > >> >> I'm not convinced. Look at Google Maps and street view. Gmail uses more >>> Flash now than it used to. >>> >> >> For new features, sure. But are they reimplementing existing browser-based >> functionality to use plugins instead? >> > > I think it is sufficient to just talk in the context of new features. A JS > library or component grows a new feature that suddenly starts using a > plugin. Now, API calls that were not supposed to touch plugins start > touching plugins, and the storage mutex gets dropped. > That only matters if they start using the new feature in the middle of a localStorage "transaction". That seems possible, but unlikely, to me. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelaarontaylor at gmail.com Tue Nov 3 12:24:13 2009 From: michaelaarontaylor at gmail.com (Mike Taylor) Date: Tue, 3 Nov 2009 15:24:13 -0500 Subject: [whatwg] elemen.onFocus instead of window.onhashcange ? In-Reply-To: References: Message-ID: <7e56b1e10911031224k3a9bebecr1cf305d999c7f2a4@mail.gmail.com> > > > PS: Please ease on the JavaScripting on the WHATWG version of the > spec. I've got a quite old computer and Firefox freezes on me when I > visit that page too often. Is all of that needed? Or don't old UAs > matter to such an backwards compatible spec? > > Are you aware of the multi-page spec ( http://www.whatwg.org/specs/web-apps/current-work/multipage/)? The single page version will bring any browser to its knees. Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From bnkuhn at gmail.com Tue Nov 3 12:55:46 2009 From: bnkuhn at gmail.com (Brian Kuhn) Date: Tue, 3 Nov 2009 12:55:46 -0800 Subject: [whatwg] should async scripts block the document's load event? Message-ID: <335a812d0911031255l696cddd6nb04f66420fedbdb4@mail.gmail.com> In section 4.3.1, it says: *Fetching an external script must delay the load event of the element's document until the task that is queued by the networking task source once the resource has been fetched (defined above) has been run.* Has any thought been put into changing this for async scripts? It seems like it might be worthwhile to allow window.onload to fire while an async script is still downloading if everything else is done. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadow2531 at gmail.com Tue Nov 3 16:16:15 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 19:16:15 -0500 Subject: [whatwg] elemen.onFocus instead of window.onhashcange ? In-Reply-To: <7e56b1e10911031224k3a9bebecr1cf305d999c7f2a4@mail.gmail.com> References: <7e56b1e10911031224k3a9bebecr1cf305d999c7f2a4@mail.gmail.com> Message-ID: On Tue, 03 Nov 2009 15:24:13 -0500, Mike Taylor wrote: >> >> >> PS: Please ease on the JavaScripting on the WHATWG version of the >> spec. I've got a quite old computer and Firefox freezes on me when I >> visit that page too often. Is all of that needed? Or don't old UAs >> matter to such an backwards compatible spec? >> >> > Are you aware of the multi-page spec ( > http://www.whatwg.org/specs/web-apps/current-work/multipage/)? > The single page version will bring any browser to its knees. Webkit browsers (Safari Win32 for example) handle the single page version really well even on ancient computers. However, if you still want the single-page version (becauses it's easier to search) for Firefox, Opera and IE, you can use , which will make things better (although you lose some advanced features on the page). -- Michael From robert at ocallahan.org Tue Nov 3 16:26:58 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Wed, 4 Nov 2009 13:26:58 +1300 Subject: [whatwg] elemen.onFocus instead of window.onhashcange ? In-Reply-To: References: <7e56b1e10911031224k3a9bebecr1cf305d999c7f2a4@mail.gmail.com> Message-ID: <11e306600911031626m4f57e62dvf27ee55f79fea3f3@mail.gmail.com> On Wed, Nov 4, 2009 at 1:16 PM, Michael A. Puls II wrote: > Webkit browsers (Safari Win32 for example) handle the single page version > really well even on ancient computers. > One interesting reason for that is discussed here: http://weblogs.mozillazine.org/bz/archives/020267.html Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: From shadow2531 at gmail.com Tue Nov 3 16:34:47 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 19:34:47 -0500 Subject: [whatwg] elemen.onFocus instead of window.onhashcange ? In-Reply-To: <11e306600911031626m4f57e62dvf27ee55f79fea3f3@mail.gmail.com> References: <7e56b1e10911031224k3a9bebecr1cf305d999c7f2a4@mail.gmail.com> <11e306600911031626m4f57e62dvf27ee55f79fea3f3@mail.gmail.com> Message-ID: On Tue, 03 Nov 2009 19:26:58 -0500, Robert O'Callahan wrote: > On Wed, Nov 4, 2009 at 1:16 PM, Michael A. Puls II > wrote: > >> Webkit browsers (Safari Win32 for example) handle the single page >> version >> really well even on ancient computers. >> > > One interesting reason for that is discussed here: > http://weblogs.mozillazine.org/bz/archives/020267.html Interesting. Thanks. -- Michael From waw325 at gmail.com Tue Nov 3 16:54:49 2009 From: waw325 at gmail.com (Wesley Walser) Date: Tue, 3 Nov 2009 19:54:49 -0500 Subject: [whatwg] Sectioning In-Reply-To: References: Message-ID: <7666665a0911031654r3921f831h9ba9889514a20db0@mail.gmail.com> I had to read it several times to get it as well. "...regardless of what implied sections other headings may have created." That is the part that answers the questions I believe. Yes, any element that starts an explicit section is *not* a subsection of nearest implicit sections. Also, any element that create an explicit section, ends any implicit sections on it's same level. Thanks, Wes On Mon, Nov 2, 2009 at 6:13 PM, Elizabeth Castro wrote: > In 4.4.11, it says > > Sectioning content?elements are always considered subsections of their > nearest ancestor element of?sectioning content, regardless of what implied > sections other headings may have created. > > Does that line mean that a section element is *not* a subsection of the > nearest implied section? > So, if there is no other explicit sectioning content, as in the example > given, then what would the section element be a subsection of? > I don't get why Thud ends up on an equal level as Quux and Bar. It seems > like as a section under h2 it should be a subsection of that Quux h2, just > as the implied Bar section is a subsection of the implied Foo section. > thanks, > Liz > > From curtiss at ten-321.com Tue Nov 3 18:05:26 2009 From: curtiss at ten-321.com (Curtiss Grymala) Date: Tue, 03 Nov 2009 21:05:26 -0500 Subject: [whatwg] Adding a src attribute to all elements Message-ID: <1257300326.16740.7.camel@cgrymala-desktop> I would like to propose that a src attribute be added to the spec for all HTML elements. The content of the file referenced in the src attribute would then replace the contents of the element that contains the src attribute. The src attribute would then be interpreted differently, depending on the type of file referenced in that src attribute. For instance, if I create a level 1 header that looks like:
This is a header
The text "This is a header" would be replaced with the image that's located at /example.png. However, if /example.png returns a 404 error, the text would be displayed instead. If, however, I create a div that looks like:
This is some other text
The text content of /example.txt would replace the text "This is some other text" within the div that I created. Again, though, if /example.txt returned a 404 error, then "This is some other text" would show up inside the div instead. The contents of the file referenced in the src attribute would need to be parsed and rendered prior to replacing the initial content of the element. For instance, if I reference a PHP file in the src attribute, I would expect the PHP to be parsed before it shows up in my document. I'm not sure if this is at all feasible, but I personally think it would be a great addition to the spec. Thank you. ________________________________________________________________________ Curtiss Grymala curtiss at ten-321.com From remco47 at gmail.com Tue Nov 3 18:44:07 2009 From: remco47 at gmail.com (Remco) Date: Wed, 4 Nov 2009 03:44:07 +0100 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <1257300326.16740.7.camel@cgrymala-desktop> References: <1257300326.16740.7.camel@cgrymala-desktop> Message-ID: <36a11a3a0911031844w2b6515e0q17b62902d21e7fa2@mail.gmail.com> On Wed, Nov 4, 2009 at 03:05, Curtiss Grymala wrote: > I would like to propose that a src attribute be added to the spec for > all HTML elements. The content of the file referenced in the src > attribute would then replace the contents of the element that contains > the src attribute. The src attribute would then be interpreted > differently, depending on the type of file referenced in that src > attribute. I tried to do something similar: I tried to get the alt attribute on all elements with external content. That would have made the HTML specification more consistent. But I think we have to accept that HTML is not a beautiful streamlined well-designed language. Everything you add to the specification needs to be implemented by all browsers. They all need to see the merit of it. Can you think of a good use case for this? What problem would it solve? If you can convince people that they have a problem which you solve, then you're in business. > For instance, if I reference a PHP file in the src attribute, I > would expect the PHP to be parsed before it shows up in my document. Minor nitpick: HTML does not influence that. A PHP file is translated into HTML on the server and then that HTML is served to the browser. The browser always only sees HTML. The .php extension has no meaning. It could just as well be .html or .foobar. -- Remco From nils-dagsson-moskopp at dieweltistgarnichtso.net Tue Nov 3 18:49:00 2009 From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp) Date: Wed, 4 Nov 2009 03:49:00 +0100 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <1257300326.16740.7.camel@cgrymala-desktop> References: <1257300326.16740.7.camel@cgrymala-desktop> Message-ID: <20091104034900.4c137cd3@desudesudesu> Am Tue, 03 Nov 2009 21:05:26 -0500 schrieb Curtiss Grymala : > I would like to propose that a src attribute be added to the spec for > all HTML elements. The content of the file referenced in the src > attribute would then replace the contents of the element that contains > the src attribute. The src attribute would then be interpreted > differently, depending on the type of file referenced in that src > attribute. A perfectly good way to go confuse people, if you ask me. > For instance, if I create a level 1 header that looks like: >
This is a header
> The text "This is a header" would be replaced with the image that's > located at /example.png. However, if /example.png returns a 404 error, > the text would be displayed instead. How is that different than this example ?
> If, however, I create a div that looks like: >
This is some other text
> The text content of /example.txt would replace the text "This is some > other text" within the div that I created. Again, though, > if /example.txt returned a 404 error, then "This is some other text" > would show up inside the div instead. and <object> elements are fine too. > The contents of the file referenced in the src attribute would need to > be parsed and rendered prior to replacing the initial content of the > element. For instance, if I reference a PHP file in the src > attribute, I would expect the PHP to be parsed before it shows up in > my document. I would suggest learning the semantics of the <iframe> element. Also, PHP is server side, HTML is client side. > I'm not sure if this is at all feasible, but I personally think it > would be a great addition to the spec. Thank you. What would be the use case for this ? -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091104/8fdf4934/attachment.pgp> From shadow2531 at gmail.com Tue Nov 3 20:21:35 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 23:21:35 -0500 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <1257300326.16740.7.camel@cgrymala-desktop> References: <1257300326.16740.7.camel@cgrymala-desktop> Message-ID: <op.u2urp9ul1ejg13@sandra-svwliu01> On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala <curtiss at ten-321.com> wrote: > I would like to propose that a src attribute be added to the spec for > all HTML elements. The content of the file referenced in the src > attribute would then replace the contents of the element that contains > the src attribute. The src attribute would then be interpreted > differently, depending on the type of file referenced in that src > attribute. > > For instance, if I create a level 1 header that looks like: > <h1 src="/example.png">This is a header</h1> > The text "This is a header" would be replaced with the image that's > located at /example.png. However, if /example.png returns a 404 error, > the text would be displayed instead. Opera supports this with css extensions. For example: <!DOCTYPE html> <style> *[src] { -o-replace: attr(src); width: attr(width); height: attr(height); display: inline-block; border: 1px solid black; } *[href] { -o-link: attr(href); -o-link-source: current; display: inline; text-decoration: underline; color: blue; } /* in XML */ image_link[src] { -o-link: attr(src) !important; -o-link-source: current; -o-replace: attr(src); display: inline-block; border: 1px solid blue; text-decoration: underline; color: blue; } </style> <h1 src="http://www.google.com/images/logo.gif" width="300" height="150">fallback</h1> <div href="http://hardocp.com/">test</a> <image_link src="http://www.google.com/images/logo.gif">fallback</image_link> However, -o-replace seems broken, -o-link doesn't always work right, attr() doesn't always work right, you can't specify the type/unit of what attr() returns (although I think there's a spec for that that no vendor follows) and using -o-link with -o-replace probably wouldn't work if -o-replace worked right. You can try in Opera 8.x maybe. It might work better there. So, the support is all broken and limited. However, I've always loved the idea of it and even like that it's done via CSS. Whether it's more semantic to use <img> inside something and <a> around something or not doesn't really matter to me. So, I think the end result of having all elements support @src and @href (not necessarily with css like above) would be cool. Yet, vendor devs have said that it'd be a pain and or annoying to implement, so... I don't feel super strongly about it though. I just think it'd be nice/cool. -- Michael From nils-dagsson-moskopp at dieweltistgarnichtso.net Tue Nov 3 20:49:45 2009 From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp) Date: Wed, 4 Nov 2009 05:49:45 +0100 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <op.u2urp9ul1ejg13@sandra-svwliu01> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> Message-ID: <20091104054945.05d1a82c@desudesudesu> Am Tue, 03 Nov 2009 23:21:35 -0500 schrieb "Michael A. Puls II" <shadow2531 at gmail.com>: > I don't feel super strongly about it though. I just think it'd be > nice/cool. And I want a Pony !! ;) -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net> From jackalmage at gmail.com Tue Nov 3 20:50:43 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Tue, 3 Nov 2009 20:50:43 -0800 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <op.u2urp9ul1ejg13@sandra-svwliu01> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> Message-ID: <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II <shadow2531 at gmail.com> wrote: > On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala <curtiss at ten-321.com> > wrote: >> For instance, if I create a level 1 header that looks like: >> <h1 src="/example.png">This is a header</h1> >> The text "This is a header" would be replaced with the image that's >> located at /example.png. However, if /example.png returns a 404 error, >> the text would be displayed instead. > > Opera supports this with css extensions. This is supported in the CSS specs properly, via the content property. *[src] { content: attr(src,url); } Done. (Doesn't work yet anywhere I believe, but it will.) ~TJ From shadow2531 at gmail.com Tue Nov 3 20:57:33 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Tue, 03 Nov 2009 23:57:33 -0500 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> Message-ID: <op.u2utd7iq1ejg13@sandra-svwliu01> On Tue, 03 Nov 2009 23:50:43 -0500, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II > <shadow2531 at gmail.com> wrote: >> On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala >> <curtiss at ten-321.com> >> wrote: >>> For instance, if I create a level 1 header that looks like: >>> <h1 src="/example.png">This is a header</h1> >>> The text "This is a header" would be replaced with the image that's >>> located at /example.png. However, if /example.png returns a 404 error, >>> the text would be displayed instead. >> >> Opera supports this with css extensions. > > This is supported in the CSS specs properly, via the content property. > > *[src] { > content: attr(src,url); > } > > Done. (Doesn't work yet anywhere I believe, but it will.) Cool. Thanks -- Michael From derernst at gmx.ch Wed Nov 4 02:03:49 2009 From: derernst at gmx.ch (Markus Ernst) Date: Wed, 04 Nov 2009 11:03:49 +0100 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> Message-ID: <4AF15185.30007@gmx.ch> Tab Atkins Jr. schrieb: > On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II <shadow2531 at gmail.com> wrote: >> On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala <curtiss at ten-321.com> >> wrote: >>> For instance, if I create a level 1 header that looks like: >>> <h1 src="/example.png">This is a header</h1> >>> The text "This is a header" would be replaced with the image that's >>> located at /example.png. However, if /example.png returns a 404 error, >>> the text would be displayed instead. >> Opera supports this with css extensions. > > This is supported in the CSS specs properly, via the content property. > > *[src] { > content: attr(src,url); > } If I understand things correctly, your example seems a little bit confusing to me. The *[src] selector selects elements with a src attribute specified, which does not apply to <h1> (if valid HTML5). Maybe abusing another attribute could work then? (I apologize if the example is stupid - I spent some time studying CSS3 now, but am not really familiar with the recommendations yet.) h1 { content: attr(title,url); } And the HTML: <h1 title="pix/aheadline.gif">A headline</h1> Looks quite ugly, if it would work at all. To match Curtiss' suggestion with CSS you would possibly rather use the style attribute, something like: <h1 style="content: url(pix/aheadline.gif)">A headline</h1> From shadow2531 at gmail.com Wed Nov 4 02:13:16 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Wed, 04 Nov 2009 05:13:16 -0500 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <4AF15185.30007@gmx.ch> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> <4AF15185.30007@gmx.ch> Message-ID: <op.u2u70das1ejg13@sandra-svwliu01> On Wed, 04 Nov 2009 05:03:49 -0500, Markus Ernst <derernst at gmx.ch> wrote: > Tab Atkins Jr. schrieb: > On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II > <shadow2531 at gmail.com> wrote: > On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala <curtiss at ten-321.com> > wrote: > For instance, if I create a level 1 header that looks like: > <h1 src="/example.png">This is a header</h1> > The text "This is a header" would be replaced with the image that's > located at /example.png. However, if /example.png returns a 404 error, > the text would be displayed instead. > Opera supports this with css extensions. > This is supported in the CSS specs properly, via the content property. > *[src] { > content: attr(src,url); > } > If I understand things correctly, your example seems a little bit > confusing to me. The *[src] selector selects elements with a src > attribute specified, which does not apply to <h1> (if valid HTML5) *[data-my-src] {} <h1 data-my-src=""> -- Michael From derernst at gmx.ch Wed Nov 4 02:57:43 2009 From: derernst at gmx.ch (Markus Ernst) Date: Wed, 04 Nov 2009 11:57:43 +0100 Subject: [whatwg] Custom attributes [was: Adding a src attribute to all elements] In-Reply-To: <op.u2u70das1ejg13@sandra-svwliu01> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> <4AF15185.30007@gmx.ch> <op.u2u70das1ejg13@sandra-svwliu01> Message-ID: <4AF15E27.5050503@gmx.ch> Michael A. Puls II schrieb: > On Wed, 04 Nov 2009 05:03:49 -0500, Markus Ernst <derernst at gmx.ch> wrote: > >> Tab Atkins Jr. schrieb: >> On Tue, Nov 3, 2009 at 8:21 PM, Michael A. Puls II >> <shadow2531 at gmail.com> wrote: >> On Tue, 03 Nov 2009 21:05:26 -0500, Curtiss Grymala <curtiss at ten-321.com> >> wrote: >> For instance, if I create a level 1 header that looks like: >> <h1 src="/example.png">This is a header</h1> >> The text "This is a header" would be replaced with the image that's >> located at /example.png. However, if /example.png returns a 404 error, >> the text would be displayed instead. >> Opera supports this with css extensions. >> This is supported in the CSS specs properly, via the content property. >> *[src] { >> content: attr(src,url); >> } >> If I understand things correctly, your example seems a little bit >> confusing to me. The *[src] selector selects elements with a src >> attribute specified, which does not apply to <h1> (if valid HTML5) > > *[data-my-src] {} > <h1 data-my-src=""> While experimenting with the validator (at validator.w3.org), I found that it does actually not complain about <h1 src="whatever.gif">. Thus, Tab's example would be perfectly valid. The validator even seems to accept any custom attribute name on any element - this is said to be valid HTML5: <!doctype html> <html> <body> <h1 foo="bar">Huhu</h1> </body> </html> I tried to find info about this in the spec, but only found: 3.2.1: Authors must not use elements, attributes, and attribute values that are not permitted by this specification or other applicable specifications. 3.2.3: Custom data attributes (e.g. data-foldername or data-msgid) can be specified on any HTML element, to store custom data specific to the page. According to 3.2.3.8 custom data attribute names must begin with "data-". I did not find anything on other custom attributes allowed. Is this a mistake in the validator, due to its experimental state, or is there something missing in the spec? From Simetrical+w3c at gmail.com Wed Nov 4 06:25:58 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Wed, 4 Nov 2009 09:25:58 -0500 Subject: [whatwg] Custom attributes [was: Adding a src attribute to all elements] In-Reply-To: <4AF15E27.5050503@gmx.ch> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> <4AF15185.30007@gmx.ch> <op.u2u70das1ejg13@sandra-svwliu01> <4AF15E27.5050503@gmx.ch> Message-ID: <7c2a12e20911040625o24ccea7cy6f133954333b4bab@mail.gmail.com> On Wed, Nov 4, 2009 at 5:57 AM, Markus Ernst <derernst at gmx.ch> wrote: > While experimenting with the validator (at validator.w3.org), I found that > it does actually not complain about <h1 src="whatever.gif">. Thus, Tab's > example would be perfectly valid. The validator even seems to accept any > custom attribute name on any element - this is said to be valid HTML5: > > . . . > > Is this a mistake in the validator, due to its experimental state, or is > there something missing in the spec? A mistake in the validator. http://validator.nu/ gives the correct answer: it's invalid. You need to prefix custom attributes with "data-". From jackalmage at gmail.com Wed Nov 4 07:58:47 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 4 Nov 2009 07:58:47 -0800 Subject: [whatwg] Adding a src attribute to all elements In-Reply-To: <4AF15185.30007@gmx.ch> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> <4AF15185.30007@gmx.ch> Message-ID: <dd0fbad0911040758o551dc660j615d193aabace668@mail.gmail.com> On Wed, Nov 4, 2009 at 2:03 AM, Markus Ernst <derernst at gmx.ch> wrote: > Tab Atkins Jr. schrieb: >> *[src] { >> ?content: attr(src,url); >> } > > If I understand things correctly, your example seems a little bit confusing > to me. The *[src] selector selects elements with a src attribute specified, > which does not apply to <h1> (if valid HTML5). Maybe abusing another > attribute could work then? (I apologize if the example is stupid - I spent > some time studying CSS3 now, but am not really familiar with the > recommendations yet.) > > h1 { > ?content: attr(title,url); > } > > And the HTML: > <h1 title="pix/aheadline.gif">A headline</h1> > > Looks quite ugly, if it would work at all. To match Curtiss' suggestion with > CSS you would possibly rather use the style attribute, something like: > > <h1 style="content: url(pix/aheadline.gif)">A headline</h1> Yes, it's using the invalid @src attribute, simply because that's what was asked for by the OP. Using a valid attribute like @title, or better yet a new attribute like @data-my-src suggested by Puls, would work equally well. CSS just doesn't care about HTML's attribute validity requirements. ~TJ From jackalmage at gmail.com Wed Nov 4 08:03:26 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Wed, 4 Nov 2009 08:03:26 -0800 Subject: [whatwg] Custom attributes [was: Adding a src attribute to all elements] In-Reply-To: <7c2a12e20911040625o24ccea7cy6f133954333b4bab@mail.gmail.com> References: <1257300326.16740.7.camel@cgrymala-desktop> <op.u2urp9ul1ejg13@sandra-svwliu01> <dd0fbad0911032050l4c0fddd6r283f92a08a4b8e9b@mail.gmail.com> <4AF15185.30007@gmx.ch> <op.u2u70das1ejg13@sandra-svwliu01> <4AF15E27.5050503@gmx.ch> <7c2a12e20911040625o24ccea7cy6f133954333b4bab@mail.gmail.com> Message-ID: <dd0fbad0911040803k4c1c8c0s7a02382a520713ff@mail.gmail.com> On Wed, Nov 4, 2009 at 6:25 AM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote: > On Wed, Nov 4, 2009 at 5:57 AM, Markus Ernst <derernst at gmx.ch> wrote: >> While experimenting with the validator (at validator.w3.org), I found that >> it does actually not complain about <h1 src="whatever.gif">. Thus, Tab's >> example would be perfectly valid. The validator even seems to accept any >> custom attribute name on any element - this is said to be valid HTML5: >> >> . . . >> >> Is this a mistake in the validator, due to its experimental state, or is >> there something missing in the spec? > > A mistake in the validator. ?http://validator.nu/ gives the correct > answer: it's invalid. ?You need to prefix custom attributes with > "data-". And/or write an "applicable specification" that defines the attribute and becomes accepted enough by the community to be recognized by validators. ~TJ From rob.ennals at gmail.com Wed Nov 4 14:13:03 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Wed, 4 Nov 2009 14:13:03 -0800 Subject: [whatwg] localStorage mutex - a solution? Message-ID: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> [this is Rob Ennals from Intel, posting from gmail over my phone while at tpac] How about this for a solution for the localStorage mutex problem: "the user agent MAY release the storage mutex on *any* API operation except localStorage itself" This guarantees that the common case of "several storage operations in a row with nothing in-between" works, but gives the implementors the freedom to release the storage mutex wherever else they find they need to. I ran this by a few people at the W3C tpac (where I am now) and everyone I talked to seemed to think this would work. Let the objections commence..... -Rob From mike.shaver at gmail.com Wed Nov 4 14:21:15 2009 From: mike.shaver at gmail.com (Mike Shaver) Date: Wed, 4 Nov 2009 17:21:15 -0500 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> Message-ID: <cc092ba00911041421k4cf1a14xb88cab4ddd9821c3@mail.gmail.com> On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > How about this for a solution for the localStorage mutex problem: > > "the user agent MAY release the storage mutex on *any* API operation except > localStorage itself" > > This guarantees that the common case of "several storage operations in a row > with nothing in-between" works, but gives the implementors the freedom to > release the storage mutex wherever else they find they need to. How does it guarantee that? Can't the user agent release the mutex due to activity in another process/thread, between operations that are sequential in a given script? Mike From rob.ennals at gmail.com Wed Nov 4 14:51:26 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Wed, 4 Nov 2009 14:51:26 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <cc092ba00911041421k4cf1a14xb88cab4ddd9821c3@mail.gmail.com> References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> <cc092ba00911041421k4cf1a14xb88cab4ddd9821c3@mail.gmail.com> Message-ID: <9914907F-9E28-418A-B097-1D978EA40637@gmail.com> The reason we sometimes need to release the storage mutex is to avoid a deadlock that can occur if a thread holding the storage mutex for domain X has to wait for another mutex Y - since whoever holds Y might wait for X, creating a wait cycle. One way to avoid this problem is to release the storage mutex if we need to wait for another mutex. I'm not aware of any situation where a thread A would need to release it's storage mutex due to actions by another process/thread B without A using any API. It's fine for thread B to block waiting for another domain's storage mutex so long as thread A isn't waiting for thread B - which it can't be unless it uses an API. Or to put it another way: if the thread can't call an API then it can't block waiting for another storage mutex, thus deadlock can't occur, thus we don't need to release the storage mutex. Does that claify things? Or am I missing something? -Rob On Nov 4, 2009, at 2:21 PM, Mike Shaver <mike.shaver at gmail.com> wrote: > On Wed, Nov 4, 2009 at 5:13 PM, Rob Ennals <rob.ennals at gmail.com> > wrote: >> How about this for a solution for the localStorage mutex problem: >> >> "the user agent MAY release the storage mutex on *any* API >> operation except >> localStorage itself" >> >> This guarantees that the common case of "several storage operations >> in a row >> with nothing in-between" works, but gives the implementors the >> freedom to >> release the storage mutex wherever else they find they need to. > > How does it guarantee that? Can't the user agent release the mutex > due to activity in another process/thread, between operations that are > sequential in a given script? > > Mike From mike.shaver at gmail.com Wed Nov 4 14:56:24 2009 From: mike.shaver at gmail.com (Mike Shaver) Date: Wed, 4 Nov 2009 17:56:24 -0500 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <9914907F-9E28-418A-B097-1D978EA40637@gmail.com> References: <3C068FE7-8FB3-4477-A092-1780985FEF0D@gmail.com> <cc092ba00911041421k4cf1a14xb88cab4ddd9821c3@mail.gmail.com> <9914907F-9E28-418A-B097-1D978EA40637@gmail.com> Message-ID: <cc092ba00911041456u6d23aa4eua93115fcb23a89f3@mail.gmail.com> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > Or to put it another way: if the thread can't call an API then it can't > block waiting for another storage mutex, thus deadlock can't occur, thus we > don't need to release the storage mutex. Right, but the spec text there doesn't prevent the UA from releasing more than in that scenario, which seems like it's not an improvement over where we are right now: unpredictable consistency. Existing racy implementations like in IE would be conformant, so developers can't count on the script-sequenced-storage-ops pattern providing transactionality. More likely, though, _I_'m missing something... Mike From rob.ennals at gmail.com Wed Nov 4 15:15:07 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Wed, 4 Nov 2009 15:15:07 -0800 Subject: [whatwg] localStorage mutex - a solution? Message-ID: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> I suspect my suggested spec line was insufficiently precise. How about this: "the user agent MUST NOT release the storage mutex between calls to local storage, except that the user agent MAY release the storage mutex on any API operation" We'd still need to define what "API operation" means, and I'm sure this could be worded better, but hopefully this makes the basic idea clearer. -Rob On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: > On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> > wrote: >> Or to put it another way: if the thread can't call an API then it >> can't >> block waiting for another storage mutex, thus deadlock can't occur, >> thus we >> don't need to release the storage mutex. > > Right, but the spec text there doesn't prevent the UA from releasing > more than in that scenario, which seems like it's not an improvement > over where we are right now: unpredictable consistency. Existing racy > implementations like in IE would be conformant, so developers can't > count on the script-sequenced-storage-ops pattern providing > transactionality. > > More likely, though, _I_'m missing something... > > Mike From rob.ennals at gmail.com Wed Nov 4 15:31:36 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Wed, 4 Nov 2009 15:31:36 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> Message-ID: <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> Missed out the important final qualifier. Here's take 3: "the user agent MUST NOT release the storage mutex between calls to local storage, except that the user agent MAY release the storage mutex on any API operation /other that a local storage oeration/" If a local storage op can release the mutex then the whole thing is pointless :-) -Rob On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > I suspect my suggested spec line was insufficiently precise. How > about this: > > "the user agent MUST NOT release the storage mutex between calls to > local storage, except that the user agent MAY release the storage > mutex on any API operation" > > We'd still need to define what "API operation" means, and I'm sure > this could be worded better, but hopefully this makes the basic idea > clearer. > > -Rob > > On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: > >> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> >> wrote: >>> Or to put it another way: if the thread can't call an API then it >>> can't >>> block waiting for another storage mutex, thus deadlock can't >>> occur, thus we >>> don't need to release the storage mutex. >> >> Right, but the spec text there doesn't prevent the UA from releasing >> more than in that scenario, which seems like it's not an improvement >> over where we are right now: unpredictable consistency. Existing >> racy >> implementations like in IE would be conformant, so developers can't >> count on the script-sequenced-storage-ops pattern providing >> transactionality. >> >> More likely, though, _I_'m missing something... >> >> Mike > From scherkus at chromium.org Wed Nov 4 22:17:09 2009 From: scherkus at chromium.org (Andrew Scherkus) Date: Wed, 4 Nov 2009 22:17:09 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> Message-ID: <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell < Brian.P.Campbell at dartmouth.edu> wrote: > As a multimedia developer, I am wondering about the purpose of the > timeupdate event on media elements. On first glance, it would appear that > this event would be useful for synchronizing animations, bullets, captions, > UI, and the like. The spec specifies a rate of 4 to 66 Hz for these events. > The high end of this (30 or more Hz) is pretty reasonable for displaying > things in sync with the video. The low end, however, 4 Hz, is far too slow > for most types of synchronization; everything feels laggy at this frequency. > From my testing on a two year old MacBook Pro, Firefox is giving me about 25 > timeupdate events per second, while Safari and Chrome are giving me the bare > minimum, of 4 timeupdate events per second. > > At 4 timeupdate events per second, it isn't all that useful. I can replace > it with setInterval, at whatever rate I want, query the time, and get the > synchronization I need, but that makes the timeupdate event seem to be > redundant. At 25 timeupdate events per second, it is reasonably useful, and > can be used to synchronize various things to the video. > > So, I'm wondering if there's a purpose for the timeupdate event that I'm > missing. If it is intended for any sort of synchronization with the video, I > think it should be improved to give better guarantees on the interval > between updates, or just dropped from the spec; it's not useful enough in > its current form. To improve it, the maximum interval between updates could > be reduced to about 40 ms, or perhaps the interval could be made settable so > the author could control how often they want to get the event. > > -- Brian > I believe it's a convenience over using setTimeout/setInterval + polling to determine whether playback has progressed ie., for rendering your own playback progress bar. I've also seen it been used as a signal to copy frames into <canvas> on Firefox, however if timeupdate frequency != fps of video you either miss frames or paint too much. I don't think timeupdate today is very useful for doing anything beyond a progress bar or other simple synchronized animations. Would something like <video> firing events for every frame rendered help you out? This would help also fix the <canvas> over/under painting issue and improve synchronization. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091104/291f1b78/attachment-0001.htm> From robert at ocallahan.org Wed Nov 4 23:31:11 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 5 Nov 2009 20:31:11 +1300 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> Message-ID: <11e306600911042331l1e378elb73d9312160b65ea@mail.gmail.com> On Thu, Nov 5, 2009 at 7:17 PM, Andrew Scherkus <scherkus at chromium.org>wrote: > Would something like <video> firing events for every frame rendered help > you out? This would help also fix the <canvas> over/under painting issue > and improve synchronization. > That is actually what timeupdate does in Firefox. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/03c64275/attachment.htm> From scherkus at chromium.org Wed Nov 4 23:41:26 2009 From: scherkus at chromium.org (Andrew Scherkus) Date: Wed, 4 Nov 2009 23:41:26 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <11e306600911042331l1e378elb73d9312160b65ea@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <11e306600911042331l1e378elb73d9312160b65ea@mail.gmail.com> Message-ID: <eb35a2a80911042341x48ac9245w30e1e48b473320bd@mail.gmail.com> On Wed, Nov 4, 2009 at 11:31 PM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Thu, Nov 5, 2009 at 7:17 PM, Andrew Scherkus <scherkus at chromium.org>wrote: > >> Would something like <video> firing events for every frame rendered help >> you out? This would help also fix the <canvas> over/under painting issue >> and improve synchronization. >> > > That is actually what timeupdate does in Firefox. Cool! How is your timeupdate frequency determined for <audio>? Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091104/147a166b/attachment.htm> From robert at ocallahan.org Thu Nov 5 00:12:33 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Thu, 5 Nov 2009 21:12:33 +1300 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <eb35a2a80911042341x48ac9245w30e1e48b473320bd@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <11e306600911042331l1e378elb73d9312160b65ea@mail.gmail.com> <eb35a2a80911042341x48ac9245w30e1e48b473320bd@mail.gmail.com> Message-ID: <11e306600911050012q65a9b7f3wbd30501100f5c7@mail.gmail.com> On Thu, Nov 5, 2009 at 8:41 PM, Andrew Scherkus <scherkus at chromium.org>wrote: > Cool! How is your timeupdate frequency determined for <audio>? > It's something arbitrary that depends on the codec. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/fbedeaae/attachment.htm> From brian.p.campbell at Dartmouth.EDU Thu Nov 5 06:10:17 2009 From: brian.p.campbell at Dartmouth.EDU (Brian Campbell) Date: Thu, 5 Nov 2009 09:10:17 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> Message-ID: <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: > On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell <Brian.P.Campbell at dartmouth.edu > > wrote: > As a multimedia developer, I am wondering about the purpose of the > timeupdate event on media elements. On first glance, it would appear > that this event would be useful for synchronizing animations, > bullets, captions, UI, and the like. The spec specifies a rate of 4 > to 66 Hz for these events. The high end of this (30 or more Hz) is > pretty reasonable for displaying things in sync with the video. The > low end, however, 4 Hz, is far too slow for most types of > synchronization; everything feels laggy at this frequency. From my > testing on a two year old MacBook Pro, Firefox is giving me about 25 > timeupdate events per second, while Safari and Chrome are giving me > the bare minimum, of 4 timeupdate events per second. > > At 4 timeupdate events per second, it isn't all that useful. I can > replace it with setInterval, at whatever rate I want, query the > time, and get the synchronization I need, but that makes the > timeupdate event seem to be redundant. At 25 timeupdate events per > second, it is reasonably useful, and can be used to synchronize > various things to the video. > > So, I'm wondering if there's a purpose for the timeupdate event that > I'm missing. If it is intended for any sort of synchronization with > the video, I think it should be improved to give better guarantees > on the interval between updates, or just dropped from the spec; it's > not useful enough in its current form. To improve it, the maximum > interval between updates could be reduced to about 40 ms, or perhaps > the interval could be made settable so the author could control how > often they want to get the event. > > -- Brian > > I believe it's a convenience over using setTimeout/setInterval + > polling to determine whether playback has progressed ie., for > rendering your own playback progress bar. I've also seen it been > used as a signal to copy frames into <canvas> on Firefox, however if > timeupdate frequency != fps of video you either miss frames or paint > too much. > > I don't think timeupdate today is very useful for doing anything > beyond a progress bar or other simple synchronized animations. Right. That's what I figured the point is; I just wanted to check to make sure I wasn't missing something. As implemented by Safari and Chrome (which is the minimum rate allowed by the spec), it's not really useful for that purpose, as 4 updates per second makes any sort of synchronization feel jerky and laggy. If it were done at the frame rate of the video, or perhaps with a minimum of 25 frames per second, it would be much more useful. Even at a minimum of 15 frames per second, you would still be able to get some sorts of useful synchronization, though animations synchronized wouldn't feel as smooth as they could. > Would something like <video> firing events for every frame rendered > help you out? This would help also fix the <canvas> over/under > painting issue and improve synchronization. Yes, this would be considerably better than what is currently specced. -- Brian From jorlow at chromium.org Thu Nov 5 10:16:54 2009 From: jorlow at chromium.org (Jeremy Orlow) Date: Thu, 5 Nov 2009 10:16:54 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> Message-ID: <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> This is intriguing. But what it comes down to is what we consider an "API operation". For example, you could define "API operation" to be the existing list of thing that unlock LocalStorage. Or it could be defined in a way that Darin Fisher's idea to lock whenever we're about to nest locking calls would also work. Or a variety of other things. Does anyone have any ideas on what the exact language for what an "API operation" might look like? I do have a couple of concerns though: Leaving the language open might not be terribly useful to a typical web developer since they're not going to read the spec and probably aren't going to have a very firm idea of whether what they're doing could unlock storage or not. Experimentation wouldn't work very well since each platform could be wildly different (since a lot of possible behaviors fall between the MAY and the MAY NOT in the proposed spec). Another concern is that the worst case performance aspects of LocalStorage remain. I cringe every time I think of one event loop blocking another. But I will admit that the average time would be better--especially if we're unlocking fairly aggressively. I'm interested to hear what others have to say on this proposal. J On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > Missed out the important final qualifier. Here's take 3: > > "the user agent MUST NOT release the storage mutex between calls to local > storage, except that the user agent MAY release the storage mutex on any API > operation /other that a local storage oeration/" > > If a local storage op can release the mutex then the whole thing is > pointless :-) > > -Rob > > > On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > > I suspect my suggested spec line was insufficiently precise. How about >> this: >> >> "the user agent MUST NOT release the storage mutex between calls to local >> storage, except that the user agent MAY release the storage mutex on any API >> operation" >> >> We'd still need to define what "API operation" means, and I'm sure this >> could be worded better, but hopefully this makes the basic idea clearer. >> >> -Rob >> >> On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: >> >> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> wrote: >>> >>>> Or to put it another way: if the thread can't call an API then it can't >>>> block waiting for another storage mutex, thus deadlock can't occur, thus >>>> we >>>> don't need to release the storage mutex. >>>> >>> >>> Right, but the spec text there doesn't prevent the UA from releasing >>> more than in that scenario, which seems like it's not an improvement >>> over where we are right now: unpredictable consistency. Existing racy >>> implementations like in IE would be conformant, so developers can't >>> count on the script-sequenced-storage-ops pattern providing >>> transactionality. >>> >>> More likely, though, _I_'m missing something... >>> >>> Mike >>> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/2540a648/attachment.htm> From shess at google.com Thu Nov 5 11:06:10 2009 From: shess at google.com (Scott Hess) Date: Thu, 5 Nov 2009 12:06:10 -0700 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> Message-ID: <696e4b7c0911051106i648eed1at743d9892b30bc193@mail.gmail.com> "user agent MAY release" means that people will write code which works now, and later the browser vendor will make a change that will break their code. Who is at fault? We all know that the browser vendor is at fault! Suggest "the user agent SHALL release the storage mutex on any API operation /other that a local storage operation/". The user agent is free to do internal optimizations to make things super efficient if there's only one local storage op client. But this means that the web developer's practical experience will lead them to the right place. -scott On Thu, Nov 5, 2009 at 11:16 AM, Jeremy Orlow <jorlow at chromium.org> wrote: > This is intriguing. ?But what it comes down to is what we consider an "API > operation". ?For example, you could define "API operation" to be the > existing list of thing that unlock LocalStorage. ?Or it could be defined in > a way that Darin Fisher's idea to lock whenever we're about to nest locking > calls would also work. ?Or a variety of other things. > Does anyone have any ideas on what the exact language for what an "API > operation" might look like? > > I do have a couple of concerns though: > Leaving the language open might not be terribly useful to a typical web > developer since they're not going to read the spec and probably aren't going > to have a very firm idea of whether what they're doing could unlock storage > or not. ?Experimentation?wouldn't work very well since each platform could > be wildly different (since a lot of possible behaviors fall between the MAY > and the MAY NOT in the proposed spec). > Another concern is that the worst case performance aspects of LocalStorage > remain. ?I cringe every time I think of one event loop blocking another. > ?But I will admit that the average time would be better--especially if we're > unlocking fairly?aggressively. > I'm interested to hear what others have to say on this proposal. > J > > On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <rob.ennals at gmail.com> wrote: >> >> Missed out the important final qualifier. Here's take 3: >> >> "the user agent MUST NOT release the storage mutex between calls to local >> storage, except that the user agent MAY release the storage mutex on any API >> operation /other that a local storage oeration/" >> >> If a local storage op can release the mutex then the whole thing is >> pointless :-) >> >> -Rob >> >> On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote: >> >>> I suspect my suggested spec line was insufficiently precise. How about >>> this: >>> >>> "the user agent MUST NOT release the storage mutex between calls to local >>> storage, except that the user agent MAY release the storage mutex on any API >>> operation" >>> >>> We'd still need to define what "API operation" means, and I'm sure this >>> could be worded better, but hopefully this makes the basic idea clearer. >>> >>> -Rob >>> >>> On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: >>> >>>> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> wrote: >>>>> >>>>> Or to put it another way: if the thread can't call an API then it can't >>>>> block waiting for another storage mutex, thus deadlock can't occur, >>>>> thus we >>>>> don't need to release the storage mutex. >>>> >>>> Right, but the spec text there doesn't prevent the UA from releasing >>>> more than in that scenario, which seems like it's not an improvement >>>> over where we are right now: unpredictable consistency. ?Existing racy >>>> implementations like in IE would be conformant, so developers can't >>>> count on the script-sequenced-storage-ops pattern providing >>>> transactionality. >>>> >>>> More likely, though, _I_'m missing something... >>>> >>>> Mike >>> > > From scherkus at chromium.org Thu Nov 5 12:11:15 2009 From: scherkus at chromium.org (Andrew Scherkus) Date: Thu, 5 Nov 2009 12:11:15 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> Message-ID: <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell < brian.p.campbell at dartmouth.edu> wrote: > On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: > > On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell < >> Brian.P.Campbell at dartmouth.edu> wrote: >> As a multimedia developer, I am wondering about the purpose of the >> timeupdate event on media elements. On first glance, it would appear that >> this event would be useful for synchronizing animations, bullets, captions, >> UI, and the like. The spec specifies a rate of 4 to 66 Hz for these events. >> The high end of this (30 or more Hz) is pretty reasonable for displaying >> things in sync with the video. The low end, however, 4 Hz, is far too slow >> for most types of synchronization; everything feels laggy at this frequency. >> From my testing on a two year old MacBook Pro, Firefox is giving me about 25 >> timeupdate events per second, while Safari and Chrome are giving me the bare >> minimum, of 4 timeupdate events per second. >> >> At 4 timeupdate events per second, it isn't all that useful. I can replace >> it with setInterval, at whatever rate I want, query the time, and get the >> synchronization I need, but that makes the timeupdate event seem to be >> redundant. At 25 timeupdate events per second, it is reasonably useful, and >> can be used to synchronize various things to the video. >> >> So, I'm wondering if there's a purpose for the timeupdate event that I'm >> missing. If it is intended for any sort of synchronization with the video, I >> think it should be improved to give better guarantees on the interval >> between updates, or just dropped from the spec; it's not useful enough in >> its current form. To improve it, the maximum interval between updates could >> be reduced to about 40 ms, or perhaps the interval could be made settable so >> the author could control how often they want to get the event. >> >> -- Brian >> >> I believe it's a convenience over using setTimeout/setInterval + polling >> to determine whether playback has progressed ie., for rendering your own >> playback progress bar. I've also seen it been used as a signal to copy >> frames into <canvas> on Firefox, however if timeupdate frequency != fps of >> video you either miss frames or paint too much. >> >> I don't think timeupdate today is very useful for doing anything beyond a >> progress bar or other simple synchronized animations. >> > > Right. That's what I figured the point is; I just wanted to check to make > sure I wasn't missing something. > > As implemented by Safari and Chrome (which is the minimum rate allowed by > the spec), it's not really useful for that purpose, as 4 updates per second > makes any sort of synchronization feel jerky and laggy. If it were done at > the frame rate of the video, or perhaps with a minimum of 25 frames per > second, it would be much more useful. Even at a minimum of 15 frames per > second, you would still be able to get some sorts of useful synchronization, > though animations synchronized wouldn't feel as smooth as they could. > > Would something like <video> firing events for every frame rendered help >> you out? This would help also fix the <canvas> over/under painting issue >> and improve synchronization. >> > > Yes, this would be considerably better than what is currently specced. > > -- Brian > I'll see if we can do something for WebKit based browsers, because today it literally is hardcoded to 250ms for all ports. http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254 Maybe we'll end up firing events based on frame updates for video, and something arbitrary for audio (as it is today). Brian, since Firefox is doing what you proposed -- can you think of any other issues with its current implementation? What about for audio files? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/ef76ca52/attachment.htm> From anewpage.media at gmail.com Thu Nov 5 12:59:36 2009 From: anewpage.media at gmail.com (Brian Blakely) Date: Thu, 5 Nov 2009 15:59:36 -0500 Subject: [whatwg] Hand the function of <address/> over to <contact/>? Message-ID: <d7e38f950911051259o3f261acarfb8c67f9280d3fc7@mail.gmail.com> I can only imagine the usage of <address/> will be utilized more productively if its intuitive purpose (arbitrary contact/postal addresses) were its actual function. As our friends at HTML5 Doctor illustrate, it is all too easy to jump to conclusions and use this element incorrectly. Perhaps a <contact/> element would be more suitable for document-specific contact info? Just a thought, off-hand. Thanks! -Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/811f8242/attachment.htm> From rob.ennals at gmail.com Thu Nov 5 15:14:40 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Thu, 5 Nov 2009 15:14:40 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> Message-ID: <8E82BE35-F94C-4E17-9BEE-EBF409465FEB@gmail.com> By "API operation" I mean anything other than core ecmascript and localstorage itself. Eg you can be sure that the following will not release the mutex: * do nothing * function call * if/for etc * access to a local variable * access to a basic ecmascript object (not host objects) But anything else outside core ecmascript is free to release the mutex if it wants. Eg any call to dom or any access to any object provided by the host. Rather than telling them what *can* release the mutex, we instead tell them to assume that everything can unless it is in our list of things that *can't*. This is intentionally broad for several reasons: * to avoid us having to work out the full list of all cases that could require any user agent to release the mutex * to give users an easy rule that they can remember and know will always be safe on any user agent * to give the user agent the freedom to release the mutex as soon as possible, thus improving concurrency [I am rep for Intel so I care about this] Apologies for being vague earlier. -Rob On Nov 5, 2009, at 10:16 AM, Jeremy Orlow <jorlow at chromium.org> wrote: > This is intriguing. But what it comes down to is what we consider > an "API operation". For example, you could define "API operation" > to be the existing list of thing that unlock LocalStorage. Or it > could be defined in a way that Darin Fisher's idea to lock whenever > we're about to nest locking calls would also work. Or a variety of > other things. > > Does anyone have any ideas on what the exact language for what an > "API operation" might look like? > > > I do have a couple of concerns though: > Leaving the language open might not be terribly useful to a typical > web developer since they're not going to read the spec and probably > aren't going to have a very firm idea of whether what they're doing > could unlock storage or not. Experimentation wouldn't work very > well since each platform could be wildly different (since a lot of > possible behaviors fall between the MAY and the MAY NOT in the > proposed spec). > > Another concern is that the worst case performance aspects of > LocalStorage remain. I cringe every time I think of one event loop > blocking another. But I will admit that the average time would be > better--especially if we're unlocking fairly aggressively. > > I'm interested to hear what others have to say on this proposal. > > J > > > On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <rob.ennals at gmail.com> > wrote: > Missed out the important final qualifier. Here's take 3: > > "the user agent MUST NOT release the storage mutex between calls to > local storage, except that the user agent MAY release the storage > mutex on any API operation /other that a local storage oeration/" > > If a local storage op can release the mutex then the whole thing is > pointless :-) > > -Rob > > > On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > > I suspect my suggested spec line was insufficiently precise. How > about this: > > "the user agent MUST NOT release the storage mutex between calls to > local storage, except that the user agent MAY release the storage > mutex on any API operation" > > We'd still need to define what "API operation" means, and I'm sure > this could be worded better, but hopefully this makes the basic idea > clearer. > > -Rob > > On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> wrote: > > On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals <rob.ennals at gmail.com> > wrote: > Or to put it another way: if the thread can't call an API then it > can't > block waiting for another storage mutex, thus deadlock can't occur, > thus we > don't need to release the storage mutex. > > Right, but the spec text there doesn't prevent the UA from releasing > more than in that scenario, which seems like it's not an improvement > over where we are right now: unpredictable consistency. Existing racy > implementations like in IE would be conformant, so developers can't > count on the script-sequenced-storage-ops pattern providing > transactionality. > > More likely, though, _I_'m missing something... > > Mike > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091105/163246af/attachment.htm> From rob.ennals at gmail.com Thu Nov 5 15:19:40 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Thu, 5 Nov 2009 15:19:40 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <696e4b7c0911051106i648eed1at743d9892b30bc193@mail.gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> <5dd9e5c50911051016q1fc53733q903b4635774fcde7@mail.gmail.com> <696e4b7c0911051106i648eed1at743d9892b30bc193@mail.gmail.com> Message-ID: <65C1EBFD-9BD9-4D07-9C6B-60B062024AFA@gmail.com> That version is fine with me. My reason for using MAY was I thought it would make efficient implementation easier. Also, testing when things are being unlocked is pretty much impossible for users due to the statistical nature of race conditions and shedulers. But yeah, SHALL is better semantically, if everyone is happy to imlement that. -Rob On Nov 5, 2009, at 11:06 AM, Scott Hess <shess at google.com> wrote: > "user agent MAY release" means that people will write code which works > now, and later the browser vendor will make a change that will break > their code. Who is at fault? We all know that the browser vendor is > at fault! > > Suggest "the user agent SHALL release the storage mutex on any API > operation /other that a local storage operation/". The user agent is > free to do internal optimizations to make things super efficient if > there's only one local storage op client. But this means that the web > developer's practical experience will lead them to the right place. > > -scott > > > On Thu, Nov 5, 2009 at 11:16 AM, Jeremy Orlow <jorlow at chromium.org> > wrote: >> This is intriguing. But what it comes down to is what we consider >> an "API >> operation". For example, you could define "API operation" to be the >> existing list of thing that unlock LocalStorage. Or it could be >> defined in >> a way that Darin Fisher's idea to lock whenever we're about to nest >> locking >> calls would also work. Or a variety of other things. >> Does anyone have any ideas on what the exact language for what an >> "API >> operation" might look like? >> >> I do have a couple of concerns though: >> Leaving the language open might not be terribly useful to a typical >> web >> developer since they're not going to read the spec and probably >> aren't going >> to have a very firm idea of whether what they're doing could unlock >> storage >> or not. Experimentation wouldn't work very well since each >> platform could >> be wildly different (since a lot of possible behaviors fall between >> the MAY >> and the MAY NOT in the proposed spec). >> Another concern is that the worst case performance aspects of >> LocalStorage >> remain. I cringe every time I think of one event loop blocking >> another. >> But I will admit that the average time would be better--especially >> if we're >> unlocking fairly aggressively. >> I'm interested to hear what others have to say on this proposal. >> J >> >> On Wed, Nov 4, 2009 at 3:31 PM, Rob Ennals <rob.ennals at gmail.com> >> wrote: >>> >>> Missed out the important final qualifier. Here's take 3: >>> >>> "the user agent MUST NOT release the storage mutex between calls >>> to local >>> storage, except that the user agent MAY release the storage mutex >>> on any API >>> operation /other that a local storage oeration/" >>> >>> If a local storage op can release the mutex then the whole thing is >>> pointless :-) >>> >>> -Rob >>> >>> On Nov 4, 2009, at 3:15 PM, Rob Ennals <rob.ennals at gmail.com> wrote: >>> >>>> I suspect my suggested spec line was insufficiently precise. How >>>> about >>>> this: >>>> >>>> "the user agent MUST NOT release the storage mutex between calls >>>> to local >>>> storage, except that the user agent MAY release the storage mutex >>>> on any API >>>> operation" >>>> >>>> We'd still need to define what "API operation" means, and I'm >>>> sure this >>>> could be worded better, but hopefully this makes the basic idea >>>> clearer. >>>> >>>> -Rob >>>> >>>> On Nov 4, 2009, at 2:56 PM, Mike Shaver <mike.shaver at gmail.com> >>>> wrote: >>>> >>>>> On Wed, Nov 4, 2009 at 5:51 PM, Rob Ennals >>>>> <rob.ennals at gmail.com> wrote: >>>>>> >>>>>> Or to put it another way: if the thread can't call an API then >>>>>> it can't >>>>>> block waiting for another storage mutex, thus deadlock can't >>>>>> occur, >>>>>> thus we >>>>>> don't need to release the storage mutex. >>>>> >>>>> Right, but the spec text there doesn't prevent the UA from >>>>> releasing >>>>> more than in that scenario, which seems like it's not an >>>>> improvement >>>>> over where we are right now: unpredictable consistency. >>>>> Existing racy >>>>> implementations like in IE would be conformant, so developers >>>>> can't >>>>> count on the script-sequenced-storage-ops pattern providing >>>>> transactionality. >>>>> >>>>> More likely, though, _I_'m missing something... >>>>> >>>>> Mike >>>> >> >> From giles at xiph.org Thu Nov 5 16:17:31 2009 From: giles at xiph.org (Ralph Giles) Date: Thu, 5 Nov 2009 16:17:31 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> Message-ID: <5d88ef650911051617p2d6f776fj7bd87b04ae39bfbc@mail.gmail.com> On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell <brian.p.campbell at dartmouth.edu> wrote: > As implemented by Safari and Chrome (which is the minimum rate allowed by > the spec), it's not really useful for that purpose, as 4 updates per second > makes any sort of synchronization feel jerky and laggy. It really depends what you're doing. It's fine for presentation slides, and not too bad for subtitles. I agree it's useless for anything moving faster than that. -r From rob.ennals at gmail.com Thu Nov 5 16:50:35 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Thu, 5 Nov 2009 16:50:35 -0800 Subject: [whatwg] Possible compremise for namespaces in html5 Message-ID: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> [this is Ron Ennals from Intel, posting from gmail on my phone while at tpac] I've talked to a few people about the distibuted extensibility problem and I'd like to suggest a possible compremise: * maintain a central registry of prefixes with standard meanings - so eg fb always means fbml. Thus no namespace decl is needed. * for a prefixed node the prefix is itself the namespace - thus the user agent doesn't need to know what a prefix means * prefixes are allowed for tags and attributes * a web browser MUST ignore prefix tags and attributes - they are for data, just like microdata and data attributes, not for browser extensions I believe this satisfies the most important requirement for the people who like namespaces and the people who don't. In particular: Reasons why namespaces etc are good: * allow data on a page without worrying about name clashes * copy and paste data from existing XML files into HTML * support markup like fbml, rails, etc - on the client as well as server * allow companies to include their own XML data inside an HTML file, for processing with other tools Reasons why namespaces are bad: * copy and paste breaks * the meaning of a tag depends on what namespaces you have * the encourage incompatible extentions to the browser * long namespace urls are horrible I've pitched this idea about a bit and got tentative buy in from some (but not all) people on both sides of the namespace divide. This idea is unashamedly derived from Liam Quin's similar proposal, tweaking the bits some people didn't like. Comments/bugs/stupidities... ??? [I'll probably post this to public-HTML too later, but I can't do that from gmail on my phone] -Rob From rob.ennals at gmail.com Thu Nov 5 16:54:43 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Thu, 5 Nov 2009 16:54:43 -0800 Subject: [whatwg] Possible compremise for namespaces in html5 In-Reply-To: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> References: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> Message-ID: <4A4B73AA-3151-4E46-9163-30DC9AE06C6B@gmail.com> Ug. s/compremise/compromise/ s/Ron Ennals/Rob Ennals/ I'm tired... -Rob On Nov 5, 2009, at 4:50 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > [this is Ron Ennals from Intel, posting from gmail on my phone while > at tpac] > > I've talked to a few people about the distibuted extensibility > problem and I'd like to suggest a possible compremise: > > * maintain a central registry of prefixes with standard meanings - > so eg fb always means fbml. Thus no namespace decl is needed. > * for a prefixed node the prefix is itself the namespace - thus the > user agent doesn't need to know what a prefix means > * prefixes are allowed for tags and attributes > * a web browser MUST ignore prefix tags and attributes - they are > for data, just like microdata and data attributes, not for browser > extensions > > > I believe this satisfies the most important requirement for the > people who like namespaces and the people who don't. In particular: > > Reasons why namespaces etc are good: > * allow data on a page without worrying about name clashes > * copy and paste data from existing XML files into HTML > * support markup like fbml, rails, etc - on the client as well as > server > * allow companies to include their own XML data inside an HTML file, > for processing with other tools > > Reasons why namespaces are bad: > * copy and paste breaks > * the meaning of a tag depends on what namespaces you have > * the encourage incompatible extentions to the browser > * long namespace urls are horrible > > I've pitched this idea about a bit and got tentative buy in from > some (but not all) people on both sides of the namespace divide. > > This idea is unashamedly derived from Liam Quin's similar proposal, > tweaking the bits some people didn't like. > > > Comments/bugs/stupidities... ??? > > > [I'll probably post this to public-HTML too later, but I can't do > that from gmail on my phone] > > -Rob From whatwg at adambarth.com Thu Nov 5 19:47:42 2009 From: whatwg at adambarth.com (Adam Barth) Date: Thu, 5 Nov 2009 19:47:42 -0800 Subject: [whatwg] Comments on @sandbox Message-ID: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com> As some of you know, WebKit is reviewing a patch to add the sandbox attribute to frames, as specced in HTML5. I'm hoping this will motivate various folks to review @sandbox and give their feedback. == allow-same-origin + allow-script == It's clear that adding both allow-same-origin and allow-script to @sandbox at the same time make the sandbox useless because the sandboxed content can simply reach outside the frame and remove the sandbox attribute. Should we disallow setting these values at the same time? If an author does set both, maybe we should only pay attention to one? == Mutability == One interesting feature of @sandbox is that the hosting page can change the value of the sandbox attribute. Even though it's clear that having both allow-same-origin and allow-script at the *same* time lets the sandboxed content escape, it's probably less clear to folks that first setting allow-same-origin and then removing it and adding allow-script is also very dangerous. The reason is slightly subtle. Essentially, when the frame is in the allow-same-origin mode, it is very easy for the outer document to leak a JavaScript object into the DOM of the inner document. Then, when the frame enters the allow-script phase, the document can abuse the leaked object to XSS the outer page, as described in http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf>. The reverse sequence is also dangerous because the inner page could use the techniques in this paper <http://www.adambarth.com/papers/2009/adida-barth-jackson.pdf> to build a fake DOM during the allow-scripts phase and confuse the outer page into XSSing itself in the allow-same-origin phase. To avoid these subtle traps for developers, I recommend to freezing the privileges of a sandboxed document at the time the document is loaded into the frame. == X-Sandbox == If a page contains a sandboxed frame, the document contained in the frame is only sandboxed because the user encountered the document via the frame. If the use encounters the same document directly (e.g., in a top-level browsing context), then the document will not be sandboxed. I recommend letting servers deliver the sandbox policy both via the sandbox attribute and via an HTTP header. The value of the HTTP header approach is that the document will be sandboxed in whatever context the user agent loads the document. For various esoteric reasons, I wrote up a description of how this might work on Mozilla's Wiki: <https://wiki.mozilla.org/Security/CSP/Sandbox>. In general, I think @sandbox is a useful primitive and I'm glad to see browser vendors starting to adopt it. Adam From rob.ennals at gmail.com Thu Nov 5 20:16:57 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Thu, 5 Nov 2009 20:16:57 -0800 Subject: [whatwg] Possible compremise for namespaces in html5 In-Reply-To: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> References: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> Message-ID: <f3fb55dd0911052016r72699b20n305ca763963fdfdf@mail.gmail.com> I talked to a few more people, resulting in the following additional requirement: "A prefixed node MUST NOT contain HTML nodes" This is to stop people creating prefixed nodes that replace HTML nodes, with resulting loss in universally understood semantics. Prefixed tag names are to be used only for data. If you want to add information to a node that contains HTML nodes, then this must either be done with a prefixed attribute, or microdata. This would break some existing practices, but those are arguably bad practices and should be changed. E.g. in Lift you can write: <lift:surround with="default" at="content"> ... some HTML ... </lift:surround> But this would be better done as <article lift:surround-with="default" lift:at="content"> ... some HTML ... </article> BTW: my previous email was wrong. Ruby markup isn't proper XML - I was confusing it with Lift. There is some question about exactly how best to map a prefix into a namespace. To enable polyglot files, we need to allow a user to write an xmlns decl that specifies the same namespace that the prefix automatically maps to, but XML does not allow a namespace to be just a string like "fbml" or "lift". One suggestion is to have a default mapping to something like "whatever:lift" - which would also be the namespace used by the HTML parser. There is then the question of whether createElementNs should accept a prefix in place of a namespace. Barring niggles, this version seems to have tentative buy-in from people on both "sides" of the namespace argument. -Rob On Thu, Nov 5, 2009 at 4:50 PM, Rob Ennals <rob.ennals at gmail.com> wrote: > [this is Ron Ennals from Intel, posting from gmail on my phone while at > tpac] > > I've talked to a few people about the distibuted extensibility problem and > I'd like to suggest a possible compremise: > > * maintain a central registry of prefixes with standard meanings - so eg fb > always means fbml. Thus no namespace decl is needed. > * for a prefixed node the prefix is itself the namespace - thus the user > agent doesn't need to know what a prefix means > * prefixes are allowed for tags and attributes > * a web browser MUST ignore prefix tags and attributes - they are for data, > just like microdata and data attributes, not for browser extensions > > > I believe this satisfies the most important requirement for the people who > like namespaces and the people who don't. In particular: > > Reasons why namespaces etc are good: > * allow data on a page without worrying about name clashes > * copy and paste data from existing XML files into HTML > * support markup like fbml, rails, etc - on the client as well as server > * allow companies to include their own XML data inside an HTML file, for > processing with other tools > > Reasons why namespaces are bad: > * copy and paste breaks > * the meaning of a tag depends on what namespaces you have > * the encourage incompatible extentions to the browser > * long namespace urls are horrible > > I've pitched this idea about a bit and got tentative buy in from some (but > not all) people on both sides of the namespace divide. > > This idea is unashamedly derived from Liam Quin's similar proposal, tweaking > the bits some people didn't like. > > > Comments/bugs/stupidities... ??? > > > [I'll probably post this to public-HTML too later, but I can't do that from > gmail on my phone] > > -Rob > From ian at hixie.ch Thu Nov 5 21:11:19 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 6 Nov 2009 05:11:19 +0000 (UTC) Subject: [whatwg] Comments on @sandbox In-Reply-To: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com> References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0911060506230.22553@hixie.dreamhostps.com> I'll respond in more depth later, but some quick notes since you're reviewing a patch: On Thu, 5 Nov 2009, Adam Barth wrote: > > One interesting feature of @sandbox is that the hosting page can change > the value of the sandbox attribute. Even though it's clear that having > both allow-same-origin and allow-script at the *same* time lets the > sandboxed content escape, it's probably less clear to folks that first > setting allow-same-origin and then removing it and adding allow-script > is also very dangerous. It's actually more dangerous than you describe, because, per spec, 'allow-same-origin' only takes effect when the nested page is loaded, whereas the allow-scripts value is live, so if it is set initially, then removed (which has no effect) and replaced with 'allow-scripts' (which does), the nested frame is same-origin with scripts enabled. There's currently a red warning in the spec about this. (We could resolve this by making 'allow-scripts' not be live.) > I recommend letting servers deliver the sandbox policy both via the > sandbox attribute and via an HTTP header. The value of the HTTP header > approach is that the document will be sandboxed in whatever context the > user agent loads the document. For various esoteric reasons, I wrote up > a description of how this might work on Mozilla's Wiki: > <https://wiki.mozilla.org/Security/CSP/Sandbox>. I agree, but I didn't want to get ahead of ourselves -- in particular given the work on CSP. We wouldn't want to end up with both. Also, some of the requirements may be a little different (e.g. CSP probably wants to disallow inline scripts but not external scripts, whereas here we're not worried about XSS within the sandboxed frame, so it doesn't make much sense to do that). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From whatwg at adambarth.com Thu Nov 5 21:26:24 2009 From: whatwg at adambarth.com (Adam Barth) Date: Thu, 5 Nov 2009 21:26:24 -0800 Subject: [whatwg] Comments on @sandbox In-Reply-To: <Pine.LNX.4.62.0911060506230.22553@hixie.dreamhostps.com> References: <7789133a0911051947l538ce87fk56be2cc44728233@mail.gmail.com> <Pine.LNX.4.62.0911060506230.22553@hixie.dreamhostps.com> Message-ID: <7789133a0911052126w2890ebf2nd7816b131fc90689@mail.gmail.com> On Thu, Nov 5, 2009 at 9:11 PM, Ian Hickson <ian at hixie.ch> wrote: > I'll respond in more depth later, but some quick notes since you're > reviewing a patch: Thanks. The plan is to implement the spec as currently written and then track changes to the spec. > On Thu, 5 Nov 2009, Adam Barth wrote: > It's actually more dangerous than you describe, because, per spec, > 'allow-same-origin' only takes effect when the nested page is loaded, > whereas the allow-scripts value is live, so if it is set initially, then > removed (which has no effect) and replaced with 'allow-scripts' (which > does), the nested frame is same-origin with scripts enabled. > > There's currently a red warning in the spec about this. I see. It seems confusing to have some of the attributes be live and others not. > (We could resolve this by making 'allow-scripts' not be live.) Yes. >> I recommend letting servers deliver the sandbox policy both via the >> sandbox attribute and via an HTTP header. ?The value of the HTTP header >> approach is that the document will be sandboxed in whatever context the >> user agent loads the document. ?For various esoteric reasons, I wrote up >> a description of how this might work on Mozilla's Wiki: >> <https://wiki.mozilla.org/Security/CSP/Sandbox>. > > I agree, but I didn't want to get ahead of ourselves -- in particular > given the work on CSP. We wouldn't want to end up with both. Also, some of > the requirements may be a little different (e.g. CSP probably wants to > disallow inline scripts but not external scripts, whereas here we're not > worried about XSS within the sandboxed frame, so it doesn't make much > sense to do that). I agree. This certainly doesn't block implementing @sandbox. I just wanted to include everything that was on my mind. Adam From yuzo at google.com Thu Nov 5 22:18:29 2009 From: yuzo at google.com (Yuzo Fujishima) Date: Fri, 6 Nov 2009 15:18:29 +0900 Subject: [whatwg] US-ASCII vs. ASCII in Web Socket Protocol Message-ID: <9124e09b0911052218y5106a2d4qcda01ff67577679b@mail.gmail.com> I see both "US-ASCII" and "ASCII" are used in: http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 If they mean the same thing, one should be used consistently. In the document, US-ASCII seems to mean encoding while ASCII mean charset. Is this common? (I guess US-ASCII is commonly considered as an alias for ASCII. http://en.wikipedia.org/wiki/ASCII#Aliases ) Yuzo From bruant at enseirb-matmeca.fr Thu Nov 5 22:32:35 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Thu, 05 Nov 2009 22:32:35 -0800 Subject: [whatwg] [WebWorkers] About the delegation example Message-ID: <4AF3C303.5070701@enseirb-matmeca.fr> Hi, First of all, there is a typo error in this example. The main HTML page is a copy/paste of the first example ("Worker example: One-core computation"). My point here is to ask for a new attribute for the navigator object that could describe the "best" number of workers in a delegation use case. In the delegation example, the number of workers chosen is an arbitrary 10. But, in a single-core processor, having only one worker will result in more or less the same running time, because at the end, each worker runs on the only core. This is just a waist of memory (and maybe time because of scheduling cost). On the other hand, on a 16-core processor (which doesn't exist yet, but is a realistic idea for the next couple of decades), the task could be executed faster with 16 workers. I've given the examples with cores, but the problem may be a little trickier. In the case of weird operating system, we can imagine that some ressources (some cores) are not available for user-land processes, so, the number I'm trying to describe is not just a hardware description. We can imagine this ressource restriction in virtualized operating systems too. The current best way to determine the number of worker that yields the ressouces in the best way is to run a benchmark on an increasing number of worker and stop it when the performance improvement stops. I hope you will admit that this way in not acceptable. Moreover, for a totally other purpose, this attribute could be used to make statistics on the spread of multicore processors like the statistics that are already done for operating system or screen resolution use. David From yuzo at google.com Thu Nov 5 23:12:43 2009 From: yuzo at google.com (Yuzo Fujishima) Date: Fri, 6 Nov 2009 16:12:43 +0900 Subject: [whatwg] Web Socket Protocol: Handling of erroneous UTF-8 on the server side? Message-ID: <9124e09b0911052312s58fb1689va7fddad50265baae@mail.gmail.com> Hi, Section 4.4 of http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54 specifies how erroneous UTF-8 must be handled on the client side. Does the same apply for the server side? Yuzo From yuzo at google.com Fri Nov 6 00:39:13 2009 From: yuzo at google.com (Yuzo Fujishima) Date: Fri, 6 Nov 2009 17:39:13 +0900 Subject: [whatwg] Web Socket Protocol: How Lenient Server Should Be in Handshake? Message-ID: <9124e09b0911060039y2ac6fbbfgb2914e428390a8c7@mail.gmail.com> Hi, As far as I can read from http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-54#section-5.2 the server should (or must?) accept requests starting with, say: POST<SPACE>/some/resource<SPACE>HTTP/1.0 or, even <SPACE>/some/resource<SPACE> Is a server expected to be this lenient? Yuzo From philipj at opera.com Fri Nov 6 01:44:24 2009 From: philipj at opera.com (=?iso-8859-15?Q?Philip_J=E4genstedt?=) Date: Fri, 06 Nov 2009 10:44:24 +0100 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> Message-ID: <op.u2yv0afnatwj1d@sisko.linkoping.osa> On Thu, 05 Nov 2009 21:11:15 +0100, Andrew Scherkus <scherkus at chromium.org> wrote: > On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell < > brian.p.campbell at dartmouth.edu> wrote: > >> On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: >> >> On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell < >>> Brian.P.Campbell at dartmouth.edu> wrote: >>> As a multimedia developer, I am wondering about the purpose of the >>> timeupdate event on media elements. On first glance, it would appear >>> that >>> this event would be useful for synchronizing animations, bullets, >>> captions, >>> UI, and the like. The spec specifies a rate of 4 to 66 Hz for these >>> events. >>> The high end of this (30 or more Hz) is pretty reasonable for >>> displaying >>> things in sync with the video. The low end, however, 4 Hz, is far too >>> slow >>> for most types of synchronization; everything feels laggy at this >>> frequency. >>> From my testing on a two year old MacBook Pro, Firefox is giving me >>> about 25 >>> timeupdate events per second, while Safari and Chrome are giving me >>> the bare >>> minimum, of 4 timeupdate events per second. >>> >>> At 4 timeupdate events per second, it isn't all that useful. I can >>> replace >>> it with setInterval, at whatever rate I want, query the time, and get >>> the >>> synchronization I need, but that makes the timeupdate event seem to be >>> redundant. At 25 timeupdate events per second, it is reasonably >>> useful, and >>> can be used to synchronize various things to the video. >>> >>> So, I'm wondering if there's a purpose for the timeupdate event that >>> I'm >>> missing. If it is intended for any sort of synchronization with the >>> video, I >>> think it should be improved to give better guarantees on the interval >>> between updates, or just dropped from the spec; it's not useful enough >>> in >>> its current form. To improve it, the maximum interval between updates >>> could >>> be reduced to about 40 ms, or perhaps the interval could be made >>> settable so >>> the author could control how often they want to get the event. >>> >>> -- Brian >>> >>> I believe it's a convenience over using setTimeout/setInterval + >>> polling >>> to determine whether playback has progressed ie., for rendering your >>> own >>> playback progress bar. I've also seen it been used as a signal to copy >>> frames into <canvas> on Firefox, however if timeupdate frequency != >>> fps of >>> video you either miss frames or paint too much. >>> >>> I don't think timeupdate today is very useful for doing anything >>> beyond a >>> progress bar or other simple synchronized animations. >>> >> >> Right. That's what I figured the point is; I just wanted to check to >> make >> sure I wasn't missing something. >> >> As implemented by Safari and Chrome (which is the minimum rate allowed >> by >> the spec), it's not really useful for that purpose, as 4 updates per >> second >> makes any sort of synchronization feel jerky and laggy. If it were done >> at >> the frame rate of the video, or perhaps with a minimum of 25 frames per >> second, it would be much more useful. Even at a minimum of 15 frames per >> second, you would still be able to get some sorts of useful >> synchronization, >> though animations synchronized wouldn't feel as smooth as they could. >> >> Would something like <video> firing events for every frame rendered >> help >>> you out? This would help also fix the <canvas> over/under painting >>> issue >>> and improve synchronization. >>> >> >> Yes, this would be considerably better than what is currently specced. >> >> -- Brian >> > > I'll see if we can do something for WebKit based browsers, because today > it > literally is hardcoded to 250ms for all ports. > http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254 > > Maybe we'll end up firing events based on frame updates for video, and > something arbitrary for audio (as it is today). > > Brian, since Firefox is doing what you proposed -- can you think of any > other issues with its current implementation? What about for audio > files? > > Thanks, > Andrew We've considered firing it for each frame, but there is one problem. If people expect that it fires once per frame they will probably write scripts which do frame-based animations by moving things n pixels per frame or similar. Some animations are just easier to do this way, so there's no reason to think that people won't do it. This will break horribly if a browser is ever forced to drop a frame, which is going to happen on slower machines. In balance this may or may not be a risk worth taking. -- Philip J?genstedt Core Developer Opera Software From robert at ocallahan.org Fri Nov 6 02:05:03 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Fri, 6 Nov 2009 23:05:03 +1300 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2yv0afnatwj1d@sisko.linkoping.osa> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> Message-ID: <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> On Fri, Nov 6, 2009 at 10:44 PM, Philip J?genstedt <philipj at opera.com>wrote: > We've considered firing it for each frame, but there is one problem. If > people expect that it fires once per frame they will probably write scripts > which do frame-based animations by moving things n pixels per frame or > similar. Some animations are just easier to do this way, so there's no > reason to think that people won't do it. This will break horribly if a > browser is ever forced to drop a frame, which is going to happen on slower > machines. In balance this may or may not be a risk worth taking. > That's possible, but we haven't noticed authors doing that yet. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091106/a565a321/attachment.htm> From hsivonen at iki.fi Fri Nov 6 02:47:11 2009 From: hsivonen at iki.fi (Henri Sivonen) Date: Fri, 6 Nov 2009 12:47:11 +0200 Subject: [whatwg] Possible compremise for namespaces in html5 In-Reply-To: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> References: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> Message-ID: <73F59CCF-57CF-4905-AD4E-BCD3DA2F5E1B@iki.fi> On Nov 6, 2009, at 02:50, Rob Ennals wrote: > I've talked to a few people about the distibuted extensibility > problem and I'd like to suggest a possible compremise: > > * maintain a central registry of prefixes with standard meanings - > so eg fb always means fbml. Thus no namespace decl is needed. > * for a prefixed node the prefix is itself the namespace - thus the > user agent doesn't need to know what a prefix means > * prefixes are allowed for tags and attributes > * a web browser MUST ignore prefix tags and attributes - they are > for data, just like microdata and data attributes, not for browser > extensions [...] > Comments/bugs/stupidities... ??? [Quoting a subsequent email.] > This would break some existing practices, but those are arguably bad > practices and should be changed. E.g. in Lift you can write: > <lift:surround with="default" at="content"> > ... some HTML ... > </lift:surround> So currently, given <lift:surround>, the HTML5 parsing algorithm creates an element node whose namespace is "http://www.w3.org/1999/ xhtml" and whose local name is "lift:surround". However, it's impossible to represent this kind of element in XML 1.0. Do I understand correctly that you are suggesting it would create an element node whose namespace is "lift" and whose local name is "surround"? (Thereby requiring xmlns:lift='lift' when used in XHTML5.) If so, what is the benefit of your proposal compared to the following scheme? 1) Names that contain the hyphen (-) character are extension names. 2) Extension element names are in the "http://www.w3.org/1999/xhtml" namespace for the purposes of DOM Level 2 or the Infoset. 3) Extension attribute names are in no namespace for the purposes of DOM Level 2 or the Infoset. 4) The prefix "aria" is reserved for ARIA. 5) The prefix "http" is grandfathered as a reserved non-extension (for http-equiv). Hence, given <lift-surround>, you'd get an element node whose namespace is "http://www.w3.org/1999/xhtml" and local name is "lift- surround". This element can be represented in XML 1.0. Furthermore, this scheme wouldn't require changes to either HTML or XML parsing. As far as I can tell, this scheme would put as much information in the DOM as your scheme. However, this scheme has the upside that it doesn't require any parser changes (Degrade Gracefully) and produces the same DOM in both text/html and application/xhtml+xml (DOM Consistency). This scheme has the political downside that it doesn't use the colon or vary the namespaceURI DOM property. This scheme also has the downside that you can't use existing wildcarding mechanisms for selecting all elements that come from the 'lift' extension, but the use cases for such wildcarding seem to be of questionable utility to me. Especially when you stipulate that extension subtrees wouldn't mix standard elements, it seems sufficient to select on the root of the 'lift' extension subtrees and then traverse the subtrees. (Of course, all of the above is just a syntactic hypothetical. It isn't clear to me what use cases are being addressed. Has Facebook reported the lack of a formally blessed way of doing FBML as a problem?) -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/ From simonp at opera.com Fri Nov 6 03:16:06 2009 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Nov 2009 12:16:06 +0100 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> Message-ID: <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> On Fri, 06 Nov 2009 11:05:03 +0100, Robert O'Callahan <robert at ocallahan.org> wrote: > On Fri, Nov 6, 2009 at 10:44 PM, Philip J?genstedt > <philipj at opera.com>wrote: > >> We've considered firing it for each frame, but there is one problem. If >> people expect that it fires once per frame they will probably write >> scripts >> which do frame-based animations by moving things n pixels per frame or >> similar. Some animations are just easier to do this way, so there's no >> reason to think that people won't do it. This will break horribly if a >> browser is ever forced to drop a frame, which is going to happen on >> slower >> machines. In balance this may or may not be a risk worth taking. >> > > That's possible, but we haven't noticed authors doing that yet. http://people.mozilla.com/~prouget/demos/round/index.xhtml -- Simon Pieters Opera Software From rob.ennals at gmail.com Fri Nov 6 06:56:55 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Fri, 6 Nov 2009 06:56:55 -0800 Subject: [whatwg] Possible compremise for namespaces in html5 In-Reply-To: <73F59CCF-57CF-4905-AD4E-BCD3DA2F5E1B@iki.fi> References: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com> <73F59CCF-57CF-4905-AD4E-BCD3DA2F5E1B@iki.fi> Message-ID: <AB7A58E5-3ECD-44B6-B350-A4E8390540FB@gmail.com> You understand things correctly. What you propose was also suggested by several people at tpac and may well be the right approach. The argument in favor of colon was that it might fit better with the existing namespace way of doing stuff in XML. But it's not clear that that is really the case. -Rob On Nov 6, 2009, at 2:47 AM, Henri Sivonen <hsivonen at iki.fi> wrote: > On Nov 6, 2009, at 02:50, Rob Ennals wrote: > >> I've talked to a few people about the distibuted extensibility >> problem and I'd like to suggest a possible compremise: >> >> * maintain a central registry of prefixes with standard meanings - >> so eg fb always means fbml. Thus no namespace decl is needed. >> * for a prefixed node the prefix is itself the namespace - thus the >> user agent doesn't need to know what a prefix means >> * prefixes are allowed for tags and attributes >> * a web browser MUST ignore prefix tags and attributes - they are >> for data, just like microdata and data attributes, not for browser >> extensions > [...] >> Comments/bugs/stupidities... ??? > [Quoting a subsequent email.] >> This would break some existing practices, but those are arguably bad >> practices and should be changed. E.g. in Lift you can write: >> <lift:surround with="default" at="content"> >> ... some HTML ... >> </lift:surround> > > > So currently, given <lift:surround>, the HTML5 parsing algorithm > creates an element node whose namespace is "http://www.w3.org/1999/xhtml > " and whose local name is "lift:surround". However, it's impossible > to represent this kind of element in XML 1.0. > > Do I understand correctly that you are suggesting it would create an > element node whose namespace is "lift" and whose local name is > "surround"? (Thereby requiring xmlns:lift='lift' when used in XHTML5.) > > If so, what is the benefit of your proposal compared to the > following scheme? > > 1) Names that contain the hyphen (-) character are extension names. > 2) Extension element names are in the "http://www.w3.org/1999/xhtml" > namespace for the purposes of DOM Level 2 or the Infoset. > 3) Extension attribute names are in no namespace for the purposes of > DOM Level 2 or the Infoset. > 4) The prefix "aria" is reserved for ARIA. > 5) The prefix "http" is grandfathered as a reserved non-extension > (for http-equiv). > > Hence, given <lift-surround>, you'd get an element node whose > namespace is "http://www.w3.org/1999/xhtml" and local name is "lift- > surround". This element can be represented in XML 1.0. Furthermore, > this scheme wouldn't require changes to either HTML or XML parsing. > > As far as I can tell, this scheme would put as much information in > the DOM as your scheme. However, this scheme has the upside that it > doesn't require any parser changes (Degrade Gracefully) and produces > the same DOM in both text/html and application/xhtml+xml (DOM > Consistency). This scheme has the political downside that it doesn't > use the colon or vary the namespaceURI DOM property. > > This scheme also has the downside that you can't use existing > wildcarding mechanisms for selecting all elements that come from the > 'lift' extension, but the use cases for such wildcarding seem to be > of questionable utility to me. Especially when you stipulate that > extension subtrees wouldn't mix standard elements, it seems > sufficient to select on the root of the 'lift' extension subtrees > and then traverse the subtrees. > > (Of course, all of the above is just a syntactic hypothetical. It > isn't clear to me what use cases are being addressed. Has Facebook > reported the lack of a formally blessed way of doing FBML as a > problem?) > > -- > Henri Sivonen > hsivonen at iki.fi > http://hsivonen.iki.fi/ > > From brian.p.campbell at dartmouth.edu Fri Nov 6 09:11:14 2009 From: brian.p.campbell at dartmouth.edu (Brian Campbell) Date: Fri, 6 Nov 2009 12:11:14 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <5d88ef650911051617p2d6f776fj7bd87b04ae39bfbc@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <5d88ef650911051617p2d6f776fj7bd87b04ae39bfbc@mail.gmail.com> Message-ID: <AB0B6BFC-6F87-49F8-9A88-188BE87D0921@dartmouth.edu> On Nov 5, 2009, at 7:17 PM, Ralph Giles wrote: > On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell > <brian.p.campbell at dartmouth.edu> wrote: > >> As implemented by Safari and Chrome (which is the minimum rate >> allowed by >> the spec), it's not really useful for that purpose, as 4 updates >> per second >> makes any sort of synchronization feel jerky and laggy. > > It really depends what you're doing. It's fine for presentation > slides, and not too bad for subtitles. I agree it's useless for > anything moving faster than that. Our major use case is actually synchronizing bullets, slide changes, and the like with video, in educational multimedia produced with high production values. I've seen our artists tweak timing of bullets and slide changes to within about 1/15th of a second in order to get just the right synchronization; our current system has a 1/30th second resolution, and I've seen people make changes of 2 frames in order to get the synchronization just right. For captions, or for synchronizing slides when you don't care about the precise sync as much, quarter second resolution might be enough, but for anything where you need to get the sync to really feel tight, it's insufficient. -- Brian From brian.p.campbell at dartmouth.edu Fri Nov 6 09:11:18 2009 From: brian.p.campbell at dartmouth.edu (Brian Campbell) Date: Fri, 6 Nov 2009 12:11:18 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> Message-ID: <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> On Nov 5, 2009, at 3:11 PM, Andrew Scherkus wrote: > On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell <brian.p.campbell at dartmouth.edu > > wrote: > On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: > > On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell <Brian.P.Campbell at dartmouth.edu > > wrote: > As a multimedia developer, I am wondering about the purpose of the > timeupdate event on media elements. On first glance, it would appear > that this event would be useful for synchronizing animations, > bullets, captions, UI, and the like. The spec specifies a rate of 4 > to 66 Hz for these events. The high end of this (30 or more Hz) is > pretty reasonable for displaying things in sync with the video. The > low end, however, 4 Hz, is far too slow for most types of > synchronization; everything feels laggy at this frequency. From my > testing on a two year old MacBook Pro, Firefox is giving me about 25 > timeupdate events per second, while Safari and Chrome are giving me > the bare minimum, of 4 timeupdate events per second. > > At 4 timeupdate events per second, it isn't all that useful. I can > replace it with setInterval, at whatever rate I want, query the > time, and get the synchronization I need, but that makes the > timeupdate event seem to be redundant. At 25 timeupdate events per > second, it is reasonably useful, and can be used to synchronize > various things to the video. > > So, I'm wondering if there's a purpose for the timeupdate event that > I'm missing. If it is intended for any sort of synchronization with > the video, I think it should be improved to give better guarantees > on the interval between updates, or just dropped from the spec; it's > not useful enough in its current form. To improve it, the maximum > interval between updates could be reduced to about 40 ms, or perhaps > the interval could be made settable so the author could control how > often they want to get the event. > > -- Brian > > I believe it's a convenience over using setTimeout/setInterval + > polling to determine whether playback has progressed ie., for > rendering your own playback progress bar. I've also seen it been > used as a signal to copy frames into <canvas> on Firefox, however if > timeupdate frequency != fps of video you either miss frames or paint > too much. > > I don't think timeupdate today is very useful for doing anything > beyond a progress bar or other simple synchronized animations. > > Right. That's what I figured the point is; I just wanted to check to > make sure I wasn't missing something. > > As implemented by Safari and Chrome (which is the minimum rate > allowed by the spec), it's not really useful for that purpose, as 4 > updates per second makes any sort of synchronization feel jerky and > laggy. If it were done at the frame rate of the video, or perhaps > with a minimum of 25 frames per second, it would be much more > useful. Even at a minimum of 15 frames per second, you would still > be able to get some sorts of useful synchronization, though > animations synchronized wouldn't feel as smooth as they could. > > Would something like <video> firing events for every frame rendered > help you out? This would help also fix the <canvas> over/under > painting issue and improve synchronization. > > Yes, this would be considerably better than what is currently specced. > > -- Brian > > I'll see if we can do something for WebKit based browsers, because > today it literally is hardcoded to 250ms for all ports. > http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254 > > Maybe we'll end up firing events based on frame updates for video, > and something arbitrary for audio (as it is today). > > Brian, since Firefox is doing what you proposed -- can you think of > any other issues with its current implementation? What about for > audio files? The way Firefox works is fine for me. I haven't yet tested it with audio only, but something around 25 or 30 updates per second would work fine for all use cases that I have; 15 updates per second is about the minimum I'd consider useful for synchronizing one off events like bullets or slide transitions (this is for stuff where you want good, tight sync for stuff with high production values), and while animations would work at that rate, they'd be pretty jerky. -- Brian From eric.carlson at apple.com Fri Nov 6 09:20:10 2009 From: eric.carlson at apple.com (Eric Carlson) Date: Fri, 06 Nov 2009 09:20:10 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2yv0afnatwj1d@sisko.linkoping.osa> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> Message-ID: <4745090F-6D40-49EA-919C-AB98001E150C@apple.com> On Nov 6, 2009, at 1:44 AM, Philip J?genstedt wrote: > We've considered firing it for each frame, but there is one problem. > If people expect that it fires once per frame they will probably > write scripts which do frame-based animations by moving things n > pixels per frame or similar. Some animations are just easier to do > this way, so there's no reason to think that people won't do it. > This will break horribly if a browser is ever forced to drop a > frame, which is going to happen on slower machines. In balance this > may or may not be a risk worth taking. > I share Philip's concern. eric From jackalmage at gmail.com Fri Nov 6 10:29:59 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 6 Nov 2009 10:29:59 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <4AF3C303.5070701@enseirb-matmeca.fr> References: <4AF3C303.5070701@enseirb-matmeca.fr> Message-ID: <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> On Thu, Nov 5, 2009 at 10:32 PM, David Bruant <bruant at enseirb-matmeca.fr> wrote: > Hi, > > First of all, there is a typo error in this example. The main HTML page > is a copy/paste of the first example ("Worker example: One-core > computation"). > > My point here is to ask for a new attribute for the navigator object > that could describe the "best" number of workers in a delegation use case. > > In the delegation example, the number of workers chosen is an arbitrary > 10. But, in a single-core processor, having only one worker will result > in more or less the same running time, because at the end, each worker > runs on the only core. This is just a waist of memory (and maybe time > because of scheduling cost). This is not true. The naive way of coding it without workers may freeze the UI whenever doing heavy computation. To ensure that you can avoid this you have to be very explicit about breaking up your algorithm into chunks that you can chain together with setTimeout. Offloading the heavy computation to a worker allows you to code in the naive style (which is much easier to both code and understand) without the risk of UI-freeze. (I don't know the details, but it also seems possible that the context-switching between main page and worker may be cheaper than heavy setTimeout use. Someone else would have to confirm/deny this.) > On the other hand, on a 16-core processor (which doesn't exist yet, but > is a realistic idea for the next couple of decades), the task could be > executed faster with 16 workers. Try 2 years, if AMD's press releases can be trusted. ^_^ > The current best way to determine the number of worker that yields the > ressouces in the best way is to run a benchmark on an increasing number > of worker and stop it when the performance improvement stops. > I hope you will admit that this way in not acceptable. I'm interested in seeing if browsers can provide reasonably accurate estimates of this. ~TJ From bruant at enseirb-matmeca.fr Fri Nov 6 10:50:12 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Fri, 06 Nov 2009 10:50:12 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> Message-ID: <4AF46FE4.1060302@enseirb-matmeca.fr> Tab Atkins Jr. a ?crit : > On Thu, Nov 5, 2009 at 10:32 PM, David Bruant <bruant at enseirb-matmeca.fr> wrote: > >> Hi, >> >> First of all, there is a typo error in this example. The main HTML page >> is a copy/paste of the first example ("Worker example: One-core >> computation"). >> >> My point here is to ask for a new attribute for the navigator object >> that could describe the "best" number of workers in a delegation use case. >> >> In the delegation example, the number of workers chosen is an arbitrary >> 10. But, in a single-core processor, having only one worker will result >> in more or less the same running time, because at the end, each worker >> runs on the only core. This is just a waist of memory (and maybe time >> because of scheduling cost). >> > > This is not true. The naive way of coding it without workers may > freeze the UI whenever doing heavy computation. To ensure that you > can avoid this you have to be very explicit about breaking up your > algorithm into chunks that you can chain together with setTimeout. > Offloading the heavy computation to a worker allows you to code in the > naive style (which is much easier to both code and understand) without > the risk of UI-freeze. > > (I don't know the details, but it also seems possible that the > context-switching between main page and worker may be cheaper than > heavy setTimeout use. Someone else would have to confirm/deny this.) > When I say "having only one worker will result in more or less the same running time", I mean "one worker on top of the main delegating browsing context". So, I compare "the main browsing context + 10 workers" with "the main browsing context + 1 worker" (or 16 in the next example). In all what I say, there is no need to change the architecture of the program of to use timers, just the JS variable "num_workers". Sorry for the misunderstanding. >> On the other hand, on a 16-core processor (which doesn't exist yet, but >> is a realistic idea for the next couple of decades), the task could be >> executed faster with 16 workers. >> > > Try 2 years, if AMD's press releases can be trusted. ^_^ > > >> The current best way to determine the number of worker that yields the >> ressouces in the best way is to run a benchmark on an increasing number >> of worker and stop it when the performance improvement stops. >> I hope you will admit that this way in not acceptable. >> > > I'm interested in seeing if browsers can provide reasonably accurate > estimates of this. > > ~TJ > David From brian.p.campbell at dartmouth.edu Fri Nov 6 11:02:31 2009 From: brian.p.campbell at dartmouth.edu (Brian Campbell) Date: Fri, 6 Nov 2009 14:02:31 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> Message-ID: <3351E5D2-12F2-4FE6-82F3-358FDB9F4F71@dartmouth.edu> On Nov 6, 2009, at 6:16 AM, Simon Pieters wrote: > On Fri, 06 Nov 2009 11:05:03 +0100, Robert O'Callahan <robert at ocallahan.org > > wrote: > >> On Fri, Nov 6, 2009 at 10:44 PM, Philip J?genstedt >> <philipj at opera.com>wrote: >> >>> We've considered firing it for each frame, but there is one >>> problem. If >>> people expect that it fires once per frame they will probably >>> write scripts >>> which do frame-based animations by moving things n pixels per >>> frame or >>> similar. Some animations are just easier to do this way, so >>> there's no >>> reason to think that people won't do it. This will break horribly >>> if a >>> browser is ever forced to drop a frame, which is going to happen >>> on slower >>> machines. In balance this may or may not be a risk worth taking. >>> >> >> That's possible, but we haven't noticed authors doing that yet. > > http://people.mozilla.com/~prouget/demos/round/index.xhtml Hmm. That's a quick and dirty demo that just does a silly effect on each frame. It should be dependent on the current time of the video, as should any animation; for instance, if that demo worked at all on WebKit, it would go glacially slowly. Anyone who does animation that depends on their update function being called at a constant rate is going to be broken; are we trying to avoid that case? Is there anyone out there who uses setInterval and increments anything a constant amount each time, rather than basing progress on how much time has actually elapsed? I agree that there is some concern here, but I'm wondering how much it's worth worrying about. No matter what, there aren't any hard guarantees about how much time will elapse between timeupdate events (the thread could block for some reason, the user could scrub the video, the video could stall or be paused). And no matter what, if timeupdate events come in at any sort of regular rate (whether it be the frame rate, or an arbitrary rate like 4 or 30 times per second, or if they bypass timeupdate entirely and just use setInterval), there are going to be some people who mistakenly assume that they can just do a constant increment each time they are called. So, I think those users will have errors whether or not timeupdate happens once per frame or at some other interval. Anyhow, for my purposes, once per frame, or 30 times per second, or anything like that, are all fairly reasonable. 4 updates per second means that I'm just going to have to replace it with setInterval, and am much more likely to forget to disable that setInterval when, say, the video is paused, leading to extra wasted CPU cycles. -- Brian From bzbarsky at MIT.EDU Fri Nov 6 11:30:11 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Fri, 06 Nov 2009 14:30:11 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <3351E5D2-12F2-4FE6-82F3-358FDB9F4F71@dartmouth.edu> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> <3351E5D2-12F2-4FE6-82F3-358FDB9F4F71@dartmouth.edu> Message-ID: <4AF47943.7070803@mit.edu> On 11/6/09 2:02 PM, Brian Campbell wrote: > Is there anyone out there who uses setInterval and increments > anything a constant amount each time, rather than basing progress on how > much time has actually elapsed? Yes, mostly people who are writing so-called performance tests or not caring how their stuff actually looks. These are the same folks who use setInterval(0), of course. -Boris From robert at ocallahan.org Fri Nov 6 12:31:17 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 7 Nov 2009 09:31:17 +1300 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <11e306600911060205y502d265ax59d84d597ec7431b@mail.gmail.com> <op.u2yz81w3idj3kv@zcorpandell.linkoping.osa> Message-ID: <11e306600911061231n68d1fb88scc3800ed70fd4812@mail.gmail.com> On Sat, Nov 7, 2009 at 12:16 AM, Simon Pieters <simonp at opera.com> wrote: > On Fri, 06 Nov 2009 11:05:03 +0100, Robert O'Callahan < > robert at ocallahan.org> wrote: > > On Fri, Nov 6, 2009 at 10:44 PM, Philip J?genstedt <philipj at opera.com >> >wrote: >> >> We've considered firing it for each frame, but there is one problem. If >>> people expect that it fires once per frame they will probably write >>> scripts >>> which do frame-based animations by moving things n pixels per frame or >>> similar. Some animations are just easier to do this way, so there's no >>> reason to think that people won't do it. This will break horribly if a >>> browser is ever forced to drop a frame, which is going to happen on >>> slower >>> machines. In balance this may or may not be a risk worth taking. >>> >>> >> That's possible, but we haven't noticed authors doing that yet. >> > > http://people.mozilla.com/~prouget/demos/round/index.xhtml<http://people.mozilla.com/%7Eprouget/demos/round/index.xhtml> > Aha, good catch. But I agree with Brian. These people are just as likely to use setTimeout(0), and that's broken too. Users of scripted animation APIs who advance their animations by a fixed amount per callback are guaranteed to lose no matter what period the callback nominally has. The only thing we could do is require callback intervals to be highly random so authors notice jerkiness and fix their code :-). Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091107/214a8c19/attachment.htm> From bent.mozilla at gmail.com Fri Nov 6 13:41:36 2009 From: bent.mozilla at gmail.com (ben turner) Date: Fri, 6 Nov 2009 13:41:36 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <4AF46FE4.1060302@enseirb-matmeca.fr> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> Message-ID: <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> I think it's important to note that there is no guarantee that each worker is tied to an actual OS-level thread. Firefox, for instance, will schedule workers on a limited number of OS threads to prevent resource swamping. Other implementations (Chromium only?) create new processes to run worker code. The only guarantee is that code executed in a worker will not block the main thread. -Ben From shadow2531 at gmail.com Fri Nov 6 14:08:30 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Fri, 06 Nov 2009 17:08:30 -0500 Subject: [whatwg] <object> behavior In-Reply-To: <Pine.LNX.4.62.0910160621020.25383@hixie.dreamhostps.com> References: <4A7ACFB1.8030808@ado.is-a-geek.net> <4A7AE539.6020406@mit.edu> <Pine.LNX.4.62.0908140155380.6420@hixie.dreamhostps.com> <4A85320D.2060102@ado.is-a-geek.net> <Pine.LNX.4.62.0908242325300.13789@hixie.dreamhostps.com> <4A93A385.5020005@ado.is-a-geek.net> <Pine.LNX.4.62.0908310906470.6775@hixie.dreamhostps.com> <4A9BCF43.1080206@mit.edu> <Pine.LNX.4.62.0909020152530.6775@hixie.dreamhostps.com> <4AA4053B.8080107@mit.edu> <Pine.LNX.4.62.0909132154440.14605@hixie.dreamhostps.com> <4AAE3A22.3070300@mit.edu> <op.u0f250wi1ejg13@sandra-svwliu01> <4AB37A7C.3010009@mit.edu> <op.u0gh6jv01ejg13@sandra-svwliu01> <4AB3D4DB.7070502@mit.edu> <op.u0g406uw1ejg13@sandra-svwliu01> <4AB67927.9080209@mit.edu> <op.u0lq8npj1ejg13@sandra-svwliu01> <Pine.LNX.4.62.0910160621020.25383@hixie.dreamhostps.com> Message-ID: <op.u2zuggti1ejg13@sandra-svwliu01> On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson <ian at hixie.ch> wrote: > On Sun, 20 Sep 2009, Michael A. Puls II wrote: >> >> O.K., so put simply, HTML5 should explicitly mention that the css >> display property for <object>, <embed> (and <applet> in the handling >> section) has absolutely no effect on plug-in instantiation and >> destroying and has absolutely no effect on @src and @data resource >> fetching. >> >> HTML5 could also be extra clear by example that display: none doesn't >> destroy, or prevent the creation of, the plug-in instance and that >> changing the display value doesn't destroy the instance. >> >> Lastly, HTML5 could briefly mention that what the plug-in does when its >> window/area is not displayed because of display: none, is plug-in and >> plug-in API dependent. > > I've added a note to this effect. Also see <https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68>. Should probably add a note in the spec that the css overflow and position properties don't affect instantiation/destroying etc. (might as well add visibility too). And, after that, it'd probably be best to note that css in general doesn't affect instantiation/destroying (to avoid having to keep on adding CSS properties to the list) Something like this: Note: The above algorithm is independent of CSS. For example, it runs even if the element is hidden or out-of-view because of the 'display', 'position', 'visibility' and 'overflow' properties. Further, changing the value of any CSS property does not cause the above algorithm to run again on the element. For example, changing the element's 'display' property from 'inline-block' to 'none' does not destroy the loaded resource. -- Michael From bruant at enseirb-matmeca.fr Fri Nov 6 14:41:15 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Fri, 06 Nov 2009 14:41:15 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> Message-ID: <4AF4A60B.4030207@enseirb-matmeca.fr> ben turner a ?crit : > I think it's important to note that there is no guarantee that each > worker is tied to an actual OS-level thread. Firefox, for instance, > will schedule workers on a limited number of OS threads to prevent > resource swamping. Other implementations (Chromium only?) create new > processes to run worker code. The only guarantee is that code executed > in a worker will not block the main thread. > I didn't know the differences between the current web workers implementations and that's interesting. The problem with developing JS code using Web workers in a delegation use case is that you cannot predict what is the hardware, the OS and the browser you will run your code on. So, what is the "right", "best" number of workers to use ? 1, 10, 16, 1000 ? It is not a defined number, it depends on hardware, OS and browser (or any user agent, of course). My point is to give this information to the developer. If FF decides that all the workers will run on 3 OS threads even if you're on a 16-core, my number is 3. If you're in Chrome and your OS allows you to create only one more process, this number is 1. If you're in Chrome and your OS allow you to create "as many processes as you want" on a quad-core, this number is 4. But for each case, the web browser can ask this information to the OS (once when you install it ? each time you open your browser ? dynamically ?). This information is available (and shouldn't be that hard to retrieve !) and can be given to the web developer. David > -Ben > From simonp at opera.com Fri Nov 6 14:52:42 2009 From: simonp at opera.com (Simon Pieters) Date: Fri, 06 Nov 2009 23:52:42 +0100 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> Message-ID: <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> On Fri, 06 Nov 2009 18:11:18 +0100, Brian Campbell <brian.p.campbell at dartmouth.edu> wrote: >> Brian, since Firefox is doing what you proposed -- can you think of any >> other issues with its current implementation? What about for audio >> files? > > The way Firefox works is fine for me. I haven't yet tested it with audio > only, but something around 25 or 30 updates per second would work fine > for all use cases that I have; 15 updates per second is about the > minimum I'd consider useful for synchronizing one off events like > bullets or slide transitions (this is for stuff where you want good, > tight sync for stuff with high production values), and while animations > would work at that rate, they'd be pretty jerky. What if you have a video with say one frame per second? Unless I'm mistaken Firefox will still fire timeupdate once per frame. (The spec says you have to fire at least every 250ms.) -- Simon Pieters Opera Software From atwilson at google.com Fri Nov 6 15:01:39 2009 From: atwilson at google.com (Drew Wilson) Date: Fri, 6 Nov 2009 15:01:39 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <4AF4A60B.4030207@enseirb-matmeca.fr> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> <4AF4A60B.4030207@enseirb-matmeca.fr> Message-ID: <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> I think I understand what you're trying to achieve, but it's not clear to me that giving the web page a snapshot count of "free cores" is actually going to do what you want, given that the number of free cores can vary greatly over time. For example, I launch your page, the browser tells you that there are 16 free cores, then I decide to play a flash game or watch video in another tab. Suddenly, the number of free cores is no longer correct. Alternatively, I launch your page, then I launch *another* copy of your page. What happens? Exposing information that's not reliable seems worse than not exposing it at all, and would encourage applications to grab all available resources (after all, that's the purpose of the API!). And the problem domains that would benefit from this information (arbitrarily parallelizable algorithms like ray tracing) seem to be few in number. -atw On Fri, Nov 6, 2009 at 2:41 PM, David Bruant <bruant at enseirb-matmeca.fr>wrote: > ben turner a ?crit : > > I think it's important to note that there is no guarantee that each > > worker is tied to an actual OS-level thread. Firefox, for instance, > > will schedule workers on a limited number of OS threads to prevent > > resource swamping. Other implementations (Chromium only?) create new > > processes to run worker code. The only guarantee is that code executed > > in a worker will not block the main thread. > > > I didn't know the differences between the current web workers > implementations and that's interesting. > The problem with developing JS code using Web workers in a delegation > use case is that you cannot predict what is the hardware, the OS and the > browser you will run your code on. So, what is the "right", "best" > number of workers to use ? 1, 10, 16, 1000 ? It is not a defined number, > it depends on hardware, OS and browser (or any user agent, of course). > > My point is to give this information to the developer. > > If FF decides that all the workers will run on 3 OS threads even if > you're on a 16-core, my number is 3. If you're in Chrome and your OS > allows you to create only one more process, this number is 1. If you're > in Chrome and your OS allow you to create "as many processes as you > want" on a quad-core, this number is 4. But for each case, the web > browser can ask this information to the OS (once when you install it ? > each time you open your browser ? dynamically ?). > > This information is available (and shouldn't be that hard to retrieve !) > and can be given to the web developer. > > David > > > -Ben > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091106/1a248eaf/attachment-0001.htm> From bruant at enseirb-matmeca.fr Fri Nov 6 15:43:57 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Fri, 06 Nov 2009 15:43:57 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> <4AF4A60B.4030207@enseirb-matmeca.fr> <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> Message-ID: <4AF4B4BD.2070105@enseirb-matmeca.fr> Drew Wilson a ?crit : > I think I understand what you're trying to achieve, but it's not clear > to me that giving the web page a snapshot count of "free cores" is > actually going to do what you want, given that the number of free > cores can vary greatly over time. > > For example, I launch your page, the browser tells you that there are > 16 free cores, then I decide to play a flash game or watch video in > another tab. Suddenly, the number of free cores is no longer correct. > Alternatively, I launch your page, then I launch *another* copy of > your page. What happens? I agree on the fact the a dynamic computation is not a good idea. However, I still think that a number computed at opening time with only static values, like number of cores, number of threads/processes allowed is a good idea. The installation time is not a good idea because after installation, hardware and OS configuration can be changed (the OS configs can also be changed while you're running your web browser, but the relative inaccuracy lifetime is very short). > > Exposing information that's not reliable seems worse than not exposing > it at all, and would encourage applications to grab all available > resources (after all, that's the purpose of the API!). And the problem > domains that would benefit from this information (arbitrarily > parallelizable algorithms like ray tracing) seem to be few in number. Even if I know that it's true, I don't think it's a good argument to refuse to add this attibute. The problem domains are few in number, but for these problems, having this information is very useful. In all the example we can find on the web the number of workers is always arbitrary and, in my humble opinion, arbitrary is almost never the best solution of any problem. Moreover, the problem domains are few in number today, but we have no idea of how the web applications will be designed tomorrow. David > > -atw > > On Fri, Nov 6, 2009 at 2:41 PM, David Bruant > <bruant at enseirb-matmeca.fr <mailto:bruant at enseirb-matmeca.fr>> wrote: > > ben turner a ?crit : > > I think it's important to note that there is no guarantee that each > > worker is tied to an actual OS-level thread. Firefox, for instance, > > will schedule workers on a limited number of OS threads to prevent > > resource swamping. Other implementations (Chromium only?) create new > > processes to run worker code. The only guarantee is that code > executed > > in a worker will not block the main thread. > > > I didn't know the differences between the current web workers > implementations and that's interesting. > The problem with developing JS code using Web workers in a delegation > use case is that you cannot predict what is the hardware, the OS > and the > browser you will run your code on. So, what is the "right", "best" > number of workers to use ? 1, 10, 16, 1000 ? It is not a defined > number, > it depends on hardware, OS and browser (or any user agent, of course). > > My point is to give this information to the developer. > > If FF decides that all the workers will run on 3 OS threads even if > you're on a 16-core, my number is 3. If you're in Chrome and your OS > allows you to create only one more process, this number is 1. If > you're > in Chrome and your OS allow you to create "as many processes as you > want" on a quad-core, this number is 4. But for each case, the web > browser can ask this information to the OS (once when you install it ? > each time you open your browser ? dynamically ?). > > This information is available (and shouldn't be that hard to > retrieve !) > and can be given to the web developer. > > David > > > -Ben > > > > From bnkuhn at gmail.com Fri Nov 6 16:22:39 2009 From: bnkuhn at gmail.com (Brian Kuhn) Date: Fri, 6 Nov 2009 16:22:39 -0800 Subject: [whatwg] should async scripts block the document's load event? In-Reply-To: <335a812d0911031255l696cddd6nb04f66420fedbdb4@mail.gmail.com> References: <335a812d0911031255l696cddd6nb04f66420fedbdb4@mail.gmail.com> Message-ID: <335a812d0911061622x4a94a603wed86c0b02c0b9dfa@mail.gmail.com> No one has any thoughts on this? It seems to me that the purpose of async scripts is to get out of the way of user-visible functionality. Many sites currently attach user-visible functionality to window.onload, so it would be great if async scripts at least had a way to not block that event. It would help minimize the affect that secondary-functionality like ads and web analytics have on the user experience. -Brian On Tue, Nov 3, 2009 at 12:55 PM, Brian Kuhn <bnkuhn at gmail.com> wrote: > In section 4.3.1<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-async>, > it says: > > *Fetching an external script must delay the load event of the element's > document until the task that is queued by the networking task source once > the resource has been fetched (defined above) has been run.* > > Has any thought been put into changing this for async scripts? It seems > like it might be worthwhile to allow window.onload to fire while an async > script is still downloading if everything else is done. > > Thanks, > Brian > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091106/7f4864d7/attachment.htm> From robert at ocallahan.org Fri Nov 6 16:37:36 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Sat, 7 Nov 2009 13:37:36 +1300 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> Message-ID: <11e306600911061637s6390ba0cy439b923b5956c9e8@mail.gmail.com> On Sat, Nov 7, 2009 at 11:52 AM, Simon Pieters <simonp at opera.com> wrote: > What if you have a video with say one frame per second? Unless I'm mistaken > Firefox will still fire timeupdate once per frame. (The spec says you have > to fire at least every 250ms.) > Hmm. Why would you want timeupdate to fire more often than once per frame? Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091107/e5acca02/attachment.htm> From scherkus at chromium.org Fri Nov 6 16:51:18 2009 From: scherkus at chromium.org (Andrew Scherkus) Date: Fri, 6 Nov 2009 16:51:18 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <11e306600911061637s6390ba0cy439b923b5956c9e8@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> <11e306600911061637s6390ba0cy439b923b5956c9e8@mail.gmail.com> Message-ID: <eb35a2a80911061651xa96776dmd27378eac2ee068c@mail.gmail.com> On Fri, Nov 6, 2009 at 4:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote: > On Sat, Nov 7, 2009 at 11:52 AM, Simon Pieters <simonp at opera.com> wrote: > >> What if you have a video with say one frame per second? Unless I'm >> mistaken Firefox will still fire timeupdate once per frame. (The spec says >> you have to fire at least every 250ms.) >> > > Hmm. Why would you want timeupdate to fire more often than once per frame? If you tie progress bar animation to timeupdate, the position will update in larger steps depending on the framerate of the video. i.e., a 10 second clip at 1fps will animate in 10 large steps. If your video subsystem returns a wall clock or some continuously increasing time source, the 250ms update will at least give you a smoother animating progress bar. i.e., a 10 second clip at 1fps will animate in 40 smaller steps. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091106/7005b228/attachment.htm> From rob.ennals at gmail.com Fri Nov 6 18:17:44 2009 From: rob.ennals at gmail.com (Rob Ennals) Date: Fri, 6 Nov 2009 18:17:44 -0800 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <4AF4A60B.4030207@enseirb-matmeca.fr> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> <4AF4A60B.4030207@enseirb-matmeca.fr> Message-ID: <7FB1B431-6E89-41E4-8851-4095E751299E@gmail.com> [this is Rob Ennals from Intel] I assume the use case for this is to allow parallel processing of a potentially large set of data? Maybe what we really want here is some kind of parallel map operation where we give the user agent an array and then say "call this function on each element, using as many threads as you deem appropriate" given the resources available. Each function call would logically execute in it's own worker context, but to keep semantics transparent, we might declare that such workers are not be allowed to send messages (other than a final result) and so could not tell how many parallel workers had actually been created. In the single core case this reduces to creating a single worker and then executing each function call in sequence. In the 1000 way cores of the not-so-distant future it will schedule tasks as appropriate. I'm not convinced that it is a good idea to expose details like the number o processor cores to a user. Such numbers can be messy. What if it changes? What if some of them are faster than others? What if another app is using some of them? What if they have different instruction sets? What if we'd like to keep some powered off? What if some are expensive to communicate with? What if we don't have enough memory to do them all in parallel? What if they cant all share cache? What is some jobs complete earlier than others? I don't think we should trust user code to know how many threads they should create. If what they want is to do a parallel map over a set of items making optimal use of the available resources, then we should give them a primitive that does exactly that. If we felt clever we might want to allow shuffle and reduce as well. Thoughts? -Rob On Nov 6, 2009, at 2:41 PM, David Bruant <bruant at enseirb-matmeca.fr> wrote: > ben turner a ?crit : >> I think it's important to note that there is no guarantee that each >> worker is tied to an actual OS-level thread. Firefox, for instance, >> will schedule workers on a limited number of OS threads to prevent >> resource swamping. Other implementations (Chromium only?) create new >> processes to run worker code. The only guarantee is that code >> executed >> in a worker will not block the main thread. >> > I didn't know the differences between the current web workers > implementations and that's interesting. > The problem with developing JS code using Web workers in a delegation > use case is that you cannot predict what is the hardware, the OS and > the > browser you will run your code on. So, what is the "right", "best" > number of workers to use ? 1, 10, 16, 1000 ? It is not a defined > number, > it depends on hardware, OS and browser (or any user agent, of course). > > My point is to give this information to the developer. > > If FF decides that all the workers will run on 3 OS threads even if > you're on a 16-core, my number is 3. If you're in Chrome and your OS > allows you to create only one more process, this number is 1. If > you're > in Chrome and your OS allow you to create "as many processes as you > want" on a quad-core, this number is 4. But for each case, the web > browser can ask this information to the OS (once when you install it ? > each time you open your browser ? dynamically ?). > > This information is available (and shouldn't be that hard to > retrieve !) > and can be given to the web developer. > > David > >> -Ben >> > From cjones at mozilla.com Fri Nov 6 23:43:59 2009 From: cjones at mozilla.com (Chris Jones) Date: Sat, 07 Nov 2009 01:43:59 -0600 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> <4AF4A60B.4030207@enseirb-matmeca.fr> <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> Message-ID: <4AF5253F.7000904@mozilla.com> David Bruant wrote: > On the other hand, on a 16-core processor (which doesn't exist yet, but > is a realistic idea for the next couple of decades), the task could be > executed faster with 16 workers. > Maybe you mean "hardware thread" instead of "core"? If so, the machine I'm writing this message on has 16 HW threads (2 CPUs x 4 cores/CPU x 2 HW threads/core). And there's the http://en.wikipedia.org/wiki/Niagara_2 which has been shipping for a while now, and has 64 HW threads. (If we wanted to talk GPGPUs, we'd be in the 1000s of HW threads and 100s of cores. Some crazy person could make simple worker computations work on GPGPUs ;) .) Drew Wilson wrote: > I think I understand what you're trying to achieve, but it's not clear > to me that giving the web page a snapshot count of "free cores" is > actually going to do what you want, given that the number of free cores > can vary greatly over time. > I completely agree that telling a web app the number of "free cores" (idle HW threads?) at a given point in time is useless, and probably counterproductive, even if it could be done. Rob Ennals wrote: > Maybe what we really want here is some kind of parallel map operation > where we give the user agent an array and then say "call this function > on each element, using as many threads as you deem appropriate" given > the resources available. Each function call would logically execute in > it's own worker context, but to keep semantics transparent, we might > declare that such workers are not be allowed to send messages (other > than a final result) and so could not tell how many parallel workers had > actually been created. > This. It's just the SPMD model, ported to web workers. Though I'm not sure what's gained by hiding the number of allocated parallel workers from the app, after they've been allocated. IMHO this isn't a decision that should change over the duration of the computation. If I were writing a computationally-bound webapp, I would want an interface like [main thread] SharedWorker.parallelMap(workerfn [, ...]]) [worker thread] function workerfn(myThreadIndex, numberOfworkerfns [, ...]) { // partition problem dataset [...] based on |myThreadIndex| and |numberOfworkerfns| // compute } Cheers, Chris From cjones at mozilla.com Sat Nov 7 00:08:18 2009 From: cjones at mozilla.com (Chris Jones) Date: Sat, 07 Nov 2009 02:08:18 -0600 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> Message-ID: <4AF52AF2.8020408@mozilla.com> Rob Ennals wrote: > Missed out the important final qualifier. Here's take 3: > > "the user agent MUST NOT release the storage mutex between calls to > local storage, except that the user agent MAY release the storage mutex > on any API operation /other that a local storage oeration/" > IMHO, this is actually worse than the current proposal of a global mutex :S. This proposal makes atomicity guarantees not only library-dependent, but browser-implementation-dependent. For example a = localStorage.x() jquery.foo() b = localStorage.y() If |jquery.foo()| were, say, parsing JSON or determining selector matching, it might involve "browser API calls" in some browser, and in others not. Worse, if |jquery.foo()| involves accessing browser-managed things like computed DOM attributes, then even in the *same* browser it might result in sometimes needing a "browser API call", and sometimes only needing a JS-only call. (Depending on DOM attribute cache status, if present.) This of course of depends on the definition of "browser API call", but I interpret this as approximately meaning "calling from JS to C++". These objections are in addition to those made by Jeremy Orlow concerning a script-managed, possibly cross-process mutex, which I also find unpleasant. Cheers, Chris From cjones at mozilla.com Sat Nov 7 00:42:34 2009 From: cjones at mozilla.com (Chris Jones) Date: Sat, 07 Nov 2009 02:42:34 -0600 Subject: [whatwg] [WebWorkers] About the delegation example In-Reply-To: <4AF5253F.7000904@mozilla.com> References: <4AF3C303.5070701@enseirb-matmeca.fr> <dd0fbad0911061029v8a684d9p8b179a1108dd77db@mail.gmail.com> <4AF46FE4.1060302@enseirb-matmeca.fr> <21b1517c0911061341j402a03b2h68a6a8505cca2c3@mail.gmail.com> <4AF4A60B.4030207@enseirb-matmeca.fr> <f965ae410911061501n4f06f198m9546b367610f388d@mail.gmail.com> <4AF5253F.7000904@mozilla.com> Message-ID: <4AF532FA.3010101@mozilla.com> Chris Jones wrote: > If I were writing a computationally-bound webapp, I would want an > interface like > > [main thread] > SharedWorker.parallelMap(workerfn [, ...]]) > > [worker thread] > function workerfn(myThreadIndex, numberOfworkerfns [, ...]) { > // partition problem dataset [...] based on |myThreadIndex| and > |numberOfworkerfns| > // compute > } > On second thought, I think that worker semantics dictate that the dataset partitioning decision should be made by [main thread] before the workers are spawned. But I don't think this significantly changes the API (move "// partition ..." into [main thread]). Cheers, Chris From brian.p.campbell at dartmouth.edu Sat Nov 7 12:25:52 2009 From: brian.p.campbell at dartmouth.edu (Brian Campbell) Date: Sat, 7 Nov 2009 15:25:52 -0500 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <AF83D0C6-7BBA-4DD6-94B9-6379DA202632@dartmouth.edu> <op.u2zwh4myidj3kv@simon-pieterss-macbook.local> Message-ID: <39FBB77A-9007-46EE-BBE0-2A2CAF8AF4B5@dartmouth.edu> On Nov 6, 2009, at 5:52 PM, Simon Pieters wrote: > On Fri, 06 Nov 2009 18:11:18 +0100, Brian Campbell <brian.p.campbell at dartmouth.edu > > wrote: > >>> Brian, since Firefox is doing what you proposed -- can you think >>> of any other issues with its current implementation? What about >>> for audio files? >> >> The way Firefox works is fine for me. I haven't yet tested it with >> audio only, but something around 25 or 30 updates per second would >> work fine for all use cases that I have; 15 updates per second is >> about the minimum I'd consider useful for synchronizing one off >> events like bullets or slide transitions (this is for stuff where >> you want good, tight sync for stuff with high production values), >> and while animations would work at that rate, they'd be pretty jerky. > > What if you have a video with say one frame per second? Unless I'm > mistaken Firefox will still fire timeupdate once per frame. (The > spec says you have to fire at least every 250ms.) That's a fair point, though videos with frame rates that low are pretty rare. I suppose if you encoded something like a slideshow as a video, with a very low frame rate, you might get such an effect. Of course, if you're playing a video at that frame rate, I'm wondering what you would need to be synchronized at a higher frame rate; though if it has an audio track as well, you may be trying to synchronize against the audio. If this is something that we think is worth worrying about, then I'd advocate for just saying that timeupdate events should be fired approximately 30 times per second, perhaps with a minimum of 15 and a a maximum of 60 or so. For videos over 15 FPS, the browser could simply send one update per frame; for videos with a lower frame rate, the browser would have to generate intermediate timeupdate events to keep the interval reasonable. Or, the browser could just pick a rate in that range and send the events at that rate, without tying them to when the frames are displayed. I'd be fine with just having a reasonably consistent rate of 30 updates per second while the video is playing. -- Brian From jonas at sicking.cc Sat Nov 7 15:21:49 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Sat, 7 Nov 2009 15:21:49 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <op.u2yv0afnatwj1d@sisko.linkoping.osa> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> Message-ID: <63df84f0911071521k3a1002d3waf18873e9f78056c@mail.gmail.com> On Fri, Nov 6, 2009 at 1:44 AM, Philip J?genstedt <philipj at opera.com> wrote: > On Thu, 05 Nov 2009 21:11:15 +0100, Andrew Scherkus <scherkus at chromium.org> > wrote: > >> On Thu, Nov 5, 2009 at 6:10 AM, Brian Campbell < >> brian.p.campbell at dartmouth.edu> wrote: >> >>> On Nov 5, 2009, at 1:17 AM, Andrew Scherkus wrote: >>> >>> ?On Fri, Oct 30, 2009 at 10:18 PM, Brian Campbell < >>>> >>>> Brian.P.Campbell at dartmouth.edu> wrote: >>>> As a multimedia developer, I am wondering about the purpose of the >>>> timeupdate event on media elements. On first glance, it would appear >>>> that >>>> this event would be useful for synchronizing animations, bullets, >>>> captions, >>>> UI, and the like. The spec specifies a rate of 4 to 66 Hz for these >>>> events. >>>> The high end of this (30 or more Hz) is pretty reasonable for displaying >>>> things in sync with the video. The low end, however, 4 Hz, is far too >>>> slow >>>> for most types of synchronization; everything feels laggy at this >>>> frequency. >>>> From my testing on a two year old MacBook Pro, Firefox is giving me >>>> about 25 >>>> timeupdate events per second, while Safari and Chrome are giving me the >>>> bare >>>> minimum, of 4 timeupdate events per second. >>>> >>>> At 4 timeupdate events per second, it isn't all that useful. I can >>>> replace >>>> it with setInterval, at whatever rate I want, query the time, and get >>>> the >>>> synchronization I need, but that makes the timeupdate event seem to be >>>> redundant. At 25 timeupdate events per second, it is reasonably useful, >>>> and >>>> can be used to synchronize various things to the video. >>>> >>>> So, I'm wondering if there's a purpose for the timeupdate event that I'm >>>> missing. If it is intended for any sort of synchronization with the >>>> video, I >>>> think it should be improved to give better guarantees on the interval >>>> between updates, or just dropped from the spec; it's not useful enough >>>> in >>>> its current form. To improve it, the maximum interval between updates >>>> could >>>> be reduced to about 40 ms, or perhaps the interval could be made >>>> settable so >>>> the author could control how often they want to get the event. >>>> >>>> -- Brian >>>> >>>> I believe it's a convenience over using setTimeout/setInterval + polling >>>> to determine whether playback has progressed ie., for rendering your own >>>> playback progress bar. ?I've also seen it been used as a signal to copy >>>> frames into <canvas> on Firefox, however if timeupdate frequency != fps >>>> of >>>> video you either miss frames or paint too much. >>>> >>>> I don't think timeupdate today is very useful for doing anything beyond >>>> a >>>> progress bar or other simple synchronized animations. >>>> >>> >>> Right. That's what I figured the point is; I just wanted to check to make >>> sure I wasn't missing something. >>> >>> As implemented by Safari and Chrome (which is the minimum rate allowed by >>> the spec), it's not really useful for that purpose, as 4 updates per >>> second >>> makes any sort of synchronization feel jerky and laggy. If it were done >>> at >>> the frame rate of the video, or perhaps with a minimum of 25 frames per >>> second, it would be much more useful. Even at a minimum of 15 frames per >>> second, you would still be able to get some sorts of useful >>> synchronization, >>> though animations synchronized wouldn't feel as smooth as they could. >>> >>> ?Would something like <video> firing events for every frame rendered help >>>> >>>> you out? ?This would help also fix the <canvas> over/under painting >>>> issue >>>> and improve synchronization. >>>> >>> >>> Yes, this would be considerably better than what is currently specced. >>> >>> -- Brian >>> >> >> I'll see if we can do something for WebKit based browsers, because today >> it >> literally is hardcoded to 250ms for all ports. >> >> http://trac.webkit.org/browser/trunk/WebCore/html/HTMLMediaElement.cpp#L1254 >> >> Maybe we'll end up firing events based on frame updates for video, and >> something arbitrary for audio (as it is today). >> >> Brian, since Firefox is doing what you proposed -- can you think of any >> other issues with its current implementation? ?What about for audio files? >> >> Thanks, >> Andrew > > We've considered firing it for each frame, but there is one problem. If > people expect that it fires once per frame they will probably write scripts > which do frame-based animations by moving things n pixels per frame or > similar. Some animations are just easier to do this way, so there's no > reason to think that people won't do it. This will break horribly if a > browser is ever forced to drop a frame, which is going to happen on slower > machines. In balance this may or may not be a risk worth taking. When timeupdate was added, the stated goal was actually as a battery saving feature for for example mobile devices. The idea was that the implementation could scale back how often it fired the event in order to save battery. Now that we have implementation experience, is timeupdate fulfilling this goal? If not, is it fulfilling any other goals making it worth keeping? / Jonas From dolske at mozilla.com Sat Nov 7 19:21:35 2009 From: dolske at mozilla.com (Justin Dolske) Date: Sat, 07 Nov 2009 19:21:35 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <63df84f0911071521k3a1002d3waf18873e9f78056c@mail.gmail.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <63df84f0911071521k3a1002d3waf18873e9f78056c@mail.gmail.com> Message-ID: <4AF6393F.10009@mozilla.com> On 11/7/09 3:21 PM, Jonas Sicking wrote: > When timeupdate was added, the stated goal was actually as a battery > saving feature for for example mobile devices. The idea was that the > implementation could scale back how often it fired the event in order > to save battery. > > Now that we have implementation experience, is timeupdate fulfilling > this goal? If not, is it fulfilling any other goals making it worth > keeping? FWIW, I felt that having Firefox's default video controls update their state for every frame was excessive (and could lead to competing for the CPU with the video itself). So, the controls basically ignore timeupdate events that occur within .333 seconds of the last timeupdate position... Which leads to having a bit of complication to deal with edge cases like having the video end less than .333 seconds after the last timeupdate event (otherwise the UI might look like stuck shortly before the end of the video). At least for my needs, having an event fire at ~3 Hz (and when special things happen, like a seek or the video ending) would be somewhat simpler and more efficient. Justin From silviapfeiffer1 at gmail.com Sat Nov 7 21:41:52 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Sat, 7 Nov 2009 21:41:52 -0800 Subject: [whatwg] What is the purpose of timeupdate? In-Reply-To: <4AF6393F.10009@mozilla.com> References: <12E92C46-513F-4D82-AC8C-12EE34CCBBEE@dartmouth.edu> <eb35a2a80911042217kb20a05fg4259ea4d9ed4d219@mail.gmail.com> <7EFDB7A2-3D2A-4C1E-913C-2C0360B9C09C@Dartmouth.EDU> <eb35a2a80911051211n47e60418oc4c864e16238a27e@mail.gmail.com> <op.u2yv0afnatwj1d@sisko.linkoping.osa> <63df84f0911071521k3a1002d3waf18873e9f78056c@mail.gmail.com> <4AF6393F.10009@mozilla.com> Message-ID: <2c0e02830911072141w2b00f6a8xced021407ba87cfd@mail.gmail.com> On Sat, Nov 7, 2009 at 7:21 PM, Justin Dolske <dolske at mozilla.com> wrote: > On 11/7/09 3:21 PM, Jonas Sicking wrote: > >> When timeupdate was added, the stated goal was actually as a battery >> saving feature for for example mobile devices. The idea was that the >> implementation could scale back how often it fired the event in order >> to save battery. >> >> Now that we have implementation experience, is timeupdate fulfilling >> this goal? If not, is it fulfilling any other goals making it worth >> keeping? > > FWIW, I felt that having Firefox's default video controls update their state > for every frame was excessive (and could lead to competing for the CPU with > the video itself). So, the controls basically ignore timeupdate events that > occur within .333 seconds of the last timeupdate position... Which leads to > having a bit of complication to deal with edge cases like having the video > end less than .333 seconds after the last timeupdate event (otherwise the UI > might look like stuck shortly before the end of the video). > > At least for my needs, having an event fire at ~3 Hz (and when special > things happen, like a seek or the video ending) would be somewhat simpler > and more efficient. I use timeupdate to register a callback that will update captions/subtitles. The alternative is to use the setInterval (or setTimeout) function which checks regularly whether your video's currentTime is still within your subtitle element. I think timeupdate is very useful, in particular since it is more accurate than checking currentTime. But I also think we need to add another mechanism to register events with the video/audio element that are triggered at the registered time (or within an interval). This would avoid constant polling for captions. At TPAC in the video breakout group we discussed a little how to re-introduce something like cue ranges in the context of captions in a declarative manner. We still need to make this more concrete, but it may be similar to the onenter and onleave events that the itextlist element has in https://wiki.mozilla.org/Accessibility/HTML5_captions_v2 . Cheers, Silvia. From silviapfeiffer1 at gmail.com Sat Nov 7 23:35:50 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Sat, 7 Nov 2009 23:35:50 -0800 Subject: [whatwg] unexpected use of the CORS specification Message-ID: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> Hi, a friend of mine just wrote an interesting blog post about "unshortening twitter URLs", see http://benno.id.au/blog/2009/11/08/urlunshortener . In it he proposes that url shorteners should be treated specially in browsers such that when you mouse over a shortened url, the browse knows to interpret them (i.e. follow the redirection) and shows you the long URL as a hint. I would support such an approach, since I have been annoyed more than once that shortened URLs don't tell me anything about the target. As part of this would be a requirement for URL shorteners to support CORS http://www.w3.org/TR/cors/, which browsers can then use to follow the redirection. Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ with a property to disable following redirects automatically so as to be able to expose the redirection. I am not aware if somebody else has suggested these use cases for CORS and XMLHttpRequest before (this may not even be the right fora for it), but since these are so closely linked to what we do in HTML5, I thought it would be good to point it out. I would think that at minimum Anne knows what to do with it, since he is editor on both. Regards, Silvia. From gundersen at gmail.com Sun Nov 8 02:57:57 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Sun, 8 Nov 2009 21:57:57 +1100 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> Message-ID: <45f4181c0911080257y284d6d06l139df85c2a4ff597@mail.gmail.com> This could lead to a lot of requests being made by the client, just to check a url. If a page contains 100 links, then 100 HEAD requests need to be made, and in most cases they will be plain old ordinary links, so no 301 redirects. The browser could do the check when you mouse over the link, that is, when the tooltip appears. This would reduce the number of requests being made, but it would still result in a lot of requests being made just to get a (useless) 200 OK reply. This should be a simple thing to implement as an extension in Firefox or as a patch to webkit, so we can see how effective it would be. Marius Gundersen On Sun, Nov 8, 2009 at 6:35 PM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com>wrote: > Hi, > > a friend of mine just wrote an interesting blog post about > "unshortening twitter URLs", see > http://benno.id.au/blog/2009/11/08/urlunshortener . > > In it he proposes that url shorteners should be treated specially in > browsers such that when you mouse over a shortened url, the browse > knows to interpret them (i.e. follow the redirection) and shows you > the long URL as a hint. I would support such an approach, since I have > been annoyed more than once that shortened URLs don't tell me anything > about the target. As part of this would be a requirement for URL > shorteners to support CORS http://www.w3.org/TR/cors/, which browsers > can then use to follow the redirection. > > Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ > with a property to disable following redirects automatically so as to > be able to expose the redirection. > > I am not aware if somebody else has suggested these use cases for CORS > and XMLHttpRequest before (this may not even be the right fora for > it), but since these are so closely linked to what we do in HTML5, I > thought it would be good to point it out. I would think that at > minimum Anne knows what to do with it, since he is editor on both. > > Regards, > Silvia. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091108/209ed7a3/attachment-0001.htm> From pgraff at apple.com Sun Nov 8 06:56:34 2009 From: pgraff at apple.com (pgraff) Date: Sun, 08 Nov 2009 13:36:34 -0120 Subject: [whatwg] 225 VIAGRU CIALES LEVITRU Message-ID: <478101ca6089$4077f5b0$0a05e7d5@home-b76b69de99> An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091108/5e7c1d34/attachment.htm> -------------- next part -------------- From whatwg at adambarth.com Sun Nov 8 07:25:37 2009 From: whatwg at adambarth.com (Adam Barth) Date: Sun, 8 Nov 2009 07:25:37 -0800 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> Message-ID: <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> I don't see the connection with CORS. The browser is free to request whatever URLs it wants. The results need not be accessible to content. Maybe I'm misunderstanding. Adam On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > Hi, > > a friend of mine just wrote an interesting blog post about > "unshortening twitter URLs", see > http://benno.id.au/blog/2009/11/08/urlunshortener . > > In it he proposes that url shorteners should be treated specially in > browsers such that when you mouse over a shortened url, the browse > knows to interpret them (i.e. follow the redirection) and shows you > the long URL as a hint. I would support such an approach, since I have > been annoyed more than once that shortened URLs don't tell me anything > about the target. As part of this would be a requirement for URL > shorteners to support CORS http://www.w3.org/TR/cors/, which browsers > can then use to follow the redirection. > > Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ > with a property to disable following redirects automatically so as to > be able to expose the redirection. > > I am not aware if somebody else has suggested these use cases for CORS > and XMLHttpRequest before (this may not even be the right fora for > it), but since these are so closely linked to what we do in HTML5, I > thought it would be good to point it out. I would think that at > minimum Anne knows what to do with it, since he is editor on both. > > Regards, > Silvia. > From dgerard at gmail.com Sun Nov 8 07:54:10 2009 From: dgerard at gmail.com (David Gerard) Date: Sun, 8 Nov 2009 15:54:10 +0000 Subject: [whatwg] Unbiased browser stats (semi-OT) Message-ID: <fbad4e140911080754o41c2150dua7ce248738125c27@mail.gmail.com> ... or as unbiased as you're likely to get, anyway, from a top 10 website of very mainstream interest whose direct interest is serving the readers: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at just over 40%. The work here is having excellent real-world significance :-D - d. From Simetrical+w3c at gmail.com Sun Nov 8 08:31:11 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Sun, 8 Nov 2009 11:31:11 -0500 Subject: [whatwg] Unbiased browser stats (semi-OT) In-Reply-To: <fbad4e140911080754o41c2150dua7ce248738125c27@mail.gmail.com> References: <fbad4e140911080754o41c2150dua7ce248738125c27@mail.gmail.com> Message-ID: <7c2a12e20911080831l6bfded18r5f1c89c09d61ccc4@mail.gmail.com> On Sun, Nov 8, 2009 at 10:54 AM, David Gerard <dgerard at gmail.com> wrote: > ... or as unbiased as you're likely to get, anyway, from a top 10 > website of very mainstream interest whose direct interest is serving > the readers: > > http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm > http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm > > The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at > just over 40%. Microsoft has indicated that they intend to support HTML5 in Internet Explorer as well, so I don't know why it's not "HTML5-aspiring". Also, Wikipedia *editors* are probably represented very disproportionately in those figures, and they would certainly tend to use IE a lot less than the general population. From dgerard at gmail.com Sun Nov 8 08:39:39 2009 From: dgerard at gmail.com (David Gerard) Date: Sun, 8 Nov 2009 16:39:39 +0000 Subject: [whatwg] Unbiased browser stats (semi-OT) In-Reply-To: <7c2a12e20911080831l6bfded18r5f1c89c09d61ccc4@mail.gmail.com> References: <fbad4e140911080754o41c2150dua7ce248738125c27@mail.gmail.com> <7c2a12e20911080831l6bfded18r5f1c89c09d61ccc4@mail.gmail.com> Message-ID: <fbad4e140911080839x22d37b14l8968cc36113654d7@mail.gmail.com> 2009/11/8 Aryeh Gregor <Simetrical+w3c at gmail.com>: > On Sun, Nov 8, 2009 at 10:54 AM, David Gerard <dgerard at gmail.com> wrote: >> ... or as unbiased as you're likely to get, anyway, from a top 10 >> website of very mainstream interest whose direct interest is serving >> the readers: >> http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm >> http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm >> The first shows HTML5-aspiring browsers (places 2 to 5 on the list) at > Microsoft has indicated that they intend to support HTML5 in Internet > Explorer as well, so I don't know why it's not "HTML5-aspiring". I heartily support their statements, but I'm afraid I'll count them when I see action. YMMV, absolutely. > Also, Wikipedia *editors* are probably represented very > disproportionately in those figures, and they would certainly tend to > use IE a lot less than the general population. Actually, no - readers have *way* outstripped editors since about 2006. It's not even the "tech-savvy" or "web-savvy" audience - Wikipedia is standard fare for people who can't work computers to look stuff up on. Wikipedia is stupidly mainstream and it's sometimes hard for those of us on the inside (you and me) to realise just how mainstream. But when I see a poster in Kings Cross train station advertising some pop culture museum exhibition as "The Wikipedia of ..." (whatever it was), it reminds me ... So I feel quite confident in stating that this is indicative of the actual Internet user base. - d. From Simetrical+w3c at gmail.com Sun Nov 8 08:59:19 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Sun, 8 Nov 2009 11:59:19 -0500 Subject: [whatwg] Unbiased browser stats (semi-OT) In-Reply-To: <fbad4e140911080839x22d37b14l8968cc36113654d7@mail.gmail.com> References: <fbad4e140911080754o41c2150dua7ce248738125c27@mail.gmail.com> <7c2a12e20911080831l6bfded18r5f1c89c09d61ccc4@mail.gmail.com> <fbad4e140911080839x22d37b14l8968cc36113654d7@mail.gmail.com> Message-ID: <7c2a12e20911080859q2fcdb611j54040e60a1ea2fd0@mail.gmail.com> On Sun, Nov 8, 2009 at 11:39 AM, David Gerard <dgerard at gmail.com> wrote: > Actually, no - readers have *way* outstripped editors since about > 2006. It's not even the "tech-savvy" or "web-savvy" audience - > Wikipedia is standard fare for people who can't work computers to look > stuff up on. Granted, registered users are <5% of views last I heard, but there are biases in every sample. Regular Wikipedia readers tend to be disproportionately young, for instance, which means more browsing from home and fewer on corporate networks who are locked into IE. You can't really say what the most popular browser is on the whole web. (Well, you can: it's IE. But you can't really say by how much, exactly.) From mressler at gmail.com Sun Nov 8 13:16:17 2009 From: mressler at gmail.com (Mike Ressler) Date: Sun, 8 Nov 2009 16:16:17 -0500 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> Message-ID: <1fec3f0a0911081316p1d240735k29c3d87b9779b7d4@mail.gmail.com> I think that Silvia was implying that a URL shortening service could respond with Access-Control-Allow-Origin:*<http://www.w3.org/TR/cors/#access-control-allow-origin-response-hea>or some such header to signal to the browser that this domain serves resources in a cross-origin fashion. This would allow the browser to eagerly fetch the resulting URLs to aid in user interface hints without having to eagerly fetch URLs that aren't "shortened". Mike On Sun, Nov 8, 2009 at 10:25 AM, Adam Barth <whatwg at adambarth.com> wrote: > I don't see the connection with CORS. The browser is free to request > whatever URLs it wants. The results need not be accessible to > content. Maybe I'm misunderstanding. > > Adam > > > On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer > <silviapfeiffer1 at gmail.com> wrote: > > Hi, > > > > a friend of mine just wrote an interesting blog post about > > "unshortening twitter URLs", see > > http://benno.id.au/blog/2009/11/08/urlunshortener . > > > > In it he proposes that url shorteners should be treated specially in > > browsers such that when you mouse over a shortened url, the browse > > knows to interpret them (i.e. follow the redirection) and shows you > > the long URL as a hint. I would support such an approach, since I have > > been annoyed more than once that shortened URLs don't tell me anything > > about the target. As part of this would be a requirement for URL > > shorteners to support CORS http://www.w3.org/TR/cors/, which browsers > > can then use to follow the redirection. > > > > Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ > > with a property to disable following redirects automatically so as to > > be able to expose the redirection. > > > > I am not aware if somebody else has suggested these use cases for CORS > > and XMLHttpRequest before (this may not even be the right fora for > > it), but since these are so closely linked to what we do in HTML5, I > > thought it would be good to point it out. I would think that at > > minimum Anne knows what to do with it, since he is editor on both. > > > > Regards, > > Silvia. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091108/628b0fc9/attachment.htm> From silviapfeiffer1 at gmail.com Sun Nov 8 14:08:31 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Sun, 8 Nov 2009 14:08:31 -0800 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <1fec3f0a0911081316p1d240735k29c3d87b9779b7d4@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> <1fec3f0a0911081316p1d240735k29c3d87b9779b7d4@mail.gmail.com> Message-ID: <2c0e02830911081408g1ff1da26x31f24db906597656@mail.gmail.com> Yes, that's the point. Please read the blog post for details. Benno also discussed the issue of the number of requests made. BTW: I've taken the public-html list off this thread, since I think the discussion so far was only by WHATWG members and we want to avoid too much cross-posting. Thanks, Silvia. On Sun, Nov 8, 2009 at 1:16 PM, Mike Ressler <mressler at gmail.com> wrote: > I think that Silvia was implying that a URL shortening service could respond > with Access-Control-Allow-Origin:* or some such header to signal to the > browser that this domain serves resources in a cross-origin fashion.? This > would allow the browser to eagerly fetch the resulting URLs to aid in user > interface hints without having to eagerly fetch URLs that aren't > "shortened". > > Mike > > On Sun, Nov 8, 2009 at 10:25 AM, Adam Barth <whatwg at adambarth.com> wrote: >> >> I don't see the connection with CORS. ?The browser is free to request >> whatever URLs it wants. ?The results need not be accessible to >> content. ?Maybe I'm misunderstanding. >> >> Adam >> >> >> On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer >> <silviapfeiffer1 at gmail.com> wrote: >> > Hi, >> > >> > a friend of mine just wrote an interesting blog post about >> > "unshortening twitter URLs", see >> > http://benno.id.au/blog/2009/11/08/urlunshortener . >> > >> > In it he proposes that url shorteners should be treated specially in >> > browsers such that when you mouse over a shortened url, the browse >> > knows to interpret them (i.e. follow the redirection) and shows you >> > the long URL as a hint. I would support such an approach, since I have >> > been annoyed more than once that shortened URLs don't tell me anything >> > about the target. As part of this would be a requirement for URL >> > shorteners to support CORS http://www.w3.org/TR/cors/, which browsers >> > can then use to follow the redirection. >> > >> > Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ >> > with a property to disable following redirects automatically so as to >> > be able to expose the redirection. >> > >> > I am not aware if somebody else has suggested these use cases for CORS >> > and XMLHttpRequest before (this may not even be the right fora for >> > it), but since these are so closely linked to what we do in HTML5, I >> > thought it would be good to point it out. I would think that at >> > minimum Anne knows what to do with it, since he is editor on both. >> > >> > Regards, >> > Silvia. >> > > > From jonas at sicking.cc Sun Nov 8 14:36:15 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Sun, 8 Nov 2009 14:36:15 -0800 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <2c0e02830911081408g1ff1da26x31f24db906597656@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> <1fec3f0a0911081316p1d240735k29c3d87b9779b7d4@mail.gmail.com> <2c0e02830911081408g1ff1da26x31f24db906597656@mail.gmail.com> Message-ID: <63df84f0911081436v3e7d6068nb1b30e2b68888d55@mail.gmail.com> On Sun, Nov 8, 2009 at 2:08 PM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > Yes, that's the point. Please read the blog post for details. Benno > also discussed the issue of the number of requests made. > > BTW: I've taken the public-html list off this thread, since I think > the discussion so far was only by WHATWG members and we want to avoid > too much cross-posting. But if you're asking the *browser* to do this, then the browser doesn't need the server to opt in to CORS. The browser can provide this functionality without needing cooperation from the server. Possibly even greasemonkey scripts have enough authority to do this without any server opt-in. If however you are suggesting that *pages* do this, then yes, the redirect server would need to opt in to CORS, and we would probably need to add functionality to allow pages to get informed about the redirect chain. / Jonas From whatwg at adambarth.com Sun Nov 8 16:42:00 2009 From: whatwg at adambarth.com (Adam Barth) Date: Sun, 8 Nov 2009 16:42:00 -0800 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <4AF52AF2.8020408@mozilla.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> <4AF52AF2.8020408@mozilla.com> Message-ID: <7789133a0911081642l18ba153eie57456a3ca180f64@mail.gmail.com> On Sat, Nov 7, 2009 at 12:08 AM, Chris Jones <cjones at mozilla.com> wrote: > Rob Ennals wrote: >> >> Missed out the important final qualifier. Here's take 3: >> >> "the user agent MUST NOT release the storage mutex between calls to local >> storage, except that the user agent MAY release the storage mutex on any API >> operation /other that a local storage oeration/" > > IMHO, this is actually worse than the current proposal of a global mutex :S. > ?This proposal makes atomicity guarantees not only library-dependent, but > browser-implementation-dependent. ?For example > > ?a = localStorage.x() > ?jquery.foo() > ?b = localStorage.y() As I mentioned to Ian at TPAC, one way to make this more predictable is to release the lock on *every* function call and return. This provides content enough atomicity to build whatever locks it needs. Adam From robert at ocallahan.org Sun Nov 8 17:33:27 2009 From: robert at ocallahan.org (Robert O'Callahan) Date: Mon, 9 Nov 2009 14:33:27 +1300 Subject: [whatwg] localStorage mutex - a solution? In-Reply-To: <7789133a0911081642l18ba153eie57456a3ca180f64@mail.gmail.com> References: <A9F21DE2-86D6-4EE5-95A1-A560A0C02FD4@gmail.com> <7F16695A-3A0A-4C01-8E85-554D403E8EDB@gmail.com> <4AF52AF2.8020408@mozilla.com> <7789133a0911081642l18ba153eie57456a3ca180f64@mail.gmail.com> Message-ID: <11e306600911081733v74bcd05ch89184d5c942a780e@mail.gmail.com> On Mon, Nov 9, 2009 at 1:42 PM, Adam Barth <whatwg at adambarth.com> wrote: > As I mentioned to Ian at TPAC, one way to make this more predictable > is to release the lock on *every* function call and return. This > provides content enough atomicity to build whatever locks it needs. > Then simple refactorings that should be semantics-preserving --- like extracting a block of code into a shared function --- would break atomicity. This also places a new burden on JS implementations. Rob -- "He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091109/d03bd038/attachment.htm> From mjs at apple.com Sun Nov 8 17:35:19 2009 From: mjs at apple.com (Maciej Stachowiak) Date: Sun, 08 Nov 2009 17:35:19 -0800 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> Message-ID: <0534B6F4-3CCD-41B5-8DC1-1F01071FC7DA@apple.com> On Nov 8, 2009, at 7:25 AM, Adam Barth wrote: > I don't see the connection with CORS. The browser is free to request > whatever URLs it wants. The results need not be accessible to > content. Maybe I'm misunderstanding. The proposal at the link was for a method to do URL unshortening as a client-side script in the browser. That would indeed require CORS. A feature built-in to the browser would not. Regards, Maciej > > Adam > > > On Sat, Nov 7, 2009 at 11:35 PM, Silvia Pfeiffer > <silviapfeiffer1 at gmail.com> wrote: >> Hi, >> >> a friend of mine just wrote an interesting blog post about >> "unshortening twitter URLs", see >> http://benno.id.au/blog/2009/11/08/urlunshortener . >> >> In it he proposes that url shorteners should be treated specially in >> browsers such that when you mouse over a shortened url, the browse >> knows to interpret them (i.e. follow the redirection) and shows you >> the long URL as a hint. I would support such an approach, since I >> have >> been annoyed more than once that shortened URLs don't tell me >> anything >> about the target. As part of this would be a requirement for URL >> shorteners to support CORS http://www.w3.org/TR/cors/, which browsers >> can then use to follow the redirection. >> >> Further, Benno suggests extending http://www.w3.org/TR/ >> XMLHttpRequest/ >> with a property to disable following redirects automatically so as to >> be able to expose the redirection. >> >> I am not aware if somebody else has suggested these use cases for >> CORS >> and XMLHttpRequest before (this may not even be the right fora for >> it), but since these are so closely linked to what we do in HTML5, I >> thought it would be good to point it out. I would think that at >> minimum Anne knows what to do with it, since he is editor on both. >> >> Regards, >> Silvia. >> From f.freiburg at googlemail.com Mon Nov 9 01:43:49 2009 From: f.freiburg at googlemail.com (Fabian Freiburg) Date: Mon, 9 Nov 2009 10:43:49 +0100 Subject: [whatwg] Proposal: Extension to the base element Message-ID: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> Dear list! DISCLAIMER I've never used a list before and I've never posted a proposal, so please be patient with me if I'm doing something wrong. PROPOSAL The "base" element is very helpful. Trouble is that it affects all relative links and "src" attributes. Especially for the "src" attributes it would be very useful if it could define a context or media type to which it belongs. With this it would be possible to define a "base" URI fore. g. images, javascripts or stylesheets. Furthermore it would be very easy to use a CDN for serving static media files. There are probably some more advantages. There are different ways to implement this feature: One idea is to use a "content" or "type" attribute, where the MIME type to which the "base" belongs can be defined. For example the following "base" would affect all GIF images: <base href="http://example.com/media/images/" type="image/gif"> Another idea is to use some kind of tagging, which would mean more flexibility. For example: <base href="http://example.com/media/images/" class="images cdn gif"> Each element using one of the classes will belong to the relevant "base" element. Please let me know what you think about it. Regards, Fabian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091109/d4e7ab7e/attachment-0001.htm> From gundersen at gmail.com Mon Nov 9 03:26:34 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Mon, 9 Nov 2009 22:26:34 +1100 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> Message-ID: <45f4181c0911090326v1d303240mbc001a0e57ff80a6@mail.gmail.com> One problem with the first proposal is that you don't know the mimetype of the content before you load it. Just because it ends in .gif does not mean it is a gif file (eg, using GD a .php file could be a GIF image). Instead of using class, maybe the rel attribute would fit better. Marius Gundersen On Mon, Nov 9, 2009 at 8:43 PM, Fabian Freiburg <f.freiburg at googlemail.com>wrote: > Dear list! > > DISCLAIMER > I've never used a list before and I've never posted a proposal, so please > be patient with me if I'm doing something wrong. > > PROPOSAL > The "base" element is very helpful. Trouble is that it affects all relative > links and "src" attributes. Especially for the "src" attributes it would be > very useful if it could define a context or media type to which it belongs. > With this it would be possible to define a "base" URI fore. g. images, > javascripts or stylesheets. Furthermore it would be very easy to use a CDN > for serving static media files. There are probably some more advantages. > > There are different ways to implement this feature: One idea is to use a > "content" or "type" attribute, where the MIME type to which the "base" > belongs can be defined. For example the following "base" would affect all > GIF images: > <base href="http://example.com/media/images/" type="image/gif"> > > Another idea is to use some kind of tagging, which would mean more > flexibility. For example: > <base href="http://example.com/media/images/" class="images cdn gif"> > Each element using one of the classes will belong to the relevant "base" > element. > > Please let me know what you think about it. > > Regards, > Fabian > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091109/38a61f1c/attachment.htm> From workmad3 at gmail.com Mon Nov 9 03:45:50 2009 From: workmad3 at gmail.com (David Workman) Date: Mon, 9 Nov 2009 11:45:50 +0000 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <45f4181c0911090326v1d303240mbc001a0e57ff80a6@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> <45f4181c0911090326v1d303240mbc001a0e57ff80a6@mail.gmail.com> Message-ID: <4a60c8650911090345s56438508geae24a92b97ee3c0@mail.gmail.com> I'd suggest using an attribute over a type specifier too. Not only does it have the problem Marius spotted, but if you specified a type attribute then you have much more difficulty displaying content of the same type from both a CDN and dynamic user content in the same page (such as in a social networking site, displaying user-uploaded images from one location and the static images for the site layout from a CDN). Other than that, I think this would be a good addition that would make <base> much more usable in dynamic sites. 2009/11/9 Marius Gundersen <gundersen at gmail.com> > One problem with the first proposal is that you don't know the mimetype of > the content before you load it. Just because it ends in .gif does not mean > it is a gif file (eg, using GD a .php file could be a GIF image). > > Instead of using class, maybe the rel attribute would fit better. > > Marius Gundersen > > > On Mon, Nov 9, 2009 at 8:43 PM, Fabian Freiburg <f.freiburg at googlemail.com > > wrote: > >> Dear list! >> >> DISCLAIMER >> I've never used a list before and I've never posted a proposal, so please >> be patient with me if I'm doing something wrong. >> >> PROPOSAL >> The "base" element is very helpful. Trouble is that it affects all >> relative links and "src" attributes. Especially for the "src" attributes it >> would be very useful if it could define a context or media type to which it >> belongs. With this it would be possible to define a "base" URI fore. g. >> images, javascripts or stylesheets. Furthermore it would be very easy to use >> a CDN for serving static media files. There are probably some more >> advantages. >> >> There are different ways to implement this feature: One idea is to use a >> "content" or "type" attribute, where the MIME type to which the "base" >> belongs can be defined. For example the following "base" would affect all >> GIF images: >> <base href="http://example.com/media/images/" type="image/gif"> >> >> Another idea is to use some kind of tagging, which would mean more >> flexibility. For example: >> <base href="http://example.com/media/images/" class="images cdn gif"> >> Each element using one of the classes will belong to the relevant "base" >> element. >> >> Please let me know what you think about it. >> >> Regards, >> Fabian >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091109/116f853c/attachment.htm> From privat at ni-po.com Mon Nov 9 06:49:18 2009 From: privat at ni-po.com (Nikita Popov) Date: Mon, 09 Nov 2009 15:49:18 +0100 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> Message-ID: <4AF82BEE.6010805@ni-po.com> Fabian Freiburg schrieb: > PROPOSAL > The "base" element is very helpful. Trouble is that it affects all > relative links and "src" attributes. Especially for the "src" > attributes it would be very useful if it could define a context or > media type to which it belongs. With this it would be possible to > define a "base" URI fore. g. images, javascripts or stylesheets. > Furthermore it would be very easy to use a CDN for serving static > media files. There are probably some more advantages. I don't really understand why or when you need this addition. I personally use <base> only if I rewrite the URI to some sub-directory stuff. (index.php?page=download&action=view&name=foobar gets /download/view:foobar) Or do you want to use it to specify, that all images can be found in upload/images/? MfG Nikita Popov From Chris.Taylor at figureout.com Mon Nov 9 07:42:57 2009 From: Chris.Taylor at figureout.com (Chris Taylor) Date: Mon, 9 Nov 2009 15:42:57 +0000 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <4a60c8650911090345s56438508geae24a92b97ee3c0@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> <45f4181c0911090326v1d303240mbc001a0e57ff80a6@mail.gmail.com> <4a60c8650911090345s56438508geae24a92b97ee3c0@mail.gmail.com> Message-ID: <7805560CD71B3B4793F5FDBCDE22E52B1A52500130@tpexmb01> David Workman said: > I'd suggest using an attribute over a type specifier too. Not > only does it have the problem Marius spotted, but if you > specified a type attribute then you have much more difficulty > displaying content of the same type from both a CDN and dynamic > user content in the same page (such as in a social networking > site, displaying user-uploaded images from one location and > the static images for the site layout from a CDN). > > Other than that, I think this would be a good addition that > would make <base> much more usable in dynamic sites. David, can you clarify what you mean by attribute, please? Do you mean an attribute on each element to specify which <base> it is to reference? Like this pseudo-code: <base href="http://cdn.provider.com/" id="cdn"> <base href="http://www.mysite.com/images/" id="images"> <base href="http://youtube.com/" id="video"> <img src="image-from-cdn.jpg" base="cdn" alt="Image from CDN"> <img src="image-from-mysite.jpg" base=" images " alt="Image from mysite.com"> <video src="video1234.mpg" base="cdn" alt="Video from YouTube"> Or do you mean something else? Apologies for sounding dim, my brain is on strike today. Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com From Simetrical+w3c at gmail.com Mon Nov 9 08:04:13 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Mon, 9 Nov 2009 11:04:13 -0500 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> Message-ID: <7c2a12e20911090804x33d008dl46aec0d177d44578@mail.gmail.com> On Mon, Nov 9, 2009 at 4:43 AM, Fabian Freiburg <f.freiburg at googlemail.com> wrote: > The "base" element is very helpful. Trouble is that it affects all relative > links and "src" attributes. Especially for the "src" attributes it would be > very useful if it could define a context or media type to which it belongs. > With this it would be possible to define a "base" URI fore. g.? images, > javascripts or stylesheets. Furthermore it would be very easy to use a CDN > for serving static media files. Why can't you just use absolute URLs here, or regular relative URLs? If your page is dynamically generated, you can have the script add the appropriate domain to the URLs. If your page is static, then you're most likely hosting it on the CDN too, in which case you can just use normal relative URLs. Extending <base> to handle this seems unnecessarily complicated and fragile. From Chris.Taylor at figureout.com Mon Nov 9 09:18:08 2009 From: Chris.Taylor at figureout.com (Chris Taylor) Date: Mon, 9 Nov 2009 17:18:08 +0000 Subject: [whatwg] Proposal: Extension to the base element In-Reply-To: <4a60c8650911090859x221d5c05n9a9d7650cec7c91c@mail.gmail.com> References: <310995830911090143t642fc412v9021c44e417f8c1@mail.gmail.com> <45f4181c0911090326v1d303240mbc001a0e57ff80a6@mail.gmail.com> <4a60c8650911090345s56438508geae24a92b97ee3c0@mail.gmail.com> <7805560CD71B3B4793F5FDBCDE22E52B1A52500130@tpexmb01> <4a60c8650911090859x221d5c05n9a9d7650cec7c91c@mail.gmail.com> Message-ID: <7805560CD71B3B4793F5FDBCDE22E52B1A52500134@tpexmb01> David Workman said: > Chris, > > That's pretty much what I was thinking yes. I was referring > back to the second proposal of using a class attribute and > to Marius's suggestion of potentially using the 'rel' > attribute to specify the behavior. Your pseudo-code looks > fairly nice and neat though. OK, we're on the same page. However I'm not sure what advantages it would give except for saving some bytes for each element referencing a base URL. Would this introduce a level of complexity that may confuse authors? Chris This message has been scanned for malware by SurfControl plc. www.surfcontrol.com From ajvincent at gmail.com Mon Nov 9 12:25:52 2009 From: ajvincent at gmail.com (Alex Vincent) Date: Mon, 9 Nov 2009 12:25:52 -0800 Subject: [whatwg] Proposal: Extension to the base element Message-ID: <9301ed6b0911091225m362c529awa2387fd4365d6fb6@mail.gmail.com> How would HTML 4.01 clients respond to multiple BASE tags in a HTML 5 document? Even with extra attributes to say "Restrict this to a particular content-type," you'd probably see some less-than-desirable side effects - HTML 4 clients wouldn't care about them. The BASE tag affects how the document's other resources are loaded. Older clients reading the document would probably break. -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091109/dea5c069/attachment.htm> From julian.reschke at gmx.de Tue Nov 10 05:31:24 2009 From: julian.reschke at gmx.de (Julian Reschke) Date: Tue, 10 Nov 2009 14:31:24 +0100 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> Message-ID: <4AF96B2C.90500@gmx.de> Silvia Pfeiffer wrote: > ... > Further, Benno suggests extending http://www.w3.org/TR/XMLHttpRequest/ > with a property to disable following redirects automatically so as to > be able to expose the redirection. > > I am not aware if somebody else has suggested these use cases for CORS > and XMLHttpRequest before (this may not even be the right fora for > it), but since these are so closely linked to what we do in HTML5, I > thought it would be good to point it out. I would think that at > minimum Anne knows what to do with it, since he is editor on both. > ... Extending XMLHttpRequest for better control over redirects certainly would be a good thing. Note that there's work-in-progress of adding "proper" HTTP support to the Netscape plugin API (see <https://wiki.mozilla.org/Plugins:GenericHttpMethod>), where we have the same feature request, and it would be good to align this with XmlHttpRequest semantics. Best regards, Julian From silviapfeiffer1 at gmail.com Tue Nov 10 09:16:04 2009 From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer) Date: Wed, 11 Nov 2009 04:16:04 +1100 Subject: [whatwg] unexpected use of the CORS specification In-Reply-To: <0534B6F4-3CCD-41B5-8DC1-1F01071FC7DA@apple.com> References: <2c0e02830911072335o71eee29cle3b21b4d9a03af18@mail.gmail.com> <7789133a0911080725j6f7003ceqf77b7c20e56dff7e@mail.gmail.com> <0534B6F4-3CCD-41B5-8DC1-1F01071FC7DA@apple.com> Message-ID: <2c0e02830911100916s79a59c15ha068a521c2470c56@mail.gmail.com> On Mon, Nov 9, 2009 at 12:35 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Nov 8, 2009, at 7:25 AM, Adam Barth wrote: > >> I don't see the connection with CORS. ?The browser is free to request >> whatever URLs it wants. ?The results need not be accessible to >> content. ?Maybe I'm misunderstanding. > > The proposal at the link was for a method to do URL unshortening as a > client-side script in the browser. That would indeed require CORS. A feature > built-in to the browser would not. Yes, there are different ways to solve this and we can go all the way to the browser, or leave it to a script. But to push it to a script (which I think is preferable), we need CORS. Cheers, Silvia. From lists.whatwg at stakface.com Tue Nov 10 10:55:57 2009 From: lists.whatwg at stakface.com (Kartikaya Gupta) Date: Tue, 10 Nov 2009 18:55:57 +0000 Subject: [whatwg] Polynomial DOM growth with active formatting elements Message-ID: <20091110185558.558A58C9A@looneymail-mx3.g.dreamhost.com> If you have a page like this: <!DOCTYPE HTML> <html><body> <font size="2" face="Verdana"> <p align="left">Some text <font size="2" face="Verdana"> <p align="left">Some text </body></html> according to the HTML5 parser rules, I believe this should create a DOM with 3 font elements that looks something like this: <!DOCTYPE HTML><HTML><HEAD></HEAD><BODY> <FONT face="Verdana" size="2"> <P align="left">Some text <FONT face="Verdana" size="2"> </FONT></P><P align="left"><FONT size="2" face="Verdana">Some text </FONT></P></FONT></BODY></HTML> However, if you add extend the original source with another font/p combination, like so: <!DOCTYPE HTML> <html><body> <font size="2" face="Verdana"> <p align="left">Some text <font size="2" face="Verdana"> <p align="left">Some text <font size="2" face="Verdana"> <p align="left">Some text </body></html> You end up with a DOM which has 6 font elements: <!DOCTYPE HTML><HTML><HEAD></HEAD><BODY> <FONT face="Verdana" size="2"> <P align="left">Some text <FONT face="Verdana" size="2"> </FONT></P><P align="left"><FONT size="2" face="Verdana">Some text <FONT face="Verdana" size="2"> </FONT></FONT></P><P align="left"><FONT face="Verdana" size="2"><FONT size="2" face="Verdana">Some text </FONT></FONT></P></FONT></BODY></HTML> .. and so on. In general the number of font elements in the DOM grows polynomially, with the result that pages like [1] and [2] end up with hundreds of thousands of font elements. I haven't even been able to successfully parse [3] with either our own HTML5 parser or the one at validator.nu, it just gobbles up all available memory and asks for more. Is this behavior expected, or is it a bug in the spec? Obviously shipping browsers don't demonstrate this behavior (nor does Firefox's HTML5 parser - see bugzilla 525960) so I'm wondering if the spec could be modified to not have this polynomial-growth behavior. Cheers, kats [1] http://www.miprepzone.com/past.asp?Category=%27news%27 [2] http://info4.juridicas.unam.mx/ijure/tcfed/8.htm?s= [3] http://info4.juridicas.unam.mx/ijure/tcfed/1.htm?s= From micdesim at gmail.com Tue Nov 10 12:23:37 2009 From: micdesim at gmail.com (Michelangelo De Simone) Date: Tue, 10 Nov 2009 21:23:37 +0100 Subject: [whatwg] validationMessage Message-ID: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> Hi, I've been dealing with the validationMessage implementation in WebKit. As some of WebKit member pointed out it's quite unusual for an attribute to "return a suitably *localized message* that the user agent would show the user". Couldn't such behavior be potentially heterogeneous among UAs and localizations? What is the rationale about this choice? A simpler behavior with a predetermined list of return values (eg: i.validationMessage == VALUEMISSING) could be much more efficient for authors and implementors to deal with, IMHO. Thank you for your feedbacks. -- Bye, Michelangelo From scott.gonzalez at gmail.com Tue Nov 10 14:37:51 2009 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Tue, 10 Nov 2009 18:37:51 -0400 Subject: [whatwg] validationMessage In-Reply-To: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> References: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> Message-ID: <9450c5340911101437l26be3d09m72dbe8230b5cb87d@mail.gmail.com> Wouldn't the UA be written for a specific language that would be independent of the language the page's content is written in? For example, a user in Spain would be using a UA with a Spanish locale (the UA's menus, dialogs, button labels, etc. would all be in Spanish). If that user were to visit a page written in French wouldn't the content generated by the UA still be in Spanish? So an alert would contain a message in French, but a button in Spanish. I would expect the same thing to happen with validation messages. As for the suggestion of the validation message just being a constant, you can just check the validity state if you want to provide custom messages. On Tue, Nov 10, 2009 at 4:23 PM, Michelangelo De Simone <micdesim at gmail.com>wrote: > Hi, > > I've been dealing with the validationMessage implementation in WebKit. As > some of WebKit member pointed out it's quite unusual for an attribute to > "return a suitably *localized message* that the user agent would show the > user". > > Couldn't such behavior be potentially heterogeneous among UAs and > localizations? > > What is the rationale about this choice? A simpler behavior with a > predetermined list of return values (eg: i.validationMessage == > VALUEMISSING) could be much more efficient for authors and implementors to > deal with, IMHO. > > Thank you for your feedbacks. > -- > Bye, Michelangelo > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091110/1b26fcee/attachment.htm> From simonp at opera.com Wed Nov 11 07:05:53 2009 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Nov 2009 16:05:53 +0100 Subject: [whatwg] Web Workers: Worker.onmessage Message-ID: <op.u28j73uyidj3kv@zcorpandell.linkoping.osa> Shouldn't setting onmessage on a Worker object enable the port message queue? Currently step 8 of the "run a worker" algorithm enables the port message queue for the WorkerGlobalObjectScope side, but it is never enabled when going in the other direction, if I'm reading the spec correctly. -- Simon Pieters Opera Software From philipj at opera.com Wed Nov 11 07:36:35 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Wed, 11 Nov 2009 16:36:35 +0100 Subject: [whatwg] <video> abort and error should bubble for simplicity Message-ID: <op.u28lm9ihsr6mfa@sisko> Since we are no longer using progress events for media elements we don't have the external requirement that abort/error shouldn't bubble. I'd like them to bubble, because: 1. error events fired on <source> will bubble to <video>, which is quite useful if one doesn't particularly care which source failed (one need not register an event handler on each individual source attribute) 2. Implementors don't have to deal with the possibility that events of the same name and type sometimes bubbles and sometimes not. 3. It's the same as for <img>, which all else equals seems nice and simple. I'll note that <video> abort/error events in Firefox already seems to bubble while they apparently don't in Safari. We'd like to align with Firefox and have the spec changed. -- Philip J?genstedt Opera Software From simonp at opera.com Wed Nov 11 07:39:46 2009 From: simonp at opera.com (Simon Pieters) Date: Wed, 11 Nov 2009 16:39:46 +0100 Subject: [whatwg] Web Workers: Worker.onmessage In-Reply-To: <op.u28j73uyidj3kv@zcorpandell.linkoping.osa> References: <op.u28j73uyidj3kv@zcorpandell.linkoping.osa> Message-ID: <op.u28lsksdidj3kv@zcorpandell.linkoping.osa> On Wed, 11 Nov 2009 16:05:53 +0100, Simon Pieters <simonp at opera.com> wrote: > Shouldn't setting onmessage on a Worker object enable the port message > queue? > > Currently step 8 of the "run a worker" algorithm enables the port > message queue for the WorkerGlobalObjectScope side, but it is never > enabled when going in the other direction, if I'm reading the spec > correctly. Hmm. Actually, step 12 and 13 of the Worker constructor enable the port message queue for both the inside and outside ports. Why does the "run a worker" algorithm enable one of them again? Isn't it too early to enable the port message queues before the worker has run and set 'onmessage'? -- Simon Pieters Opera Software From beidson at apple.com Wed Nov 11 17:48:34 2009 From: beidson at apple.com (Brady Eidson) Date: Wed, 11 Nov 2009 17:48:34 -0800 Subject: [whatwg] AJAX History Concerns Message-ID: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> For reference see section 6.10.2 of the spec. In getting an implementation for pushState(), replaceState(), and clearState() going I've had a few concerns. pushState() and replaceState(): When pushState() or replaceState() are called with a URL argument, the document's current address is changed. This has a lot of side effects in that it is exposed to scripts and the DOM and most modern user agents would update their UI to show this. However, this same section takes care to point out "The title is purely advisory. User agents might use the title in the user interface." Indeed, many user agents would show the title of the current page at the top of the browser window or tab, in their back/forward list, and possibly in their global persistent history. But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM. I'm questioning the reasoning behind this distinction and am curious if it was intentional or not. clearState(): The following text describes clearState(): "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any. Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history." Imagine the following scenario: A document has 5 state entries. They each have a different URL as follows: http://www.example.com/page.html?1, http://www.example.com/page.html?2, http://www.example.com/page.html?3, http://www.example.com/page.html?4, and http://www.example.com/page.html?5 The current entry is the 3rd entry. A script calls "clearState()" so these entries are all cleared out, including the current entry. Since the current entry was removed, the current entry after the clearState() call is changed to be the last entry for the Document. My reading of the spec is that after clearState() returns, the entries 1-4 will be gone completely, the state object for entry 5 will have been cleared, and entry 5 will now be the current entry. This has the side effect of the URL for the current entry - http://www.example.com/page.html?5 - not matching the current URL of the document - http://www.example.com/page.html?3 Is my understanding of what the current entry should be correct? If not, what am I missing? And is the disjoint between the Document's URL and the current entries URL correct? If not, what am I missing? Thanks, ~Brady From philipj at opera.com Wed Nov 11 18:23:54 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Thu, 12 Nov 2009 03:23:54 +0100 Subject: [whatwg] Microdata DOM API issues Message-ID: <op.u29flv14sr6mfa@worf> I've been playing with the microdata DOM APIs again, continuing the JavaScript experimental implementation <http://gitorious.org/microdatajs>. It's not small or elegant, but at least some spec issues have come up in the process. What is the http://www.w3.org/1999/xhtml/microdata# URI? Just leftovers from earlier revisions to the spec? Why are the algorithms for extracting RDF gone? All that's left is the book example with the equivalent Turtle, but it would be nice if it were actually defined how to extract RDF. The same for the JSON stuff, was that no good? http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items "Otherwise, if one of the other elements in pending is an ancestor element of candidate, and that element is scope, then remove candidate from pending." "Otherwise, if one of the other elements in pending is an ancestor element of candidate, and that element also has scope as its nearest ancestor element with an itemscope attribute specified, then remove candidate from pending." The intention of these requirements seems to be to eliminate redundant elements in pending, but a comment on the intention of each in the spec would be helpful as it's quite cryptic right now. http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#microdata-dom-api itemtype and itemid are both URL attributes and therefore when getting itemType and itemId relative URLs should be resolved (even if only absolute URLs are valid). Correct? itemprop and itemref are both "unordered set of unique space-separated tokens", but in HTMLElement only itemProp is a DOMSettableTokenList while itemRef is a DOMString. This doesn't really make sense, so make itemRef a DOMSettableTokenList too? From reading the spec it's not obvious (without following cross-references) that itemProp isn't just a plain string. An example using .itemProp.contains(name) or similar would make this more difficult to miss. http://www.whatwg.org/specs/vocabs/current-work/#vcard Having clickable cross-references in this spec would help a lot when reviewing! Grammar: Let value *be* the result of collecting the first vCard subproperty named value in subitem. "Let n1 be the value of the first property named family-name in subitem, or the empty string if there is no such property or the property's value is itself an item." Why not use "collecting the first vCard subproperty" here? Not doing so had me trying to find how the two were different, but I couldn't find any differences given that the values are later escaped. There's also the issue of how newlines from textContent values are escaped. Applying the vCard extraction algorithm to the spec example gives: BEGIN:VCARD PROFILE:VCARD VERSION:3.0 SOURCE:http://foolip.org/microdatajs/demo/vcard.html NAME:vCard demo FN:Jack Bauer PHOTO;VALUE=URI:http://foolip.org/microdatajs/demo/jack-bauer.jpg ORG:Counter-Terrorist Unit;Los Angeles Division ADR:;;10201 W. Pico Blvd.;Los Angeles;CA;90064;United States GEO:34.052339;-118.410623 TEL;TYPE=work:+1 (310)\n 597 3781 URL;VALUE=URI:http://en.wikipedia.org/wiki/Jack_Bauer URL;VALUE=URI:http://www.jackbauerfacts.com/ EMAIL:j.bauer at la.ctu.gov.invalid TEL;TYPE=cell:+1 (310) 555\n 3781 NOTE:If I'm out in the field\, you may be better off\n contacting Chloe O'B rian if it's about\n work\, or ask Tony Almeida if\n you're interested in the CTU five-a-side football team we're trying\n to get going. AGENT;VALUE=VCARD:BEGIN:VCARD\nPROFILE:VCARD\nVERSION:3.0\nSOURCE:http://fo olip.org/microdatajs/demo/vcard.html\nNAME:vCard demo\nEMAIL\;VALUE=URI:ma ilto:c.obrian at la.ctu.gov.invalid\nFN:Chloe O'Brian\nN:O'Brian\;Chloe\;\;\; \nEND:VCARD\n AGENT:Tony Almeida REV:2008-07-20T21:00:00+0100 TEL;TYPE=home:01632 960 123 N:Bauer;Jack;;; END:VCARD TEL and NOTE has line breaks that are just because of how the HTML source is formatted. Importing this into Gmail preserves these linebreaks which looks quite broken. Unless we expect text fields to contain meaningful formatting, perhaps simply collapsing all whitespace into a single space is OK? In the best of worlds <br> would be converted to \n, but I'm not sure if it's worth the trouble. Finally on vCard, the final part of the extraction algorithm goes to great trouble to guess what is the family name and what is the given name. This guess will be broken for transliterated east Asian names (CJKV that I know of, maybe others too). Just saying. Also, why is it important to explicitly add N:;;;; for organizations? http://www.whatwg.org/specs/vocabs/current-work/#vevent "Add an iCalendar line with the type name and the value value to output." At this point value is undefined. Given the algorithm for extracting iCal, it seems that dtstart and dtend must be specified using <time datetime="">, as it's only for time elements that the time stamps will be properly formatted (stripping - and :) There are some errors in the example. I got it working by applying this diff: --- vevent.js.orig 2009-11-11 10:52:37.000000000 +0100 +++ vevent.js 2009-11-11 23:54:15.000000000 +0100 @@ -1,3 +1,3 @@ function getCalendar(node) { - while (node && (!node.nodeScope || !node.itemType == 'http://microformats.org/profile/hcalendar#vevent')) + while (node && (!node.itemScope || !node.itemType == 'http://microformats.org/profile/hcalendar#vevent')) node = node.parentNode; @@ -26,3 +26,3 @@ value = value.replace(/;/g, '\\;'); - value = value.replace(/,/g, \\,'); + value = value.replace(/,/g, '\\,'); value = value.replace(/\n/g, '\\n'); @@ -31,3 +31,3 @@ var name = prop.itemProp[nameIndex]; - if (!name.match(':') && !name.match('.')) + if (!name.match(':') && !name.match('\\.')) calendar += name.toUpperCase() + parameters + ':' + value + '\r\n'; Perhaps /\./ would be better to make it clear that it's a regexp. Also: if (prop.date && prop.time) date and time aren't properties on HTMLTimeElement, I don't know what this is. Is there or should there be a DOM API for determining if a string is a valid date string other than implementing those algorithms in script? http://www.whatwg.org/specs/vocabs/current-work/#licensing-works What's the n in http://n.whatwg.org/work? If this URL is going to stick, it would be nice if there were also something to be seen at that page. Also, the conversion to RDF section isn't really useful and seems to hide some assumptions about how the properties vocabulary should be prefixed with http://n.whatwg.org/work and how the http://www.w3.org/1999/xhtml/microdata# prefix is supposed to be used. http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#domtokenlist The DOM intro box doesn't explain the return value for .toggle(), you have to consult the algorithm to figure it out. I'm sure there will be more issues, but that's it for now. -- Philip J?genstedt From bruant at enseirb-matmeca.fr Wed Nov 11 19:19:17 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Wed, 11 Nov 2009 19:19:17 -0800 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case Message-ID: <4AFB7EB5.7010001@enseirb-matmeca.fr> Hi, This is a new proposal taking into account the feedback I recieved to the "[WebWorkers] About the delegation example" message. In the delegation example of the WebWorker spec, we can see this line : "var num_workers = 10;" My concern is about the arbitrarity of the "10". Regarding the hardware, the operating system and the WebWorker implementation, on one hand, this "10" may not result in a better performance than if num_worker was equal to 1. On the other hand, the user agent configuration may have better performances with a greater number of workers (16 ? 100 ?). My proposal is to add an attribute to the navigator object to write this : "var num_workers = navigator.optimalWorkerNumber; var items_per_worker = 10000000/num_workers;" (uneven dividing can easily be solved) (the name "optimalWorkerNumber" is not good, but I will use it in the rest of this e-mail) This attribute have the following properties : - It's only dependant on the hardware, the operating system and the WebWorker implementation (thus, it is not dynamically computed by the user agent at each call and two calls in the same hardware//OS//WebWorker implementation have the same result). - In the same running conditions (same memory available, same number of process running concurrently...) running the "same algorithm" (an easy delegation algorithm) has a significantly better performance with (navigator.optimalWorkerNumber) workers than (navigator.optimalWorkerNumber - 1) workers - In the same running conditions, running the same algorithm has no significantly better performance with (navigator.optimalWorkerNumber +1) workers than (navigator.optimalWorkerNumber) workers Thanks for your feedback (previous and coming) David From bzbarsky at MIT.EDU Wed Nov 11 19:32:48 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 11 Nov 2009 22:32:48 -0500 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFB7EB5.7010001@enseirb-matmeca.fr> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> Message-ID: <4AFB81E0.7000100@mit.edu> On 11/11/09 10:19 PM, David Bruant wrote: > This attribute have the following properties : > - It's only dependant on the hardware, the operating system and the > WebWorker implementation (thus, it is not dynamically computed by the > user agent at each call and two calls in the same > hardware//OS//WebWorker implementation have the same result). > - In the same running conditions (same memory available, same number of > process running concurrently...) running the "same algorithm" (an easy > delegation algorithm) has a significantly better performance with > (navigator.optimalWorkerNumber) workers than > (navigator.optimalWorkerNumber - 1) workers > - In the same running conditions, running the same algorithm has no > significantly better performance with (navigator.optimalWorkerNumber +1) > workers than (navigator.optimalWorkerNumber) workers I believe that these conditions are mutually contradictory. Indeed, condition 1 requires that optimalWorkerNumber be a constant independent of what the browser itself and other applications are doing. Condition 2 requires that running with navigator.optimalWorkerNumber has better performance than running with (navigator.optimalWorkerNumber - 1) workers. In particular, it requires that this be the case even if there is already one worker doing something (due to condition 1). This implies that performance with (navigator.optimalWorkerNumber+1) workers be better than that with navigator.optimalWorkerNumber workers, which directly violates condition 3. -Boris From Simetrical+w3c at gmail.com Wed Nov 11 20:16:02 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Wed, 11 Nov 2009 23:16:02 -0500 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present Message-ID: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> I already filed a bug <http://www.w3.org/Bugs/Public/show_bug.cgi?id=8268>, but figured I'd copy it here to get more discussion. Wikipedia just experimented with switching to an HTML5 doctype. A lot of user tools broke, and after two hours of investigation, we determined that the problem is intractable and switched back to XHTML 1.0 Transitional. XMLHttpRequest was historically intended only for XML, and lots of scripts rely on the responseXML property being set to a Document. In current browsers, this only happens when the document is actually well-formed XML. But named entities are treated differently based on the doctype. Consider this document: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html><head> <title>Hello</title> </head> <body> <p> </p> </body> </html> This works just fine in all browsers I tested in (latestish versions of Firefox, Chrome, Opera). However, if you serve the exact same document but replace the doctype with <!DOCTYPE html>, all of them throw a syntax error on  . Practically speaking, this means that any site that wants to serve content compatible with XHR cannot use either of the two doctypes that the spec recommends for authors. There are a variety of widely-used scripts on Wikipedia that rely on XHR, so this is currently a blocker for us. It's very unlikely that we'll deploy HTML5 in the foreseeable future if it means our users have to rewrite all their scripts. I'm pretty sure that XHR is used for screen-scraping beyond Wikipedia, too, so this will probably crop up elsewhere too. I don't know what the extent of the magic is that causes this problem. Could some reasonably minimal, distinctive doctype be invented that would avoid the problem but not make the document look to humans and validators like it thinks it's some old version of XHTML? If an existing XHTML doctype must be reused, should validators continue to raise warnings as they do now, or should an XHTML doctype be promoted from "obsolete permitted DOCTYPE" to a fully permitted doctype? Also, is this a wider problem? Are there any other tools besides browsers that might be magically allowing named entities for some doctypes only? From bzbarsky at MIT.EDU Wed Nov 11 20:39:47 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Wed, 11 Nov 2009 23:39:47 -0500 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present In-Reply-To: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> References: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> Message-ID: <4AFB9193.3070701@mit.edu> On 11/11/09 11:16 PM, Aryeh Gregor wrote: > I'm pretty sure that XHR is used for screen-scraping beyond Wikipedia, Since it'd fail any time the data is not well-formed XML, I'd actually expect such usage to be rare. It's not all that common to find "XHTML" on the web that happens to be well-formed XML. > Could some reasonably minimal, distinctive doctype be invented that > would avoid the problem but not make the document look to humans and > validators like it thinks it's some old version of XHTML? Yes, but browsers would have to add explicit support for it. > Also, is this a wider problem? Are there any other tools besides > browsers that might be magically allowing named entities for some > doctypes only? Sure; anything that actually goes and loads the DTD. -Boris From Simetrical+w3c at gmail.com Wed Nov 11 20:57:57 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Wed, 11 Nov 2009 23:57:57 -0500 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present In-Reply-To: <4AFB9193.3070701@mit.edu> References: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> <4AFB9193.3070701@mit.edu> Message-ID: <7c2a12e20911112057m41b42b5cre48e0b27a4536185@mail.gmail.com> On Wed, Nov 11, 2009 at 11:39 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > Since it'd fail any time the data is not well-formed XML, I'd actually > expect such usage to be rare. ?It's not all that common to find "XHTML" on > the web that happens to be well-formed XML. A number of popular web apps output mostly well-formed XML, as far as I know: vBulletin, WordPress, etc. Not even close to most websites, of course, but a significant number, I'd think. Of course, they probably don't have the same kind of script-writing community that Wikipedia does -- that's very peculiar to Wikipedia. > Yes, but browsers would have to add explicit support for it. That mostly defeats the point -- they could equally add explicit support for non-XML responseXML first. This should be a short- to medium-term problem only. This makes it sound like if Wikipedia switches to HTML5 and isn't willing to break all screen-scrapers on principle, we'll have to use an obsolete but conforming doctype. That's kind of a pain, particularly from an evangelism point of view. Especially if it raises validator warnings. But I guess that's where XML has gotten us. From bzbarsky at MIT.EDU Wed Nov 11 21:33:17 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 00:33:17 -0500 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present In-Reply-To: <7c2a12e20911112057m41b42b5cre48e0b27a4536185@mail.gmail.com> References: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> <4AFB9193.3070701@mit.edu> <7c2a12e20911112057m41b42b5cre48e0b27a4536185@mail.gmail.com> Message-ID: <4AFB9E1D.8040101@mit.edu> On 11/11/09 11:57 PM, Aryeh Gregor wrote: > A number of popular web apps output mostly well-formed XML, as far as > I know: vBulletin, WordPress, etc. I assume you meant "mostly" as in "most of the pages are well-formed", not "pages are mostly well-formed", since the latter is useless, right? I did a brief survey of obvious sites fitting those descriptions that I had in my browser history at the moment. These were not-well-formed: http://www.dria.org/wordpress/archives/2009/11/10/1043/ http://bisdaktech.wordpress.com/ http://weekinthenee.wordpress.com/2009/11/11/sitting-in-a-park-in-paris-france/ http://terrytao.wordpress.com/2009/10/29/displaying-mathematics-on-the-web/ http://ehren.wordpress.com/2009/10/24/a-gcc-hack-my-0-1-release/ http://www.nvnews.net/vbulletin/showthread.php?t=104201 http://www.nvnews.net/vbulletin/showthread.php?t=132449 These are: http://boomswaggerboom.wordpress.com/ http://fiber-space.de/wordpress/?p=1016 http://dafizilla.wordpress.com/2009/11/08/karmic-koala-hides-firefox-context-menuitems-icons/ So either you're looking at a totally different dataset or "mostly" is a bit of a stretch.... > Not even close to most websites, of course, but a significant number, I'd think. Sure. 0.01% of all websites is a "significant number". I just think it's broken often enough, and easy enough to break by accident, that relying on it working for screen scraping is not likely to be happening on a wide scale.... >> Yes, but browsers would have to add explicit support for it. > > That mostly defeats the point -- they could equally add explicit > support for non-XML responseXML first. Yep. > This makes it sound like if Wikipedia switches to HTML5 and isn't > willing to break all screen-scrapers on principle, we'll have to use > an obsolete but conforming doctype. Or stop using HTML named entities, yes. -Boris From gundersen at gmail.com Wed Nov 11 23:24:19 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Thu, 12 Nov 2009 18:24:19 +1100 Subject: [whatwg] AJAX History Concerns In-Reply-To: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> Message-ID: <45f4181c0911112324l3255becfkd2204087f44247e5@mail.gmail.com> I'm not exactly sure what you mean in the first case. How is the title change hidden from the DOM? When you call document.title = "new title", then the title does change in the DOM and in the UI. About your second question, I think you misunderstood it. As you said, it says: "Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history." In other words, the last entry in the session history must now equal what was the current entry. It's just worded a bit confusingly. A better way of saying it would be: "Then, if the current entry was removed in the previous step, the current entry must now be pushed onto the session history". Marius Gundersen On Thu, Nov 12, 2009 at 12:48 PM, Brady Eidson <beidson at apple.com> wrote: > For reference see section 6.10.2 of the spec. > > In getting an implementation for pushState(), replaceState(), and > clearState() going I've had a few concerns. > > pushState() and replaceState(): > > When pushState() or replaceState() are called with a URL argument, the > document's current address is changed. This has a lot of side effects in > that it is exposed to scripts and the DOM and most modern user agents would > update their UI to show this. > > However, this same section takes care to point out "The title is purely > advisory. User agents might use the title in the user interface." Indeed, > many user agents would show the title of the current page at the top of the > browser window or tab, in their back/forward list, and possibly in their > global persistent history. > > But unlike the URL which actually changes in the Document object and is > therefore exposed to the DOM, this "purely advisory" title change is hidden > from the DOM. I'm questioning the reasoning behind this distinction and am > curious if it was intentional or not. > > clearState(): > > The following text describes clearState(): > > "When this method is invoked, the user agent must remove from the session > history all the entries from the first state object entry for that Document > object up to the last entry that references that same Document object, if > any. > > Then, if the current entry was removed in the previous step, the current > entry must be set to the last entry for that Document object in the session > history." > > Imagine the following scenario: > > A document has 5 state entries. > They each have a different URL as follows: > http://www.example.com/page.html?1, http://www.example.com/page.html?2, > http://www.example.com/page.html?3, http://www.example.com/page.html?4, > and http://www.example.com/page.html?5 > The current entry is the 3rd entry. > A script calls "clearState()" so these entries are all cleared out, > including the current entry. > Since the current entry was removed, the current entry after the > clearState() call is changed to be the last entry for the Document. > > My reading of the spec is that after clearState() returns, the entries 1-4 > will be gone completely, the state object for entry 5 will have been > cleared, and entry 5 will now be the current entry. > > This has the side effect of the URL for the current entry - > http://www.example.com/page.html?5 - not matching the current URL of the > document - http://www.example.com/page.html?3 > > Is my understanding of what the current entry should be correct? > If not, what am I missing? > And is the disjoint between the Document's URL and the current entries URL > correct? > If not, what am I missing? > > Thanks, > ~Brady > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091112/32e1463d/attachment.htm> From Simetrical+w3c at gmail.com Thu Nov 12 07:14:29 2009 From: Simetrical+w3c at gmail.com (Aryeh Gregor) Date: Thu, 12 Nov 2009 10:14:29 -0500 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present In-Reply-To: <4AFB9E1D.8040101@mit.edu> References: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> <4AFB9193.3070701@mit.edu> <7c2a12e20911112057m41b42b5cre48e0b27a4536185@mail.gmail.com> <4AFB9E1D.8040101@mit.edu> Message-ID: <7c2a12e20911120714g2b08c1c5of447d649e0df3c74@mail.gmail.com> On Thu, Nov 12, 2009 at 12:33 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > I assume you meant "mostly" as in "most of the pages are well-formed", not > "pages are mostly well-formed", since the latter is useless, right? > > I did a brief survey of obvious sites fitting those descriptions that I had > in my browser history at the moment. . . . > > So either you're looking at a totally different dataset or "mostly" is a bit > of a stretch.... I admit I didn't look closely. At a guess, maybe the default WordPress skin(s) are valid XHTML, but custom skins are very popular for WordPress and those mostly aren't valid XHTML? MediaWiki is unreasonably difficult to reskin, so that's not much of a problem for us . . . > Sure. ?0.01% of all websites is a "significant number". ?I just think it's > broken often enough, and easy enough to break by accident, that relying on > it working for screen scraping is not likely to be happening on a wide > scale.... You're probably right. > Or stop using HTML named entities, yes. That's not really a very good option, given the size of MediaWiki's code base and the size of Wikipedia's database, and the ugliness of trying to remember what   is when reading the HTML source. It sounds like we're stuck with a legacy doctype if we don't want to break screen-scrapers. From gsneddon at opera.com Thu Nov 12 08:17:06 2009 From: gsneddon at opera.com (Geoffrey Sneddon) Date: Thu, 12 Nov 2009 17:17:06 +0100 Subject: [whatwg] HTML5 doctypes incompatible with XHR if named entities present In-Reply-To: <7c2a12e20911120714g2b08c1c5of447d649e0df3c74@mail.gmail.com> References: <7c2a12e20911112016n3d6eeeedj848a1e6ed9cb8cf9@mail.gmail.com> <4AFB9193.3070701@mit.edu> <7c2a12e20911112057m41b42b5cre48e0b27a4536185@mail.gmail.com> <4AFB9E1D.8040101@mit.edu> <7c2a12e20911120714g2b08c1c5of447d649e0df3c74@mail.gmail.com> Message-ID: <4AFC3502.5030404@opera.com> Aryeh Gregor wrote: > On Thu, Nov 12, 2009 at 12:33 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> I assume you meant "mostly" as in "most of the pages are well-formed", not >> "pages are mostly well-formed", since the latter is useless, right? >> >> I did a brief survey of obvious sites fitting those descriptions that I had >> in my browser history at the moment. . . . >> >> So either you're looking at a totally different dataset or "mostly" is a bit >> of a stretch.... > > I admit I didn't look closely. At a guess, maybe the default > WordPress skin(s) are valid XHTML, but custom skins are very popular > for WordPress and those mostly aren't valid XHTML? MediaWiki is > unreasonably difficult to reskin, so that's not much of a problem for > us . . . Even with the default skin it's easy to break (e.g., search for U+FFFF). That'll be output to the page and make it not well-formed. -- Geoffrey Sneddon ? Opera Software <http://gsnedders.com/> <http://www.opera.com/> From beidson at apple.com Thu Nov 12 09:12:19 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 09:12:19 -0800 Subject: [whatwg] AJAX History Concerns In-Reply-To: <45f4181c0911112324l3255becfkd2204087f44247e5@mail.gmail.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <45f4181c0911112324l3255becfkd2204087f44247e5@mail.gmail.com> Message-ID: <DCFF2990-A25F-4D4B-9C8F-605312A403A1@apple.com> On Nov 11, 2009, at 11:24 PM, Marius Gundersen wrote: > I'm not exactly sure what you mean in the first case. How is the title change hidden from the DOM? When you call document.title = "new title", then the title does change in the DOM and in the UI. Sure, that's my point. You're talking about the DOM API to title, but I'm talking about the new API that says the title you pass in the function calls is "purely advisory." So if you do: document.title = "Old title"; replaceState("state object", "New title", "http://example.com/index.html?2"); alert(document.title); What does the alert show? The current back/forward entry would says "New title" in most (all?) modern browsers. But the actual title of the document, as exposed to the DOM, is still "Old title" This seems inconsistent and silly. > About your second question, I think you misunderstood it. As you said, it says: > "Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history." > > In other words, the last entry in the session history must now equal what was the current entry. It's just worded a bit confusingly. I agree it's confusing. I don't see how you're right here, though. Imagine the following session history. 3 documents - A, B, and C. Each have more than one entry because they're all using this hawt new API: A1 - A2 - B1 - *B2* - B3 - C1 - C2 In this scenario, B2 is the current entry. "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any." So If a script on document B calls "clearState()", then quite clear, entries B1, B2, and B3 will be removed. Oh no, the current entry was removed! So, now what is the current entry? This is most certainly where it gets confusing: "Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history." The Document object in question is B. B1, B2, and B3 were just removed. There is no "last entry for that Document object" because we just removed them all. In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed. Which would leave us the following: A1 - A2 - *B3* - C1 - C2 I'm not saying this is correct, but it's my best following of the described procedure. Your interpretation is that the list should be: A1 - A2 - C1 - C2 - B2 That seems insane to me. We've never given scripts the ability to arbitrarily re-order the back/forward list before, and I don't think we should start now. Even pushState() carefully preserves the ordering of documents A - B - C. What you're proposing is that document B can "cut in line" in front of document C's entries in the list. It seems to me that malicious and/or downright rude site developers could abuse this to always keep themselves "on top" of the back/forward list, breaking the UI expectations of what those little left/right arrows mean. > A better way of saying it would be: > > "Then, if the current entry was removed in the previous step, the current entry must now be pushed onto the session history". That wording would be very clear, but I don't think that's at all what the current language is intending. Also, if that was the actual intent and wording, I would object (see discussion above). ~Brady > > Marius Gundersen > > > On Thu, Nov 12, 2009 at 12:48 PM, Brady Eidson <beidson at apple.com> wrote: > For reference see section 6.10.2 of the spec. > > In getting an implementation for pushState(), replaceState(), and clearState() going I've had a few concerns. > > pushState() and replaceState(): > > When pushState() or replaceState() are called with a URL argument, the document's current address is changed. This has a lot of side effects in that it is exposed to scripts and the DOM and most modern user agents would update their UI to show this. > > However, this same section takes care to point out "The title is purely advisory. User agents might use the title in the user interface." Indeed, many user agents would show the title of the current page at the top of the browser window or tab, in their back/forward list, and possibly in their global persistent history. > > But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM. I'm questioning the reasoning behind this distinction and am curious if it was intentional or not. > > clearState(): > > The following text describes clearState(): > > "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any. > > Then, if the current entry was removed in the previous step, the current entry must be set to the last entry for that Document object in the session history." > > Imagine the following scenario: > > A document has 5 state entries. > They each have a different URL as follows: http://www.example.com/page.html?1, http://www.example.com/page.html?2, http://www.example.com/page.html?3, http://www.example.com/page.html?4, and http://www.example.com/page.html?5 > The current entry is the 3rd entry. > A script calls "clearState()" so these entries are all cleared out, including the current entry. > Since the current entry was removed, the current entry after the clearState() call is changed to be the last entry for the Document. > > My reading of the spec is that after clearState() returns, the entries 1-4 will be gone completely, the state object for entry 5 will have been cleared, and entry 5 will now be the current entry. > > This has the side effect of the URL for the current entry - http://www.example.com/page.html?5 - not matching the current URL of the document - http://www.example.com/page.html?3 > > Is my understanding of what the current entry should be correct? > If not, what am I missing? > And is the disjoint between the Document's URL and the current entries URL correct? > If not, what am I missing? > > Thanks, > ~Brady > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091112/6fbc11f2/attachment-0001.htm> From bruant at enseirb-matmeca.fr Thu Nov 12 09:49:41 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Thu, 12 Nov 2009 09:49:41 -0800 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFB81E0.7000100@mit.edu> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> Message-ID: <4AFC4AB5.7020606@enseirb-matmeca.fr> Boris Zbarsky a ?crit : > On 11/11/09 10:19 PM, David Bruant wrote: >> This attribute have the following properties : >> - It's only dependant on the hardware, the operating system and the >> WebWorker implementation (thus, it is not dynamically computed by the >> user agent at each call and two calls in the same >> hardware//OS//WebWorker implementation have the same result). >> - In the same running conditions (same memory available, same number of >> process running concurrently...) running the "same algorithm" (an easy >> delegation algorithm) has a significantly better performance with >> (navigator.optimalWorkerNumber) workers than >> (navigator.optimalWorkerNumber - 1) workers >> - In the same running conditions, running the same algorithm has no >> significantly better performance with (navigator.optimalWorkerNumber +1) >> workers than (navigator.optimalWorkerNumber) workers > > I believe that these conditions are mutually contradictory. > > Indeed, condition 1 requires that optimalWorkerNumber be a constant > independent of what the browser itself and other applications are doing. => That is what I meant (and still mean) > Condition 2 requires that running with navigator.optimalWorkerNumber > has better performance than running with > (navigator.optimalWorkerNumber - 1) workers. In particular, it > requires that this be the case even if there is already one worker > doing something (due to condition 1). This implies that performance > with (navigator.optimalWorkerNumber+1) workers be better than that > with navigator.optimalWorkerNumber workers, which directly violates > condition 3. => You're perfectly right. I reformulate the definition of "running conditions" (appearing in condition 2 and 3) as : "same memory available, same number of process running concurrently, no other worker running working on the same document". David > > -Boris From justin.lebar at gmail.com Thu Nov 12 11:22:17 2009 From: justin.lebar at gmail.com (Justin Lebar) Date: Thu, 12 Nov 2009 11:22:17 -0800 Subject: [whatwg] AJAX History Concerns In-Reply-To: <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> Message-ID: <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> > "The title [argument to pushState] is purely advisory. User agents might use the title in the user interface." > > But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM. ?I'm questioning the reasoning behind this distinction and am curious if it was intentional or not. What I did in my Firefox patch (which should be checked into trunk within a few weeks, I hope) is use that title only to identify the history entry in the pull-down back-forward menu (what's shown when you click the down arrow next to the forward button in Firefox). If you want the rest of the UI (e.g. browser title bar) to match up with this title, you have to set document.title. ?In fact, if you pushState with title 'Foo', then navigate back and then forward, the history entry's title will be reset to the document's title. ?(I intend to write something detailing tricks like these once we land the pushState patch.) On the one hand, the implementation as it is allows developers some control over the history entry title independent of the document title, and perhaps that's useful. ?On the other hand, most use cases I can imagine for setting the history entry title are only useful if it persists between back/forwards. It appears in my testing that if you do pushState("title1"); document.title="title2" Firefox shows "title2" in both the local and global history, so setting document.title appears to subsume most of the functionality of pushState's title argument. We could make the API change document.title and remember that change between back/forwards, but I think that would be unnecessarily complicated. After a pushState, you'd get a new document which shares all mutable state *except* its title with its sibling. Unless there's a compelling use for it, perhaps we should simplify the API by getting rid of the title parameter altogether. ?One can pretty easily update document.title on popStates manually. ?But perhaps I'm missing something; I recall at one time being convinced that the title parameter was important. ?:) > [Given] A1 - A2 - B1 - *B2* - B3 - C1 - C2 > >> "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any." > > In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed. I don't think removing the entry from the history implies that we clear its state object. Certainly the spec could be clarified, however. I don't think that Marius's reading, here that B1, B2, and B3 would all be removed, is completely unsupported by the text. But I also don't think that's what we want. If I understand things correctly, we always remove the current entry after a clearState. So perhaps the language could be "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document up to the second-to-last entry that references the same Document. The current entry is then set to the one remaining entry for the Document." That said, we didn't implement clearState when we did push/replaceState because it's hard to get right and we don't currently have a compelling use case. There are probably lots of things we'd change if we were going to implement it -- for instance, why go back to the last entry instead of staying at the current one? But that's probably a conversation for another thread. -Justin From bzbarsky at MIT.EDU Thu Nov 12 11:48:55 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 14:48:55 -0500 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFC4AB5.7020606@enseirb-matmeca.fr> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> <4AFC4AB5.7020606@enseirb-matmeca.fr> Message-ID: <4AFC66A7.2010404@mit.edu> On 11/12/09 12:49 PM, David Bruant wrote: > => You're perfectly right. I reformulate the definition of "running > conditions" (appearing in condition 2 and 3) as : > "same memory available, same number of process running concurrently, no > other worker running working on the same document". That doesn't help that much, unfortunately. Most simply, consider a quad-core chip and workers that are completely cpu-bound. If there are no other processes running, the optimal number of workers is 4. If there is one other process which is also completely cpu-bound running, the optimal number of workers is 3 (in the sense that 4 may well not satisfy your condition 3). This is really the same issue as having one worker running, but it's some process not under the browser's control. If, on the other hand, the workers are I/O bound (esp. network I/O latency bound), then the optimal number of workers can well be larger than the number of cores... -Boris From beidson at apple.com Thu Nov 12 11:52:35 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 11:52:35 -0800 Subject: [whatwg] AJAX History Concerns In-Reply-To: <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> Message-ID: <0A6975D5-0DC2-4B28-80A4-3E63C21456E3@apple.com> On Nov 12, 2009, at 11:22 AM, Justin Lebar wrote: >> "The title [argument to pushState] is purely advisory. User agents might use the title in the user interface." >> >> But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM. I'm questioning the reasoning behind this distinction and am curious if it was intentional or not. > > On the one hand, the implementation as it is allows developers some > control over the history entry title independent of the document > title, and perhaps that's useful. On the other hand, most use cases I > can imagine for setting the history entry title are only useful if it > persists between back/forwards. I guess having the history entry and the document.title be different at an exact moment in time may be useful, I just can't think of the use case. See a few responses below. > It appears in my testing that if you do pushState("title1"); > document.title="title2" Firefox shows "title2" in both the local and > global history, so setting document.title appears to subsume most of > the functionality of pushState's title argument. I imagine that's how it would probably work in most browsers. But there's still this quantum of inconsistency before the script first updates document.title. > We could make the API change document.title and remember that change > between back/forwards, but I think that would be unnecessarily > complicated. After a pushState, you'd get a new document which shares > all mutable state *except* its title with its sibling. Where does this new document come from? The whole point of this API is reusing the same document across back/forward entries. Also, my goal isn't to make things more complicated, but rather remove complication in the form of inconsitency. > Unless there's a compelling use for it, perhaps we should simplify the > API by getting rid of the title parameter altogether. One can pretty > easily update document.title on popStates manually. But perhaps I'm > missing something; I recall at one time being convinced that the title > parameter was important. :) After more thought and more input from others, this is what my current thoughts have boiled down to - Is there a compelling reason why the title parameter is here and that we can't just rely on the document's title as it existed at the time that pushState() or replaceState() was called? A use case someone can think of that isn't possible otherwise? If not, we should just get rid of it. > >> [Given] A1 - A2 - B1 - *B2* - B3 - C1 - C2 >> >>> "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any." >> >> In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed. > > I don't think removing the entry from the history implies that we > clear its state object. This is another point that is not clear. I assumed that the remaining entry should not have a state object, since "clearState()" seems to clear all state objects. One interesting side effect of "clearState()" not actually clearing the state object from the current entry means that once a script has opted in to AJAX history by calling "pushState()" or "replaceState()", they cannot explicitly opt out altogether. I haven't thought this through entirely and don't know if I care. > "When this method is invoked, the user agent must remove from the > session history all the entries from the first state object entry for > that Document up to the second-to-last entry that references the same > Document. The current entry is then set to the one remaining entry > for the Document." This makes sense to me, and I would support the text being updated to it. An interesting edge case would be if there is only one entry for the current document. Your text is precise enough to account for this, but in other areas of the spec we explicitly call out edge cases like this to make it clear. Something like: "If the current entry is the only entry for that Document, then the call to clearState() has no effect." > Certainly the spec could be clarified, however. I don't think that > Marius's reading, here that B1, B2, and B3 would all be removed, is > completely unsupported by the text. Me neither. But Document B "cutting in line" past Document C is unsupported and I have strong objections to that. I'd like that to be filtered out in no ambiguous terms! > That said, we didn't implement clearState when we did > push/replaceState because it's hard to get right and we don't > currently have a compelling use case. There are probably lots of > things we'd change if we were going to implement it -- for instance, > why go back to the last entry instead of staying at the current one? > But that's probably a conversation for another thread. Since the spec is in last call for comments and we have yet to see a single implementation of this, I'd like to keep focusing on it till we have it worked out... ;) ~Brady > > -Justin From justin.lebar at gmail.com Thu Nov 12 12:00:53 2009 From: justin.lebar at gmail.com (Justin Lebar) Date: Thu, 12 Nov 2009 12:00:53 -0800 Subject: [whatwg] Do we really need history.clearState()? Message-ID: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> As I alluded to in the thread "AJAX History Concerns," I'm not convinced that we need the history.clearState() function. I haven't been able to come up with a compelling case where a page would use this. I guess the idea is that I'm on Google Maps, which is using pushState to make a history entry every time I scroll the map. If I scroll around a lot, it might clobber my history and make it hard to go back to the page I was at before I began looking at the map. But it could be nice and at some point (possibly triggered by some user action) call clearState. Then I'd be able to click "back" and actually go back to the Document I was previously viewing. clearState as it exists doesn't match this use case particularly well. If we were concerned about clobbering history, we'd probably want to keep the two or three newest history entries and throw out all the rest of them. If you were really clever, you might be able to accomplish this by calling clearState and then using pushState to reconstruct the part of the history you want to keep. But getting the URLs right would be pretty tricky, especially if clearState took you to the last entry for the document, as currently specified. clearState is also useless if you don't use this single-document pushState model for your site. If we think clearing the history is useful for AJAX pages, I'm not sure why it wouldn't be useful for a web application which loads multiple documents. I think the use case I proposed is much better served by something like history.truncate(numBefore, numAfter), which would remove all but the numBefore entries before the current entry and the numAfter entries after the current entry. We'd subject this to the same-origin policy, of course, and stop removing entries in a direction as soon as we encountered an entry from another origin. I'm not sure if history.truncate() is a good idea -- do we really want to give pages that kind of control over the history? -- but at least I can actually imagine a page using it. Perhaps a better idea is leaving this whole issue to the UA, which could collapse all the entries from a single origin in the UI. Then we wouldn't need either function. -Justin From bruant at enseirb-matmeca.fr Thu Nov 12 12:40:49 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Thu, 12 Nov 2009 12:40:49 -0800 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFC66A7.2010404@mit.edu> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> <4AFC4AB5.7020606@enseirb-matmeca.fr> <4AFC66A7.2010404@mit.edu> Message-ID: <4AFC72D1.9020904@enseirb-matmeca.fr> Boris Zbarsky a ?crit : > On 11/12/09 12:49 PM, David Bruant wrote: >> => You're perfectly right. I reformulate the definition of "running >> conditions" (appearing in condition 2 and 3) as : >> "same memory available, same number of process running concurrently, no >> other worker running working on the same document". > > That doesn't help that much, unfortunately. Most simply, consider a > quad-core chip and workers that are completely cpu-bound. If there > are no other processes running, the optimal number of workers is 4. > If there is one other process which is also completely cpu-bound > running, the optimal number of workers is 3 (in the sense that 4 may > well not satisfy your condition 3). This is really the same issue as > having one worker running, but it's some process not under the > browser's control. => If you are comparing "no other processes running" and "one other process which is also completely cpu-bound running", you are not in what I've called "same running conditions". (because the number of concurrent processes is different). The condition 2 and 3 may be not well-expressed, however, the condition 1 is very important and particularly the fact that this number is independant of the "running conditions" (which are, IMHO, totally out of the scope of a high-level spec such as the web-workers one) and shouldn't be determined dynamically. I reformulate this way the conditions 2 and 3: - In "blank conditions" (no other processes/thread running on the CPU, enough memory to allocate the workers), running the same algorithm (an easy delegation algorithm) has significantly better performances with (navigator.optimalWorkerNumber) dedicated workers than with (navigator.optimalWorkerNumber -1) dedicated workers - In "blank conditions", running the same algorithm has no significantly better performances with (navigator.optimalWorkerNumber+1) dedicated workers than with (navigator.optimalWorkerNumber) dedicated workers Just to remind, the purpose of this attribute is to decide, at the beginning of a delegation algorithm what is the "optimal" number of workers to divide the work in a way that is optimal regarding the hardware, the OS and the worker implementation. No matter the running conditions, 2 calls return the same value for the same hardware//OS//Worker implementation. The idea behind this property is that even if you start running the algorithm with a lot of concurrent processes, you create a number of workers that cannot be ran concurrently at the beginning, but you may use optimally the ressources later (if the other processes/threads stop running, what you cannot control, but can still hope that it happens during the "algorithm lifetime". According to the spec, "workers are expected to be long-lived"). Thanks for your feedback David > > If, on the other hand, the workers are I/O bound (esp. network I/O > latency bound), then the optimal number of workers can well be larger > than the number of cores... > > -Boris From beidson at apple.com Thu Nov 12 13:08:24 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 13:08:24 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> Message-ID: <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> I think clearState() is a good idea but is just spec'ed poorly. Imagine the use case of the checkout procedure at an online merchant. There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order." It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information. But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant. The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order. In this case, clearState() fits the bill greatly! It is true that what is really being performed is "truncate this part of history." But we wouldn't to give scripts the ability to control parts of session history they don't own. And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries. One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others. I might be able to think of a use-case for that, but I don't see it being tremendously important. It could always be added later if there's demand for it. I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable. ~Brady On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote: > As I alluded to in the thread "AJAX History Concerns," I'm not > convinced that we need the history.clearState() function. > > I haven't been able to come up with a compelling case where a page > would use this. I guess the idea is that I'm on Google Maps, which is > using pushState to make a history entry every time I scroll the map. > If I scroll around a lot, it might clobber my history and make it hard > to go back to the page I was at before I began looking at the map. > But it could be nice and at some point (possibly triggered by some > user action) call clearState. Then I'd be able to click "back" and > actually go back to the Document I was previously viewing. > > clearState as it exists doesn't match this use case particularly well. > If we were concerned about clobbering history, we'd probably want to > keep the two or three newest history entries and throw out all the > rest of them. If you were really clever, you might be able to > accomplish this by calling clearState and then using pushState to > reconstruct the part of the history you want to keep. But getting the > URLs right would be pretty tricky, especially if clearState took you > to the last entry for the document, as currently specified. > > clearState is also useless if you don't use this single-document > pushState model for your site. If we think clearing the history is > useful for AJAX pages, I'm not sure why it wouldn't be useful for a > web application which loads multiple documents. > > I think the use case I proposed is much better served by something > like history.truncate(numBefore, numAfter), which would remove all but > the numBefore entries before the current entry and the numAfter > entries after the current entry. We'd subject this to the same-origin > policy, of course, and stop removing entries in a direction as soon as > we encountered an entry from another origin. > > I'm not sure if history.truncate() is a good idea -- do we really want > to give pages that kind of control over the history? -- but at least I > can actually imagine a page using it. > > Perhaps a better idea is leaving this whole issue to the UA, which > could collapse all the entries from a single origin in the UI. Then > we wouldn't need either function. > > -Justin From Olli.Pettay at helsinki.fi Thu Nov 12 13:08:31 2009 From: Olli.Pettay at helsinki.fi (Olli Pettay) Date: Thu, 12 Nov 2009 23:08:31 +0200 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> Message-ID: <4AFC794F.4050606@helsinki.fi> On 11/12/09 10:00 PM, Justin Lebar wrote: > > Perhaps a better idea is leaving this whole issue to the UA, which > could collapse all the entries from a single origin in the UI. Then > we wouldn't need either function. How would UA collapse entries from a single origin? I agree clearState is a bit limiting. Some sort of truncate would be better, and yet easy to use and shouldn't be much harder to implement than clearState. -Olli From beidson at apple.com Thu Nov 12 13:16:51 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 13:16:51 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> Message-ID: <5E05F7C3-6B49-46A1-94B3-0C0A09219117@apple.com> I should've responded to this more directly: On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote: > I think the use case I proposed is much better served by something > like history.truncate(numBefore, numAfter), which would remove all but > the numBefore entries before the current entry and the numAfter > entries after the current entry. We'd subject this to the same-origin > policy, of course, and stop removing entries in a direction as soon as > we encountered an entry from another origin. The History object is - quite purposefully - very limited in scope and abilities. Today, it gives the ability to navigate back and forward a number of steps. Period. The pushState() API adds a very limited way of adding new items programatically. clearState() also adds the ability for a script to remove entries, but only ones that it added. Period. Same-origin policy be damned, I really don't like the idea of a script being able to remove items that it didn't add. As I said in my previous reply, I think it might be useful to give a more fine-grained version of "clearState()", but that could always be added later if there's demand. And I still think it should be limited to affecting the string of the Document object's entries. ~Brady > > -Justin From bzbarsky at MIT.EDU Thu Nov 12 13:35:06 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 16:35:06 -0500 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFC72D1.9020904@enseirb-matmeca.fr> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> <4AFC4AB5.7020606@enseirb-matmeca.fr> <4AFC66A7.2010404@mit.edu> <4AFC72D1.9020904@enseirb-matmeca.fr> Message-ID: <4AFC7F8A.1050703@mit.edu> On 11/12/09 3:40 PM, David Bruant wrote: > => If you are comparing "no other processes running" and "one other > process which is also completely cpu-bound running", you are not in what > I've called "same running conditions". (because the number of concurrent > processes is different). Yes, but your condition 1 is that the value returned is independent of running conditions.... > The condition 2 and 3 may be not well-expressed, however, the condition > 1 is very important and particularly the fact that this number is > independant of the "running conditions" (which are, IMHO, totally out of > the scope of a high-level spec such as the web-workers one) and > shouldn't be determined dynamically. OK. > I reformulate this way the conditions 2 and 3: > - In "blank conditions" (no other processes/thread running on the CPU, > enough memory to allocate the workers), running the same algorithm (an > easy delegation algorithm) has significantly better performances with > (navigator.optimalWorkerNumber) dedicated workers than with > (navigator.optimalWorkerNumber -1) dedicated workers > - In "blank conditions", running the same algorithm has no significantly > better performances with (navigator.optimalWorkerNumber+1) dedicated > workers than with (navigator.optimalWorkerNumber) dedicated workers OK, but I'm not sure this is a useful number, then, since these "blank conditions" never happen in practice. > Just to remind, the purpose of this attribute is to decide, at the > beginning of a delegation algorithm what is the "optimal" number of > workers to divide the work in a way that is optimal regarding the > hardware, the OS and the worker implementation. I'm glad you put "optimal" in quotes.... ;) Is there a reason that apps that really care about this shouldn't just measure to see what number works best for them? > The idea behind this property is that even if you start running the > algorithm with a lot of concurrent processes, you create a number of > workers that cannot be ran concurrently at the beginning, but you may > use optimally the ressources later But in the meantime you will be using them very suboptimally, no? > (if the other processes/threads stop > running, what you cannot control, but can still hope that it happens > during the "algorithm lifetime". According to the spec, "workers are > expected to be long-lived"). Most of my apps are long-lived... -Boris From justin.lebar at gmail.com Thu Nov 12 14:03:15 2009 From: justin.lebar at gmail.com (Justin Lebar) Date: Thu, 12 Nov 2009 14:03:15 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <4AFC794F.4050606@helsinki.fi> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <4AFC794F.4050606@helsinki.fi> Message-ID: <c84706c70911121403g32b8317bm9f04656ec323b97@mail.gmail.com> On Thu, Nov 12, 2009 at 1:08 PM, Olli Pettay <Olli.Pettay at helsinki.fi> wrote: > On 11/12/09 10:00 PM, Justin Lebar wrote: >> >> Perhaps a better idea is leaving this whole issue to the UA, which >> could collapse all the entries from a single origin in the UI. ?Then >> we wouldn't need either function. > > How would UA collapse entries from a single origin? Right now, the back button means "take me to the previous history entry". The UA could add a "take me back to the previous document/origin" button. Similarly, the browser could collect together all the entries from a document or origin in the drop-down menu of history entries (the down arrow next to the forward button in Firefox). When you click the down arrow, it could show a list of documents/origins, and when you hovered over an entry in the list, it could expand out and show all the entries associated with that document/origin. > Brady Eidson <beidson at apple.com> wrote: > Imagine the use case of the checkout procedure at an online merchant. [...] I think this is a pretty good example of where clearState actually helps. I'm not sure how general it is, though. A designer who wants to use clearState in this way is forced to begin the checkout wizard in a new Document. Maybe that's OK, but it seems like an arbitrary limitation to me. -Justin From jonas at sicking.cc Thu Nov 12 15:25:35 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 12 Nov 2009 15:25:35 -0800 Subject: [whatwg] AJAX History Concerns In-Reply-To: <0A6975D5-0DC2-4B28-80A4-3E63C21456E3@apple.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> <0A6975D5-0DC2-4B28-80A4-3E63C21456E3@apple.com> Message-ID: <63df84f0911121525x7ce7f271x1ab6bcb09db4a8bc@mail.gmail.com> >> That said, we didn't implement clearState when we did >> push/replaceState because it's hard to get right and we don't >> currently have a compelling use case. ?There are probably lots of >> things we'd change if we were going to implement it -- for instance, >> why go back to the last entry instead of staying at the current one? >> But that's probably a conversation for another thread. > > Since the spec is in last call for comments and we have yet to see a single implementation of this, I'd like to keep focusing on it till we have it worked out... ?;) My recommendation would be to take clearState out of the spec unless someone can come up with compelling use cases. It's really hard to ensure that the details of clearState works for the intended use cases if we don't know what those use cases are. Thus we can debate a very long time what the correct behavior is without actually having a way to verify the various opinions. / Jonas From gundersen at gmail.com Thu Nov 12 15:37:06 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Fri, 13 Nov 2009 10:37:06 +1100 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <5E05F7C3-6B49-46A1-94B3-0C0A09219117@apple.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <5E05F7C3-6B49-46A1-94B3-0C0A09219117@apple.com> Message-ID: <45f4181c0911121537x3c8a328fp365c7eb553af19f4@mail.gmail.com> On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson <beidson at apple.com> wrote: > I should've responded to this more directly: > > On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote: > > > I think the use case I proposed is much better served by something > > like history.truncate(numBefore, numAfter), which would remove all but > > the numBefore entries before the current entry and the numAfter > > entries after the current entry. We'd subject this to the same-origin > > policy, of course, and stop removing entries in a direction as soon as > > we encountered an entry from another origin. > > The History object is - quite purposefully - very limited in scope and > abilities. Today, it gives the ability to navigate back and forward a > number of steps. Period. > > The pushState() API adds a very limited way of adding new items > programatically. clearState() also adds the ability for a script to remove > entries, but only ones that it added. Period. > > Same-origin policy be damned, I really don't like the idea of a script > being able to remove items that it didn't add. > > As I said in my previous reply, I think it might be useful to give a more > fine-grained version of "clearState()", but that could always be added later > if there's demand. And I still think it should be limited to affecting the > string of the Document object's entries. > I don't think the history.truncate function proposed would be able to affect other Document object's entries. So for example, if the current history looks like this: A1 A2 B1 *B2* B3 B4 C1 C2 Then you can only call history.truncate(1, 2). If you call it with a higher number in either parameter, then you will get a same origin exception. If the numbers are smaller though, it would still work. For example, calling history.truncate(0,1) would leave the following in your history: A1 A2 B1 *B2* B4 C1 C2 I think this is the usecase clearState is designed for, but it's just not implemented in a very good way. This would not add a lot of extra work, and wouldn't complicate it for the user. truncate could also be called with no parameters, in which case it would clear the entire Document object's history, similarly to clearState. Marius Gundersen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091113/4984166f/attachment-0001.htm> From beidson at apple.com Thu Nov 12 15:41:16 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 15:41:16 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <45f4181c0911121537x3c8a328fp365c7eb553af19f4@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <5E05F7C3-6B49-46A1-94B3-0C0A09219117@apple.com> <45f4181c0911121537x3c8a328fp365c7eb553af19f4@mail.gmail.com> Message-ID: <9145FE00-C668-4008-9518-F7270F6933A8@apple.com> On Nov 12, 2009, at 3:37 PM, Marius Gundersen wrote: > > > On Fri, Nov 13, 2009 at 8:16 AM, Brady Eidson <beidson at apple.com> wrote: > I should've responded to this more directly: > > On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote: > > > I think the use case I proposed is much better served by something > > like history.truncate(numBefore, numAfter), which would remove all but > > the numBefore entries before the current entry and the numAfter > > entries after the current entry. We'd subject this to the same-origin > > policy, of course, and stop removing entries in a direction as soon as > > we encountered an entry from another origin. > > The History object is - quite purposefully - very limited in scope and abilities. Today, it gives the ability to navigate back and forward a number of steps. Period. > > The pushState() API adds a very limited way of adding new items programatically. clearState() also adds the ability for a script to remove entries, but only ones that it added. Period. > > Same-origin policy be damned, I really don't like the idea of a script being able to remove items that it didn't add. > > As I said in my previous reply, I think it might be useful to give a more fine-grained version of "clearState()", but that could always be added later if there's demand. And I still think it should be limited to affecting the string of the Document object's entries. > > I don't think the history.truncate function proposed would be able to affect other Document object's entries. So for example, if the current history looks like this: > > A1 A2 B1 *B2* B3 B4 C1 C2 > > Then you can only call history.truncate(1, 2). If you call it with a higher number in either parameter, then you will get a same origin exception. If the numbers are smaller though, it would still work. For example, calling history.truncate(0,1) would leave the following in your history: > > A1 A2 B1 *B2* B4 C1 C2 > > I think this is the usecase clearState is designed for, but it's just not implemented in a very good way. This would not add a lot of extra work, and wouldn't complicate it for the user. truncate could also be called with no parameters, in which case it would clear the entire Document object's history, similarly to clearState. You're confusing the "same origin" policy with this API's inherent "Document object" policy. Document objects A, B, and C could all be from the same origin. I'm asserting that even with that qualification, Document B should not be able to remove entries for Document A and Document C. ~Brady > Marius Gundersen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091112/ec7e4d1f/attachment.htm> From bruant at enseirb-matmeca.fr Thu Nov 12 16:24:45 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Thu, 12 Nov 2009 16:24:45 -0800 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFC7F8A.1050703@mit.edu> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> <4AFC4AB5.7020606@enseirb-matmeca.fr> <4AFC66A7.2010404@mit.edu> <4AFC72D1.9020904@enseirb-matmeca.fr> <4AFC7F8A.1050703@mit.edu> Message-ID: <4AFCA74D.80905@enseirb-matmeca.fr> Boris Zbarsky a ?crit : > On 11/12/09 3:40 PM, David Bruant wrote: >> I reformulate this way the conditions 2 and 3: >> - In "blank conditions" (no other processes/thread running on the CPU, >> enough memory to allocate the workers), running the same algorithm (an >> easy delegation algorithm) has significantly better performances with >> (navigator.optimalWorkerNumber) dedicated workers than with >> (navigator.optimalWorkerNumber -1) dedicated workers >> - In "blank conditions", running the same algorithm has no significantly >> better performances with (navigator.optimalWorkerNumber+1) dedicated >> workers than with (navigator.optimalWorkerNumber) dedicated workers > OK, but I'm not sure this is a useful number, then, since these "blank > conditions" never happen in practice. => I think it happens very often. While I'm writing this e-mail, "no process" is running. About fifty processes are runnable, but not running. They are passively waiting. My CPU is barely used. >> Just to remind, the purpose of this attribute is to decide, at the >> beginning of a delegation algorithm what is the "optimal" number of >> workers to divide the work in a way that is optimal regarding the >> hardware, the OS and the worker implementation. > > I'm glad you put "optimal" in quotes.... ;) => I'm fully aware that for a such high-level specification, talking about optimality (and even performance !) is very relative. > > Is there a reason that apps that really care about this shouldn't just > measure to see what number works best for them? => I agree on the fact that this is the key question to decide if my proposal must be taken into account or not. My point is that this number may be available very easily. For example, in my dual-core, Linux, Firefox 3.5, the number is 2. Why spare an information that can be useful and reliable (more than measurement at least !) ? I also agree on the fact that this attribute is not the most important attribute in the world, but as the colorDepth attribute of the screen object (http://www.w3.org/TR/cssom-view/#dom-screen-colordepth), it will be useful to some people in some usecase. >> The idea behind this property is that even if you start running the >> algorithm with a lot of concurrent processes, you create a number of >> workers that cannot be ran concurrently at the beginning, but you may >> use optimally the ressources later > > But in the meantime you will be using them very suboptimally, no? => Yes and no. No one can know if they will be optimally used or not. What you are "garanteed" (quotes again) is that in "blank conditions", they will be optimally used (which is more or less the definition of this number). >> (if the other processes/threads stop >> running, what you cannot control, but can still hope that it happens >> during the "algorithm lifetime". According to the spec, "workers are >> expected to be long-lived"). > > Most of my apps are long-lived... > > -Boris From bzbarsky at MIT.EDU Thu Nov 12 16:35:39 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 19:35:39 -0500 Subject: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case In-Reply-To: <4AFCA74D.80905@enseirb-matmeca.fr> References: <4AFB7EB5.7010001@enseirb-matmeca.fr> <4AFB81E0.7000100@mit.edu> <4AFC4AB5.7020606@enseirb-matmeca.fr> <4AFC66A7.2010404@mit.edu> <4AFC72D1.9020904@enseirb-matmeca.fr> <4AFC7F8A.1050703@mit.edu> <4AFCA74D.80905@enseirb-matmeca.fr> Message-ID: <4AFCA9DB.5000103@mit.edu> On 11/12/09 7:24 PM, David Bruant wrote: > => I think it happens very often. While I'm writing this e-mail, "no > process" is running. About fifty processes are runnable, but not > running. They are passively waiting. My CPU is barely used. Interesting. I have several browser processes using timeslices right now (the incessant XHR google apps tend to do, I think), plus at least two other things running that are fully using up one core and most of another, as I write this mail. I don't see how a browser could return a single number that would "work" or both of us. > My point is that this number may be available very easily. For example, > in my dual-core, Linux, Firefox 3.5, the number is 2. OK, what about in Firefox 3.6? If your worker plans to not allocate many strings and the like, it's 2. Otherwise, it's 1 (because a good bit of gc finalization has been moved to a separate thread). > Why spare an information that can be useful and reliable (more than measurement at > least !) ? Because the information is _not_ reliable. The optimal number of concurrent threads of execution given a given fixed set of computation resources is heavily dependent on the behavior of the threads of execution and what else is using the computation resources... Put another way, as a UA implementor I don't know what I'd make this attribute return without it being a bald-faced lie in pretty simple cases. > => Yes and no. No one can know if they will be optimally used or not. > What you are "garanteed" (quotes again) is that in "blank conditions", > they will be optimally used (which is more or less the definition of > this number). See above; even in "blank conditions" this may well depend on the exact workload of your workers. -Boris From jonas at sicking.cc Thu Nov 12 16:39:24 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 12 Nov 2009 16:39:24 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> Message-ID: <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beidson at apple.com> wrote: > I think clearState() is a good idea but is just spec'ed poorly. > > Imagine the use case of the checkout procedure at an online merchant. > > There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order." ?It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information. > > But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant. ?The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order. ?In this case, clearState() fits the bill greatly! > > It is true that what is really being performed is "truncate this part of history." ?But we wouldn't to give scripts the ability to control parts of session history they don't own. ?And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries. > > One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others. ?I might be able to think of a use-case for that, but I don't see it being tremendously important. ?It could always be added later if there's demand for it. > > I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable. As a user of a site, I'm not really sure that that's what I would like to have happen. I can see wanting to be able to go back to those pages to for example see what information I filled out. In general I'm always annoyed as a user when I can't go back to pages that I've left (it's why I pushed the back-button in the first place). And in any event I don't think clearState provides enough fine grained control to be able to satisfy this use case. I would imagine that in many cases a call to clearState would nuke not just the checkout-wizard, but likely also navigation the happened before that. In order to satisfy this use case I'd imagine you'd need the ability to remove a precise range of session history entries. And be able to do so in a way that doesn't get messed up if the user created additional session history entries by clicking links such as <a href="#sizeinfo">Check size information here before buying</a>. / Jonas From beidson at apple.com Thu Nov 12 16:54:40 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 16:54:40 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> Message-ID: <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> On Nov 12, 2009, at 4:39 PM, Jonas Sicking wrote: > On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beidson at apple.com> wrote: >> I think clearState() is a good idea but is just spec'ed poorly. >> >> Imagine the use case of the checkout procedure at an online merchant. >> >> There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order." It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information. >> >> But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant. The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order. In this case, clearState() fits the bill greatly! >> >> It is true that what is really being performed is "truncate this part of history." But we wouldn't to give scripts the ability to control parts of session history they don't own. And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries. >> >> One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others. I might be able to think of a use-case for that, but I don't see it being tremendously important. It could always be added later if there's demand for it. >> >> I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable. > > As a user of a site, I'm not really sure that that's what I would like > to have happen. I can see wanting to be able to go back to those pages > to for example see what information I filled out. In general I'm > always annoyed as a user when I can't go back to pages that I've left > (it's why I pushed the back-button in the first place). An AJAX heavy site already violates your user preconceptions about back/forward. One of the whole points of this API is to allow such AJAX heavy sites to play *better* with back/forward. > > And in any event I don't think clearState provides enough fine grained > control to be able to satisfy this use case. I would imagine that in > many cases a call to clearState would nuke not just the > checkout-wizard, but likely also navigation the happened before that. Remember this API extends the lifetime of a single Document object. If the checkout-wizard is its own document, then its invocation of "clearState()" could not nuke any more history than it owned. > In order to satisfy this use case I'd imagine you'd need the ability > to remove a precise range of session history entries. I disagree, see above. > And be able to do so in a way that doesn't get messed up if the user created > additional session history entries by clicking links such as <a > href="#sizeinfo">Check size information here before buying</a>. This already plays well with the "A Document object is the only thing that gets to manage its own state entries" model. If you clicked this link sometime during the middle of your checkout process, then completed the checkout and clearState() was called, your fragment entry would be removed along with the others for the document. I know you're arguing "as a user, I don't want my back history messed with." But the whole point of this API is to give scripts the ability to mess with a very limited, very controlled subset of the back/forward history. Having that as a goal but then neutering the scripts ability to take advantage seem somewhat contrary here. ~Brady > > / Jonas From beidson at apple.com Thu Nov 12 17:05:10 2009 From: beidson at apple.com (Brady Eidson) Date: Thu, 12 Nov 2009 17:05:10 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> Message-ID: <32271903-C0F3-46DF-BB60-B9D7C9A7C67C@apple.com> Sorry to self-reply. I just want to make four targetted points: -As is, the language specifying clearState() has gapping holes that prevent us from agreeing on what it is we're implementing. -I personally think the intention of clearState() is useful and not a bad idea, and that a more fine grained "truncate" is something that can easily be added later with enough demand. -I personally think expanding the API to allow a script to remove history entries its Document object didn't create is a bad idea, and would object to expanding this power beyond the Document object to "same origin" based control. -I think that if we can't reach a consensus fairly soon, we should dump clearState() and revisit it later. The API is certainly very useful with just pushState() and replaceState(). ~Brady On Nov 12, 2009, at 4:54 PM, Brady Eidson wrote: > > On Nov 12, 2009, at 4:39 PM, Jonas Sicking wrote: > >> On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beidson at apple.com> wrote: >>> I think clearState() is a good idea but is just spec'ed poorly. >>> >>> Imagine the use case of the checkout procedure at an online merchant. >>> >>> There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order." It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information. >>> >>> But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant. The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order. In this case, clearState() fits the bill greatly! >>> >>> It is true that what is really being performed is "truncate this part of history." But we wouldn't to give scripts the ability to control parts of session history they don't own. And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries. >>> >>> One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others. I might be able to think of a use-case for that, but I don't see it being tremendously important. It could always be added later if there's demand for it. >>> >>> I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable. >> >> As a user of a site, I'm not really sure that that's what I would like >> to have happen. I can see wanting to be able to go back to those pages >> to for example see what information I filled out. In general I'm >> always annoyed as a user when I can't go back to pages that I've left >> (it's why I pushed the back-button in the first place). > > An AJAX heavy site already violates your user preconceptions about back/forward. One of the whole points of this API is to allow such AJAX heavy sites to play *better* with back/forward. >> >> And in any event I don't think clearState provides enough fine grained >> control to be able to satisfy this use case. I would imagine that in >> many cases a call to clearState would nuke not just the >> checkout-wizard, but likely also navigation the happened before that. > > Remember this API extends the lifetime of a single Document object. If the checkout-wizard is its own document, then its invocation of "clearState()" could not nuke any more history than it owned. > >> In order to satisfy this use case I'd imagine you'd need the ability >> to remove a precise range of session history entries. > > I disagree, see above. > >> And be able to do so in a way that doesn't get messed up if the user created >> additional session history entries by clicking links such as <a >> href="#sizeinfo">Check size information here before buying</a>. > > This already plays well with the "A Document object is the only thing that gets to manage its own state entries" model. If you clicked this link sometime during the middle of your checkout process, then completed the checkout and clearState() was called, your fragment entry would be removed along with the others for the document. > > I know you're arguing "as a user, I don't want my back history messed with." But the whole point of this API is to give scripts the ability to mess with a very limited, very controlled subset of the back/forward history. Having that as a goal but then neutering the scripts ability to take advantage seem somewhat contrary here. > > ~Brady >> >> / Jonas > From ian at hixie.ch Thu Nov 12 17:43:33 2009 From: ian at hixie.ch (Ian Hickson) Date: Fri, 13 Nov 2009 01:43:33 +0000 (UTC) Subject: [whatwg] AJAX History Concerns In-Reply-To: <63df84f0911121525x7ce7f271x1ab6bcb09db4a8bc@mail.gmail.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> <0A6975D5-0DC2-4B28-80A4-3E63C21456E3@apple.com> <63df84f0911121525x7ce7f271x1ab6bcb09db4a8bc@mail.gmail.com> Message-ID: <Pine.LNX.4.62.0911130110450.27661@hixie.dreamhostps.com> On Wed, 11 Nov 2009, Brady Eidson wrote: > > When pushState() or replaceState() are called with a URL argument, the > document's current address is changed. This has a lot of side effects > in that it is exposed to scripts and the DOM and most modern user agents > would update their UI to show this. > > However, this same section takes care to point out "The title is purely > advisory. User agents might use the title in the user interface." > Indeed, many user agents would show the title of the current page at the > top of the browser window or tab, in their back/forward list, and > possibly in their global persistent history. > > But unlike the URL which actually changes in the Document object and is > therefore exposed to the DOM, this "purely advisory" title change is > hidden from the DOM. I'm questioning the reasoning behind this > distinction and am curious if it was intentional or not. The idea is that the string you would put into the back button or history menu is not the same as the string you would put into the title bar or bookmarks (i.e. not the same as <title>). > The following text describes clearState(): > > "When this method is invoked, the user agent must remove from the > session history all the entries from the first state object entry for > that Document object up to the last entry that references that same > Document object, if any. > > Then, if the current entry was removed in the previous step, the current > entry must be set to the last entry for that Document object in the > session history." > > Imagine the following scenario: > > A document has 5 state entries. > > They each have a different URL as follows: > http://www.example.com/page.html?1, http://www.example.com/page.html?2, > http://www.example.com/page.html?3, http://www.example.com/page.html?4, > and http://www.example.com/page.html?5 > > The current entry is the 3rd entry. > > A script calls "clearState()" so these entries are all cleared out, > including the current entry. > > Since the current entry was removed, the current entry after the > clearState() call is changed to be the last entry for the Document. > > My reading of the spec is that after clearState() returns, the entries > 1-4 will be gone completely, the state object for entry 5 will have been > cleared, and entry 5 will now be the current entry. > > This has the side effect of the URL for the current entry - > http://www.example.com/page.html?5 - not matching the current URL of the > document - http://www.example.com/page.html?3 > > Is my understanding of what the current entry should be correct? > If not, what am I missing? > And is the disjoint between the Document's URL and the current entries URL correct? > If not, what am I missing? clearState() was not properly fixed when we changed pushState() and replaceState(). I've removed it altogether for now. On Thu, 12 Nov 2009, Brady Eidson wrote: > > document.title = "Old title"; > replaceState("state object", "New title", "http://example.com/index.html?2"); > alert(document.title); > > What does the alert show? "Old title". document.title is often used to include things like unread count in a mail client or RSS reader. That's orthogonal from the state you would want to show in the back button ("Inbox", "Spam folder", "Settings", or whatever). On Thu, 12 Nov 2009, Justin Lebar wrote: > > What I did in my Firefox patch (which should be checked into trunk > within a few weeks, I hope) is use that title only to identify the > history entry in the pull-down back-forward menu (what's shown when you > click the down arrow next to the forward button in Firefox). > > If you want the rest of the UI (e.g. browser title bar) to match up with > this title, you have to set document.title. ?In fact, if you pushState > with title 'Foo', then navigate back and then forward, the history > entry's title will be reset to the document's title. ?(I intend to write > something detailing tricks like these once we land the pushState patch.) That seems like a bug. On Thu, 12 Nov 2009, Brady Eidson wrote: > > After more thought and more input from others, this is what my current > thoughts have boiled down to - Is there a compelling reason why the > title parameter is here and that we can't just rely on the document's > title as it existed at the time that pushState() or replaceState() was > called? A use case someone can think of that isn't possible otherwise? Is the use case above -- where the current title and the title you'd want in the history don't match -- provide an adequate use case? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Thu Nov 12 18:03:02 2009 From: jonas at sicking.cc (Jonas Sicking) Date: Thu, 12 Nov 2009 18:03:02 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> Message-ID: <63df84f0911121803t4a347b7du8f8d387aff12b5b7@mail.gmail.com> On Thu, Nov 12, 2009 at 4:54 PM, Brady Eidson <beidson at apple.com> wrote: > > On Nov 12, 2009, at 4:39 PM, Jonas Sicking wrote: > >> On Thu, Nov 12, 2009 at 1:08 PM, Brady Eidson <beidson at apple.com> wrote: >>> I think clearState() is a good idea but is just spec'ed poorly. >>> >>> Imagine the use case of the checkout procedure at an online merchant. >>> >>> There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order." ?It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information. >>> >>> But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant. ?The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order. ?In this case, clearState() fits the bill greatly! >>> >>> It is true that what is really being performed is "truncate this part of history." ?But we wouldn't to give scripts the ability to control parts of session history they don't own. ?And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries. >>> >>> One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others. ?I might be able to think of a use-case for that, but I don't see it being tremendously important. ?It could always be added later if there's demand for it. >>> >>> I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable. >> >> As a user of a site, I'm not really sure that that's what I would like >> to have happen. I can see wanting to be able to go back to those pages >> to for example see what information I filled out. In general I'm >> always annoyed as a user when I can't go back to pages that I've left >> (it's why I pushed the back-button in the first place). > > An AJAX heavy site already violates your user preconceptions about back/forward. ?One of the whole points of this API is to allow such AJAX heavy sites to play *better* with back/forward. The fact that AJAX already breaks how I as a user would like pages to behave doesn't mean that we should build APIs to allow them to keep doing so. Like you say, the intent of this API is to make AJAX work better. >> And in any event I don't think clearState provides enough fine grained >> control to be able to satisfy this use case. I would imagine that in >> many cases a call to clearState would nuke not just the >> checkout-wizard, but likely also navigation the happened before that. > > Remember this API extends the lifetime of a single Document object. ?If the checkout-wizard is its own document, then its invocation of "clearState()" could not nuke any more history than it owned. But it means that you have to load a new Document object for the checkout part of your site. I.e. you can't extend the lifetime of the product page to cover the checkout page as well. > I know you're arguing "as a user, I don't want my back history messed with." ?But the whole point of this API is to give scripts the ability to mess with a very limited, very controlled subset of the back/forward history. I disagree. The goal of this API isn't to allow pages to "mess" with my history. I think the goal of this API is to allow AJAX pages to integrate better with the web platform and behave more like normal pages. I.e. things like bookmarks will work like normal pages, AJAX pages get the correct referrer (something that is a big deal in many cases), work like normal pages with the back button, etc. / Jonas From bruant at enseirb-matmeca.fr Thu Nov 12 18:21:20 2009 From: bruant at enseirb-matmeca.fr (David Bruant) Date: Thu, 12 Nov 2009 18:21:20 -0800 Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers Message-ID: <4AFCC2A0.1030202@enseirb-matmeca.fr> Hi, I was waiting for Firefox to stop freezing on the HTML5 spec page (it freezes about one minute each time I visit the one-page version) and I tried to think of a way to "design" this page in a way that wouldn't freeze my browser. One good way I have found would be to cut the whole page into several parts (one the server side, what is already done in the multi-page version) and to launch several workers. Each worker gets one part of the whole page in the background and could give it to the browsing context which will append the right part at the right place. But what is this "give" ? Without the DOM API, this "give" means "sending a string through the postMessage() method" and the "append" means "rightPlace.innerHTML = stringContainingAPartOfThePage". However, with the DOM API, each worker could build independantly its documentFragment, send it to the browsing context which will "append" (appendChild) it in the right place. Building the page requires 3 main operations : - getting the content (can be parallelized with the workers which can make XMLHttpRequests) - building a DOM tree from the content - rendering (cannot be parallelized because must occur in the browsing context) Without the DOM API, the second step cannot be parallelized in the WebWorkers. I understand that the whole DOM API is not useful for the WebWorkers, but, could a reduced API (sufficient to describe the tree structure of a document) be available to the web workers to have a chance to parallelize the tree structuration of the content (and then reduce its cost) ? Thanks, David From bzbarsky at MIT.EDU Thu Nov 12 18:46:12 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 21:46:12 -0500 Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers In-Reply-To: <4AFCC2A0.1030202@enseirb-matmeca.fr> References: <4AFCC2A0.1030202@enseirb-matmeca.fr> Message-ID: <4AFCC874.1090209@mit.edu> On 11/12/09 9:21 PM, David Bruant wrote: > I was waiting for Firefox to stop freezing on the HTML5 spec page (it > freezes about one minute each time I visit the one-page version) and I > tried to think of a way to "design" this page in a way that wouldn't > freeze my browser. Two easy ways to do this: 1) Take out the script at the end of the page that goes and messes with the DOM. 2) Fix the O(N^2) algorithm in the web browser that this script happens to trigger (<https://bugzilla.mozilla.org/show_bug.cgi?id=526394>; should be checked in pretty soon unless something goes drastically wrong). > One good way I have found would be to cut the whole page into several > parts (one the server side, what is already done in the multi-page > version) and to launch several workers. Each worker gets one part of the > whole page in the background and could give it to the browsing context > which will append the right part at the right place. I'm not sure what you mean, exactly... what would the worker "give", exactly? > But what is this "give" ? Without the DOM API, this "give" means > "sending a string through the postMessage() method" and the "append" > means "rightPlace.innerHTML = stringContainingAPartOfThePage". > However, with the DOM API, each worker could build independantly its > documentFragment, send it to the browsing context which will "append" > (appendChild) it in the right place. The problem here is that of a script making certain DOM mutations after the DOM is completely built and reflecting those mutations into the rendering tree, not of initial DOM construction. That is, even if this proposal were implemented it would not eliminate the hang you're seeing without item 2 above being addressed. > Building the page requires 3 main operations : > - getting the content (can be parallelized with the workers which can > make XMLHttpRequests) > - building a DOM tree from the content > - rendering (cannot be parallelized because must occur in the browsing > context) And in this case the slowness you seem to be trying to address is in the "rendering" part. -Boris From gundersen at gmail.com Thu Nov 12 19:43:42 2009 From: gundersen at gmail.com (Marius Gundersen) Date: Fri, 13 Nov 2009 14:43:42 +1100 Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers In-Reply-To: <4AFCC874.1090209@mit.edu> References: <4AFCC2A0.1030202@enseirb-matmeca.fr> <4AFCC874.1090209@mit.edu> Message-ID: <45f4181c0911121943p1e5c0634te274c5c16335935c@mail.gmail.com> On Fri, Nov 13, 2009 at 1:46 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote: > On 11/12/09 9:21 PM, David Bruant wrote: > >> I was waiting for Firefox to stop freezing on the HTML5 spec page (it >> freezes about one minute each time I visit the one-page version) and I >> tried to think of a way to "design" this page in a way that wouldn't >> freeze my browser. >> > > Two easy ways to do this: > > 1) Take out the script at the end of the page that goes and messes > with the DOM. > 2) Fix the O(N^2) algorithm in the web browser that this script > happens to trigger > (<https://bugzilla.mozilla.org/show_bug.cgi?id=526394>; should be > checked in pretty soon unless something goes drastically wrong). > > > One good way I have found would be to cut the whole page into several >> parts (one the server side, what is already done in the multi-page >> version) and to launch several workers. Each worker gets one part of the >> whole page in the background and could give it to the browsing context >> which will append the right part at the right place. >> > > I'm not sure what you mean, exactly... what would the worker "give", > exactly? > > > But what is this "give" ? Without the DOM API, this "give" means >> "sending a string through the postMessage() method" and the "append" >> means "rightPlace.innerHTML = stringContainingAPartOfThePage". >> However, with the DOM API, each worker could build independantly its >> documentFragment, send it to the browsing context which will "append" >> (appendChild) it in the right place. >> > > The problem here is that of a script making certain DOM mutations after the > DOM is completely built and reflecting those mutations into the rendering > tree, not of initial DOM construction. > > That is, even if this proposal were implemented it would not eliminate the > hang you're seeing without item 2 above being addressed. > > > Building the page requires 3 main operations : >> - getting the content (can be parallelized with the workers which can >> make XMLHttpRequests) >> - building a DOM tree from the content >> - rendering (cannot be parallelized because must occur in the browsing >> context) >> > > And in this case the slowness you seem to be trying to address is in the > "rendering" part. > > -Boris > The reason WebWorkers don't have access to the DOM is concurrency. For example, to loop through a list of children I need to first read the number of childrens, then have a for loop which starts at 0 and ends at length-1. If you have two threads that can access the DOM concurrently, then one could change the number of children while the other was looping through the list, which would cause bugs in the program. The only way to fix this is to make the DOM a monitor or introduce semaphores, but then you would have to change the way the DOM is accessed in HTML5, breaking backwards compatibility, which is not a good idea. A better solution to your problem is to load fragments of the entire document using AJAX and then insert those fragments into the main document, when they are needed. You rarely need to see the entire document at once anyways. Marius Gundersen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091113/69306a4e/attachment-0001.htm> From bzbarsky at MIT.EDU Thu Nov 12 19:48:15 2009 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Thu, 12 Nov 2009 22:48:15 -0500 Subject: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers In-Reply-To: <45f4181c0911121943p1e5c0634te274c5c16335935c@mail.gmail.com> References: <4AFCC2A0.1030202@enseirb-matmeca.fr> <4AFCC874.1090209@mit.edu> <45f4181c0911121943p1e5c0634te274c5c16335935c@mail.gmail.com> Message-ID: <4AFCD6FF.6030007@mit.edu> On 11/12/09 10:43 PM, Marius Gundersen wrote: > A better solution to your problem is to load fragments of the entire > document using AJAX and then insert those fragments into the main > document, when they are needed. This may well be slower than just loading the document and being done with it. In fact, the slow part of the html5 spec single-page load is precisely the operation you describe: dom fragments being loaded via ajax and sprinkled about. It's slow in all browsers (e.g. in Safari this operation takes about 2x as long as the pageload itself). > You rarely need to see the entire document at once anyways. Until you try to do a "find in page"; something that needs to be done with depressing regularity for specs. -Boris From justin.lebar at gmail.com Fri Nov 13 00:22:05 2009 From: justin.lebar at gmail.com (Justin Lebar) Date: Fri, 13 Nov 2009 00:22:05 -0800 Subject: [whatwg] AJAX History Concerns In-Reply-To: <Pine.LNX.4.62.0911130110450.27661@hixie.dreamhostps.com> References: <EB911329-E0CD-4F0D-8603-4B4D3B976995@apple.com> <c84706c70911111931i25156866of6b376f674027b8a@mail.gmail.com> <c84706c70911121122r522cf38dk8dc3cfee595d8199@mail.gmail.com> <0A6975D5-0DC2-4B28-80A4-3E63C21456E3@apple.com> <63df84f0911121525x7ce7f271x1ab6bcb09db4a8bc@mail.gmail.com> <Pine.LNX.4.62.0911130110450.27661@hixie.dreamhostps.com> Message-ID: <c84706c70911130022j227764e8m7e9ae6a26a074d9e@mail.gmail.com> On Thu, Nov 12, 2009 at 5:43 PM, Ian Hickson <ian at hixie.ch> wrote: > The idea is that the string you would put into the back button or history > menu is not the same as the string you would put into the title bar or > bookmarks (i.e. not the same as <title>). That doesn't seem too unreasonable, but I think it's strange to set that title through push/replaceState, since an alternate page title is orthogonal to the idea of an AJAX page with state objects. It might be confusing to expose this alternate title in the document object, but perhaps we could expose it as a property or setter function somewhere else. Then we could persist it properly across forward / backs within the same document. > document.title is often used to include things like unread count in a mail > client or RSS reader. That's orthogonal from the state you would want to > show in the back button ("Inbox", "Spam folder", "Settings", or whatever). In this case, it seems like we'd want the bookmark title to use the pushState title, not document.title (e.g. the bookmark would read "Inbox", not "Inbox (8)"). -Justin From philipj at opera.com Fri Nov 13 10:27:39 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Fri, 13 Nov 2009 19:27:39 +0100 Subject: [whatwg] Microdata DOM API issues In-Reply-To: <op.u29flv14sr6mfa@worf> References: <op.u29flv14sr6mfa@worf> Message-ID: <op.u3civ6mwsr6mfa@worf> On Thu, 12 Nov 2009 03:23:54 +0100, Philip J?genstedt <philipj at opera.com> wrote: > Why are the algorithms for extracting RDF gone? All that's left is the > book example with the equivalent Turtle, but it would be nice if it were > actually defined how to extract RDF. The same for the JSON stuff, was > that no good? D'oh! I've been reading the multipage version and missed that it's on another page: http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html I'll have to try implementing that and see if there are any more issues. -- Philip J?genstedt Opera Software From philipj at opera.com Fri Nov 13 15:14:37 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Sat, 14 Nov 2009 00:14:37 +0100 Subject: [whatwg] Microdata DOM API issues In-Reply-To: <op.u3civ6mwsr6mfa@worf> References: <op.u29flv14sr6mfa@worf> <op.u3civ6mwsr6mfa@worf> Message-ID: <op.u3cv6nfjsr6mfa@worf> On Fri, 13 Nov 2009 19:27:39 +0100, Philip J?genstedt <philipj at opera.com> wrote: > On Thu, 12 Nov 2009 03:23:54 +0100, Philip J?genstedt > <philipj at opera.com> wrote: > >> Why are the algorithms for extracting RDF gone? All that's left is the >> book example with the equivalent Turtle, but it would be nice if it >> were actually defined how to extract RDF. The same for the JSON stuff, >> was that no good? > > D'oh! I've been reading the multipage version and missed that it's on > another page: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html > > I'll have to try implementing that and see if there are any more issues. > http://www.whatwg.org/specs/web-apps/current-work/multipage/converting-html-to-other-formats.html#json This was easy to implement, but the algorithm isn't guaranteed to terminate. <div itemscope> <div itemprop="foo" itemscope itemref="oops" id="oops"></div> </div> This simple input causes the algorithm to recurse as the item references itself. I went back to the vCard algorithm and found that it too will fail to terminate with this input: <span itemscope itemtype="http://microformats.org/profile/hcard"> <span itemprop="agent" itemscope id="oops" itemref="oops" itemtype="http://microformats.org/profile/hcard"> </span> vEvent is safe as the algorithm never recurses, but the RDF conversion algorithm would hit the same problem. It's certainly possible to create loops which are less easy to spot: <div itemscope> <div itemprop="prop1" itemscope itemref="id2" id="id1"></div> <div itemprop="prop2" itemscope itemref="id3" id="id2"></div> ... <div itemprop="propn" itemscope itemref="id1" id="idn"></div> </div> Or this: <div itemscope> <div itemprop="foo" itemscope id="a"> <div itemprop="bar" itemscope itemref="a"></div> </div> </div> The itemref mechanism allows creating arbitrary graphs of items, rather than the tree of items that is the intended microdata model (right?). Even though my default reaction to graphs is "oh cool", for microdata when the domain model is a graph you should probably just represent it with a level of indirection (RDF). Options: 1. patch the algorithms which can go into recursion 2. patch <http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items> to first check if an itemref'd property creates a loop before adding it to candidates 3. ? I think I prefer 2. -- Philip J?genstedt From jackalmage at gmail.com Fri Nov 13 15:34:12 2009 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 13 Nov 2009 17:34:12 -0600 Subject: [whatwg] Microdata DOM API issues In-Reply-To: <op.u3cv6nfjsr6mfa@worf> References: <op.u29flv14sr6mfa@worf> <op.u3civ6mwsr6mfa@worf> <op.u3cv6nfjsr6mfa@worf> Message-ID: <dd0fbad0911131534u16765334k775b08b42ecaa050@mail.gmail.com> On Fri, Nov 13, 2009 at 5:14 PM, Philip J?genstedt <philipj at opera.com> wrote: > The itemref mechanism allows creating arbitrary graphs of items, rather than > the tree of items that is the intended microdata model (right?). Even though > my default reaction to graphs is "oh cool", for microdata when the domain > model is a graph you should probably just represent it with a level of > indirection (RDF). > > Options: > 1. patch the algorithms which can go into recursion > 2. patch > <http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items> > to first check if an itemref'd property creates a loop before adding it to > candidates > 3. ? > > I think I prefer 2. Looping in data-graphs is often useful, so I'm not sure I want to throw it out generally. Your statement in the first paragraph I'm quoting, though, says that you'd rather leave loops to be defined in the vocabulary itself? So loops would be done by, frex, itemprop'ing a link to the other element rather than itemref'ing the other element directly? That would probably be fine, and is compatible with a tree-based data model like JSON. Vocabs should know when loops are permissible/desirable for themselves. ~TJ From philipj at opera.com Sat Nov 14 01:32:58 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Sat, 14 Nov 2009 10:32:58 +0100 Subject: [whatwg] Microdata DOM API issues In-Reply-To: <dd0fbad0911131534u16765334k775b08b42ecaa050@mail.gmail.com> References: <op.u29flv14sr6mfa@worf> <op.u3civ6mwsr6mfa@worf> <op.u3cv6nfjsr6mfa@worf> <dd0fbad0911131534u16765334k775b08b42ecaa050@mail.gmail.com> Message-ID: <op.u3dos8qgsr6mfa@worf> On Sat, 14 Nov 2009 00:34:12 +0100, Tab Atkins Jr. <jackalmage at gmail.com> wrote: > On Fri, Nov 13, 2009 at 5:14 PM, Philip J?genstedt <philipj at opera.com> > wrote: >> The itemref mechanism allows creating arbitrary graphs of items, rather >> than >> the tree of items that is the intended microdata model (right?). Even >> though >> my default reaction to graphs is "oh cool", for microdata when the >> domain >> model is a graph you should probably just represent it with a level of >> indirection (RDF). >> >> Options: >> 1. patch the algorithms which can go into recursion >> 2. patch >> <http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#associating-names-with-items> >> to first check if an itemref'd property creates a loop before adding it >> to >> candidates >> 3. ? >> >> I think I prefer 2. > > Looping in data-graphs is often useful, so I'm not sure I want to > throw it out generally. Your statement in the first paragraph I'm > quoting, though, says that you'd rather leave loops to be defined in > the vocabulary itself? So loops would be done by, frex, itemprop'ing > a link to the other element rather than itemref'ing the other element > directly? Yes, that's basically what I'm saying. One option is to simply use microdata such that the RDF you extract is the graph you want (it will probably look quite ugly though). Another is always referencing subitems by a mechanism other than refid. For example, in the MusicBrainz XML webservice when an artist contains a release which itself references artists (e.g. as the producer), a stub item is used with only artist name and id, rather than including all information recursively. In microdata I would do: <section itemscope itemtype="http://musicbrainz.org/artist/" itemid="http://musicbrainz.org/artist/4d5447d7-c61c-4120-ba1b-d7f471d385b9"> <h1 itemprop="name">John Lennon</h1> <section> <h1>Releases</h1> <section itemprop="release" itemscope itemtype="http://musicbrainz.org/release/" itemid="http://musicbrainz.org/release/f237e6a0-4b0e-4722-8172-66f4930198bc"> <h1>Imagine</h1> Producer: <span itemprop="producer" itemscope itemtype="http://musicbrainz.org/artist/" itemid="http://musicbrainz.org/artist/e7b587f7-e678-47c1-81dd-e7bb7855b0f9" ><span itemprop="name">Phil Spector</span></span> </section> </section> </section> Even if John Lennon were the producer here, you don't get any looping in the microdata itself. If you want to know everything about the producer, you should just follow the itemid... I haven't looked that much at the RDF extraction algorithm yet, but I think this example might even create the proper graph with loops if the producer were John Lennon. > That would probably be fine, and is compatible with a tree-based data > model like JSON. Vocabs should know when loops are > permissible/desirable for themselves. I agree, I don't see that we have a problem here. -- Philip J?genstedt Opera Software From timeless at gmail.com Sat Nov 14 14:28:17 2009 From: timeless at gmail.com (timeless) Date: Sun, 15 Nov 2009 00:28:17 +0200 Subject: [whatwg] rp is a styling tag and has no semantic function In-Reply-To: <4AEC110E.5040601@ni-po.com> References: <20091030201216.9640.C8DE7135@html5.jp> <4AEAF16A.3020704@ni-po.com> <20091031014537.D90B.C8DE7135@html5.jp> <4AEC110E.5040601@ni-po.com> Message-ID: <26b395e60911141428v5f69eee1s2716b0bbc5213cfd@mail.gmail.com> Nikita Popov <privat at ni-po.com>: > Screen-readers are yet another problem: I'm not sure, what's better: > "ka-n-ka-n-ji-ji" or > "ka-n-bracketopen-ka-n-bracketclose-ji-bracketopen-ji-bracketclose". I > think the first one is even better, because the text is only duplicated > and the reader mustn't read the brackets, too. (This is for > screen-readers not supporting ruby. The ones that support it can then > handle it by only reading out the rt, as you proposed. [Though you need > to consider the problem above.]) I don't use screen readers often, but I'd like to note that '(' is a parenthesis not a bracket. so it should be 'open parenthesis' and 'closed parenthesis' respectively. http://en.wikipedia.org/wiki/Bracket#Parentheses_.28_.29 screen readers should have a way of handling parentheticals which doesn't involve reading them as individual characters. I believe you're imaging problems that don't exist and therefore potentially creating problems that aren't necessary.... From timeless at gmail.com Sat Nov 14 16:07:51 2009 From: timeless at gmail.com (timeless) Date: Sun, 15 Nov 2009 02:07:51 +0200 Subject: [whatwg] validationMessage In-Reply-To: <9450c5340911101437l26be3d09m72dbe8230b5cb87d@mail.gmail.com> References: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> <9450c5340911101437l26be3d09m72dbe8230b5cb87d@mail.gmail.com> Message-ID: <26b395e60911141607m14132d46k4c5b12fa3620e46c@mail.gmail.com> So... trying to do anything like this is a disaster. But it sounds like the API is *trying* to handle the problem described below. I'm not sure it does (and suspect in fact that it doesn't). === implementation experience: GMail with a composed but unsent message will toss up a dialog if you try to leave the page. In the MicroB browser on the N900 we provide localized Yes/No buttons instead of OK/Cancel buttons (because our UI specifiers don't use browser user and don't care about GMail). As a result we get lots of bugs complaining about this behavior. https://bugs.maemo.org/show_bug.cgi?id=5130 there are probably 20 or so internal bugs for this issue. I'm pretty sure that makes it one of our highest reported bugs. In short, there's no way to get any of this right. Google apparently does expect localized buttons <https://bugs.maemo.org/show_bug.cgi?id=5704> but in some cases the buttons they expect are not the labels they want. We've had reports where the gmail instructions mention OK/Cancel and the user had localized (Yes/No) buttons . === The problem is that there's basically no way to properly frame such a thing. If the user agent is using Portuguese but the Browser Content is using English, then you're going to have to have something where there's a language mix in the content area. Any transition here will be rough. Trying to assume how the string is formatted or trying to guess which strings describe the given buttons/actions by doing parsing is going to fail. OTOH, a User Agent could e.g. stick an error case into an information banner (typically the thing at the top of the page which is not part of the content area). From shadow2531 at gmail.com Sat Nov 14 17:20:32 2009 From: shadow2531 at gmail.com (Michael A. Puls II) Date: Sat, 14 Nov 2009 20:20:32 -0500 Subject: [whatwg] Canvas.cloneNode() In-Reply-To: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com> References: <fdd21a0e0910300903y23bcbfe2u7efa11796e81767a@mail.gmail.com> Message-ID: <op.u3ewoee01ejg13@sandra-svwliu01> On Fri, 30 Oct 2009 12:03:46 -0400, OmegaJunior <omegajunior at omegajunior.net> wrote: > Greetings, > > Since Last Call was announced and I just ran into this problem, hereby > this question: > > If an image is drawn on a Canvas element, and subsequently the > javascript function cloneNode(true) is executed for that element, > should the clone include a copy of the source canvas image, or should > it show an empty space? I think it'd be cool if the clone showed the image. But, I'm pretty sure cloneNode(true) is just supposed to create a new canvas element with the same attributes and childNodes as the original. It's not supposed to copy everything that's going on with the element being copied. There are some exceptions with state for certain elements. Perhaps that can happen with canvas too. -- Michael From timeless at gmail.com Sat Nov 14 17:23:16 2009 From: timeless at gmail.com (timeless) Date: Sun, 15 Nov 2009 03:23:16 +0200 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <63df84f0911121803t4a347b7du8f8d387aff12b5b7@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> <63df84f0911121803t4a347b7du8f8d387aff12b5b7@mail.gmail.com> Message-ID: <26b395e60911141723x4dd96ca8xdda10b33c6bec1db@mail.gmail.com> what if pushState returned a value which could be passed to clearState? https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review was interesting (i can't find clearState in http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate -- maybe i'm looking in the wrong place?) From justin.lebar at gmail.com Sat Nov 14 17:44:08 2009 From: justin.lebar at gmail.com (Justin Lebar) Date: Sat, 14 Nov 2009 17:44:08 -0800 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <26b395e60911141723x4dd96ca8xdda10b33c6bec1db@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> <63df84f0911121803t4a347b7du8f8d387aff12b5b7@mail.gmail.com> <26b395e60911141723x4dd96ca8xdda10b33c6bec1db@mail.gmail.com> Message-ID: <c84706c70911141744o31d3e2fdo51b7ae4bd890e17@mail.gmail.com> On Sat, Nov 14, 2009 at 5:23 PM, timeless <timeless at gmail.com> wrote: > what if pushState returned a value which could be passed to clearState? I'm not sure how this would work. What would clearState do with that value? > (i can't find clearState in > http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate Hixie removed it a few days ago. -Justin From timeless at gmail.com Sun Nov 15 07:00:25 2009 From: timeless at gmail.com (timeless) Date: Sun, 15 Nov 2009 17:00:25 +0200 Subject: [whatwg] Do we really need history.clearState()? In-Reply-To: <c84706c70911141744o31d3e2fdo51b7ae4bd890e17@mail.gmail.com> References: <c84706c70911121200j71be3da3k6cc16766600bce7f@mail.gmail.com> <7AE09E8E-005C-499F-848C-A2B9BE3B46E6@apple.com> <63df84f0911121639k1527138cw4d1ab4f3ede9974c@mail.gmail.com> <26F6E1DF-A9F5-47DF-8DC6-8C6274AEF38B@apple.com> <63df84f0911121803t4a347b7du8f8d387aff12b5b7@mail.gmail.com> <26b395e60911141723x4dd96ca8xdda10b33c6bec1db@mail.gmail.com> <c84706c70911141744o31d3e2fdo51b7ae4bd890e17@mail.gmail.com> Message-ID: <26b395e60911150700g37067b20pe724d7e8187d5245@mail.gmail.com> On Sat, Nov 14, 2009 at 5:23 PM, timeless <timeless at gmail.com> wrote: > what if pushState returned a value which could be passed to clearState? On Sun, Nov 15, 2009 at 3:44 AM, Justin Lebar <justin.lebar at gmail.com> wrote: > I'm not sure how this would work. ?What would clearState do with that value? roughly: user visits http://app.example.com/ app calls pushState() and stores the result user initiates a login process, which results in a sequence of 5 pushState() calls which the app knows it doesn't care about. user completes login process app calls clearState() with result from previous stored pushState() app calls pushState() to its current state >> (i can't find clearState in >> http://www.whatwg.org/specs/web-apps/current-work/#dom-history-pushstate > > Hixie removed it a few days ago. ah that explains it, thanks From tkent at chromium.org Sun Nov 15 22:48:02 2009 From: tkent at chromium.org (TAMURA, Kent) Date: Mon, 16 Nov 2009 15:48:02 +0900 Subject: [whatwg] stepMismatch with value < min or value > max Message-ID: <b7b4ecf80911152248o1206a800y7ec827a3a8e380c0@mail.gmail.com> <input type=number min=0 step=2 value='-1'> <input type=number min=0 max=4 step=2 value=5> Should input.validity.stepMismatch return true in these cases? The spec simply says: "that number subtracted from the step base is not an integral multiple of the allowed value step, the element is suffering from a step mismatch." and doesn't mention the relationship with rangeUnderflow and rangeOverflow. So I think stepMismatch should work even if value is less than min or greater than max. I'd like to clarify it. -- TAMURA Kent Software Engineer, Google -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091116/7698ef32/attachment.htm> From mikewse at hotmail.com Mon Nov 16 04:51:59 2009 From: mikewse at hotmail.com (Mike Wilson) Date: Mon, 16 Nov 2009 13:51:59 +0100 Subject: [whatwg] AJAX History Concerns In-Reply-To: <Pine.LNX.4.62.0911130110450.27661@hixie.dreamhostps.com> Message-ID: <023901ca66bb$96a34380$0a01a8c0@mikedeskxp> Ian Hickson wrote: > The idea is that the string you would put into the back > button or history menu is not the same as the string > you would put into the title bar or bookmarks (i.e. not > the same as <title>). It might be good to spell out the fact that sessionHistoryEntry.title has nothing to do with document.title a bit more explicitly in the text, as this seems to be easily misinterpreted (maybe because of the use of the "title" identifer?). Maybe adding a note to 6.10.1, and/or expanding the note about title in 6.10.2 would be good? Best regards Mike Wilson From philipj at opera.com Mon Nov 16 10:47:45 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Mon, 16 Nov 2009 19:47:45 +0100 Subject: [whatwg] <time> parsing and rendering Message-ID: <op.u3h3tnx1sr6mfa@worf> http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-month-component Is there a use case for machine-readable dates after 9999? I'm sure HTML5 will have been obsoleted before it's meaningful to express accurate times that far in the future. As existing similar formats use a 4-digit year, adapting parsers for those is a lot easier if the HTML5 year format be exactly 4 figures. Also, it seems more likely that >4-digit years will be typos than intended and useful as machine-readable data. If there are no strong use cases for it, please make it YYYY only. http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#parse-a-date-or-time-string "10. If the date present and time present flags are both true, but position is beyond the end of input, then fail." This seems to be a bug if you consider how '2009-11-16T' would be parsed. The algorithm is supposed to return a date time or global date and time, but '2009-11-16T' is valid as neither. The intent of this step must be to make sure that T is always followed by a date, but it won't work. Except from being in the incorrect order (after time present may have been set to false) it also checks for the end of input, which doesn't make sense when the "in content" variant is used. Perhaps it would be possible to simply replace this algorithm with "try parsing a global date and time, else try parsing a date, else try parsing a time"? I haven't check carefully if this is equivalent though. http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0 "When the time binding applies to a time element, the element is expected to render as if it contained text conveying the date (if known), time (if known), and time-zone offset (if known) represented by the element, in the fashion most convenient for the user." This is very vague. Anything which tries to localize the date/time will fail because guessing the language of web pages is hard. Hard-coding it to English also wouldn't be very nice. What seems to make the most sense is using the "best representation of the global date and time string" and equivalents for just time and date that have to be defined. Still, I'm not sure this is very useful, as the same rendering (but slightly more flexible) could be accomplished by simply putting the date/time in the content instead of in the attribute. As a bonus, that would degrade gracefully. Unless I'm missing something, I suggest dropping the special rendering requirements for <time> completely. -- Philip J?genstedt Opera Software From svartman95 at gmail.com Tue Nov 17 07:50:30 2009 From: svartman95 at gmail.com (Bjartur Thorlacius) Date: Tue, 17 Nov 2009 15:50:30 +0000 Subject: [whatwg] element.onFocus instead of window.onhashcange ? Message-ID: <e205f470911170750s231c332bm5b440bf3d4bc80b3@mail.gmail.com> As the discussion had turned into bunch (good) advice giving, I decided to repost this if anyone actually has opinion on this matter and/or could tell me why the spec recommends firing hashchange on the document instead of a specific element when a user navigates to a URI with a hash component. ---------- Forwarded message ---------- From: Bjartur Thorlacius <svartman95 at gmail.com> Date: Tue, 3 Nov 2009 18:46:54 +0000 Subject: elemen.onFocus instead of window.onhashcange ? To: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org> Wouldn't it make more sense to fire a focus event on a element whose id is that of the new hash instead of firing hashchange on the whole window? In most cases script authors will check the hash against a few options and then act upon with actions such as loading a new body (or div). It would make sense to have the new elements in the HTML but hidden (or out of view, but scrollable to -- though that's hard to implement) and when the focus is thrown on the element it's scrollIntoView()d. Maybe click or some new 'scrolledTo' event might be used instead of focus, I don't know, but my point is the event should fire on the element not window and it would be best to do so using an already supported event. Importantly this would encourage authors to use real HTML elements as targets for their #references so UAs which don't support HTML 5 scripting interfaces and/or CSS will render all the content (though likely some of it'll be out of the screen or not-yet rendered) but when a user follows a link to it it'll simply scrollIntoView(). This won't always be exactly what supposed but often close enough. But then the scrollIntoView function definition should make clear that non-visual UAs should also support the top argument, by only rendering the referenced element when applicable (scrollIntoView(false)). From cbiesinger at gmail.com Tue Nov 17 14:02:58 2009 From: cbiesinger at gmail.com (Christian Biesinger) Date: Tue, 17 Nov 2009 23:02:58 +0100 Subject: [whatwg] Web sockets and existing HTTP stacks Message-ID: <557ae280911171402v7546e5e7n93a1e57f87dc10e5@mail.gmail.com> Hi, so I was reading the web sockets spec as well as a Firefox patch to implement it. Is it intentional that it is impossible to implement this spec over an existing HTTP stack, as currently specified? In particular, due to the strict requirements on the headers to send, it seems like you can't really implement it with an existing HTTP stack. On the other hand, you really do want to reuse your HTTP implementation, because otherwise you have to reimplement all your HTTP proxy authentication, including NTLM, GSSAPI, etc. Obviously another problem would be that the actual bidirectional communication might be hard to fit into your HTTP implementation, but that might be easier to work around. Do you as the spec authors have any thoughts on this? -christian From philipj at opera.com Tue Nov 17 14:11:18 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Tue, 17 Nov 2009 23:11:18 +0100 Subject: [whatwg] Microdata example validation Message-ID: <op.u3j7w4hdsr6mfa@worf> http://www.whatwg.org/specs/vocabs/current-work/#examples The Jack Bauer example has validation issues (using http://validator.nu/) My fix: --- jack.html.orig 2009-11-17 11:03:03.000000000 +0100 +++ jack.html 2009-11-17 11:03:19.000000000 +0100 @@ -41,12 +41,12 @@ you're interested in the CTU five-a-side football team we're trying to get going.</p> - <ins datetime="2008-07-20T21:00:00+0100"> + <ins datetime="2008-07-20T21:00:00+01:00"> <span itemprop="rev" itemscope> <meta itemprop="type" content="date-time"> - <meta itemprop="value" content="2008-07-20T21:00:00+0100"> + <meta itemprop="value" content="2008-07-20T21:00:00+01:00"> </span> <p itemprop="tel" itemscope><strong>Update!</strong> My new <span itemprop="type">home</span> phone number is - <span itemprop="value">01632 960 123</span>. + <span itemprop="value">01632 960 123</span>.</p> </ins> </section> This is just a convenient format, not a patch... Apart from this I get validation errors in this and many other examples because the meta and link elements aren't allowed in the contexts where they are used, but I suspect this is just validator.nu being in need of fixing (waiting for new account email so I can report). -- Philip J?genstedt From josh at openvideoalliance.org Tue Nov 17 16:49:59 2009 From: josh at openvideoalliance.org (Josh Levy) Date: Tue, 17 Nov 2009 19:49:59 -0500 Subject: [whatwg] Open Video Alliance Contest Message-ID: <2b117e380911171649i5dbc81c0p75fb6b08aeab4829@mail.gmail.com> With a nod to HTML5... ;) *Want to win a trip to South By Southwest 2010? Or maybe a Flip Mino video camera? Read on...* *Open Video in 60 Seconds* <http://contest.openvideoalliance.org/> The Open Video Alliance is holding a video contest<http://contest.openvideoalliance.org/>. To enter, just make a video spot explaining open video in 60 seconds or less. Then upload it anywhere and tell us the URL. Our judges?including web luminaries like Jimmy Wales and Mitchell Baker?will pick the best and most creative entries. One lucky winner will be headed to Austin on an expenses-paid trip to SXSW 2010 <http://sxsw.com/interactive>*, *and three runners-up will get a Flip Mino handheld video camera. The last day to submit a video is January 31, 2010. Head over to the contest page <http://contest.openvideoalliance.org/> to check out the entries and submit your own video! Complete rules are here<http://contest.openvideoalliance.org/about/> . *Need some inspiration?* We've got you covered. Here are some ideas.<http://contest.openvideoalliance.org/about/#3>For more on open video, check out some open video issues <http://openvideoalliance.org/issues>. *Who are you?* The Open Video Alliance <http://openvideoalliance.org/> is a coalition of organizations and individuals devoted to creating and promoting free and open technologies, policies, and practices in online video. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091117/4030c40b/attachment.htm> From beidson at apple.com Wed Nov 18 14:12:42 2009 From: beidson at apple.com (Brady Eidson) Date: Wed, 18 Nov 2009 14:12:42 -0800 Subject: [whatwg] svn.whatwg.org inaccessible? Message-ID: <2AC39C81-9C96-4CA0-AFD4-9517C8880C0A@apple.com> I need to look at some older versions of the spec, but it appears svn.whatwg.org is currently inaccessible. Is there some other interface to browse past revisions? ~Brady From dean.edwards at gmail.com Wed Nov 18 16:38:48 2009 From: dean.edwards at gmail.com (Dean Edwards) Date: Thu, 19 Nov 2009 00:38:48 +0000 Subject: [whatwg] element.onFocus instead of window.onhashcange ? In-Reply-To: <e205f470911170750s231c332bm5b440bf3d4bc80b3@mail.gmail.com> References: <e205f470911170750s231c332bm5b440bf3d4bc80b3@mail.gmail.com> Message-ID: <4B049398.70207@gmail.com> On 17/11/2009 15:50, Bjartur Thorlacius wrote: > As the discussion had turned into bunch (good) advice giving, I > decided to repost this if anyone actually has opinion on this matter > and/or could tell me why the spec recommends firing hashchange on the > document instead of a specific element when a user navigates to a URI > with a hash component. > A lot of Ajax apps will manipulate the value of location.hash to represent the *state of the application*. In this case there is no corresponding element to trap the onfocus event. -dean From ukai at chromium.org Wed Nov 18 20:26:04 2009 From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=) Date: Thu, 19 Nov 2009 13:26:04 +0900 Subject: [whatwg] [hybi] Races in websocket API? In-Reply-To: <4B04C2D6.8010908@webtide.com> References: <4B04C2D6.8010908@webtide.com> Message-ID: <de17d48e0911182026i1a31dcbdoa5edafeb1f48e779@mail.gmail.com> On Thu, Nov 19, 2009 at 1:00 PM, Greg Wilkins <gregw at webtide.com> wrote: > > Is there a race in the websocket API. > > When you do: > > var ws = new WebSocket("ws://mysite.com","myprotocol"); > > then the spec says: > > Return a new WebSocket object, and continue these steps in the > background (without blocking scripts). > > Establish a Web Socket connection to a host host, on port port > (if one was specified), from origin, with the flag secure, with > resource name as the resource name, and with protocol as the > protocol (if it is present). > > > So if the next line in the script is > > ws.onopen=myopenfunc; > > there is a race between if the onopen function will > be assigned and if the background connection has been established? > I believe open event is just queued at the moment, and it will be fired later when javascript becomes idle. When the Web Socket connection is established, the user agent must run the following steps: Change the readyState attribute's value to OPEN (1). Queue a task to fire a simple event named open at the WebSocket object. -- ukai > > OK it is currently unlikely that the connect will happen that > quick - however if I'm running in a rhino test environment > or a on a browser that is multiplexing the websocket onto an > already existing connection, then the onopen may indeed be fast. > > Similar races exist for onmessage and onclose. Setting onmessage > might miss a message that is delivered quickly after the websocket > is opened. > > > regards > _______________________________________________ > hybi mailing list > hybi at ietf.org > https://www.ietf.org/mailman/listinfo/hybi > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091119/652a0c4e/attachment.htm> From mike at w3.org Wed Nov 18 23:49:37 2009 From: mike at w3.org (Michael(tm) Smith) Date: Thu, 19 Nov 2009 16:49:37 +0900 Subject: [whatwg] svn.whatwg.org inaccessible? In-Reply-To: <2AC39C81-9C96-4CA0-AFD4-9517C8880C0A@apple.com> References: <2AC39C81-9C96-4CA0-AFD4-9517C8880C0A@apple.com> Message-ID: <20091119074936.GA28497@sideshowbarker> Brady Eidson <beidson at apple.com>, 2009-11-18 14:12 -0800: > I need to look at some older versions of the spec, but it appears svn.whatwg.org is currently inaccessible. > > Is there some other interface to browse past revisions? There's http://dev.w3.org/cvsweb/html5/spec/Overview.html -- Michael(tm) Smith http://people.w3.org/mike/ From t.broyer at gmail.com Thu Nov 19 01:33:25 2009 From: t.broyer at gmail.com (Thomas Broyer) Date: Thu, 19 Nov 2009 10:33:25 +0100 Subject: [whatwg] element.onFocus instead of window.onhashcange ? In-Reply-To: <4B049398.70207@gmail.com> References: <e205f470911170750s231c332bm5b440bf3d4bc80b3@mail.gmail.com> <4B049398.70207@gmail.com> Message-ID: <a9699fd20911190133w1a6768bcraa7ca9e3ced01aff@mail.gmail.com> On Thu, Nov 19, 2009 at 1:38 AM, Dean Edwards wrote: > On 17/11/2009 15:50, Bjartur Thorlacius wrote: >> >> As the discussion had turned into bunch (good) advice giving, I >> decided to repost this if anyone actually has opinion on this matter >> and/or could tell me why the spec recommends firing hashchange on the >> document instead of a specific element when a user navigates to a URI >> with a hash component. >> > > A lot of Ajax apps will manipulate the value of location.hash to represent > the *state of the application*. In this case there is no corresponding > element to trap the onfocus event. ...and this includes GMail that Bjartur is using (it also includes: Twitter, Facebook, Google Reader, Google Code Hosting's source browsing, Google Wave, etc.) -- Thomas Broyer /t?.ma.b?wa.je/ From philipj at opera.com Thu Nov 19 14:51:59 2009 From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=) Date: Thu, 19 Nov 2009 23:51:59 +0100 Subject: [whatwg] <link>/<meta> and microdata Message-ID: <op.u3ny4xcksr6mfa@worf> In a (slightly edited) Jack Bauer example [1], Chrome, Firefox and presumably Safari has the meta elements moved to head. This will severely break script-based implementation of microdata, which are likely to be used for the time being until the DOM API is implemented natively. I can't see any workaround for this, so I suggest that <meta> simply not be used for microdata, preferably by making it non-conforming and removing it from the definitions/algorithms. For <link>, the rel attribute issue [2] needs to be settled. It seems to me that sometimes requiring rel and sometimes not makes for a less consistent language with more room for error. I hesitate to make an argument based on aesthetics, but I think repurposing either <link> or <meta> for use in microdata is decidedly ugly, mostly because my legacy understanding of them is as "<head> only elements". In the usability study [3] there was only one example which used <link> and <meta> [4]. Was there any indication then that any of the test subjects were put off by either <link> or <meta>? Is my concern exaggerated? (It often is.) Both <item> and <link> are used only to include non-visible metadata in the item. Philip Taylor points out in IRC that these work equally well: <span hidden itemprop=foo>bar</span> (instead of meta) <a itemprop=foo href=bar></a> (instead of link) Of course this is just as ugly. It's good enough perhaps, but if someone has an aesthetically pleasing solution for these cases, I'd like to hear about it. New void elements are a no-go, just like <itemref> didn't work out. [1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/312 [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8340 [3] http://blog.whatwg.org/usability-testing-html5 [4] http://damowmow.com/playground/microdata/001/yelp-annotated.html -- Philip J?genstedt From micdesim at gmail.com Thu Nov 19 15:51:42 2009 From: micdesim at gmail.com (Michelangelo De Simone) Date: Fri, 20 Nov 2009 00:51:42 +0100 Subject: [whatwg] validationMessage In-Reply-To: <9450c5340911101437l26be3d09m72dbe8230b5cb87d@mail.gmail.com> References: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> <9450c5340911101437l26be3d09m72dbe8230b5cb87d@mail.gmail.com> Message-ID: <25148B62-A123-43B5-B6A8-16153B8879BD@gmail.com> Hi, pardon me but it seems almost nonsense to me: would users fill forms in a language they can't even understand? For instance: I'm italian, I speak Italian and English but I'm required to fill a form in Swahili. I would understand validation messages for sure (they would come from my UA) but I couldn't understand why they don't satisfy their constraints, what I'm supposed to fill and when I should submit the form. A clarification is needed. Il giorno 10/nov/2009, alle ore 23.37, Scott Gonz?lez ha scritto: > Wouldn't the UA be written for a specific language that would be independent of the language the page's content is written in? For example, a user in Spain would be using a UA with a Spanish locale (the UA's menus, dialogs, button labels, etc. would all be in Spanish). If that user were to visit a page written in French wouldn't the content generated by the UA still be in Spanish? So an alert would contain a message in French, but a button in Spanish. I would expect the same thing to happen with validation messages. > > As for the suggestion of the validation message just being a constant, you can just check the validity state if you want to provide custom messages. > > > On Tue, Nov 10, 2009 at 4:23 PM, Michelangelo De Simone <micdesim at gmail.com> wrote: > Hi, > > I've been dealing with the validationMessage implementation in WebKit. As some of WebKit member pointed out it's quite unusual for an attribute to "return a suitably *localized message* that the user agent would show the user". > > Couldn't such behavior be potentially heterogeneous among UAs and localizations? > > What is the rationale about this choice? A simpler behavior with a predetermined list of return values (eg: i.validationMessage == VALUEMISSING) could be much more efficient for authors and implementors to deal with, IMHO. > > Thank you for your feedbacks. > -- > Bye, Michelangelo > > > > -- Bye, Michelangelo From pkasting at google.com Thu Nov 19 16:05:55 2009 From: pkasting at google.com (Peter Kasting) Date: Thu, 19 Nov 2009 16:05:55 -0800 Subject: [whatwg] validationMessage In-Reply-To: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> References: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> Message-ID: <d62cf1d10911191605w2046d465u4103926577822dca@mail.gmail.com> On Tue, Nov 10, 2009 at 12:23 PM, Michelangelo De Simone <micdesim at gmail.com > wrote: > What is the rationale about this choice? A simpler behavior with a > predetermined list of return values (eg: i.validationMessage == > VALUEMISSING) could be much more efficient for authors and implementors to > deal with, IMHO. > I tend to agree. >From https://bugs.webkit.org/show_bug.cgi?id=27959#c29 , where this was implemented for WebKit: "This patch sure does seem to be an eloquent argument for not having all these localized strings in the HTML5 form element design! I don't see a lot of value of returning these strings that might not even be in the same language as the website. I wish we could get that changed." -- Darin Adler My oversimplified view of this is: * Providing a way for the webpage to specify validation constraints and understand when they have not been met -- good * Directing the UA to step into this process and show the user messages about the validation failures, which don't take into account context the web page has -- bad This seems like an attempt to make life slightly easier on webpage authors by providing boilerplate UI if they don't want to write anything. But I see that as a small benefit with significant edge cases. Authors are already expected to supply the textual content in the page, the text in alerts, etc., so providing the text in the "validation failed" UI doesn't seem that bad. The UA can still do things like turn fields red or add warning sign icons or something if it likes. PK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091119/8274eff1/attachment.htm> From scott.gonzalez at gmail.com Thu Nov 19 18:58:46 2009 From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=) Date: Thu, 19 Nov 2009 21:58:46 -0500 Subject: [whatwg] validationMessage In-Reply-To: <d62cf1d10911191605w2046d465u4103926577822dca@mail.gmail.com> References: <B72C6CB1-6DAE-4735-8200-FBE0536996A5@gmail.com> <d62cf1d109111916

{Title}

Join Mailing list OR visit our website

The Solar System in 3/4

The Solar System in 3/4

...

3D JAVASCRIPT, 2D HTML & CSS -----------------------------------------------

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

>
>
>
> > > >
>
> > > >
>
> > > >
> ... >
>
> > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > >

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

>>
>>
>>
>> >> >> >>
>>
>> >> >> >>
>>
>> >> >> >>
>> ... >>
>>
>> >> >> >> 3D JAVASCRIPT, 2D HTML & CSS >> ----------------------------------------------- >> >> >> >>

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

...

3D JAVASCRIPT, 2D HTML & CSS -----------------------------------------------

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

>
>
>
> > > >
>
> > > >
>
> > > >
> ... >
>
> > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > >

The Solar System in 3/4

This is a header

This is a header

{Title}

Join Mailing list OR visit our website

The Solar System in 3/4

The Solar System in 3/4

... 3D JAVASCRIPT, 2D HTML & CSS ----------------------------------------------- canvas { * Height/Width of viewport }

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

> > > > > > > > > > > > > > > > > > ... > > > > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > > canvas { > * Height/Width of viewport > } > > > >

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ... >> >> >> >> >> >> 3D JAVASCRIPT, 2D HTML & CSS >> ----------------------------------------------- >> >> >> >> canvas { >> * Height/Width of viewport >> } >> >> >> >>

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

... 3D JAVASCRIPT, 2D HTML & CSS ----------------------------------------------- canvas { * Height/Width of viewport }

The Solar System in 3/4

The Solar System in 3/4

The Solar System in 3/4

> > > > > > > > > > > > > > > > > > ... > > > > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > > canvas { > * Height/Width of viewport > } > > > >

The Solar System in 3/4

This is a header

This is a header

...

3D JAVASCRIPT, 2D HTML & CSS -----------------------------------------------

>
>
>
> > > >
>
> > > >
>
> > > >
> ... >
>
> > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > >

>>
>>
>>
>> >> >> >>
>>
>> >> >> >>
>>
>> >> >> >>
>> ... >>
>>
>> >> >> >> 3D JAVASCRIPT, 2D HTML & CSS >> ----------------------------------------------- >> >> >> >>

...

3D JAVASCRIPT, 2D HTML & CSS -----------------------------------------------

>
>
>
> > > >
>
> > > >
>
> > > >
> ... >
>
> > > > 3D JAVASCRIPT, 2D HTML & CSS > ----------------------------------------------- > > > >