On 27 May 2009, at 14:47, Rimantas L. wrote:
Now the next part—how do I tell rails to stop polluting my code
with “/>”?
http://github.com/jonleighton/html_output/tree/master
Best regards
Peter De Berdt
Rimantas L. 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.
[…]
Well, even if names of Anne van Kesteren (Opera), Ian Hickson(Google,
author
and maintainer of Acid2 and Acid3 tests, editor of HTML5 spec),
Lachlan Hunt (Opera), Roger J. (prominent web standards advocate)
are not credible enough, you can always try for yourself and see.
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.
I’ve done that five years ago: http://rimantas.com/bits/xhtml-test.php
What’s the point of citing 5-year-old tests? Software – and standards
– can change greatly over periods that long.
It is trivial to test if DOCTYPE affects if page is processed with HTML
or
XHTML parser (it doesn’t) or is it only influenced by MIME type (it is).
I can believe that (although I got it wrong at first). That is not a
fact I am disputing, although I really am not sure why browsers are
written this way.
Also it is not difficult to see that in XHTML mode CSS may be
interpreted
differently,
I admit that I am having trouble seeing how the differences in CSS
interpretation would be of any practical significance.
Javascript is affected (just try to add line if (x<y) in
your
Javascript, do not escape it with CDATA and serve with
application/xhtml+xml.
You will see what I am talking about. Or try to wrap your JS code withand see if it runs at all).
If you put inline JavaScript in your HTML, you deserve any problems you
get. 
It’s a stupid thing to do.
Regards,
Rimantas
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Rimantas L. 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…
Any parser which is practical to use should be able to parse HTML and
tag soup, because truly valid XHTML pages are precious rarity.
And no, I do not like idea to produce invalid pages just because that
makes testing easier (does it?).
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.
I’ve done that five years ago: http://rimantas.com/bits/xhtml-test.php
What’s the point of citing 5-year-old tests? Â Software – and standards
– can change greatly over periods that long.
What? Did XHTML 1.0 standard change? Did HTML 4.01 standard change?
Nope. Yep, software did change. Still IE does not support XHTML, Mozilla
still treats xhtml without namespaces declaration as plain XML, etc.
Nothing did change in this regard. So that test page works just like it
did
five years ago.
<…>
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.
If you put inline JavaScript in your HTML, you deserve any problems you
get.
I agree. Now just look around…
Regards,
Rimantas
http://github.com/jonleighton/html_output/tree/master
Best regards
Peter De Berdt
I will take a look, thanks! If this does work it should be in Rails
proper, with some config
setting…
Regards,
Rimantas
Trying to change the way Rails lays down a stylesheet include is
really a waste of time. This HTML vs XHTML syntax only matters if
you’re validating…otherwise, the browser renders it as HTML.
Don’t waste your time and definitely update your browser.
Lee S. wrote:
Trying to change the way Rails lays down a stylesheet include is
really a waste of time. This HTML vs XHTML syntax only matters if
you’re validating…otherwise, the browser renders it as HTML.Don’t waste your time and definitely update your browser.
i think there are time when i actually want to validate my page
output… especially if the page is complicated with layouts and div’s.
On Wed, May 27, 2009 at 1:15 PM, Jian L.
[email protected] wrote:
i think there are time when i actually want to validate my page
output… especially if the page is complicated with layouts and div’s.
Absolutely – validation is an essential web developer troubleshooting
tool. So make it all valid XHTML and be happy, regardless of whether
you’re ultimately serving it as text/html or application/xhtml+xml
–
Hassan S. ------------------------ [email protected]
On May 27, 12:03 pm, Rimantas L. [email protected] wrote:
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 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 construct, though not
, I guess in the hope that is not likely to be parsed as
NET. However, the W3C’s validator doesn’t even like with an
HTML 4 DOCTYPE. However again, the DOCTYPE doesn’t matter for browser
parsing. I need a drink. 
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
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.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]
Lee S. wrote:
Trying to change the way Rails lays down a stylesheet include is
really a waste of time.
Completely wrong.
This HTML vs XHTML syntax only matters if
you’re validating…
And you should always be validating, because you should always produce
valid markup, because that’s the only way to be sure that the browser
will interpret it correctly.
otherwise, the browser renders it as HTML.
Don’t waste your time and definitely update your browser.
Huh?
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
That’s exactly why I’m saying not to waste your time…Rails lays it
down in XHTML syntax so if he changed the doctype from XHTML specific,
then his validation won’t work. Hence, don’t waste your time changing
it if you’re not worried about validation.
On May 27, 3:27 pm, Hassan S. [email protected]
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).
Almost every ruby based xml parse can parse HTML and use XPath
searches on them. nokogiri, libxml-ruby, and hpricot all support HTML
parsing with xpath searches.
hm… you know what, my coworker had this one line:
and the page would still validate perfectly as XHTML, but IE will render
it differently from FF.
FF will take it as a closing div. IE will not take it as a closing div.
so I will have perfectly validated code that behaves differently on two
popular browsers.
and i can communicate to all my coworkers. but it is hard if the code
is already 2000 files and was written for the past 2 years and many
coworkers were even gone at other companies. i still need to deal with
all the existing code.
Hassan S. wrote:
[…]
So make it all valid XHTML and be happy, regardless of whether
you’re ultimately serving it as text/html or application/xhtml+xml
Not quite. Validate to a DOCTYPE that matches the MIME type that the
browser will use to parse the document – that is, validate to XHTML if
you will serve as application/xhtml+xml, or as HTML if you’ll serve as
text/html. Rails unfortunately generates XHTML and serves as text/html,
which seems to be kind of the worst of both worlds, since it yields
inconsistent results.
–
Hassan S.
Best,
–
Marnen Laibow-Koser
http://www.marnen.org
[email protected]