Re: Are web components *seriously* not namespaced?

> Web Components are also JS.  Any renaming you do in JS, you can do 
> just as easily in HTML.
+
> No functionality is enabled by namespaces that can't be done without 
> them just as easily but with a little more verbosity.
So I can import a custom element and rename it even after it has been 
registered?

Also, how do I get information about a custom element in my IDE of choice?

> You don't need to fear future conflicts. Googling for a name is often 
> sufficient.  You can change later if there is a conflict.
Seriously? And then I break all the code of users who depend on my 
element? So they rename it to the new name, and for them it conflicts 
with yet another element?

> Most people who mention namespaces on the web are referring to XML 
> Namespaces, so I assumed you were as well.
The only thing that was similar was the use of a URL, and I made it 
clear that this was just an example.

Regarding the use of URLs:

- You can just as easily misspell (or screw up a copy/paste) if you were 
using a URN or arbitrary string. Since the NS wouldn't match the one 
defined with the element, the element would fail to "run".

- "You can't actually fetch namespace urls" -- It would be made clear 
that the URLs should return certain metadata, if they don't then it's 
just a poorly maintained element.

- "URLs contain a bunch of extra typing baggage" -- Who types 
namespaces? Copy/paste.

- "Domain names don't mean much" -- that's why you can open the URL in a 
browser and find information about the element(s).

- "The ability to redefine namespaces at various points in the tree make 
generic processing far more complicated than it should be" -- This is an 
implementation detail that I cannot comment on, but it may be sufficient 
to just support declarations in the <head>. I just thought that this 
would be useful in cases where you have less control of certain areas 
within your page (AJAX-loaded content, etc.).

- "The ns prefix is actually significant ..." -- Same as above.

> All a namespace needs is to be of reasonable length so that it's 
> probably unique
I agree, but "reasonable length" will be too long in the case of HTML 
elements. Go to "http://customelements.io" and search for "x-". For 
example, "x-gif" has no identity. We can Google x-gif and get 5 x-gif 
elements, so now I have to search through my code to find the 
definition, and hope that there are comments etc. pointing to more 
information about the element.

> There are any number of non-insane ways to do that ...
Good. So:

1. Are you thinking of using something like a URN? If so, will there be 
an endpoint that allows you to register your element and provide 
metadata that IDEs can query? It's a single point of failure, but it's 
better than nothing at all. (I think that arbitrary strings would 
probably be a bad idea)

2. Can you, or anyone else, agree with me that namespaces should be 
implemented sooner rather than later? Has this already been put to a 
vote? If so, have any of the vendors changed their minds?

I really think that this is important.

G.

On 2015/02/05 21:55, Tab Atkins Jr. wrote:
> 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 Friday, 6 February 2015 11:25:00 UTC