On Tue, Mar 12, 2013 at 8:39 AM, Scott Miles <sjmiles@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 <esprehn@gmail.com> wrote: > >> >> On Mon, Mar 11, 2013 at 2:45 PM, Philip Walton <philip@philipwalton.com>wrote: >> >>> 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>
Received on Wednesday, 13 March 2013 05:46:22 UTC