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. jackalm...@gmail.com wrote:
On Thu, Feb 5, 2015 at 12:00 PM, Kurt Cagle kurt.ca...@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
