[whatwg] Ideas regarding Web Applications 1.0

[Ian Hickson]

On Thu, 14 Oct 2004, Matthew Raymond wrote:
> 
> Here's a <tabbox> example[1] from the Web Applications 1.0
> specification:
> 
> | <tabbox>
> |  <section>
> |   <h2>About</h2>
> |   <p><img src="logo" alt=""></p>
> |   <p>The Application.</p>
> |   <p>© copyright 2004 by The First Team.</p>
> |  </section>
> |  <section>
> |   <h2>Credits</h2>
> |   <ul>
> |    <li>Jack O'Neill</li>
> |    <li>Samantha Carter</li>
> |    <li>Daniel Jackson</li>
> |    <li>Teal'c</li>
> |    <li>Jonas Quinn</li>
> |   </ul>
> |  </section>
> | </tabbox>
> 
> There are several problems with this example:

That's putting it nicely, heh. I'm very much not sold on this idea. To be 
honest I'm not really sure what problem I was trying to solve when I wrote 
it, and have been looking at how to redo that section.


> 1) There's no method of styling tabs and legacy headers separately. The 
> webmaster is forced to style the tabs and the fallback header in the 
> exact same way by styling the <h2> element.

That's mostly a CSS limitation, though.


> 2) The content for the tab and the fallback header are not and cannot be 
> separate.

That's a feature, not a bug.


> 3) What happens if the webmaster copies legacy markup that contains 
> <h1>-<h6> elements into the <section> element but forgets to put in a 
> header for the tab label?

The UA will use the first header as the tab label (which is better than 
nothing, and is immediately obvious in testing).


> 4) Structurally, the use of <h1>-<h6> as a label for a <section> differs 
> from the use of <fieldset> and <legend>, where you have a single element
> that does not have a different semantic meaning in another context.

Well, the semantic meaning is the same. "Section header". Only the 
presentation differs.


> Here's the example modified to address some of these problems:
> 
> | <tabbox>
> |  <section level="2">

level="2" should be inferred from context.


> |   <h><h2>About</h2></h>

<h><h2>? Ew! :-)


> My definition of <h> is slightly different from that suggested by 
> others. In the examples in this email, the <h> element is similar to the 
> <legend> element: it's an optional element for which there is only one 
> per <section> element that labels a <section>. Another difference is 
> that my version of <h> ignores child <h1>-<h6> elements. This allows you 
> to use <h1>-<h6> for graceful degradation in legacy user agents.

It seems redundant though. Why not just use <hX> for that?


> What happens if you want to style the tab directly?

That's a CSS problem.

Ok, that's a terrible answer, but in this particular case I think it's 
the right one. I would imagine that the <section> elements would get 
pseudo-elements ::label that style the boxes used for the tabs, much like 
how ::value is used to style the field in XForms.


> My thought is that the <tabbox> could have implied elements that can be 
> used to style the actual tabs and their contents (called <tablabel> 
> perhaps). If you want the legacy section label content to vary from the 
> contents of the tab, you could then explicitly use a <tablabel> element:

What's the use case for legacy UAs having different headers than WA1 UAs?

Don't forget the "tab"ness is merely a suggested default presentation. 
(The element should be called <group> or some such.)


> | <tabbox>
> |  <tablabel>About
> |   <section>

It makes no semantic sense for the section to be part of its label. That 
would be equivalent to saying:

   <h2> About
    <p> I am a fish. </p>
   </h2>

...for instance.

(The <label> semantics notwithstanding.)


But more importantly, I think the tab header should always be derived from 
the section's _actual_ header.


> I suggest a new element called <tablink> for establishing a semantic 
> context for hyperlinks. Here's an example of how this might work.
> 
> | <tabbox>
> |  <tablabel for="main">Main</tablabel>
> |  <tablabel for="about">About</tablabel>
> |
> |  <section id="main" label="Main"> ...Content... </section>
> |
> |  <tablink id="about">
> |   <a href="about.html">About</a>
> |  </tablink>

I don't understand how this is better than just:

   <tabbox>
    <section id="main"> <h2>Main</h2> ...Content... </section>
    <a href="about.html">About</a>

...especially given how much shorter the latter is. Your example repeats 
the word "about" four times, not counting the URI!

Redundancy is bad, especially in a language like HTML where every time 
there is anything redundant, authors will put in conflicting contradictory 
information. Not to put too fine a point on it, a good proportion of the 
people writing content using these specs will be morons, and the language 
needs to be resilient to their "skills".



> As you can see, <tablabel> allows you to use hyperlinks as legacy 
> content without that content being interpreted as a tab in the <tabbox>. 
> A compressed version of the tag could be used when you don't want 
> fallback content to appear for a specific tab at all: [...]

What would the use case for such divergent behaviour be?


> The <tablink> element can also be used to make markup smaller and 
> simpler:
> 
> | <tabbox>
> |  <tablabel>About <tablink href="about.html"/></tablabel>
> |  <tablabel>Credits <tablink href="credits.html"/></tablabel>
> | </tabbox>

   <tabbox>
    <a href="about.html">About</a>
    <a href="credits.html">Credits</a>
   </tabbox>


> I would also like to propose a more flexible version version of the 
> <iframe> element that I'd like to call <divframe>. The <divframe> 
> element would act much like an <iframe> element, but it would be 
> resizable and much more CSS-friendly. It could effectively be used to 
> replace server-side includes, while at the same time having all the 
> benefits of a frame as well.

Could you expand on this?


> One of my main concerns about the examples I've seen using <a> for tabs 
> is the fact that the examples show no content inside the actual tab box.

Well, the idea there was to make it possible for a tab to act as a link, 
with the assumption being that the target page also has an equivalent tab 
group. I am rather dubious about this, though. While it would be nice to 
get effects like that seen on whatwg.org more easily (and more resilient 
to the effects of narrow windows, etc), I don't think that the way the 
spec does it now is the way to go.

I'm leaning towards the idea that it is in fact purely presentational, and 
that the semantics is just a list of links (which is is, in the whatwg.org 
content) which should be styled by binding the elements to some XBL that 
makes them look like tabs.


> |  <divframe name="tabbody" href="main.html">
> |   Your user agent does not support frames or is currently configured
> |   not to display frames.
> |  </divframe>

That's a pretty convincing argument against this element. :-)


> [...]

Your proposal is indeed quite neat overall, but I think it suffers from 
many of the same problems as the current one in the spec, and has the 
additional disadvantages of incrased redundancy in the markup and more 
elements generally.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'