Re: Are web components *seriously* not namespaced?

2015-09-21 Thread Henri Manson
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?

2015-04-09 Thread Rahly
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?

2015-04-09 Thread Dimitri Glazkov
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?

2015-02-07 Thread Melvin Carvalho
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?

2015-02-06 Thread Kurt Cagle
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?

2015-02-06 Thread Austin William Wright
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?

2015-02-06 Thread Glen
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?

2015-02-06 Thread Arthur Barstow

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?

2015-02-06 Thread Dimitri Glazkov
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?

2015-02-05 Thread Glen
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?

2015-02-05 Thread Anne van Kesteren
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?

2015-02-05 Thread Melvin Carvalho
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?

2015-02-05 Thread Glen
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?

2015-02-05 Thread Kurt Cagle
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?

2015-02-05 Thread Tab Atkins Jr.
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?

2015-02-05 Thread Tab Atkins Jr.
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?

2015-02-05 Thread Tab Atkins Jr.
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?

2015-02-05 Thread Tab Atkins Jr.
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 

Are web components *seriously* not namespaced?

2015-02-04 Thread Glen
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?

2015-02-04 Thread Glenn Adams
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?

2015-02-04 Thread Glen
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?

2015-02-04 Thread William Edney
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?

2015-02-04 Thread Glen

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?

2015-02-04 Thread Tab Atkins Jr.
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?

2015-02-04 Thread Tab Atkins Jr.
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?

2015-02-04 Thread Kurt Cagle
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?

2015-02-04 Thread Benjamin Goering
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