On Sat, Sep 26, 2009 at 2:13 AM, Simon Willison <si...@simonwillison.net> wrote:
> Yes - I looked briefly at how much work was involved in doing this and
> it's not insubstantial, which is why I opted for string replacement
> just to demonstrate the API. I'm confident the exact functionality of
> django-html could be replicated in a less messy way by patching core,
> but it would require quite a bit of refactoring of django.forms.
This is the bit I was hoping we could get to. What would that
refactoring look like, you think? Would it involve making forms use
Templates? Or something else?
> I think the key problem is template filters, which often produce XHTML
> (linebreaksbr for example). This could be solved by allowing template
> filters selective access to the template context, which I'm in favour
> of in the absence of a compelling argument against. This could be done
> in a way that allows existing filters to continue to work - maybe
> something as simple as this:
>
> register.filter('cut', cut, takes_context=True)
>
> Which emulates the register.inclusion_tag API.
We've got django.forms and tags/filters on the plate. How might we
fix something like comments which has templates which write out XHTML
(or other little places which hand code HTML)?
For example, if one includes contrib.comments in their HTML4 website,
it doesn't validate...
http://validator.w3.org/check?uri=http%3A%2F%2Fjacobian.org%2Fwriting%2Fsnakes-on-the-web%2F&charset=%28detect+automatically%29&doctype=Inline&group=0
Ahem. Sorry Jacob!
I'd really hate to see something like this everywhere:
<input type="hidden" name="next" value="{{ next }}"{% if
doctype.xhtml %} /{% endif %}>
> Really not keen on that - designers should be able to pick their
> doctype, and there are some cases where specific pages of a site (or
> of a reusable app) might need to use a specific doctype - MathML
> output still requires XHTML for example.
I agree.
Simon mentioned how HTML and XHTML could result in Javascript and DOM
differences -- should we be concerned about being too dynamic about
swapping out HTML for XHTML, and vice versa, for fear of breaking
Javascript and CSS that rely on them?
For example, I think the Django admin is fine as XHTML since it isn't
intended to be an included part of your website. But say we were able
to easily set a different doctype that rendered as HTML4. Does that
have the possibility of really breaking things?
> I've somewhat foolishly volunteered for a bunch of 1.2 related hacking
> already (CSRF, logging, signing) but I remain actively interested in
> this, so I'll try to keep an eye on things and see if there's anything
> I can contribute.
If we can come up with something that everyone is happy with, I'm in
for volunteering time to help code it. I'm sure it will be a learning
experience for me as far as Django internals, but I'm willing to put
the effort into it.
Thanks,
Rob
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
