[html5] A <ui> Tag?

[Darcy Murphy]

Yup, right on. All of it, even the <form> within a <ui> bit.

On Thu, May 13, 2010 at 11:07 AM, Nathan Ziarek <nziarek at gmail.com> wrote:

> 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?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100513/0d0374c4/attachment-0002.htm>