Re: [w3c/webcomponents] Scoped Custom Element Registries (#716)

> What on earth would happen in this situation:

Just like with variable shadowing in practically any programming language, then in that case that `<link>` is no longer the sort of `<link>` from the outer scope, and it will not pull in the stylesheet, unless the Custom Element implements that.

```js
const foo = "foo"

~function() {
  const foo = "bar"

  console.log(foo)
  // is "foo" here the same "foo" as outside? Nope, not any more, we're in a new scope!
}()
```

Same thing for elements! If you override a "variable" (in this case an element name) in the inner scope, then it is no longer what it was in the outer scope.

> `    <override element="input">`

But, that's in global scope. Overriding should only be possible in non-global scope. Maybe, `<override element="XXX">` is something that could work, as it can signal the parser not to do certain things if `xxx` is `tr`, for example.

But then again, I don't like redundancy, I like things DRY.

Imagine if this was required in JavaScript:

```js
const foo = "foo"

~function() {
  override foo;
  const foo = "bar"
  console.log(foo)
}()
```

I would not prefer a similar thing for HTML name scope. But, what if an HTML/CSS no-JS person looks at the markup? They might get confused? True! I would probably not want to do that, just like I don't override globals in JS. What it would really be useful for is, for example, coming up with new element names that don't already exist (like `<node3d>` or `<magic>`), and then if the browser _by chance_ introduces one of those names, oh well, then the component will just work, and everyone can be happy. If a component wasn't using a yet-to-exist `<magic>` element before, but rather a custom element called `<magic>`, then, who cares if the browser introduces a new `<magic>` element later, as long as that component continues to work. Some other component can decide to use the builtin `<magic>` element by not overriding it.

I find myself in situation where I'm forced to think of another word to add to a single-word component, just to appease the hyphen rule. Sometimes I do something stupid like `<stu-pid>` just to do it, which is awkward.

So my argument isn't leaning toward overriding certain builtins (though I can imagine that if someone wanted to implement a "super link" that worked, plus did much more, and making it painless to adopt by overriding the builtin in one, then why not?

Personally, I just want to use single words when I want to.

-- 
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/716#issuecomment-365166602