Mail fired a bit early there.
That said, I'm not against a {% doctype %} tag or anything. However, I
do think having an xhtml default is a Good Thing due to its backwards
compatibility. I'm also not entirely fond of the idea of having 100
different language outputs in Django. Why stop only after xhtml and
html? So on.
I'm all for a better abstraction, but it needs to be thought twice
before adding features "just because".
J. Leclanche / Adys
On Sat, Sep 26, 2009 at 8:50 AM, Jerome Leclanche <adys...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
