2010/9/2 Mark Lentczner :

On Sep 2, 2010, at 5:00 AM, David Waern wrote: If you'd like to see the new look in action, I've generated some pages for a few packages here:        http://www.ozonehouse.com/mark/snap-xhtml/

Is it possible to switch back from frame version to non frame version? The "Frames" button disappears in frame mode... Also style changing works only inside the main frame.

I am well aware of the differences between HTML and XHTML. I choose to switch Haddock's output from HTML to XHTML mostly because I have found the consistency of rendering cross-browser to be greater and easier to achieve with XHTML. I'm not alone in this opinion: Many well respected web design authorities have promoted, and publish their own sites, in XHTML.[1] Even Microsoft's own developer web site uses it[2]! Indeed, there is just one kind of validation error in the pages: the ids for section headings within a page are pure numbers and need an alphabetic prefix. That said, they work just fine in all browsers. I did fix the very bad validation problems with other ids (those that link to specific program symbols), and several other classes of ids. I will push my fix for the remaining ids and it will appear in the next release.[3,4] As for extensions and doctypes, I believe that we are following best practices for the most interoperable result among browsers, and given that we need to produce output that will be served in a variety of ways including different web servers, and being browsed directly off the file system.[5] Of course, as soon as it is viable, I would love to move Haddock's output to HTML 5. However, given the pace of adoption of such standards, and the range, age and mix of browsers that readers of Haddock's output use, it is likely to be two years off. - Mark [1] See, for example: http://www.alistapart.com/ http://www.csszengarden.com/ http://www.quirksmode.org/ http://happycog.com/ http://www.w3.org/ all of which are published as XHTML [2] See: http://msdn.microsoft.com/en-us/default.aspx [3] Considerable thought was put into both making identifiers validating, while maximizing browser interoperability and forward/backward compatibility. See: http://projects.haskell.org/pipermail/haddock/2010-August/000623.html [4] Given that the prior Haddock produced pages with much more significant validation errors and they didn't seem to cause issues, I don't think we should rush a point fix just for this change. [5] I can't find any evidence for your assertion that Internet Explorer doesn't support XHTML, or the way Haddock names the files (and hence URLs). Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark

Followup: here's a version of the "xhtml" library which supports selectable doctypes (HTML 4.01, XHTML 1.0, XHTML 1.1): https://patch-tag.com/r/jmillikin/haddock-html/home I couldn't find a darcs repo for "xhtml", so this repo starts from the current version on Hackage. The main "xhtml" library has not been updated in years; it may be easier to upload it under the name "haddock-html", or even merge it into Haddock itself. There are three patches to Haddock to use this library, in varying degrees. They attached to this email (I can't upload my Haddock branch to patch-tag, for some reason). Also hosted at < http://ianen.org/temp/haddock-xhtml.patch >, if your client strips attachments. The first patch simply corrects minor errors in attributes, so <a> uses "id" instead of "name", and group header IDs don't start with a number. The second patch uses the upgraded "xhtml" to generate HTML 4.01. This effectively just corrects the doctypes on the files Haddock is already generating, so the patch is very small. Both of these patches are, I believe, suitable for commitment to the main repository/ The third patch is large, and I think it needs some reviewing before commit. It enables Haddock to generate XHTML (*real* XHTML). The vast majority is plumbing, so files are generated with the correct filenames, so servers can send them with correct mimetypes. Here's samples of the modified Haddock's output: http://ianen.org/temp/haddock/html/ http://ianen.org/temp/haddock/xhtml/ And here's verification that the pages are valid: http://validator.w3.org/check?uri=http%3A%2F%2Fianen.org%2Ftemp%2Fhaddock%2Fhtml%2F http://validator.w3.org/check?uri=http%3A%2F%2Fianen.org%2Ftemp%2Fhaddock%2Fxhtml%2F I haven't had time to extensively test the JavaScript yet, but it appears to work correctly in XHTML mode, so I believe no significant modification to it will be required.

On Thu, Sep 2, 2010 at 11:14 PM, Mark Lentczner wrote:

I am well aware of the differences between HTML and XHTML.

I choose to switch Haddock's output from HTML to XHTML mostly because I have found the consistency of rendering cross-browser to be greater and easier to achieve with XHTML. I'm not alone in this opinion: Many well respected web design authorities have promoted, and publish their own sites, in XHTML.[1] Even Microsoft's own developer web site uses it[2]!

I am very glad for the new CSS based layout! Thanks! I am very dubious that switching from HTML to XHTML makes anything more consistent. If you have a counter example I would love to see it, because this is an issue that affects my daily work. Here is why I am dubious. Browsers that support html and xhtml have two different code paths for rending html vs xhtml. The *only* way to select which code path is taken is by specifying the mime-type when you serve it. Either application/xml or text/html. So, if you take xhtml and serve it as text/html, then the browser will treat it as html and send it to the html code rendering path. In other words, it will send it down a code path that knows nothing about xhtml. The reason it works at all is because browsers do their darnest to make it render. So in xhtml you might have a tag like: <br /> Which, in xhtml, is short for <br></br>. When you send it down the html path, it the html render will see it as:
That is, it will see it as the normal <br> tag with a bogus attribute named /. Now, perhaps you can understand why I am dubious? Whether or not you send html or xhtml, it is being rendered by the same code that only understands html. So it is hard to see how adding bogus attributes like / to elements is going to improve cross browser compatibility. You are basically saying that if you add bogus markup to your html that the browser ignores, it is works more reliably than producing valid html. The fact that the bogus markup happens to make it valid xhtml is unimportant, because the code path knows nothing of xhtml anyway. If you converted the current code from xhtml to html, and anything changes in the rendering, I, for one, will be shocked, and very curious about why that happened. Also, if you plan to eventually migrate to the x/html 5, that spec says: "generally speaking, authors are discouraged from trying to use XML on the Web" Since the Web Hypertext Application Technology Working Group is full of people that actually develop browsers, I think their opinion carries some weight ;) Anyway, I expect the use of xhtml (served as text/html) instead of valid html in haddock will have no negative effects for me whatsoever. But the use of CSS will be a big win! So thanks again for doing that! - jeremy

On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 9/4/10 21:27 , Jeremy Shaw wrote:

...

Here is why I am dubious. Browsers that support html and xhtml have two different code paths for rending html vs xhtml. The *only* way to select which code path is taken is by specifying the mime-type when you serve it. Either application/xml or text/html.

XHTML starts with a <!DOCTYPE>.  You've just asserted that no browser is capable of noticing that and responding to it even though it's right at the start, while somehow managing to support <META HTTP-EQUIV=...> tags buried in the <HEAD> that can force it to go back and start from scratch.  Really?

Browsers *could* look at the doctype to pick the path. But they *do not*. What they look at is the http header that is sent before the response body is even parsed. (Obviously, things are a little different if it is reading a file from the disk). For example, if you do, curl -v http://www.w3.org/, you will see this: < Content-Type: text/html; charset=utf-8 < <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> Where the, Content-Type: text/html; charset=utf-8, is an HTTP response header. Rather than second guess what the response body is, the browsers consider that content-type header to be authoritative over the <meta /> tag. (http://www.dev-archive.net/articles/xhtml.html#types) If you open that url in firefox, and go to, Tools > Page Info, it will tell you: Type: text/html Render Mode: Standards Compliance Mode Encoding: utf-8 Meaning that even though it has the xhtml doctype (clearly shown in the curl output), firefox is only paying attention to the text/html content type. If you visit this page, http://www.echoofeden.com/htmlTests/xhtmlFix/index.xhtml Then it shows: Type: application/xhtml+xml Or, perhaps more relevant is this page: http://www.schillmania.com/content/entries/2004/10/24/application-xhtml+xml/... Which contains an xml error. You can tell it is using the XML rendering path, because it correctly gives an error instead of trying to guess what you mean and rendering the page anyway. Now, in the case of firefox. If you serve an xhtml with the DOCTYPE as text/html, it will trigger the use of the text/html renderer. If the DOCTYPE is xhtml 1.0 transition, then the browser will sniff that and use 'almost standards' mode. Which is exactly like the normal text/html standards mode except for one thing: the layout of images inside table cells is handled as they are in Gecko's "quirks" mode. (https://developer.mozilla.org/en/Gecko's_"Almost_Standards"_Mode). Everything I have ever read says that browsers only look at the content-type header to choose html vs xhtml rendering. And the supporting evidence seems to indicate that is true. If you have contrary evidence I would be glad to hear it. It's really difficult to find reliable information on this topic. - jeremy

 Or have we all been imagining the latter for the past, oh, 15 or so years?  (Mozilla had a serious bug relating to that restart for years; I assure you it's not a fantasy.)

I wouldn't be surprised if HTML and XHTML ultimately follow different rendering paths --- but your assertions are raising red flags and smell suspiciously like ideology taking offense at reality not automatically constraining itself to fit in its assigned pigeonhole.

- -- brandon s. allbery     [linux,solaris,freebsd,perl]      allbery@kf8nh.com system administrator  [openafs,heimdal,too many hats]  allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university      KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyC9qsACgkQIn7hlCsL25U8uACfdDA4RLUv5LedObrIaO4DpQE1 0CMAnj5ntJ6dhRju5sCw7IGfor68Aaa4 =TaCL -----END PGP SIGNATURE----- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai wrote:

In theory, what does file extension matter? Media type is the dictator. The normative Section 5.1 permits the choice of application/xhtml+xml or text/html. While the latter entails extra requirements in the informative Appendix C, as far as I can see (after all IDs are repaired) they are all met.

In a cunning combination of theory and practice in our reality, the file extension .html implies the media type text/html unless the server specifies otherwise. But since text/html is allowed in theory, so is .html allowed in practice. Indeed, Internet Explorer plays along just fine with text/html; it stops only when you claim application/xhtml+xml. For example http://www.vex.net/~trebla/xhtml10.html works.

This is a correct use of xhtml 1.0, and I fully endorse it.

It's not correct. Here's the exact same XHTML document (verify by viewing the source), served with different mimetypes: http://ianen.org/temp/inline-svg.html http://ianen.org/temp/inline-svg.xhtml Notice that the version served as HTML does not render properly. This is because the browser is treating it as HTML with an unknown doctype, not as XHTML. I'm not debating that it's *possible* to serve HTML with an XHTML mimetype and still see something rendered to the screen. Hundreds of thousands of sites do so every day. But to call this XHTML is absurd.

On Fri, Sep 3, 2010 at 23:02, David Menendez wrote:

Yes, using foreign namespaces is one of the things recommended against when serving XHTML as text/html. This says nothing about documents following the recommendations in Appendix C.

...

I'm not debating that it's *possible* to serve HTML with an XHTML mimetype and still see something rendered to the screen. Hundreds of thousands of sites do so every day. But to call this XHTML is absurd.

I agree, if by "absurd" you mean "consistent with the letter and spirit of the XHTML recommendation".

Content served as text/html is not XHTML, any more than content served as text/plain or image/jpg is. *IF* XHTML could be served using "text/html", then my example pages would render identically in browsers with XHTML support. Appendix C is a guideline on how to make the same byte content render *something* when treated as HTML or XHTML; it's intended as a low-fidelity fallback for user agents without support for XHTML (IE). It is *not* a means by which HTML may be labelled XHTML for the sake of buzzword compliance. You seem to be under the common misconception that XHTML is merely an alternative encoding of HTML. This is incorrect. XHTML has a different DOM, different CSS support, and different syntax. HTML and XHTML are like Java and C# -- beneath a superficial resemblance, distinct.

On Sat, Sep 4, 2010 at 12:19 PM, David Menendez wrote:

HTML and XHTML are not encodings of anything. They are markup languages defined using SGML and the XML subset of SGML. There are multiple HTML definitions of varying popularity, and the fact that we can pass some XHTML documents to a web browser expecting HTML and get acceptable results is consistent with the fact that we can pass HTML 3.0 (never implemented by any popular browser) with minimal loss.

But what is the point? The w3c originally suggested serving xhtml as text/html back in 2000 (http://www.w3.org/2000/01/xhtml-pressrelease.html.en), because they believed that it would be an easy way for people to transition to xhtml while the browsers caught up. Well, a decade later, ie still doesn't support xhtml, so perhaps their recommendation should be viewed in light of the fact that the web does not appear to be moving to xhtml at any great speed. Creating output that renders the same as both text/html and application/xml is not a trivial task. For starters, the contents of the <script> tag are treated as pcdata in html, and cdata in xhtml. And it only gets worse from there... So the choices are: 1. only focus on getting the xhtml 1.0 served as application/xml working correctly, and ie users get nothing.. 2. create xhtml 1.0 that would work correctly if served as application/xml, but serve it as text/html, and ignore that fact that some stuff might not be rendering correctly when treated as text/html. 3. create xhtml documents which render correctly whether served as application/xml or text/html, but then only serve them as text/html anyway 4. forget about how the xhtml documents render as application/xml, and only focus on how they render as text/html. Now, I think that options 1 and 2 are not even worth considering. Option 4 seems silly. If you are going to create xhtml that does not really work correctly when actually served as xhtml, then why create xhtml in the first place. This is really just html masquerading as xhtml. Why not actually create valid html and serve it as text/html, instead of creating purposely broken html? Option 3 requires extra work (and also means that you will never be able to upgrade to xhtml 1.1 or xhtml 2.0). The idea of serving xhtml 1.0 as text/html was supposed to be a transitional measure. But if you intend to do it forever.. that is not very transitional. What benefit do you get by creating xhtml 1.0 that also happens to render correctly as html ? What is the use case ? Seems that a vast majority of the usage is going to be viewing the content in web browsers. For that purpose, text/html seems superior, due to it being supported in a much wider variety of browsers. No browser will actually even try to render it as xhtml since it is being served as text/html. It seems that the only advantage of xhtml served as text/html is that it is easier to process the output. But, is anyone actually going to do that? Haddock has been around for a long time.. has anyone had a need to do that so far? And even then, is processing it via an xml parser really better than using tagsoup ? Mark suggested that it was easier to achieve multi-browser compatibility using xhtml instead of html, but I am quite certain he is mistaken. There are really three different rendering modes found in browsers: 1. standards mode 2. quirks mode 3. xhtml mode By serving xhtml content as text/html, he is getting browsers to use quirks mode instead of standards mode. That *can* sometimes lead to better browser compatibility. He is never invoking the xhtml rendering mode. If the aim is simply to trigger quirks mode, there is no need to use xhtml to achieve that. - jeremy

Mark Lentczner schrieb:

The choice to generate Haddock output as XHTML 1.0 Transitional and Frames, stored into files with an extension of .html, and that would likely be served as text/html, was mine and I did so with review of current best practices. The output Haddock now generates renders correctly and consistently in all browses in use by the Haskell community (Firefox, Chrome, Safari, Opera, IE 6, IE 7, and IE 8), the Javascript is handled properly, and with one minor exception[1] it validates as served by the W3C.

I use KDE's Konqueror, which I like much more than Firefox, because it allows me to easily browse between WWW and local files, shows highlighted source code, disk consumption of directories, dia shows etc. In my opinion focusing on a small set of assumed popular browsers and complying to their quirks is the wrong way. It seems to me that browsers become popular because web authors choose to support their quirks and bugs. It would be better if browsers would comply to the standards and web authors do so as well. All these incompatibilities between browsers and common abuse in HTML and XHTML make it a nightmare for me to process web documents as in my online web-site "enhancement" :-) service: http://www.haskell.org.monadtransformer.parallelnetz.de/haskellwiki/Category...

On 6 September 2010 17:11, Mark Lentczner wrote:

On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote:

...

... focusing on a small set of assumed popular browsers ...

I didn't want to assume either. I ran a survey of the Haskell community and got over a 150 responses.

On Sep 6, 2010, at 2:40 AM, Henning Thielemann wrote:

...

and complying to their quirks is the wrong way.

I believe the only sop to browser quirks in the current Haddock output are three lines of CSS that came from YUI 3: CSS Fonts [2] to achieve consistent font sizing in IE. These are well researched and minimal.

Speaking as someone who worked at a company where we had to write 100% valid XHTML and CSS for *non-trival* designs (groans at the recollection), generally for fairly simple documents you can write standard compliant web pages with (X)HTML/CSS/JavaScript and it will render the same on Firefox/Chrome/Safari/Opera/IE8. It will probably work but look less fancy on IE6 if it's simple. If other browsers don't render correctly, that's not your problem. Regarding font sizing, you shouldn't really have to care about the size of the font. If your page renders differently on different browsers due to different font settings, that's because the user/browser chose that font set. Why do you care about consistent font sizes? Personally I'm pragmatic, I don't care about W3C validation, I do care about standards and accessibility. If your page is semantic, usable/accessible across the major browsers then you've done a great job and W3C validation is just a pat on the back. I think it's a matter of priorities. If we're going to appeal to authority, Google see it fit to start using HTML5 straight away (and they really care about validity) and (I was told at the Zurich Google offices by someone who works on YouTube) that we have no business sending XHTML to web browsers. But I don't see the particular mark-up as a Big Deal like others do, when (as I demonstrate below) there are more important issues to deal with that most people don't get right.

As I did the work on Haddock, I tested the results on five browser/os combinations on my own machines, and about 30 browser/os combinations via browsershots[1].

FWIW there's a great web site that provides screenshots of IE immediately: http://ipinfo.info/netrenderer/ Don't waste your time on obscure browsers. You have better things to be doing.

There were a few times where I tried something (usually a choice of markup and CSS) that looked nice in WebKit browsers (Safari and Chrome), but didn't work in Firefox or others. In those cases I retreated to other approaches. A notable example is the "Portability" box in the upper right. I wanted that to be a dl list, and could get it to style nicely in all browsers except Firefox on Linux! I retreated to a table in that case. Since both the thing I tried and the result were valid markup and CSS, I'm hoping you won't consider this a major concession to "quirks".

I'd like to see such cases of inconsistency between Webkit and Firefox ("on Linux"), I can help out if you're having trouble. You want to do the portability box as a definition list? For semantic meaning and search engines, there should be one h1 in the page, many h2's, and subheadings, etc. A really easy way to check your site's quality as a structured document is by rendering it without CSS or JavaScript, because it can make you aware of problems immediately: http://i.imgur.com/7ksCW.png There's no h1, what's the title of this page? The h2s have been written as h1's, and the contents, title and description aren't headings at all. The portability table is done with tds (table *data*) with no th's (table *heading*) and there's no actual description for the table. Headings are useful for navigating the document -- this is how blind people work in a browser, they get a list of headings and tab through it quickly (I have a reference study for this, I'll find it if you're interested). Just think about what are the main points of this document and the way to code it comes naturally. Like I said, you're priority has been cross-platform and validation but basic things like semantic document structure have been overlooked. Anyway, I think you're doing a sterling job and you seem to really care about doing it right, good job! It looks really nice, gives a professional sheen to Haskell's documentation. I know you need to build up a thick skin to deal with all the bikeshed-like criticism that always seems to crop up when web sites are discussed. Don't worry about my criticisms, I'm constructive about it! If you care about this stuff then I'll put my money where my mouth is and send some patches to address whatever I think could be improved, you don't have to lift a finger. If you're not really bothered then disregard all my above comments and just imagine I said "awesome design, good job!"

On Sat, Sep 4, 2010 at 14:46, Jeremy Shaw wrote:

So the choices are:

 1. only focus on getting the xhtml 1.0 served as application/xml working correctly, and ie users get nothing..

 2. create xhtml 1.0 that would work correctly if served as application/xml, but serve it as text/html, and ignore that fact that some stuff might not be rendering correctly when treated as text/html.

 3. create xhtml documents which render correctly whether served as application/xml or text/html, but then only serve them as text/html anyway

 4. forget about how the xhtml documents render as application/xml, and only focus on how they render as text/html.

5. Do as my patch does; default to HTML 4 (supported by all browsers), and allow users to generate correct XHTML if they want/need to.

On 9/2/10 9:57 PM, John Millikin wrote:

Is there any particular reason you're using XHTML instead of HTML? You're using a transitional doctype, invalid IDs, and the .html file extension -- in short, HTML with an incorrect doctype. The markup doesn't even validate.

Because HTML is evil? Though, yes, invalid XHTML is evil too...

In case you're not aware, HTML and XHTML are separate file formats. HTML is a dialect of SGML, whereas XHTML is a dialect of XML.

And XML is just a dialect of SGML if we want to get picky. -- Live well, ~wren