Re: [webcomponents]: First stab at the Web Components spec
Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit : Here's a first rough draft of the Web Components spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Cool. I see link rel=component href=/components/heart.html Do you plan to allow the HTTP counterpart? Link: /components/heart.html; rel=component -- Karl Dubost http://www.la-grange.net/karl/
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost k...@la-grange.net wrote: Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit : Here's a first rough draft of the Web Components spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Cool. I see link rel=component href=/components/heart.html Do you plan to allow the HTTP counterpart? Link: /components/heart.html; rel=component Does that need to be allowed? I thought the Link header was just equivalent, in general, to specify a link in your head. ~TJ
Re: [webcomponents]: First stab at the Web Components spec
On Mar 18, 2013 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost k...@la-grange.net wrote: Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit : Here's a first rough draft of the Web Components spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Cool. I see link rel=component href=/components/heart.html Do you plan to allow the HTTP counterpart? Link: /components/heart.html; rel=component Does that need to be allowed? I thought the Link header was just equivalent, in general, to specify a link in your head. ~TJ Just bringing this up on list as it has come up in conversations offlist: while not currently valid.for htmk, link for Web components will work in the body too? #justcheckin
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 18, 2013 at 7:51 AM, Brian Kardell bkard...@gmail.com wrote: On Mar 18, 2013 10:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost k...@la-grange.net wrote: Le 7 mars 2013 à 18:25, Dimitri Glazkov a écrit : Here's a first rough draft of the Web Components spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html Cool. I see link rel=component href=/components/heart.html Do you plan to allow the HTTP counterpart? Link: /components/heart.html; rel=component Does that need to be allowed? I thought the Link header was just equivalent, in general, to specify a link in your head. Just bringing this up on list as it has come up in conversations offlist: while not currently valid.for htmk, link for Web components will work in the body too? #justcheckin Again, I don't think that's something anyone gets a choice on. HTML defines how link-in-body works, iirc. ~TJ
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 18, 2013 at 10:46 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 18, 2013 at 7:35 AM, Karl Dubost k...@la-grange.net wrote: Do you plan to allow the HTTP counterpart? Link: /components/heart.html; rel=component Does that need to be allowed? I thought the Link header was just equivalent, in general, to specify a link in your head. But it's not entirely clear we want to support HTTP Link long term yet, so yes. And I think that no, we don't want to do that for now as the web platform has no dependency on HTTP Link thus far. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Wed, Mar 13, 2013 at 5:41 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Mar 12, 2013 at 4:53 PM, Dimitri Glazkov dglaz...@google.com wrote: Yup, been doing this for a while now. The stylesheet-like behavior seems to have settled as the least evil of the compromises. It's an over-constrained problem, as usual :) If applications have issues with performance because of this today, how is increasing the number of external resources that exhibits this behavior going to help? I am glad you're asking this question. It's been burning in the back of my head for years now and I haven't gotten many good answers. If we make components load completely asynchronously, we will have the problem of creating instances of custom elements whose definitions haven't loaded yet. The only solution to that problem is element upgrade (that is, the equivalent of renameNode), and it will most definitely eat all (and more) of your performance gains from asynchronous loads. At least, with stylesheet-like load, a webdev can use good judgement and take advantage the fact that the components are fetched and processed asynchronously. The sad truth is that most apps will probably choose to inline most (if not all) component documents into the master document for their production builds. At this point, I am primarily hoping to help in 2 ways: 1) make it possible to achieve nice modularity in a development (or any other non-mission critical) build, so that the webdevs don't need to use complex and varying packaging shims that often use document.write and other crazy hacks to get the right behavior; 2) make inlining as close to just concatenating files as possible. What's the scenario if there's a script before link rel=component or you insert link rel=component at some later point in time? script before link rel=component is fairly straightforward, right? script runs first, then link rel=component is fetched. Dynamically inserting link rel=component is interesting. Logically, it should be equivalent to synchronously fetching and processing the component document. :DG
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 11, 2013 at 8:00 PM, Dimitri Glazkov dglaz...@google.com wrote: The resources will only block script (just like CSS: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21218), so there's definitely opportunity for parallelism. Blocking script for CSS is seen as a large pita and I've heard requests for ways to prevent that (e.g. with link rel=stylesheet async). Expanding the set of external resources that does that does not seem like a great idea to me. I am not sure how the message port thing will work. Never mind that suggestion. We can't have an async DOM (yet). b) making sub-resources not block on script sort of ruins my plan for integrating element registration. If there's no blocking script, I have no assurances that the elements in subresources are registered before script starts running, which means that we'll have to do something like element upgrade, which I worked pretty hard to remove :) I recommend discussing this with the HTML parser crowd and performance crowd. I would've thought we would not want to repeat mistakes made in the past. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Tue, Mar 12, 2013 at 3:46 AM, Anne van Kesteren ann...@annevk.nl wrote: I recommend discussing this with the HTML parser crowd and performance crowd. I would've thought we would not want to repeat mistakes made in the past. Yup, been doing this for a while now. The stylesheet-like behavior seems to have settled as the least evil of the compromises. It's an over-constrained problem, as usual :) :DG
Re: [webcomponents]: First stab at the Web Components spec
On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles sjmi...@google.com wrote: My issue is that the target of this link will not in general be an atomic thing like a 'component' or a 'module'. It's a carrier for resources and links to other resources. IMO this is one of the great strengths of this proposal. To go on the record: I like link rel=component and calling these components. Initially I was confused too; I have heard people casually refer to custom elements as components. But it makes sense to treat these are discrete concepts: Components are the units of reuse. Although they're not atomic they should ideally be a usable unit which references all of its dependencies. Custom elements are the units of instantiation. One component may contain be comprised of many custom elements. For this reason, when it was rel=components (plural) there was no problem for me. Having said all that, I'm not particularly up in arms about this issue. The name will bend to the object in the fullness of time. :) S On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton phi...@philipwalton.comwrote: Personally, I had no objection to rel=component. It's similar in usage to rel=stylesheet in the fact that it's descriptive of what you're linking to. On the other hand, rel=include is very broad. It could just as easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) +1, I like rel=component, document or include doesn't make sense. - E -- Email SLA http://goto.google.com/dc-email-sla • Google+https://plus.sandbox.google.com/111762620242974506845/posts
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov dglaz...@google.com wrote: That's not the problem, that's a feature :) Think of it as a template tag for documents. I'd think that author expectations would be different given how external CSS resources work, but maybe. As for the API, do we really want that to be a synchronous API? That seems future-hostile for two reasons: we want to do more in parallel (Servo) and we definitely do not want cross-origin to be synchronous in this manner I think. Maybe it's better if we provide message port access between the Document objects? And if this is mostly for applying components to documents, maybe we should not expose API for that so that it the declarative way can be optimized. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 11, 2013 at 10:14 AM, Anne van Kesteren ann...@annevk.nlwrote: On Fri, Mar 8, 2013 at 6:53 PM, Dimitri Glazkov dglaz...@google.com wrote: That's not the problem, that's a feature :) Think of it as a template tag for documents. I'd think that author expectations would be different given how external CSS resources work, but maybe. As for the API, do we really want that to be a synchronous API? That seems future-hostile for two reasons: we want to do more in parallel (Servo) and we definitely do not want cross-origin to be synchronous in this manner I think. Maybe it's better if we provide message port access between the Document objects? And if this is mostly for applying components to documents, maybe we should not expose API for that so that it the declarative way can be optimized. The resources will only block script (just like CSS: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21218), so there's definitely opportunity for parallelism. I am not sure how the message port thing will work. a) It sounds icky from developer ergonomics perspective and b) making sub-resources not block on script sort of ruins my plan for integrating element registration. If there's no blocking script, I have no assurances that the elements in subresources are registered before script starts running, which means that we'll have to do something like element upgrade, which I worked pretty hard to remove :) :DG
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda rgi...@chromium.org wrote: rel=include ? And Inclusions as the name? Or HTML Inclusions? This could work. Any objections or better names? Rob might just win this one. :DG
Re: [webcomponents]: First stab at the Web Components spec
Personally, I had no objection to rel=component. It's similar in usage to rel=stylesheet in the fact that it's descriptive of what you're linking to. On the other hand, rel=include is very broad. It could just as easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) On Mon, Mar 11, 2013 at 2:28 PM, Dimitri Glazkov dglaz...@google.comwrote: On Fri, Mar 8, 2013 at 1:47 PM, Robert Ginda rgi...@chromium.org wrote: rel=include ? And Inclusions as the name? Or HTML Inclusions? This could work. Any objections or better names? Rob might just win this one. :DG
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton phi...@philipwalton.comwrote: Personally, I had no objection to rel=component. It's similar in usage to rel=stylesheet in the fact that it's descriptive of what you're linking to. On the other hand, rel=include is very broad. It could just as easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) +1, I like rel=component, document or include doesn't make sense. - E
Re: [webcomponents]: First stab at the Web Components spec
My issue is that the target of this link will not in general be an atomic thing like a 'component' or a 'module'. It's a carrier for resources and links to other resources. IMO this is one of the great strengths of this proposal. For this reason, when it was rel=components (plural) there was no problem for me. Having said all that, I'm not particularly up in arms about this issue. The name will bend to the object in the fullness of time. :) S On Mon, Mar 11, 2013 at 3:35 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton phi...@philipwalton.comwrote: Personally, I had no objection to rel=component. It's similar in usage to rel=stylesheet in the fact that it's descriptive of what you're linking to. On the other hand, rel=include is very broad. It could just as easily apply to a stylesheet as a Web component, and may limit the usefulness of the term if/when future rel values are introduced. (p.s. I'm new to this list and haven't read through all the previous discussions on Web components. Feel free to disregard this comment if I'm rehashing old topics) +1, I like rel=component, document or include doesn't make sense. - E
Re: [webcomponents]: First stab at the Web Components spec
On Mon, Mar 11, 2013 at 4:39 PM, Scott Miles sjmi...@google.com wrote: My issue is that the target of this link will not in general be an atomic thing like a 'component' or a 'module'. It's a carrier for resources and links to other resources. IMO this is one of the great strengths of this proposal. For this reason, when it was rel=components (plural) there was no problem for me. Having said all that, I'm not particularly up in arms about this issue. The name will bend to the object in the fullness of time. :) I guess that doesn't bother me because rel=stylesheet isn't just one stylesheet either, you can @import lots of them down there. :) Similarly when I think of a component I don't think of one custom widget, I think of lots of logically related bundled things. - E
Re: [webcomponents]: First stab at the Web Components spec
On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov dglaz...@google.com wrote: Please look over it. I look forward to your eagle-eyed insights in the form of bugs and emails. You try to monkey patch the obtain algorithm but in doing so you invoke a different fetch algorithm. One which does not expose resources as CORS-cross-origin. Also, for rel=component tainted resources make no sense, so we should only use No CORS in combination with fail. Why is Component not simply a subclass of Document? If you already have a Document object you might as well use that directly... Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. Can't we just put all the component stuff in one specification? I find the whole organization quite confusing. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 6:03 PM, Dimitri Glazkov dglaz...@google.com wrote: I just mirrored LinkStyle (http://dev.w3.org/csswg/cssom/#the-linkstyle-interface) here. Given that document already has URL, you're right -- I don't need the Component interface at all. LinkComponent could just have a content attribute that returns Document. Also, there's no need for sub-classing anything. Components are just documents. https://www.w3.org/Bugs/Public/show_bug.cgi?id=21225 If you still want to point to the embedding element though you'll need to subclass Document in some way, but maybe that is not needed for now. Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. Can't we just put all the component stuff in one specification? I find the whole organization quite confusing. Components don't directly correlate with custom elements. They are just documents that you can load together with your document. With things like multi-threaded parser, these are useful on their own, even without custom elements. Because they don't have an associated browsing context? What other use case are you describing here? That seems like a potential problem by the way. That subresources from such a document such as img will not load because there's no associated browsing context. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 10:41 AM, Anne van Kesteren ann...@annevk.nl wrote: Components don't directly correlate with custom elements. They are just documents that you can load together with your document. With things like multi-threaded parser, these are useful on their own, even without custom elements. Because they don't have an associated browsing context? What other use case are you describing here? That seems like a potential problem by the way. That subresources from such a document such as img will not load because there's no associated browsing context. That's not the problem, that's a feature :) Think of it as a template tag for documents. The author can stash all of the markup that they don't need to render on loading into components, and then use it when necessary as they need it. An easy example: suppose my webapp has multiple states/views that the user goes through in random order. With components, I can leave the starting view in master document, and move the rest into (multiple, if needed) components. As I need the view, I simply grab it and move it to the master document. :DG
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell sorv...@google.com wrote: I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? Then we probably need to rename link rel=module for consistency? :DG
Re: [webcomponents]: First stab at the Web Components spec
Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. On Fri, Mar 8, 2013 at 12:24 PM, Dimitri Glazkov dglaz...@google.comwrote: On Fri, Mar 8, 2013 at 12:22 PM, Steve Orvell sorv...@google.com wrote: I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? Then we probably need to rename link rel=module for consistency? :DG
Re: [webcomponents]: First stab at the Web Components spec
Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. I also find the name confusing. It's common to use the term 'component' when describing the functionality of a custom element. What about HTML Modules? On Fri, Mar 8, 2013 at 1:19 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Mar 7, 2013 at 11:25 PM, Dimitri Glazkov dglaz...@google.com wrote: Please look over it. I look forward to your eagle-eyed insights in the form of bugs and emails. You try to monkey patch the obtain algorithm but in doing so you invoke a different fetch algorithm. One which does not expose resources as CORS-cross-origin. Also, for rel=component tainted resources make no sense, so we should only use No CORS in combination with fail. Why is Component not simply a subclass of Document? If you already have a Document object you might as well use that directly... Also, it sounds like this specification should be titled Fetching components or some such as that's about all it defines. Can't we just put all the component stuff in one specification? I find the whole organization quite confusing. -- http://annevankesteren.nl/
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell sorv...@google.com wrote: Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents]: First stab at the Web Components spec
rel=include ? On Fri, Mar 8, 2013 at 1:05 PM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell sorv...@google.com wrote: Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents]: First stab at the Web Components spec
yes, it actually is document related to current document... does not seem confusing to me at all, but I can go with fragment or stub as well :] B. On 8.3.2013 22:25, Dimitri Glazkov wrote: On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles sjmi...@google.com wrote: Agree. Seems like Dimitri and Anne decided that these targets are 'document', did they not? rel=document seems to communicate that the relation of the linked resources to the document is document, which is at least cyclical if not totally wrong :) :DG
Re: [webcomponents]: First stab at the Web Components spec
On Fri, Mar 8, 2013 at 1:15 PM, Scott Miles sjmi...@google.com wrote: Agree. Seems like Dimitri and Anne decided that these targets are 'document', did they not? rel=document seems to communicate that the relation of the linked resources to the document is document, which is at least cyclical if not totally wrong :) :DG
Re: [webcomponents]: First stab at the Web Components spec
Agree. Seems like Dimitri and Anne decided that these targets are 'document', did they not? Scott On Fri, Mar 8, 2013 at 1:12 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: hi let's apply KISS here how about just rel=document or rel=htmldocument Brona On 8.3.2013 22:05, Dimitri Glazkov wrote: On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell sorv...@google.com wrote: Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
Re: [webcomponents]: First stab at the Web Components spec
hi let's apply KISS here how about just rel=document or rel=htmldocument Brona On 8.3.2013 22:05, Dimitri Glazkov wrote: On Fri, Mar 8, 2013 at 12:30 PM, Steve Orvell sorv...@google.com wrote: Indeed. Unfortunately, using 'module' here could be confusing wrt ES6 modules. Perhaps package is better? The name is difficult. My main point is that using components causes unnecessary confusion. I understand. Welcome to the 2013 Annual Naming Contest/bikeshed. Rules: 1) must reflect the intent and convey the meaning. 2) link type and name of the spec must match. 3) no biting. :DG
[webcomponents]: First stab at the Web Components spec
Hello fellow web-appanauts, The day you've been waiting for had finally arrived (or not, depending on the type of day been waiting for). Here's a first rough draft of the Web Components spec: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/components/index.html This spec looks really small, and I am really hoping to keep it that way. Thanks to Ian's excellent HTML spec (which allowed plugging most of the existing behaviors straight in) and delegating most of the heavy lifting to other specs under Web Components umbrella, there's very little left in the actual bell cap. Things missing: * somehow processing element elements when loading components. * unfixed bugs * examples and nicer intro Please look over it. I look forward to your eagle-eyed insights in the form of bugs and emails. :DG
