Comments on patch #9521 requested

53 views
Skip to first unread message

Andrew White

unread,
Sep 10, 2007, 11:05:50 AM9/10/07
to rubyonra...@googlegroups.com
I thought I'd bring up what may be another contentious patch here.

Patch #9521 adds a config attribute to ActionView::Base to control
the tag helper method's generation of empty tags. I personally prefer
to generate HTML4 pages served as text/html in line with the flowing
comments:

http://webkit.org/blog/?p=68
http://www.hixie.ch/advocacy/xhtml

I know that the above comments have been rebutted by various people,
but since some people are in one camp or the other I think it makes
sense provide the option with the default setting being current
behaviour of course.


Andrew White

DHH

unread,
Sep 10, 2007, 5:32:37 PM9/10/07
to Ruby on Rails: Core
> Patch #9521 adds a config attribute to ActionView::Base to control
> the tag helper method's generation of empty tags. I personally prefer
> to generate HTML4 pages served as text/html in line with the flowing
> comments:

I'm -1 on that change. Rails should strive to produce XML valid
content so we can use XML tools to operate on the content.

But this looks like a simple thing to wrap up in a plugin.

Andrew White

unread,
Sep 11, 2007, 12:20:30 PM9/11/07
to rubyonra...@googlegroups.com
On 10 Sep 2007, at 22:32, DHH wrote:

>> Patch #9521 adds a config attribute to ActionView::Base to control
>> the tag helper method's generation of empty tags. I personally prefer
>> to generate HTML4 pages served as text/html in line with the flowing
>> comments:
>
> I'm -1 on that change. Rails should strive to produce XML valid
> content so we can use XML tools to operate on the content.

I'd agree if the only thing Rails outputted was XML. Anyway, if
that's the case shouldn't the default content-type be a proper XML
content type such as application/xhtml+xml?

Want me to close it then?


Andrew White

DHH

unread,
Sep 11, 2007, 1:43:43 PM9/11/07
to Ruby on Rails: Core
> I'd agree if the only thing Rails outputted was XML. Anyway, if
> that's the case shouldn't the default content-type be a proper XML
> content type such as application/xhtml+xml?

It perhaps should be, if it wasn't because browser bugs caused a world
of hurt around that.

> Want me to close it then?

I'd be happy to entertain more debate if anyone else have an opinion
on it, but I'm -1 for now.

Gabe da Silveira

unread,
Sep 11, 2007, 2:05:00 PM9/11/07
to rubyonra...@googlegroups.com
On 9/11/07, DHH <david.he...@gmail.com> wrote:

> I'd agree if the only thing Rails outputted was XML. Anyway, if
> that's the case shouldn't the default content-type be a proper XML
> content type such as application/xhtml+xml?

It perhaps should be, if it wasn't because browser bugs caused a world
of hurt around that.

Although XHTML tends to be the knee-jerk doctype, the fact that it can't be sent correctly is a concern for many developers who care about standards.  HTML is no less a standard than XHTML, and HTML 4 is equivalent of XHTML 1, so no features are missing.

True XHTML is a little more consistent to parse, but HTML is important enough that there are plenty of tools that respect its empty elements.

> Want me to close it then?

I'd be happy to entertain more debate if anyone else have an opinion
on it, but I'm -1 for now.

I don't see any reason that Rails should be limited to XHTML output.  Aside from the slightly pedantic content-type reasoning, HTML 4 is still a viable standard and XHTML is not guaranteed to be the future in any way (see HTML 5).  I know we don't like extraneous config options here, but I think this is a pretty important one to some people.  I guess a plugin would be okay, but this seems to be more of a core type of option--what flavor of HTML to emit.  

I haven't looked at the patch, but I'm +1 on the concept if the implementation looks okay.

--
Gabe da Silveira
http://darwinweb.net

Gustavo Beathyate

unread,
Sep 11, 2007, 2:31:22 PM9/11/07
to rubyonra...@googlegroups.com

On Sep 11, 2007, at 1:05 PM, Gabe da Silveira wrote:

> I haven't looked at the patch, but I'm +1 on the concept if the
> implementation looks okay.

Me too, knowing how many browser makers are supporting this, I'd like
HTML support.

Gustavo


Matthew Palmer

unread,
Sep 11, 2007, 4:24:20 PM9/11/07
to rubyonra...@googlegroups.com
On Tue, Sep 11, 2007 at 12:05:00PM -0600, Gabe da Silveira wrote:
> On 9/11/07, DHH <david.he...@gmail.com> wrote:
> > > I'd agree if the only thing Rails outputted was XML. Anyway, if
> > > that's the case shouldn't the default content-type be a proper XML
> > > content type such as application/xhtml+xml?
> >
> > It perhaps should be, if it wasn't because browser bugs caused a world
> > of hurt around that.
>
> Although XHTML tends to be the knee-jerk doctype, the fact that it can't be
> sent correctly is a concern for many developers who care about standards.
> HTML is no less a standard than XHTML, and HTML 4 is equivalent of XHTML 1,
> so no features are missing.
>
> True XHTML is a little more consistent to parse, but HTML is important
> enough that there are plenty of tools that respect its empty elements.

Is the trailing-slash-to-auto-close output that we (are/were) discussing
invalid HTML 4? I know it's something you don't often see anywhere except
in XML, but is it *actually* illegal in HTML? It seems to me that, if the
slash is legal but just odd, we could leave the slash in an get XHTML *and*
HTML compatibility in one hit.

- Matt

Gabe da Silveira

unread,
Sep 11, 2007, 5:49:09 PM9/11/07
to rubyonra...@googlegroups.com


On 9/11/07, Matthew Palmer <mpa...@hezmatt.org> wrote:

Is the trailing-slash-to-auto-close output that we (are/were) discussing
invalid HTML 4?  I know it's something you don't often see anywhere except
in XML, but is it *actually* illegal in HTML?  It seems to me that, if the
slash is legal but just odd, we could leave the slash in an get XHTML *and*
HTML compatibility in one hit.

My impression is that it is NOT legal HTML, but I could be wrong about that.

Geoff B

unread,
Sep 11, 2007, 6:16:19 PM9/11/07
to Ruby on Rails: Core
According to the W3C Validator -- http://validator.w3.org/ -- self-
closing tags don't pass validation when the doctype is HTML 4.01
Strict, but they do pass when the doctype is HTML 4.01 Transitional.

The validator links to this article -- http://www.cs.tut.fi/~jkorpela/html/empty.html
-- which gives the following advice:

"If you start using XHTML features like <hr />, don't expect your
documents to validate against an HTML DOCTYPE. They need to be
converted to comply with XHTML requirements as a whole, including the
use of an XHTML DOCTYPE."


On Sep 11, 4:49 pm, "Gabe da Silveira" <gabrie...@gmail.com> wrote:

Mislav Marohnić

unread,
Sep 11, 2007, 6:18:18 PM9/11/07
to rubyonra...@googlegroups.com
On 9/11/07, Gabe da Silveira <gabr...@gmail.com> wrote:

My impression is that it is NOT legal HTML, but I could be wrong about that.

It's not. The HTML4 spec doesn't say anything about the slash. It only defines that some elements can not have closing tags. The slash, however, is required in XHTML. XHTML compatibility (with HTML) guidelines advise that you should include the slash, but with a space in front, like "<BR />", so that HTML-conforming user agents could correctly parse the document as HTML.

This all means that the trailing slash is not a part of HTML4 specification, but is so widely understood by user agents that it can be used in HTML anytime. Why is it understood, I can't say. User agents were probably made to be future-compatible to some extent.

Geoff B

unread,
Sep 11, 2007, 6:46:25 PM9/11/07
to Ruby on Rails: Core
> This all means that the trailing slash is not a part of HTML4 specification,
> but is so widely understood by user agents that it can be used in HTML
> anytime. Why is it understood, I can't say. User agents were probably made
> to be future-compatible to some extent.

The article I linked to above gives the answer -- the slash actually
has a meaning in HTML that's different than the meaning in XHTML, but
browsers didn't bother to implement this behavior.

If browsers had implemented HTML in complete compliance with the spec,
<hr/ and <hr> would be equivalent, and therefore <hr/> would be
equivalent to <hr>>. This is why pages will render fine, but fail
strict validation.

Martin Emde

unread,
Sep 11, 2007, 10:49:09 PM9/11/07
to rubyonra...@googlegroups.com
+1 on this patch. Presuming that developers will use a not-fully-supported doc type or else have invalid markup is not the way rails should behave. Besides, this is one of the least invasive patches I've ever seen. 80% of the people using rails will never notice it unless it's pointed out to them (but that 20% will get their valid markup if they so choose)

-Martin

Michael Koziarski

unread,
Sep 11, 2007, 10:58:53 PM9/11/07
to rubyonra...@googlegroups.com
> If browsers had implemented HTML in complete compliance with the spec,
> <hr/ and <hr> would be equivalent, and therefore <hr/> would be
> equivalent to <hr>>. This is why pages will render fine, but fail
> strict validation.

If browsers had been in strict html compliance then we'd be in an
entirely different world. Thankfully we're not.

As it stands this patch makes literally *no* difference to users of a
rails site, and could be trivially overwritten by a plugin for the
developers who worry about such things. Does it really need to be
another option added to the framework?

--
Cheers

Koz

Jay Levitt

unread,
Sep 11, 2007, 11:56:28 PM9/11/07
to rubyonra...@googlegroups.com
On Wed, 12 Sep 2007 14:58:53 +1200, Michael Koziarski wrote:

> As it stands this patch makes literally *no* difference to users of a
> rails site, and could be trivially overwritten by a plugin for the
> developers who worry about such things. Does it really need to be
> another option added to the framework?

Should it really take a plugin to make Rails generate valid HTML, however
pedantic that validation may seem? That just seems silly and adds to the
Rails-is-a-toy FUD.

Jay Levitt

Steven A Bristol

unread,
Sep 12, 2007, 12:18:47 AM9/12/07
to rubyonra...@googlegroups.com
On 9/11/07, Martin Emde <marti...@gmail.com> wrote:
> Presuming that developers will use a not-fully-supported
> doc type or else have invalid markup is not the way rails should behave.


+1

--
Thank you,
Steven A Bristol
st...@lesseverything.com
Home page: http://lesseverything.com
Blog: http://b.lesseverything.com
What you need: http://lessaccounting.com

Gabe da Silveira

unread,
Sep 12, 2007, 12:31:26 AM9/12/07
to rubyonra...@googlegroups.com
On 9/11/07, Michael Koziarski <mic...@koziarski.com> wrote:

As it stands this patch makes literally *no* difference to users of a
rails site,  and could be trivially overwritten by a plugin for the
developers who worry about such things.  Does it really need to be
another option added to the framework?

I really respect the opinionated nature of Rails and reluctance to add options willy-nilly.  However markup output is an extremely fundamental aspect of any web framework.  For those using XHTML it may seem like an esoteric feature, but that is just a snapshot in time.  I'll go back to my original point which is that XHTML is not guaranteed to be the future of HTML.  XHTML 1.1 is seeing very slow implementation, and XHTML 2.0 is widely derided as being too complicated.  Meanwhile work continues on HTML 5.  

I don't think it's wise to put all Rails' eggs in the XHTML basket when the alternative is just a simple and unobtrusive configuration option.

Sandofsky

unread,
Sep 12, 2007, 3:35:43 AM9/12/07
to Ruby on Rails: Core
First, more options means more you have to document and more a novice
has to learn.

Second, by presenting an extra configuration option, you discourage
people from enhancing that feature, because now they're pressured to
write two versions.

Third, by giving users the option of creating html4 documents, you are
lending validity to the idea that html4 is fine. I believe few people
share that feeling.

-1

On Sep 11, 9:31 pm, "Gabe da Silveira" <gabrie...@gmail.com> wrote:

Andrew White

unread,
Sep 12, 2007, 5:13:56 AM9/12/07
to rubyonra...@googlegroups.com
On 12 Sep 2007, at 08:35, Sandofsky wrote:

> First, more options means more you have to document and more a novice
> has to learn.

How would it be easier for a novice to learn that they have to create
a plugin and monkey patch the tag helper method if they need to
produce valid HTML to pass WCAG 1.0 without producing warnings.

> Second, by presenting an extra configuration option, you discourage
> people from enhancing that feature, because now they're pressured to
> write two versions.

Have you looked at the patch? All it does is control the default for
the last parameter to the tag helper method - I'd hardly call it a
feature! I also doubt it'd require writing two versions of anything.

> Third, by giving users the option of creating html4 documents, you are
> lending validity to the idea that html4 is fine. I believe few people
> share that feeling.

HTML4 is perfectly fine - I don't recall the W3C revoking it at any
point. I'm assuming that you serve your pages as text/html in which
case all you are doing is producing invalid HTML as that's how the
browser will treat it.[1]


Andrew White

[1] http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html

Jay Levitt

unread,
Sep 12, 2007, 9:08:22 AM9/12/07
to rubyonra...@googlegroups.com
On Wed, 12 Sep 2007 07:35:43 -0000, Sandofsky wrote:

> Third, by giving users the option of creating html4 documents, you are
> lending validity to the idea that html4 is fine. I believe few people
> share that feeling.

Have you been keeping up with the goings-on this summer, or at least read
the OP's links? At the moment, at least, the XHTML track is (a) highly
problematic in the present and (b) not getting a lot of love in the future.

Jay Levitt

Gabe da Silveira

unread,
Sep 12, 2007, 9:34:59 AM9/12/07
to rubyonra...@googlegroups.com
On 9/12/07, Sandofsky <sand...@gmail.com> wrote:

Third, by giving users the option of creating html4 documents, you are
lending validity to the idea that html4 is fine. I believe few people
share that feeling.

Okay, this idea needs to be shot down right here.  HTML 4 is fine--standards uber-geek Anne Van Kesteren switched back to HTML from XHTML two years ago (http://annevankesteren.nl/2005/05/xhtml).  XHTML in practice is just a reformulation of HTML (unless you are using XHTML 1.1 which few are) and offers nothing above and beyond HTML except for stricter parsing.  Sure the majority of standards-based designers are using XHTML, but that is mostly an example of cargo-cult programming.  You will even hear some people say XHTML is more semantic or some similar rubbish, but it is not.  Make no mistake, XHTML is not innately superior to HTML, and there's no reason to believe XHTML 2 will beat HTML 5 as the defacto standard.

Ben Munat

unread,
Sep 12, 2007, 2:51:34 PM9/12/07
to rubyonra...@googlegroups.com
Gabe da Silveira wrote:
> Third, by giving users the option of creating html4 documents, you are
> lending validity to the idea that html4 is fine. I believe few people
> share that feeling.
>
> Okay, this idea needs to be shot down right here. HTML 4 /is/
> fine--standards uber-geek Anne Van Kesteren switched back to HTML from
> XHTML two years ago (http://annevankesteren.nl/2005/05/xhtml). XHTML in
> practice is just a reformulation of HTML (unless you are using XHTML 1.1
> which few are) and offers nothing above and beyond HTML except for
> stricter parsing. Sure the majority of standards-based designers are
> using XHTML, but that is mostly an example of cargo-cult programming.
> You will even hear some people say XHTML is more semantic or some
> similar rubbish, but it is not. Make no mistake, XHTML is not innately
> superior to HTML, and there's no reason to believe XHTML 2 will beat
> HTML 5 as the defacto standard.
>

There is plenty of strong opposition to HTML5 as well. I predict that no new
html/xhtml specs will be adopted/recommended/supported for a long time to come.

Also, for the record, it *was* the intention of the w3c -- the primary standards
body of the world wide web (and made up of representatives from lots of
companies... not just theoreticians in glass towers) -- that HTML 4.1 be the
*last* HTML spec and that HTML be phased out completely. We were supposed to
transition to xhtml. It wasn't supposed to be too hard. But microsoft killed all
that. Now we'll all just argue about it until we retire. Oh what a wonderful world.

Ben

Gabe da Silveira

unread,
Sep 12, 2007, 3:03:07 PM9/12/07
to rubyonra...@googlegroups.com
On 9/12/07, Ben Munat <bmu...@gmail.com> wrote:

There is plenty of strong opposition to HTML5 as well. I predict that no new
html/xhtml specs will be adopted/recommended/supported for a long time to come.

Also, for the record, it *was* the intention of the w3c -- the primary standards
body of the world wide web (and made up of representatives from lots of
companies... not just theoreticians in glass towers) -- that HTML 4.1 be the
*last* HTML spec and that HTML be phased out completely. We were supposed to
transition to xhtml. It wasn't supposed to be too hard. But microsoft killed all
that. Now we'll all just argue about it until we retire. Oh what a wonderful world.

Well let me just hedge by saying that if core's opinion falls squarely on the XHTML side of the fence then so be it.  Having to install a plugin is not going to kill anybody.  The main thing I wanted to communicate is that XHTML is not a foregone conclusion, and HTML is a legitimate markup choice regardless of the W3C's intended roadmap.

DHH

unread,
Sep 12, 2007, 5:11:03 PM9/12/07
to Ruby on Rails: Core
> XHTML in practice is just a reformulation of HTML (unless you are using XHTML
> 1.1 which few are) and offers nothing above and beyond HTML except for stricter
> parsing.

I think that's a noble goal in itself. HTML as XML means that XML
tools work on HTML.

Anyway, I continue to be unswayed by this option, so I remain -1 and
say go-go plugin.

Sandofsky

unread,
Sep 12, 2007, 5:49:29 PM9/12/07
to Ruby on Rails: Core
> How would it be easier for a novice to learn that they have to create
> a plugin and monkey patch the tag helper method if they need to
> produce valid HTML to pass WCAG 1.0 without producing warnings.
>

It isn't important enough to most users that they'll be forced to do
that.

> > Second, by presenting an extra configuration option, you discourage
> > people from enhancing that feature, because now they're pressured to
> > write two versions.
>
> Have you looked at the patch? All it does is control the default for
> the last parameter to the tag helper method - I'd hardly call it a
> feature! I also doubt it'd require writing two versions of anything.
>

It's a small feature, but it is a feature.

More functionality means more to maintain, more tests to break, and
more considerations when writing a plugin.

> > Third, by giving users the option of creating html4 documents, you are
> > lending validity to the idea that html4 is fine. I believe few people
> > share that feeling.
>
> HTML4 is perfectly fine - I don't recall the W3C revoking it at any
> point. I'm assuming that you serve your pages as text/html in which
> case all you are doing is producing invalid HTML as that's how the
> browser will treat it.[1]
>

HTML4 is fine. But it isn't fine enough that it deserves the support
of Rails.

Sandofsky

unread,
Sep 12, 2007, 6:29:02 PM9/12/07
to Ruby on Rails: Core

> Okay, this idea needs to be shot down right here. HTML 4
> *is*fine--standards uber-geek Anne Van Kesteren switched back to HTML

> from XHTML
> two years ago (http://annevankesteren.nl/2005/05/xhtml). XHTML in practice
> is just a reformulation of HTML (unless you are using XHTML 1.1 which few
> are) and offers nothing above and beyond HTML except for stricter parsing.
> Sure the majority of standards-based designers are using XHTML, but that is
> mostly an example of cargo-cult programming. You will even hear some people
> say XHTML is more semantic or some similar rubbish, but it is not. Make no
> mistake, XHTML is not innately superior to HTML, and there's no reason to
> believe XHTML 2 will beat HTML 5 as the defacto standard.

Let's call a spade a spade. If you aren't closing your tags, your
markup is, literally, retarded. Closing all tags is more consistant in
both processing and aesthetics. This has an immediate impact on my
productivity.

I don't care if the browser is really treating my xhtml as invalid
html4. That has had zero impact on my work. Blindly following
standards is being "enterprise" but bowing to a different master.

Jack Danger Canty

unread,
Sep 12, 2007, 6:34:59 PM9/12/07
to rubyonra...@googlegroups.com
Let's call a spade a spade. If you aren't closing your tags, your
markup is, literally, retarded.

We're traveling some very well-worn territory here.  It can go on like this for a good long time.
Personally, I'm curious to see a concrete example that this is useful.  Specifically: 1) has the plugin been written yet? and 2) has anyone installed it yet?

::Jack Danger
http://6brand.com

Andrew White

unread,
Sep 12, 2007, 6:36:58 PM9/12/07
to rubyonra...@googlegroups.com
On 12 Sep 2007, at 22:49, Sandofsky wrote:

> It isn't important enough to most users that they'll be forced to do
> that.

By the same token they wouldn't be forced to learn a new config
setting either, so this consideration is irrelevant in this case.

> More functionality means more to maintain, more tests to break, and
> more considerations when writing a plugin.

In that case should I submit a patch to move RESTful routing into a
plugin - after all that's complex area for newbies and there's load
of stuff to maintain (only joking). The point I'm trying to make is
that deciding on whether to add a feature should be balance between
maintainability and usefulness - I personally think the usefulness
exceeds the likely maintenance overhead.

> HTML4 is fine. But it isn't fine enough that it deserves the support
> of Rails.

To me that would make Rails dogmatic rather than just opinionated
software. If I can generate images with Rails why would should it
only allow me to product invalid HTML (as that's what XHTML served as
text/html is).


Andrew White

Jay Levitt

unread,
Sep 12, 2007, 6:41:50 PM9/12/07
to rubyonra...@googlegroups.com
On Wed, 12 Sep 2007 23:36:58 +0100, Andrew White wrote:

>> HTML4 is fine. But it isn't fine enough that it deserves the support
>> of Rails.
>
> To me that would make Rails dogmatic rather than just opinionated
> software.

No, /that/ isn't what makes Rails dogmatic...

Jay

Mislav Marohnić

unread,
Sep 12, 2007, 6:45:05 PM9/12/07
to rubyonra...@googlegroups.com
On 9/13/07, Jack Danger Canty <danger...@gmail.com> wrote:

1) has the plugin been written yet?

2) has anyone installed it yet?

Dunno. I know I didn't, I use XHTML and content-type negotiation.

Michael Koziarski

unread,
Sep 12, 2007, 8:15:13 PM9/12/07
to rubyonra...@googlegroups.com
> HTML4 is fine. But it isn't fine enough that it deserves the support
> of Rails.

To put my cards on the table, HTML *is* fine, XHTML has failed to
deliver on its promise and likely never will.

My objection is different to david's, I just don't see that the
option is justified. The html_output plugin is available to people
who feel the need to validate against a strict sgml DTD, for people
who don't validate, this makes literally no difference.

Browsers understand <br /> just fine, I'm suggesting we be pragmatic.
What's the real problem we're trying to solve? What's the impact of
not solving it? What's the problem with installing a plugin which
does this?


--
Cheers

Koz

Andrew White

unread,
Sep 13, 2007, 5:59:21 AM9/13/07
to rubyonra...@googlegroups.com
On 13 Sep 2007, at 01:15, Michael Koziarski wrote:

> Browsers understand <br /> just fine, I'm suggesting we be pragmatic.

Actually browsers don't understand <br /> - it's their lax error
handling that makes it work. Most XHTML pages would actually fail if
run through an XML parser as they are ill-formed. Take Basecamp's
homepage page for example - there's a meta tag without the /> at the
end which makes it ill-formed. It's the fact that they're served as
text/html that makes them work.

> What's the real problem we're trying to solve? What's the impact
> of not solving it?

Well in my case I'm trying produce valid HTML4 that will pass WCAG
without warnings to appease my local government / lottery funded
clients who require accessible websites.

> What's the problem with installing a plugin which does this?

I have no problem, but I personally feel that Rails should be able to
generate valid markup out of the box. Anyway I've closed the ticket
with a link to the available plugin.


Andrew White

Julian Tarkhanov

unread,
Sep 18, 2007, 12:55:51 AM9/18/07
to rubyonra...@googlegroups.com

On 11-sep-2007, at 20:05, Gabe da Silveira wrote:

> I haven't looked at the patch, but I'm +1 on the concept if the
> implementation looks okay.

-2, if only because it should be second nature for anyone in 2007 to
do the space-bar-forward-slash-more-than.
And yes, I am using XHTML Transitional exclusively for the last five
years, if not because it has stricter and more
meaningful rules (that make you close tags), and because such
behaviour makes things both more readable
(like the end statement in Ruby) and easier for the parsers.

I would consider this a huge step backwards for Rails because XHTML
is a step forward in the style domain, if you know what
I mean by ever trying to analyze (valid) HTML with _indentation only_.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl


Julian Tarkhanov

unread,
Sep 18, 2007, 12:58:43 AM9/18/07
to rubyonra...@googlegroups.com

On 12-sep-2007, at 15:34, Gabe da Silveira wrote:

> Make no mistake, XHTML is not innately superior to HTML, and
> there's no reason to believe XHTML 2 will beat HTML 5 as the
> defacto standard.

To me it's not the difference of Anne's opininos or Ian's opinions
and not a difference of mime types. I consider traditional HTML Ruby
in Perl-style. I thouhgt this is something
we would love to leave in the past.

Andrew White

unread,
Sep 18, 2007, 1:54:10 AM9/18/07
to rubyonra...@googlegroups.com

On 18 Sep 2007, at 05:55, Julian Tarkhanov wrote:

> And yes, I am using XHTML Transitional exclusively for the last five
> years, if not because it has stricter and more
> meaningful rules (that make you close tags), and because such
> behaviour makes things both more readable
> (like the end statement in Ruby) and easier for the parsers.

(sighs...)

Apart from the fact that I've closed the ticket, producing XHTML and
serving it as text/html makes no difference for the parser in the
various web browsers as it's all treated as HTML. It may make it
easier for your validator of choice to parse it but judging by the
fact that the majority of pages with XHTML doctypes aren't even well-
formed that doesn't seem to have had a major impact.

I'd also question the any improvement in readability gained from
added slashes to empty tags but I guess that's a matter of personal
preference.

Anyway consider the matter closed! :-)


Andrew White

Reply all
Reply to author
Forward
0 new messages