Ruby on Rails default templates now comes with HTML5 doctype | Hacker News Reader

Ruby on Rails default templates now comes with HTML5 doctype

github.com

51 pointslaktek20 comments

this is not at all related to the essence of the commit, but as the rails guys are using git which brings us the beauty that is rebase -i, why is this commit so incredibly bad?

It mixes functional changes and whitespace changes. It even contains functional changes not related to the commit message.

I would never dare to submit a commit like this into our internal repository, much less to a public one.

I know. Just nitpicking, but having the possibility of creating "clean" commits in a reasonable amount of time is one of the nice features of git. Why not use them?

"I would never dare to submit a commit like this into our internal repository, much less to a public one."

Never? Are your deadlines infinitely flexible? I try my best to adhere to single purpose commits too, but being under the gun I know I've slipped on a few (hundred) occasions. And no, I don't go back and split commits.

And no, I don't go back and split commits.

After all, that will make it all the more fun the next time you are under a deadline, and you are wondering why that commit broke something. You have the added benefit of having to imagine what you were thinking a few months ago, in addition to debugging. Fun!

In other news, writing tests is a waste of time when you are under a deadline. It mostly works in the browser!

Ease up on the sarcasm. I get it, you write perfectly descriptive commit messages and your apps are perfectly tested. I was cutting the original committer some slack because he was guilty of something that most of us are guilty of.

was I still using SVN, I would totally agree with you here, but git was designed to help with issues as the ones that are in the patch:

Git diff is awfully useful in displaying things like inconsistent newlines, inconsistent whitespace and it helps you keeping whitespace and code changes separate.

And then there's "git add -i" which makes it very easy to go through a file change by change and commit parts of the changes. This feels dangerous, but to keep whitespace changes separate from functional changes, it's very powerful and not dangerous at all.

Fixing a commit like this takes maybe 20 seconds more than just committing it and considering the amount of time you save when you try to fix the bug in that commit (of course there is one), it's totally worth the hassle.

Note that this relies on git features. If you don't have git, I totally agree with your point. But my comment was about a commit made with git.

To make a point: Have a look at the last change in the commit. How are these <th> tags related to the HTML5 conversion?

Now when they go back to the changes in a few weeks, wouldn't they be glad to see these changes in its own commit with its own message?

It looks more like his text editor was configured to auto-remove unused whitespaces.

I do this too, although it's not a bad idea (from a history-preserving standpoint) to filter-branch and kill that off from time to time.

(Cue the "omg, it can break stuff!" comments in 3... 2... 1...)

Rails 3 is supposedly going to add helpers for adding HTML5 data attributes ( http://ejohn.org/blog/html-5-data-attributes ) at some point, too.

Ok what's the downside to using the new doctag? What about old IE6 users? I have a new site going online tomorrow and would be willing to go HTML5 as long as it won't kill older browsers.

You mean a doctype. IE6 users won't be affected if you declare the HTML5 elements in JS, as described here: http://html5doctor.com/how-to-get-html5-working-in-ie-and-fi...

Also, tag helpers for audio and video HTML5 tags have been pushed to edge rails - http://bit.ly/PGV5B

So doctype change must've been made mainly to support these tags.

Apparently this isn't a typo, HTML 5 really has no DTD. Hasn't the industry already wasted enough developer-years trying to parse tag soup? Are we really going to make this disastrous blunder again?

What blunder are you talking about? HTML4.01 has DTD, XHTML1.0 has DTD, did it help in any way? Tag soup is already there and will stay for a long time. From all the specs so far HTML5 has the best description how to deal with it.

Yes, I do think they helped. Before HTML 2, validation didn't exist, so whether or not a document's markup made any sense was merely an opinion. "Best viewed with" was the order of the day because there was no way to know whether a browser would handle a document reasonably other than testing them together.

The web mostly interoperates now, but if we eliminate validation with HTML 5 I fully expect a return to the trainwreck we faced in 1995.

First, not having DTD is not the same as not being able to validate: there is a validator for HTML5, validator.nu. You can also use XML serialization of HTML5 and XML tools to make sure your document is valid XML.

Second, having means to validate markup does not mean that authors will care and do that: what portion of document having doctype with dtd slapped on top are actually valid? Good markup is not produced by tools, but by those who care.

Thanks! http://about.validator.nu/#pitch seems to be using a RELAX NG schema instead of a DTD, which is fine, though it's not clear where the schema actually came from. The draft alludes to "Criteria that cannot be expressed by a DTD, but can still be checked by a machine", and that's a good sign. But I can't find any formalized list of those criteria, and that's really not.

And sure, there will always be overworked or ignorant authors who roll out slipshod work. But I at least want it to be possible to expect better, as it was not before we had the first DTD for HTML.

I was also very dubious about HTML 5 until I attended a talk last May given by Mike Smith (http://sideshowbarker.net/). Slides here (for what they're worth without the talking to go with them):

http://www.slideshare.net/sideshowbarker/html5-and-xhtml2/

Previously I was quite pro XHTML but now, not so much. Mike mentioned in his talk that he did not think that XHTML 2 specification would ever come to fruition and it appears that he was correct. The XHTML 2 Working Group's charter will expire at the end of this year and not be renewed. So it's looking more and more likely that HTML 5 is our future.

Mike seemed like a knowledgeable guy with his head screwed on right. I don't think he and the others working on HTML 5 would be doing anything to set the web back. I'm sure there will be good options for people to validate their HTML 5 mark-up.

DTD != DOCTYPE.

More clearly, you are conflating two things: a Document Type Definition, which HTML5 does not have (since it is not an SGML application) and a Document Type Declaration, which HTML5 does have.

The former is (glossing over a lot here) an SGML document outlining the grammar and vocabulary of a particular markup language. The latter is a statement that a document uses a particular markup language. And such a statement does not require or imply the existence of a corresponding formal SGML definition of the language.

Right, they removed the public and system identifiers from the declaration because there will be no SGML DTD to point at. But as far as I can tell, the current draft fails to provide an official schema of any kind to take the place of a DTD.

That's because the specification instead defines the manner in which HTML5 documents should be parsed. In theory someone can provide an XML schema which defines the rules for the XML serialization of HTML5, but parsing HTML5 as HTML isn't something which (so far as I know) can be expressed in a standard machine-readable schema format.

The downside is you don't have "drop this file into an SGML parser and it works". But since that never worked with real-world SGML-based HTML anyway, the upside is that you get a parsing mechanism which actually handles the sorts of things you'll encounter in the wild.

Reply on news.ycombinator.com