Re: [whatwg] Spec formats
On Mar 20, 2010, at 10:40 AM, Perry Smith wrote: Hi, I'm somewhat frustrated right now. I hope this email is not too caustic. The page at http://www.whatwg.org/specs/web-apps/current-work/ causes my Firefox to freeze for a minute or more. Eventually it recovers and it has all the pretty do-dads and things but it sure is painful to wait. And, this may be a Firefox problem but every time I hit a link, it freezes again as it recomputes (I guess) all the pretty do-dads and things. The pretty do-dads and things just are not worth it to me. Maybe there is something I can turn off but not until after the first wait period. You may find that the W3C Editor's Draft is more friendly to your browser: http://dev.w3.org/html5/spec/Overview.html. However, it does not include all the same content as the WHATWG copy. Regards, Maciej
Re: [whatwg] Spec formats
On Sun, 21 Mar 2010 04:23:40 -0300, Maciej Stachowiak m...@apple.com wrote: On Mar 20, 2010, at 10:40 AM, Perry Smith wrote: Hi, I'm somewhat frustrated right now. I hope this email is not too caustic. The page at http://www.whatwg.org/specs/web-apps/current-work/ causes my Firefox to freeze for a minute or more. Eventually it recovers and it has all the pretty do-dads and things but it sure is painful to wait. And, this may be a Firefox problem but every time I hit a link, it freezes again as it recomputes (I guess) all the pretty do-dads and things. The pretty do-dads and things just are not worth it to me. Maybe there is something I can turn off but not until after the first wait period. You may find that the W3C Editor's Draft is more friendly to your browser: http://dev.w3.org/html5/spec/Overview.html. However, it does not include all the same content as the WHATWG copy. Or, http://www.whatwg.org/specs/web-apps/current-work/?slow-browser might be sufficient. -- Michael
Re: [whatwg] Question about the application/x-www-form-urlencoded encoding algorithm
Hi, (2010/01/21 16:29), NARUSE, Yui wrote: 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? The spec is read that \x89\x41 in Shift_JIS should be encoded as %89%41. But current impplementations encode it as %89A. (I tested IE, Firefox, Opera, Chrome) So this should be a bug of the spec. -- NARUSE, Yui nar...@airemix.jp
