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:
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.
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.
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?
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’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.
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.
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.
"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."
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 “ ”, 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.
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.
+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)
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?
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.
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.
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.
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]
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.
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.
