On May 27, 12:03 pm, Rimantas Liubertas <[email protected]> wrote: > > Rimantas Liubertas wrote: > > [...] > >> Once again > >> using XML brings nothing to the table if you use text/html. > > > Absolutely untrue. If nothing else, it brings the use of XML tools to > > test out your markup. And while people like Hickson don't seem to > > understand the importance of that, the fact is that it makes automated > > testing of your output *much* easier (rspec_hpricot_matchers, anyone?). > > And automated testing is exactly what we should be doing all the time. > > So hpricot cannot parse HTML? Interesting…
Of course it can, but can XPath expressions be practically used on HTML? That's one big reason I use rspec_hpricot_matchers (especially for Facebook projects, since FBML is basically an XML application, but that's another issue). > Any parser which is practical to use should be able to parse HTML and > tag soup, because truly validXHTMLpages are precious rarity. For HTML, I agree. For XHTML, the parser shouldn't even try to fix errors, since that would be improper behavior for an XML parser. > And no, I do not like idea to produce invalid pages just because that > makes testing easier (does it?). The pages are only invalid because browsers use a questionable method of determining whether a page is HTML 4 or XHTML. Although Ian Hickson goes through a lot of bellyaching about the supposed problems of determining whether a page uses an XHTML or HTML DOCTYPE, his objections don't seem to hold up in practice, since only a highly restricted range of DOCTYPEs need to be supported. However, as far as self-closing <tags /> in HTML 4 are concerned, even the W3C seem to be ambivalent enough on this score that they've explicitly proposed (informatively, though) an "HTML compatibility syntax" for XHTML which includes the <tag /> construct, though not <tag/>, I guess in the hope that <tag /> is not likely to be parsed as NET. However, the W3C's validator doesn't even like <tag /> with an HTML 4 DOCTYPE. However again, the DOCTYPE doesn't matter for browser parsing. I need a drink. :P This problem would mostly go away if content negotiation headers were correctly set by most browsers, or if IE would handle XHTML served with the correct MIME type... > > > I don't care about names; I care about quality of reasoning. And while > > I'm sure most (not all) of the facts cited are accurate, the quality of > > reasoning in those articles is extremely low (see the comments to van > > Kesteren's article for some nice hole-poking). I do plan to set up some > > tests of my own. > > Well, set them up and see then. Actually, I found a more recent series of tests at http://www.webdevout.net/articles/beware-of-xhtml which are going a long way toward convincing me to use HTML 4 for most things. Unlike the van Kesteren and Hickson references, that article is recent and does a good job of explaining the issues with concrete examples and clear logic. Hickson also has a nice little Perl script that switches the MIME type if the browser is IE, which could get rid of some objections, but that feels philosophically strange. I might try it anyway. [...] > I admit that I am having trouble seeing how the differences in CSS > > interpretation would be of any practical significance. > > Well, just try my test page then and you will see. Put all the elements > in your CSS in upper case and "no CSS is applied" will become very > significant in practice. As far as I can recall, I have never used uppercase element names in CSS, even with HTML pages. I don't ever plan to do so unless some future standard mandates it. Therefore, this issue will not affect me. > > > If you put inline JavaScript in your HTML, you deserve any problems you > > get. :) It's a stupid thing to do. > > I agree. Now just look around… Again, I don't do this, XHTML or no XHTML, so the problem will not affect me. I don't really care about finding a delivery method for my pages that caters to stupid coding, because I (try to) write my applications so that the output isn't stupid! :) I care about a delivery method that will work for what I actually write -- standards- compliant HTML or XHTML with all JS and CSS in external files. (I don't even like Rails' use of onclick handlers, although I tend to use them anyway for simplicity's sake.) However, now that I know about the DOCTYPE and MIME-type issues involved, I think I'll give the html_output plugin a try and see what happens if I change my DOCTYPE. I use Haml, which can already be set to turn off self-closing easily enough (one line in environment.rb), so that's no problem. I will, however, seriously miss being able to use XPath expressions in my testing code if I go this route (unless they somehow work on HTML, but I doubt it). And unclosed singleton tags are really ugly to me (and always have been, since before I was even aware of XML). > > Regards, > Rimantas > --http://rimantas.com/ Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
