- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 11 Oct 2011 06:29:06 +0000 (UTC)
- To: Dirk Pranke <dpranke@chromium.org>
- cc: Dimitri Glazkov <dglazkov@chromium.org>, Roland Steiner <rolandsteiner@chromium.org>, WebApps WG <public-webapps@w3.org>, Dominic Cooney <dominicc@chromium.org>
On Mon, 10 Oct 2011, Dirk Pranke wrote: > On Wed, Sep 28, 2011 at 4:52 PM, Ian Hickson <ian@hixie.ch> wrote: > > If an author invents a new element, it doesn't matter what it inherits > > from. It won't have fallback behaviour, it won't have semantics that > > can be interpreted by search engines and accessibility tools, it won't > > have default renderings, and it won't allow for validation to catch > > authoring mistakes. I don't see what inheritance has to do with > > anything here. > > Ian, apologies if you have answered this before and I haven't seen it, > but a (fairly brief) query didn't turn up anything for me: when is it > okay to create new elements? Obviously, we created a bunch for HTML 5 > that don't have fallback behavior ... Most of the elements that have been added to HTML over the past five years actually have a pretty good fallback behaviour. For example, <progress>'s contents show in legacy UAs but not new UAs: <progress value=45 max=100> 45% complete </progress> ...so there's no loss of semantics or accessibility, it just doesn't look as pretty. > It seems like it would be helpful to distinguish between "new" elements > that can be reasonably mapped onto existing elements' semantics and > elements that cannot; perhaps we can agree that elements should be > reused where possible, but that there should also be mechanism for > defining new elements otherwise? Sometimes <div> or <span> is the most appropriate element, sure. Hopefully we can dramatically minimise those cases. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 11 October 2011 06:33:16 UTC