Re: Are web components *seriously* not namespaced?

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.84@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
>

Received on Thursday, 5 February 2015 13:49:07 UTC