[whatwg] Ideas regarding Web Applications 1.0

[Matthew Raymond]

Ian Hickson wrote:
[Example snipped.]
>>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.

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

>>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
which to use a shorter or abbreviated title for the tab label.

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

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

>>Here's the example modified to address some of these problems:
>>
>>| <tabbox>
>>|  <section level="2">
> 
> level="2" should be inferred from context.

    In my more recent messages, I use the |level| attribute as part of
an automatic header importance mechanism where the |level| of a parent
<section> is reflected in child <section> elements. The advantages are
more obvious with a complex document structure.

>>|   <h><h2>About</h2></h>
> 
> <h><h2>? Ew! :-)

    I've changed my position on this since the post you're quoting. All
header elements would be valid now under my scheme, so this kind of
nesting is unnecessary.

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

    See above, although I should make it clear that my current view of
<h> is that it allows the user to take advantage of the automated
importance system.

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

    Why not just have implied <tablabel> elements that could be defined
explicitly? That way you could still use your <section>-related example
from the spec, but you could also define a separate label directly.

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

    Explain to me why you would want tab labels to look like headers?
Keep in mind that CSS is all about presentation.

    Also it doesn't shove header = tab title down the webmasters' throats.

> (The element should be called <group> or some such.)

    I don't like "group", because it sound more like a <fieldset> than a
set of tabs.

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

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

    This ignores several issues. First, you don't have to use the |for|
attribute. You can use implied or sibling association, in which case you
only have one additional "about". Also, since <tablabel> is optional,
you can simply say this:

| <tablink><a href="about.html">About</a></tablink>

    What's more, if you don't care about legacy browsers, you can do the
following:

| <tablink href="about.html" label="About"/>

    Only the <a> elements extremely short text length give it an
advantage at this point. Look at what happens when you change "a" to
"hyperlink" and put these examples side by side:

| <hyperlink href="about.html">About</hyperlink>
| <tablink href="about.html" label="About"/>

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

    Hmm, I'm not sure I meant those behaviors to be used in the same use 
case. I supposed I phrased it poorly. One could do the both of the above 
with my markup model, but it wouldn't be the ideal way to handle the markup:

| <tabbox>
|  <tablabel label="About"/><tablink href="about.html"/>
|  <tablabel label="Credits"/><tablink href="credits.html"/>
|
|  <ul>
|   <li><a href="about.html">About</a></li>
|   <li><a href="credits.html">Credits</a></li>
|  </ul>
| </tabbox>

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

| <tabbox>
|  <tablink href="about.html" label="About"/>
|  <tablink href="credits.html" label="Credits"/>
| </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?

    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.

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

    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.

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

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