Re: Namespacing Components

On Tue, Jun 25, 2013 at 1:55 AM, <merrick.christensen@gmail.com> wrote:

> Fair enough, what do you propose as a solution,
>

I haven't come up with anything that is workable yet.


> perhaps applying some sort of scoped attribute to indicate something is
> scoped to a subtree?
>

Usually how programming languages get around this is by letting the
importing module do renaming. For example in C# you write using Foo =
Some.Library; or in Haskell (in the limit) import qualified Some.Library as
Foo where "Foo" is at the whim of the importing module.

The problem is that the document forms one flat namespace for Custom
Elements. Whenever you attempt to carve that up into scopes, you run into
weirdness when an element moves from one scope to another. Weirdness like
breaking round-tripping with innerHTML/outerHTML. (I note that if you
create a type extension custom element and delete its "is" attribute,
serialization is broken too. But maybe that is a spec bug. Even if not, I
am pretty sure web authors will adopt the practice of "don't do that.")

I think HTML Imports provides a better vehicle for scoping than Shadow DOM,
because HTML Imports have their own document, which is a rich object that
nodes have a strong association with; there's already a well-specified
point in time ("adoption") for moving from one document to another. I could
imagine doing alpha-renaming when nodes are adopted into a different
document, for example.

A couple of problems are that will beget element creation (if we need to
"rename" an tag name) and author scripts in the Import will have to be very
careful to detect whether they're working in the imported document (use the
intrinsic name) or the importing document (somehow work out the renamed
name.)

Here's a strawman, everyone, please direct your tomatoes in my direction:

The HTML Imports specification gains some attribute for renaming:

<link rel="import" as="foo-" href="acme-widgets.html">

In HTML there's some magic character that you can use to say "insert
prefix:"

<☃tab-strip>, document.createElement('☃tab-strip')

(I'm using the snowman here because this is such a cool proposal.) The
replacement of ☃ would depend on the ownerDocument, when parsing, and the
document that contains the script, when running script.

Sub-imports could chose to transmit the prefix, if the sub-import is part
of the same logical library:

<link rel="import" as="☃" href="acme-frozzler.html">

Or they could chose something concatenative if the sub-import is used by
this library, but should not be exposed by it:

<link rel="import" as="acme-private-☃" href="scumco-frozzle-agitator.html">

Alternative strawman: As above, but you can't write ☃ literally; instead
there is an implicit ☃ in every tag name and every "as" attribute.

Glad to hear you agree it is a problem. :-)
>
> M
>
>
>
> On Jun 24, 2013, at 9:10 AM, Dominic Cooney <dominicc@google.com> wrote:
>
> On Fri, Jun 21, 2013 at 6:32 AM, <merrick.christensen@gmail.com> wrote:
>
>> ## Namespaced Web Components
>>
>> One of the biggest problems working with Angular.js, Ember, and Web Components is that by nature each component is essentially a global token. I am concerned with this direction especially when it comes to web components and would like to open some discussion to resolve the problem.
>>
>> I agree that this is a problem.
>
>> Globals are globals, that is as true in declarative code as it is in imperative code. In a large application it is not unlikely for two disparate developers on completely different teams to register a component called 'tooltip'. When loaded into the same page the last component wins, overriding the original component. It is even more prevalent when wanting to use third party code which enforce certain names.
>>
>> In our application, using angular directives, this happens *all the time*.
>>
>> One proposal would be to adopt the import syntax from JavaScript ES6.
>>
>> ```html
>> <link rel="import" href="/imports/heart.html" as="my-heart" />
>> ```
>>
>> These could be scoped based upon where they exist in the document tree, so in the case that one might want to namespace for different parts of the document.
>>
>> ```html
>> <div id="some-app">
>>   <link rel="import" href="/imports/heart.html" as="my-heart" />
>> </div>
>>
>> <!-- my-heart in here is different than the my-heart in some-app -->
>> <div id="other-app">
>>   <link rel="import" href="/imports/my-heart.html" />
>> </div>
>> ```
>>
>> I don't think this is a workable solution because if an element is moved
> to a different part of the tree, what if that name is not available in that
> scope? It has to have *some* name. Similarly, many elements start life from
> document.createElement. What scope is that associated with? You would have
> to work hard to define what happens as a result.
>
> The cure might be worse than the disease.
>
>> Another approach would be to scope the imports using CSS selectors.
>>
>> ```html
>> <!-- my-heart can only used under elements that match the for selector -->
>> <link rel="import" href="/imports/my-heart.html" for="#some-app" />
>> ```
>>
>> I think that this suffers from similar problems.
>
>
>> https://gist.github.com/iammerrick/5826778
>>
>
>
>
> --
> <http://goto.google.com/dc-email-sla>
>
>
>


-- 
<http://goto.google.com/dc-email-sla>

Received on Tuesday, 25 June 2013 01:28:21 UTC