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 > >
