Re: Are web components *seriously* not namespaced?

On Fri, Feb 6, 2015 at 12:48 AM, Glen <glen.84@gmail.com> wrote:
> 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.

Web Components are also JS.  Any renaming you do in JS, you can do
just as easily in HTML.

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

Again, namespaces are nothing more than an indirection mechanism for
prefixes, so you can write a long and more-likely-unique prefix as a
shorter prefix that you know is unique for your page.  No
functionality is enabled by namespaces that can't be done without them
just as easily but with a little more verbosity.

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

Anne pointed out that XML Namespaces screwed this up, not that it's
not easy to get right.

You don't need to fear future conflicts.  Googling for a name is often
sufficient.  You can change later if there is a conflict.

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

Most people who mention namespaces on the web are referring to XML
Namespaces, so I assumed you were as well.  Your suggestion is shaped
exactly like XML Namespaces, with the use of urls as namespace, etc.

>> They [XML namespaces] have a number of terrible affordances
> +
>> Most of them don't commit the same mistakes that XML namespaces did
> Such as?

A few are:

* URLs are not a good fit for namespaces. Humans make a number of
assumptions about how urls can be changed (capitalization, trailing /,
http vs https, www or not, etc) which are often true for real urls due
to nice server software, but are not true for urls, which are opaque
strings.
* There's no consistency in the URL structure used: some namespaces
end in a word, some in a slash, some in a hash, etc.
* You can't actually fetch namespace urls.  Again, they're opaque
strings, not urls, so there's no guarantee or expectation that there's
anything useful on the other side, or that what is on the other side
is parseable in any way.  As a given XML namespace becomes more
popular, fetching the namespace url constitutes a DDOS attack; the
W3C, for example, has to employ sophisticated caching to prevent
namespace url requests from taking down their website.
* URLs contain a bunch of extra typing baggage that don't serve to
uniquify anything, just make it longer to type.  The "http://" prefix,
for example, is identical for all namespaces (and if it's not, it's
one more hurdle for authors to run into).  Using a string with a
higher information content is better for authors.
* Domain names don't mean much. For example, Dublin Core's namespace
starts with "http://purl.org/", which is effectively meaningless.
* Similarly, path components often exist which are worthless and just
lengthen the namespace for no uniquifying gain, such as the SVG
namespace http://www.w3.org/2000/svg which contains /2000/ for some
historical reason (it was minted in 2000, and at the time the W3C put
the year in most urls for some reason).  (Note the use of www in this
url, compared to no www in the DC namespace. Inconsistency!)
* The ability to redefine namespaces at various points in the tree
make generic processing far more complicated than it should be, as
<foo:bar> can refer to two completely different elements in different
parts of the tree.
* The ns prefix is actually significant - you can't just refer to an
element by its expanded name, you *must* stuff the namespace into a
prefix and use it.  Again, hard for generic processing.  It's
impossible to just move an element from one part of the tree to
another, because its prefix may have been redefined to mean something
else, and you can't just expand away the prefix to make it
unambiguous; instead, you have to maintain logic to check the prefixes
in use on the element (and all of its descendants) in effect in the
new location, and if there are any conflicts, rename the conflicting
ones on the element (and its descendants) to new unique prefixes and
associate those prefixes with the namespaces in question.

I'll stop there, though I could name a few more.  All a namespace
needs is to be of reasonable length so that it's probably unique.
There are any number of non-insane ways to do that, but XML namespaces
chose many of the worst options possible.

~TJ

Received on Thursday, 5 February 2015 19:56:08 UTC