From eireland at sybase.com Mon Feb 1 11:10:45 2010 From: eireland at sybase.com (Evan Ireland) Date: Mon, 1 Feb 2010 11:10:45 -0800 Subject: [imps] Implementations of synchronous Web Database API Message-ID: Hi, I've just joined this list, and I am curious to find out what implementations exist in desktop browsers of the synchronous Web Database API (openDatabaseSync etc), as it is defined in (or close to): http://dev.w3.org/html5/webdatabase Thanks. From ericu at chromium.org Mon Feb 1 14:23:25 2010 From: ericu at chromium.org (Eric Uhrhane) Date: Mon, 1 Feb 2010 14:23:25 -0800 Subject: [imps] Implementations of synchronous Web Database API In-Reply-To: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> References: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> Message-ID: <44b058fe1002011423h21d9b846j44a15aaec24417e6@mail.gmail.com> I've done a bunch of restructuring to WebKit to support DB access from workers. I've got a bit more work to do on thread safety before I can put in the JSC bindings, but I've tested [but not yet checked in] V8 bindings. That's all for the async DB API, though; I'll start in on the sync API once I've got the async working. Eric ericu at chromium.org > On Mon, Feb 1, 2010 at 11:10 AM, Evan Ireland wrote: >> >> Hi, >> >> I've just joined this list, and I am curious to find out what >> implementations exist in desktop browsers of the synchronous >> Web Database API (openDatabaseSync etc), as it is defined in >> (or close to): >> >> http://dev.w3.org/html5/webdatabase >> >> Thanks. >> >> _______________________________________________ >> Implementors mailing list >> Implementors at lists.whatwg.org >> http://lists.whatwg.org/listinfo.cgi/implementors-whatwg.org > > From rjelling at microsoft.com Fri Feb 5 14:03:02 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Fri, 5 Feb 2010 22:03:02 +0000 Subject: [imps] Tree construction question Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> This list seems pretty quiet now; if there is a better list / forum to ask this, please advise. (Also, to avoid misinterpretation, I am not on the IE team and do not speak for the IE team's plans.) Section 9.2.5.10 of the latest version of the spec contains this text under the rule for the "a" start tag: In the non-conforming stream ab
x, the first a element would be closed upon seeing the second one, and the "x" character would be inside a link to "b", not to "a". This is despite the fact that the outer a element is not in table scope (meaning that a regular end tag at the start of the table wouldn't close the outer a element). This is consistent with the behavior when feeding this example to http://james.html5.org/parsetree.html which outputs: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |a href="b" |#text: x My personal implementation delivers identical results, and my reading of the spec is that this is compliant output given the definition of tree construction -- the second tag gets foster parented under the first tag, because the first tag is selected as the foster parent element when the second tag is encountered. Of course, it is not actually HTML-compliant output, because of nested tags, which are invalid. So it appears that the HTML 5 tree construction algorithm produces invalid HTML in the case of this non-compliant input. IE gets it even worse, but Firefox seems to get it more correct: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |#text: x Is this known? Already planned to be fixed? Or is this a known bug that will ship? My apologies if this example has already been discussed; pointers on finding that earlier discussion will help me learn to fish. Thanks, Rob Jellinghaus Microsoft Technical Strategy Incubation -------------- next part -------------- An HTML attachment was scrubbed... URL: From annevk at opera.com Fri Feb 5 14:22:16 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 05 Feb 2010 23:22:16 +0100 Subject: [imps] Tree construction question In-Reply-To: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus wrote: > Is this known? Already planned to be fixed? Or is this a known bug > that will ship? > > My apologies if this example has already been discussed; pointers on > finding that earlier discussion will help me learn to fish. The idea of the parsing algorithm is not that any input yields a valid output. It just gives back a tree. Whether that tree is conforming is orthogonal. A simple example of this would be unknown elements not being removed (or transformed). -- Anne van Kesteren http://annevankesteren.nl/ From jonas at sicking.cc Fri Feb 5 14:37:31 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Fri, 5 Feb 2010 14:37:31 -0800 Subject: [imps] Tree construction question In-Reply-To: References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: > On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus > wrote: >> >> Is this known? ?Already planned to be fixed? ?Or is this a known bug that >> will ship? >> >> My apologies if this example has already been discussed; pointers on >> finding that earlier discussion will help me learn to fish. > > The idea of the parsing algorithm is not that any input yields a valid > output. It just gives back a tree. Whether that tree is conforming is > orthogonal. A simple example of this would be unknown elements not being > removed (or transformed). Also note that Firefox does not yet by default attempt to implement the HTML5 parsing algorithm. We still use the parser we've used since Firefox 1.0. Back in the days this parser indeed tried to always output a valid HTML DOM. This idea was eventually abandoned because it turned out not to be practical and just caused more confusion and trouble than it helped anyone. So even this parser can these days output invalid DOM trees. However with Firefox 3.6 there is a not-yet-finished alternative parser that implements the HTML5 algorithm. If you go to "about:config" and flip the "html5.enable" pref to true you should see a result very much like what the HTML5 spec states. We expect to ship this as the default parser for the next release of firefox if all goes well. / Jonas From rjelling at microsoft.com Fri Feb 5 16:14:14 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Sat, 6 Feb 2010 00:14:14 +0000 Subject: [imps] Tree construction question In-Reply-To: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365EFD62@TK5EX14MBXC138.redmond.corp.microsoft.com> On Fri, Feb 5, 2010 at 2:38 PM, Jonas Sicking wrote: >On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: >> The idea of the parsing algorithm is not that any input yields a valid >> output. It just gives back a tree. Whether that tree is conforming is >> orthogonal. A simple example of this would be unknown elements not being >> removed (or transformed). > >Also note that Firefox does not yet by default attempt to implement >the HTML5 parsing algorithm. We still use the parser we've used since >Firefox 1.0. Back in the days this parser indeed tried to always >output a valid HTML DOM. This idea was eventually abandoned because it >turned out not to be practical and just caused more confusion and >trouble than it helped anyone. So even this parser can these days >output invalid DOM trees. Thanks, Anne and Jonas. Good to know the impossible is not necessary :-) It would be helpful if the HTML 5 spec added a sentence to that non-normative paragraph, explicitly stating the output of that example, and its anticipated noncompliance. That would head off future confusion. Cheers! Rob Jellinghaus Microsoft Technical Strategy Incubation From xz911jp at yahoo.co.jp Tue Feb 16 06:25:29 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Tue, 16 Feb 2010 23:25:29 +0900 Subject: [imps] Question about body.onload Message-ID: <4B7AAAD9.8000204@yahoo.co.jp> Dear all Nice to meet you. My name is Zheng Xu, a new face on this ML. I have question about when should user agent fire the body.onload event. Would you like give me some answer or hint? 1. When should body.onload event fired. I have investigated in HTML5 and find following description in "4.8.7 The video element". "The user agent finishes fetching the entire media resource" Is this the definition of body.onload? Based on the above definition, I think that body.onload should be fired when whole data be complete fetched from network. (For example, should be fired before fetched image data is complete decoded.) Am I correct? 2. If body.onload is defined as above, why "delay the load event" is defined again? 3. What element may "delay the load event"? What (type of) elements may (should) "delay the load event" supposed by HTML5? Sincerely, -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ From annevk at opera.com Fri Feb 19 05:42:46 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 19 Feb 2010 14:42:46 +0100 Subject: [imps] Question about body.onload In-Reply-To: <4B7AAAD9.8000204@yahoo.co.jp> References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo wrote: > I have question about when should user agent fire the body.onload event. > Would you like give me some answer or hint? > > 1. When should body.onload event fired. > I have investigated in HTML5 and find following description in "4.8.7 > The video element". > "The user agent finishes fetching the entire media resource" > Is this the definition of body.onload? No. The load event is dispatched after parsing, when nothing in the document "delays the load event". See: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > Based on the above definition, I think that body.onload should be fired > when whole data be complete fetched from network. > (For example, should be fired before fetched image data is > complete decoded.) > Am I correct? It may be fired before, but dimensions have to be known. > 2. If body.onload is defined as above, why "delay the load event" is > defined again? You were not looking at the body load event. > 3. What element may "delay the load event"? > What (type of) elements may (should) "delay the load event" supposed > by HTML5? If you click on the definition in http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event it should give you a list with everything that references it. -- Anne van Kesteren http://annevankesteren.nl/ From xz911jp at yahoo.co.jp Tue Feb 23 13:46:50 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Wed, 24 Feb 2010 06:46:50 +0900 Subject: [imps] Question about body.onload In-Reply-To: References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: <4B844CCA.60305@yahoo.co.jp> Dear Kesteren Thans a lot for your reply. I have confirmed the link in following mail. I were reading the load event at following URL http://www.w3.org/TR/html5/semantics.html#the-body-element-0 http://www.w3.org/TR/html5/browsers.html#handler-window-onload herer is a link of onload to following Media Source. http://www.w3.org/TR/html5/video.html#event-load However, I found that the link of following page is unavialable. http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-window-onload Thank you again for the explanation. Sincerely, Anne van Kesteren ????????: > On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo > wrote: >> I have question about when should user agent fire the body.onload event. >> Would you like give me some answer or hint? >> >> 1. When should body.onload event fired. >> I have investigated in HTML5 and find following description in "4.8.7 >> The video element". >> "The user agent finishes fetching the entire media resource" >> Is this the definition of body.onload? > > No. > > The load event is dispatched after parsing, when nothing in the > document "delays the load event". See: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > > > >> Based on the above definition, I think that body.onload should be fired >> when whole data be complete fetched from network. >> (For example, should be fired before fetched image data is >> complete decoded.) >> Am I correct? > > It may be fired before, but dimensions have to be known. > > >> 2. If body.onload is defined as above, why "delay the load event" is >> defined again? > > You were not looking at the body load event. > > >> 3. What element may "delay the load event"? >> What (type of) elements may (should) "delay the load event" >> supposed by HTML5? > > If you click on the definition in > > http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event > > it should give you a list with everything that references it. > > -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ From eireland at sybase.com Mon Feb 1 11:10:45 2010 From: eireland at sybase.com (Evan Ireland) Date: Mon, 1 Feb 2010 11:10:45 -0800 Subject: [imps] Implementations of synchronous Web Database API Message-ID: Hi, I've just joined this list, and I am curious to find out what implementations exist in desktop browsers of the synchronous Web Database API (openDatabaseSync etc), as it is defined in (or close to): http://dev.w3.org/html5/webdatabase Thanks. From ericu at chromium.org Mon Feb 1 14:23:25 2010 From: ericu at chromium.org (Eric Uhrhane) Date: Mon, 1 Feb 2010 14:23:25 -0800 Subject: [imps] Implementations of synchronous Web Database API In-Reply-To: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> References: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> Message-ID: <44b058fe1002011423h21d9b846j44a15aaec24417e6@mail.gmail.com> I've done a bunch of restructuring to WebKit to support DB access from workers. I've got a bit more work to do on thread safety before I can put in the JSC bindings, but I've tested [but not yet checked in] V8 bindings. That's all for the async DB API, though; I'll start in on the sync API once I've got the async working. Eric ericu at chromium.org > On Mon, Feb 1, 2010 at 11:10 AM, Evan Ireland wrote: >> >> Hi, >> >> I've just joined this list, and I am curious to find out what >> implementations exist in desktop browsers of the synchronous >> Web Database API (openDatabaseSync etc), as it is defined in >> (or close to): >> >> http://dev.w3.org/html5/webdatabase >> >> Thanks. >> >> _______________________________________________ >> Implementors mailing list >> Implementors at lists.whatwg.org >> http://lists.whatwg.org/listinfo.cgi/implementors-whatwg.org > > From rjelling at microsoft.com Fri Feb 5 14:03:02 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Fri, 5 Feb 2010 22:03:02 +0000 Subject: [imps] Tree construction question Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> This list seems pretty quiet now; if there is a better list / forum to ask this, please advise. (Also, to avoid misinterpretation, I am not on the IE team and do not speak for the IE team's plans.) Section 9.2.5.10 of the latest version of the spec contains this text under the rule for the "a" start tag: In the non-conforming stream ab
x, the first a element would be closed upon seeing the second one, and the "x" character would be inside a link to "b", not to "a". This is despite the fact that the outer a element is not in table scope (meaning that a regular end tag at the start of the table wouldn't close the outer a element). This is consistent with the behavior when feeding this example to http://james.html5.org/parsetree.html which outputs: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |a href="b" |#text: x My personal implementation delivers identical results, and my reading of the spec is that this is compliant output given the definition of tree construction -- the second tag gets foster parented under the first tag, because the first tag is selected as the foster parent element when the second tag is encountered. Of course, it is not actually HTML-compliant output, because of nested tags, which are invalid. So it appears that the HTML 5 tree construction algorithm produces invalid HTML in the case of this non-compliant input. IE gets it even worse, but Firefox seems to get it more correct: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |#text: x Is this known? Already planned to be fixed? Or is this a known bug that will ship? My apologies if this example has already been discussed; pointers on finding that earlier discussion will help me learn to fish. Thanks, Rob Jellinghaus Microsoft Technical Strategy Incubation -------------- next part -------------- An HTML attachment was scrubbed... URL: From annevk at opera.com Fri Feb 5 14:22:16 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 05 Feb 2010 23:22:16 +0100 Subject: [imps] Tree construction question In-Reply-To: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus wrote: > Is this known? Already planned to be fixed? Or is this a known bug > that will ship? > > My apologies if this example has already been discussed; pointers on > finding that earlier discussion will help me learn to fish. The idea of the parsing algorithm is not that any input yields a valid output. It just gives back a tree. Whether that tree is conforming is orthogonal. A simple example of this would be unknown elements not being removed (or transformed). -- Anne van Kesteren http://annevankesteren.nl/ From jonas at sicking.cc Fri Feb 5 14:37:31 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Fri, 5 Feb 2010 14:37:31 -0800 Subject: [imps] Tree construction question In-Reply-To: References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: > On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus > wrote: >> >> Is this known? ?Already planned to be fixed? ?Or is this a known bug that >> will ship? >> >> My apologies if this example has already been discussed; pointers on >> finding that earlier discussion will help me learn to fish. > > The idea of the parsing algorithm is not that any input yields a valid > output. It just gives back a tree. Whether that tree is conforming is > orthogonal. A simple example of this would be unknown elements not being > removed (or transformed). Also note that Firefox does not yet by default attempt to implement the HTML5 parsing algorithm. We still use the parser we've used since Firefox 1.0. Back in the days this parser indeed tried to always output a valid HTML DOM. This idea was eventually abandoned because it turned out not to be practical and just caused more confusion and trouble than it helped anyone. So even this parser can these days output invalid DOM trees. However with Firefox 3.6 there is a not-yet-finished alternative parser that implements the HTML5 algorithm. If you go to "about:config" and flip the "html5.enable" pref to true you should see a result very much like what the HTML5 spec states. We expect to ship this as the default parser for the next release of firefox if all goes well. / Jonas From rjelling at microsoft.com Fri Feb 5 16:14:14 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Sat, 6 Feb 2010 00:14:14 +0000 Subject: [imps] Tree construction question In-Reply-To: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365EFD62@TK5EX14MBXC138.redmond.corp.microsoft.com> On Fri, Feb 5, 2010 at 2:38 PM, Jonas Sicking wrote: >On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: >> The idea of the parsing algorithm is not that any input yields a valid >> output. It just gives back a tree. Whether that tree is conforming is >> orthogonal. A simple example of this would be unknown elements not being >> removed (or transformed). > >Also note that Firefox does not yet by default attempt to implement >the HTML5 parsing algorithm. We still use the parser we've used since >Firefox 1.0. Back in the days this parser indeed tried to always >output a valid HTML DOM. This idea was eventually abandoned because it >turned out not to be practical and just caused more confusion and >trouble than it helped anyone. So even this parser can these days >output invalid DOM trees. Thanks, Anne and Jonas. Good to know the impossible is not necessary :-) It would be helpful if the HTML 5 spec added a sentence to that non-normative paragraph, explicitly stating the output of that example, and its anticipated noncompliance. That would head off future confusion. Cheers! Rob Jellinghaus Microsoft Technical Strategy Incubation From xz911jp at yahoo.co.jp Tue Feb 16 06:25:29 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Tue, 16 Feb 2010 23:25:29 +0900 Subject: [imps] Question about body.onload Message-ID: <4B7AAAD9.8000204@yahoo.co.jp> Dear all Nice to meet you. My name is Zheng Xu, a new face on this ML. I have question about when should user agent fire the body.onload event. Would you like give me some answer or hint? 1. When should body.onload event fired. I have investigated in HTML5 and find following description in "4.8.7 The video element". "The user agent finishes fetching the entire media resource" Is this the definition of body.onload? Based on the above definition, I think that body.onload should be fired when whole data be complete fetched from network. (For example, should be fired before fetched image data is complete decoded.) Am I correct? 2. If body.onload is defined as above, why "delay the load event" is defined again? 3. What element may "delay the load event"? What (type of) elements may (should) "delay the load event" supposed by HTML5? Sincerely, -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ From annevk at opera.com Fri Feb 19 05:42:46 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 19 Feb 2010 14:42:46 +0100 Subject: [imps] Question about body.onload In-Reply-To: <4B7AAAD9.8000204@yahoo.co.jp> References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo wrote: > I have question about when should user agent fire the body.onload event. > Would you like give me some answer or hint? > > 1. When should body.onload event fired. > I have investigated in HTML5 and find following description in "4.8.7 > The video element". > "The user agent finishes fetching the entire media resource" > Is this the definition of body.onload? No. The load event is dispatched after parsing, when nothing in the document "delays the load event". See: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > Based on the above definition, I think that body.onload should be fired > when whole data be complete fetched from network. > (For example, should be fired before fetched image data is > complete decoded.) > Am I correct? It may be fired before, but dimensions have to be known. > 2. If body.onload is defined as above, why "delay the load event" is > defined again? You were not looking at the body load event. > 3. What element may "delay the load event"? > What (type of) elements may (should) "delay the load event" supposed > by HTML5? If you click on the definition in http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event it should give you a list with everything that references it. -- Anne van Kesteren http://annevankesteren.nl/ From xz911jp at yahoo.co.jp Tue Feb 23 13:46:50 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Wed, 24 Feb 2010 06:46:50 +0900 Subject: [imps] Question about body.onload In-Reply-To: References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: <4B844CCA.60305@yahoo.co.jp> Dear Kesteren Thans a lot for your reply. I have confirmed the link in following mail. I were reading the load event at following URL http://www.w3.org/TR/html5/semantics.html#the-body-element-0 http://www.w3.org/TR/html5/browsers.html#handler-window-onload herer is a link of onload to following Media Source. http://www.w3.org/TR/html5/video.html#event-load However, I found that the link of following page is unavialable. http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-window-onload Thank you again for the explanation. Sincerely, Anne van Kesteren ????????: > On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo > wrote: >> I have question about when should user agent fire the body.onload event. >> Would you like give me some answer or hint? >> >> 1. When should body.onload event fired. >> I have investigated in HTML5 and find following description in "4.8.7 >> The video element". >> "The user agent finishes fetching the entire media resource" >> Is this the definition of body.onload? > > No. > > The load event is dispatched after parsing, when nothing in the > document "delays the load event". See: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > > > >> Based on the above definition, I think that body.onload should be fired >> when whole data be complete fetched from network. >> (For example, should be fired before fetched image data is >> complete decoded.) >> Am I correct? > > It may be fired before, but dimensions have to be known. > > >> 2. If body.onload is defined as above, why "delay the load event" is >> defined again? > > You were not looking at the body load event. > > >> 3. What element may "delay the load event"? >> What (type of) elements may (should) "delay the load event" >> supposed by HTML5? > > If you click on the definition in > > http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event > > it should give you a list with everything that references it. > > -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ From eireland at sybase.com Mon Feb 1 11:10:45 2010 From: eireland at sybase.com (Evan Ireland) Date: Mon, 1 Feb 2010 11:10:45 -0800 Subject: [imps] Implementations of synchronous Web Database API Message-ID: Hi, I've just joined this list, and I am curious to find out what implementations exist in desktop browsers of the synchronous Web Database API (openDatabaseSync etc), as it is defined in (or close to): http://dev.w3.org/html5/webdatabase Thanks. From ericu at chromium.org Mon Feb 1 14:23:25 2010 From: ericu at chromium.org (Eric Uhrhane) Date: Mon, 1 Feb 2010 14:23:25 -0800 Subject: [imps] Implementations of synchronous Web Database API In-Reply-To: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> References: <5dd9e5c51002011254h32c49bfeice9fa9d3ee89df53@mail.gmail.com> Message-ID: <44b058fe1002011423h21d9b846j44a15aaec24417e6@mail.gmail.com> I've done a bunch of restructuring to WebKit to support DB access from workers. I've got a bit more work to do on thread safety before I can put in the JSC bindings, but I've tested [but not yet checked in] V8 bindings. That's all for the async DB API, though; I'll start in on the sync API once I've got the async working. Eric ericu at chromium.org > On Mon, Feb 1, 2010 at 11:10 AM, Evan Ireland wrote: >> >> Hi, >> >> I've just joined this list, and I am curious to find out what >> implementations exist in desktop browsers of the synchronous >> Web Database API (openDatabaseSync etc), as it is defined in >> (or close to): >> >> http://dev.w3.org/html5/webdatabase >> >> Thanks. >> >> _______________________________________________ >> Implementors mailing list >> Implementors at lists.whatwg.org >> http://lists.whatwg.org/listinfo.cgi/implementors-whatwg.org > > From rjelling at microsoft.com Fri Feb 5 14:03:02 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Fri, 5 Feb 2010 22:03:02 +0000 Subject: [imps] Tree construction question Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> This list seems pretty quiet now; if there is a better list / forum to ask this, please advise. (Also, to avoid misinterpretation, I am not on the IE team and do not speak for the IE team's plans.) Section 9.2.5.10 of the latest version of the spec contains this text under the rule for the "a" start tag: In the non-conforming stream ab
x, the first a element would be closed upon seeing the second one, and the "x" character would be inside a link to "b", not to "a". This is despite the fact that the outer a element is not in table scope (meaning that a regular end tag at the start of the table wouldn't close the outer a element). This is consistent with the behavior when feeding this example to http://james.html5.org/parsetree.html which outputs: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |a href="b" |#text: x My personal implementation delivers identical results, and my reading of the spec is that this is compliant output given the definition of tree construction -- the second tag gets foster parented under the first tag, because the first tag is selected as the foster parent element when the second tag is encountered. Of course, it is not actually HTML-compliant output, because of nested tags, which are invalid. So it appears that the HTML 5 tree construction algorithm produces invalid HTML in the case of this non-compliant input. IE gets it even worse, but Firefox seems to get it more correct: |html |head |body |a href="a" |#text: a |a href="b" |#text: b |table |#text: x Is this known? Already planned to be fixed? Or is this a known bug that will ship? My apologies if this example has already been discussed; pointers on finding that earlier discussion will help me learn to fish. Thanks, Rob Jellinghaus Microsoft Technical Strategy Incubation -------------- next part -------------- An HTML attachment was scrubbed... URL: From annevk at opera.com Fri Feb 5 14:22:16 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 05 Feb 2010 23:22:16 +0100 Subject: [imps] Tree construction question In-Reply-To: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus wrote: > Is this known? Already planned to be fixed? Or is this a known bug > that will ship? > > My apologies if this example has already been discussed; pointers on > finding that earlier discussion will help me learn to fish. The idea of the parsing algorithm is not that any input yields a valid output. It just gives back a tree. Whether that tree is conforming is orthogonal. A simple example of this would be unknown elements not being removed (or transformed). -- Anne van Kesteren http://annevankesteren.nl/ From jonas at sicking.cc Fri Feb 5 14:37:31 2010 From: jonas at sicking.cc (Jonas Sicking) Date: Fri, 5 Feb 2010 14:37:31 -0800 Subject: [imps] Tree construction question In-Reply-To: References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> Message-ID: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: > On Fri, 05 Feb 2010 23:03:02 +0100, Rob Jellinghaus > wrote: >> >> Is this known? ?Already planned to be fixed? ?Or is this a known bug that >> will ship? >> >> My apologies if this example has already been discussed; pointers on >> finding that earlier discussion will help me learn to fish. > > The idea of the parsing algorithm is not that any input yields a valid > output. It just gives back a tree. Whether that tree is conforming is > orthogonal. A simple example of this would be unknown elements not being > removed (or transformed). Also note that Firefox does not yet by default attempt to implement the HTML5 parsing algorithm. We still use the parser we've used since Firefox 1.0. Back in the days this parser indeed tried to always output a valid HTML DOM. This idea was eventually abandoned because it turned out not to be practical and just caused more confusion and trouble than it helped anyone. So even this parser can these days output invalid DOM trees. However with Firefox 3.6 there is a not-yet-finished alternative parser that implements the HTML5 algorithm. If you go to "about:config" and flip the "html5.enable" pref to true you should see a result very much like what the HTML5 spec states. We expect to ship this as the default parser for the next release of firefox if all goes well. / Jonas From rjelling at microsoft.com Fri Feb 5 16:14:14 2010 From: rjelling at microsoft.com (Rob Jellinghaus) Date: Sat, 6 Feb 2010 00:14:14 +0000 Subject: [imps] Tree construction question In-Reply-To: <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> References: <9701F5AA905BF549AEF8EF6EF9D5A312365ED2CB@TK5EX14MBXC138.redmond.corp.microsoft.com> <63df84f1002051437of694aafh81b11636c30cc034@mail.gmail.com> Message-ID: <9701F5AA905BF549AEF8EF6EF9D5A312365EFD62@TK5EX14MBXC138.redmond.corp.microsoft.com> On Fri, Feb 5, 2010 at 2:38 PM, Jonas Sicking wrote: >On Fri, Feb 5, 2010 at 2:22 PM, Anne van Kesteren wrote: >> The idea of the parsing algorithm is not that any input yields a valid >> output. It just gives back a tree. Whether that tree is conforming is >> orthogonal. A simple example of this would be unknown elements not being >> removed (or transformed). > >Also note that Firefox does not yet by default attempt to implement >the HTML5 parsing algorithm. We still use the parser we've used since >Firefox 1.0. Back in the days this parser indeed tried to always >output a valid HTML DOM. This idea was eventually abandoned because it >turned out not to be practical and just caused more confusion and >trouble than it helped anyone. So even this parser can these days >output invalid DOM trees. Thanks, Anne and Jonas. Good to know the impossible is not necessary :-) It would be helpful if the HTML 5 spec added a sentence to that non-normative paragraph, explicitly stating the output of that example, and its anticipated noncompliance. That would head off future confusion. Cheers! Rob Jellinghaus Microsoft Technical Strategy Incubation From xz911jp at yahoo.co.jp Tue Feb 16 06:25:29 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Tue, 16 Feb 2010 23:25:29 +0900 Subject: [imps] Question about body.onload Message-ID: <4B7AAAD9.8000204@yahoo.co.jp> Dear all Nice to meet you. My name is Zheng Xu, a new face on this ML. I have question about when should user agent fire the body.onload event. Would you like give me some answer or hint? 1. When should body.onload event fired. I have investigated in HTML5 and find following description in "4.8.7 The video element". "The user agent finishes fetching the entire media resource" Is this the definition of body.onload? Based on the above definition, I think that body.onload should be fired when whole data be complete fetched from network. (For example, should be fired before fetched image data is complete decoded.) Am I correct? 2. If body.onload is defined as above, why "delay the load event" is defined again? 3. What element may "delay the load event"? What (type of) elements may (should) "delay the load event" supposed by HTML5? Sincerely, -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/ From annevk at opera.com Fri Feb 19 05:42:46 2010 From: annevk at opera.com (Anne van Kesteren) Date: Fri, 19 Feb 2010 14:42:46 +0100 Subject: [imps] Question about body.onload In-Reply-To: <4B7AAAD9.8000204@yahoo.co.jp> References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo wrote: > I have question about when should user agent fire the body.onload event. > Would you like give me some answer or hint? > > 1. When should body.onload event fired. > I have investigated in HTML5 and find following description in "4.8.7 > The video element". > "The user agent finishes fetching the entire media resource" > Is this the definition of body.onload? No. The load event is dispatched after parsing, when nothing in the document "delays the load event". See: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > Based on the above definition, I think that body.onload should be fired > when whole data be complete fetched from network. > (For example, should be fired before fetched image data is > complete decoded.) > Am I correct? It may be fired before, but dimensions have to be known. > 2. If body.onload is defined as above, why "delay the load event" is > defined again? You were not looking at the body load event. > 3. What element may "delay the load event"? > What (type of) elements may (should) "delay the load event" supposed > by HTML5? If you click on the definition in http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event it should give you a list with everything that references it. -- Anne van Kesteren http://annevankesteren.nl/ From xz911jp at yahoo.co.jp Tue Feb 23 13:46:50 2010 From: xz911jp at yahoo.co.jp (xuzheng_yahoo) Date: Wed, 24 Feb 2010 06:46:50 +0900 Subject: [imps] Question about body.onload In-Reply-To: References: <4B7AAAD9.8000204@yahoo.co.jp> Message-ID: <4B844CCA.60305@yahoo.co.jp> Dear Kesteren Thans a lot for your reply. I have confirmed the link in following mail. I were reading the load event at following URL http://www.w3.org/TR/html5/semantics.html#the-body-element-0 http://www.w3.org/TR/html5/browsers.html#handler-window-onload herer is a link of onload to following Media Source. http://www.w3.org/TR/html5/video.html#event-load However, I found that the link of following page is unavialable. http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#handler-window-onload Thank you again for the explanation. Sincerely, Anne van Kesteren ????????: > On Tue, 16 Feb 2010 15:25:29 +0100, xuzheng_yahoo > wrote: >> I have question about when should user agent fire the body.onload event. >> Would you like give me some answer or hint? >> >> 1. When should body.onload event fired. >> I have investigated in HTML5 and find following description in "4.8.7 >> The video element". >> "The user agent finishes fetching the entire media resource" >> Is this the definition of body.onload? > > No. > > The load event is dispatched after parsing, when nothing in the > document "delays the load event". See: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#the-end > > > >> Based on the above definition, I think that body.onload should be fired >> when whole data be complete fetched from network. >> (For example, should be fired before fetched image data is >> complete decoded.) >> Am I correct? > > It may be fired before, but dimensions have to be known. > > >> 2. If body.onload is defined as above, why "delay the load event" is >> defined again? > > You were not looking at the body load event. > > >> 3. What element may "delay the load event"? >> What (type of) elements may (should) "delay the load event" >> supposed by HTML5? > > If you click on the definition in > > http://www.whatwg.org/specs/web-apps/current-work/#delay-the-load-event > > it should give you a list with everything that references it. > > -------------------------------------- VANCOUVER 2010 Olympic News [Yahoo! Sports/sportsnavi] http://pr.mail.yahoo.co.jp/olympic/