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>