Re: [OFF LIST] HTML 5 and XHTML 2 combined

On 6/1/09 15:24, Molte wrote:
> It's also good that XML doesn't allow any slacking with
> the code like not making it well-formed.

Perhaps, though the utility of this is debatable. For example:

1. It makes integrating XHTML into the existing tolerant ecosystem of 
the web, with tools that accept and emit tag soup and with much content 
provision financed by incorporating arbitrary third-party code (ads), 
very difficult.

2. Draconian error-handling reduces the chance that people will see your 
ad, buy your products, read your content, or play your games, all 
because of an unescaped ampersand (for example). Content producers tend 
to prefer partial to total failure as an error state.

> That makes it more
> device-independent and easier for browsers and applications to parse it
> without it would need a lot of error handling.

Strictly defined processing requirements are more important than 
arbitrary syntactical rigidity to making it easy to develop consuming 
devices and applications, because it is processing requirements that 
directly reduce the need for reverse engineering.

See also the current discussions along these lines on the www-tag 
mailing list.

> That the HTML 5 Working Group thinks they can rebirth HTML is without
> good reason in my eyes (why use an old, deprecated language when the
> newer is just better?).

text/html has never been "deprecated" in the W3C sense.

As to why a new version of HTML is being developed by W3C, Tim 
Berners-Lee has offered some reasons:

http://dig.csail.mit.edu/breadcrumbs/node/166

> In XHTML 2 all elements (nearly) can serve as a hyper link or an image.

Note this wasn't backported to HTML5 because browser vendors thought it 
would be hard to implement.

> I would never have thought of that idea myself, but when I think about
> it, what /is /the reason to have the img and a tags? Then it's just
> crazy they keep the tags around when they're no longer needed...

If the more generic mechanisms can in fact be implemented, then yes the 
specific mechanisms are likely redundant.

> Also a good thing about XHTML 2 is that it distances between structure
> and layout. That should make the job easier for screen-readers and such
> (and just make nicer code).

Can you explain what in a conforming HTML5 document might fail to 
distance "structure" from "layout"?

> XHTML 2 uses XForms. After my opinion there is both pros and cons about
> that. That the layout is not defined makes the user able to choose which
> method to fill in a form he/she would prefer. But it also mean that you
> (as the web developer) can't control the layout, and therefore I think
> it might be triggy getting the input field to fit on the page when you
> don't know how it is going to look like.

I'm confused. Doesn't CSS apply to XForms, allowing authors to suggest 
layout?

There are examples of applying CSS to XForms in the XForms 1.1 draft:

http://www.w3.org/TR/xforms11/

> XHTML 2's role attribute might help defining your code and should be to
> prefer compared to HTML 5's predifined classes (you should be free to
> choose whatever you want for class names).

HTML5 doesn't have predefined classes anymore.

I believe the role attribute is under consideration as part of ARIA.

> Let's start off with the figure element; it's cool you finaly will be
> able to make a description to an object or image.

I believe that's possible in XHTML2 too:

<img id="photo" src="cat.jpg">A black cat plays with a ball of string 
beneath a Christmas tree.</img>
<p about="#photo" property="description">My cat Ernie fooling around 
last Christmas.</p>

> input is improved with support for e-mail, date, time, numbers, and
> URLs. Perhaps that is a better solution than the XForms?

Note XForms includes these data types:

http://www.w3.org/TR/xforms11/#datatypes-xforms

> Having tags like heading, footer, and so will better structurise the data.

There is no "heading" element in HTML5 (I think you mean the "header" 
element).

"header" is approximated by XHTML2's "role='banner'.

There's no approximation of the "footer" element AFAIK.

> Of some reason HTML 5 includes old deprecated layout-tags like font used
> when there was nothing called CSS yet.

"font" has been dropped from the conforming set of HTML5 elements.

HTML5 includes "b" and "i" with some semantic fig-leaves:

http://www.whatwg.org/specs/web-apps/current-work/#the-i-element

http://www.whatwg.org/specs/web-apps/current-work/#the-b-element

I'm dubious as to whether these meagre coverings guarantee media 
independence, but I don't think their inclusion is going to make a major 
practical difference to end-users, especially if the more specific 
elements are used appropriately (e.g. heading elements for headings, em 
for emphasis, strong for importance, mark for marked sections). 
Conversely, their absence wouldn't guarantee the use of these other 
elements. It's easy enough for a "WYSIWYG" editor to substitute:

<span class="italic">

and

<span class="bold">

in XHTML 2, for example.

Did you have any other elements in mind?

> HTML 5 believes a language needs to be backwards compatible. I wonder if
> the persons behind that idea have ever though about, why you include the
> version number in the (X)HTML document... The browser should be able to
> parse many language versions differently.

HTML5 attempts to define how browsers can interoperably parse the 
existing text/html corpus such that the corpus is mostly usable; 
previous HTML specifications do not do this. For example, they do not 
define error handling - necessary for most of the corpus - in sufficient 
detail.

As to why HTML5 tries to avoiding defining different parsing for a new 
version, see:

http://wiki.whatwg.org/wiki/FAQ#How_are_pre-HTML5_documents_parsed.3F

> In HTML 5 when using a WYSISYG editor you NEED to include which editor
> in the page.

I believe you're referring to a requirement dropped from the draft a 
long while ago. If not, could you please link to the relevant section of 
the current draft?

http://www.whatwg.org/specs/web-apps/current-work/

--
Benjamin Hawkes-Lewis

Received on Tuesday, 6 January 2009 17:10:57 UTC