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
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.
>> 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
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.
> 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.
> 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
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
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.
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:
My impression is that it is NOT legal HTML, but I could be wrong about that.
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.
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
> 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
+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
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?
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:
> 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
> 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
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.
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
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.
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.
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.
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.
Let's call a spade a spade. If you aren't closing your tags, your
markup is, literally, retarded.
> 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
>> 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
1) has the plugin been written yet?
2) has anyone installed it yet?
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
> 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
> 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
> 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.
> 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