a way that helper functions not produce XHTML but HTML?

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,

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

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.

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,

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,

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,

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

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,

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

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.

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://github.com/jonleighton/html_output/tree/master

Best regards

Peter De Berdt

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. :slight_smile: It's a stupid thing to do.

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

Best,

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. :slight_smile: It's a stupid thing to do.

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

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

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. :slight_smile: 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! :slight_smile: 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,

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.

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.