On Thu, Feb 5, 2015 at 3:57 PM, Benjamin Goering <b...@livefyre.com> wrote:
> Glad to see this. I was 'checking in' on the professional practicalities of
> custom elements earlier this week, and was pretty bummed when I couldn't use
> XHTML5 namespaces for my employer's organization.
> I build widgets all day. They run in inhospitable that websites I'm not in
> control of. They have so many globals I just can't even. I get planning,
> execution, and/or distribution friction when the standards prevent be from
> creating a truly universal web component that will work in all those
> environments.
> To Tab's point, I don't think that will prevent a 90%-sufficient solution,
> or one that is 99%-sufficient for some subset of the potential market.
> But I do agree with Kurt that eventually it seems like 'the right way'.
> It seems valuable today to at least standardize and have a spec for XHTML5
> Custom Elements (e.g. <my-vendor:jquery/>). <1% of sites will actually use
> these in a way that fully validates against XHTML5. But at least web authors
> and developers will be using the web instead of Contrived JavaScript Embeds.
> With a vote of confidence (or better yet spec) on the consistency of XHTML5
> Custom Elements, I see no reason why I couldn't in the interim use this, and
> sleep at night knowing it will eventually be the way the web actually works:
> <html xmlns:my-vendor="https://html.my-vendor.com/elements";>
> <span is="my-vendor:jquery" />
> </html>
> or
> <div xmlns="https://html.my-vendor.com/elements";>
> <span is="jquery@~2.9" />
> <span is="react@^1.3" />
> </div>

Right now, those are invalid, and the document.register() call will
throw an error due to incorrect characters.

> One of the cool things about this is: Let's say in that last example I need
> to switch vendors or change where in the cloud my elements come from (e.g.
> QA, Staging, Production). All I need to change is the xmlns URL in that one
> attribute.

Namespaces do not enable this.  Switching the url of the script that
defines the elements does.  That can be done regardless of whether
namespaces are used or not, regardless of whether the elements have
the same name or different ones.

A namespace is literally nothing more than a convenience API over
prefix-based uniquified names, so you can define a long and
very-likely-unique prefix name without having to write it over and
over again.  It does not enable any new or unique programming models
or abilities.  <foo:bar> and <foo-bar> are identical, except that it's
possible that "foo" is a label for a longer and more-likely-unique


Reply via email to