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?