Re: Are web components *seriously* not namespaced?
I created a prototype of this idea on github: https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/README.md by forking the original webcomponents.js project. It contains a working example of this concept. Below the content of the README.md file: This fork of webcomponents.js enhances Document.registerElement so that the options argument can contain a 'namespace' property which contains an XHTML namespaceURI e.g. http://mansoft.nl/big-blue-button so you can put a custom element in another namespace than http://www.w3.org/1999/xhtml, which is the default when no namespace is specified. The custom element registry is now a 2 dimensional lookup table. First the namespaceURI is looked up and then the localname of the custom Element. An example usage can be found at https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-test-polyfill-ce.xhtml Here two custom elements are defined with the same name 'bigbutton' (without dashes) but with different namespaces " http://mansoft.nl/big-red-button; and "http://mansoft.nl/big-blue-button;. When webcomponents.js is build you can test this file on a browser not natively implementing Document.registerElement e.g. Firefox An important change is to no longer use the HTML-specific onclick functions etc. but the generic DOM AddEventListener pattern. The registration of the components using the extra 'namespace' property is done in https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/bbb-component.js and https://github.com/hfmanson/webcomponentsjs/blob/xml-namespace/xmltests/brb-component.js The example component 'Big Red Button' is based on a webcomponent sample from Robin Berjon's presentation 'Distributed Extensibility: Finally Done Right?' on XML Prague 2014. When this will be implemented in the official Custom Element specification it will be possible to polyfill XHTML with for example XForms by implementing each XForm component using custom components. Or MathML. I'll be happy to hear your comments and suggestions.
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML has been hotly debated, and many, many potential solutions proposed. Regardless, I do think that there is a very real need for namespaces in the general sense, if only as a way of being able to assert conceptual domain scope and to avoid collisions (div is the prototypical example here). Although they are ugly, they did do one thing correct, and that was to place the burden of namespace resolution and use on the final document creator. I think that namespace/prefix should be defined by the web page designer and not the component library designer. This allows end users of the component the ability to resolve the conflicts, instead of filing a bug report and a component designer has to fix all namespace resolutions. As a component designer, I'd like the ability to develop with a single panel instead of my-really-long-hopefully-not-conflicting-panel. I definitely prefer the prefix solution as it looks cleaner in the end product. document.registerElement should warn/error if the end product tag is already in use, that's for sure.
Re: Are web components *seriously* not namespaced?
On Thu, Apr 9, 2015 at 9:04 AM, Rahly hungry.ra...@gmail.com wrote: On Thu, Feb 5, 2015 at 4:12 PM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML has been hotly debated, and many, many potential solutions proposed. Regardless, I do think that there is a very real need for namespaces in the general sense, if only as a way of being able to assert conceptual domain scope and to avoid collisions (div is the prototypical example here). Although they are ugly, they did do one thing correct, and that was to place the burden of namespace resolution and use on the final document creator. I think that namespace/prefix should be defined by the web page designer and not the component library designer. This allows end users of the component the ability to resolve the conflicts, instead of filing a bug report and a component designer has to fix all namespace resolutions. As a component designer, I'd like the ability to develop with a single panel instead of my-really-long-hopefully-not-conflicting-panel. This is a problem I would like solve as well. I definitely prefer the prefix solution as it looks cleaner in the end product. document.registerElement should warn/error if the end product tag is already in use, that's for sure. It already does: http://w3c.github.io/webcomponents/spec/custom/#dfn-definition-construction-algorithm :DG
Re: Are web components *seriously* not namespaced?
On 5 February 2015 at 20:55, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@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. Note: For those that dont know, purl means permanent URL. During the
Re: Are web components *seriously* not namespaced?
I'm inclined to agree with Glen here on a couple of points. 1) The exact form of the namespacing mechanism isn't so important as the fact that there is a mechanism in place. While not everyone will use namespaces (and to be honest that should be seen as a requirement, that any namespace proposal should account for that 90% case that Tab laid out earlier where namespaces are an encumbrance) I think that the sooner such a namespacing mechanism be put into place, the sooner that it can be adopted by the 10% who do in fact have significant need for namespaces (semantic web being the biggest use case I can think of at the top of my head). 2) I tend to distrust public registries - they add a layer of complexity and often are underutilized when finally implemented. I'm more inclined to see something like a namespace bundle or package that can be written in JSON in some kind of standardized format. Node's *npm* might be a good model there. This creates a set of bound key prefixes for a given site that can in turn be associated with corresponding namespaced globals and extended HTML elements. I'd have to think about this a bit, but I could see this both as a way to allow for large organizations to manage its widget usage within web apps. Kurt Cagle Principle Evangelist, Semantic Technologies Avalon Consulting, LLC kurt.ca...@gmail.com, personal cag...@avalonconsult.com, business 443-837-8725 On Fri, Feb 6, 2015 at 9:01 AM, Dimitri Glazkov dglaz...@google.com wrote: On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com wrote: Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? Yep. That's a good place. :DG
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 12:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: * Domain names don't mean much. For example, Dublin Core's namespace starts with http://purl.org/;, which is effectively meaningless. It means that the owner of purl.org decided to allocate the namespace, as opposed to someone else. So while it's not arbitrary, for our purposes it's entirely opaque. * 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!) URIs are opaque, it's not really worth it to argue about how they're designed, because their design is meaningless to everyone except the authority that minted them. Every once in a while in the RDF/Semantic Web community, there's a complaint that http://www.w3.org/1999/02/22-rdf-syntax-ns# is too long to remember. Eventually the discussion realizes that it's a non issue because, again, URIs are opaque. If you have to look up a URI, http://prefix.cc/xsd (for example) works pretty well. If you type, auto-complete, copy/paste, or otherwise enter the wrong namespace, it'll be pretty clear right off the bat that your program isn't working. Even if that weren't the case, we have spell-checkers, why not namespace-checkers? (snip) 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. I would call the namespace issue largely /resolved/ by XML. All of the features you named exist because it adds a definite feature; e.g. the ability to paste an SVG document directly into a document without having to copy-paste a bunch of headers (Turtle, SPARQL has this problem; nested namespaces are a definite *feature*!). XML namespaces are greatly preferable to the tag-soup problem we have with text/html and application/json, where there's *no* namespaces whatsoever, with *no* way to mix vocabularies, and *no* forward compatibility. Nothing against JSON; I maintain numerous utilities around JSON including JSON Schema, JSON Hyper-schema, JSON-LD, and more. JSON documents are great for what they do; XML (and other DOM serializations) documents are great for the different task that they do, and they do namespaces. If nothing else, we need to support namespaces because HTML isn't the only DOM-based hypertext technology out there. Limiting our sights to HTML would be unfortunate. I'm not even sure how namespaces are unsupported; namespaces exist in the DOM, even if they don't exist in the text/html syntax. It's not terribly hard to use: var svgns = 'http://www.w3.org/2000/svg'; // functionally same as xmlns=, @prefix, etc document.getElementsByTagNameNS(svgns, 'svg'); var e = document.createElementNS(svgns, 'rect'); ... this is not fundamentally different than all the DOM stuff we do for HTML. We're dealing with Web Scale here. Works for 90% of us isn't good enough. Austin Wright.
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...@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
Re: Are web components *seriously* not namespaced?
On 2/4/15 4:41 PM, Dimitri Glazkov wrote The proposed solution is using registries: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578 Thanks Dimitri. Glen - FYI, I added a link to the thread you started to the above bug (and embellished the bug's title a bit to reflect this thread). The registry API hasn't been spec'd yet. Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? -ArtB
Re: Are web components *seriously* not namespaced?
On Fri, Feb 6, 2015 at 4:05 AM, Arthur Barstow art.bars...@gmail.com wrote: Dimitri - if someone wants to provide input (f.ex. requirements ) for this API, should they add them to the above bug (or do you recommend else)? Yep. That's a good place. :DG
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...@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
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 2:15 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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. (It shouldn't, but yet when XML added namespacing it did so in a way that was incompatible with XML itself (see the : and the horrible set of APIs in the DOM we ended up with as a result). And when XHTML came along it used a namespace whereas HTML did not (we later fixed that).) -- https://annevankesteren.nl/
Re: Are web components *seriously* not namespaced?
On 4 February 2015 at 22:31, 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.
Can someone explain why this is so, and what the justification is? Or is
it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @ http://lists.w3.org/Archives/
Public/public-webapps/2013AprJun/0964.html, but nothing changed.
It's not going to be long before x-tabs has been defined by 1,000,000
people (slight exaggeration), and you have no idea what it is or where it
came from without looking through imports/scripts etc. Also you want to
keep things short, so you call your element ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
definition is used.
Please note that the above syntax is just an example of what could be used.
Another BIG pro here is that IDEs can pull in information about the
elements by sending an HTTP request to the namespace URI so that a tooltip
could be displayed with an element description, author, sample usage, etc.
I really do hope that it's not too late to make such a change.
+1 to everything
Could a colon perhaps be saved as a special character so in future you can
have ms:panel and msft:panel and the user agent would be able to work
out which code to use?
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
I like the look of a colon, however it would quite probably conflict
with XML/XHTML so it's probably best to avoid it (although I am not an
expert).
A hyphen or maybe even a tilde (~) would likely be the better option.
ms-panel polymer-element a href=xxx x-controller=xxx
ms~panel polymer~element a href=xxx x~controller=xxx
G.
On 2015/02/05 16:51, Melvin Carvalho wrote:
On 4 February 2015 at 22:31, Glen glen...@gmail.com
mailto: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.
Can someone explain why this is so, and what the justification is?
Or is it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before x-tabs has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element ms-panel (you work for Monkey Solutions LLC),
but then someone else on the team is importing ms-panel from
Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace
like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest
element definition is used.
Please note that the above syntax is just an example of what could
be used.
Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.
I really do hope that it's not too late to make such a change.
+1 to everything
Could a colon perhaps be saved as a special character so in future you
can have ms:panel and msft:panel and the user agent would be able
to work out which code to use?
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
Tab,
I spend the vast majority of my time anymore in RDF-land, where namespaces
actually make sense (I'm not going to argue on the XML use of namespaces -
they are, agreed, ugly and complex). I know that when I've been at Balisage
or any of the W3 confabs, the issue of namespaces ex-XML has been hotly
debated, and many, many potential solutions proposed. Regardless, I do
think that there is a very real need for namespaces in the general sense,
if only as a way of being able to assert conceptual domain scope and to
avoid collisions (div is the prototypical example here).
Now, I'd like to see clark notation more heavily used, both on the XML and
HTML side - {http://www.w3.org/2001/XMLSchema#}string is ugly but
unambiguous. CURIE notation works so long as you assume that context
changes within a scoped entry, and that a curied name, whether ms:foo or
ms-foo must always be closed - ie,
divThis is a ms:glossarytermglossary term/term/ms:glossary/div
would change internal scope, such as on term, to the innermost declared
ancestor (ms:glossary). This is actually very consistent behavior for web
content in particular, and one area I think XML got wrong.
Re: formation of IRIs - I normally declare namespaces for RDF using non URL
notation such as urn:uuid:12334592125 or something similar, avoiding
http: protocols, precisely for the confusion from neophytes working with
namespaces. Java classes use similar namespace notation:
com.oracle.java.Foo in establishing namespacing into their framework. The
problem that I see with the 90% argument is that everyone's remaining 10%
is different, and those are the cases where namespacing - as a context
establishing mechanism becomes useful.
Kurt Cagle
Principle Evangelist, Semantic Technologies
Avalon Consulting, LLC
kurt.ca...@gmail.com, personal
cag...@avalonconsult.com, business
443-837-8725
On Thu, Feb 5, 2015 at 11:55 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@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
Re: Are web components *seriously* not namespaced?
On Fri, Feb 6, 2015 at 8:12 AM, Kurt Cagle kurt.ca...@gmail.com wrote: Tab, I spend the vast majority of my time anymore in RDF-land, where namespaces actually make sense (I'm not going to argue on the XML use of namespaces - they are, agreed, ugly and complex). I know that when I've been at Balisage or any of the W3 confabs, the issue of namespaces ex-XML has been hotly debated, and many, many potential solutions proposed. Regardless, I do think that there is a very real need for namespaces in the general sense, if only as a way of being able to assert conceptual domain scope and to avoid collisions (div is the prototypical example here). Yes, as I've said, I don't disagree that we'll want a namespacing mechanism at some point. It's just not needed at the moment, and we can safely introduce it in the future. ~TJ
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 3:57 PM, Benjamin Goering b...@livefyre.com wrote: 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 Right now, those are invalid, and the document.register() call will throw an error due to incorrect characters. 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. Namespaces do not enable this. Switching the url of the script that defines the elements does. That can be done regardless of whether namespaces are used or not, regardless of whether the elements have the same name or different ones. A namespace is literally nothing more than a convenience API over prefix-based uniquified names, so you can define a long and very-likely-unique prefix name without having to write it over and over again. It does not enable any new or unique programming models or abilities. foo:bar and foo-bar are identical, except that it's possible that foo is a label for a longer and more-likely-unique prefix. ~TJ
Re: Are web components *seriously* not namespaced?
On Thu, Feb 5, 2015 at 7:44 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Feb 5, 2015 at 2:15 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: 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. (It shouldn't, but yet when XML added namespacing it did so in a way that was incompatible with XML itself (see the : and the horrible set of APIs in the DOM we ended up with as a result). And when XHTML came along it used a namespace whereas HTML did not (we later fixed that).) Yes, I said can be added organically. It's always possible to shoot yourself in the foot, as XML Namespaces did, if you really try. ~TJ
Re: Are web components *seriously* not namespaced?
On Fri, Feb 6, 2015 at 12:48 AM, Glen glen...@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
Re: Are web components *seriously* not namespaced?
On Wed, Feb 4, 2015 at 2:31 PM, 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.
There is a serious antipathy towards XML in some quarters. So I believe the
vocabulary was designed for non-XML namespace aware parsers. Others can
verify my understanding (or not).
Can someone explain why this is so, and what the justification is? Or is
it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @ http://lists.w3.org/Archives/
Public/public-webapps/2013AprJun/0964.html, but nothing changed.
It's not going to be long before x-tabs has been defined by 1,000,000
people (slight exaggeration), and you have no idea what it is or where it
came from without looking through imports/scripts etc. Also you want to
keep things short, so you call your element ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
definition is used.
Please note that the above syntax is just an example of what could be used.
Another BIG pro here is that IDEs can pull in information about the
elements by sending an HTTP request to the namespace URI so that a tooltip
could be displayed with an element description, author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
It doesn't really matter whether or not it's based on (or at least
resembles) XML, as long as there is some way to specify (and redefine)
the prefix of custom elements.
G.
On 2015/02/04 23:39, Glenn Adams wrote:
On Wed, Feb 4, 2015 at 2:31 PM, Glen glen...@gmail.com
mailto: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.
There is a serious antipathy towards XML in some quarters. So I
believe the vocabulary was designed for non-XML namespace aware
parsers. Others can verify my understanding (or not).
Can someone explain why this is so, and what the justification is?
Or is it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before x-tabs has been defined by
1,000,000 people (slight exaggeration), and you have no idea what
it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so you
call your element ms-panel (you work for Monkey Solutions LLC),
but then someone else on the team is importing ms-panel from
Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace
like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest
element definition is used.
Please note that the above syntax is just an example of what could
be used.
Another BIG pro here is that IDEs can pull in information about
the elements by sending an HTTP request to the namespace URI so
that a tooltip could be displayed with an element description,
author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
Glen -
Glenn has the answer.
So we're going to come up with yet-another-registry rather than use one
that already exists and guarantees (at least as far can be guaranteed)
uniqueness: DNS.
The ramifications of not making HTML5 be XHTML5 will be with us for a very
long time indeed.
Cheers,
- Bill
On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov dglaz...@google.com wrote:
The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
The registry API hasn't been spec'd yet.
:DG
On Wed, Feb 4, 2015 at 1:31 PM, 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.
Can someone explain why this is so, and what the justification is? Or is
it just a case of it was too complicated, this is good enough?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before x-tabs has been defined by 1,000,000
people (slight exaggeration), and you have no idea what it is or where it
came from without looking through imports/scripts etc. Also you want to
keep things short, so you call your element ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing ms-panel
from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom elements. --
element name=panel namespace=https://microsoft.com/namespace;
prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a namespace like
this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest element
definition is used.
Please note that the above syntax is just an example of what could be
used.
Another BIG pro here is that IDEs can pull in information about the
elements by sending an HTTP request to the namespace URI so that a tooltip
could be displayed with an element description, author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
Can either of you provide an example in layman's terms?
I don't quite understand what this will look like.
G.
On 2015/02/05 00:29, William Edney wrote:
Glen -
Glenn has the answer.
So we're going to come up with yet-another-registry rather than use
one that already exists and guarantees (at least as far can be
guaranteed) uniqueness: DNS.
The ramifications of not making HTML5 be XHTML5 will be with us for a
very long time indeed.
Cheers,
- Bill
On Wed, Feb 4, 2015 at 3:41 PM, Dimitri Glazkov dglaz...@google.com
mailto:dglaz...@google.com wrote:
The proposed solution is using registries:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578
The registry API hasn't been spec'd yet.
:DG
On Wed, Feb 4, 2015 at 1:31 PM, Glen glen...@gmail.com
mailto: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.
Can someone explain why this is so, and what the justification
is? Or is it just a case of it was too complicated, this is
good enough?
I see this has been brought up once before @
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0964.html,
but nothing changed.
It's not going to be long before x-tabs has been defined by
1,000,000 people (slight exaggeration), and you have no idea
what it is or where it came from without looking through
imports/scripts etc. Also you want to keep things short, so
you call your element ms-panel (you work for Monkey
Solutions LLC), but then someone else on the team is importing
ms-panel from Microsoft, and BAM!, you have another problem.
Why can't we do something like this?
!-- /scripts/monkey-solutions/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://monkey-solutions.com/namespace;
});
/script
!-- /scripts/microsoft/panel.js --
script
var panel = document.registerElement(panel, {
namespace: ms https://microsoft.com/namespace;
});
/script
!-- Uses last defined element, as it currently works. --
ms-panel
!-- Redefine the namespace prefix for one of the custom
elements. --
element name=panel
namespace=https://microsoft.com/namespace; prefix=msft /
ms-panel
msft-panel
You could also assign a prefix to all elements within a
namespace like this:
element name=* namespace=https://microsoft.com/namespace;
prefix=msft /
You can override the prefix multiple times and the closest
element definition is used.
Please note that the above syntax is just an example of what
could be used.
Another BIG pro here is that IDEs can pull in information
about the elements by sending an HTTP request to the namespace
URI so that a tooltip could be displayed with an element
description, author, sample usage, etc.
I really do hope that it's not too late to make such a change.
Regards,
Glen.
Re: Are web components *seriously* not namespaced?
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
Re: Are web components *seriously* not namespaced?
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
Re: Are web components *seriously* not namespaced?
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. 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) ! Kurt Cagle Principle Evangelist, Semantic Technologies Avalon Consulting, LLC kurt.ca...@gmail.com, personal cag...@avalonconsult.com, business 443-837-8725 On Wed, Feb 4, 2015 at 2:58 PM, Tab Atkins Jr. jackalm...@gmail.com 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
Re: Are web components *seriously* not namespaced?
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
