Unrecognised markup should be scriptable and stylable

[Cerbera]

Currently, the market leading browser (Internet Explorer) does not apply CSS to unrecognised elements. Also, its DOM is somewhat messed up for elements which are not recognised.

In Firefox, CSS is applied to unrecognised elements. AFAICT, the DOM they produce is correct. This seems like a useful feature, particularly as HTML specifications usually add some new elements with each update.

I would propose that an HTML5 UA should treat unrecognised elements in such a way that they respond to CSS and are added to the DOM sanely (e.g. future sectioning and grouping elements). I would also propose that unrecognised attributes be selectable via CSS and work in the DOM (e.g. future type values for <input>).

This would make HTML5 UAs more forwards compatible. If more elements and attributes are added to HTML at a later time, they would more or less work in HTML5 UAs. Firefox already seems to implement this, as mentioned.

[Xano]

Makes sense to me, just like you say it.

On the other hand, what is exactly is the use of such a feature? The one browser that doesn't support new stuff within a reasonably short period after 'release' would be Internet Explorer and I wouldn't count on its developers implement this forward-compatibility feature.

[zcorpan]

I would propose that an HTML5 UA should treat unrecognised elements in such a way that they respond to CSS and are added to the DOM sanely (e.g. future sectioning and grouping elements). I would also propose that unrecognised attributes be selectable via CSS and work in the DOM (e.g. future type values for <input>).

This is already the case as specced.

[Cerbera]

Sorry, I hadn't noticed it in the spec. Looking again, I've now spotted this:

When the steps below require the UA to create an element for a token, the UA must create a node implementing the interface appropriate for the element type corresponding to the tag name of the token [...], with the tag name being the name of that element, with the node being in the HTML namespace, and with the attributes on the node being those given in the given token.

[...]

The interface appropriate for an element that is not defined in this specification is HTMLElement.

(Source: 8.2.4.3.3. Creating and inserting HTML elements.)

So I guess that's the part which specifies that unrecognised elements and attributes must be added to the DOM and work sanely?

[zcorpan]

Hmm, yeah but you probably also want to look for "Anything else" in various places in the tree construction section.

You also mentioned attribute values, which are just inserted as specified per HTML5. So <input type=foo> will have the value "foo", but still be treated as if it was "text".

[Cerbera]

Thanks for that. Never simple, is it?

So if this markup were used in an HTML5 document:

Code: Select all

<input type=foo>

And if this CSS was linked to that document:

Code: Select all

input[type=foo] {
background: lime;
}

Would the CSS be applied to that element? I'm guessing it would, but that a UA would have created a text input (rather than a "foo" input) if the type was not a known value.

[zcorpan]

So if this markup were used in an HTML5 document:

Code: Select all

<input type=foo>

And if this CSS was linked to that document:

Code: Select all

input[type=foo] {
background: lime;
}

Would the CSS be applied to that element?

Yes.

[bfrohs]

Makes sense to me, just like you say it.

On the other hand, what is exactly is the use of such a feature? The one browser that doesn't support new stuff within a reasonably short period after 'release' would be Internet Explorer and I wouldn't count on its developers implement this forward-compatibility feature.

I also doubt they would, but if it were a recommendation to do so, maybe it would encourage the IE developers to implement this forward-compatibility feature. Not only would it help with developing (X)HTML at a quicker pace (enabling the creation of tags more quickly without waiting for browsers to catch up), but it would also allow for currently unsupported tags to work with at least limited functionality.

[Sander Aarts]

This is a good thing I guess and I don't know why MS wouldn't want to build that into IE as it would make their browser more forward compatible as well.

If I understand this correctly then this feature also offers the possibility to create custom elements. Not elements that have a semantic value, but more <div>-/<span>-like. This can be great, but it can also be the path to invalid tag soup. If all kinds of applications that are incorporated in a website (internal site search, cms, etc.) use their own custom elements, it can become very messy again.
Is this something that has been considered or am I just a bit too pessimistic here?

[zcorpan]

If I understand this correctly then this feature also offers the possibility to create custom elements.

It already is possible, even in IE (if you use funny enough names, e.g. with colons in them), but it doesn't make it allowed to do so. Custom elements are forbidden to use in HTML5.

[legendscrolls]

Currently, the market leading browser (Internet Explorer) does not apply CSS to unrecognised elements. Also, its DOM is somewhat messed up for elements which are not recognised.

Actually IE does support styling unknown elements in HTML documents at least by, what I call, a DOM Trigger:
Say you want to use <section> and <article> in current IE 6 or higher you can write a little internal or external script in the head that has this code:
document.createElement("section");
document.createElement("article");

This will allow IE's CSS parser to style these elements even though IE doesn't currently, natively support them.
Although don't forget to at least style them with display: block.

Gecko, Presto and Webkit based such as Firefox, Opera and Safari all support styling without this DOM Trigger.

But KHTML based like Konqueror does not support styling unknown markup at all.
At least KHTML will be merging with Webkit so hopefully Konqueror 4.1 will.

iCab 4 appears to be built with Webkit so iCab now also supports styling unknown elements like Safari 3.

[zcorpan]

Actually IE does support styling unknown elements in HTML documents at least by, what I call, a DOM Trigger:
Say you want to use <section> and <article> in current IE 6 or higher you can write a little internal or external script in the head that has this code:
document.createElement("section");
document.createElement("article");

This will allow IE's CSS parser to style these elements even though IE doesn't currently, natively support them.

The CSS parser doesn't behave differently, but the HTML parser does. IE treats such tags pretty much the same as it would with tags that have colons in them -- the elements can have content, the case is preserved, stray end tags are ignored, and the /> syntax has the XML empty-element tag semantics. (Normally, IE creates empty elements for unknown start and end tags what's between the tags end up as siblings to those elements, the element names are uppercased, and the /> syntax is ignored.)

Gecko, Presto and Webkit based such as Firefox, Opera and Safari all support styling without this DOM Trigger.

Gecko closes unknown elements at the first block-level element.