Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Geoffrey Garen]

> I'm afraid that bind regional setting to interface language is not
> correct. For example, I prefer the English language interface (it's
> easier to write bug reports, search in Google documentation), but I
> need the russian regional settings (number format, date format and
> time format) for input controls. Expected behaiour that regional
> settings would be inherited from OS settings.

My claim is that if you want English language with Russian regional settings 
then browsers must report “en-ru” in navigator.language.

My reasoning is that many website authors use navigator.language to infer 
locale. So, if navigator.language reports “en-us”, you will get US regional 
settings on many websites.

Geoff

Re: [whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Geoffrey Garen]

>> This question came up in WebKit because ECMA-402’s DefaultLocale()
>> incorporates both language and locale and, to avoid confusion, we
>> wanted navigator.language, HTTP Accept-Language, and ECMA-402
>> DefaultLocale() to agree with each other.
> 
> It confuses me why you would want to have those three to agree.

We want them to agree because old code has been written to infer locale based 
on navigator.language, while new code will be written to infer locale based on 
EMCA-402, and we don’t want a webpage to display two distinct localizations 
simply because two library authors adopted two distinct APIs.

> • navigator.language is the language of the interface
> • HTTP Accept-Language is the language of content

I don’t think this is correct.

As Anne points out later, these two values *should* agree with each other 
according to HTML.

> • ECMA-402 DefaultLocale() is the user's locale
> 
> To me, these seem like completely different things. For example, I am
> currently on a computer in Germany where LANG is de_DE.UTF-8, but my
> browser uses HTTP Accept-Language to display web sites in English.
> 
>> Alexey has raised the point that “English as spoken in Poland” /
>> “English with a Polish locale” is not a language, and is a potentially
>> surprising value. Therefore, it might risk breaking websites.
> 
> Do you have evidence for web sites being broken by this string?

No.

> 
>> On the other hand, “en-pl” is a syntactically valid BCP 47 language
>> tag, and it’s the only way to avoid incompatibility between code that
>> uses ECMA-402 and code that uses navigator.language and/or HTTP
>> Accept-Language.
> 
> What incompatibilities are there? I do not understand this.

Let’s say that my system is set up for English language with Polish locale. 
ECMA-402 APIs honors this setup. But navigator.language reports “en-us”.

Now I navigate to a news website with ads. The news website author uses 
navigator.language to infer my locale but the ad author uses ECMA-402. So, all 
the dates on the news stories display as MM/DD/YYY while all the dates on the 
ads display as DD/MM/. This is a bad experience. 

If navigator.language reported “en-pl”, all my dates would display as 
DD/MM/. This is a good experience.

Geoff

[whatwg] Should navigator.language and and/or HTTP Accept-Language include locale?

[Geoffrey Garen]

Hi folks.

Should navigator.language and/or HTTP Accept-Language include my locale in 
addition to my language — even if the combination is exotic?

For example, if I speak English but I like Polish number formatting, should 
navigator.language report “en-pl”?

This question came up in WebKit because ECMA-402’s DefaultLocale() incorporates 
both language and locale and, to avoid confusion, we wanted navigator.language, 
HTTP Accept-Language, and ECMA-402 DefaultLocale() to agree with each other.

Alexey has raised the point that “English as spoken in Poland” / “English with 
a Polish locale” is not a language, and is a potentially surprising value. 
Therefore, it might risk breaking websites.

On the other hand, “en-pl” is a syntactically valid BCP 47 language tag, and 
it’s the only way to avoid incompatibility between code that uses ECMA-402 and 
code that uses navigator.language and/or HTTP Accept-Language.

In researching this question, I discovered that lots of code uses 
navigator.language and/or HTTP Accept-Language to infer the user’s locale, 
despite the fact that language and locale are not equivalent. For example, the 
#1 search result for “infer user locale” is 
, which 
states, "since many applications need to know the locale of the user, common 
practice has used Accept-Language to determine this information”.

Regards,
Geoff

Re: [whatwg] WebIDL vs HTML5 storage changes

[Geoffrey Garen]

My instinct is that if the community decides it is just kind of  
weird, then it is a useful shorthand that we wouldn't lose anything  
from standardizing on.


It is *very* weird, and therefore not a useful shorthand.

In JavaScript, delete means remove this property / interface from  
this JavaScript object. I can't think of any context in which it  
means anything else.


For example, delete node.parentNode attempts to remove the  
parentNode property from node. It does not remove parentNode  
from the document or anything like that.


delete window attempts to remove the window property from the  
global object. It does not close the window or anything like that.


In other words, you can be certain that delete is a simple operation  
with a consistent side-effect.


As a JavaScript programmer, I would find it very difficult to reason  
about objects that might or might not change the behavior of the  
delete operator. One reason i would find it very difficult is that  
operator overloading does not exist in JavaScript at all, so to  
understand this one API, I would need to understand a vast corpus of  
programming language goobery that is not at all covered in any  
JavaScript manual. Another reason I would find it very difficult is  
that the overloaded meaning of delete here (remove persistent  
storage from disk) is far afield from the original meaning (remove  
interface from temporary object in memory). To give you an analogy,  
even in C++, where you're allowed to overload operator delete, if you  
overloaded operator delete to mean do not free this object's memory,  
but do delete the file it references from the file system, well,  
let's just say that your patch would not pass code review with any of  
your four reviewers :).


I am not sure if any JS decoration or collection libraries depend on  
the canonical behavior of operator delete, but if they do, I would  
hate for them all to have to ship with the asterisk, BEWARE: do NOT  
use this decoration / collection library with that one weird DOM  
object that interprets 'delete' to mean 'remove important data from  
the user's disk'. Oy!


Geoff

Re: [whatwg] ApplicationCache add/remove with invalid URLs

[Geoffrey Garen]

I think an exception should be thrown when ApplicationCache add/ 
remove is called with invalid URLs.


Can you be more specific about what you mean by invalid?

URL not found in the cache?

Malformed URL?

Something else?

Geoff

Re: [whatwg] Preventing nested click() calls

[Geoffrey Garen]

To me it just seems wrong to prevent this.  This is in theory no
different than a recursive call and just like recursion it can end up
in an infinite loop.


You're right, it is no different *in theory*. It is, however,  
different in practice. If we allow click() to re-enter itself, popular  
websites stop working.



 Having a limit seems OK since most JavaScript
engines already have a limit on the size of the call stack.


The concern here isn't implementation complexity -- it's web  
compatibility. A standard that breaks the web is no standard at all.


Geoff

[whatwg] Exceptions thrown by XMLHttpRequest.responseXML and XMLHttpRequest.responseText

[Geoffrey Garen]

Hi.

The current working draft of the XMLHttpRequest spec says the  
following about responseXML and responseText.


responseText:
If the state is not LOADING or DONE raise an INVALID_STATE_ERR  
exception and terminate these steps.


responseXML:
If the state is not DONE raise an INVALID_STATE_ERR exception and  
terminate these steps.


While implementing this specification in WebKit, we gathered the  
following pieces of data:


1. This specification breaks at least one AJAX library, used by  
greenfieldonline.com.


2. This specification does not match any shipping version of Safari or  
Firefox, which do not throw exceptions.


3. This specification does not match any shipping version of Internet  
Explorer, which throws exceptions in some of these conditions, but not  
all. (The specifics here are a little weird, so I'll leave them out.)


4. Generally speaking, throwing an exception, which aborts a program,  
is a much bigger compatibility risk than not throwing an exception.


Therefore, for WebKit, I've decided that the most compatible and least  
weird behavior is not to throw an exception when accessing  
responseText or responseXML. Rather, for responseText, return the  
empty string, and for responseXML, return null.


Would you be willing to consider editing the XMLHttpRequest spec to  
match this behavior?


Thanks,
Geoff

Re: [whatwg] Workers in HTML5 (was: postMessage apply(), pipe, etc.)

[Geoffrey Garen]

Since postMessage API is looking more an more like the Gears worker
messaging API (or better), can we go one step further and introduce
workers into the HTML5, defined as invisible windows with limited
capabilities:


Why call these windows at all? They seem to have no relationship  
physical windows, or the JavaScript window object.



WorkerWindow openWorker(in DOMString url);


Can I supply a URL to an HTML file here? Does the file load and parse  
as an HTML document? Is the document accessible to the worker?


Since the whole point of the worker is to do JavaScript work, should  
this string be a script instead of a URL?


How do I pass data to a worker?

Is there an API contract regarding synchronization and/or order of  
execution?



  // some events
  attribute EventListener onabort;
  attribute EventListener onload;
  attribute EventListener onunload;


Why these events?

When is a worker considered loaded? Unloaded? Aborted?

Thanks,
Geoff

Re: [whatwg] SQL storage and onunload

[Geoffrey Garen]

It seems to be a natural idea to save Web application state from an  
unload event handler. But is it guaranteed that client-side database  
API is still functional at this point? And if it is - can one queue  
up more statements and/or transactions from statement callbacks?


I see two options here:

1. Delay leaving the page indefinitely, until all outstanding database  
operations have completed.


2. Leave the page immediately, canceling all outstanding database  
operations.


Option #1 seems undesirable because it allows a malicious or poorly  
programmed website to hijack the browser. That's a pretty bad user  
experience -- one that the database API's asynchronous callbacks were  
specifically designed to avoid.


Option #2 is not ideal, but it's workable. A beforeunload event  
handler can detect unsaved changes and prompt the user to cancel the  
navigation and save. Once the save succeeds, the page can update its  
UI to indicate that navigation is OK.


So, I recommend option #2.

Geoff

On Feb 8, 2008, at 1:44 AM, Alexey Proskuryakov wrote:



 There needs to be some limits put on this, as otherwise a script  
could continue to use resources indefinitely after a browser window  
is closed. But I do not see where it is specified, explicitly or  
implicitly.


- WBR, Alexey Proskuryakov

Re: [whatwg] SQL API error handling

[Geoffrey Garen]

perhaps it would be prudent to change the spec to at least suggest  
that if a database becomes known to be corrupt, operations on all  
open handles to that database should start throwing  
INVALID_STATE_ERR exceptions.


I think this is already specified:
3. If transaction has been marked as bad, then raise an  
INVALID_STATE_ERR exception.


...

7. If the statement execution fails for some reason, transaction must  
be rolled back and marked as bad.


I think you can reasonably consider a statement on a corrupt database  
to have failed for some reason.


Geoff

Re: [whatwg] SQL API error handling

[Geoffrey Garen]

perhaps it would be prudent to change the spec to at least suggest  
that if a database becomes known to be corrupt, operations on  
all open handles to that database should start throwing  
INVALID_STATE_ERR exceptions.


I think this is already specified:
3. If transaction has been marked as bad, then raise an  
INVALID_STATE_ERR exception.

...
7. If the statement execution fails for some reason, transaction  
must be rolled back and marked as bad.


I think you can reasonably consider a statement on a corrupt  
database to have failed for some reason.


After all active transactions are cleared, there is no context that  
remembers that the database is corrupt, and the next statement to be  
run would actually attempt to be executed.


I suppose user agents can volunteer to remember this and  
automatically fail the next statement, but it's certainly not  
specified.


Are you proposing that, once a database has been corrupted, all  
transactions executed on it should fail, raising an INVALID_STATE_ERR  
exception, for all time?


Once all active transactions are cleared, there's no need to remember  
that the database was corrupt. The user agent should simply recover  
from the corruption in an implementation-defined way -- either by  
deleting the database, performing an error-recovering integrity check,  
asking the user to install cosmic ray shielding around the house, or  
something else.


Geoff

Re: [whatwg] SQL API error handling

[Geoffrey Garen]

It would be nice to have a way to indicate to the script There was  
a catastrophic event and we reset your database, assume you're  
starting over from scratch.


In general, I'm not sure how useful it is to know that you're  
starting over from scratch, since any database query needs to check  
its result. Presumably, an app's behavior in the no data case is the  
same regardless of *why* there's no data. 99% of the time the behavior  
will be to reload the data from a server.


More importantly, what constitutes a corrupt database, and how to  
recover from it, are serious implementation details. Some  
implementations may have error correction algorithms. Others may have  
backups they can restore. Others may have to wipe the database  
completely and start over. Still others may not be able to start  
anything. (For example, the storage medium might have gone bad, or  
been locked or disconnected.) So, imposing a start over from scratch  
requirement would hamper some implementations while requiring the  
impossible of others.


Geoff

Re: [whatwg] Compatibility problems with HTML5 Canvas spec.

[Geoffrey Garen]

We can certainly fix it, I'm just wondering what makes the most  
sense to do so.  Like I said, there's a patch sitting in our  
(Mozilla's) bugzilla that implements the spec-compatible behaviour.   
I'd be happy to fix it and relnote that it was fixed, while  
providing a simple workaround (which is basically calling  
beginPath() after calling fill/strokRect etc.)


I believe that fixing Firefox/Gecko to match the spec is the best  
solution. Safari 3 beta has already shipped with behavior that  
conforms to the spec, with substantial developer evangelism about this  
issue. (See, e.g., this recently published tech note: http://developer.apple.com/technotes/tn2007/tn2177.html#CANVAS) 
. Reversing the spec, and re-reversing our course to return to Safari  
2 behavior, would be terribly confusing. (I'm not even sure that it's  
possible at this late hour.)


Thanks,
Geoff

Re: [whatwg] XMLHttpRequest for missing file

[Geoffrey Garen]

Safari 3 for Windows raises this exception:


For the record, I've just now changed Safari (WebKit) to stop throwing  
that exception, which matches Safari 2.


Geoff

Re: [whatwg] A few editing suggestions for the HTML5 spec

[Geoffrey Garen]

Pressing a button when the user agent is in paused state should  
cause the
button to remain pressed until the user agent wakes up and  
execution of the

associated event handlers should be deferred.


So, if I had N buttons in a page, does that mean that all N could  
potentially end up in a pressed state?


Geoff

[whatwg] A few editing suggestions for the HTML5 spec

[Geoffrey Garen]

Hi folks.

I just read through the HTML5 spec for the first time. It looks  
great, and I appreciate all the hard work that everyone has done.


While reading through, I noticed a few edits that might improve  
clarity. I'm posting them here in a take 'em or leave 'em fashion  
-- take what you like, leave the rest.


Thanks,
Geoff

1.4
when not qualified to explicitly refer
when not qualified explicitly to refer
(split infinitive)

or the node itself is there is none
or the node itself if there is none
(typo)

The term root element, when not qualified to explicitly refer to the  
document's root element, means the furthest ancestor element node of  
whatever node is being discussed, or the node itself is there is  
none. When the node is a part of the document, then that is indeed  
the document's root element. However, if the node is not currently  
part of the document tree, the root element will be an orphaned node.


I found this paragraph's wording vague and hard to understand. I  
would suggest instead:


The term root element, unless qualified explicitly to refer to the  
document's root element, means the furthest ancestor element node of  
the node under discussion, or, if the node under discussion has no  
ancestor element nodes, the node itself. When a node is a part of a  
document, its root element is the document's root element. Otherwise,  
its root element is an orphaned node.


Some of the algorithms in this specification, for historical  
reasons, require the user agent to pause until some condition has  
been met. While a user agent is paused, it must ensure that no  
scripts execute (e.g. no event handlers, no timers, etc). User agents  
should remain responsive to user input while paused, however.


How should a user agent respond to user input that would cause an  
event handler to fire, like clicking on a button?


1.4.1

Generally speaking, authors are discouraged from trying to use XML  
on the Web, because XML has much stricter syntax rules than the  
HTML5 variant described above, and is relatively newer and  
therefore less mature.


Stricter syntax rules is often listed as an advantage of XML. If  
you're going to list it as a disadvantage, for credibility's sake, I  
think you should say something about why it's a disadvantage.


2.1.1

The referrer attribute must return either the URI of the page which  
navigated the browsing context to the current document (if any), or  
the empty string (if there is no such originating page, or if the UA  
has been configured not to report referrers).


It might help clarity to mention that a UA will intentionally hide  
referrers for security reasons (even the UA is not generally  
configured not to report referrers).


3.3.3.1

For instance, the script elements is allowed inside head elements
For instance, the script element is allowed inside the head element
(typo)


3.3.2

Text, embedded content, and elements that annotate the text without  
introducing structural grouping. For example: a, meter, img.


It would be nice if the examples followed the descriptions in order:  
[text], img, a.


3.12.4

By emphasising the first word, the statement implies that the kind  
of animal under discussion is in question (maybe someone is asserting  
that dogs are cute):
...implies that the kind of animal deserving to be called cute is in  
question...
(The first formation suggests that the speaker is questioning whether  
he/she is even talking about dogs and cats, not which one is cuter.)


8.2.1
do not have to actually create a DOM Document object
do not actually have to create a DOM Document object
(split infinitive)