On 6 September 2010 17:11, Mark Lentczner
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!"