This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 5815 - foreignObject in the SVG namespace should be scoping
Summary: foreignObject in the SVG namespace should be scoping
Status: VERIFIED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NoReply
Depends on:
Blocks:
 
Reported: 2008-06-27 11:59 UTC by Henri Sivonen
Modified: 2010-10-04 13:54 UTC (History)
3 users (show)

See Also:


Attachments

Description Henri Sivonen 2008-06-27 11:59:53 UTC
(This bug pertains to XXXSVG comments in the Editor's Draft.)

First consider:
<!DOCTYPE html><body>foo<math><mtext><i>baz</i></mtext><annotation-xml><svg><desc><b>eggs</b></desc><g><foreignObject><P>spam<TABLE><tr><td><img></td></table></foreignObject></g><g>quux</g></svg></annotation-xml></math>bar

This parses sanely to:
| <!DOCTYPE html>
| <html>
|   <head>
|   <body>
|     "foo"
|     <math math>
|       <math mtext>
|         <i>
|           "baz"
|       <math annotation-xml>
|         <svg svg>
|           <svg desc>
|             <b>
|               "eggs"
|           <svg g>
|             <svg foreignObject>
|               <p>
|                 "spam"
|               <table>
|                 <tbody>
|                   <tr>
|                     <td>
|                       <img>
|           <svg g>
|             "quux"
|     "bar"


Now consider:
<!DOCTYPE html><body><p>foo<math><mtext><i>baz</i></mtext><annotation-xml><svg><desc><b>eggs</b></desc><g><foreignObject><P>spam<TABLE><tr><td><img></td></table></foreignObject></g><g>quux</g></svg></annotation-xml></math>bar

This parses to:
#document
| <!DOCTYPE html>
| <html>
|   <head>
|   <body>
|     <p>
|       "foo"
|       <math math>
|         <math mtext>
|           <i>
|             "baz"
|         <math annotation-xml>
|           <svg svg>
|             <svg desc>
|               <b>
|                 "eggs"
|             <svg g>
|               <svg foreignObject>
|     <p>
|       "spam"
|     <table>
|       <tbody>
|         <tr>
|           <td>
|             <img>
|     <g>
|       "quux"
|     "bar"

This is badness. The reasonable way to fix is the make foreignObject scoping when it has been assigned to the SVG namespace. I know this violates a design axiom, but not making foreignObject scoping has too counter-intuitive consequences.
Comment 1 Henri Sivonen 2008-06-27 12:43:14 UTC
(In reply to comment #0)
> The reasonable way to fix is the make foreignObject scoping
> when it has been assigned to the SVG namespace. 

I deployed this fix at http://parsetree.validator.nu/ to allow experimentation with the effects of this change.
Comment 2 Ian 'Hixie' Hickson 2008-06-27 19:26:22 UTC
I don't know that it's that bad... do we want to allow nested paragraphs like that? The semantics seem dubious.
Comment 3 Henri Sivonen 2008-06-28 12:28:22 UTC
(In reply to comment #2)
> I don't know that it's that bad...

It's bad because it spectacularly fails to adhere to the principle of least surprise. It is reasonable to assume that you can put an SVG subtree anywhere that an <img> could go. It is also reasonable to assume that the kind of things you can do in a <td> you can also do in a <foreignObject>. Currently, it appears like this is the case for some things, but then if you change things a little bit, the parse tree becomes fundamentally different in a very rendering-relevant way.

> do we want to allow nested paragraphs like that? 

Yes. :-)

> The semantics seem dubious.

As far as I can tell, given how paragraphs have been defined since December, the semantics are the same with an explicit outer <p> or without. :-)

Anyway, I don't buy semantic arguments: The rule for where you can put an SVG subtree should be simple. The rule for what you can put in a foreignObject should be simple (and intuitively, it would be really weird not to be able to use <p> in there). The two rules should be composable without counter-intuitive consequences.
Comment 4 Ian 'Hixie' Hickson 2008-06-29 08:00:13 UTC
How about:

   <table>
     <tr>
       <td>
         <math> <mi> x
       <td>
          ...
   </table>

Should that <td> close the <mi> and <math> elements?
Comment 5 Henri Sivonen 2008-06-29 09:52:33 UTC
It probably should. The expectations for mi and foreignObject are different. The expectation (well, mine at least) for mi is that it takes inline/phrase-level content. The expectation for foregeignObject is that a whole subworld lives in there.

As for SVG desc, the expectations aren't so clear.
Comment 6 Ian 'Hixie' Hickson 2008-06-29 10:11:23 UTC
So in:
   <table>
    <td>
     <svg>
      <foreignObject>
    <td>

...you want the second <td> to not have any effect?
Comment 7 Henri Sivonen 2008-06-29 11:01:29 UTC
(In reply to comment #6)
> So in:
>    <table>
>     <td>
>      <svg>
>       <foreignObject>
>     <td>
> 
> ...you want the second <td> to not have any effect?

That's not what I want:
http://parsetree.validator.nu/?parser=html5&content=%3Ctable%3E%3Ctd%3E%3Csvg%3E%3CforeignObject%3E%3Ctd%3E%0D%0A

What I'm suggesting is making "have element in scope" sensitive to foreignObject in the SVG namespace. I am not suggesting changes to the "have element in table scope" variant.

Specifically, I am suggesting that the list in step 4 under 'have an element in scope' be amended with the item "foreignObject in the SVG namespace".

(Aside: It would be an editorial improvement to write the "have element in scope" and "have element in table scope" algorithms separately.)
Comment 8 Ian 'Hixie' Hickson 2008-06-29 21:22:41 UTC
Interesting. Ok, I'll look into it.
Comment 9 Ian 'Hixie' Hickson 2008-07-01 00:24:15 UTC
r1837; commented out in r1838.
Comment 10 Maciej Stachowiak 2010-03-14 13:14:46 UTC
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.