[html5] A <ui> Tag?

[Nathan Ziarek]

For the record, I'm in favor of something like a <ui> element, I just
have no need for it :)

I tend to think of the elements of HTML5 in two camps: content (<p>,
<ul>, <h#>) and chrome (<nav>, <header>).

The content side of the equation has generic, non-semantic elements
(<span> and <div>) that can be used for any styling purpose.

It doesn't seem as if the chrome side has a generic, non-semantic
element for using the same way. That's where I think your <ui>
suggestion fits in: an open use element that indicates to any agent
that the stuff inside isn't part of the content.

Where I think we disagree is that the <ui> element should affect the
baseline actions of the content within. A <form> within a <ui> should
still submit as a page refresh unless rerouted by JS.

You are probably right that it's too late in the game to have
something like this added now, but it certainly isn't a bad idea. Keep
it around for HTML6 :)

nz

On Thu, May 13, 2010 at 10:41 AM, Darcy Murphy <mrdarcymurphy at gmail.com> wrote:
> Mostly I'm being an overly picky perfectionist, but in my opinion the
> separation of content and chrome is where HTML falls apart from an
> application development perspective. HTML5 was originally intended "to
> address the need for one coherent development environment
> for Web Applications"
> (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000005.html)
> and it has made enormous strides towards that, so please don't think that
> I'm discounting anything that's been done so far. However I feel strongly
> that it's not quite as useful as it could be, and this one little tag that
> I'm arguing for would do it (for me).
> For example consider a text area with a WYSIWYG toolbar atop it. The toolbar
> is clearly UI chrome, a collection of buttons and inputs, but it doesn't
> submit any information to the server, it only modifies the textarea I'm
> working with. For something as complex as http://280slides.com you can
> clearly see that the only actual "document" on the page is the slide you're
> currently working on, everything else is purely UI Chrome and I believe it
> should be marked up as such, not as the ridiculous <div> soup that it is.
> I think I understand what you're saying regarding HTML Documents having no
> notion of AJAX and to a point I agree, but by that argument they also have
> no notion of Javascript and to discount the importance of the new JS API's
> in HTML5 would be wrong. Web apps aren't web apps these days without JS, and
> subsequently, AJAX.
> In order to build web apps properly we've been taught that pages need to
> work over, around, and despite a wide array of inconsistently available
> functionality — that's the reality we live with in order to have extremely
> interoperable apps (a computing achievement that shouldn't be looked down
> upon). The additional tags in HTML5 don't violate that, and I don't believe
> that a <ui> tag would either. All I'm thinking is that a subtle realignment
> and enhancement regarding what part of an HTML document is content and which
> part is chrome would be extremely valuable not only to us as developers but
> also to our site's users.
> - Darcy
> On Thu, May 13, 2010 at 9:11 AM, Nathan Ziarek <nziarek at gmail.com> wrote:
>>
>> > From what I
>> > gathered the newly added tags are all still oriented towards document
>> > creation.
>>
>> You are right here, but I think this is the way it should be. HTML
>> documents are just structure. They don't have any notion of AJAX.
>>
>> > With HTML5 being principled on
>> > improving our ability to create Web Apps I found it strikingly odd that
>> > in
>> > this age of AJAX I cannot semantically group my controls without having
>> > to
>> > invoke a refresh of my page every time a button is pressed.
>>
>> This is the part I don't understand. When you write your web
>> application, have the JavaScript return false to all submit events.
>> While HTML5 will improve the ability to create apps, HTML is designed
>> to scale and fall back through progressive enhancement.
>>
>> I think a <ui> element for semantic purposes -- telling search engines
>> that this information isn't part of the content of the page -- could
>> be useful (although I can't come up with a scenario where the new
>> elements won't suffice for my uses). A <ui> element used only to
>> change the default behavior of HTML (form submission, link navigation)
>> doesn't quite line up with my expectations.
>>
>> Maybe I'm misunderstanding the issue?
>
>