Re: [whatwg] Structured clone algorithm on LocalStorage
On Tue, Sep 29, 2009 at 12:19 AM, Darin Fisher wrote:
> On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking wrote:
>>
>> On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher wrote:
>> > On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking wrote:
>> >>
>> >> On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher
>> >> wrote:
>> >> > On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking
>> >> > wrote:
>> >> >>
>> >> >> On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher
>> >> >> wrote:
>> >> >> > On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Wed, Sep 23, 2009 at 10:19 PM, Darin Fisher
>> >> >> >>
>> >> >> >> 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!
I think we're mostly in agreement. What I'm not sure about is what you
are proposing we do with localStorage? Remove it from the spec? Change
the API? Something else?
>> >> > 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
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 Hickson 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 . 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 and 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, has no list="" support, cols="" > > works differently than size="", the default value is set differently, > > 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 , and I'm not aware of any UA that does 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r4029 - [e] (0) Example of use without .
Ah. I was afraid you might say that. On Tue, Sep 29, 2009 at 6:54 PM, Ian Hickson 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] [html5] r4029 - [e] (0) Example of use without .
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] The new content model for 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] The new content model for 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 Edwards wrote: You have two choices to get around the rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: I don't like either solution. The third solution, of course, is just to avoid 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 which will look OK in some browsers but completely break others." This whole thing is really much less of an issue than the 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 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 breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwards wrote: > You have two choices to get around the rendering bug: > > 1. The potentially dangerous document.write() > > 2. Inserting weird conditional comments into your code: > > > > > > I don't like either solution. The third solution, of course, is just to avoid 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 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 s or s 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 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 . 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 rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: I don't like either solution. -dean
Re: [whatwg] The new content model for 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 . 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 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 Edwards wrote: This will also affect the 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.) 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 . 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] 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 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 breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 11:55 AM, Dean Edwards 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 in an fixes things, but I have no clue how or why putting an unclosed in the (which doesn't end up appearing in the actual DOM) works. ~TJ
Re: [whatwg] The new content model for 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 Edwards wrote: This will also affect the 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.) 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 breaks rendering in MSIE5-7
On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwards wrote: > > This will also affect the 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 .) ~TJ
[whatwg] Closing tags for empty content model
> Just to reiterate, Opera<10 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] Cache Manifest: why have NETWORK?
On Thu, 24 Sep 2009 10:43:57 +0200, Anne van Kesteren wrote: On Wed, 23 Sep 2009 20:09:03 +0200, Michael Nordman 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=x&newValue=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] The new content model for breaks rendering in MSIE5-7
This will also affect the element. Test case: http://dean.edwards.name/test/details.html -dean
Re: [whatwg] [html5] r4029 - [e] (0) Example of use without .
s/Html/html/ On Tue, Sep 29, 2009 at 4:30 AM, Simon Pieters wrote: > On Tue, 29 Sep 2009 07:57:21 +0200, 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 use without . >> >> 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 @@ >> >> + >> + Here is a graduation programme with two sections, one for the >> + list of people graduating, and one for the description of the >> + ceremony. >> + >> + >> > > 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/
Re: [whatwg] Closing tags for empty content model
On Tue, 29 Sep 2009 05:58:43 +0200, Dean Edwards wrote: Just to reiterate, Opera<10 treats all unknown elements as container (flow) elements. That means that as soon as it encounters a tag, all of the following elements are *children* of the element. This makes all DOM queries and CSS rules completely useless. Allowing a closing tag solves the problem. The problem with allowing this is that means which is not intuitive at all. Also, it might lead people to think that x 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] Workers and addEventListener
On Tue, 29 Sep 2009 09:13:17 +0200, Zoltan Herczeg 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] [html5] r4029 - [e] (0) Example of use without .
On Tue, 29 Sep 2009 07:57:21 +0200, 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 use without . 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 @@ + + Here is a graduation programme with two sections, one for the + list of people graduating, and one for the description of the + ceremony. + + s/DOCTPE/DOCTYPE/ -- Simon Pieters Opera Software
Re: [whatwg] [html5] r4017 - [] (0) Hide margin on 'dd' if in or . Fixing http://www.w3.org [...]
On Tue, 29 Sep 2009 03:01:06 +0200, 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 or .
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; } /* LTR-specific: 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] Interface object vs constructor in Web Workers
On Fri, 25 Sep 2009 14:47:10 +0200, Simon Pieters 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] Structured clone algorithm on LocalStorage
On Thu, Sep 24, 2009 at 11:57 PM, Jonas Sicking wrote:
> On Thu, Sep 24, 2009 at 9:04 PM, Darin Fisher wrote:
> > On Thu, Sep 24, 2009 at 4:43 PM, Jonas Sicking wrote:
> >>
> >> On Thu, Sep 24, 2009 at 10:52 AM, Darin Fisher
> wrote:
> >> > On Thu, Sep 24, 2009 at 10:40 AM, Jonas Sicking
> >> > wrote:
> >> >>
> >> >> On Thu, Sep 24, 2009 at 1:17 AM, Darin Fisher
> >> >> wrote:
> >> >> > On Thu, Sep 24, 2009 at 12:20 AM, Jonas Sicking
> >> >> > 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
[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
