Re: [whatwg] about:blank synchronicity
On Jan 15, 2010, at 12:05, Henri Sivonen wrote: I've located a Mozilla test case that seems to depend on the event loop task mapping of data: URL loads (http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/chrome/test_bug533845.xul). This was most likely a misdiagnosis. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
[whatwg] script async and defer attributes questions and confusion
I'm trying to understand the async and defer attributes of the script tag. Unfortunately, since script execution is so intimately tied up with HTML parsing, section 4.3.1 is particularly hard to make sense of. I've got 3 questions, and 3 suggested clarifications to the spec. Thanks to anyone who can explain these! First, my questions. Are the following three statements correct? (I'm only concerned with script tags that actually appear in a document, not those inserted or emitted (via document.write()) by another script.): 1) Scripts without async or defer attributes are executed in the order in which they appear in the document. They are executed synchronously, which means that the parser must stop parsing the document while they run. 2) Scripts with the defer attribute, but without the async attribute are executed in the order in which they appear in the document, but their execution is deferred until the document has finished parsing. All these scripts will execute before DOMContentLoaded and the load event are fired. A deferred script can assume that the entire DOM tree has been constructed and is ready for manipulation--these scripts do not generally need to register an onload event handler. A call to document.write() within a deferred script will blow away the current document and begin a new one. 3) Scripts with the async attribute are executed as their script content becomes available over the network, with no guarantee that they will be executed in the order in which they appear in the document. The only guarantee is that these scripts will run before the DOMContentLoaded or load events are fired. Document parsing may or may not have completed when an async script is run, and a call to document.write() from an async script will have unpredictable behavior. Though the order of execution of async scripts is not predictable, the scripts will always appear to run in some serial order without concurrent execution. Next, I suggest that the following things in the spec be clarified: 1) After describing the async and defer attributes, the spec promises: The exact processing details for these attributes are described below. I take this to mean below, somewhere in section 4.3. In fact, however, the exact processing details are scattered throughout the spec, and understanding the attributes requires understanding section 9, I think. It would be nice to note this. 2) The last sentence of this paragraph: The second is a flag indicating whether the element was parser-inserted. Initially, script elements must have this flag unset. It is set by the HTML parser and is used to handle document.write() calls. made me think that the parser-inserted flag would only be set to true for scripts that were emitted through document.write() calls. That is, I thought that the parser-inserted flag would be set only in unusual cases rather than in the most common case. This section should explain the meaning of the parser-inserted flag. Instead it describes one of the purposes of the flag, but that purpose is different than the purpose for which it is used in this section. 3) The algorithm for running a script adds scripts to the list of scripts that will execute as soon as possible. And 9.2.6 spins the event loop until this list is empty. But I don't see anything in the spec that removes items from this list. That seems like an error in the spec, not just a confusing bit. Furthermore, the fact that this mechanism is specified as a list rather than as a set implies some kind of sequential execution of the scripts. But I don't think any sequence is meant here. David Flanagan
Re: [whatwg] Microdata feedback
On Mon, 18 Jan 2010 16:24:46 +0100, Jeremy Keith jer...@adactio.com wrote: Hixie wrote: Finally on vCard, the final part of the extraction algorithm goes to great trouble to guess what is the family name and what is the given name. This guess will be broken for transliterated east Asian names (CJKV that I know of, maybe others too). Just saying. Also, why is it important to explicitly add N: for organizations? This is intended to be compatible with Microformats vCard, which has these weird rules. If you think we should remove them, please at least first speak to Tantek and see why he thinks. The fn optimisation pattern isn't intended to catch 100% of cases, just the situation Firstname Lastname or Firstname Middlename Lastname. So if you just use fn (formatted name) and don't use n (name), the name will be extracted/guessed using the optimisation pattern. In cases where the pattern doesn't work (e.g. Anne van Kesteren, or east Asian names) you can still explicitly specify the family name and given name, over-riding the fn optimisation pattern. If you do this, you need to explicitly state this is the name (n) as well as the formatted name (fn). This is going to break badly whenever a template uses vCard microdata and its author either doesn't know the family name and given name (because the data was never collected) or doesn't even consider that the vcard conversion does this funny guesswork. If a social network site or similar does this, then Anne van Kesteren and Zhang Min (fictional name) will have their names messed up with no way of fixing it. At least I haven't seen a site which asks users to both fill in their full name and each component, which is what you need to get this right. Similarly, for organisations, you don't have to explicitly set n (name) if you apply both fn (formatted name) and org (organisation name) to a string. This time, the optimisation pattern assumes that the fn is the name of the organisation. Technically, the n property is *always* required but if you use either of those two optimisation patterns, the n is inferred from fn. If this is just a technical problem with some software requiring N to be present, would it be OK to just output an empty N like for organizations? -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Microdata feedback
On Mon, 18 Jan 2010 13:58:16 +0100, Ian Hickson i...@hixie.ch wrote: I'd like at some point to introduce some sort of semantic textContent that handles br, pre, bdo, dir=, img alt, del, space- collapsing, and newline elimination, but there hasn't been much enthusiasm around the idea, and it's not clear what else it would be good for. I've changed the example, at least, to have it work ok, and added a comment in the example about it. OK. Won't hold my breath for semantic textContent, but it sounds like a good solution. On Thu, 19 Nov 2009, Philip Jägenstedt wrote: In a (slightly edited) Jack Bauer example [1], Chrome, Firefox and presumably Safari has the meta elements moved to head. This will severely break script-based implementation of microdata, which are likely to be used for the time being until the DOM API is implemented natively. I can't see any workaround for this, so I suggest that meta simply not be used for microdata, preferably by making it non-conforming and removing it from the definitions/algorithms. This is a short-term problem that only affects scripted implementations that are shipped with the pages, so the workaround is simple: don't use meta and link. Any implementations outside of the page can just fix their parser to be HTML5-compatible. OK, fair enough. Thanks for all the other fixes, still reviewing the algorithm change... -- Philip Jägenstedt Core Developer Opera Software
[whatwg] Question about the application/x-www-form-urlencoded encoding algorithm
In 4.10.19.4 URL-encoded form data, The application/x-www-form-urlencoded encoding algorithm, it says: For each character in the entry's name and value, apply the following subsubsteps: If the character isn't in the range U+0020, U+002A, U+002D, U+002E, U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A then replace the character with a string formed as follows: Start with the empty string, and then, taking each byte of the character when expressed in the selected character encoding in turn, append to the string a U+0025 PERCENT SIGN character (%) followed by two characters in the ranges U+0030 DIGIT ZERO (0) to U+0039 DIGIT NINE (9) and U+0041 LATIN CAPITAL LETTER A to U+0046 LATIN CAPITAL LETTER F representing the hexadecimal value of the byte (zero-padded if necessary). If the character is a U+0020 SPACE character, replace it with a single U+002B PLUS SIGN character (+). This means, U+9670, encoded as ¥x89¥x41 in Shift_JIS, must be encoded as %89%41, and shouldn't be %89A? thanks, -- NARUSE, Yui nar...@airemix.jp
