Re: template namespace attribute proposal
On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [Sorry for the reply-chain breaking; Gmail is being super weird about your message in particular, and won't let me reply directly to it. Some bug.] Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. - R. Niwa
Re: template namespace attribute proposal
On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. Possibly, dunno. I could go either way. Consistently resolving ambiguity in one direction could be simpler, but so could resolving in favor of the massively-more-likely one. Spec/impl complexity isn't really of concern here; impls would need an explicit list of elements/namespaces anyway. The spec could possible get away with a blanket statement, but that opens up the possibility of ambiguity, like image (which should clearly be SVG, despite the parser turning it into img for you). ~TJ
Re: template namespace attribute proposal
On Mar 18, 2015, at 2:19 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa rn...@apple.com wrote: On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. That may be true but the added complexity of title inside a template element being special (i.e. it’s treated as SVG instead of HTML) may not be worth the effort. HTML parser is already complex enough that using a simple rule of always falling back to HTML if element names are ambiguous may result in a better overall developer ergonomics. Possibly, dunno. I could go either way. Consistently resolving ambiguity in one direction could be simpler, but so could resolving in favor of the massively-more-likely one. Spec/impl complexity isn't really of concern here; impls would need an explicit list of elements/namespaces anyway. The spec could possible get away with a blanket statement, but that opens up the possibility of ambiguity, like image (which should clearly be SVG, despite the parser turning it into img for you). Implementation complexity isn’t my concern. Exception for title will be yet another random fact Web developer needs to be aware of. In general, we have too much tolerance for complexity and exceptions to rules on the Web platform. We should strive to make the Web platform as simple as possible so that humans can comprehend. - R. Niwa
Re: template namespace attribute proposal
On 2015/03/14 9:41, Karl Dubost wrote:
Tab,
The only conflicts in the namespaces are font
(deprecated in SVG2), script and style (harmonizing with HTML so
there's no difference), and a (attempting to harmonize API surface).
*If* I didn't make any mistakes
(I quickly did and didn't check everything.)
The intersection seems to be:
['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video',
'iframe', 'audio', 'font']
'track', 'canvas', 'source', 'video', 'iframe', and 'audio' will be
removed from the SVG2 spec (and SVG namespace). We want to allow them
directly in SVG but using HTML namespace.[1]
'font' is obsolete.
('image' might be another conflict since HTML autocorrects image to
img for compatibility reasons[1] but perhaps we could let image
refer to the SVG image in this context?)
[1] http://www.w3.org/2015/02/11-svg-minutes.html#item05
[2] https://html.spec.whatwg.org/multipage/syntax.html#parsing-main-inbody
Re: template namespace attribute proposal
Could you post the specific regression you ran into?
Specifically this was around platform development. Let's say I have my
developers (those that use my platform) all define their templates in
template/ tags. This is used for all components, including components
that are partials or are composable... One specific example is this:
my-graph domainx=0,100 width=200 domainy=0,100 height=100
my-line data=0,1 1,1 2,2 3,3 4,4 ... snip ... 100, 100/my-line
/my-graph
- the shadow root of `my-graph` has an svg element that contains it's
content (which also doesn't work well in SVG).
- the shadow root of `my-line` has a path element.
So we'd *hope* that you could define the templates for the above (roughly)
as follows:
template id=my-graph
svg
content/
/svg
/template
template id=my-line
path /
/template
This, of course, is broken all over the place.
1. Last I checked (6 months ago), content/ is an SVGElement, not an
HTMLContentElement.
2. template#my-line has a `content` with a single HTMLUnknownElement,
meaning trying to use it purely as a document fragment is broken.
3. As the platform author, there is no way for me to know that the
developer intends template#my-line to be an SVG fragment so I can at least
polyfill a solution for them automatically
As a platform author, a namespace attribute would enable me to easily
identify the developer's intent so I can polyfill the behavior before the
browser even supports it.
The idea of having template just work with SVG without some sort of
attribute like this seems like pie in the sky, and worse, it doesn't give
me an immediate way to solve the problem other than checking the
firstElementChild.tagName of every template and praying developers know the
edge cases like a/. Even if it's implemented in every browser, the
developer would still need to know the edge cases. With an attribute, the
developer just needs to know that they're dealing with SVG or not.
On Sat, Mar 14, 2015 at 6:04 PM, Austin William Wright a...@bzfx.net wrote:
On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh bl...@netflix.com wrote:
For my part, I disagree slightly with this statement. If you just drop a
circle tag in a div, you're going to get an HTMLUnknownElement. This is
by design and to spec, of course. But it unfortunately means you can't
clone() the element over to an SVG parent and hope it will work.d
Could you post the specific regression you ran into? The behavior you
describe should only true for text/html parsing; it doesn't apply to DOM
and application/xhtml+xml.
For instance, given an arbitrary, conforming HTML document containing an
SVG circle element, this should work:
var svgns = 'http://www.w3.org/2000/svg';
var c = document.getElementsByTagNameNS(svgns, 'circle')[0].cloneNode();
document.getElementsByTagName('body')[0].appendChild(c);
document.getElementsByTagName('body')[0].lastElementChild.namespaceURI ==
svgns; // true
text/html just isn't cut out for the sort of complex stuff we're
discussing. For instance, what if I want to start using the proposed
application/api-problem+xml format? You can't. text/html simply isn't built
for the complex features being proposed. This is made explicit in HTML5:
The DOM, the HTML syntax, and the XHTML syntax cannot all represent the
same content. For example, namespaces cannot be represented using the HTML
syntax, but they are supported in the DOM and in the XHTML syntax.
Similarly, documents that use the noscript feature can be represented using
the HTML syntax, but cannot be represented with the DOM or in the XHTML
syntax. Comments that contain the string -- can only be represented in
the DOM, not in the HTML and XHTML syntaxes.
There's a craptonne of XML based markup languages and file formats out
there. We can't just keep importing all of them into HTML every time we
decide one of them might be useful to embed inside HTML. THERE is a
usability and complexity nightmare.
Explicit is better than implicit, so I like the idea of a namespace
attribute element, it is forward-compatible with future vocabularies we may
wish to use.
Namespaces aren't *that* hard to understand. In my code above, I added one
line declaring the namespace (`var svgns`). Is that really so hard? If you
want to use the more advanced features of HTML, use namespaces, or import
whatever vocabulary I want - DocBook, OpenDocument, music notation, XSL,
without worry of collision. That's what they're there for, and at least a
handful of client-side libraries already do this, e.g. http://webodf.org/
.
(Certainly much simpler than, say, the parsing differences between script,
style, pre, and attributes, which I only understand well enough to know to
stay the cuss away from putting user content in script tags. The amount of
inconsistency and complexity of text/html parsing is single-handedly
responsible for most of the XSS injections I come across. This isn't just
matter of having a feature or not, this
Re: template namespace attribute proposal
[Sorry for the reply-chain breaking; Gmail is being super weird about your message in particular, and won't let me reply directly to it. Some bug.] Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] Whoops, sorry, forgot about title. We can resolve that conflict in favor of SVG; putting an html title into a template is, I suspect, exceedingly rare. track/canvas/source/video/iframe/audio are all being removed as the SVGWG switches to allowing HTML elements natively in SVG. ~TJ
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh bl...@netflix.com wrote:
For my part, I disagree slightly with this statement. If you just drop a
circle tag in a div, you're going to get an HTMLUnknownElement. This is
by design and to spec, of course. But it unfortunately means you can't
clone() the element over to an SVG parent and hope it will work.d
Could you post the specific regression you ran into? The behavior you
describe should only true for text/html parsing; it doesn't apply to DOM
and application/xhtml+xml.
For instance, given an arbitrary, conforming HTML document containing an
SVG circle element, this should work:
var svgns = 'http://www.w3.org/2000/svg';
var c = document.getElementsByTagNameNS(svgns, 'circle')[0].cloneNode();
document.getElementsByTagName('body')[0].appendChild(c);
document.getElementsByTagName('body')[0].lastElementChild.namespaceURI ==
svgns; // true
text/html just isn't cut out for the sort of complex stuff we're
discussing. For instance, what if I want to start using the proposed
application/api-problem+xml format? You can't. text/html simply isn't built
for the complex features being proposed. This is made explicit in HTML5:
The DOM, the HTML syntax, and the XHTML syntax cannot all represent the
same content. For example, namespaces cannot be represented using the HTML
syntax, but they are supported in the DOM and in the XHTML syntax.
Similarly, documents that use the noscript feature can be represented using
the HTML syntax, but cannot be represented with the DOM or in the XHTML
syntax. Comments that contain the string -- can only be represented in
the DOM, not in the HTML and XHTML syntaxes.
There's a craptonne of XML based markup languages and file formats out
there. We can't just keep importing all of them into HTML every time we
decide one of them might be useful to embed inside HTML. THERE is a
usability and complexity nightmare.
Explicit is better than implicit, so I like the idea of a namespace
attribute element, it is forward-compatible with future vocabularies we may
wish to use.
Namespaces aren't *that* hard to understand. In my code above, I added one
line declaring the namespace (`var svgns`). Is that really so hard? If you
want to use the more advanced features of HTML, use namespaces, or import
whatever vocabulary I want - DocBook, OpenDocument, music notation, XSL,
without worry of collision. That's what they're there for, and at least a
handful of client-side libraries already do this, e.g. http://webodf.org/.
(Certainly much simpler than, say, the parsing differences between script,
style, pre, and attributes, which I only understand well enough to know to
stay the cuss away from putting user content in script tags. The amount of
inconsistency and complexity of text/html parsing is single-handedly
responsible for most of the XSS injections I come across. This isn't just
matter of having a feature or not, this is a matter of security... why not
fix *this*? /rant)
I understand the URI may be too much for people to grok, maybe instead use
a tag name (html, svg or mathml):
template namespace=svg
circle cx=10 cy=10 cr=10 /
/template
The application/xhtml+xml parser would simply ignore the namespace
attribute, using xmlns on children instead. Polyglot HTML would use both
attributes.
If two separate attributes is too much, then just add xmlns= support to
text/html.
Austin.
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking jo...@sicking.cc wrote: Unless the SVG WG is willing to drop support for script![CDATA[...]]/script. But that seems like it'd break a lot of content. Like, on the same line? Because I recall that sort of thing showing up in old HTML tutorials, with the CDATA parts on their own lines. ~TJ
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Absolutely. Forcing authors to write, or even *think* about, namespaces in HTML is a complete usability failure, and utterly unnecessary. The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). If you just looked at the root element, skipping through as, you could do the same magical mode selection we currently do for tr/etc. Ideally we could do this by just pulling SVG into the HTML namespace, which the SVGWG is comfortable with, but no implementors have felt like doing it yet. :/ ~TJ
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 1:27 PM, Benjamin Lesh bl...@netflix.com wrote: I agree completely, Tab, but it's actually too late to stop forcing authors to think about namespaces, the fact I currently have to think about it is the source of this suggestion. You have to think about it today *because we've failed to do things correctly*. That doesn't mean we can't fix it so you can continue to blithely ignore namespaces, like you can otherwise do for everything except the createElement*() functions. The merging of namespaces is the ideal solution, no doubt, but it's probably not a realistic solution in the short or even medium term. It's almost the equivalent of punting. SVG and HTML differ too drastically to just combine them overnight, I suspect. Different types stored in properties, different APIs, etc. On the API level this is completely unproblematic. SVGElement is already a subclass of Element; the namespace really isn't a big deal. The compat issue is just with libraries that branch on the namespace for some reason, and that might be what kills this. Importantly, though, we don't have to merge namespaces to make template work correctly. SVG already resolved that template inside of SVG *should* be the HTMLTemplateElement, not a brand new svg:template element that acts identically. The template element itself already has special parsing rules that cause it to start in particular parser modes, to correctly handle things like templatetrtdfoo/td/tr/template; giving it some more rules to correctly handle templatecircle/circle/template isn't difficult or unrealistic. With that, users of template can just ignore namespaces entirely, except for the corner case of templateatext/a/template, which'll get interpreted as the html:a element rather than svg:a. Namespace unification closes this final gap; it's not needed for the rest. It would be far easier/quicker to add an attribute and deprecate it later than get the namespaces merged. At the very least, it would immediately provide authors something they could polyfill to solve this issue. Deprecation doesn't remove things; every thing we add, we should assume is permanent. Immediately is a funny term to use when discussing standards. Adding an attribute and having it be useful cross-browser isn't any faster than adding to the special cases for SVG-in-template. ~TJ
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 1:57 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Absolutely. Forcing authors to write, or even *think* about, namespaces in HTML is a complete usability failure, and utterly unnecessary. The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). Note that the contents of a HTML script parses vastly different from an SVG script. I don't recall if the same is true for style. So the parser sadly still needs to be able to tell an SVG script from a HTML one. I proposed aligning these so that parsing would be the same, but there was more opposition than interest back then. That's back then. The SVGWG is more interested in pursuing convergence now, per our last few F2Fs. The resistance came mainly from the HTML-parser camp since it required changes to parsing HTML scripts too. Unless the SVG WG is willing to drop support for script![CDATA[...]]/script. But that seems like it'd break a lot of content. / Jonas
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Absolutely. Forcing authors to write, or even *think* about, namespaces in HTML is a complete usability failure, and utterly unnecessary. The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). Note that the contents of a HTML script parses vastly different from an SVG script. I don't recall if the same is true for style. So the parser sadly still needs to be able to tell an SVG script from a HTML one. I proposed aligning these so that parsing would be the same, but there was more opposition than interest back then. / Jonas
Re: template namespace attribute proposal
I agree completely, Tab, but it's actually too late to stop forcing authors to think about namespaces, the fact I currently have to think about it is the source of this suggestion. The merging of namespaces is the ideal solution, no doubt, but it's probably not a realistic solution in the short or even medium term. It's almost the equivalent of punting. SVG and HTML differ too drastically to just combine them overnight, I suspect. Different types stored in properties, different APIs, etc. It would be far easier/quicker to add an attribute and deprecate it later than get the namespaces merged. At the very least, it would immediately provide authors something they could polyfill to solve this issue. On Mar 13, 2015 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Absolutely. Forcing authors to write, or even *think* about, namespaces in HTML is a complete usability failure, and utterly unnecessary. The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). If you just looked at the root element, skipping through as, you could do the same magical mode selection we currently do for tr/etc. Ideally we could do this by just pulling SVG into the HTML namespace, which the SVGWG is comfortable with, but no implementors have felt like doing it yet. :/ ~TJ
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Absolutely. Forcing authors to write, or even *think* about, namespaces in HTML is a complete usability failure, and utterly unnecessary. The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). Note that the contents of a HTML script parses vastly different from an SVG script. I don't recall if the same is true for style. So the parser sadly still needs to be able to tell an SVG script from a HTML one. I proposed aligning these so that parsing would be the same, but there was more opposition than interest back then. That's back then. The SVGWG is more interested in pursuing convergence now, per our last few F2Fs. ~TJ
Re: template namespace attribute proposal
Tab, The only conflicts in the namespaces are font (deprecated in SVG2), script and style (harmonizing with HTML so there's no difference), and a (attempting to harmonize API surface). *If* I didn't make any mistakes (I quickly did and didn't check everything.) The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] # python svg = ['a', 'altGlyph', 'altGlyphDef', 'altGlyphItem', 'animate', 'animateColor', 'animateMotion', 'animateTransform', 'audio', 'canvas', 'circle', 'clipPath', 'color-profile', 'cursor', 'defs', 'desc', 'discard', 'ellipse', 'feBlend', 'feColorMatrix', 'feComponentTransfer', 'feComposite', 'feConvolveMatrix', 'feDiffuseLighting', 'feDisplacementMap', 'feDistantLight', 'feDropShadow', 'feFlood', 'feFuncA', 'feFuncB', 'feFuncG', 'feFuncR', 'feGaussianBlur', 'feImage', 'feMerge', 'feMergeNode', 'feMorphology', 'feOffset', 'fePointLight', 'feSpecularLighting', 'feSpotLight', 'feTile', 'feTurbulence', 'filter', 'font', 'font-face', 'foreignObject', 'g', 'glyph', 'glyphRef', 'hatch', 'hatchPath', 'hkern', 'iframe', 'image', 'line', 'linearGradient', 'marker', 'mask', 'meshGradient', 'meshPatch', 'meshRow', 'metadata', 'missing-glyph', 'mpath', 'path', 'pattern', 'polygon', 'polyline', 'radialGradient', 'rect', 'script', 'set', 'solidColor', 'source', 'stop', 'style', 'svg', 'switch', 'symbol', 'text', 'textPath', 'title', 'track', 'tref', 'tspan', 'use', 'video', 'view', 'vkern'] html = ['a', 'abbr', 'address', 'area', 'article', 'aside', 'audio', 'b', 'base', 'bdi', 'bdo', 'blockquote', 'body', 'br', 'button', 'canvas', 'caption', 'cite', 'code', 'col', 'colgroup', 'command', 'datalist', 'dd', 'del', 'details', 'dfn', 'div', 'dl', 'dt', 'em', 'embed', 'fieldset', 'figcaption', 'figure', 'footer', 'form', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6', 'head', 'header', 'hgroup', 'hr', 'html', 'i', 'iframe', 'img', 'input', 'ins', 'kbd', 'keygen', 'label', 'legend', 'li', 'link', 'main', 'map', 'mark', 'menu', 'meta', 'meter', 'nav', 'noscript', 'object', 'ol', 'optgroup', 'option', 'output', 'p', 'param', 'pre', 'progress', 'q', 'rp', 'rt', 'ruby', 's', 'samp', 'script', 'section', 'select', 'small', 'source', 'span', 'strong', 'style', 'sub', 'summary', 'sup', 'table', 'tbody', 'td', 'template', 'textarea', 'tfoot', 'th', 'thead', 'time', 'title', 'tr', 'track', 'u', 'ul', 'var', 'video', 'wbr'] set(html).intersection(set(svg)) -- Karl Dubost http://www.la-grange.net/karl/
template namespace attribute proposal
I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template Likewise, content should work properly inside of that template tag, but I suspect that's more of a proposal for the SVG spec. This proposal comes from work I'm doing at Netflix to create composable graph components that are SVG based. Currently, I'm not able to use template tags efficiently. This proposal seems like something that would be good in the long run, and something that would also be easy to polyfill in the meantime. What are your thoughts on this idea? Thank you, Ben Lesh @benlesh Senior UI Engineer Netflix
Re: template namespace attribute proposal
On 12/03/2015 11:07 , Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Or even go the extra mile and just slurp all SVG elements into the HTML namespace. There are a few name clashes, but we ought to be able to iron those out. And ditto MathML. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 4:13 AM, Robin Berjon ro...@w3.org wrote: On 12/03/2015 11:07 , Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. Love this idea. Or even go the extra mile and just slurp all SVG elements into the HTML namespace. There are a few name clashes, but we ought to be able to iron those out. And ditto MathML. Not sure what the timeline would look like for this work. I guess this would depend on whether there's existing content counting on namespaces being different? :DG
Re: template namespace attribute proposal
FWIW: Currently, template tags nested in svg are SVGElement, and not HTMLTemplate Element. You also need to hide the SVG container or it will be rendered. On Mar 12, 2015 8:18 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa rn...@apple.com wrote: By special casing, do you mean to recognize SVG element names? Yeah, not really sure there's another way of doing it. (You can of course put things within svg, but then you could also put tbody in table...) I'd prefer allowing template elements inside SVG as in: svgtemplate~/template/svg Would that create an HTMLTemplateElement with a different parser mode? -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa rn...@apple.com wrote: By special casing, do you mean to recognize SVG element names? Yeah, not really sure there's another way of doing it. (You can of course put things within svg, but then you could also put tbody in table...) I'd prefer allowing template elements inside SVG as in: svgtemplate~/template/svg Would that create an HTMLTemplateElement with a different parser mode? -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein ad...@chromium.org wrote: For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. That was going to be my argument, but then I remembered that we went out of our way to make tbody, tr, td, etc. work as direct children of template. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 11:22 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 7:16 PM, Adam Klein ad...@chromium.org wrote: For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. That was going to be my argument, but then I remembered that we went out of our way to make tbody, tr, td, etc. work as direct children of template. Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere?
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein ad...@chromium.org wrote: Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere? It was more principled, not sure about compatibility. Most of the HTML parser depends on modes. Then requiring svg makes sense. Just like it makes sense to require table for td not to be dropped. However, template was designed to work with any element, irrespective of mode. So td should work without table anywhere. Following that logic, it would make sense if circle worked without svg anywhere. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh bl...@netflix.com wrote: I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. - Adam
RE: template namespace attribute proposal
I would also prefer to enable this to work without any extra annotation. So much of the rest of how SVG/MathML are handled in HTML is seamless by design. From: ad...@google.com [mailto:ad...@google.com] On Behalf Of Adam Klein Sent: Thursday, March 12, 2015 11:17 AM To: Benjamin Lesh Cc: WebApps WG Subject: Re: template namespace attribute proposal On Wed, Mar 11, 2015 at 8:32 PM, Benjamin Lesh bl...@netflix.commailto:bl...@netflix.com wrote: I'd like to propose that the template tag have a namespace= attribute that allows the user to specify namespaces such as http://www.w3.org/2000/svg;, so that the document fragment that comes from `.content` is created properly. e.g.: template id=my-svg-template namespace=http://www.w3.org/2000/svg circle cx=10 cy=10 cr=10/ /template For clarity, is this significantly different from the below (which works today)? template id=tmpl svg circle .../ /svg /template Clearly there's an extra step here, in that accessing the SVG elements requires hopping into firstElementChild, but adding new namespace-related features seems unfortunate. - Adam
Re: template namespace attribute proposal
On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh bl...@netflix.com wrote: What are your thoughts on this idea? I think it would be more natural (HTML-parser-wise) if we special-cased SVG elements, similar to how e.g. table elements are special-cased today. A lot of template-parsing logic is set up so that things work without special effort. -- https://annevankesteren.nl/
Re: template namespace attribute proposal
So much of the rest of how SVG/MathML are handled in HTML is seamless by design. For my part, I disagree slightly with this statement. If you just drop a circle tag in a div, you're going to get an HTMLUnknownElement. This is by design and to spec, of course. But it unfortunately means you can't clone() the element over to an SVG parent and hope it will work. This was a problem in Angular's $compile that I helped sort out. Angular would simple clone() partials straight from the DOM and insert them, if that partial happened to be some fragment of SVG, you were then sticking HTMLUnknownElements in your SVG Doc. Ultimately, Angular ended up tracking namespace changes as it traversed the DOM looking for directives, as well as specifying a starting namespace for directives with template strings that were SVG partials. Ember and Handlebars had similar issues with this. Handlebars had to use a wrapMap technique to create DOM elements in the proper way, but that didn't account for the a tag which exists in both namespaces. I'm not sure what HTMLBars is doing to solve this problem, honestly. I'd be shocked if whatever they were doing didn't require some sort of namespace specification somewhere, or simply didn't work with certain edge cases like the a tag. I think this feature is really something that will help framework developers and component library developers create generic code to accommodate their needs. It's more for code sanity than anything. templatesvgcircle//svg/template will clearly work, but then you're putting the onus on the framework authors to make conditional checks that might not always be accurate is the firstElementNode svg? If I'm a framework author, I can't dependably check that and just assume it's an SVG partial. It could be a full SVG-based web component. On Thu, Mar 12, 2015 at 2:08 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein ad...@chromium.org wrote: Is your thinking that adding special-casing for SVG-looking (as in, tag names appearing in the list of SVG tags but not in the list of HTML tags) inside template has fewer compat risks than a wholesale change of the HTML parser to recognize SVG-looking tags anywhere? It was more principled, not sure about compatibility. Most of the HTML parser depends on modes. Then requiring svg makes sense. Just like it makes sense to require table for td not to be dropped. However, template was designed to work with any element, irrespective of mode. So td should work without table anywhere. Following that logic, it would make sense if circle worked without svg anywhere. -- https://annevankesteren.nl/
