ParserIssues - Revision history

Hsivonen: /* Filed bugs */ and in "in foreign content" cause severe badness

2010-06-30T09:34:37Z

Filed bugs: </html> and </body> in "in foreign content" cause severe badness

← Older revision		Revision as of 09:34, 30 June 2010
Line 13:		Line 13:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 Insertion point for script@onload doesn't match Firefox		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 Insertion point for script@onload doesn't match Firefox
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985 How to parse </foo </bar>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985 How to parse </foo </bar>
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=10055 <nowiki></html> and </body> in "in foreign content" cause severe badness</nowiki>

	== Emails ==		== Emails ==

Hsivonen: Added a section of emails

2010-06-24T07:34:44Z

Added a section of emails

← Older revision		Revision as of 07:34, 24 June 2010
Line 13:		Line 13:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 Insertion point for script@onload doesn't match Firefox		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 Insertion point for script@onload doesn't match Firefox
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985 How to parse </foo </bar>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985 How to parse </foo </bar>

			== Emails ==

			* http://lists.whatwg.org/pipermail/implementors-whatwg.org/2010-June/000273.html Tokenizer spec switches the tokenizer state back to the data state right after the tree builder may have set it to the state that it needs to be switched to

	== Possible other issues ==		== Possible other issues ==

Abarth: /* Filed bugs */

2010-06-22T21:55:58Z

Filed bugs

← Older revision		Revision as of 21:55, 22 June 2010
Line 10:		Line 10:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9910 <nowiki><basefont> and <bgsound> should not break out of 'in head', should be treated as a void elements within <head></nowiki>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9910 <nowiki><basefont> and <bgsound> should not break out of 'in head', should be treated as a void elements within <head></nowiki>
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9983 Insertion point not saved for external scripts
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9984 Insertion point for script@onload doesn't match Firefox
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9985 How to parse </foo </bar>

	== Possible other issues ==		== Possible other issues ==

Jgraham at 08:08, 11 June 2010

2010-06-11T08:08:00Z

← Older revision		Revision as of 08:08, 11 June 2010
Line 9:		Line 9:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9910 <nowiki><basefont> and <bgsound> should not break out of 'in head', should be treated as a void elements within <head></nowiki>

	== Possible other issues ==		== Possible other issues ==

Hsivonen: /* Possible other issues */ CNN Money

2010-06-07T07:57:02Z

Possible other issues: CNN Money

← Older revision		Revision as of 07:57, 7 June 2010
Line 14:		Line 14:
	* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?		* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?
	* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.		* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.
			* Having <nowiki>-- ></nowiki> terminate comments breaks CNN Money https://bugzilla.mozilla.org/show_bug.cgi?id=570309

Hsivonen: /* Filed bugs */ Add new bug

2010-06-03T13:13:33Z

Filed bugs: Add new bug

← Older revision		Revision as of 13:13, 3 June 2010
Line 8:		Line 8:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <nowiki><p></nowiki>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <nowiki><p></nowiki>
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9843 <nowiki>Specced behavior for document.write("<link rel=stylesheet href=...><script>...</script>...") matches none of the top 4 engines</nowiki>

	== Possible other issues ==		== Possible other issues ==

Jgraham at 13:40, 2 June 2010

2010-06-02T13:40:52Z

← Older revision		Revision as of 13:40, 2 June 2010
Line 6:		Line 6:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <p>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <nowiki><p></nowiki>
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements

Jgraham at 13:40, 2 June 2010

2010-06-02T13:40:28Z

← Older revision		Revision as of 13:40, 2 June 2010
Line 7:		Line 7:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <p>		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <p>
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9831 Handling of EOF in foreignContent mode causes all tags to be popped of stack of open elements

	== Possible other issues ==		== Possible other issues ==

Hsivonen: /* Filed bugs */

2010-06-02T08:35:41Z

Filed bugs: <button> should be scoping for the purpose of implicitly closing <p>

← Older revision		Revision as of 08:35, 2 June 2010
Line 6:		Line 6:
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9580 Steps for handling end tags in the "in foreign" mode walk past the root node in the stack
	* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it		* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 Consider ignoring document.write() when IE ignores it if IE has a sane condition for ignoring it
			* http://www.w3.org/Bugs/Public/show_bug.cgi?id=9829 <button> should be scoping for the purpose of implicitly closing <p>

	== Possible other issues ==		== Possible other issues ==

Hsivonen: /* Possible other issues */ src, async, defer freezing

2010-05-31T10:57:26Z

Possible other issues: src, async, defer freezing

← Older revision		Revision as of 10:57, 31 May 2010
Line 10:		Line 10:

	* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?		* <nowiki><!DOCTYPE html><p><b><i><u></p> <p>X</nowiki> - should spaceness of character have any effect in InBody mode?
			* To enable the parser to decide whether a given script can call document.write() (for optimizing speculative parsing), it is necessary for the execution properties of the script as seen at start tag to remain constant until the end tag is parsed. This can be achieved by freezing the effective values for the src, defer and async attributes when a parser-inserted script is inserted to the tree. There's no non-racy way for a script to detect this when the script comes from the network stream, so this is OK. However, if the parser implements the same script execution logic for the network stream case and the document.write case in the same way, there is a non-racy way to detect the implementation details in the document.write() case. For an implementation that does speculative off-the-main-thread parsing, it is a developer time-consuming theoretical purity exercise to make the document.write() case correct per spec. OTOH, if the spec enshrines the freezing behavior as correct, it'll be a developer time-consuming theoretical purity exercise for implementations that don't have the kind of speculative parsing that needs the freezing.

ParserIssues - Revision history

Hsivonen: /* Filed bugs */ and in "in foreign content" cause severe badness

Hsivonen: Added a section of emails

Abarth: /* Filed bugs */

Jgraham at 08:08, 11 June 2010

Hsivonen: /* Possible other issues */ CNN Money

Hsivonen: /* Filed bugs */ Add new bug

Jgraham at 13:40, 2 June 2010

Jgraham at 13:40, 2 June 2010

Hsivonen: /* Filed bugs */ should be scoping for the purpose of implicitly closing

Hsivonen: /* Possible other issues */ src, async, defer freezing

Hsivonen: /* Filed bugs */