RE: XHTML 1.0 spec (was Re: Call for contributions: new and improved "Web site quality" articles

Hi Jim (and Bob)
    Following your comments about XHTML and MIME types I've written a
draft advisory document which takes on-board your suggestions:
http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-35/

and a case study which explains why the QA Focus Web site uses XHTML and
how we intend to change the MIME types:
http://www.ukoln.ac.uk/qa-focus/documents/case-studies/case-study-22/

Comments welcome.

Thanks

Brian

---------------------------------------
Brian Kelly
UK Web Focus
UKOLN
University of Bath 
BATH
BA2 7AY
Email: B.Kelly@ukoln.ac.uk
Web: http://www.ukoln.ac.uk/
Phone: 01225 383943
FOAF: http://www.ukoln.ac.uk/ukoln/staff/b.kelly/foaf/bkelly-foaf.xrdf
For info on FOAF see http://www.ukoln.ac.uk/ukoln/staff/b.kelly/foaf/

> -----Original Message-----
> From: public-evangelist-request@w3.org 
> [mailto:public-evangelist-request@w3.org] On Behalf Of Jim Ley
> Sent: 02 October 2003 19:13
> To: public-evangelist@w3.org
> Subject: Re: XHTML 1.0 spec (was Re: Call for contributions: 
> new and improved "Web site quality" articles
> 
> 
> 
> "Brian Kelly" <b.kelly@ukoln.ac.uk>
> > On Thu, 2 Oct 2003, Jim Ley wrote:
> > > XHTML is only "allowed" to be served as text/html if it's under 
> > > Appendix
> C,
> > > if someone would like to correct me on that and say 
> Appendix C isn't 
> > > normative and any old XHTML can be served as text/html then I'll
> withdraw
> > > the criticism.
> >
> > The document says
> > "C. HTML Compatibility Guidelines
> > This appendix is informative."
> >
> > If you think that's incorrect I suggest the editor of the 
> spec should 
> > be informed (I guess there's a QA of the spec issue).
> 
> I agree Appendix C is non-normative, however the MIME-type 
> definition 5.1 is normative 
> http://www.w3.org/TR/xhtml1/#media and it says
> 
> | XHTML Documents which follow the guidelines set forth in 
> Appendix C, 
> | "HTML Compatibility Guidelines" may be labeled with the 
> Internet Media 
> | Type "text/html"
> 
> So whilst Appendix C isn't normative in itself (since you can 
> use application/xml or application/xhtml+xml for your XHTML) 
> if you wish to serve it as text/html 5.1 requires it to be.  
> This is certainly been my interpretation and it's been 
> discussed here and in other places often enough that I'd've 
> thought someone would correct me on it if it was wrong.
> 
> > C.7 says you need lang: and xml:lang attributes.  I have the lang 
> > attribute in the html element.  I don't need to give the xml:lang 
> > attribute as C.1 allows me to omit it (as I understand it).
> 
> Ah, I understood the xml declaration was the
> <?xml version="1.0"?> and that was all you were being allowed 
> to leave out, it had no bearing on C.7, I could be wrong of 
> course, but again, it's been often discussed.
> 
> 
> > So I think my approach is better than creating HTML 4 resources.
> 
> All of your reasons for serving XHTML how are you, I entirely 
> agree with, and are completely understandable, indeed they're 
> probably required in the real world.  However you've not 
> given the reason why HTML 4.01 strict is not appropriate for 
> you, it's semantically identical to XHTML 1.0.  Or what it is 
> about it that makes you not want to author it (a point that 
> I've not yet seen made on this list)
> 
> > Note that an advantage with text/html is that the page will 
> display if 
> > the XHTML is invalid.
> 
> I'd personally say, this is a huge disadvantage of XHTML as 
> specified, not an advantage of breaking the rules, it doesn't 
> have a method of degrading, the don't display anything in 
> error is a key weakness, and a key strength of HTML 4.01 as 
> deployed.  I don't think pretending XHTML is really HTML 
> tag-soup and relying on that get us out of trouble if we make 
> a mistake is
> to be applauded.   I don't think we should deploy XHTML in any format,
> unless we have automated publishing tools to actually ensure 
> it's valid, the constraint on invalid - no rendering is too 
> severe a failure, in a document that is mostly correct.
> 
> Jim.
> 
>

Received on Monday, 6 October 2003 09:55:37 UTC