Re: template namespace attribute proposal
> On Mar 18, 2015, at 2:19 PM, Tab Atkins Jr. wrote: > > On Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa wrote: >> On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. wrote: >>> Karl Dubost said: The intersection seems to be: ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', 'iframe', 'audio', 'font'] >>> >>> Whoops, sorry, forgot about . We can resolve that conflict in >>> favor of SVG; putting an html into a is, I suspect, >>> exceedingly rare. >> >> That may be true but the added complexity of 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 (which should clearly be SVG, despite the parser turning > it into for you). Implementation complexity isn’t my concern. Exception for 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 Wed, Mar 18, 2015 at 2:06 PM, Ryosuke Niwa wrote: > On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. wrote: >> Karl Dubost said: >>> The intersection seems to be: >>> ['a', 'style', 'script', 'track', 'title', 'canvas', 'source', 'video', >>> 'iframe', 'audio', 'font'] >> >> Whoops, sorry, forgot about . We can resolve that conflict in >> favor of SVG; putting an html into a is, I suspect, >> exceedingly rare. > > That may be true but the added complexity of 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 (which should clearly be SVG, despite the parser turning it into for you). ~TJ
Re: template namespace attribute proposal
> On Mar 16, 2015, at 3:14 PM, Tab Atkins Jr. 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 . We can resolve that conflict in > favor of SVG; putting an html into a is, I suspect, > exceedingly rare. That may be true but the added complexity of 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 2015/03/14 9:41, Karl Dubost wrote: Tab, The only conflicts in the namespaces are (deprecated in SVG2),
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 . We can resolve that conflict in favor of SVG; putting an html into a 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
> 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
tags. This is used for all components, including components
that are partials or are "composable"... One specific example is this:
- the shadow root of `` has an element that contains it's
"content" (which also doesn't work well in SVG).
- the shadow root of `` has a element.
So we'd *hope* that you could define the templates for the above (roughly)
as follows:
This, of course, is broken all over the place.
1. Last I checked (6 months ago), 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 "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 . 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
>> tag in a , 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. >.
>
> (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"):
>
>
>
>
>
> The application/xhtml+xm
Re: template namespace attribute proposal
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
> tag in a , 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.
Re: template namespace attribute proposal
Tab, > The only conflicts in the namespaces are > (deprecated in SVG2),
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 2:15 PM, Tab Atkins Jr. wrote: > On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking wrote: >> Unless the SVG WG is willing to drop support for >> . 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. No. If we want to unify HTML
Re: template namespace attribute proposal
On Fri, Mar 13, 2015 at 2:09 PM, Jonas Sicking wrote: > Unless the SVG WG is willing to drop support for > . 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 Fri, Mar 13, 2015 at 1:57 PM, Tab Atkins Jr. wrote: > On Fri, Mar 13, 2015 at 1:48 PM, Jonas Sicking wrote: >> On Fri, Mar 13, 2015 at 1:16 PM, Tab Atkins Jr. wrote: >>> On Thu, Mar 12, 2015 at 3:07 AM, Anne van Kesteren wrote: On Thu, Mar 12, 2015 at 4:32 AM, Benjamin Lesh 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 -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 >>> (deprecated in SVG2), and