Re: template namespace attribute proposal

2015-03-16 Thread Benjamin Lesh
 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

- 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

template id=my-line
  path /

This, of course, is broken all over the place.

1. Last I checked (6 months ago), content/ is an SVGElement, not an
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 wrote:

 On Thu, Mar 12, 2015 at 4:20 PM, Benjamin Lesh 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 = '';
 var c = document.getElementsByTagNameNS(svgns, 'circle')[0].cloneNode();
 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.

 (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

template namespace attribute proposal

2015-03-12 Thread Benjamin Lesh
I'd like to propose that the template tag have a namespace= attribute
that allows the user to specify namespaces such as;, so that the document fragment that comes from
`.content` is created properly.


template id=my-svg-template namespace=
  circle cx=10 cy=10 cr=10/

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
Senior UI Engineer

Re: template namespace attribute proposal

2015-03-13 Thread Benjamin Lesh
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. wrote:

 On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren
  On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh
  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. :/


Re: template namespace attribute proposal

2015-03-12 Thread Benjamin Lesh
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
On Mar 12, 2015 8:18 AM, Anne van Kesteren wrote:

 On Thu, Mar 12, 2015 at 3:57 PM, Ryosuke Niwa 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

  I'd prefer allowing template elements inside SVG as in:

 Would that create an HTMLTemplateElement with a different parser mode?


Re: template namespace attribute proposal

2015-03-12 Thread Benjamin Lesh
 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 wrote:

 On Thu, Mar 12, 2015 at 8:24 PM, Adam Klein 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
  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.