Comments on patch #9521 requested

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 (XHTML was good for the web — Anne’s Blog). 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

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.

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.

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.

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 (XHTML was good for the web — Anne’s Blog). 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.

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

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

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

Jay

  1. has the plugin been written yet?

Yes, last year: http://agilewebdevelopment.com/plugins/html_output

  1. has anyone installed it yet?

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

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?

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

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

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.

(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! :slight_smile:

Andrew White