W3C home > Mailing lists > Public > www-html-editor@w3.org > January to March 2003

Re: Feedback on XHTML 2.0 WD (20030131)

From: Herr Christian Wolfgang Hujer <Christian.Hujer@itcqis.com>
Date: Fri, 28 Mar 2003 10:00:10 +0100
To: Toby A Inkster <tobyink@goddamn.co.uk>
Cc: www-html@w3.org, www-html-editor@w3.org
Message-Id: <200303281000.13994.Christian.Hujer@itcqis.com>

Hash: SHA1

Hello Toby,

Am Donnerstag, 27. März 2003 21:14 schrieb Toby A Inkster:
> On Thu, Mar 27, 2003 at 02:26:04PM +0100, Herr Christian Wolfgang Hujer 
> | 4. XHTML 2.0 Document Type
> | I'd like to see XHTML 2.0 also include MathML, not just XForms.
> | (I know that's just a wish)
> Would be nice. Perhaps, create two versions of XHTML2:
> 	* Standard
> 	* Enhanced
> With "Enhanced" including support for SVG, MathML, etc. That way, people
> can include more appropriate XML-based markups in their documents
> without sacricifing that "Valid XHTML" button.
I agree with that.
Currently this is achieved by "Profiles", I think, "Profiles" are too far away 
from the normal HTML / XHTML Recommendations and I fear companies like MS 
won't support SVG until it is mentioned as part of an XHTML recommendation 

> | About the footer suggestion: Though I like the idea, I'm against it
> | because it can be achieved with div and CSS.
> Then why not get rid of <p/>, <blockquote/>, <abbr/>, <pre/>, <quote/>,
> etc... they can all be achieved with <div/>, <span/> and CSS.
But then... the logical markup always is just a compromise. And I think 
section is appropriate enough for footers.

> | 7.3 The title element
> I say get rid of the <title/> element altogether. Instead use <meta
> name="Title"> or <meta name="DC.Title">. After all, why should <title/>
> have its own element, but not other meta data?
With title being an element, it's possible to enforce documents to have a 

> | 8.9 headings
> | I'd even not include h1-h6, not just deprecate them. Remove them. With
> | section and h, they're not required anymore.
> Agreed. If you really want to preserve the old model as a fall-back,
> then include a "level" attribute.
I agree.

> | Currently, Mosaic, Netscape / Mozilla and lynx are the only user agents I
> | know that process link elements other than those linking to stylesheets.
> | But link is one of the most useful HTML elements ever since, I think.
> Links, eLinks, Opera 5 for Mac, Opera 7 for any platform, Googlebot...

Links (2.1pre2) has no full support for <link/> elements since it does not 
render the title attribute. When defining bookmarks, I get a list of several 
Link: Bookmark. Really helpful. As helpful as not rendering bookmark links at 
Same applies to elinks 0.4.2

I can't try Opera 5 for Mac because I have neither a Macintosh nor a 
Shapeshifter for my Amiga.

But Opera 7 (at least 7.0.0 P1 for Linux) also lacks full support for <link/>. 
It didn't respect anchors in links and doesn't support Bookmark links at all. 
So link support in Opera 7 is worse than that of Links.

Still, Opera 7, Links and elinks deserve plaudit, since at least they strive 
to support <link/>, unlike IE, which I dislike for not supporting <link/> at 
all (except for stylesheets).

About Googlebot I have no information wether it just blindly follows any src 
and href attributes or wether it knows the semantics of the rel and rev 
attributes and knows how to deal with the title attribute.

- -- 
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/
Version: GnuPG v1.0.7 (GNU/Linux)

Received on Friday, 28 March 2003 05:31:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:08:48 UTC