Or: Why is HTML4 such a PITA to get right? Outline: * What I know about HTML4 and Django * Some info about past efforts and discussions * Thoughts and curiosities about what we can do
What I know about HTML4 and Django ============================ First, let's not let this turn into an argument about HTML vs XHTML. People have their preference one way or the other, and I believe Django should be agnostic. Currently, however, Django *is* biased to producing XHTML output in the various places that output HTML, such as comments, formtools, csrf, forms.widgets, and various filters and HTML utilities that output "<br />" tags. For someone that prefers an HTML4 doctype, this is a hassle with no easy answer. Some info about past efforts and discussions ================================= Some tickets already open on this... Ticket #6925: CSRF html output is not valid html (it is xhtml) http://code.djangoproject.com/ticket/6925 Ticket #7281: Add doctype tag to webdesign template tags http://code.djangoproject.com/ticket/7281 Ticket #7452: Settings for HTML4 or XHTML output http://code.djangoproject.com/ticket/7452 Proposal from Mar 2008: Form rendering with filters... http://groups.google.com/group/django-developers/browse_thread/thread/5f3694b8a19fb9a1 Proposal from Sept 2008: {% doctype %} and {% field %} tag for outputting form widgets as HTML or XHTML... http://groups.google.com/group/django-developers/browse_thread/thread/f04aed2bc60274f0 Since those tickets aren't closed as "wontfix" or "invalid", and much of the conversation surrounding this agrees that *something* should be done, I'm hoping to start a conversation as to what that something might be. Thoughts and curiosities about what we can do ================================== After thinking for some time, I've only been able to come up with two ideas... 1. Incorporate something along the lines of Simon's django-html project (http://github.com/simonw/django-html). I think the genera idea is this: You set a doctype in your base template via a template tag (e.g. {% doctype "html4" %}, and any rendering that is done after that (in inherited or included templates) is based on this doctype. Advantages: * It puts the doctype decision into the hands of the designer. * It allows for different parts of an application to have different doctypes. Shortcomings: * Fixes the symptom, not the bug. [1] I think the fix should not do string replacement, but output the correct HTML in the first place. (I realize this is the best one can hope for as a 3rd party app, but if something were to come into core it would have the ability to fix things properly.) * Doesn't "fix" the rest of the areas where Django outputs XHTML. Is it possible? * Ties various parts of Django to the-thing-that-produces-HTML. 2. Add a new setting, e.g. settings.DOCTYPE, that various parts of Django and 3rd party apps use to render HTML. Advantages: * Simple and straightforward Shortcomings: * Yet another setting * Doesn't allow for template level decisions of doctype by designers Since I think idea #1 has the best chance of making headway, I've tried to look at how it might be done. Unfortunately, I don't know the template system well enough to see how setting {% doctype "html4" %} might be able to affect other areas of Django. Here was my thought process the other night... If Django widgets and other parts of Django always used the Template system to render HTML, it might be possible to set some global context variable of the current doctype. But perhaps the reason for not doing this initially is because each `get_template` call results in a read from the filesystem (or thread safety?)? In which case, we should consider fixing #6262, Cache templates. Using Templates everywhere does inhibit re-use of pieces of Django outside of Django as they would all now rely on Django's templates. There's also the option of something like Werkzeug's HTMLBuilder[2] and their use in Solace widgets[3]. I don't claim to have the answer, but I'm willing to put time and effort into helping solve this. Thoughts? Other ideas? Thanks, Rob [1] http://www.pointy-stick.com/blog/2007/09/04/fix-bug-not-symptom/ [2] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126 [3] http://bitbucket.org/plurk/solace/src/tip/solace/utils/forms.py#cl-294 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
