Re: Making template play nice with XML and tags-and-text

2012-08-08 Thread Elliott Sprehn
On Sun, Aug 5, 2012 at 7:00 AM, Henri Sivonen hsivo...@iki.fi wrote:

 On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote:
  On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org wrote:
 
  On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:
 
  Inspired by a conversation with hsivonen in #whatwg, I spend some time
  thinking about how we would design template for an XML world.  One
 idea I
  had was to put the elements inside the template into a namespace other
 than
  http://www.w3.org/1999/xhtml.

 On the face of things, this seems a lot less scary than the wormhole
 model. I think this merits further exploration! Thank you!


This proposal seems worse than wormhole parsing because the interface of
the template nodes is not HTMLElement, unless we're assuming it's a
different but identical namespace?

For instance it's super weird if img src=x is missing the .src property
because it's not in the HTML namespace, but suddenly when it's cloned for
instantiation it's back in the HTML namespace and has the src property.

- E


RE: Making template play nice with XML and tags-and-text

2012-08-06 Thread Tony Ross
From: hsivo...@gmail.com [mailto:hsivo...@gmail.com] On Behalf Of Henri Sivonen
Sent: Sunday, August 05, 2012 7:00 AM 
 On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote:
  On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org
 wrote:
 
  On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:
 
  Inspired by a conversation with hsivonen in #whatwg, I spend some
  time thinking about how we would design template for an XML world.
  One idea I had was to put the elements inside the template into a
  namespace other than http://www.w3.org/1999/xhtml.
 
 On the face of things, this seems a lot less scary than the wormhole
 model. I think this merits further exploration! Thank you!

Just to clarify, is what you find scary about the other model the lack of 
support for XML, or something more?

I've been under the impression we're trying to shield HTML developers from 
namespaces, so I'm a little concerned that this new proposal will move us in 
the opposite direction. Sure I'd like a proposal that works for XML too, but 
not if it means making the feature confusing for web developers.

  Also, the elements inside template, though they appear to be HTML,
  wouldn't have any of the IDL attributes one might expect, e.g., a
  href=foo/a would have no href property in JS (nor would img
  have src, etc). They are, perhaps, too inert.
 
 I think that's not a problem, because you're not supposed to mutate the
 template anyway. You're supposed to clone the template and then mutate
 the clone.

I agree cloning is the main use case (and will probably require a dedicated API 
since cloneNode won't cut it as-is), but I wouldn't rule out developers 
altering templates dynamically. Under those conditions this exposes a lot of 
subtle differences I think most developers won't expect or understand. 

- Tony


RE: Making template play nice with XML and tags-and-text

2012-08-06 Thread Tony Ross
From: Adam Barth [mailto:w...@adambarth.com]
Sent: Monday, August 06, 2012 1:36 PM
 On Mon, Aug 6, 2012 at 11:44 AM, Tony Ross tr...@microsoft.com wrote:
 
  I've been under the impression we're trying to shield HTML developers
 from namespaces, so I'm a little concerned that this new proposal will
 move us in the opposite direction. Sure I'd like a proposal that works
 for XML too, but not if it means making the feature confusing for web
 developers.
 
 We already uses namespaces in HTML to implement SVG-in-HTML, for example.

I know and this works great at the parsing level, but developers get confused 
once they get to the DOM because suddenly namespaces matter again. I've lost 
count of how many times I've been asked why createElement(circle) doesn't 
work.

- Tony




Re: Making template play nice with XML and tags-and-text

2012-08-06 Thread Jonas Sicking
On Mon, Aug 6, 2012 at 11:44 AM, Tony Ross tr...@microsoft.com wrote:
 From: hsivo...@gmail.com [mailto:hsivo...@gmail.com] On Behalf Of Henri 
 Sivonen
 Sent: Sunday, August 05, 2012 7:00 AM
 On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote:
  On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org
 wrote:
 
  On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:
 
  Inspired by a conversation with hsivonen in #whatwg, I spend some
  time thinking about how we would design template for an XML world.
  One idea I had was to put the elements inside the template into a
  namespace other than http://www.w3.org/1999/xhtml.

 On the face of things, this seems a lot less scary than the wormhole
 model. I think this merits further exploration! Thank you!

 Just to clarify, is what you find scary about the other model the lack of 
 support for XML, or something more?

 I've been under the impression we're trying to shield HTML developers from 
 namespaces, so I'm a little concerned that this new proposal will move us in 
 the opposite direction. Sure I'd like a proposal that works for XML too, but 
 not if it means making the feature confusing for web developers.

I agree.

I feel like this proposal reduces some complexity in the parsing
model, at the cost of increasing complexity in a lot of other parts of
the system.

I'll also note that this doesn't help with things like querySelector
since that usually selects all elements with a certain localName,
independent of namespace. Likewise with getElementsByTagName.

Why is it that we are so much more concerned about the DOM-building
during XML parsing, than we are about DOM-building during HTML
parsing?

I think we for years have been complaining about XML parsing being too
different from HTML parsing in bad ways. HTML5 did some to help the
two move closer together. I'd rather continue on that path than create
more splits again.

I can certainly see being less concerned about introducing complexity
for XML users given that there are a lot fewer of those than HTML
users. Is that the reasoning here?

/ Jonas



Re: Making template play nice with XML and tags-and-text

2012-08-05 Thread Henri Sivonen
On Wed, Jul 18, 2012 at 11:35 PM, Adam Barth w...@adambarth.com wrote:
 On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org wrote:

 On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:

 Inspired by a conversation with hsivonen in #whatwg, I spend some time
 thinking about how we would design template for an XML world.  One idea I
 had was to put the elements inside the template into a namespace other than
 http://www.w3.org/1999/xhtml.

On the face of things, this seems a lot less scary than the wormhole
model. I think this merits further exploration! Thank you!

 One question about your proposal: do the contents of template in an HTML
 Unlike the existing wormhole template semantics, in this approach the
 tags-and-text inside template would translate into DOM as usual for XML.
 We'd get the inert behavior for free because we'd avoid defining any
 behavior for elements in the http://www.w3.org/2012/xhtml-template namespace
 (just as no behavior is defined today).

 This does get you inertness, but doesn't avoid querySelector matching
 elements inside template.

If changes of the magnitude discussed here are on the table for HTML
parsing, I don't see why querySelectorAll() or even Selectors should
be assumed to be unchangeable.

 Also, the elements inside template, though they appear to be HTML,
 wouldn't have any of the IDL attributes one might expect, e.g., a
 href=foo/a would have no href property in JS (nor would img have
 src, etc). They are, perhaps, too inert.

I think that's not a problem, because you're not supposed to mutate
the template anyway. You're supposed to clone the template and then
mutate the clone.

 That's unfortunate.  I guess that means CSS styles will get applied to them
 as well, which wouldn't be what authors would want.

That's not really a problem as long as subtrees with elements in the
template namespaces are rooted at a display: none; template element.

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/



Re: Making template play nice with XML and tags-and-text

2012-07-18 Thread Ian Hickson
On Wed, 18 Jul 2012, Adam Barth wrote:

 Inspired by a conversation with hsivonen in #whatwg, I spend some time 
 thinking about how we would design template for an XML world.  One 
 idea I had was to put the elements inside the template into a namespace 
 other than http://www.w3.org/1999/xhtml.

Interesting idea.

To handle multiple namespaces (specifically SVG and MathML), we could say 
that inert namespaces are namespaces that start with or end with a 
particular prefix, e.g. that are in the inert: scheme or that end with 
#inert. Then to de-inert nodes, you just strip the relevant part of the 
namespace string when cloning.

To make this work in HTML with nested namespaces might be interesting:

   template
 div
   svg
 foreignObject
   math
 mi
   var

I guess what we do in the HTML parser is have it use all the same 
codepaths as now, except the create an element operations check if 
there's a template on the stack, and if there is, then they add the 
inert marker to the namespace, but everything else in the parser acts as 
if the marker is not there?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'



Re: Making template play nice with XML and tags-and-text

2012-07-18 Thread Adam Barth
On Wed, Jul 18, 2012 at 10:43 AM, Ian Hickson i...@hixie.ch wrote:

 On Wed, 18 Jul 2012, Adam Barth wrote:
 
  Inspired by a conversation with hsivonen in #whatwg, I spend some time
  thinking about how we would design template for an XML world.  One
  idea I had was to put the elements inside the template into a namespace
  other than http://www.w3.org/1999/xhtml.

 Interesting idea.

 To handle multiple namespaces (specifically SVG and MathML), we could say
 that inert namespaces are namespaces that start with or end with a
 particular prefix, e.g. that are in the inert: scheme or that end with
 #inert. Then to de-inert nodes, you just strip the relevant part of the
 namespace string when cloning.

 To make this work in HTML with nested namespaces might be interesting:

template
  div
svg
  foreignObject
math
  mi
var

 I guess what we do in the HTML parser is have it use all the same
 codepaths as now, except the create an element operations check if
 there's a template on the stack, and if there is, then they add the
 inert marker to the namespace, but everything else in the parser acts as
 if the marker is not there?


Yeah, that could work.  We also need to consider nested templates:

template
  div
template
  span

I suspect we'll want the span to be in the same inert namespace as the
div, not doubly inerted.

Adam


Re: Making template play nice with XML and tags-and-text

2012-07-18 Thread Adam Klein
On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:

 Inspired by a conversation with hsivonen in #whatwg, I spend some time
 thinking about how we would design template for an XML world.  One idea I
 had was to put the elements inside the template into a namespace other than
 http://www.w3.org/1999/xhtml.


Interesting idea! We considered something like this back before Rafael's
initial email to WebApps but discarded it for reasons discussed below.

One question about your proposal: do the contents of template in an HTML
document parse as HTML or XHTML (I'm not as familiar as I should be with
how the contents of svg are parsed in HTML)? For example, can I omit
closing /p tags?


 Unlike the existing wormhole template semantics, in this approach the
 tags-and-text inside template would translate into DOM as usual for XML.
  We'd get the inert behavior for free because we'd avoid defining any
 behavior for elements in the http://www.w3.org/2012/xhtml-templatenamespace 
 (just as no behavior is defined today).


This does get you inertness, but doesn't avoid querySelector matching
elements inside template.

Also, the elements inside template, though they appear to be HTML,
wouldn't have any of the IDL attributes one might expect, e.g., a
href=foo/a would have no href property in JS (nor would img have
src, etc). They are, perhaps, too inert.

When combined with the querySelector problem, this seems especially bad,
since jQuery-style invocations would expect everything matching, say,
$('img') to behave the same way (I guess we already have this problem with
SVG a tags, but it seems especially weird in a document that one might
think is all-HTML).

- Adam


Re: Making template play nice with XML and tags-and-text

2012-07-18 Thread Adam Barth
On Wed, Jul 18, 2012 at 11:29 AM, Adam Klein ad...@chromium.org wrote:

 On Wed, Jul 18, 2012 at 9:19 AM, Adam Barth w...@adambarth.com wrote:

 Inspired by a conversation with hsivonen in #whatwg, I spend some time
 thinking about how we would design template for an XML world.  One idea I
 had was to put the elements inside the template into a namespace other than
 http://www.w3.org/1999/xhtml.


 Interesting idea! We considered something like this back before Rafael's
 initial email to WebApps but discarded it for reasons discussed below.

 One question about your proposal: do the contents of template in an HTML
 document parse as HTML or XHTML (I'm not as familiar as I should be with
 how the contents of svg are parsed in HTML)? For example, can I omit
 closing /p tags?


We get to pick, but presumably we'd pick HTML-like parsing.


 Unlike the existing wormhole template semantics, in this approach the
 tags-and-text inside template would translate into DOM as usual for XML.
  We'd get the inert behavior for free because we'd avoid defining any
 behavior for elements in the http://www.w3.org/2012/xhtml-templatenamespace 
 (just as no behavior is defined today).


 This does get you inertness, but doesn't avoid querySelector matching
 elements inside template.

 Also, the elements inside template, though they appear to be HTML,
 wouldn't have any of the IDL attributes one might expect, e.g., a
 href=foo/a would have no href property in JS (nor would img have
 src, etc). They are, perhaps, too inert.

 When combined with the querySelector problem, this seems especially bad,
 since jQuery-style invocations would expect everything matching, say,
 $('img') to behave the same way (I guess we already have this problem with
 SVG a tags, but it seems especially weird in a document that one might
 think is all-HTML).


That's unfortunate.  I guess that means CSS styles will get applied to them
as well, which wouldn't be what authors would want.

Adam