My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 14: Support output as XHTML 1.0 Strict or HTML 4.01 Strict
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  jdand...@gmail.com
Closed:  May 2007


Sign in to add a comment
 
Project Member Reported by jdand...@gmail.com, Sep 26, 2006
There's a debate raging - that of using HTML vs XHTML in present-day user agents (browsers). 
Here's a sampling:

Sending XHTML as text/html Considered Harmful
http://www.hixie.ch/advocacy/xhtml (Note: Ian works at Google in NYC!)

Understanding HTML, XML and XHTML
http://webkit.org/blog/?p=68

Sending XHTML as text/html Considered Harmful to Feelings
http://h3h.net/2005/12/xhtml-harmful-to-feelings/

I can appreciate both sides of the issue, so I'm curious to see how much of a stretch it would be 
to have the XSLT write HTML or XHTML There are only a handful of gotchas to be overcome along 
the way, and the prognosis looks excellent thus far.
Sep 26, 2006
Project Member #1 jdand...@gmail.com
Here's what we need to do:

1. Offer the appropriate DOCTYPE for HTML 4.01 Strict.
2. Use lang vs xml:lang.
3. Adjust the Content-Type metadata.

These two items we should do regardless of the mode:

1. Move the id attribute from html to body.
2. Add a legend element to each fieldset. (Originally kept out for other reasons.)

In initial tests, this is all it takes to get valid HTML 4.01 Strict.
Status: Accepted
Sep 26, 2006
Project Member #2 jdand...@gmail.com
To clarify, the idea here is to offer BOTH options - HTML or XHTML.
Sep 26, 2006
Project Member #3 jdand...@gmail.com
Note that, in HTML output mode, the content-type metadata is automagically inserted! This is what drove the 
original addition of the plainHeadStart template ...

"Utility functions for generating head elements so that the XSLT processor won't add a meta tag to the output, 
since it may specify the wrong encoding (utf8) in the meta tag."

If there's a way to influence the encoding in the new XSLT processor (recently changed in the GSA), so much the 
better.
Sep 26, 2006
Project Member #4 jdand...@gmail.com
Per http://www.w3.org/TR/xslt#section-HTML-Output-Method (regarding xsl:output's encoding attribute):

"The encoding attribute specifies the preferred encoding to be used. If there is a HEAD element, then the html 
output method should add a META element immediately after the start-tag of the HEAD element specifying 
the character encoding actually used."

Gaah. The catch is we can't reference a variable or piece of the XML in xsl:output.

We have two choices out the gate: Settle for utf8 (for now), or go back to hard-coding the HEAD element. I'm 
leaning toward settling for utf8 and holding out for a cleaner way to set the encoding, but I suppose I could 
be swayed the other way. :)
Nov 17, 2006
Project Member #5 jdand...@gmail.com
We have another snag. Attached is a minimal test case. Try to validate it.

Thus, we have to work around this next - but still make the CSS do our bidding.
test.html
381 bytes   Download
Nov 17, 2006
Project Member #6 jdand...@gmail.com
Wait! Pilot error. A legend element needs to be added per:

ELEMENT FIELDSET - - (#PCDATA,LEGEND,(%flow;)*)

Whew. :)
May 13, 2007
Project Member #7 jdand...@gmail.com
(No comment was entered for this change.)
Status: Started
May 13, 2007
Project Member #8 jdand...@gmail.com
Fixed in revision 16. Be sure to get the entire revision - style files have been
updated! (Note: Examples have not been updated to match just yet.)
Status: Fixed
Sign in to add a comment

Powered by Google Project Hosting