Re: Are web components *seriously* not namespaced?

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>

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.

Critiques?

--
Benjamin Goering - @bengo
Platform @Livefyre Labs

On Wed, Feb 4, 2015 at 5:15 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:
> > I predict that sometime around 2025, we will end up redefining namespaces
> > because the number of jQuery-like components have ballooned into the
> > millions, the web has descended once again into a sea of
> interoperability,
> > and registries will, once again, have proven to be a bottleneck, as they
> > have EVERY SINGLE TIME they have been implemented.
>
> Yes, real namespacing does eventually prove necessary as the
> population grows.  That's fine.  It's something that can be added
> organically as necessary; letting everything live in the null
> namespace first doesn't harm future namespacing efforts.
>
> > Of course, they won't be called namespaces, and they'll probably use a
> dash
> > instead of a colon , and they definitely won't be XML based because
> everyone
> > knows that XML is EVIL ... (sigh) !
>
> There are more namespacing solutions in heaven and earth, Horatio,
> than are dreamt of in your XML.  Most of them don't commit the same
> mistakes that XML namespaces did.
>
> ~TJ
>
>

Received on Thursday, 5 February 2015 04:57:53 UTC