Forum: Ruby on Rails a way that helper functions not produce XHTML but HTML?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-25 06:48

I would like to use HTML 4.01 Strict, and used a DOCTYPE of it in my
application template. But look like when a style sheet is included by a
helper function

  <%= stylesheet_link_tag 'style' %>

the code produced is XHTML:

  <link href="/stylesheets/style.css?1243210734" media="screen"
rel="stylesheet" type="text/css" />

is there a way to ask Rails to use HTML instead of XHTML?
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-05-25 11:15
(Received via mailing list)
On May 25, 5:48 am, SpringFlowers AutumnMoon <rails-mailing-
l...@andreas-s.net> wrote:
>
> is there a way to ask Rails to use HTML instead of XHTML?

Nope, while it has been discussed a few times this is not something
rails supports. there might be a plugin for this out there.

Fred
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-25 14:47
SpringFlowers AutumnMoon wrote:
>
>
> I would like to use HTML 4.01 Strict, and used a DOCTYPE of it in my
> application template.
[...]

Why?  XHTML is definitely the way to go these days.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-25 18:59
Marnen Laibow-Koser wrote:
> SpringFlowers AutumnMoon wrote:
>>
>>
>> I would like to use HTML 4.01 Strict, and used a DOCTYPE of it in my
>> application template.
> [...]
>
> Why?  XHTML is definitely the way to go these days.


coz IE doesn't support XHTML.  So while we use XHTML, we are actually
using something that the majority of the client doesn't understand.
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 03:22
SpringFlowers AutumnMoon wrote:
> Marnen Laibow-Koser wrote:
>> SpringFlowers AutumnMoon wrote:
>>>
>>>
>>> I would like to use HTML 4.01 Strict, and used a DOCTYPE of it in my
>>> application template.
>> [...]
>>
>> Why?  XHTML is definitely the way to go these days.
>
>
> coz IE doesn't support XHTML.  So while we use XHTML, we are actually
> using something that the majority of the client doesn't understand.
If I remember correctly, IE *does* support XHTML from version 6, if not
before, so long as you have the proper DOCTYPE declaration.  I would
guess that quirksmpde.org would have more information.

All my webapps and static sites use XHTML, and they work fine in IE as
far as I know.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-26 04:08
Marnen Laibow-Koser wrote:

> If I remember correctly, IE *does* support XHTML from version 6, if not
> before, so long as you have the proper DOCTYPE declaration.  I would
> guess that quirksmpde.org would have more information.

I think on SitePoint and StackOverflow.com, they usually say XHTML is
not supported by IE 6, 7, 8.

http://www.sitepoint.com/forums/showthread.php?t=611664

http://stackoverflow.com/questions/856043/is-it-tr...


http://en.wikipedia.org/wiki/Xhtml#Adoption

Most web browsers have mature support[15] for all of the possible XHTML
media types.[16] The notable exception is Internet Explorer by
Microsoft; [...] Microsoft developer Chris Wilson explained in 2005 that
IE7’s priorities were improved security and CSS support, and that proper
XHTML support would be difficult to graft onto IE’s
compatibility-oriented HTML parser.[19]
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 05:24
SpringFlowers AutumnMoon wrote:
[...]
> I think on SitePoint and StackOverflow.com, they usually say XHTML is
> not supported by IE 6, 7, 8.

The Wikipedia article seems to say that this is not really a problem if
the XHTML is served as text/html, which is what Rails does by default.

Therefore, my advice would be this:
* Use XHTML markup with appropriate DOCTYPE.
* Serve as text/html.
* Test with IE.  Based on my own experience and the Wikipedia article,
it will work in 99 cases out of 100.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-26 06:11
Marnen Laibow-Koser wrote:

> The Wikipedia article seems to say that this is not really a problem if
> the XHTML is served as text/html, which is what Rails does by default.

hm... so the XHTML will just be used as html... and we aim to output it
as XHTML anyway...

pragmatically, it will work...  i just wonder why we don't just output
what is really being accepted by most browsers.
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 06:43
SpringFlowers AutumnMoon wrote:
[...]
> hm... so the XHTML will just be used as html...

Not really; the DOCTYPE still tells the browser that it's XHTML.

 and we aim to output it
> as XHTML anyway...
>
> pragmatically, it will work...  i just wonder why we don't just output
> what is really being accepted by most browsers.

Most browsers have no problem.  IE is the exception, sort of.

Anyway, XHTML is a cleaner standard than HTML -- since it's 100%
well-formed XML, it's easier to parse and more extensible.  There is
absolutely no reason *not* to use XHTML for all your output.  You are
creating a problem out of thin air.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-26 07:05
Marnen Laibow-Koser wrote:
> SpringFlowers AutumnMoon wrote:
> [...]
>> hm... so the XHTML will just be used as html...
>
> Not really; the DOCTYPE still tells the browser that it's XHTML.

except IE use it as HTML.


>  and we aim to output it
>> as XHTML anyway...
>>
>> pragmatically, it will work...  i just wonder why we don't just output
>> what is really being accepted by most browsers.
>
> Most browsers have no problem.  IE is the exception, sort of.

Please note that MOST BROWSERS out there are IE.  about 66%.  So how do
you mean most browser has no problem when 66% of browsers have problem?


> Anyway, XHTML is a cleaner standard than HTML -- since it's 100%
> well-formed XML, it's easier to parse and more extensible.  There is
> absolutely no reason *not* to use XHTML for all your output.  You are
> creating a problem out of thin air.

I hope you won't accuse people of something.  HTML is a standard. XHTML
is a standard.  If some people want to use a particular standard, it is
not so bad as "creating a problem out of thin air".
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 07:27
SpringFlowers AutumnMoon wrote:
> Marnen Laibow-Koser wrote:
>> SpringFlowers AutumnMoon wrote:
>> [...]
>>> hm... so the XHTML will just be used as html...
>>
>> Not really; the DOCTYPE still tells the browser that it's XHTML.
>
> except IE use it as HTML.

Perhaps...but better browsers will understand it for what it is.  In
other words, it degrades gracefully.
[...]
>>
>> Most browsers have no problem.  IE is the exception, sort of.
>
> Please note that MOST BROWSERS out there are IE.  about 66%.  So how do
> you mean most browser has no problem when 66% of browsers have problem?

I was counting distinct programs, not total number of client
installations.

Anyway, it's extremely dangerous to rely on across-the-board statistics
like these.  It's well established that different sites can have
*wildly* different browser usage figures.

Besides, IE's market share is shrinking as more and more people
recognize it for the piece of crap it is.

[...]
>
> I hope you won't accuse people of something.

Huh?

> HTML is a standard. XHTML
> is a standard.  If some people want to use a particular standard, it is
> not so bad as "creating a problem out of thin air".

Yes it is.  HTML is an obsolescent standard, basically simply a matter
of backwards compatibility at this point.  XHTML is the way forward, for
reasons I've already explained.  If you follow the procedure I have
recommended, XHTML does not even cause problems with IE.  That is a
fact.  So why make more work for yourself by not using it?

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-26 07:36
Marnen Laibow-Koser wrote:

> Yes it is.  HTML is an obsolescent standard, basically simply a matter
> of backwards compatibility at this point.  XHTML is the way forward, for
> reasons I've already explained.  If you follow the procedure I have
> recommended, XHTML does not even cause problems with IE.  That is a
> fact.  So why make more work for yourself by not using it?

mainly, i feel weird using something that 66% of browsers don't
understand...  so if I use HTML in some part of my code, and Rails
produce XHTML, then the final result won't be able to validate.
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 11:10
SpringFlowers AutumnMoon wrote:
>
> mainly, i feel weird using something that 66% of browsers don't
> understand...

The idea that it won't be understood is simply false.  Leaving aside the
questionable accuracy of the 66% figure, it is a fact that all browsers
*do* understand XHTML served as I have outlined above -- that is, the
way Rails does it *by default*!

This is why I say you're creating a problem out of thin air: the fact is
that Rails' default settings work for IE with *no problem whatsoever*
and *no extra effort* on your part.

If you don't believe me on this point, try it and see for yourself.

>  so if I use HTML in some part of my code, and Rails
> produce XHTML, then the final result won't be able to validate.

Whether it will validate depends entirely on the DOCTYPE declaration.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-26 11:21
Marnen Laibow-Koser wrote:

> The idea that it won't be understood is simply false.  Leaving aside the
> questionable accuracy of the 66% figure,

http://en.wikipedia.org/wiki/Usage_share_of_web_browsers


> it is a fact that all browsers
> *do* understand XHTML served as I have outlined above -- that is, the
> way Rails does it *by default*!

so if i write

  <div style="clear:both" />

will IE close the div?
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-26 11:30
SpringFlowers AutumnMoon wrote:
> Marnen Laibow-Koser wrote:
>
>> The idea that it won't be understood is simply false.  Leaving aside the
>> questionable accuracy of the 66% figure,
>
> http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

Irrelevant.  As I already explained, *across-the-board statistics are
not useful here*.

>
>
>> it is a fact that all browsers
>> *do* understand XHTML served as I have outlined above -- that is, the
>> way Rails does it *by default*!
>
> so if i write
>
>   <div style="clear:both" />
>
> will IE close the div?

Self-closing container tags are basically the only risky XHTML syntax in
IE, as I understand it.  I suggest you try this and see what you get.
If it turns out to be a problem, use <div></div>, which is valid HTML
and XHTML.  I don't think Rails' helpers produce empty containers in any
case, so you're safe.

Again: *try it*.  If you have problems, then fix them.  But most things
should Just Work, so don't worry until something *actually* goes wrong.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-05-26 21:42
(Received via mailing list)
> Not really; the DOCTYPE still tells the browser that it's XHTML.

DOCTYPEs do not matter in this case. Browsers do switch
rendering modes depending on doctypes, but the only thing
that influences the choice of parser is MIME type [1]

> Most browsers have no problem.  IE is the exception, sort of.

All the browsers, IE or not, will treat XHTML document served as
text/html. And no, IE does not understand XHTML with
MIME type of text/xhtml+xml.
And yes, <element /> means completely different thing in
SGML and hence HTML. If browsers were treating this
correctly you'd see ">" scattered all over the "xhtml" documents.
Sure, no vendor will now risk to fix this.
By the way, Gecko 1.9 in source view shows "/" in red i.e.
as error if page uses xhtml syntax and is served with html
MIME type.

> Anyway, XHTML is a cleaner standard than HTML -- since it's 100%
> well-formed XML, it's easier to parse and more extensible.  There is
> absolutely no reason *not* to use XHTML for all your output.  You are
> creating a problem out of thin air.

Except that all browser will parse your xhtml served as text/html with
their HTML parser, hence none of the above benefits will apply.

Semantically XHTML has no advantages over HTML 4—it is the
same spec reformulated in XML.
Serving with proper MIME type you will once again hit the problem
that IE does not support it. Also there are other issues, and sadly,
majority of XHTML users who chose it because "Zeldman told so"
are not aware about them [2,3,4].

It is very unfortunate, that RoR chose this path. Especially now,
when some may want to use HTML5.

[1] http://annevankesteren.nl/2004/07/mime
[2] http://hixie.ch/advocacy/xhtml
[3]
http://www.456bereastreet.com/archive/200501/the_p...
[4] http://lachy.id.au/log/2005/12/xhtml-beginners

Regards,
Rimantas
--
http://rimantas.com/
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-27 02:11
Rimantas Liubertas wrote:
[snip]

Wow, where to begin?  Your references are very interesting, but as I
read them, it seems to me that their authors have leapt to conclusions
from a farrago of spurious "facts" and unwarranted assumptions.

> It is very unfortunate, that RoR chose this path. Especially now,
> when some may want to use HTML5.

HTML 5 supports at least some of the XML-style syntax, including things
like "<br/>", so I wonder how much of a problem this would be in
practice.

I'll try to write a detailed explanation of why your references *really*
don't impress me, but for now let me just say that while they provide
some interesting information on the issues involved, I do not think that
they have sufficient credibility for their recommendations to be worth
following.

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-05-27 13:34
(Received via mailing list)
> Wow, where to begin?  Your references are very interesting, but as I
> read them, it seems to me that their authors have leapt to conclusions
> from a farrago of spurious "facts" and unwarranted assumptions.

You can begin by reading apropriate specifications and trying things
out. Then you will very well see how "unwarranted" those assumptions
are.

>> It is very unfortunate, that RoR chose this path. Especially now,
>> when some may want to use HTML5.
>
> HTML 5 supports at least some of the XML-style syntax, including things
> like "<br/>", so I wonder how much of a problem this would be in
> practice.

HTML5 supports two different modes of serialization. Once again
using XML brings nothing to the table if you use text/html.

> I'll try to write a detailed explanation of why your references *really*
> don't impress me, but for now let me just say that while they provide
> some interesting information on the issues involved, I do not think that
> they have sufficient credibility for their recommendations to be worth
> following.

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 Johansson (prominent web standards advocate)
are not credible enough, you can always try for yourself and see.
I've done that five years ago: http://rimantas.com/bits/xhtml-test.php

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).
Also it is not difficult to see that in XHTML mode CSS may be
interpreted
differently, 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 with
<!-- //-->
and see if it runs at all).

Regards,
Rimantas
--
http://rimantas.com/
3131fcea0a711e5ad89c8d49cc9253b4?d=identicon&s=25 Julian Leviston (Guest)
on 2009-05-27 14:30
(Received via mailing list)
This is a fairly retarded argument. Rails produces an XHTML
transitional doctype, so it's all irrelevant.

If you want your own doctype, then type it in. It's not hard.

Julian.

----------------------------------------------
Learn: http://sensei.zenunit.com/
Last updated 20-May-09 (Rails, Basic Unix)
Blog: http://random8.zenunit.com/
Twitter: http://twitter.com/random8r
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-05-27 14:49
(Received via mailing list)
> This is a fairly retarded argument. Rails produces an XHTML
> transitional doctype, so it's all irrelevant.

Did you read? Doctypes are relevant only for rendering modes
swithcing (quirks/standards), not for parsing engines (html/xml)
switching.

> If you want your own doctype, then type it in. It's not hard.

Oh thanks, this idea never occured to me.
Now the next part—how do I tell rails to stop polluting  my code with
"/>"?

Regards,
Rimantas
--
http://rimantas.com/
00973881979aa0a660ffbbb2f7a907fb?d=identicon&s=25 Peter De Berdt (Guest)
on 2009-05-27 16:32
(Received via mailing list)
On 27 May 2009, at 14:47, Rimantas Liubertas 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
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-27 17:13
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.

[...]
> 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 Johansson (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 with
> <!-- //-->
> and 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
> --
> http://rimantas.com/

Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-05-27 18:04
(Received via mailing list)
> 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…
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. :)  It's a stupid thing to do.

I agree. Now just look around…

Regards,
Rimantas
--
http://rimantas.com/
Ec5a599777854c540fd102ef4691fe10?d=identicon&s=25 Rimantas Liubertas (Guest)
on 2009-05-27 18:06
(Received via mailing list)
> 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
--
http://rimantas.com/
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-27 19:58
(Received via mailing list)
On May 27, 12:03 pm, Rimantas Liubertas <riman...@gmail.com> 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 <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
marnen@marnen.org
3ff9c2544554b13c6c7877e76684751b?d=identicon&s=25 Lee Smith (smitjel)
on 2009-05-27 22:03
(Received via mailing list)
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.
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-27 22:15
Lee Smith 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.
Bee69cfed999cd13e3bff73d472a39ee?d=identicon&s=25 Hassan Schroeder (Guest)
on 2009-05-27 22:27
(Received via mailing list)
On Wed, May 27, 2009 at 1:15 PM, Jian Lin
<rails-mailing-list@andreas-s.net> 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 Schroeder ------------------------ hassan.schroeder@gmail.com
3ff9c2544554b13c6c7877e76684751b?d=identicon&s=25 Lee Smith (smitjel)
on 2009-05-27 22:35
(Received via mailing list)
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 Schroeder <hassan.schroe...@gmail.com>
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-27 22:41
Lee Smith 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
marnen@marnen.org
Eb71c362ddeda80c2668d2575e97bc70?d=identicon&s=25 winter heat (winterheat)
on 2009-05-27 22:51
hm... you know what, my coworker had this one line:

<div style="clear:both" />

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.
5b0e76c182e8a18abaa732e05a029aa5?d=identicon&s=25 John H. (Guest)
on 2009-05-27 22:58
(Received via mailing list)
> 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.
Dd2d775dea75b381edb1bbf0600a0907?d=identicon&s=25 Marnen Laibow-Koser (marnen)
on 2009-05-28 05:45
Hassan Schroeder 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 Schroeder
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen@marnen.org
This topic is locked and can not be replied to.