Re: [w3c/webcomponents] [idea] Allow custom element naming on a per-shadow-root basis. (#488)

Well, I mentioned you for a reason: you're one of the only two (three?) people who have polyfilled Custom Elements, so therefore you might be able to provide the best insight (for me) on how feasible it would be to implement scoped Custom Element naming, or if that is even possible.

> I've noticed more than a person involved with the process and the implementation said already it's not gonna happen

So, just because "the powers that be" say to jump off a bridge (i.e. write bad code with lower maintenance standards), you will do so? You will let them rule? You won't speak up?

> > We use web components to load functionality from different services/locations with different development lifecycles
> 
> sounds to me like looking for troubles. What do you mean you don't know what you are loading?

He means, for example, you load any number of 3rd party libraries, eventually, some Custom Element names are going to conflict. This is a problem that leads to high-maintenance costs and head aches, and a problem that designers of Custom Elements have decided is okay to have in current and future applications the more complex they get.

We _do_ know what we import into our applications, but sometimes we don't know the name of every single component that a library might register, and for there to be a stupid runtime error because of this is just ugly.

We could've opted to have some form of scoping, and therefore we would be able to avoid or easily mitigate the problem without having to resort to forking 3rd party code and consuming the forked code from somewhere else, or without having to resort to absurd build steps to rename elements (these are high maintenance burdens that can easily be avoided).

People who use Vue/React/etc don't have this problem, they can easily name components anything they want within the scope of their components.

> Has the term XCS came up already? That's Cross Component Scripting which is IMO as bad as XSS.

Describe how this has to do with scoped element naming.

> We managed to make npm modules name convention good enough for the biggest open source repository out there, I am sure we can survive with current Custom Elements global naming status for the time being.

It's slightly different, because there's only one source of truth when we get NPM dependencies: npmjs.org.

There's not one source of truth with Custom Elements: any authors can publish any number of custom elements to anywhere, and inside the packages that they publish, even if it is on NPM, there can be conflicting element names. **There isn't a mechanism that avoids publishing of an already-existing element name, like there is with NPM packages.** If there were, then you're right, such a mechanism like NPM's would prevent the problem, but it doesn't exist with element naming until it's too late, and the elements have been placed into an application only to cause runtime error. You'll never get a runtime error about duplicate NPM packages with the same name, because duplicate-named packages from NPM will never get into your application to begin with. It's not quite the same.

> I rather would like to see Custom Elements V1 out in every browser and as of today I have zero interest in making Custom Elements any different from the current status, the only bit I honestly miss is the abiity to tell when a node has been upgraded.

Okay, that's totally fair, better to have that than nothing maybe; but I would also hope that we can be flexible and willing to adapt to newer and better engineering standards (f.e. avoiding global mechanisms like global variables or global registries which are things we've proven many times to be problematic).



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/488#issuecomment-341789447