[whatwg] Fwd: HTML 5 remarks on typo
-- Forwarded message -- From: Innovimax SARL innovi...@gmail.com Date: Fri, Apr 3, 2009 at 9:37 AM Subject: Re: HTML 5 remarks on typo To: wha...@whatwg.org Dear Here are some updated comments : good job most of the typo are now out == Some css properties are emphasized and other not == In 3.3.3.5. The dir attribute [[ CSS 'direction' and 'unicode-bidi' properties ]] are not emphasized as in 4.6.21 The bdo element [[ requirements by implementing the CSS unicode-bidi property. [CSS21] ]] == Choose between == initialize and initialise (DONE) absence and absense (DONE) authorize and authorise (DONE) behaviour and behavior (still one ) code point and codepoint (a lot of this one) invokation and invocation (DONE) You used en version for Localisation (with an S) (DONE) == Typo == s/appplies/applies/ (DONE) s/attribte/attribute/ (DONE) s/attributs/attributes/ (DONE) s/backgound/background/ (DONE) s/betwen/between/ (DONE) s/chacacters/characters/ (DONE) s/chosing/choosing/ (DONE) s/clipbroad/clipboard/ (DONE) s/befor /before / (DONE) s/conjuction/conjunction/ (REMOVED) s/corstructors/constructors/ (DONE) s/declaraing/declaring/ (DONE) s/decsendant/descendant/ (DONE) s/descendent/descendant/ (DONE) s/detais/details/ (DONE) s/ eding/ ending/ (DONE) s/errorneous/erroneous/ (DONE) s/explictly/explicitly/ (DONE) s/inteface/interface/ (DONE) s/musn't/mustn't/ (DONE) s/negotation/negotiation/ (DONE) s/numberic/numeric/ (DONE) s/occured/occurred/ (DONE) s/occurances/occurrences/ (STILL THERE) s/ofsets/offsets/ (DONE) s/ ommited/ omitted/ (DONE) s/particlar/particular/ (DONE) s/perferm/perform/ (DONE) s/preceeded/preceded/ (DONE) s/preceeding/preceding/ (DONE) s/pronounciations/pronunciations/ (DONE) s/asychronously/asynchronously/ (STILL THERE) Mohamed ZERGAOUI -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 € -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
I suppose that converting a string to uppercase is an action relevant only to cases where only ASCII character set is allowed in the argument, such as HTML element names. Within this restricted application domain, converting to uppercase has the same effect as converting to uppercase ASCII. IMHO, Chris
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
Well that could be a good answer indeed Now let's try to dig into the subtilties on Unicode For example what does the spec says about an attribute whose name is data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+212A ) ? Is it allowed ? If not why ? That's why I think everywhere in the spec, where ASCII is meant, it should be explicit. If not it would clash with a Unicode understanding IMHO Mohamed On Sat, Apr 4, 2009 at 10:06 AM, Kristof Zelechovski giecr...@stegny.2a.plwrote: I suppose that converting a string to uppercase is an action relevant only to cases where only ASCII character set is allowed in the argument, such as HTML element names. Within this restricted application domain, converting to uppercase has the same effect as converting to uppercase ASCII. IMHO, Chris -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
data-* attributes allow XML name characters and they are converted to lower case in HTML (ASCII, AIUI). BTW, editorial correction for 3.3.3.8 http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#embedd ing-custom-non-visible-data : should be its name contains no characters in the range (because an attribute contains its value). Chris
Re: [whatwg] Worker feedback
On Sat, Apr 4, 2009 at 11:17 AM, Jeremy Orlow jor...@google.com wrote: True serializability would imply that the HTTP request read and write are atomic. In other words, you'd have to keep a lock for the entirety of each HTTP request and couldn't do multiple in parallel. When I said there's no way to guarantee serializability, I guess I meant to qualify it with in practice. OK, I don't think anyone expects, wants, or has ever had that :-). After thinking about it for a bit, your suggestion of reading the cookies to send with an HTTP request is an atomic operation, and writing them as a result of an HTTP response is an atomic operation does seems like a pretty sensible compromise. It's what the spec says (the spec doesn't say anything about reading cookies when constructing an HTTP request, but that's probably just an oversight) and it's what I expected, so not really a compromise :-). The one thing I'd still be concerned about: localStorage separates storage space by origins. In other words, www.google.com cannot access localStorage values from google.com and visa versa. Cookies, on the other hand, have a much more complex scheme of access control. Coming up with an efficient and dead-lock-proof locking scheme might take some careful thought. I hope browser implementors can solve this internally. I think the main thing we have to watch out for in the spec is situations where a script can *synchronously* entangle browsing contexts that previously could not interfere with each other (i.e., that a browser could have assigned independent locks). (Setting document.domain might be a problem, for example, although I don't know enough about cookies to be sure.) Depending on exactly what you mean by a Web application, that's not really true. There are a variety of ways to exploit multicore parallelism within a window with the current set of specs, at least in principle. What else is there? (I believe you, I'm just interested in knowing what's out there.) In Gecko we're working on making HTML parsing happen in parallel with other activities (including script execution), and video decoding already does. I can imagine doing all graphics rendering in parallel with other tasks and being parallel internally too. Some aspects of layout can be parallelized internally and overlapped with script execution. Expensive Javascript compiler optimizations can be run in parallel with actual application work. Canvas3D can run GPU programs which are another form of parallelism (OK that's not exactly multicore parallelism unless you believe Intel). 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]
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
An attribute named data-K is allowed.
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
Well again it depends if you read the spec with an ASCII point of view or a Unicode point of view If I read carefully the spec, it is explicitly said that [[ 3.3.3.8 Embedding custom non-visible data A custom data attribute is an attribute whose name starts with the string data-, has at least one character after the hyphen, is XML-compatible, has no namespace, and contains no characters in the range U+0041 .. U+005A (LATIN CAPITAL LETTER A .. LATIN CAPITAL LETTER Z). ]] So This sequence is allowed data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+212A ) but the following one is NOT data-K (where we have this unicode sequence U+0064 U+0061 U+0074 U+0061 U+002D U+004B ) ? That's why I was asking this question in particular Mohamed On Sat, Apr 4, 2009 at 11:05 AM, Kristof Zelechovski giecr...@stegny.2a.plwrote: An attribute named data-K is allowed. -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
On Sat, 04 Apr 2009 10:06:55 +0200, Kristof Zelechovski giecr...@stegny.2a.pl wrote: I suppose that converting a string to uppercase is an action relevant only to cases where only ASCII character set is allowed in the argument, such as HTML element names. Within this restricted application domain, converting to uppercase has the same effect as converting to uppercase ASCII. That's not true. You can get Unicode characters in HTML element names. (You still want to lowercase only the ASCII characters though.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
Sorry, I don't see the answer to my question here ! On Sat, Apr 4, 2009 at 10:54 AM, Kristof Zelechovski giecr...@stegny.2a.plwrote: data-* attributes allow XML name characters and they are converted to lower case in HTML (ASCII, AIUI). BTW, editorial correction for 3.3.3.8http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#embedding-custom-non-visible-data: should be “*its name* contains no characters in the range” (because an attribute contains its value). Chris -- Innovimax SARL Consulting, Training XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Re: [whatwg] Fwd: Remarks on HTML5 (ASCII / Unicode)
It seems that getting the element name is not covered at all, it is a core interface, so definitions in the HTML specification do not apply. Chris
Re: [whatwg] How long should sessionStorage data persist?
On , Jeremy Orlow jor...@google.com wrote: I think this also applies: NOTE: The lifetime of a browsing context can be unrelated to the lifetime of the actual user agent process itself, as the user agent may support resuming sessions after a restart. Should that restore sessionStorage data ? Aren't you making sessionStorage much more complicated while the same use cases are covered by localStorage ? sessionStorage could be optimized to be just a volatile amount of data in memory, but these requirements require sessionStorage to implement the same disk IO heuristics, and a complex heuristic to decide when to erase sessionStorage completly. I vote for the data to be present just while a page is open or is restored from history or by going back. Thank you. -- João Eiras Core Technology developer
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
sounds like a security nightmare. we already have people complaining about reframing and spoofing and things.
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
On Sat, Apr 4, 2009 at 12:56 PM, timeless timel...@gmail.com wrote: sounds like a security nightmare. Can you be less vague? We've had a number of security people vet this already, so specific complaints would be very helpful. PK
Re: [whatwg] How long should sessionStorage data persist?
On Fri, Apr 3, 2009 at 5:29 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 3 Apr 2009, Darin Fisher wrote: In Chrome we also create a new browsing context when the user types a new URL into the location bar of an existing tab. So a user can't hit the back button after typing in a URL? The user can, and we then perform that navigation in the previous rendering process or if that process has since been closed, we create a new one for the navigation. We hold all of the state in the main process to facilitate this. The term browsing context in the spec basically corresponds to the session history exposed by window.history, and the outer Window object that the history is on. However, I believe that we should still restore the old sessionStorage when the user navigates back to the old URL just as we do for form state, scroll position, and other attributes normally associated with session history. That's basically what the spec says. OK, that makes sense. -Darin
