Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0 - HTML vs. XHTML
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:Monad ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0 - HTML vs. XHTML
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. The multiple choice browser question yielded: Firefox: 59% Chrome: 51% Safari: 24% Other: 11% Opera:7% IE 8: 2% IE 7: 1% IE 6: 1% 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]. 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. 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. 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:Monad An excellent service! I hope the new, cleaner markup of Haddock works with less pain. - Mark Mark Lentczner http://www.ozonehouse.com/mark/ IRC: mtnviewmark [1] http://browsershots.org/ [2] http://developer.yahoo.com/yui/3/cssfonts/___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0 - HTML vs. XHTML
On 6 September 2010 17:11, Mark Lentczner ma...@glyphic.com 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! ___ Haskell-Cafe mailing list
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sep 2, 2010, at 11:24 AM, Yuras Shumovich wrote: Is it possible to switch back from frame version to non frame version? The Frames button disappears in frame mode... I usually just right-click on the main page and select Open frame in new window I could have made the Frames button become Unframe... do people think that's worth it? I was worried about clutter, but can add it in easy enough if folks think it makes sense. Also style changing works only inside the main frame. True - the Haddock team suspected that style changing was something people would play with a bit, pick a style they liked and leave it. Once you refresh the page - all the panels will change to the style you picked and continue to stay that way. I thought of adding logic to the Style menu to do this when in frames mode just didn't make the cut before we wanted to ship. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Fri, Sep 3, 2010 at 23:02, David Menendez d...@zednenem.com 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 11:07 AM, John Millikin jmilli...@gmail.com wrote: On Fri, Sep 3, 2010 at 23:02, David Menendez d...@zednenem.com 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. Metadata does not determine data. If I write created: 1810 on the Haskell Report, that does not make it 200 years old. If I seve a JPEG image as text/html, it's still a JPEG image. We just wouldn't expect a browser to render it correctly, because the metadata is wrong. Appendix C describes a subset of XHTML, such that a document in conformance with it may be interpreted usefully as HTML by most web browsers. The document is still XHTML, and may be given to XHTML or generic XML tools without difficulty. You seem to be under the common misconception that XHTML is merely an alternative encoding of HTML. 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. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 12:19 PM, David Menendez d...@zednenem.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 10-09-04 01:31 AM, John Millikin wrote: 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 This relies on xhtml+svg. While it is in the xhtml family, it is not xhtml 1.0 (Section 3.1.2). This is a non-example and non-reason. New haddock pages are xhtml 1.0 (after repairing IDs). 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. You have got the order reversed. serve html with an xhtml mimetype /= serve xhtml with the html mimetype But suppose you made a typo. And bear in mind again we are talking about specifically xhtml 1.0, and furthermore with restrictions. serve xhtml with the html mimetype, call this xhtml is not absurd. The syntax is xhtml. serve xhtml with the html mimetype, call this html is not absurd. A bit of a kludge, yes --- officially blessed kludge, mind you. But not absurd. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
We all seem to understand that there are a complex of issues surrounding the HTML and XHTML dialects, doc types, MIME Types, and file extensions. It is a tangle of intentions and compatibility issues, and one where experts and standards writers admit to practical compromises, which at times are even contradictory. 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. The main aim of the work was achieved: Being able to restyle the output with clear, semantic CSS, and do so in a way that works in all browsers, and all serving environments. If there is a particular issue that is causing the documentation generated to not be usable, please let me know. - Mark [1] John Milliken caught that anchor identifiers for groups didn't validate, though they did work in every browser. The fix is already coded and pushed to the development repo. The sample pages on my site updated. You can check the validation with: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ozonehouse.com%2Fmark%2Fsnap-xhtml%2Fcontainers%2FData-Map.html This fix isn't crucial, and so I've recommended that we not produce a Haddock point release just for this.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 10-09-04 05:46 PM, Jeremy Shaw wrote: 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. No. https://developer.mozilla.org/en/Mozilla%27s_DOCTYPE_sniffing http://reference.sitepoint.com/css/doctypesniffing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Thu, Sep 2, 2010 at 11:14 PM, Mark Lentczner ma...@glyphic.com 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: br / 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
-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? 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] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@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
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 8:47 PM, Brandon S Allbery KF8NH allb...@ece.cmu.edu 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/invalid-xml.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] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sat, Sep 4, 2010 at 14:46, Jeremy Shaw jer...@n-heptane.com 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 10-09-02 09: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. [...] XHTML is supported by most modern browsers (Firefox, Chrome, Safari, Opera, etc), but not by any currently released version of Internet Explorer. Although I dislike transitional personally, it is perfectly legal xhtml 1.0. I see in another message that the author will repair all IDs if I understand correctly. (If not, easy to pressure the author to repair.) File extension is a more complicated story. Which story do you want, the theory story or the practice story? (It is easy to test that enough platforms out there are happy with it. That should end the practice story. So if you bother to claim there is an issue, you likely want the theory story.) 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Fri, Sep 3, 2010 at 12:40 AM, John Millikin jmilli...@gmail.com wrote: Haddock is generating files with an .html extension, which causes webservers to serve it using text/html, the incorrect MIME-type. Secton 5.1 of the XHTML recommendation states: XHTML Documents which follow the guidelines set forth in Appendix C, 'HTML Compatibility Guidelines' may be labeled with the Internet Media Type 'text/html' [RFC2854], as they are compatible with most HTML browsers. http://www.w3.org/TR/xhtml1/#media I haven't checked Haddock's conformance with Appendix C, but it is incorrect to say that XHTML cannot be served as text/html. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Fri, Sep 3, 2010 at 20:39, Albert Y. C. Lai tre...@vex.net 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Sep 2, 2010, at 5:00 AM, David Waern wrote: -- Haddock 2.8.0 A new version of Haddock, the Haskell documentation tool, is out! The biggest news this time is that we have a shiny new XHTML backend, created by Mark Lentczner, ... Included is a new default CSS theme created by Thomas Schilling, Mark and Johan Tibell, as well as the classic theme converted to work with the new backend. 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/ - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
2010/9/2 Mark Lentczner ma...@glyphic.com: 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Thu, 02 Sep 2010 14:00:56 +0200, David Waern david.wa...@gmail.com
wrote:
-- Haddock 2.8.0
A new version of Haddock, the Haskell documentation tool, is out!
It doesn't install on Windows + MinGW:
cabal install --global haddock
Resolving dependencies...
Downloading haddock-2.8.0...
:
:
[ 9 of 33] Compiling Haddock.Utils( src\Haddock\Utils.hs,
dist\build\Haddock\Utils.o )
src\Haddock\Utils.hs:435:8: parse error on input `import'
cabal: Error: some packages failed to install:
haddock-2.8.0 failed during the building phase. The exception was:
ExitFailure 1
This concerns a line with a foreign import:
#ifdef mingw32_HOST_OS
foreign import ccall unsafe _getpid getProcessID :: IO Int -- relies on
Int == Int32 on Windows
#else
getProcessID :: IO Int
getProcessID = fmap fromIntegral System.Posix.Internals.c_getpid
#endif
Adding the line:
{-# LANGUAGE ForeignFunctionInterface #-}
to the top of file src\Haddock\Utils.hs helped.
Regards,
Henk-Jan van Tuyl
--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
--
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
2010/9/2 Henk-Jan van Tuyl hjgt...@chello.nl:
On Thu, 02 Sep 2010 14:00:56 +0200, David Waern david.wa...@gmail.com
wrote:
-- Haddock 2.8.0
A new version of Haddock, the Haskell documentation tool, is out!
It doesn't install on Windows + MinGW:
cabal install --global haddock
Resolving dependencies...
Downloading haddock-2.8.0...
:
:
[ 9 of 33] Compiling Haddock.Utils ( src\Haddock\Utils.hs,
dist\build\Haddock\Utils.o )
src\Haddock\Utils.hs:435:8: parse error on input `import'
cabal: Error: some packages failed to install:
haddock-2.8.0 failed during the building phase. The exception was:
ExitFailure 1
This concerns a line with a foreign import:
#ifdef mingw32_HOST_OS
foreign import ccall unsafe _getpid getProcessID :: IO Int -- relies on
Int == Int32 on Windows
#else
getProcessID :: IO Int
getProcessID = fmap fromIntegral System.Posix.Internals.c_getpid
#endif
Adding the line:
{-# LANGUAGE ForeignFunctionInterface #-}
to the top of file src\Haddock\Utils.hs helped.
Thanks for catching this!
I'll wait a little while in case other issues are reported before I
upload 2.8.1.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
2010/9/2 Daniel Peebles pumpkin...@gmail.com: Mmm, delicious! Thanks to all involved! Any idea how long it'll take for this to make it to hackage and regenerate all the documentation up there? It'd be wonderful to do the same to the GHC documentation too. I don't actually know yet if it's possible to regenerate the documentation on hackage. We're looking into the matter. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On 3 September 2010 11:57, John Millikin jmilli...@gmail.com wrote: Is there any particular reason you're using XHTML instead of HTML? [snip] XHTML is supported by most modern browsers (Firefox, Chrome, Safari, Opera, etc), but not by any currently released version of Internet Explorer. Sounds like a good enough reason to me... :p -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.8.0
On Thu, Sep 2, 2010 at 21:14, Mark Lentczner ma...@glyphic.com wrote: 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]! You're not generating anything browsers will parse as XHTML, so I find it unlikely that attaching the correct doctype will cause problems. I am extremely skeptical that using an HTML4 doctype will render incorrectly when an unrecognized doctype works as expected across all browsers. [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 Browsers treat any data sent using the text/html MIME-type as HTML. Those pages are being served as HTML, so browsers treat them as HTML with an unknown doctype. In particular, CSS and JS behavior on these sites will be that of HTML, *not* XHTML. Firefox will show you how the page is being rendered (HTML or XHTML) in the page info dialog. I don't know of any similar feature in Chrome. [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). IE versions 8 and below (I've not tested IE9) will not render XHTML -- they pop up a save as dialog box. You're welcome to verify this by opening an XHTML page (such as http://ianen.org/haskell/dbus/ ) in IE. You may be confused, because the pages you mentioned earlier *are* rendering in IE. However, they are not being rendered as XHTML -- again, browsers are rendering them as HTML with an unrecognized doctype. Haddock is generating files with an .html extension, which causes webservers to serve it using text/html, the incorrect MIME-type. The correct extension for XHTML content is .xhtml. For some reason, it is common to use XHTML doctypes in HTML documents -- I assume because people think the X makes it more modern. However, this is incorrect behavior. It is better to serve a page correctly as HTML4 than incorrectly as tag soup. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
