mdo / mdoml

An experiment in creating custom HTML elements based on today’s most common interface elements.

mdoml

What if you could augment HTML5's current set of elements with your own? Well, as it turns out, you can. mdoml is an experiment in creating custom HTML elements based on today's most common interface design components.

Is this a bad idea? Maybe, but that depends on how you look at it. Sure, it doesn't validate, but it does create a more approachable component-based design system. No more rules around writing classes a certain way—just create the components.

For more information, see the docs and examples.

Local development

This repo is a Jekyll site, so you'll need that installed before firing it up locally. Once you're set, just start a local server with jekyll serve and head to http://localhost:4000/mdoml/.

License

Created by @mdo, licensed under MIT.

mdoml's Issues

Anchor placeholder in breadcrumbs

I think placeholder anchor can be used breadcrumb component, right?

<breadcrumb>
  <a href="#">Home</a>
  <a href="#">Subfolder</a>
  <a href="#">Subfolder</a>
  <a>Page</a>
</breadcrumb>

Still a way clearer then current #Bootstrap: http://getbootstrap.com/components/#breadcrumbs
Let me know if I could do PR,
Thanks!

Technique

The most reliable technique for that purpose that I found is regular-elements package.

Hyphen, namespace or none of the above?!

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?

Just a question

Just a question, and not intended as a criticism. But why wouldn't you just use the web components specification to create custom elements?