Yup, right on. All of it, even the <form> within a <ui> bit.<br><br><div class="gmail_quote">On Thu, May 13, 2010 at 11:07 AM, Nathan Ziarek <span dir="ltr"><<a href="mailto:nziarek@gmail.com">nziarek@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">For the record, I'm in favor of something like a <ui> element, I just<br>
have no need for it :)<br>
<br>
I tend to think of the elements of HTML5 in two camps: content (<p>,<br>
<ul>, <h#>) and chrome (<nav>, <header>).<br>
<br>
The content side of the equation has generic, non-semantic elements<br>
(<span> and <div>) that can be used for any styling purpose.<br>
<br>
It doesn't seem as if the chrome side has a generic, non-semantic<br>
element for using the same way. That's where I think your <ui><br>
suggestion fits in: an open use element that indicates to any agent<br>
that the stuff inside isn't part of the content.<br>
<br>
Where I think we disagree is that the <ui> element should affect the<br>
baseline actions of the content within. A <form> within a <ui> should<br>
still submit as a page refresh unless rerouted by JS.<br>
<br>
You are probably right that it's too late in the game to have<br>
something like this added now, but it certainly isn't a bad idea. Keep<br>
it around for HTML6 :)<br>
<font color="#888888"><br>
nz<br>
</font><div><div></div><div class="h5"><br>
On Thu, May 13, 2010 at 10:41 AM, Darcy Murphy <<a href="mailto:mrdarcymurphy@gmail.com">mrdarcymurphy@gmail.com</a>> wrote:<br>
> Mostly I'm being an overly picky perfectionist, but in my opinion the<br>
> separation of content and chrome is where HTML falls apart from an<br>
> application development perspective. HTML5 was originally intended "to<br>
> address the need for one coherent development environment<br>
> for Web Applications"<br>
> (<a href="http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000005.html" target="_blank">http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000005.html</a>)<br>
> and it has made enormous strides towards that, so please don't think that<br>
> I'm discounting anything that's been done so far. However I feel strongly<br>
> that it's not quite as useful as it could be, and this one little tag that<br>
> I'm arguing for would do it (for me).<br>
> For example consider a text area with a WYSIWYG toolbar atop it. The toolbar<br>
> is clearly UI chrome, a collection of buttons and inputs, but it doesn't<br>
> submit any information to the server, it only modifies the textarea I'm<br>
> working with. For something as complex as <a href="http://280slides.com" target="_blank">http://280slides.com</a> you can<br>
> clearly see that the only actual "document" on the page is the slide you're<br>
> currently working on, everything else is purely UI Chrome and I believe it<br>
> should be marked up as such, not as the ridiculous <div> soup that it is.<br>
> I think I understand what you're saying regarding HTML Documents having no<br>
> notion of AJAX and to a point I agree, but by that argument they also have<br>
> no notion of Javascript and to discount the importance of the new JS API's<br>
> in HTML5 would be wrong. Web apps aren't web apps these days without JS, and<br>
> subsequently, AJAX.<br>
> In order to build web apps properly we've been taught that pages need to<br>
> work over, around, and despite a wide array of inconsistently available<br>
> functionality — that's the reality we live with in order to have extremely<br>
> interoperable apps (a computing achievement that shouldn't be looked down<br>
> upon). The additional tags in HTML5 don't violate that, and I don't believe<br>
> that a <ui> tag would either. All I'm thinking is that a subtle realignment<br>
> and enhancement regarding what part of an HTML document is content and which<br>
> part is chrome would be extremely valuable not only to us as developers but<br>
> also to our site's users.<br>
> - Darcy<br>
> On Thu, May 13, 2010 at 9:11 AM, Nathan Ziarek <<a href="mailto:nziarek@gmail.com">nziarek@gmail.com</a>> wrote:<br>
>><br>
>> > From what I<br>
>> > gathered the newly added tags are all still oriented towards document<br>
>> > creation.<br>
>><br>
>> You are right here, but I think this is the way it should be. HTML<br>
>> documents are just structure. They don't have any notion of AJAX.<br>
>><br>
>> > With HTML5 being principled on<br>
>> > improving our ability to create Web Apps I found it strikingly odd that<br>
>> > in<br>
>> > this age of AJAX I cannot semantically group my controls without having<br>
>> > to<br>
>> > invoke a refresh of my page every time a button is pressed.<br>
>><br>
>> This is the part I don't understand. When you write your web<br>
>> application, have the JavaScript return false to all submit events.<br>
>> While HTML5 will improve the ability to create apps, HTML is designed<br>
>> to scale and fall back through progressive enhancement.<br>
>><br>
>> I think a <ui> element for semantic purposes -- telling search engines<br>
>> that this information isn't part of the content of the page -- could<br>
>> be useful (although I can't come up with a scenario where the new<br>
>> elements won't suffice for my uses). A <ui> element used only to<br>
>> change the default behavior of HTML (form submission, link navigation)<br>
>> doesn't quite line up with my expectations.<br>
>><br>
>> Maybe I'm misunderstanding the issue?<br>
><br>
><br>
</div></div></blockquote></div><br>