RE: The Return of "WaSP Asks the W3C"

> -----Original Message-----
> From: public-evangelist-request@w3.org 
> [mailto:public-evangelist-request@w3.org] On Behalf Of Jim Ley
> Sent: 22 September 2003 14:07
> To: public-evangelist@w3.org
> Subject: Re: The Return of "WaSP Asks the W3C"
> 
> 
> 
> "Richard Ishida" <ishida@w3.org>
> > I use XHTML 1.0 exclusively for my web pages these days.  I 
> serve them 
> > as text/html and follow the compatability suggestions in 
> App C of the 
> > xhtml spec.
> 
> What QA tool do you use to ensure this, is it purely visual 
> inspection, and human processing, or do you actually have 
> tools that do it for you?
> 
> The majority of your reasons are about authoring,  and there 
> are good reasons for authoring in a semantically rich XML 
> format, however authoring and publishing are seperate 
> activities.  For me XHTML doesn't meet my authoring needs, 
> it's semantically pretty empty, and applicable only to 
> certain types of documents.  However even if it meets your 
> authoring needs, that doesn't follow that is how you should 
> publish it to html user agents, conversion from XHTML or 
> other XML formats is a simple mechanical process available 
> from tools such as tidy, as part of your publishing process 
> you can perform this translation, so you get your authoring 
> ease combined with serving appropriate content to all users 
> (rather than content which is only compatible with some html 
> user agents)

I guess I don't see why you should go to so much trouble.  If it's in
xhtml for good reasons, as you mention, and if you can successfully
serve it as xhtml, why change it to html?  (also see below)

> 
> > [3] I figure that if we continue to use HTML then browser 
> developers 
> > will have less incentive to implement xhtml properly.  I'd 
> eventually 
> > like to be able to use xhtml strict served as 
> application/xhtml+xml, 
> > but why would browser developers feel motivated to enable that if 
> > everyone just continues to use html?
> 
> My problem with this,  XHTML 2.0, it's a very different 
> mark-up language, yet as far as I've seen the mime-type will 
> still be application/xhtml+xml, the current preponderance of 
> invalid XHTML being served as text/html with the intention 
> that it will be changed to being served as 
> application/xhtml+xml is a problem for this, as soon as UA's 
> start being application/xhtml+xml user agents exist, people 
> will change the mime-type and the UA manufacturers will have 
> to start adding tag-soup parsing of it too.

I don't think that the mime-type indicates what DTD to use.  So I'm not
sure that this is a valid argument.

Note also that I am not serving 'invalid XHTML'.  It is perfectly valid
xhtml - and therefore well-formed xml too. Actually that's a key reason
I'm using xhtml.  Its just that the browser handles it as if it were
html.  My desire is to migrate to xhtml 1.0 served as
application/xhtml+xml when that is supported.  That should require no
change to my document code.  I'll probably only write new documents in
xhtml 2.0 when that is eventually supported.


> 
> For me, xhtml as text/html is a demonstration of how UA 
> manufacturers can ensure maximum future compatibility by 
> parsing everything as tag-soup - it supports tag-soup 
> parsing, and far from being a transitional process leading to 
> a more compliant world, it's rubber stamping the current 
> tag-soup behaviour.

I think my definition of 'tag soup' may be different from yours.  For me
tag soup is overlapping elements, documents that don't validate against
the DTD, use of browser-specific tags, use of presentational markup
instead of css, bloated code through use of many font tags, etc. 


> 
> Encouraging application/xhtml+xml support will be done by 
> serving application/xhtml , not serving tag-soup, serving 
> tag-soup encourages tag-soup!

Well, I agree that serving application/xhtml+xml will encourage browser
developers more, but it won't make our pages very readable for large
swathes of the population.  On the other hand, just staying with HTML
doesn't provide any incentive at all.  That's why I try to use xhtml to
the extent currently possible.


> 
> > **  There is one tweak I have to make.  If I want my pages 
> to trigger 
> > standards-compliant mode in IE I have to remove the xml declaration 
> > before posting.
> 
> I don't particularly understand this, as Appendix C clearly 
> says that you shouldn't include an xml declaration in any 
> case "Be aware that processing instructions are rendered on 
> some user agents" (due to a great many browsers actually 
> rendering it, quite apart from those that change rendering 
> modes based on it)

Well, yes, this is another good reason.  

For my setup I find that I need an xml declaration in XMetal to ensure
that the file is read in correctly by the editor.  It can also be
important for indicating the character encoding of xml files.  So I
personally tend to keep it at the top of my files until I decide to
serve them as html.

> 
> Jim.
>

Received on Monday, 22 September 2003 10:32:33 UTC