Re: [Shadow] URL-based shadows?
... found it: https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1 :DG On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov dglaz...@google.com wrote: Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly received (can't remember the details). :DG On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead travis.leith...@microsoft.com wrote: Dimitri et al., Has the idea of loading/parsing a Shadow DOM directly from a URL been discussed already? (e.g., a sort-of “micro-import” or an import that parses its document directly into the ShadowRoot container?) I’m curious to know if there’s some obvious flaw that I’m missing. element.createShadowRoot(“path to my component”); This is an idea around building components from the “inside out”, and using the URL as the basis for script-level access control to the Shadow contents. Thoughts?
Re: [Shadow] URL-based shadows?
On Fri, Mar 13, 2015 at 12:57 PM, Travis Leithead travis.leith...@microsoft.com wrote: Ah, thanks Dimitri. After reading that, I'm also receiving it rather coolly. It's a very interesting idea, but as it relates to web components, its errs strongly on the side of isolation to the degree that the component would be more isolated than an iframe today; at least in same-domain, non-sandboxed iframes, you can directly access the document via the contentWindow property if desired; furthermore styling of this DOMWorker thing which is running in a separate thread would be complex to say the least from an implementation standpoint. I definitely want to stay firmly on the same thread for Shadow DOMs [image: ]. Threads don't necessarily come into play here. The proposal doesn't mention it, but Elliott specifically wanted to stay on the same thread. This is not technically a worker, more like an isolator. But anyway -- it does sound different from your idea, which I captured into https://www.w3.org/Bugs/Public/show_bug.cgi?id=28211. :DG
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: [Shadow] URL-based shadows?
Ah, thanks Dimitri.
After reading that, I'm also receiving it rather coolly. It's a very
interesting idea, but as it relates to web components, its errs strongly on the
side of isolation to the degree that the component would be more isolated than
an iframe today; at least in same-domain, non-sandboxed iframes, you can
directly access the document via the contentWindow property if desired;
furthermore styling of this DOMWorker thing which is running in a separate
thread would be complex to say the least from an implementation standpoint. I
definitely want to stay firmly on the same thread for Shadow DOMs ??.
Back to what I'm thinking...
The way I see it, an HTML Import is already a shadow DOM builder (from a URL).
Imports point to a URL, fetch it, parse it (in the context of the parent's
scripting global environment), and then drop the completed document (and it's
dependents) in the 'import' property of the Link element. HTML Imports don't
render the imported document anywhere ('cause it ain't bound to an element
yet--where would you render it?).
If ShadowRoot constructors had the ability to load from a URL, I would propose
that the good parts of HTML Imports be used as the model for the loaded shadow
dom. There would be a few tweaks of course, but the model appears sound to me.
Why is this alluring to me?
* Loading a custom element is more... componentized. The element's shadow dom
(and behavior) can be imported locally in relation to the element host. From
what I have heard recently, custom elements (of sufficient complexity) without
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g.,
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today
(without a URL) may be largely unaffected.
From: Dimitri Glazkov dglaz...@google.com
Sent: Friday, March 13, 2015 10:44 AM
To: Travis Leithead
Cc: WebApps WG; Anne van Kesteren (ann...@annevk.nl); Arron Eicholz; Elliott
Sprehn
Subject: Re: [Shadow] URL-based shadows?
... found it:
https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit?pli=1
:DG
On Thu, Mar 12, 2015 at 6:05 PM, Dimitri Glazkov
dglaz...@google.commailto:dglaz...@google.com wrote:
Yep. Elliott (cc'd) had a proposal like this a while back. It was coolly
received (can't remember the details).
:DG
On Thu, Mar 12, 2015 at 5:46 PM, Travis Leithead
travis.leith...@microsoft.commailto:travis.leith...@microsoft.com wrote:
Dimitri et al.,
Has the idea of loading/parsing a Shadow DOM directly from a URL been
discussed already? (e.g., a sort-of micro-import or an import that parses its
document directly into the ShadowRoot container?) I'm curious to know if
there's some obvious flaw that I'm missing.
element.createShadowRoot(path to my component);
This is an idea around building components from the inside out, and using
the URL as the basis for script-level access control to the Shadow contents.
Thoughts?
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
[Bug 28211] New: [Shadow]: A syntax for loading/parsing shadow trees directly from HTML
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28211
Bug ID: 28211
Summary: [Shadow]: A syntax for loading/parsing shadow trees
directly from HTML
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Component Model
Assignee: dglaz...@chromium.org
Reporter: dglaz...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org,
tra...@microsoft.com
Blocks: 14978
https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0800.html
From Travis:
The way I see it, an HTML Import is already a shadow DOM builder (from a URL).
Imports point to a URL, fetch it, parse it (in the context of the parent's
scripting global environment), and then drop the completed document (and it's
dependents) in the 'import' property of the Link element. HTML Imports don't
render the imported document anywhere ('cause it ain't bound to an element
yet--where would you render it?).
If ShadowRoot constructors had the ability to load from a URL, I would propose
that the good parts of HTML Imports be used as the model for the loaded shadow
dom. There would be a few tweaks of course, but the model appears sound to me.
Why is this alluring to me?
* Loading a custom element is more... componentized. The element's shadow dom
(and behavior) can be imported locally in relation to the element host. From
what I have heard recently, custom elements (of sufficient complexity) without
shadow dom doesn't make much sense.
* The URL can be the basis for script-level access control to the component's
shadow dom (a known and well-established pattern that exists for iframe).
* We can reuse much of the existing investment in imports
* Shadow dom components are allowed to independently load resources (e.g.,
notably stylesheets) behind a potentially access-controlled boundary
* Existing patterns for synchronously loading a shadow dom as work today
(without a URL) may be largely unaffected.
--
You are receiving this mail because:
You are on the CC list for the bug.
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/
