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. ). <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:
https://html.my-vendor.com/elements";>
or
https://html.my-vendor.com/elements";>
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. wrote:
> On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle 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
>
>
