This is a non-issue. Correct me if I'm wrong, but <br /> is valid html syntax. It's parsed as valid by every html parser, and I'm positive this is the entire point of xhtml: staying backwards-compatible with html.
J. Leclanche / Adys On Sat, Sep 26, 2009 at 7:48 AM, Rob Hudson <treborhud...@gmail.com> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
