So in other words it *is* a case of "it's good enough". Web components
are quite possibly the future of the web, and yet we're implementing
them to be "good enough" in "90%" of use cases?
jQuery is JavaScript which means that it's different for various reasons:
1. It's less important to keep the names short.
2. It's possible to rename a plug-in if there is a conflict (e.g. @
http://stackoverflow.com/questions/11898992/conflict-between-two-jquery-plugins-with-same-function-name)
3. It's a library, not something built into the browser, which means
that if jQuery decides to add some form of namespacing, it doesn't
require a major specification and implementation by 5+ major browsers, etc.
> Complicating things further simply isn't all that necessary.
Complicating it for the developer, or the implementers? I can't speak
for the latter, but for developers, this would be an *optional* feature.
If you don't have conflicts you don't *have* to alter an element's NS
prefix, but specifying the prefix in your HTML would provide rich IDE
functionality, so I don't see why anyone would *not* want to do this.
> It's something that can be added organically as necessary.
Anne has already made a point about this, but also consider the fact
that without real namespacing, we're forced to name based on *potential*
conflicts. For example, in the ms- case, ms- may either already exist,
or *potentially* exist and be useful, so I name my element mks- instead.
Therefore I'm not able to give something the name that I want it to
have, for fear of future conflicts.
Even just being able to optionally shorten a custom element's NS prefix
can be useful. For example, if a vendor uses <excalibur-grid>, we can
just change that to <x-grid> and things will be easier to type, cleaner,
etc.
Regarding XML, I never even mentioned XML in my initial post, so I'm not
sure what all the fuss is about. This can be implemented in a way that
supports both HTML *and* XHTML/XML, yet doesn't look at all like XML
namespacing. The only important part is the use of URIs, I can see no
better way of providing both a unique namespace, as well as an endpoint
for gathering human- & machine-readable data about a set of custom
elements. Is there something inherently wrong with this? Or is this just
about people being too lazy to type a closing tag, because that can
remain optional.
> They [XML namespaces] have a number of terrible affordances
+
> Most of them don't commit the same mistakes that XML namespaces did
Such as?
G.
On 2015/02/05 00:58, Tab Atkins Jr. wrote:
On Thu, Feb 5, 2015 at 8:31 AM, Glen <glen...@gmail.com> wrote:
I know I'm rather late to the party, but I've been doing a lot of reading
lately about web components and related technologies, and the one thing that
confounds me is the fact that web components appear not to have any "real"
namespacing.
Prefix-based informal namespacing appears to be more than sufficient
for 90%+ of use-cases. It works fine, for example, for the huge
collection of jQuery widgets/extensions. Complicating things further
simply isn't all that necessary.
We do plan to help solve it at some point, as Dimitri says, as there
are some cases where real namespacing is useful. In particular, if
you have a name that you can assume is globally unique with high
confidence, you can actually share custom elements across documents.
Within a single page, however, prefix-based informal namespaces are
nearly always sufficient.
XML Namespaces are a pox on the platform, however, and they'll
definitely not get reproduced in custom elements. They have a number
of terrible affordances.
~TJ
