Rails - May 2009 - a way that helper functions not produce XHTML but HTML?

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?
-- 
Posted via http://www.ruby-forum.com/.

On May 25, 5:48 am, SpringFlowers AutumnMoon <rails-mailing-
l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
> 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?
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
> --
> Posted viahttp://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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.

-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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-true-that-xhtml-is-not-supported-by-ie-but-many-people-still-use-it


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]

-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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.

-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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".


-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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.


-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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?
-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

> 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_perils_of_using_xhtml_properly/
[4] http://lachy.id.au/log/2005/12/xhtml-beginners

Regards,
Rimantas
--
http://rimantas.com/

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

> 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/

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


On 27/05/2009, at 9:33 PM, Rimantas Liubertas wrote:
>
>> 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/
>
> >

> 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/

On 27 May 2009, at 14:47, Rimantas Liubertas wrote:
>> 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 "/>"?
http://github.com/jonleighton/html_output/tree/master


Best regards

Peter De Berdt


--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

> 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/

> 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/

On May 27, 12:03 pm, Rimantas Liubertas
<riman...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org

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 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.
-- 
Posted via http://www.ruby-forum.com/.

> 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.

On Wed, May 27, 2009 at 1:15 PM, Jian Lin
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Wed, May 27, 2009 at 1:15 PM, Jian Lin
>
> <rails-mailing-l...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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.schroe...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

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.
-- 
Posted via http://www.ruby-forum.com/.

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-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.