After reading
http://www.hixie.ch/advocacy/xhtml
and having some headaches with IE, I wonder whether helpers can be
configured to generate HTML instead of XHTML.
– fxn
Well, there are plenty of people who disagree with hixie… His whole
notion is based on
the fact that if we serve XHTML with the text/html mime type, that
browsers won’t be able
to take advantage of the fact that it’s xhtml. But how is that any worse
than just using
html (which was obsolete six years ago)?
But regardless “generate HTML instead of XHTML” makes no sense. What is
rails going to do
differently? You can put whatever DTD you want in your layout file. But
you should
certainly periodically run you generated pages (the actual html page)
through the w3c’s
validator (validator.w3.org).
Just make your (x)html clean and valid. If you are having trouble with
IE it is because
browsers interpreted certain aspects of the specs differently. Following
everything hixie
says to the letter is NOT going to make your life any easier. I have
done ALL of my html
development as xhtml (mostly strict, but there’s always transistional if
you need it) and
I’ve never had a problem due to it being served as text/html.
You should install the firebug extension for firefox and watch it’s
error panel as you
browse the web. It’s just stunning how much broken code (html,
javascript, and css) there
is on the web! The web – HTTP and HTML – is just one huge clusterfsck
of a disaster. And
if we insist on blowing off later versions of standards and sticking
with outdated,
deprecated, obsolete versions we will NEVER make anything better.
Basically, what hixie is advocating is similar to saying we shouldn’t be
writing rails
apps because it’s hard to make them work on IIS, or because there’s no
application server
for it, or because there’s no corporation behind it, or whatever.
Ack. This shit just makes me absolutely insane.
b
On Feb 26, 2006, at 2:32, Ben M. wrote:
Well, there are plenty of people who disagree with hixie… His
whole notion is based on the fact that if we serve XHTML with the
text/html mime type, that browsers won’t be able to take advantage
of the fact that it’s xhtml. But how is that any worse than just
using html (which was obsolete six years ago)?
As I understand it, his point is that browsers revert to quirks mode,
which is much worse than HTML 4.01 + CSS. That’s writing beautiful
XHTML + CSS just to revert to HTML 3.something and have all kind of
visual inconsistencies, not very appealing! I am talking from what I
read in books, not that I’ve seen real examples.
In my view, HTML 4.01 + CSS is as good as XHTML as far as clean code
is concerned. You are responsible for that, not the spec.
Additionally, HTML 4.01 is a W3C recommendation as of today, it is
not deprecated or whatever.
Hey, I am not saying that Rails should be able to generate HTML,
I am just asking whether it does. If it doesn’t that’s fine.
But regardless “generate HTML instead of XHTML” makes no sense.
What is rails going to do differently?
Is not going to close empty elements with " />", which prevent the
website from being valid HTML 4.01.
Just make your (x)html clean and valid. If you are having trouble
with IE it is because browsers interpreted certain aspects of the
specs differently. Following everything hixie says to the letter is
NOT going to make your life any easier. I have done ALL of my html
development as xhtml (mostly strict, but there’s always
transistional if you need it) and I’ve never had a problem due to
it being served as text/html.
Yeah, all my website validates already as XHTML strict, but I am
afraid of that quirks mode. It is relatively small and would be a
matter of a couple of hours to convert it to HTML 4.01 if I had a
flag for helpers.
Anyway, I understand that the answer is that there’s no such a
switch. In that case I’ll ponder whether I write my own img_tag and
friends or stick with what I have.
– fxn
On Feb 26, 2006, at 16:37, Chris Johanesen wrote:
The only part of Rails that generates (x)HTML are the tag and form
helpers, no? And really the only ones that would need to not have a
closing /> tag would be img, input, checkbox, correct? I would think
it’d be easy enough to override or create your own image_tag etc
helpers
that support HTML4.
Well, I don’t but that as a justification. It is the same amount of
work for the library author. Given a flag the code generates either
“>” or " />" in the handful of relevant helpers, and makes the
library more complete. You are supporting the current recommendations
that way.
My guess is that either it was simply not written, or maybe it is a
way to encourage people to use XHTML. Well, I could send a patch and
see.
IE.
And then which Content-Type do you use? According to [*] if I send
text/html the browser still uses a HTML parser which understands you
are writing incorrect HTML with tag soup, which is the benefit? IE
does not support application/xhtml+xml, which is what should be used
[**]. Wouldn’t it be easier and cleaner to generate just correct HTML
4.01 + CSS?
– fxn
[*] Activating Browser Modes with Doctype
[**] XHTML Media Types - Second Edition
Xavier,
Someone posted about a plugin to break, er, revert your tags to
non-closed just in the
last few weeks. I know cuz I tangled with him over this issue. Search
the archives for it.
I would say that using such a plugin and never writing an un-closed
tag directly in your
view wouldn’t be too bad since you would hopefully be able to change one
configuration and
switch everything to xhtml later… other than the fact that you’re
producing documents
that you can’t parse with an xml parser. Maybe that’s something you’ll
never want to do,
but why not just make it xml-compliant right off the bat?
Really, it is possible to make perfectly fine xhtml pages that work
across browsers and
serve them as text/html. Just use the xhtml transitional dtd like the
quirksmode guy
suggests and you’ll be fine. If you’re seeing differences between
browsers it is likely a
bug, plain and simple. I defy anyone to show me a page that renders
correctly in all
browsers because it’s html 4.01 (and of course the same page as xhtml
1.0 does not).
On the other hand, there is so much garbage code on the web that – as
with most things
about the human race – I think we are past the point of no return. I
find myself
wondering why I even bother to argue.
b
PS: You know, actually I don’t even like xhtml… we should have all
been serving
straightup xml ages ago.
Well, I don’t but that as a justification. It is the same amount of
work for the library author. Given a flag the code generates either
“>” or " />" in the handful of relevant helpers, and makes the
library more complete. You are supporting the current recommendations
that way.
I wasn’t implying that no one should add that functionality to Rails. I
was merely suggesting an easy way for you to add it to your existing
apps. I’m sure if you submitted a patch people would be receptive. What
goes into rails is what DHH and other contributors need/want. And I
guess no one has needed/wanted html4 support.
And then which Content-Type do you use? According to [*] if I send
text/html the browser still uses a HTML parser which understands you
are writing incorrect HTML with tag soup, which is the benefit? IE
The benefit is that even though the browser may not be seeing your doc
as XML, your doc actually is XML, so in the future you won’t need to
convert anything (like Ben said). It’s really all about foward
compatibility. You could code mal-formed html and it still have it look
fine in all current browsers right now.
Also, if you look at the chart at:
http://www.w3.org/TR/xhtml-media-types/
it says that XHTML1.0 Transitional MAY be served up as text/html and
XHTML1.0 strict SHOULD NOT (not MUST NOT) be served up as text/html. I
say the hell with content-types, all I really care about is that my
pages look good in the major browsers, and that my code is as clean and
versatile and future-proof as I can make it. Thus XHTML.
Anyone know why the rails_info/properties link on the 1.0 welcome
page would be dependent upon irb? I’m playing around with some
different Ubuntu configurations, and if I don’t install irb, the
properties link doesn’t work and I get a debug stack indicating that
the problem is caused by not being able to require irb.
This isn’t a drastic showstopper or anything. I just thought it was
curious behavior. Anyone encountered this before? If you haven’t, do
you feel like doing some detective work? I’ve looked at railties/lib/
rails_info.rb and didn’t see anything suspicious.
David
As I understand it, his point is that browsers revert to quirks mode,
Quirks mode happens under specific conditions, and it’s not hard to keep
IE6 in “almost”-strict mode. Yes, IE6 still has bugs, but there’s no
reason not to use XHTML just to avoid quirks mode.
Read: CSS - Quirks mode and strict mode
Hey, I am not saying that Rails should be able to generate HTML,
I am just asking whether it does. If it doesn’t that’s fine.
Is not going to close empty elements with " />", which prevent the
website from being valid HTML 4.01.
The only part of Rails that generates (x)HTML are the tag and form
helpers, no? And really the only ones that would need to not have a
closing /> tag would be img, input, checkbox, correct? I would think
it’d be easy enough to override or create your own image_tag etc helpers
that support HTML4.
Yeah, all my website validates already as XHTML strict, but I am
afraid of that quirks mode. It is relatively small and would be a
Again, quirks mode doesn’t happen randomly. If you use the right
doctype, avoid the <?xml declaration, and code your CSS to avoid IE bugs
then you shouldn’t have a problem. Certainly there are plenty of people
coding complicated XHTML Strict pages that have little-to-no problems in
IE.