Comments on patch #9521 requested
Andrew White
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
> 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
>> 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
> 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
> 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 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.
Gustavo Beathyate
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
> 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
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.
Geoff B
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ć
My impression is that it is NOT legal HTML, but I could be wrong about that.
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
> 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
-Martin
Michael Koziarski
> <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
> 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
> 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
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?
Sandofsky
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
> 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
> 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
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.
Ben Munat
> 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.
>
> 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
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.
DHH
> 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
> 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
> Okay, this idea needs to be shot down right here. HTML 4
> 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
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
> 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
>> 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ć
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
> 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
> 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
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
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
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