Subject: [xml2rfc] #396 (Version_3_cli_html): SVG in HTML does not display

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sun, 24 Feb 2019 21:14:54 -0000

#396: SVG in HTML does not display

 See attached XML and HTML. When displayed in browser, the SVG does not
 display.

-- 
-----------------------------------+--------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  defect                 |     Status:  new
 Priority:  medium                 |  Milestone:
Component:  Version_3_cli_html     |    Version:  2.19.*
 Keywords:                         |
-----------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Sun, 24 Feb 2019 22:55:42 -0000

Comment (by [email-masked]):

 As far as I can tell, this is what happens:

 In the provided XML, you declare the svg namespace in the <rfc> element,
 and then _again_ in the <svg> element.  The result is that in the html
 file, the browser quite correctly is presented with this in the HTML file,
 after the top-level namespace has been moved down to the relevant element
 (note the element tag <svg:svg> with an additional svg namespace
 declaration):

 {{{
 <svg:svg xmlns:svg="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" height="55" width="380"
 viewBox="0 0 380.0 55.0">
   <svg:path d="M5.5 34 v12 m 4 0 v-12" fill="none"
 stroke="black"></svg:path>
 ...
 }}}

 instead of this, which you'd get without the nested svg namespace
 declarations (and which works fine):

 {{{
 <svg xmlns="http://www.w3.org/2000/svg" height="55" width="380">
   <path d="M5.5 34 v12 m 4 0 v-12" fill="none" stroke="black"/>
 ...
 }}}

 And as you say, browsers seem not to be too happy about that.  But with
 the given input, the output is correct, as far as I can tell.  It's just
 not what the browser is ready to deal with.

 FWIW, I don't know why you'd ever add the svg namespace declaration to the
 <rfc> element.  I'm sure you'd want to use tools to generate standalone
 svg files, and they would then always include the namespace declaration in
 the <svg> element, no?

-- 
------------------------------------+--------------------
Resolution:                         |   Keywords:
------------------------------------+--------------------

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:1>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 05:17:08 -0000

> In the provided XML, you declare the svg namespace in the <rfc> element,
 and then _again_ in the <svg> element.

 Yes. I can change this, but the XML definitively is valid input.

 > The result is that in the html file, the browser quite correctly is
 presented with this in the HTML file, after the top-level namespace has
 been moved down to the relevant element (note the element tag <svg:svg>
 with an additional svg namespace declaration):

 Why is it moving these namespace declarations in the first place?

 The validators I tried did complain as well (FWIW, they are also
 complaining a lot about the CSS...

 > FWIW, I don't know why you'd ever add the svg namespace declaration to
 the <rfc> element. I'm sure you'd want to use tools to generate standalone
 svg files, and they would then always include the namespace declaration in
 the <svg> element, no?

 It wasn't intended. But then, the inoput *is* valid (it should never be
 cause breakage do have too many namespace declarations, as long in the end
 every element ends up in the namespace where it's supposed to be).

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:2>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 05:21:45 -0000

So the diff to the working HTML output is:

 {{{
 < <svg:svg xmlns:svg="http://www.w3.org/2000/svg"
 xmlns:xlink="http://www.w3.org/1999/xlink" height="55" width="380"
 viewBox="0 0 380.0 55.0">
 <           <svg:path d="M5.5 34 v12 m 4 0 v-12" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M370.5 34 v12 m 4 0 v-12" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M127 10 l-4 3 v-6 z" fill="none"
 stroke="black"></svg:path>
 <           <svg:a xlink:href="#translation_unit">
 <             <svg:rect x="60" y="30" height="20" width="130" rx="0"
 ry="0" fill="none" stroke="black"></svg:rect>
 <             <svg:text x="125" y="45" text-
 anchor="middle">translation_unit</svg:text>
 <           </svg:a>
 <           <svg:rect x="240" y="30" height="20" width="110" rx="0" ry="0"
 fill="none" stroke="black"></svg:rect>
 <           <svg:text x="295" y="45" text-
 anchor="middle">external_decl</svg:text>
 <           <svg:path d="M40 20 v10" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M210 30 q0 10 10 10" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M190 40 h50" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M30 40 q10 0 10 -10" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M40 20 q0 -10 10 -10 h150 q10 0 10 10 v10"
 fill="none" stroke="black"></svg:path>
 <           <svg:path d="M350 40 h20" fill="none"
 stroke="black"></svg:path>
 <           <svg:path d="M10 40 h50" fill="none"
 stroke="black"></svg:path>
 <         </svg:svg>
 ---
 > <svg xmlns="http://www.w3.org/2000/svg"
 >           <path d="M5.5 34 v12 m 4 0 v-12" fill="none"
 stroke="black"></path>
 >           <path d="M370.5 34 v12 m 4 0 v-12" fill="none"
 stroke="black"></path>
 >           <path d="M127 10 l-4 3 v-6 z" fill="none"
 stroke="black"></path>
 >           <a xlink:href="#translation_unit">
 >             <rect x="60" y="30" height="20" width="130" rx="0" ry="0"
 fill="none" stroke="black"></rect>
 >             <text x="125" y="45" text-
 anchor="middle">translation_unit</text>
 >           </a>
 >           <rect x="240" y="30" height="20" width="110" rx="0" ry="0"
 fill="none" stroke="black"></rect>
 >           <text x="295" y="45" text-anchor="middle">external_decl</text>
 >           <path d="M40 20 v10" fill="none" stroke="black"></path>
 >           <path d="M210 30 q0 10 10 10" fill="none"
 stroke="black"></path>
 >           <path d="M190 40 h50" fill="none" stroke="black"></path>
 >           <path d="M30 40 q10 0 10 -10" fill="none"
 stroke="black"></path>
 >           <path d="M40 20 q0 -10 10 -10 h150 q10 0 10 10 v10"
 fill="none" stroke="black"></path>
 >           <path d="M350 40 h20" fill="none" stroke="black"></path>
 >           <path d="M10 40 h50" fill="none" stroke="black"></path>
 >         </svg>

 }}}

 The problem is that xml2rfc apparently prefixes the HTML <svg> element
 with the XML namespace declaration from the source file, if present.
 That's IMHO a bug (HTML is not XML, and they are picky about the way
 namespace declarations for SVG are allowed).

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:3>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 05:37:07 -0000

FWIW, this might indicate that we should have a normalization step for
 namespace declarations in the prep stage (but I'm not yet sure about it).

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:4>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 07:51:59 -0000

> Why is it moving these namespace declarations in the first place?

 Because there's a namespace normalization step after the v2v3 conversion.
 You can avoid your XML going through the v2v3 conversion by setting
 version="3" on the <rfc> element.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:5>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 08:56:13 -0000

Indeed.

 So it's a problem in the v2-v3 namespace normalization. Why is there any
 anyway, given the fact that valid v2 documents do not use any namespaces
 in the first place?

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:6>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 08:57:12 -0000

#396: SVG in HTML does not display (depending on namespace decls)

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:7>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 11:41:47 -0000

There's no guarantees about what gets fed into the v2v3 converter.

 If the incoming XML is marked as version="3", then it goes around the
 converter.

 But if it's not so marked, it goes through the converter to guarantee that
 what's fed to the preptool and the formatters is v3 without any deprecated
 elements.  What goes into the v2v3 converter could thus be anything from
 100% v2, to an unholy mix of new v3 elements and deprecated v2 elements,
 to 100% v3 (but missing the version="3" attribute).  No way to tell ahead
 of time.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:8>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 11:47:56 -0000

Comment (by [email-masked]):

 >  What goes into the v2v3 converter could thus be anything from 100% v2,
 to an unholy mix of new v3 elements and deprecated v2 elements

 Cool, I wasn't aware of that.

 This still leaves the question why the namespace normalization creates
 something that the v3 backend can't process. That's a bug, right?

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:9>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 12:16:41 -0000

The v3 backend processes it just fine.  What comes out is actually exactly
 what you sent in, although with the namespace declaration re-arranged
 (moved from top to <svg> elemnt) as part of the final html serialization.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:10>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 12:22:38 -0000

Well, the input is valid rfcxml, the output is invalid HTML5. So I don't
 see how you can not consider this a bug...

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:11>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 12:45:14 -0000

I think the only way to avoid this kind of namespace bugs would be to
 reject input with namespace declarations in the root element, in that
 case.  Otherwise I'm afraid you could always design an input (like this
 one) that will make browsers happy, even if it is perfectly correct from
 an xml viewpoint.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:12>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 13:03:40 -0000

It's not the input that makes the browser unhappy, it's the output.

 In this case, just stripping the namespace decl on the root element
 suffices, right?

 I see that there can be more complex cases, but until proven wrong, I'll
 claim that they all can be handled in the code.

 FWIW, for now, the only place where xmlns declarations in HTML output are
 supposed to appear is on the SVG elements or it's descendants. That's
 relatively easy to enforce.

 rfc2629.xslt doesn't handle this explicitly yet, but I'm happy to draft
 code that does if you provide an example that you think is hard.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:13>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 13:10:07 -0000

Replying to [comment:13 julian.reschke@…]:

 > FWIW, for now, the only place where xmlns declarations in HTML output
 are supposed to appear is on the SVG elements or it's descendants. That's
 relatively easy to enforce.

 Not so.  There's also the XInclude case.  And for that case, it definitely
 makes editing
 easier not to have to provide the namespace for each <xi:include>.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:14>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 13:18:20 -0000

...in *HTML* output...

 There will be no XIncludes in HTML output, no?

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:15>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>

---

From: "xml2rfc issue tracker" <[email-masked]>
Date: Mon, 25 Feb 2019 13:33:38 -0000

> There will be no XIncludes in HTML output, no?

 Oh, sorry; quite right.

Ticket URL: <https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/396#comment:16>
xml2rfc <http://tools.ietf.org/tools/xml2rfc/>