Hyphen, namespace or none of the above?!

[jslegers]

By default, browsers should treat custom elements as semantically neutral :

User agents must treat elements and attributes that they do not understand as semantically neutral; leaving them in the DOM (for DOM processors), and styling them according to CSS (for CSS processors), but not inferring any meaning from them.
source

The specs suggest the use of custom XML namespaces, though, when creating custom elements using an XML syntax :

For markup-level features that can be limited to the XML serialization and need not be supported in the HTML serialization, vendors should use the namespace mechanism to define custom namespaces in which the non-standard elements and attributes are supported.
source

Example :

<tpdc:voter method='/ajax/pointlisting_vote' record_id='37' vote='1'
 fb_like_url='http://www.thepointless.com/pointlistings?id=37'>
  <tpdc:vote>vote<tpdc:vote>
  <tpdc:unvote>unvote<tpdc:unvote>
  +<tpdc:count>1<tpdc:count>
<tpdc:voter> 

source

When using an HTML syntax, however, the specs explicitly _forbid_ the creation of custom elements :

For markup-level features that are intended for use with the HTML syntax, extensions should be limited to new attributes of the form "x-vendor-feature", where vendor is a short string that identifies the vendor responsible for the extension, and feature is the name of the feature. _New element names should not be created_.
source

That is, of course, if we ignore the new custom element specs for web components.

Here, the Document.registerElement() method registers a new custom element in the browser and returns a constructor for the new element. It does, however, _require_ that a tag name contains a hyphen/dash character (-).

The first argument to document.registerElement() is the element's tag name. The name must contain a dash (-). So for example, , , and are all valid names, while and <foo_bar> are not.
source

See also :

var constructor = document.registerElement(tag-name, options);

_tag-name_
The name of the custom element. The name must contain a dash (-), for example my-tag.
source

See also :

The _custom element type_ identifies a custom element interface and is a sequence of characters that _must_ match the NCName production, _must_ contain a U+002D HYPHEN-MINUS character, and _must_ not contain any uppercase ASCII letters.
source

Personally, I think both the hyphenated syntax and the XML syntax are quite convoluted and should be recommended (to avoid potential naming conflicts) rather than mandatory.

Personally, I prefer a lean syntax without hyphens and without namespaces for frontend frameworks or projects where potential naming conflicts can easily be avoided by other means.

Unfortunately, I'm not a member of the team that writes the W3C Recommendations. Unfortunately, I'm not part of a browser's development team either, so my personal opinion is quite irrelevant here.

You seem to share my opinion on this matter, as none of your custom elements use namespaces and some of your custom elements do not contain any hyphens. Why did you make that decision and how do you intend to approach any issues involving code validity or spec compliance?

[jslegers]

See also http://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0003.html

[jslegers]

An overview of use cases where IMO non-hyphenated custom elements have great added value :

• Polyfilling, where only modern browsers offer support : I've considered it for polyfilling the <dialog> element.
• Polyfilling bleeding edge specs : It would also allow both CSS frameworks or customer projects to already implement elements defined by future HTML specs before there's any official browser support.
• CSS framework innovation : CSS frameworks like Bootstrap and Foundation are popular enough to actually set a standard that browsers are unlikely to break in the future. In fact, it would allow CSS frameworks to experiment with new standards that can be adopted by browsers at a later stage without the need for polyfills.
• REALLY custom stuff : Tags like <car>, <friend>, <hobby>, <swag> or even <chatbox> are unlikely to become part of the HTML standard because they're too specific, too non-technical, etc. If I control which third party code I use in my project, such tags should be considered safe.

An overview of use cases where I would prefer hyphenated custom elements :

• Tags like <combobox>, in projects other than CSS frameworks. This, because they are likely to break future specs or result in conflicts with third party code.
• When standards for CSS frameworks do not exist, it might be a good idea to start with something like <bootstrap-combobox> and organicly evolve towards <combobox> if there is popular support for any particular implementation. This would allow CSS frameworks to use development strategy for custom elements similar to the CSS prefix approach used by browsers.

[mdo]

You seem to share my opinion on this matter, as none of your custom elements use namespaces and some of your custom elements do not contain any hyphens. Why did you make that decision and how do you intend to approach any issues involving code validity or spec compliance?

This is an experiment, so whatever happens can be easily dealt with. I chose to rock no dashes because it felt right for a longer term vision of how HTML and frameworks could evolve. Code validity isn't an issue here for me right now—there are a few things that don'e validate in Bootstrap as well (browser hacks).

I might re-evaluate that later, but for now this seems perfectly okay to do to demonstrate the point.

[jslegers]

I chose to rock no dashes because it felt right for a longer term vision of how HTML and frameworks could evolve.

We're on the same page here. Unfortunately, the idea won't be able to move past that stage unless it's picked up by the W3C.

If you'd like to help push this idea through at the W3C, here's our chance. Do you have any experience with their mailing lists?