[whatwg] Workers and addEventListener
Hi all, I am Zoltan Herczeg from University of Szeged, Hungary. I am a member of a team who working on WebKit browser engine. In this bug report: https://bugs.webkit.org/show_bug.cgi?id=29801 , Alexey suggested me that I should contact you about my qestion. In WebKit implementation of MessagePort the addEventListener(message, ...) does not enable the transmitting of messages. All messages are actually discarded until a dummy function is assigned to onmessage. However, after the dummy is assigned, the callback functions passed to addEventListener start receiving messages. The shared workers example here http://www.w3.org/TR/workers/ in section 1.2.4 suggests that addEventListener should also enable message transmitting. However, as Alexey pointed out, the examples are non-normative. And in the normative text, it is not mentioned that addEventListener should also enable message transmitting. I feel the workaround to enable message transmitting for addEventListener is ... 'dumb' now. Anyway, my qestion is: - should addEventListener enable message transmitting? - Should it do it in all cases, or only when message is passed as the first argument Zoltan
Re: [whatwg] Structured clone algorithm on LocalStorage
On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher da...@chromium.org wrote: On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher da...@chromium.org wrote: ... snip ... multi-core is the future. what's the opposite of fine-grained locking? it's not good ;-) the implicit locking mechanism as spec'd is super lame. implicitly unlocking under mysterious-to-the-developer circumstances! how can that be a good thing? storage.setItem(y, function_involving_implicit_unlocking(storage.getItem(x))); I totally agree on all points. The current API has big imperfections. However I haven't seen any workable counter proposals so far, and I honestly don't believe there are any as long as our goals are: * Don't break existing users of the current implementations. * Don't expose race conditions to the web. * Don't rely on authors getting explicit locking mechanisms right. The current API exposes race conditions to the web. The implicit dropping of the storage lock is that. In Chrome, we'll have to drop an existing lock whenever a new lock is acquired. That can happen due to a variety of really odd cases (usually related to nested loops or nested JS execution), which will be difficult for developers to predict, especially if they are relying on third-party JS libraries. This issue seems to be discounted for reasons I do not understand. I don't believe we've heard about this before, so that would be the reason it hasn't been taken into account. So you're saying that chrome would be unable implement the current storage mutex as specified in spec? I.e. one that is only released at the explicit points that the spec defines? That seems like a huge problem. No, no... my point is that to the application developer, those explicit points will appear quite implicit and mysterious. This is why I called out third-party JS libraries. One day, a function that you are using might transition to scripting a plugin, which might cause a nested loop, which could then force the lock to be released. As a programmer, the unlocking is not explicit or predictable. Ah, indeed, this is a problem. However the unfortunate fact remains that so far no other workable solution has been proposed. OK, so we agree that the current solution doesn't meet the goals you stated above :-( Well, it addresses them as long as users are aware of the risk, and properly document weather their various library functions will release the lock or not. However I agree that it's unlikely that they will do so correctly. I thought the point of not having lock APIs was that users shouldn't have to understand locks ;-) The issue I've raised here is super subtle. We have not succeeded in avoiding subtlety! Moreover, there are other examples which have been discussed on the list. There are some DOM operations that can result in a frame receiving a DOM event synchronously. That can result in a nesting of storage locks, which can force us to have to implicitly unlock the outermost lock to avoid deadlocks. Again, the programmer will have very poor visibility into when these things can happen. So far I don't think it has been shown that these events need to be synchronous. They all appear to be asynchronous in gecko, and in the case of different-origin frames, I'm not even sure there's a way for pages to detect if the event was fired asynchronously or not. IE and WebKit dispatch some of them synchronously. It's hard to say which is correct or if it causes any web compat isues. I'm also not sure that we have covered all of the cases. It still seems to me that it's extremely unlikely that pages depend on cross origin events to fire synchronously. I can't even think of a way to test if a browser dispatches these events synchronously or not. Can you? i agree that it seems uncommon. maybe there could be some odd app that does something after resizing an iframe that could be dependent on the event handler setting some data field. this kind of thing is probably even less common in the cross-origin case. Our approach to implementing implicit locking (if we must) will be to detect nested locking, and simply unlock the first held lock to basically prevent nested locking. This way we don't have to know all of the cases where this can happen. So is
Re: [whatwg] Interface object vs constructor in Web Workers
On Fri, 25 Sep 2009 14:47:10 +0200, Simon Pieters sim...@opera.com wrote: http://www.whatwg.org/specs/web-workers/current-work/#interface-objects-and-constructors seems to say that there must be no interface object for Worker and SharedWorker, but the constructors are to be available, which doesn't make any sense since the constructor and the interface object are in fact the same object, unless I'm misunderstanding things. Also, it should probably say Worker and SharedWorker instead of Worker() and SharedWorker(url). -- Simon Pieters Opera Software
Re: [whatwg] [html5] r4017 - [] (0) Hide margin on 'dd' if in figure or details. Fixing http://www.w3.org [...]
On Tue, 29 Sep 2009 03:01:06 +0200, wha...@whatwg.org wrote:
Author: ianh
Date: 2009-09-28 18:01:05 -0700 (Mon, 28 Sep 2009)
New Revision: 4017
Modified:
index
source
Log:
[] (0) Hide margin on 'dd' if in figure or details.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7629
Modified: source
===
--- source 2009-09-29 00:56:20 UTC (rev 4016)
+++ source 2009-09-29 01:01:05 UTC (rev 4017)
@@ -85107,6 +85107,7 @@
h6 { margin-top: 2.33em; margin-bottom; 2.33em; }
dd { margin-left: 40px; } /* spanLTR-specific/span: use
'margin-right' for rtl elements */
+details dd, figure dd { margin-left: 0; }
This should be LTR-specific, too.
--
Simon Pieters
Opera Software
Re: [whatwg] [html5] r4029 - [e] (0) Example of section use without article.
On Tue, 29 Sep 2009 07:57:21 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-09-28 22:57:20 -0700 (Mon, 28 Sep 2009) New Revision: 4029 Modified: index source Log: [e] (0) Example of section use without article. Modified: index === --- index 2009-09-29 02:41:23 UTC (rev 4028) +++ index 2009-09-29 05:57:20 UTC (rev 4029) @@ -13031,7 +13031,60 @@ /div + div class=example + pHere is a graduation programme with two sections, one for the + list of people graduating, and one for the description of the + ceremony./p + + prelt;!DOCTPE Htmlgt; s/DOCTPE/DOCTYPE/ -- Simon Pieters Opera Software
Re: [whatwg] Closing tags for empty content model
On Tue, 29 Sep 2009 05:58:43 +0200, Dean Edwards dean.edwa...@gmail.com wrote: Just to reiterate, Opera10 treats all unknown elements as container (flow) elements. That means that as soon as it encounters a source tag, all of the following elements are *children* of the source element. This makes all DOM queries and CSS rules completely useless. Allowing a closing /source tag solves the problem. The problem with allowing this is that br/br means brbr which is not intuitive at all. Also, it might lead people to think that imgx/img should work and file bugs on browsers regarding that while it really should not (and cannot). This does suck a little when introducing new void elements, but keeping the syntax consistent is worth it in my opinion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] [html5] r4029 - [e] (0) Example of section use without article.
s/Html/html/ On Tue, Sep 29, 2009 at 4:30 AM, Simon Pieters sim...@opera.com wrote: On Tue, 29 Sep 2009 07:57:21 +0200, wha...@whatwg.org wrote: Author: ianh Date: 2009-09-28 22:57:20 -0700 (Mon, 28 Sep 2009) New Revision: 4029 Modified: index source Log: [e] (0) Example of section use without article. Modified: index === --- index 2009-09-29 02:41:23 UTC (rev 4028) +++ index 2009-09-29 05:57:20 UTC (rev 4029) @@ -13031,7 +13031,60 @@ /div + div class=example + pHere is a graduation programme with two sections, one for the + list of people graduating, and one for the description of the + ceremony./p + + prelt;!DOCTPE Htmlgt; s/DOCTPE/DOCTYPE/ -- Simon Pieters Opera Software -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ http://sasha.sourceforge.net/ • http://www.yoursasha.com/
[whatwg] The new content model for details breaks rendering in MSIE5-7
This will also affect the figure element. Test case: http://dean.edwards.name/test/details.html -dean
Re: [whatwg] Cache Manifest: why have NETWORK?
On Thu, 24 Sep 2009 10:43:57 +0200, Anne van Kesteren ann...@opera.com wrote: On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman micha...@google.com wrote: For cases where you don't want to, or can't, 'fallback' on a cached resource. ex 1. http://server/get/realtime/results/from/the/outside/worldCreating a fallback resource with a mock error or empty response is busy work. ex 2. http://server/change/some/state/on/server/side?id=xnewValue=y Ditto You could fallback to a non-existing fallback or some such. But if it is really needed NETWORK should get priority over FALLBACK in my opinion (or at least the subset of NETWORK that is not a wildcard) so in cases like this FALLBACK: / /fallback NETWORK /realtime-api /update ... you do not get /fallback all the time. If this change is not made (though I hope it will, since it makes sense) the specification should make it more clear in the writing section (and maybe in parsing too) of the manifest that having both a wildcard and some network URLs does not make sense as the wildcard will always win anyway (per the changes to the networking model section). -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Closing tags for empty content model
Just to reiterate, Opera10 treats all unknown elements as container (flow) elements. Most desktop Opera installations (only in the US?) were put there by an end user, and offer to update themselves. Is Opera 10 likely to still be common by the time the spec actually exits last call? -jJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwards dean.edwa...@gmail.com wrote: This will also affect the figure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing in head.) ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com wrote: This will also affect thefigure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing inhead.) I can't get it to work using document.write(). Do you have a live example? And kudos to the guy that discovered this hack. I have no idea how it works but it seems to do the trick. Do you have any background to this hack apart from what was on the W3C list? -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 11:55 AM, Dean Edwards dean.edwa...@gmail.com wrote: I can't get it to work using document.write(). Do you have a live example? Yup. http://www.xanthir.com/etc/html5-details-fix.html (This works in IE8 when the page mode is set to IE7 or Quirks. It's possible that this doesn't actually work in a real IE7 or IE6, but I have no way to test it.) And kudos to the guy that discovered this hack. I have no idea how it works but it seems to do the trick. Do you have any background to this hack apart from what was on the W3C list? Unfortunately, no. We do know that actually wrapping a figure in an object fixes things, but I have no clue how or why putting an unclosed object in the head (which doesn't end up appearing in the actual DOM) works. ~TJ
Re: [whatwg] Workers and addEventListener
The intent of the spec is fairly clear that addEventListener(message) should not start the message queue dispatch - only setting the onmessage attribute does that: The first time a MessagePort #messageport object's onmessage#handler-messageport-onmessage IDL attribute is set, the port's port message queue #port-message-queue must be enabled, as if the start() #dom-messageport-start method had been called. In fact, the only reason for the existence of the MessagePort.start() method is to enable applications to start message queue dispatch when using addEventListener(). I don't have a strong opinion as to whether we should change the spec, though. I suspect not, given Anne's email. We should instead change the example in the workers spec to call start(). -atw On Tue, Sep 29, 2009 at 2:13 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 29 Sep 2009 09:13:17 +0200, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Anyway, my qestion is: - should addEventListener enable message transmitting? - Should it do it in all cases, or only when message is passed as the first argument I don't think it should. Web Workers should not modify the semantics of addEventListener. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 17:55, Dean Edwards wrote: On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwardsdean.edwa...@gmail.com wrote: This will also affect thefigure element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing inhead.) I can't get it to work using document.write(). Do you have a live example? It's always the last thing you try. :) http://dean.edwards.name/test/details2.html There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 19:30, Keryx Web wrote: 2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the head. If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. I'm starting to think that too. MSIE5-7 accounts for about a third of web users. This admittedly clever hack is just too hackish. You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwards dean.edwa...@gmail.com wrote: You have two choices to get around the dd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. The third solution, of course, is just to avoid details until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). This whole thing is really much less of an issue than the legend problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. After all, we're already happy enough using divs or dls or whatever to implement that functionality. It would be nice to immediately start using the new stuff, but the timeline for when it's viable isn't so long as to be unworkable. In the meantime, we just keep doing what we're already doing. ~TJ
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
On 29/09/2009 20:41, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwardsdean.edwa...@gmail.com wrote: You have two choices to get around thedd rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: /head !--[if lt IE 8]object!![endif]-- body I don't like either solution. The third solution, of course, is just to avoiddetails until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- You can start using HTML5 except details which will look OK in some browsers but completely break others. This whole thing is really much less of an issue than thelegend problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. The legend issue was much easier to fix with JavaScript. But that was a horrible solution as well. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) -dean
Re: [whatwg] The new content model for details breaks rendering in MSIE5-7
2009-09-29 21:53, Dean Edwards skrev: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. - figure IS new - details IS new BUT over a few peoples dead bodies it seem, that we should add one or two new elements to make them work that would be: - intuitive and easy to teach - semantically clear and that would have: - zero technical problems - no added costs for browser makers to implement, since it would be done in conjunction with figure and details as such anyway Instead we have a solution that: - currently requires weird and fragile hacks - redefines the semantics of existing elements Just because adding elements is evil. I actually do not know what argument that could sway peoples minds on this issue. It is beyond reason to me. I mean, it is not as if the dt/dd had been carefully discussed and researched BEFORE it entered the spec... Something I thought was a criterion for inclusion. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/
Re: [whatwg] [html5] r4029 - [e] (0) Example of section use without article.
On Tue, 29 Sep 2009, Gordon P. Hemsley wrote: s/Html/html/ Actually that was intentional in that example. I like to show a variety of syntaxes so that people can see that they can do whichever one they prefer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r4029 - [e] (0) Example of section use without article.
Ah. I was afraid you might say that. On Tue, Sep 29, 2009 at 6:54 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 29 Sep 2009, Gordon P. Hemsley wrote: s/Html/html/ Actually that was intentional in that example. I like to show a variety of syntaxes so that people can see that they can do whichever one they prefer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Gordon P. Hemsley m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/ http://sasha.sourceforge.net/ • http://www.yoursasha.com/
Re: [whatwg] Text areas with pattern attributes?
On Mon, 31 Aug 2009, Jonas Sicking wrote: On Mon, Aug 31, 2009 at 12:04 AM, Ian Hicksoni...@hixie.ch wrote: On Sun, 30 Aug 2009, Jonas Sicking wrote: Ok, addresses might not be the best example. I would imagine that most use cases for pattern for a single line, carries over if you want to have that single line wrap and be displayed as multiple lines. So if you can provide the list of use cases that was used to add pattern on single-line input and I'd be very surprised if not most of them carries over to multi-line. The main use cases that were considered as far as I recall were credit card numbers and other bank numbers (we originally considered type=cc but that turned out to be more locale-specific than expected), social security numbers and other formatted serial numbers, and username fields that exclude certain characters. So add 'multiple' on all of those and you'll have a good reason you'd want them all to be able to wrap over multiple lines. I.e. ability to enter multiple bank numbers, multiple social security numbers or multiple usernames. I could see an argument for input type=text pattern=... multiple. That's probably best left for a future version though. But I don't think that's the same as multiline input. The difference between input type=text and textarea is mostly a rendering one. One scrolls the text when it can't fit, the other wraps. Do you really think that creates enough of a difference that the feature set should be different? The feature sets are different in many other ways. This is hardly an exception. For example, textarea has no list= support, cols= works differently than size=, the default value is set differently, textarea doesn't support autocomplete, etc. All of these seem like a bad idea to keep separate for multiline inputs vs. single line inputs. Except for the default value which for historic reasons make sense to use separate mechanisms, and cols/size which are both mostly rendering differences. It's not clear how list= would work with textarea, and I'm not aware of any UA that does textarea autocomplete. I don't necessarily think all this is how I would design this if we were starting from scratch, but we're not, and I don't think we should be making them consistent at this point without good use cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
