[whatwg] Input type for phone numbers
Hi, I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). antti
Re: [whatwg] Input type for phone numbers
On Mon, 30 Mar 2009, Antti Koivisto wrote: I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). Would the pattern= attribute not be enough? Generally speaking at this point it's probably best for us to wait for the currently defined features to be more widely implemented before we add any more controls, since otherwise we'll just end up with different browsers implementing different subsets and it'll be a big mess. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Input type for phone numbers
On 31/3/09 07:24, Antti Koivisto wrote: I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book).A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). Sounds nice, but I think you need to follow this process more closely: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F I'd recommend reviewing previous discussion of similar feature proposals, e.g. by searching the mailing list. An earlier draft included a tel type for input, but this was dropped after concerns it would be difficult for UAs to correct convert telephone numbers to the required format: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000150.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000206.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000287.html If you'd still like to propose the feature, I think you'll need to address questions like: * What are the author or user problems you are trying to solve? You mention virtual keyboards - are these intended to provide security in some way? * How do people already attempt to solve these problems (link to examples/tutorials)? How could solutions make use of the new features HTML5 introduces (e.g. http://www.whatwg.org/specs/web-apps/current-work/#attr-input-pattern)? Are there any other possible solutions to the problems (security, adding from address books) that HTML5 could introduce? What are the pros and cons of all these possible solutions? I'd note one important alternative is the emergence of systems to autofill such profile information by providing a username on another system, from which the information can be harvested (e.g. via microformat parsing). With regards to the specific solution you did propose, what defines what is legal in phone numbers and what these symbols mean? -- Benjamin Hawkes-Lewis
Re: [whatwg] Input type for phone numbers
On 31.3.2009, at 0:12, Ian Hickson wrote: On Mon, 30 Mar 2009, Antti Koivisto wrote: I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). Would the pattern= attribute not be enough? Pattern attribute does not communicate the type. It would not allow you to bring up phone book based pickers or special input methods so it does not satisfy the use case. It also pushes the burden of specifying a right pattern to authors, something they are likely to get often wrong. Generally speaking at this point it's probably best for us to wait for the currently defined features to be more widely implemented before we add any more controls, since otherwise we'll just end up with different browsers implementing different subsets and it'll be a big mess. While I agree with the general sentiment I think there is some surprising asymmetry in including email type but leaving this unspecified. Different browsers implementing different subsets is probably unavoidable initially in any case. antti -- Ian Hickson U+1047E) \._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _ \ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'-- (,_..'`-.;.'
Re: [whatwg] Input type for phone numbers
Antti Koivisto wrote: I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). A brief look around shows the following characters also commonly used in phone numbers as people actually type them in the US: ' ' (ascii space), '.', '-', 'x' (this last in cases like 1-800-123-4567 x235). This last case in particular is one I would suspect involves a good bit of regional variability; I doubt the Latin lowercase 'x' is used throughout the world to denote extensions. -Boris
Re: [whatwg] Input type for phone numbers
Boris Zbarsky schrieb: Antti Koivisto wrote: I'd like to propose a new input type attribute value for phone numbers (input type=phonenumber perhaps). The primary benefit would be to enable use of phone number specific input methods (for example a virtual keyboard) and pickers (for example a system address book). A useful minimal implementation could limit the allowed characters to those legal in phone numbers (+ * # and 0-9). A brief look around shows the following characters also commonly used in phone numbers as people actually type them in the US: ' ' (ascii space), '.', '-', 'x' (this last in cases like 1-800-123-4567 x235). This last case in particular is one I would suspect involves a good bit of regional variability; I doubt the Latin lowercase 'x' is used throughout the world to denote extensions. There are more issues like this - vanity numbers with letters a-zA-Z seem to be popular in the USA, while they are marginal here in the German speaking countries. Also, the separation of phone numbers into blocks and the block separation character(s) are subject to regional differencies, and several formats might be considered as valid in the same region. Here in Switzerland, these formats are quite common: +41 (0)12 345 67 89 +41 12 345 67 89 012 345 67 89 012 345 6 345 In private use you find more variants, e.g.: 012-345'67'89 012/345'67'89 012 345/67/89 You will find other formats in other countries. I have no idea what people type in Japan or Sri Lanka. So, while e-mail addresses have a strictly defined format, this does not apply to phone numbers. Internationalisation would be necessary to validate them, and still it would be a hard task, as complete sets of valid formats might not be available for every country.
Re: [whatwg] Input type for phone numbers
Phone numbers do have a strictly defined format, and the definition is provided by ITU-T E.123. HTH, Chris.
Re: [whatwg] Input type for phone numbers
Markus Ernst wrote: So, while e-mail addresses have a strictly defined format, this does not apply to phone numbers. Internationalisation would be necessary to validate them, and still it would be a hard task, as complete sets of valid formats might not be available for every country. FWIW I would imagine that the most useful aspect of input type=tel or whatever would not be validation (because validation is hard) but would be better integration on mobile devices e.g. making the default action of the keypad be number keys, making phone numbers from the contacts list available, etc. (these were both pointed out already). Therefore whilst I totally recommend this feature be postponed for HTML6, I think it makes a lot of sense and that problems with validation are a red herring.
Re: [whatwg] Input type for phone numbers
On Mar 31, 2009, at 10:02 AM, James Graham wrote: Markus Ernst wrote: So, while e-mail addresses have a strictly defined format, this does not apply to phone numbers. Internationalisation would be necessary to validate them, and still it would be a hard task, as complete sets of valid formats might not be available for every country. FWIW I would imagine that the most useful aspect of input type=tel or whatever would not be validation (because validation is hard) but would be better integration on mobile devices e.g. making the default action of the keypad be number keys, making phone numbers from the contacts list available, etc. (these were both pointed out already). Therefore whilst I totally recommend this feature be postponed for HTML6, I think it makes a lot of sense and that problems with validation are a red herring. Not just on mobile devices. Desktop browsers can also offer integration with the system Address Book, and to some extent do this already based on heuristics that guess which input fields are for phone numbers. I believe every major browser has heuristics like this. Having an unambiguous way to indicate that a field expects a phone number would allow for better integration. It would eliminate false negatives, since phone number fields may be missed if they don't use a name= that enables the browser to guess. And by eliminating false positives, it would make it practical to make more extensive changes to the field, such as actually replacing it with a pop-up to choose phone numbers for example. While I sympathize with the desire to see current HTML5 form controls implemented first, frankly, we would be more interested in implementing input type=tel than the six different date/time controls currently in HTML5. It seems to me that entering a phone number is much more common than entering any kind of date at all, and certainly more common than entering a month or a week. Regards, Maciej
Re: [whatwg] Input type for phone numbers
Maciej Stachowiak wrote: While I sympathize with the desire to see current HTML5 form controls implemented first, frankly, we would be more interested in implementing input type=tel than the six different date/time controls currently in HTML5. It seems to me that entering a phone number is much more common than entering any kind of date at all, and certainly more common than entering a month or a week. It'd be interesting to get some data here, for sure. I don't enter phone numbers on websites unless I'm registering for something for the first time and it absolutely requires one (not that common, unless they expect to actually interact with you via phone). On the other hand, I enter dates at least 5 times a month (scheduling electronic payments for gas, electricity, credit cards, rent). Any time I plan travel I enter a whole bunch of dates (orbitz, expedia, trying different days if my dates are flexible, etc). Of course this is all anecdotal evidence, which is where data would be handy. I agree that entering a week is pretty rare, though. ;) -Boris
Re: [whatwg] Input type for phone numbers
On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that entering a week is pretty rare, though. ;) As someone working on supporting new input types in WebKit: Supporting any one form of date is nontrivial, but supporting the rest after you support the first _is_ trivial. So while I'm on the week is not that useful bandwagon, it'll be simple to support once date is supported. PK
Re: [whatwg] Worker feedback
On Mon, Mar 30, 2009 at 6:45 PM, Robert O'Callahan rob...@ocallahan.orgwrote: We have no way of knowing how much trouble this has caused so far; non-reproducibility means you probably won't get a good bug report for any given incident. It's even plausible that people are getting lucky with cookie races almost all the time, or maybe cookies are usually used in a way that makes them a non-issue. That doesn't mean designing cookie races in is a good idea. So, the first argument against cookie races was this is the way the web works now - if we introduce cookie races, we'll break the web. When this was proven to be incorrect (IE does not enforce exclusive access to cookies), the argument has now morphed to the web is breaking right now and nobody notices, which is more an article of faith than anything else. I agree that designing cookie races is not a good idea. If we could go back in time, we might design a better API for cookies that didn't introduce race conditions. However, given where we are today, I'd say that sacrificing performance in the form of preventing parallel network calls/script execution in order to provide theoretical correctness for an API that is already quite happily race-y is not a good tradeoff. In this case, I think the spec should describe the current implementation of cookies, warts and all. -atw
Re: [whatwg] Input type for phone numbers
On Mar 31, 2009, at 10:25 AM, Peter Kasting wrote: On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that entering a week is pretty rare, though. ;) As someone working on supporting new input types in WebKit: Supporting any one form of date is nontrivial, but supporting the rest after you support the first _is_ trivial. So while I'm on the week is not that useful bandwagon, it'll be simple to support once date is supported. It depends on the quality of implementation you want to deliver. With a nice visual date picker, the UI for picking a month or a week is probably quite different from the UI for picking a day, which in turn would be different from the UI for picking a time, or a date and time together. For instance, a day picker would probably only show you month or possibly a 2 or 3 months at a time, whereas that would not make sense for a month picker. Just having a type-in box with no visual picker would result in a control that would likely not be usable for the kinds of sites where you enter dates. Regards, Maciej
Re: [whatwg] Input type for phone numbers
On Tue, Mar 31, 2009 at 12:58 PM, Maciej Stachowiak m...@apple.com wrote: It depends on the quality of implementation you want to deliver. With a nice visual date picker, the UI for picking a month or a week is probably quite different from the UI for picking a day, which in turn would be different from the UI for picking a time, or a date and time together. For instance, a day picker would probably only show you month or possibly a 2 or 3 months at a time, whereas that would not make sense for a month picker. Just having a type-in box with no visual picker would result in a control that would likely not be usable for the kinds of sites where you enter dates. Have you looked at Opera's implementation? it supports all these various types, and is not too bad. Regardless, from the browser's perspective, these are all pretty equally easy, since the expectation is that each platform just invokes a system date picking object when the user clicks on the control to request one... But we're getting off track. PK
Re: [whatwg] Input type for phone numbers
On 31.3.2009, at 10:02, James Graham wrote: FWIW I would imagine that the most useful aspect of input type=tel or whatever would not be validation (because validation is hard) but would be better integration on mobile devices e.g. making the default action of the keypad be number keys, making phone numbers from the contacts list available, etc. (these were both pointed out already). Therefore whilst I totally recommend this feature be postponed for HTML6, I think it makes a lot of sense and that problems with validation are a red herring. This is a fairly important feature for browsers running on mobile phones. Something like this is likely to be implemented whether or not it is in the specification. I would prefer it it to be specified for obvious interoperability reasons. Validation is indeed a complete red herring, this is about input methods. antti
Re: [whatwg] Input type for phone numbers
On Tue, 31 Mar 2009 22:19:35 +0200, Antti Koivisto an...@apple.com wrote: Validation is indeed a complete red herring, this is about input methods. In that case it might be better to re-introduce the inputmode= attribute for this purpose. The specific type= attribute values actually ensure (when implemented) that some normalized form of the data goes to the server. If that is not a goal here I'm not sure we should introduce a type= attribute value for it. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Input type for phone numbers
On 31.3.2009, at 13:35, Anne van Kesteren wrote: On Tue, 31 Mar 2009 22:19:35 +0200, Antti Koivisto an...@apple.com wrote: Validation is indeed a complete red herring, this is about input methods. In that case it might be better to re-introduce the inputmode= attribute for this purpose. The specific type= attribute values actually ensure (when implemented) that some normalized form of the data goes to the server. If that is not a goal here I'm not sure we should introduce a type= attribute value for it. Phone number specific input method presumably won't allow entering values that are not phone numbers so a reasonable implementation satisfies your normalization requirement. However validation is not the reason why this is an interesting feature, the ability to provide better user interface is. I don't see how this is different from the existing type attribute values like email. Could you explain the difference? antti -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Input type for phone numbers
My strong sense is that the canonical UI for choosing points in a metric space (time, as typically viewed, being a one dimensional Euclidean metric space) has not yet been built. Using a pointer like a mouse together with timing delays between mouseup and mousedown together with 3D accelerometer data probably would give us the ability to choose any date or real number (bounded above and below by some number), any of a finite number of words from a vocabulary, any coordinate from a 2D, 3D or 4D space, or any node (like a URL) from within the topology of a finite directed graph more quickly than equivalent data could be entered from a keyboard. This includes pretty much all input widgets. What all these spaces share in common vis a vis the human is the conceptual pegs that people assign as landmarks in those navigational realms. In the case of time we have seconds, minutes, days, months, millenia as pegs; in the real numbers, we have powers of ten; in color space we have trichromatic and opponent processes overlaid with cultural nomenclature; in the daily drive to work each day, we have traffic signals, cows etc.; on the globe we have latitude and longitude as well as the more salient pegs of nations, provinces, cities. There is a lot of data that can be leveraged from the speed, acceleration, and position of a mousedrag, even without accelerometers around. The way to choose the feedback relevant to optimizing a user's input may ultimately have a universal solution that works across input domains, but which researchers just haven't started yet to look for. Standardization may be premature. DD - Original Message - From: Maciej Stachowiak To: Peter Kasting Cc: whatwg@lists.whatwg.org ; Boris Zbarsky Sent: Tuesday, March 31, 2009 3:58 PM Subject: Re: [whatwg] Input type for phone numbers On Mar 31, 2009, at 10:25 AM, Peter Kasting wrote: On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that entering a week is pretty rare, though. ;) As someone working on supporting new input types in WebKit: Supporting any one form of date is nontrivial, but supporting the rest after you support the first _is_ trivial. So while I'm on the week is not that useful bandwagon, it'll be simple to support once date is supported. It depends on the quality of implementation you want to deliver. With a nice visual date picker, the UI for picking a month or a week is probably quite different from the UI for picking a day, which in turn would be different from the UI for picking a time, or a date and time together. For instance, a day picker would probably only show you month or possibly a 2 or 3 months at a time, whereas that would not make sense for a month picker. Just having a type-in box with no visual picker would result in a control that would likely not be usable for the kinds of sites where you enter dates. Regards, Maciej
Re: [whatwg] Input type for phone numbers
On Mar 31, 2009, at 1:35 PM, Anne van Kesteren wrote: On Tue, 31 Mar 2009 22:19:35 +0200, Antti Koivisto an...@apple.com wrote: Validation is indeed a complete red herring, this is about input methods. In that case it might be better to re-introduce the inputmode= attribute for this purpose. The specific type= attribute values actually ensure (when implemented) that some normalized form of the data goes to the server. If that is not a goal here I'm not sure we should introduce a type= attribute value for it. I don't think it's right to think of type= as only, or even primarily, about validation to a specific format. input type=text, input type=password and input type=search all allow the same set of values, and differ only in the UI. input type=button and input type=image have the same effect, but different presentation. Checkboxes and radio buttons only indicate whether they are on or off, but differ crucially in UI. On the other hand, the server side can never count on client-side validation, since it may be sent malformed requests by older or non- browser clients. So the main value-add for many kinds of specialized input fields is the user interface, not format validation. The idea that type= has anything at all to do with client-side validation is a new idea in HTML5 and not something that applies to every kind of control. I think inputmode= is not relevant here. Popping up a specialized control that lets you pick a phone number from your address book is not a specialized keyboard or input method, it's a different control. So in conclusion, whenever a control for entering phone numbers is added, it should be via type=, not inputmode=. Regards, Maciej
Re: [whatwg] Worker feedback
On Wed, Apr 1, 2009 at 7:27 AM, Drew Wilson atwil...@google.com wrote: So, the first argument against cookie races was this is the way the web works now - if we introduce cookie races, we'll break the web. When this was proven to be incorrect (IE does not enforce exclusive access to cookies), the argument has now morphed to the web is breaking right now and nobody notices, which is more an article of faith than anything else. We know for sure it's possible to write scripts with racy behaviour, so the question is whether this ever occurs in the wild. You're claiming it does not, and I'm questioning whether you really have that data. I agree that designing cookie races is not a good idea. If we could go back in time, we might design a better API for cookies that didn't introduce race conditions. However, given where we are today, I'd say that sacrificing performance in the form of preventing parallel network calls/script execution in order to provide theoretical correctness for an API that is already quite happily race-y is not a good tradeoff. We don't know how much (if any) performance must be sacrificed, because no-one's tried to implement parallel cookie access with serializability guarantees. So I don't think we can say what the correct tradeoff is. In this case, I think the spec should describe the current implementation of cookies, warts and all. You mean IE and Chrome's implementation, I presume, since Firefox and Safari do not allow cookies to be modified during script execution AFAIK. Do we know exactly what IE7, IE8 and Chrome guarantee around parallel cookie access? 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]
[whatwg] Notifications UI for Persistent Workers
Hi WHATWG,
There have been discussions in the past about building notifications
(toasts) as a way for workers, especially persistent workers, to have a
form of UI. It's not spec'd in HTML5 at the moment, but I'm currently
working on an implementation in Chromium and wanted to get broader feedback
on the design we're working from. Here's our design doc. Thoughts?
Thanks,
-John
*Notifications for Persistent Workers*
*Background*
Persistent workers run scripts in the background, potentially in the absence
of open tabs connected to that worker script. This document describes a way
for these scripts to interact with the user through notifications: toasts
which appear on the user's desktop, outside of any tab.
QUESTION: Dedicated and shared workers, though able to interact with the
user through open tabs, also have compelling use cases where desktop UI
serves better than in-tab UI (e.g., Calendar alerts and New Email
notifications). Should this be extended to all such contexts? There are
implementation benefits to limiting notifications to shared workers
(avoiding duplication of notifications, etc.), but this may present a burden
to developers who wish to incorporate notifications in a webapp with minimal
effort. This document will limit itself to the application in shared
persistent workers.
*Capabilities*
User-agents may implement desktop notifications in different ways. The
strongest form provides full HTML display, where a URL is loaded and
presented in a small desktop balloon. In some environments structured
notifications (icon, title, text) are more canonical, e.g., Ubuntu's
libnotify and Growl.
In addition, HTML5 browsers which do not have a desktop in the traditional
sense, such as those on a mobile device, may wish to implement notifications
using text-only, text-plus-icon, or other structured notifications. For
example, Palm OS offers structured notifications on mobile devices, but not
full HTML. For greatest compatibility, the spec should provide alternatives
for these different environments.
When HTML notifications are used, they should act like normal browser
windows, including stylesheets and script functionality, with the exception
that links causing a location change should always open in a new tab.
*Proposed Specification*
SharedWorkerGlobalScope {
...
readonly attribute Notifications notifications;
};
interface Notifications {
NotificationObject createHTMLNotification(URL url);
NotificationObject createNotification(StructuredNotification n);
/* see Permissions below */
readonly attribute boolean trusted;
void requestTrust();
};
In the Notifications interface, user agents may leave undefined
createHTMLNotification() if they do not support HTML notifications.
[nointerface] interface StructuredNotification {
DOMString title;
DOMString /* URL */ icon;
DOMString body;
/* ... perhaps other fields can be optional ... */
};
interface NotificationObject {
boolean show(); /* show (queue for display) the notification. throws on
repeat calls. */
boolean cancel(); /* close the notification if displayed; cancel it if not
yet */
attribute boolean sticky;
attribute EventListener ondisplay;
attribute EventListener onerror;
attribute EventListener onclose;
/* ... perhaps other events ... */
}
Applications' worker scripts can use standard normal capabilities-checking
techniques to choose which function to call, HTML or structured.
Notifications may be 'sticky', meaning the toast is shown until dismissed by
the user, but by default they are not sticky, and will be removed after a
period of time which is controlled by the user-agent and underlying desktop
based on its own display properties. A worker script may attempt to change
the stickiness before showing, although this change may not be successful if
not allowed by the environment (e.g., Ubuntu's libnotify does not support
sticky notifications at all).
Before showing a notification, the worker script can register for event
callbacks defined above. All callbacks are asynchronous.
- ondisplay: when the notification is actually shown to the user. If
it is queued for UI space limitations, this may be deferred. This event
allows scripts to control notification display intervals more precisely if
desired.
- onerror: if the notification cannot be shown for some reason, for
example if the URL provided generates an error response.
- onclose: when the notification is closed by the user or by the
notification provider. Non-sticky notifications may close themselves
automatically, thus the 'onclose' event should include an explicit
attribute which indicates if the user took an action to dismiss the
notification.
*Example*
if (notifications) {
var n;
if (typeof(notifications.createHTMLNotification) != undefined) {
n =
notifications.createHTMLNotification(/ui/event_starting?id=31415title=Team+Meetinglocation=Room+1200time=1700);
} else {
n =
Re: [whatwg] Worker feedback
On Tue, Mar 31, 2009 at 6:25 PM, Robert O'Callahan rob...@ocallahan.orgwrote: We know for sure it's possible to write scripts with racy behaviour, so the question is whether this ever occurs in the wild. You're claiming it does not, and I'm questioning whether you really have that data. I'm not claiming it *never* occurs, because in the vasty depths of the internet I suspect *anything* can be found. Also, my rhetorical powers aren't up to the task of constructing a negative proof :) We don't know how much (if any) performance must be sacrificed, because no-one's tried to implement parallel cookie access with serializability guarantees. So I don't think we can say what the correct tradeoff is. The spec as proposed states that script that accesses cookies cannot operate in parallel with network access on those same domains. The performance impact of something like this is pretty clear, IMO - we don't need to implement it and measure it to know it exists and in some situations could be significant. You mean IE and Chrome's implementation, I presume, since Firefox and Safari do not allow cookies to be modified during script execution AFAIK. I think the old spec language captured the intent quite well - document.cookie is a snapshot of an inherently racy state, which is the set of cookies that would be sent with a network call at that precise instant. Due to varying browser implementations, that state may be less racy on some browsers than on others, but the general model was one without guarantees. I understand the philosophy behind serializing access to shared state, and I agree with it in general. But I think we need to make an exception in the case of document.cookie based on current usage and expected performance impact (since it impacts our ability to parallelize network access and script execution). In this case, the burden of proof has to fall on those trying to change the spec - I think we need a compelling real-world argument why we should be making our browsers slower. The pragmatic part of my brain suggests that we're trying to solve a problem that exists in theory, but which doesn't actually happen in practice. Anyhow, at this point I think we're just going around in circles about this - I'm not sure that either of us are going to convince the other, so I'll shut up now and let others have the last word :) -atw
