Why would anyone move to xhtml 2.0? (and some problems with the current draft)

Ernest Cline wrote:

> ... nothing in the proposal that cannot be achieved by 
> prudent use of XHTML 1.  

Lachlan Hunt and Christian Hujer responded, but I'm 
not convinced -- and several of the named improvements 
may actually be worse.  

Lachy wrote:

> ... the <section> and <h> elements ... achieved using this:
<div class="section">
    <h1 class="h">heading 1</h1>
    <div class="section">
        <h2 class="h">heading 2</h2>
        <!-- etc... -->
    </div>
</div>

That is truly ugly -- but the only reason to do it is so that 
you can treat all headings the same way, regardless of level.

To be honest, I think most authors who care about style will
want to treat headings differently depending on level.  If so,
they may well prefer a stylesheet that says

h1
h2
h3
h4
h5
h6

instead of:

body > h
section h
section section h
section section section h
section section section section h
section section section section section h

And since a "section h" also matches a level 6 heading,
you have to explicitly override all earlier declarations,
or else make the selections even more complicated.

body > section > section > section > section > h

OK, no 5th section sneaking in between.  Hopefully 
there weren't any divs or blocks large enough to 
include a section, or we'll miss that one...

> XForms and XMLEvents are a big advantage for 
> accessability, and other advantages over current html 
> forms and script event handlers like @onclick, etc.  

Are you sure?  There has been a fair amount of time
to special-case workarounds for what we have now.
What do you think will become much easier?  Or 
at least more commonly supported by tools?

> The Hypertext attribute collection which can be specified
>  on most (or all?) elements provides many useful advantages.
>  Being able to make any element a hyperlink with @href or a
>  citation with @cite

I'm not sure these are worked out enough.  Just to clarify -- 
here is my current understanding.

(1)  If an element has a "src", (it is an object) then it should 
be replaced by the target of that link.  Any contained 
elements will then be dropped completely.  If the "src"
can't be fetched or understood, then the contents are used
instead.  Iff this object actually interacts (and takes clicks),
then it will href attributes will probably be meaningless.

(2)  If an element has an href, then the default "onclick" for
this element is to follow the href.  Selecting and activating
("clicking", in a normal GUI) anywhere in that element's 
display area should follow the href link.  Unless some 
contained _or_ containing element also has an onclick event.  
Then it depends on whether the event is captured or bubbled.

As a user interface issue, the borders "nearby" a link will
suddenly start to do something surprising, instead of just
ignoring you so that you move the mouse a little farther.

Since this is a bad interface, different agents will develop
their own incompatible workarounds, such as anonymous
bounding boxes just-a-bit-bigger, and event-capture 
boxes that are larger than the display boxes.

Also, some authors (or tools) will feel the need to fill out
this attribute for large blocks, so that users will no longer
be able to safely "unfocus" by clicking in a blank spot.

(3)  If an element has a cite attribute, well ... maybe that
should be treated like an href, only different.  Right-click?
Follow-if-there-is-no-href?

Christian Wolfgang Hujer wrote:

> some more reasons came into my mind, not for XHTML 2.0 in 
> particular but for XHTML in general.  ...

> 1. Inclusion of document fragments using external entities
> 2. Usage of XML Inclusions (XInclude)
> 3. Linking with XML Linking Language (XLink)
> 4. Pointing to document fragments and similar using XPointer and XPath
> 5. And of course being open for all additional technologies 
> like SVG, MathML 
> etc..

As a programmer, I like this.  Write something only once.

But as a cynic, I have to ask why this would work any 
better than the current templates that people already
use -- particularly with content management systems.
 
> With these technologies,
> * the documents can become much smaller,

When I manually clean up a "typical" web page,
I usually shrink it by at least 90%.  (In fairness, I 
often delete "content" like navigation and ads.)

So the total savings in bytes is ... almost meaningless.

Remember,  this is for a typical page where the image 
is just branding or an ad -- not meaningful content.  
But there are still a few images there, and almost any 
image is larger than an awful lot of markup.  Yet
web sites continue to use huge images.  So I don't 
think this is currently a real driver.

> * the documents can become much more modular,

Not really.  If you keep it as a separate document, then
you need to inline the data to ensure it doesn't move or
get lost.  If you're willing to track all the little resources
separately, then today's Content Management Systems
and templates already solve your problem.

> * the layout can become much more efficient and screen 
> resolution independent,

If you're worried about resolution independence, you
can just use html 4 (or html 2) without a stylesheet; you
don't need xhtml.  The reason so many sites look so lousy
on a smaller monitor is that authors really *don't* worry
about these very much, and browsers try to mimic the
intended presentation.

It is possible that xhtml + CSS would encourage them
to at least consider these issues, but ... I doubt it.  
Realistically, they will do what their tools provide.  The
fact that current tools default to "bad" choices isn't a 
limit of html 4; it is a marketing decision by the vendors.

I suppose "new standard" might be an excuse to put
out a new version, and if there were hints that laws on
accessibility might start to be enforced, this could be 
among the new features -- but it isn't tied to xhtml.

> * it is easier to develop tools that automatically process 
> these documents,

There are a fair number of tools that process html OK.

If more precise meanings are needed, then current 
systems just define their own tags - they haven't waited 
for xhtml.  (And xhtml wouldn't really solve their 
problems anyhow; it isn't specialized enough.)

-jJ

Received on Friday, 5 December 2003 15:18:06 UTC