Re: template namespace attribute proposal

2015-03-16 Thread Brian Birtles

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: [Shadow] URL-based shadows?

2015-03-16 Thread Anne van Kesteren
On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov dglaz...@google.com wrote:
 https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1

That seems really cool. I'm not sure worker is the right terminology
since at the moment worker sort of implies there's no node tree
available due to the complexity that would give. But an isolated
global for a set of reusable components that are mixed into the
document seems roughly in line with what we have with input et al
today.


-- 
https://annevankesteren.nl/



Re: [Shadow] URL-based shadows?

2015-03-16 Thread Dimitri Glazkov
On Mon, Mar 16, 2015 at 3:55 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Mar 13, 2015 at 6:44 PM, Dimitri Glazkov dglaz...@google.com
 wrote:
 
 https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1

 That seems really cool. I'm not sure worker is the right terminology
 since at the moment worker sort of implies there's no node tree
 available due to the complexity that would give. But an isolated
 global for a set of reusable components that are mixed into the
 document seems roughly in line with what we have with input et al
 today.


Agree.

:DG


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
/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

2015-03-16 Thread Tab Atkins Jr.
[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