moving well known HTML tags outside of SVG container
Reported by
m...@mail.ru,
Sep 7 2016
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0 Example URL: http://codepen.io/djFD/full/QKbvGa/ Steps to reproduce the problem: 1. Enter the URL given 2. Compare original markup with that we see 3. done What is the expected behavior? I suppose if browser does remove well known HTML tags (like <span />, <div />) from outside container, it have to do it only on a first nesting level. For the example above, the structure is <svg> <text> <unknown-tag> some contents <span>some spanned contents</span> </unknown-tag> </text> </svg> that is <span /> is nested inside of unknown tag, so IMHO all this tag contents have to be untouched, and not moved **partially** outside of SVG What went wrong? A part of content of unknown SVG tag is removed from it, either we move all unknown tag outside of SVG or leave it as is in full Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? No FF 48.0 Chrome version: 52.0.2743.116 (Developer Build) Built on Ubuntu , running on Ubuntu 16.04 (64-bit) Channel: n/a OS Version: Ubuntu 16.04 LTS Flash Version: Shockwave Flash 11.2 r202
,
Sep 7 2016
,
Sep 7 2016
to clarify a few unknown tag can be (and, in fact, it is, e.g. see https://material.angularjs.org/latest/api/directive/mdTooltip, now it is JS, tomorrow it can be some native library) implementing complex logic if its content handling, so it certainly knows how to handle **belonging to it** <span /> tag, how to render it properly. Removing a part of its contents we broke that component operation, that is a point
,
Sep 7 2016
This per the HTML parsing algorithm. You'll find it - together with the list of "well-known tags" at: https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inforeign If you want this to change, this is not the correct forum (https://github.com/whatwg/html would likely be that.)
,
Sep 7 2016
hmm, what ic: if "A start tag whose tag name is one of [...span...]" then: parse error. actions: 1) If the parser was originally created for the HTML fragment parsing algorithm, then act as described in the "any other start tag" entry below 2)Otherwise: Pop an element from the stack of open elements, and then keep popping more elements from the stack of open elements until the current node is a MathML text integration point, an HTML integration point, or an element in the HTML namespace. Now browser acts as in otherwise case. Could you confirm that "the parser was NOT originally created for the HTML fragment parsing algorithm" ?
,
Sep 7 2016
Yes, a parser that was created for the "HTML fragment parsing algorithm" would be what's used for example for Element.innerHTML (or outerHTML)
,
Sep 7 2016
so if other parsed is used (eg. specialized svg parser), then why you apply rules from https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inforeign to it?
,
Sep 7 2016
If you are parsing <svg> inline in HTML, that's the rules that apply. If you were to parse it as XML you get your expected results (but would need to take more care to get the namespaces right et.c.)
,
Sep 7 2016
If we are parsing svg inline, then it means we do use parser using "HTML fragment parsing algorithm", is not it? So why we behaving accordingly to 'otherwise' section? Anyway, wont fix so discussion is useless, as you have already taken a decision. But I asked that there https://github.com/whatwg/html/issues/1758, just FYI. Will see what these guys think of this |
|||
►
Sign in to add a comment |
|||
Comment 1 by m...@mail.ru
, Sep 7 2016