Re: =[xhr]
I would suggest taking a look at what you can do with Generators and Promises in ES6 for example ( https://www.npmjs.org/package/co ) or if you want to try something from ES7 async functions https://github.com/lukehoban/ecmascript-asyncawait I work on applications of over 200,000K LOC and we load everything in one go, are you bundling and gzipping your source? Minifying? 150,000 LOC doesn't seem to require this complexity. Jmol utilizes a virtually complete implementation of Java in JavaScript. I hope you aren't trying to force idoms from one language and environment into a totally different one and then complaining that there is an impedance mismatch. B. On Sun, Aug 31, 2014 at 11:12 AM, Robert Hanson hans...@stolaf.edu wrote: Thank you for the quick reply. I have been traveling and just noticed it. I think you misunderstand. If you want to see what I have, take a look at any of the demos in http://chemapps.stolaf.edu/jmol/jsmol, in particular http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm or http://chemapps.stolaf.edu/jmol/jsmol/test2.htm There are hundreds of implementations of JSmol out there. We are seeing documented (very partial) use involving 150,000 unique users per month utilizing JSmol. Maybe a drop in the bucket, but it's a pretty good chunk of chemistry involving just about any involvement of molecular models on the web. I can give you some examples: http://www.ebi.ac.uk/pdbe/pisa/pi_visual.html http://www.rcsb.org/pdb/explore/explore.do?structureId=1RRP just to give you an idea. Jmol utilizes a virtually complete implementation of Java in JavaScript. Including Class.forName() -- that is, Java reflection. Now, the reason that is done is that with 150,000 lines of code, you don't want to load the whole thing at once. Good programming practice in this case requires modularization, which Jmol does supremely well, with over 150 calls to Class.forName(). Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new Java class is needed. You want me to make the asynchronous call, which could involve any number of dependent class calls (most of these are just a few Kb -- they do NOT detract from the user experience -- drop the thread (throw an exception while saving the entire state), and then resume the state after file loading is complete? Has anyone got a way to do that with JavaScript? In Java it is done with thread suspension, but that's not a possibility. Wouldn't you agree that a few ms delays (typically) the user experience would be far worse if the program did not work because it could not function synchronously or would have to be loaded monolithically? Downloading 5 Mb in one go would be a terrible experience, obviously, asynchronously or not. I'm simply reacting to what I am sensing as a dogmatic noninclusive approach. Are folks really talking about disallowing synchronous transfer via XMLHttpRequest? No use cases other than mine? Really? Can you also then give me creation of threads (not just web workers, but actual full threads for the DOM) and allow me to suspend/resume them? That seems to me to be the necessary component missing if this spec goes through removing synchronous file transport. This is not a minor matter. It is a very big deal for many people. I assure you, this will break hundreds of sites in the areas of general chemistry, organic chemistry, biochemistry, computational chemistry, crystallography, materials science, computational physics, and mathematics -- today, if browser designers follow the recommendation to experiment with throwing an InvalidAccessError exception It will shut down essentially all sites involved in web-based molecular modeling. Why so draconian a recommendation? I'm very seriously concerned about this -- that it would even be suggested, much less implemented. Again, I understand your concern. But absolutely seriously, this recommendation is actually, in my opinion, simply irresponsible. Peoples livelihood could be destroyed. (Not mine, I mean all those working on the professional sites that depend upon Jmol/JSmol for their proper function.) Huge huge expenses to figure out a work-around. Bob Hanson Principal Developer, Jmol/JSmol
Re: [HTML Imports] What is the imagined work flow?
Correct, you wouldn't always want to add it to the document head. Yes I see there would still be semantic issues...I guess the safest/easiest way would be to have the developer state what type the resources are. How you would do that in a clean fashion I'm not sure... On Wed, Jul 2, 2014 at 4:09 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 2, 2014, at 3:57 AM, Brian Di Palma off...@gmail.com wrote: I'm happy to hear that it seems natural to trigger resource loading within a module. For example, I could imagine adding a new syntax for loading an arbitrary sub resource dependency. Absolutely. I think the platform could provide much better syntax then these examples. ``` import '../style/index.css!'; import spaApplicationTemplate from '../template/spaApplication.text!'; ``` As devs can't really create new syntax we are forced to work with the existing syntax. It's not pretty but the CSS/LESS/text etc plugins from SystemJS https://github.com/systemjs/systemjs/#plugins do the job. Possibly the right syntax would also address the semantic issues that were pointed out. It's not explict but the imported CSS was added to the document head, so maybe something like Do you really want to always add it to head though? In the case of defining your own element, don't you want to add it to your custom element's shadow DOM? ``` import '../style/index.css' into document; ``` Would make it more explicit? ``` import '../style/index.css' into customElementTemplate; ``` Is another possibility. I think the semantics issue or rather ambiguity we pointed out is still in the example above. Unless we rely on mime type information provided by the server, we can't figure out what kind of a resource we're loading (is it CSS, HTML, or JSON?). We might want to be more explicit in that regard. - R. Niwa
Re: Feedback on custom elements and virtual DOM
Sorry for the delay. The developers at the conference were mainly Java, Scala, Python, etc devs, so with that caveat in mind... People liked that you could integrate them easily into a web application. You add a `mycustom-element/mycustom-element` tag into the document body and your custom element class was up and running. Less technical people like designers could use custom elements without a lot of hand holding. They liked the attribute changes triggering events, the idea of that possibly being your element's API seemed to be well received. I think the component based development flow made more sense to them then just manipulating random divs. The package we used in the web components part of the workshop used the ES6 module loader to load in the element modules, template and styles. I think part of the ease of use positive feedback was actually from that, no script tags etc. Now these are not people that are experts in Ember/Angular or React so maybe if they were they would have been less impressed. The only aspect of web components we touched was custom elements... If you could provide the same experience with DOM MutationObserver then I can see why there might be some doubts... Making Custom Elements into sugar over DOM MutationObserver might be enough for some developers. The only area that I'm not so sure about is ShadowDOM, that could be a very powerful and useful feature but I'm afraid we didn't have time to dive into it. No one had a problem with using the ES6 module loader instead of HTML Imports, or with not using Templates. I have nothing concrete in mind when I talked about melding the virtual DOM and Custom Elements. I think the important benefit of React is allowing Immediate mode rendering vs Retained mode rendering. Most of the time spent on components is on maintenance and I don't think Custom Elements help out there. They encourage the retained, mutable state/two-way binding pattern that libraries like KO, Angular and Ember use. Even competing libraries are starting to pay attention https://twitter.com/vojtajina/status/482940326366040064 I doubt any elaboration on turning view components into pure functions would be as good as this blog post http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome rerender the entire app whenever a change is made. That way, it's really easy to keep everything in sync. React allows you to stop worrying about the previous DOM state, while Web Components still require you to deal with that complexity. I'm not sure what boost in productivity Web Components offer over something like React. There are a lot of good points made in that blog. Observables+DOM elements is a leaky abstraction, and as a user I shouldn't need an intimate knowledge of how the UI is kept in sync with my data. components and their behaviors are intimately dependant and should be encapsulated like so. Surely HTML can only ever be a sugar over the real business logic which will be contained in JS. We need a Turing complete language to build complex applications. Aren't you tired of having to query the DOM tree and manually manage the structure to create UIs? Web Components doesn't solve this at all, it just tries to encapsulate the work. The problem is that building apps is building components, so you inevitably are forced back into the manual DOM management to create your app-specific components (like how you constantly have to create directives in Angular). You also need to jump into JavaScript to configure and wire up any Web Components you used. It's a very messy abstraction, and fools you into desiring a pure HTML-based declarative way to write apps. The components I have built using Custom Elements had this property, I was still removing and adding event listeners and dealing with the previous DOM state. It was nice to work directly in a DOM elements but that's not an amazing win in my mind, it's a minor plus. To build complex apps you will still use something like Polymer/Angular/Ember or React. There is no guidance about data flow between different Web Components. They seem underpowered and complex... None of these concerns will stop Web Components from being standardized, implemented in browsers and used by developers. A standard will have mind share purely because it's a standard but it doesn't seem like a significant step forward. On Wed, Jul 2, 2014 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote: On Jul 2, 2014, at 3:57 AM, Brian Di Palma off...@gmail.com wrote: I gave a workshop on ES6 and Web Components at a small conference in London and there was positive feedback on Custom Elements. People liked them, felt the component approach was a good way to model web applications. Then again React has similar concepts. We tend to hear people like the idea a lot about web components but the devil is in the details in our industry. Could you elaborate more on which aspects of web components or custom elements developers liked
Re: [HTML Imports] What is the imagined work flow?
I'm happy to hear that it seems natural to trigger resource loading within a module. For example, I could imagine adding a new syntax for loading an arbitrary sub resource dependency. Absolutely. I think the platform could provide much better syntax then these examples. ``` import '../style/index.css!'; import spaApplicationTemplate from '../template/spaApplication.text!'; ``` As devs can't really create new syntax we are forced to work with the existing syntax. It's not pretty but the CSS/LESS/text etc plugins from SystemJS https://github.com/systemjs/systemjs/#plugins do the job. Possibly the right syntax would also address the semantic issues that were pointed out. It's not explict but the imported CSS was added to the document head, so maybe something like ``` import '../style/index.css' into document; ``` Would make it more explicit? ``` import '../style/index.css' into customElementTemplate; ``` Is another possiblity. I gave a workshop on ES6 and Web Components at a small conference in London and there was positive feedback on Custom Elements. People liked them, felt the component approach was a good way to model web applications. Then again React has similar concepts. Programming with the DOM as the local `this` pointer is nice and went down well. I wish we could meld the virtual DOM idea with Custom Elements as that would be the best of both worlds. Turning view components into a set of pure functions is a fantastic way of dealing with mutable state. We tried to cover too much ground though so I wasn't able to go too much into HTML Imports and Shadow DOM. B. On Tue, Jul 1, 2014 at 2:51 AM, Ryosuke Niwa rn...@apple.com wrote: I've talked to a few of my colleagues here at Apple who work on JavaScriptCore but they don't seem to think that the ES6 modules is the right mechanism to import arbitrary sub resource since the semantics of loading CSS, HTML, etc... depends on the context whereas ES6 module has exactly one purpose: importing a ES6 module. We do share the same sentiment that it's more natural to trigger resource loads within the script. For example, I could imagine adding a new syntax for loading an arbitrary sub resource dependency. We also agree that authors should to be able to use the single dependency graph shared with ES6 modules: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715 - R. Niwa On Jun 5, 2014, at 6:07 AM, Brian Di Palma off...@gmail.com wrote: Dimitri, Thank you for your excellent reply. As you mention the dependency resolution properties are also available in ES6 modules. I feel there is a case to be made for ES6 modules being used for any resource type loading. e.g. https://github.com/briandipalma/spa-2014-app/blob/master/src/SpaApplicationElement.js This Custom Element is able to load in it's dependent styling and template information. Albeit it requires extensions to the ES6 module loader they are not exceptionally complex. My preference for a ES6 module solution is biased by the fact I spend most of my time in JS code. I can imagine people who want to drop in some some broadly reusable functionality (social widgets etc) would prefer a HTML Import. If it's just a matter of adding a tag and either works then I'd question the use of two broadly similar specs. It might be easier to add native CSS and HTML loading to ES6 modules then to add HTMLImports to the platform. B. On Fri, May 23, 2014 at 6:42 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Brian, I believe Scott enumerated all these in his initial reply, but here's my take (I wrote parts of this in another email, my apologies to that email's recipient for repeating myself :) HTML Imports are primarily about dependency resolution. They allow the web developer to think locally in terms of their dependencies. Then, the underlying machinery builds a global dependency graph and turns it into a tree to ensure consistent processing order. Scripts in the imports are evaluated in this order. In addition, HTML Imports load/apply styles to the document in the same order, which enables a much saner way to reason about components and their effects. For example, in Jan Miksovsky's presentation at SFHTML5 event, he shows something very interesting (https://www.youtube.com/watch?feature=player_detailpagev=mN7IAaRdi_k#t=8608). He pastes link rel=import href=http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html; in a jsbin and instantly gets his custom element work (modulo the platform.js polyfill, which will eventually not be necessary). This is super important. A typical way to do this prior to imports is: 1) Add the script src reference to the library that was used to develop this component 2) Add the link to the stylesheets that will be used by the component 3) Add the script src reference to the component itself. 4) In the script of the component, there will probably be some
Re: [HTML Imports] What is the imagined work flow?
to implement script type=module
(https://github.com/dherman/web-modules/tree/master/module-tag), it
will fit nicely into the imports story as well -- it's just one of
dependencies.
:DG
On Fri, May 23, 2014 at 9:35 AM, Brian Di Palma off...@gmail.com wrote:
HTML Imports seems the least crucial of the Web Components specs.
Consider that all but the most trivial of Web Components will require JS.
JS is now getting a module system which can be used to load other
resources ( e.g. https://github.com/systemjs/systemjs/#plugins ).
The JS module system seems much more flexible then loading via URLs.
I think it's fair to question if HTML Imports is even necessary.
Are any of the current HTML Import use cases impossible to implement
using JS modules?
On Wed, May 21, 2014 at 8:13 AM, Scott Miles sjmi...@google.com wrote:
Sorry, but just a bit of follow up.
One may notice that the Web Components spec is imperative and assume that
declarative support is not important. But as it turns out, the notion of
using custom-elements to bootstrap declarative syntaxes allows various
parties to experiment in the real-world, as opposed to a working group
trying to resolve the trade-offs in an a-priori spec.
I mention this, because although I used Polymer as an example (it's my
project after all), the fact is we hope people will use web-components like
this:
link rel=import href=sweet-button.html
...
sweet-button/sweet-button
Is sweet-button implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.
Ideally, best-of-breed technology emerges and the option to standardize is
still available.
On Tue, May 20, 2014 at 11:56 PM, Scott Miles sjmi...@google.com wrote:
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
- importing self-organizing databases via custom elements (e.g.
core-meta elements describe/provide metadata using monostate pattern)
Also, one of the first things Polymer does is register a custom-element
which itself provides a declarative interface to the custom element
machinery. Most other Polymer elements are then structured declaratively
(as
HTML) which makes using imports highly convenient.
would stick a style element in the imported document
You can do that, reference an external stylesheet, or place a (scoped)
style tag directly in the shadow-root.
E.g. using Polymer idiom
polymer-element name=my-button noscript
template
style
:host div.someclass {
color: aliceblue;
}
/style
div class=someclassmy-button/div
/template
/polymer-element
On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Over here at mozilla we've been trying to understand how the HTML
Imports spec is intended to be used.
We have so far received descriptions of how the spec works. I.e. what
happens when the various import related attributes are added to an
link rel=import.
However I'm curious to understand the expected developer work flows.
Let me make a few guesses to clarify the type of description I'm looking
for.
Clearly imports are expected to be used together with web components.
However so far web components are mainly an imperative API, and not a
declarative thing. Any element registrations needs to be created
through JS calls, and all the shadow DOM inside a custom element needs
to be created using JS calls and then inserted into the shadow root
using script.
At first glance it seems like a simple script src=... would then
provide all that you need?
However it might be tedious to create all elements using createElement
and appendChild calls. A better work flow is to stick a script in a
link rel=imported document together with some template elements.
Then clone the of those templates from the constructors of the custom
elements.
And in order to style the custom elements, you would stick a style
element in the imported document which would have rules like
my-button::shadow div.someclass {
color: aliceblue;
}
Is this an accurate description? Are there other reasons to stick
non-script content in the HTML? Are there any examples out there of
how HTML imports are intended to be used?
/ Jonas
Re: [HTML Imports] What is the imagined work flow?
HTML Imports seems the least crucial of the Web Components specs.
Consider that all but the most trivial of Web Components will require JS.
JS is now getting a module system which can be used to load other
resources ( e.g. https://github.com/systemjs/systemjs/#plugins ).
The JS module system seems much more flexible then loading via URLs.
I think it's fair to question if HTML Imports is even necessary.
Are any of the current HTML Import use cases impossible to implement
using JS modules?
On Wed, May 21, 2014 at 8:13 AM, Scott Miles sjmi...@google.com wrote:
Sorry, but just a bit of follow up.
One may notice that the Web Components spec is imperative and assume that
declarative support is not important. But as it turns out, the notion of
using custom-elements to bootstrap declarative syntaxes allows various
parties to experiment in the real-world, as opposed to a working group
trying to resolve the trade-offs in an a-priori spec.
I mention this, because although I used Polymer as an example (it's my
project after all), the fact is we hope people will use web-components like
this:
link rel=import href=sweet-button.html
...
sweet-button/sweet-button
Is sweet-button implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.
Ideally, best-of-breed technology emerges and the option to standardize is
still available.
On Tue, May 20, 2014 at 11:56 PM, Scott Miles sjmi...@google.com wrote:
Some of the ways Polymer team uses imports are as follows:
- aggregating script src and/or link rel=stylesheet elements into
functional units
- aggregating imports themselves into units
- expressing dependencies (N modules can each import jquery2-import.html
and I only get one copy of jquery)
- importing self-organizing databases via custom elements (e.g.
core-meta elements describe/provide metadata using monostate pattern)
Also, one of the first things Polymer does is register a custom-element
which itself provides a declarative interface to the custom element
machinery. Most other Polymer elements are then structured declaratively (as
HTML) which makes using imports highly convenient.
would stick a style element in the imported document
You can do that, reference an external stylesheet, or place a (scoped)
style tag directly in the shadow-root.
E.g. using Polymer idiom
polymer-element name=my-button noscript
template
style
:host div.someclass {
color: aliceblue;
}
/style
div class=someclassmy-button/div
/template
/polymer-element
On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
Over here at mozilla we've been trying to understand how the HTML
Imports spec is intended to be used.
We have so far received descriptions of how the spec works. I.e. what
happens when the various import related attributes are added to an
link rel=import.
However I'm curious to understand the expected developer work flows.
Let me make a few guesses to clarify the type of description I'm looking
for.
Clearly imports are expected to be used together with web components.
However so far web components are mainly an imperative API, and not a
declarative thing. Any element registrations needs to be created
through JS calls, and all the shadow DOM inside a custom element needs
to be created using JS calls and then inserted into the shadow root
using script.
At first glance it seems like a simple script src=... would then
provide all that you need?
However it might be tedious to create all elements using createElement
and appendChild calls. A better work flow is to stick a script in a
link rel=imported document together with some template elements.
Then clone the of those templates from the constructors of the custom
elements.
And in order to style the custom elements, you would stick a style
element in the imported document which would have rules like
my-button::shadow div.someclass {
color: aliceblue;
}
Is this an accurate description? Are there other reasons to stick
non-script content in the HTML? Are there any examples out there of
how HTML imports are intended to be used?
/ Jonas
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Tue, Dec 10, 2013 at 9:23 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 8:33 PM, Rafael Weinstein rafa...@google.com wrote:
On Sat, Dec 7, 2013 at 6:56 PM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 7, 2013, at 3:53 PM, Rafael Weinstein rafa...@google.com wrote:
The issue is that being an element and having shadow DOM -- or any
display DOM, for that matter -- are orthogonal concerns.
There are lots of c++ HTML elements that have no display DOM. Polymer
already has an even larger number.
While that's true in browser implementations, there is very little authors
can do with a plain element without any shadow content it since JavaScript
can't implement it's own style model (i.e. creating a custom frame object in
Gecko / render object in WebKit/Blink) or paint code in JavaScript.
If the only customization author has to do is adding some CSS, then we
don't need custom element hook at all.
I'm was thinking about elements whose purpose isn't presentational. For
example, link or script in html, or polymer-ajax in polymer.
What are advantages of using an element to represent an AJAX request over,
say, doing so in JSON or via function call?
e.g.
Polymer.ajax({url: http://gdata.youtube.com/feeds/api/videos/;, params:
'{alt:json, q:chrome}', handleAs: 'json',
onResponse=handleResponse})
instead of
polymer-ajax auto url=http://gdata.youtube.com/feeds/api/videos/;
params='{alt:json, q:chrome}'
handleAs=json
on-polymer-response={{handleResponse}}
/polymer-ajax
I have been wondering this, I've already mentioned that I am not
convinced by having JS and CSS inside an HTML file and using HTML
imports to pull them in.
Hopefully the ES6 module loader can offer an alternative as I think it
can be used to pull in any resource type and with its hooks you can
handle them in the correct fashion.
I'm even less convinced by the notion that custom elements can be
turned into a rerun of Ant.
That holds very little appeal to me, although I'm sure people will
create if else for elements just because they can.
It might just work out this time.
It seems strange to have a node in DOM whose sole job is to issue an XHR
request and call a handler.
Having said that, I could imagine people implementing link[rel=import] like
feature using some custom element as a polyfill for a yet-to-be implemented
browser feature.
- R. Niwa
Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Sat, Dec 7, 2013 at 1:01 AM, Ryosuke Niwa rn...@apple.com wrote:
On Dec 6, 2013, at 1:20 AM, Brian Di Palma off...@gmail.com wrote:
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
1) It is not friendly to ES6 classes. In fact, you can't use class syntax
and this syntax together.
Okay, let the author define the constructor.
3) The approach pollutes global name space with constructors. This had been
voiced many times as unacceptable by developers.
We can solve this problem by using JavaScript object path as opposed to a
variable name.
So instead of:
template register=my-button interface=MyButton
/template
We allow:
script
var my = {views:{MyButton: ~}};
/script
template register=my-button interface=my.views.MyButton
/template
While this requires some variable to be exposed on the global scope,
libraries and frameworks do this already,
Hopefully though they won't do that any longer in the ES6 module world.
They had to be exposed on the global scope in some way otherwise they
couldn't be used, in future that will no longer be the case.
Are you proposing to provide some mechanism to declaratively define a custom
element inside a module?
How does a ES6 module end up having markup?
It doesn't. I don't like mixing the different resource types inside one file.
Whether that is a HTML file with JS inside it or a JS file with HTML inside it.
I feel they should be kept separate from each other as much as possible.
Especially since I have no need for the HTML markup in my ES6 module.
The current document.register signature requires,
TYPE, the custom element type of the element being registered
PROTOTYPE, the custom element prototype, optional
So I don't see what use the HTML markup would be to me.
If we look at the proposal we are talking about here the signature has
one extra parameter added,
TEMPLATEELEMENT, HTMLTemplateElement used as template for custom element.
again I'm not sure what I'd need the HTML markup for.
You may point out that I need the HTMLTemplateElement, which is true
and for that I'd really like
to use a mechanism that as a proficient ES6+ developer I'd be quite
familiar with.
javascript
import { myCustomElement } from my-customelement.html;
class MyCustomElement extends HTMLElement {
...
}
document.register('my-customelement', MyCustomElement, myCustomElement);
I think in fact that the import line can be made to work with the some
tweaks to the standard module loader.
I'd much prefer this over having a HTML file containing my code and
business logic stuck inside an antiquated IIFE.
With HTTP2.0/SPDY you can have your server push the CSS files related
to the custom element so they are in cache
when the element is created if browsers don't natively support the above code.
I'd build a dependency tree by using the module loader imports so that
any dependent custom elements are available.
Actually I'm not sure I'd use HTML imports at all if I had this...I'm
sure I'm missing some benefit they would provide?
P.S.
For extra fun you could import CSS in the same way and have it apply
in scoped fashion to different elements.
javascript
import CSSStyleSheetObject from my-customelement.css apply to myCustomElement;
import anotherCSSStyleSheetObject from my-application-styles.css
apply to document;
Once you have ES modules implemented this might be a quick addition
for a browser maker.
- R. Niwa
Re: [webcomponents] Auto-creating shadow DOM for custom elements
I'm just wondering what benefit is there in using custom elements if you don't use shadow dom or templates? If all we had was the custom elements spec would there be any appreciable gain for web developers without the other specs? I'm honestly curious as I'm not too familiar with the spec. On Sat, Dec 7, 2013 at 9:42 PM, Brendan Eich bren...@secure.meer.net wrote: What does polymer do? Cows are already treading paths. I still smell a chance to do better out of the gate (gave, thanks autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I think I taught Yehuda that one) doesn't help. Particular response, please. /be
Re: [webcomponents] Auto-creating shadow DOM for custom elements
Are they appreciatively more powerful then just building Angular directives though? Do they enable any functionality that you could not access without the custom elements spec? It looks like syntactic sugar for a dom tree to me (this dom tree is aliased by this element name), I like it but we can achieve that right now without a new spec. On Sat, Dec 7, 2013 at 10:16 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Brian Di Palma [mailto:off...@gmail.com] I'm just wondering what benefit is there in using custom elements if you don't use shadow dom or templates? If all we had was the custom elements spec would there be any appreciable gain for web developers without the other specs? I'm honestly curious as I'm not too familiar with the spec. As far as I can tell http://mozilla.github.io/brick/ is built entirely with custom elements and without any other web components technologies.
Re: [webcomponents] Auto-creating shadow DOM for custom elements
From your email it seems you can still achieve everything you can with custom elements when not using them, it would just involve more code/boilerplate. So custom elements without shadow dom or templates are syntactic sugar they don't enable functionality that is impossible currently? They make it much nicer and I really like it but I can manage without it and not be too stressed. Much like classes in ES6, they're great sugar but we've been able to do classes in JS since forever. I'm sure Brick is great and it looks lovely but no one in my work place is excited about it. Web Components in it's entirety though is a different matter and we are looking forward to them. Splitting it up into separate specs is good, but it's clear they combine with each other. Making it easy and painless to combine them seems like common sense. On Sat, Dec 7, 2013 at 10:37 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Brian Di Palma [mailto:off...@gmail.com] Are they appreciatively more powerful then just building Angular directives though? Do they enable any functionality that you could not access without the custom elements spec? Yes. There are at least two major benefits that I can see: 1) They allow you to create new HTMLElement-derived interfaces which are associated with the custom elements, so that you can do e.g. `document.querySelector(x-flipbox).toggle()` or `document.querySelector(x-flipbox).flipped` and so on. 2) They alert the parser of this new element, so that if you do `document.body.innerHTML = x-flipboxdivFront/divdivBack/div/x-flipbox`, this will be appropriately parsed so as to create a new flipbox with the associated behavior and interface. This effectively allows you to use the web's native widget abstraction, e.g. elements, instead of inventing your own. With something like jQuery UI or Angular, you need to access properties and methods through arcane invocations, e.g. $(document.querySelector(.my-slider)).slider(option, disabled, false); instead of document.querySelector(.my-slider).disabled = false; And if you add new elements via innerHTML, you'll have to do $(elementThatHadItsInnerHTMLChanged).find(.make-me-a-slider).slider(); to add the slider behavior, since there is no parser hook. (As for the Angular comparison, Angular tries to push you toward manipulating controllers and $scope objects, and never touching the DOM or DOM-esque widgets directly, so it's hard to really make such a comparison. Angular, more so than Polymer, seems to me like a good unifying cowpath to pave in the future.)
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Sat, Dec 7, 2013 at 11:07 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Brian Di Palma [mailto:off...@gmail.com] From your email it seems you can still achieve everything you can with custom elements when not using them, it would just involve more code/boilerplate. I don't see how you can draw that conclusion from my email, except perhaps the trivial everything can be implemented in terms of everything else in a Turing complete platform sense. Indeed, you could say that shadow DOM gives you nothing but syntactic sugar for a DOM access library that doesn't allow you to access things marked with a .shadowed class, and templates give you nothing more than script type=text/x-template. I guess you'd have to see how good the polyfill for each spec is. Can the shadow dom polyfill that Polymer uses give you the exact same power as the fully implemented spec in the browser? Much like a WeakMap can't be fully shimmed in ES5 there are issues shimming shadow dom, it's not just sugar, it's deeper. What about the custom elements polyfill? The shim for that spec doesn't seem to have any known limitations. It looks more like sugar. Everything is syntactic sugar at one level. But custom elements (by themselves) seem to add significant power by giving you parser hooks and allowing you to create, well, custom elements, which can be returned from standard browser methods like querySelector. Splitting it up into separate specs is good, but it's clear they combine with each other. Making it easy and painless to combine them seems like common sense. I think that there are many ways to combine the specs, and most of them are pretty darn easy already. Making one of them even easier by introducing the proposed coupling doesn't seem like a win. I'm not sure we will have an answer to whether this parameter/proposal is useful or not until people actually start making use of these specs in routine development. It's not a huge cost to waiting and seeing, it's a shimable and minor change after all.
Re: [webcomponents] Binding Custom Element without Polluting Global Scope (Was Proposal for Cross Origin Use Case and Declarative Syntax)
On Fri, Dec 6, 2013 at 3:24 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote:
On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov dglaz...@chromium.org wrote:
1) It is not friendly to ES6 classes. In fact, you can't use class syntax
and this syntax together.
Okay, let the author define the constructor.
3) The approach pollutes global name space with constructors. This had been
voiced many times as unacceptable by developers.
We can solve this problem by using JavaScript object path as opposed to a
variable name.
So instead of:
template register=my-button interface=MyButton
/template
We allow:
script
var my = {views:{MyButton: ~}};
/script
template register=my-button interface=my.views.MyButton
/template
While this requires some variable to be exposed on the global scope,
libraries and frameworks do this already,
Hopefully though they won't do that any longer in the ES6 module world.
They had to be exposed on the global scope in some way otherwise they
couldn't be used, in future that will no longer be the case.
and authors could use
document.register to avoid that altogether if they really wanted.
- R. Niwa
Re: [webcomponents] Auto-creating shadow DOM for custom elements
On Fri, Dec 6, 2013 at 1:37 AM, Ryosuke Niwa rn...@apple.com wrote:
Hi,
Given that many important/natural use cases of custom elements involve
shadow DOM,
can we add a flag to auto-create shadow DOM for custom elements?
In particular, can we add template as the third argument to
document.register so that
when a custom element is instantiated, the specified template is
automatically closed
I guess you mean automatically cloned?
This does seems like a nice suggestion, as an optional parameter, the
cloning code is repeated
in most examples and it would be nice to remove this boilerplate.
and inserted into a shadow DOM of the custom element.
e.g. using ES6 class syntax:
template id=myButtonTemplate
buttonHi!/button
/template
script
class MyButton extends HTMLElement {
...
}
document.register('my-button', MyButton, myButtonTemplate);
/script
Given that the shadow DOM specification is relatively stable if we constrain
ourselves to
only custom elements (i.e. ignoring all builtin elements), adding this
mechanism will allow
us to move the custom elements and shadow DOM specifications forward without
risking
to expose the general API for attaching shadow DOM to the Web.
- R. Niwa
Re: Styling form control elements
If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. I know it sounds wasteful but I'd imagine that the best ones would end up being reused much like jQuery UI widgets are today. In that case does this difficult problem need to be solved? On Fri, Dec 6, 2013 at 4:12 AM, Ryosuke Niwa rn...@apple.com wrote: On Dec 5, 2013, at 3:15 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 5 Dec 2013, Jonas Sicking wrote: I think both are issues. I.e. I think we have two separate use cases: 1. Enable using the built-in rendering of form controls, but style them using author-supplied CSS. 2. Enable completely replacing the rendering of form controls I think 1 is *really* hard. Maybe hard enough that we can't do it. But I think it would help the web a lot if we could pull it off, so I think we should try. I think there are simple cases we can address like changing the color of placeholder text, etc... And I think is=... is the wrong solution for 2. As is wrapping the control with custom elements. You should be able to attach a replacement style using CSS. This is what decorators is, which so far no one is working on afaict. Agreed. Agreed. On Dec 5, 2013, at 1:42 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 5 Dec 2013, Ryosuke Niwa wrote: On Dec 5, 2013, at 8:49 AM, Ian Hickson i...@hixie.ch wrote: On the other hand, this still doesn't tell UA whether it should be ignoring the binding on a given platform or not (i.e. it doesn't address the device-specific UI control use case). Yeah. I don't know of a way to fix that. Indeed, this is a hard problem. My point was simply that using shadow DOM or custom element wouldn't magically solve this problem. The problem you're worried about is one that we _do_ have today on mobile devices with sites that aren't designed with mobile devices in mind, just not particularly for form control styling. For example, page widths, input events, all kinds of things like that, make Web pages break on mobile, or look bad on mobile. Any solution we come up with for the general problem should, in theory, be able to solve the problem for this specific subcase too. Agreed. On the other hand, using CSS for binding shadow DOM has a culprit that instantiation life-cycle of such shadow DOM becomes a tricky issue. i.e. spec'ing exactly when those shadow DOM bind unbind would be tricky. Yes. But we shouldn't shy away from hard problems. ;-) Agreed. Perhaps you could write a spec for us? ;) - R. Niwa
Re: Styling form control elements
On Fri, Dec 6, 2013 at 12:59 PM, Scott González scott.gonza...@gmail.com wrote: On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote: If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. And you'll make the experience worse for many users because many users have devices that you actually don't want to replace. Also, all the other problems about validation, semantics, etc. I did mention that these would probably be turned into reusable components in widget libraries. If they hope to be used by developers I see no reason why the issues you raised would not be addressed by those libraries.
Re: Styling form control elements
On Fri, Dec 6, 2013 at 4:00 PM, Scott González scott.gonza...@gmail.com wrote: On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote: I did mention that these would probably be turned into reusable components in widget libraries. If they hope to be used by developers I see no reason why the issues you raised would not be addressed by those libraries. Are you aware of libraries addressing these issues today? As mentioned multiple times already, there is nothing to inform a developer what UI/UX will be most effective. This is why the best we can do right now is leave certain devices alone while using custom UIs for other devices. But we don't know (in code) which devices those are. Unless I'm misunderstanding you I think places like http://component.io/ have some nice widgets. Some of which are able to play nicely in both mobile and desktop environments, they might be simple i.e. http://component.io/ghinda/css-toggle-switch but they can do the job. It doesn't seem a significant hurdle to create your own or to use a third party control if browser's aren't as flexible as required. It's not ideal either though.
Re: [webcomponents] HTML Imports
To be fair though Web Components are bleeding edge and the vast majority of developers have had no interaction with them at all. I work in a company that should see huge benefits from Web Components as we build large scale browser applications and not one developer has had the time to investigate Web Components properly. I have even heard our developers say that Web Components are only for small widgets like buttons and aren't designed for anything large scale, basically a glorified button element. People are busy and have jobs to do, I'd love to provide good feedback on Web Components but time is a constraint. I would say though that I get the feeling that Web Components seems a specification that seems really pushed/rushed and I worry that might lead to some poor design decisions whose side effects will be felt by developers in the future. Are we sure #include is what the web wants/needs? On Wed, Dec 4, 2013 at 4:02 AM, Eric Bidelman ericbidel...@google.com wrote: On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 7, 2013, at 12:24 PM, Rafael Weinstein rafa...@google.com wrote: On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.uk wrote: On 06/10/13 17:25, Dimitri Glazkov wrote: And, if the script is executed against the global/window object of the main document, can and should you be able to access the imported document? You can and you should. HTML Imports are effectively #include for the Web. Yes, that sounds like a good description of the problem :) It is rather noticable that no one making programming languages today replicates the #include mechanism, and I think html-imports has some of the same design flaws that makes #include unpopular. I think authors will find it very hard to write code in an environment where simple functions like document.getElementById don't actually work on the document containing the script, but on some other document that they can't see. It also seems that the design requires you to be super careful about having side effects; if the author happens to have a non-idempotent action in a document that is imported, then things will break in the relatively uncommon case where a single document is imported more than once. We have an orthogonal mechanism for preventing side-effects: The HTML Template Element. Imports do not prevent side-effects implicitly. This is Good. Authors have control over the semantics they need. Want to include some DOM -- use imports, need some fragment of that to not have side effects -- put it in a template. I don't think template element solves that problem if we're talking about scripts that need to run as soon as the document is imported. On Oct 9, 2013, at 10:42 AM, Scott Miles sjmi...@google.com wrote: On Mon, Oct 7, 2013 at 3:24 AM, James Graham ja...@hoppipolla.co.uk wrote: On 06/10/13 17:25, Dimitri Glazkov wrote: And, if the script is executed against the global/window object of the main document, can and should you be able to access the imported document? You can and you should. HTML Imports are effectively #include for the Web. Yes, that sounds like a good description of the problem :) It is rather noticable that no one making programming languages today replicates the #include mechanism, and I think html-imports has some of the same design flaws that makes #include unpopular. I think authors will find it very hard to write code in an environment where simple functions like document.getElementById don't actually work on the document containing the script, but on some other document that they can't see. It's true we are introducing something new, but this actually one of The Good Parts. Imports are not the main document, they are satellite to the main document. The main document maintains primacy, but your imports can act on it. So far, we haven't really had any problems with developers on this point. We should be asking this question to an average Web developer who has never heard of HTML imports before. I speak with web developers on a regular basis. Most are agreeable with distinction and generally positive about the possibilities it opens up. http://robdodson.me/blog/2013/08/20/exploring-html-imports/ It also seems that the design requires you to be super careful about having side effects; if the author happens to have a non-idempotent action in a document that is imported, then things will break in the relatively uncommon case where a single document is imported more than once. Can you give an example of a non-idempotent, potentially breaking action? e.g. defining a global variable. Overall it feels like html imports has been designed as an over general mechanism to address certain narrow use cases and, in so doing, has handed authors a footgun. I guess I would instead suggest that generality of HTML Imports is due to the group attempting to find a virtuous
Re: [webcomponents] HTML Imports
I never meant my comments to be taken as a slight toward anyone involved in the Web Components work. Neither did I mean it to be taken to mean This work is rushed. I said, I get the feeling that Web Components seems a specification that seems really pushed/rushed, by that I meant it seemed as if the current spec is being pushed as fast as possible toward standardization. I was not commenting on the amount of time put into making the spec but more the amount of time given to interested parties to digest, implement, and comment on it. I believe Dimitri has responded to comments to this effect by extending the time between spec transitions. I'm very excited by the possibilities that Web Components open up. I would love to see the representatives from all the implementers as excited or convinced about the spec. On Wed, Dec 4, 2013 at 7:30 PM, Rafael Weinstein rafa...@google.com wrote: On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma off...@gmail.com wrote: I would say though that I get the feeling that Web Components seems a specification that seems really pushed/rushed and I worry that might lead to some poor design decisions whose side effects will be felt by developers in the future. I very much share this sentiment. It's a very reasonable and normal worry to have. I lose sleep over this worry all the time. The trick that helps me is balancing it out with the sadness of the geological timescale that it takes for Web platform to advance. Just to help visualize the geological timescale, the work on Web Components began in late 2010 (http://wiki.whatwg.org/index.php?title=Component_Model_Use_Casesoldid=5631), and was chartered in this WG over 2 years ago (http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed). To clarify my previous email: Web Components is an extremely hard problem with lots of constraints, and a concern would be that we miss some bits is totally fair. Qualifying this work as pushed/rushed probably ain't. I'd like to make an aside about having respect for one-another's work. Dimitri, Alex, Dominic, Scott, Elliot and many others have put massive time into this problem over the course of many years now, and my view is that the design has evolved and accommodated a dizzying number of challenges and constraints. What this is attempting is big scary is fair. I haven't had time to digest the design is fair. I have the following specific issues is fair. This work is rushed is always understood as an indictment. I've seen too many talented people vote with their feet and decide life will be less frustrating working on a closed system. Let's remember we're all on the same team. AFAICT, evolving the web is fundamentally an exercise in not letting perfect be the enemy of good. I have no doubt Web Components is imperfect, but from what I can tell, it is *extremely* good. Also, go hug your mother. :DG
Re: [HTML Imports]: what scope to run in
On Tue, Nov 19, 2013 at 10:16 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Mon, Nov 18, 2013 at 11:26 PM, Ryosuke Niwa rn...@apple.com wrote:
We share the concern Jonas expressed here as I've repeatedly mentioned on
another threads.
On Nov 18, 2013, at 4:14 PM, Jonas Sicking jo...@sicking.cc wrote:
This has several downsides:
* Libraries can easily collide with each other by trying to insert
themselves into the global using the same property name.
* It means that the library is forced to hardcode the property name
that it's accessed through, rather allowing the page importing the
library to control this.
* It makes it harder for the library to expose multiple entry points
since it multiplies the problems above.
* It means that the library is more fragile since it doesn't know what
the global object that it runs in looks like. I.e. it can't depend on
the global object having or not having any particular properties.
Or for that matter, prototypes of any builtin type such as Array.
* Internal functions that the library does not want to expose require
ugly anonymous-function tricks to create a hidden scope.
IMO, this is the biggest problem.
Many platforms, including Node.js and ES6 introduces modules as a way
to address these problems.
Indeed.
At the very least, I would like to see a way to write your
HTML-importable document as a module. So that it runs in a separate
global and that the caller can access exported symbols and grab the
ones that it wants.
Though I would even be interested in having that be the default way of
accessing HTML imports.
Yes! I support that.
I don't know exactly what the syntax would be. I could imagine something
like
In markup:
link rel=import href=... id=mylib
Once imported, in script:
new $('mylib').import.MyCommentElement;
$('mylib').import.doStuff(12);
or
In markup:
link rel=import href=... id=mylib import=MyCommentElement doStuff
Once imported, in script:
new MyCommentElement;
doStuff(12);
How about this?
In the host document:
link ref=import href=foo.js import=foo1 foo2
script
foo1.bar();
foo2();
/script
In foo.js:
module foo1 {
export function bar() {}
}
function foo2() {}
Inline module syntax was removed and will not be included in the ES6 module
specification. Furthermore, the example you've illustrated here isn't
entirely valid, but the valid parts are already covered within the scope of
ES6 modules:
// in some HTML...
script
import {foo1, foo2} from foo;
foo1();
foo2();
/script
// foo.js
export function foo1() {}
export function foo2() {}
(note that foo2 isn't exported in your example, so would be undefined)
Rick
I thought if an identifier wasn't exported trying to import it would
result in fast failure (SyntaxError)?
Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax
I'm not sure I would want jQuery UI to pollute the window object with $, with ES6 modules around the corner it seems like a step backwards for imports to start polluting window objects with their libraries... On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn espr...@gmail.com wrote: On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa rn...@apple.com wrote: [...] Script in the import is executed in the context of the window that contains the importingdocument. So window.document refers to the main page document. This has two useful corollaries: functions defined in an import end up on window. you don't have to do anything crazy like append the import's script blocks to the main page. Again, script gets executed. What we’re proposing is to execute the script in the imported document so the only real argument is the point that “functions defined in an imported end up on window” (of the host document). I think that’s a bad thing. We don’t want imported documents to start polluting global scope without the user explicitly importing them. e.g. import X in Python doesn’t automatically import stuff inside the module into your global scope. To do that, you explicitly say “import * from X”. Similarly, “using std” is discouraged in C++. I don’t think the argument that this is how external script and stylesheet fly either because the whole point of web components is about improving the modularity and reusability of the Web. What you're proposing breaks a primary use case of: link rel=import href=//apis.google.com/jquery-ui.html Authors don't want to list every single component from jQuery UI in the import directive, and they don't want the jQuery UI logic to be in a different global object. They want to be able to import jQuery UI and have it transitively import jQuery thus providing $ in the window in addition to all the widgets and their API. ex. body.appendChild(new JQUIPanel()).showPanel(). Note also that using a different global produces craziness like Array being different or the prototypes of nodes being different. You definitely don't want that for the same origin or CORS use case. Fortunately, there is already a boundary that we built that might be just the right fit for this problem: the shadow DOM boundary. A while back, we had lunch with Mozilla security researchers who were interested in harnessing the power of Shadow DOM, and Elliott (cc'd) came up with a pretty nifty proposal called the DOMWorker. I nagged him and he is hopefully going to post it on public-webapps. I am pretty sure that his proposal can address your use case and not cripple the rest of the spec in the process. Assuming you’re referring to https://docs.google.com/document/d/1V7ci1-lBTY6AJxgN99aCMwjZKCjKv1v3y_7WLtcgM00/edit, the security model of our proposal is very similar. All we’re doing is using a HTML-imported document instead of a worker to isolate the cross-origin component. Since we don’t want to run the cross-origin component on a separate thread, I don’t think worker is a good model for cross-origin components. A DOMWorker doesn't run on another thread, see the Note in the introduction. - E
Re: HTML as application manifest format
I've no experience of the previous XML manifest files but I must admit that I find the arguments for HTML quite persuasive. My default and original position would have been for JSON. I know that I for one will now be more open toward using HTML as a data definition format in my own work. On Tue, Aug 6, 2013 at 6:31 PM, Kornel Lesiński kor...@geekhood.net wrote: On Thu, 01 Aug 2013 17:57:20 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; The ugly part is current lack of support for nested groups of metatags, but HTML is pretty good at nesting in general, so this can be fixed easily (I've proposed metagroup and permission in passing). OTOH JSON is by design set in stone, so you can't relax parsing even to fix the merge-conflict-inducing trailing comma, you can't add language attribute to values, you can't add proper comments. Here's a very interesting post about hacking JSON format, motivated by pains of using JSON for configuration: http://fadefade.com/json-comments.html Comments are irrelevant for data serialization/exchange when JSON is spit by software (and this is where JSON shines), but become a necessity in files that humans have to carefully maintain. When files are written by hand (and config files most often are) people can abuse the syntax. The comment hack proposed in aforementioned article makes JSON-with-comments incompatible with ES5 JSON and turns underspecified quirk and implementation detail into de-facto standard. JSON left out comments deliberately to avoid deteriorating by having a hacky extension point, and now a hacky extension point has been found... you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. Actually, if I could define app's metadata and web components all in one file that would be awesome: link rel=import manifest href=/ (and for added awesomeness I'd make that file my homepage, so I can have self-contained 1-request web app, and subpages that get the manifest and components from the page that is most likely to be cached). This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. JSON is fantastic for bare key/value transmission (uncommented, unlocalized automatic data dump), but manifest is not just a basic key/value transmission. Locales tree-patching-dictionary in the spec shows that manifest already has impedance mismatch with JSON data model. -- regards, Kornel
Re: [webcomponents]: When element is having a bad time
The linking stage would be a stage where all that happens is the registration of custom elements. No custom element code would execute, there is no need to dereference the parent prototype. All that happens is the loading of resources. ES6 modules are meant to handle dependencies, it's in their design. So instead of depending on a global custom element you hope has been loaded you can import a HTML module. Referencing an unbound global variable will throw a SyntaxError. ES6 modules will also have a linking stage. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 On Wed, Jul 31, 2013 at 5:50 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Jul 31, 2013 at 9:23 AM, Brian Di Palma off...@gmail.com wrote: Is it not possible to have a linking stage before a compile stage? Can you help me understand this idea? I don't quite get the definitions of linking and compile when applied to Web platform. Or to use ES6 modules so that elements must import the prototypes they inherit from or a SyntaxError is thrown? How do modules help here? Can you elaborate a bit? :DG
