Re: [webcomponents] HTML Imports
On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
So you have link href=blah.html in meh.html and blah.html is:
div id=test/div
script /* how do I get to #test? */ /script
document.currentScript.ownerDocument.querySelector(#test) :)
This only works for code running directly in the script. The current
setup means that any time an author has something like:
template id=foo.../template
script
function cloneFoo() { /* get foo and return it. */ }
/script
they'll have to use a closure to capture the document that the
template lives in, which is rather surprising to me. Also, storing the
document in a global variable is a footgun, because that global
variable would potentially collide with another import trying to do
the same thing. ES6 modules would help here, but there a way's off.
I think the greatest impact here will be on developers. They have to start
thinking in terms of multiple documents. We should ask Polymer people: they
wrote a ton of code with Imports now and I bet they have opinions.
Out of curiosity, what have the Polymer guys been using imports for?
More than just declaring custom elements? I'm worried that we're
coming up with a very generic feature with odd semantics that only
make sense for one narrow use-case.
--
Blake Kaplan
Re: The JavaScript context of a custom element
On Mon, May 20, 2013 at 1:00 PM, Aaron Boodman a...@google.com wrote: I would like to suggest that custom elements have the ability to ask for a separate global scope for their JavaScript. This would be analogous to what happens today when you have multiple script-connected frames on the same origin. Has there been any thought along these lines in the past? There definitely has been! There was a long debate about this starting at http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0312.html where the conclusion was to punt on the isolated mode until a later version of the spec. -- Blake Kaplan
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Mon, Apr 29, 2013 at 3:00 PM, Dimitri Glazkov dglaz...@chromium.org wrote: As far as implementation complexity, content select, distribution APIs, and shadow are trivial, compared to the event handling and representation of the composed tree. Hoping to alleviate this, I wrote all event-related handling as imperatively as I could. While I agree that specifying content select, distribution APIs, and shadow is relatively simpler than some of the other parts of the spec, I'm pretty worried right now about the performance of those features, especially for dynamic changes. I just found out, as well, that Mozilla's XBL implementation of these features worked correctly in the static case, but is completely wrong in the dynamic case, so we don't have any real data on how slow doing that stuff correctly is. -- Blake Kaplan
Re: [Shadow DOM] Simplifying level 1 of Shadow DOM
On Mon, Apr 29, 2013 at 3:26 PM, Dimitri Glazkov dglaz...@chromium.org wrote: I wonder if it would be helpful for me to specify exactly where the distribution/composition integrity must be ensured (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20141)? This should help implementers to build a well-performing implementation. While that'd certainly be useful, it won't reduce the amount of work that we need to do on node insertion and appending. I think we're basically going to have to implement it and measure... I wasn't trying to say that it's definitely going to be a problem, just that it's a concern. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 10:12 AM, Rafael Weinstein rafa...@google.com wrote: It seems to me like if public-by-default was a design mistake on the web, it'd be pretty clearly in evidence already. Is it? This might depend who you ask. I know from experience that public-by-default has bitten XBL1-implemented HTML elements really badly (leading to tons of security bugs until we (Mozilla) figured out how to lock them down). We've invested many hours of time avoiding a different problem with our audio and video controls (also implemented in XBL1) where we explicitly had to avoid exposing the guts of the implementation of the control to prevent page authors from using the non-standard internal API instead of the public one. Outside of those cases, I've personally been bitten in other languages and contexts where private state was exposed publicly on an API which made what should have been a simple bug fix take days or weeks to track down all of the (ab)users of the easier API. This is a classic problem in computer science and there's a reason that it's taught in many CS 101 courses. I don't have any specific anecdotes on the web, but they simply must exist. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Wed, Mar 6, 2013 at 2:26 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: What does the exposing internals means anyway? Does it mean that there are no boundaries at all and e.g. document.querySelector can access internal? Or does it mean that you can access internals only by explicitly asking for existing shadowRoot of element and than work with it? I've always taken exposing internals to mean providing an API to access the shadow DOM of a component. I don't think that anybody is arguing that shadow elements should appear in queries on the bound document. -- Blake Kaplan
Re: [webcomponents]: Moving custom element callbacks to prototype/instance
On Wed, Mar 6, 2013 at 1:55 PM, Dimitri Glazkov dglaz...@google.com wrote: 1) Somehow magically chain create callbacks. In Lucy's case, foo-lucy will call both Raj's and Lucy's callbacks. 2) Get rid of a separate lifecycle object and just put the callbacks on the prototype object, similar to printCallback (http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jan/0259.html) I am leaning toward the second solution, but wanted to get your opinions. I also like the second solution, but Hajime's point about the mutability and general exposure of the lifecycle methods is a good one. Is there a motivation for having the lifecycle objects on the prototype as opposed to being passed in as an ancestor parameter? XBL1, as I understand it, automatically calls the constructor/destructor of extended bindings, but given the ad hoc nature of web components' inheritance, it seems like it would be much less surprising to make this stuff explicit *somewhere* (i.e. in the actual components rather than in the engine). -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
On Tue, Feb 26, 2013 at 11:05 AM, Erik Arvidsson a...@google.com wrote: Also, if shadows are public by default the API to access the shadow is well defined. If shadows are private by default and components decide to expose the shadow ad hoc then there is no standardized API. This doesn't have to be the case. Shadows can be private by default with a well defined and consistent API to override the default. -- Blake Kaplan
Re: [webcomponents]: Making Shadow DOM Subtrees Traversable
Hello everybody, I'm coming into this conversation late, but wanted to add my thoughts. As has been pointed out in this thread, the web has traditionally been very open and malleable. JavaScript has very few readonly properties, doesn't generally throw exceptions instead guessing or returning bogus values. Making shadow trees hidden clearly goes against this idiom and, by definition, limits what pages will be able to do with external libraries built using shadow DOMs. Even given this downside, though, I think that it's a mistake to make shadow trees accessible to the bound document by default. One of the most important features for frameworks is the ability to provide an encapsulated API. Without that, it becomes extremely difficult to fix bugs or add features to the framework without risking breaking downstream clients. Shadow DOMs are one of a host of features being designed and implemented that make HTML + CSS + JavaScript usable for programming in the wild and it feels like an oversight to make the default imitate the bad ol' days of monkey patching and low to no encapsulation. Finally, reading through the thread, it seems like one of the main use-cases for open-by-default is features like Google Feedback. From my point of view, it seems like features like that need to be considered from the beginning of a site's design. So if a site wants to have something like GF and also use web components and shadow DOMs, then the designers of the components should have to explicitly set the bit that says let other people poke at my internals. I don't think that this one use-case needs to trump the good programming practices of every other library. -- Blake Kaplan
