Color and Voice

entrepreneurship, design, development, django, jquery, video. A professional creative and developer in Eugene Oregon. Love my family, my work and the outdoors. 
« Back to blog

HTML 4 in Django? Why Not?

I'm finally getting back into the swing of things after a great trip to Portland for DjangoCon 2009. Needless to say I learned a TON.

The thing that I have been continuously impressed with about the Django community is a stringently agnostic approach to development. Django does not and will not commit to a specific JavaScript framework, database, or gizmo. Being agnostic provides a framework that allows me to do what I want, how I want. However, there is one exception. (X)HTML output.

XHTML should not be the default output. And not for any ideological reasons relating to doctype, javascipt preference, or mime type rendering. But simply because it is not an agnostic decision. It's not loosely coupled, its magical, its not consistent, and it's doesn't encourage best practices.

As a "front end guy" I do not want to be told that I can ONLY use XHTML if I want my documents to validate. To me, that would be like me telling a developer you HAVE to use MySQL. It just doesn't seem like a choice that the developer gets to make for me.

This is NOT a discussion about HTML vs XHTML as a proper doctype. I could care less that you want to use XHTML and I want HTML. I'm going to assume that we are all going to make educated decisions about what we are doing. So please, save the doctype debate for a different day.

Simon Willison has created a great Django app called django-html. The heart of it allows me the ability to swap doctypes at will and create instances of widgets as I need them to be with additional class name options. And that is really useful. In Django, a great solution for front end developers would be to create widget templates. These templates could be overwritten by the designer or front end guy for any purpose.

For instance, why not do this based on the widget classes:

templates/widgets/checkbox.html
templates/widgets/textarea.html
templates/widgets/radio.html
templates/widgets/input.html
templates/widgets/selector.html

There has been some talk on this topic in the tickets and in the Google Group:
http://code.djangoproject.com/ticket/7281
http://code.djangoproject.com/ticket/7452
http://groups.google.com/group/django-developers/msg/00a5d83e8c80df6c
http://groups.google.com/group/django-developers/browse_thread/thread/f04aed2bc60274f0
http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/

All I want is the choice.

Thoughts?

Loading mentions Retweet

Comments (3)

Sep 21, 2009
John Shimek said...
I just starting using django-html and love it. I came for the problem of wanting to easily set the classes on the form fields. I don't feel like that is something that should be hardcoded into the form definition. I then forked django-html and added a tag to add classes to the labels as well as the fields.

Of course, once I looked at django-html, I realized I wasn't writing xhtml and this was also an issue that needed to be addressed.

Sep 21, 2009
Dave Merwin said...
Yeah, that is how I realized about XHTML as well. "Why won't my stuff validate?"
Sep 21, 2009
Matt Wilson said...
I am with you, Dave. I think that is why I am so excited for HTML5: one does not have to declare, necessarily, a specific Doctype. Ahhh! how nice and easy that is. But, if folks are dealing with integrating a bunch of old pages into a new system, but do not have the resources or time to go back and make sure that the markup matches a singular doctype, then it would be great to have a system that simply accommodates whatever doctype that is applicable to any given page (or group of pages).
I think my comment is--even slightly--on track with the topic of your post. In a nutshell, doctype restrictions only lead to issues and reduce the flexibility of apps. With that said, we just announced that ALL documents created at our workplace need to be XHTML Transitional and must validate as such. DOH!

Leave a comment...

 
Got an account with one of these? Login here, or just enter your comment below.
Posterous-login    Connect    twitter