- From: <bugzilla@jessica.w3.org>
- Date: Thu, 14 Mar 2013 23:12:06 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21292 Bug ID: 21292 Summary: HTML5 parser does inspect the namespace of elements on the stack of open elements Classification: Unclassified Product: HTML WG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: HTML5 spec Assignee: dave.null@w3.org Reporter: rafaelw@chromium.org QA Contact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-admin@w3.org, public-html-wg-issue-tracking@w3.org Given the ability to embed foreign content, this seems like a generic problem. Here's one instance: <body><table><tr><td><svg><td><foreignObject></td>Foo<foo> When <svg> is encountered, the insertion mode is left as "in cell", as it is when the </td> is encountered. This issue here is the </td>. The rules for "in cell" for </td> say "Pop elements from the stack of open elements stack until an element with the same tag name as the token has been popped from the stack." Maybe "tag name" implies localName and namespaceURI, but that's not how it's implemented anywhere. In Webkit and Gecko, the element it pops back to is <svg td>, and the continues parsing from there. This produces: | <html> | <head> | <body> | <table> | <tbody> | <tr> | <td> | <svg svg> | <svg td> | <svg foreignObject> | "Foo" | <svg foo> I'm actually not sure what the "right" output is here, but the above doesn't seem like a candidate. I can imagine: | <html> | <head> | <body> | "Foo" | <foo> | <table> | <tbody> | <tr> | <td> | <svg svg> | <svg td> | <svg foreignObject> Where the </td> clears back past the first (html) <td>, and the "Foo", and <foo> get lifted out of the table. I can also imagine: | <html> | <head> | <body> | <table> | <tbody> | <tr> | <td> | <svg svg> | <svg td> | <svg foreignObject> | "Foo" | <foo> Where the </td> is ignored (perhaps because we define "in scope" to not search past the <svg foreignObject> -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 14 March 2013 23:12:12 UTC