[whatwg] Ideas regarding Web Applications 1.0

Tue Feb 27 21:38:23 PST 2007

On Tue, 23 Nov 2004, Matthew Raymond wrote:
> > > 
> > > 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.
> 
> Perhaps, but with a <tablabel> element (or at least an implied 
> <tablabel> element), you could style all of the tab labels by just 
> styling <tablabel>, and you wouldn't have to worry about special CSS 
> mechanisms for <a>, <h[n]> and <legend>.

So between you writing that e-mail and today, we dropped the tabs stuff 
altogether. I still don't really think we have a good story for tabs. 
However, I think there may be a solution to this that doesn't actually 
involve any new elements. The semantics of a tabbed UI are basically the 
same as any table of contents with a set of sections. Thus, I think the 
semantics should look like:

    <section> (or <article> or <body> or similar)

       <section>
         <h1> ... </h1>
         ...
       </section>

       <section>
         <h1> ... </h1>
         ...
       </section>

    </section>

The tabs would then be added using XBL.

> > > 2) The content for the tab and the fallback header are not and 
> > > cannot be separate.
> > 
> > That's a feature, not a bug.
> 
> Not really. A header can span an entire page, while a tab label is meant 
> to be displayed in a much more confined space. The webmaster may wish 
> to use a shorter or abbreviated title for the tab label.

That's a general presentation problem -- you might often want to shrink 
content as it reaches smaller media. For example, your page-wide header 
might need shortening on handheld media. I don't have a good proposal for 
this. Maybe we need the opposite of <abbr>?

> > > 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).
> 
> I agree that this was a weak point. A better point is what happens if 
> you wanted the first header in the <section> to actually be the first 
> header in the <section> rather than a tab label.

You'd still notice it pretty easily.

> > > 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.
> 
> Not true, in that you never have multiple <legend> elements in a 
> <fieldset>.

> > > 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.

Note that this becomes quite easy if we use XBL (which can declare 
pseudo-element mappings like this).

> > > | <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.
> 
> What if you're using an image for a header? Take it from the |alt| text? 
> What if you have a really long header and you want to trim it down for 
> the tabs? By allowing both an implied and an explicit system, you can 
> both empower webmasters and let them be lazy at the same time.

In general, I'd push for us to consider that kind of thing at a future 
version 2 point. But I see what you are saying.

> > 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".
> 
> Morons can simply be taught the implied labeling method. Tutorials don't 
> always teach the more detailed aspects of markup right now, and when WA1 
> comes out, it will be no exception.

As a general principle, I disagree with the above. Authors learn from 
copy-and-pasting, from random poking, from looking at documentation, 
whether targetted at advanced authors or not. We have to work on the 
assumption that the inexperienced authors will use the advanced features, 
and will shoot themselves with them. Thus, we have to go out of our way to 
make it hard to misuse features. Avoiding redundancy is a key way to do 
this.

> > > 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?
> 
> The idea was to create an element that has all the benefits of an 
> <iframe> and a <div> element at the same time. At the moment, <iframe> 
> is a real pain to deal with, in part because of how it's defined in HTML 
> 4.01:
>
> "Inline frames may not be resized (and thus, they do not take the 
> |noresize| attribute)."
> 
> The idea is to create a better version of <iframe> without breaking 
> backwards compatibility. Perhaps one could use <object>, but it's not a 
> frame, and I don't think it's not styled as a block element by default.

How would this feature look like from the DOM? Is there any reason 
improvements to CSS couldn't be used to do 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.
> 
> I'd rather not depend on XBL to do something as basic and common as 
> tabs. It's entirely possible that some WA1 clients may not support XBL. 
> I'd prefer that we be able to implement tabs with little more than HTML 
> and CSS.

I'm not convinced tabs are as simple as you say.

> That said, if I could somehow link navigational lists to <switch>:
> 
> | <div id="tabbox">
> |  <nl orientation="horizontal">
> |   <h>Contents</h>
> |   <li><a href="#introduction">Introduction</a></li>
> |   <li><a href="#conformance">Conformance</a></li>
> |   <li><a href="#references">References</a></li>
> |  </nl>
> |
> |  <switch>
> |   <section id="introduction">
> |    <p>Introduction contents...</p>
> |   </section>
> |   <section id="conformance">
> |    <p>Conformance contents...</p>
> |   </section>
> |   <section id="references">
> |    <p>References contents...</p>
> |   </section>
> |  </switch>
> | </div>
> 
> The above markup is fairly obvious. The <nl> element creates a serious 
> of blocks that can be styled as buttons or tabs. These "tabs" contain 
> hyperlinks to sections in the <switch> element. When the hyperlinks are 
> clicked, the respective section is made active.

I'm definitely not convinced that it is a _semantic_ of that document that 
the three sections are mutually exclusive. Why would I never want to 
compare the references and the conformance section side-by-side?

(Note that <switch> also fell out during the past few months. I intend to 
bring something like <switch> back, but I'm not sure how.)

> > > |  <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. :-)
> 
> I get what you're saying, but I don't see a better solution for 
> backwards compatibility.

Showing the content itself would be a good fallback. :-)

> > 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.
> 
> I understand your concerns about redundancy. My concern, though, is that 
> much of your WA1 specification depends on overloading existing markup 
> with functionality that is non-obvious and better suited to new markup. 
> This results in markup that is more difficult to understand and harder 
> to read. I also suspect it will create bloody conflicts between UA 
> vendor employees/volunteers over how to implement portions of the spec 
> that may not be well defined in specific use cases.

Yeah. At the moment we've just dropped the tab feature. I think a good 
argument can be made for saying it's presentational, and I didn't see any 
good proposals for how to put it into markup.

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