[html5] A <ui> Tag?
mrdarcymurphy at gmail.com
Thu May 13 09:44:08 PDT 2010
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 :)
> On Thu, May 13, 2010 at 10:41 AM, Darcy Murphy <mrdarcymurphy at gmail.com>
> > 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"
> > (
> > 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
> > I'm arguing for would do it (for me).
> > For example consider a text area with a WYSIWYG toolbar atop it. The
> > 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
> > currently working on, everything else is purely UI Chrome and I believe
> > 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
> > notion of AJAX and to a point I agree, but by that argument they also
> > in HTML5 would be wrong. Web apps aren't web apps these days without JS,
> > 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
> > 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
> > that a <ui> tag would either. All I'm thinking is that a subtle
> > and enhancement regarding what part of an HTML document is content and
> > part is chrome would be extremely valuable not only to us as developers
> > also to our site's users.
> > - Darcy
> > On Thu, May 13, 2010 at 9:11 AM, Nathan Ziarek <nziarek at gmail.com>
> >> > 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
> >> > in
> >> > this age of AJAX I cannot semantically group my controls without
> >> > 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
> >> 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...
More information about the Help