Proposal: switch to HTML5 for bundled templates
Luke Plant
I'd like to put forward the proposal that we switch to HTML5 for all
Django supplied templates in Django 1.4 (apart from some of the GIS
templates which apparently require XHTML to work under IE). I'm quite
prepared for this to get shot down in flames, but I think it is at the
point where it is worth suggesting.
For reference, Rails switched their to outputting HTML5 by default with
Rails 3, released last August (and obviously this was in trunk for some
months before).
The change would require changing doctypes only, and not any of the
other HTML we render. This is because XHTML style tags are valid HTML5.
All the other complications of a switch from XHTML -> HTML are mitigated
(completely mitigated, as far as I can tell) by the fact that we serve
as 'text/html' by default, which means that our generated pages have
always been treated as HTML rather than XHTML anyway. (I suspect that
extremely few are serving as application/xhtml+xml, if any. You will
probably find that the admin has various bugs if you try to serve it is
application/xhhtml+xml)
Because of this tolerance in the HTML5 spec, this is quite different
from switching to HTML4 (or supporting HTML4), which I was against [1].
I would suggest we carry on generating XHTML-style code indefinitely for
backwards compatibility with pages that have XHTML doctypes. Going
forward we can start to use HTML5 features at least as an option in
places like the admin.
So the patch is very small and simple (attached). It remains to be seen
whether the change will be as simple in practice as in theory. If we put
it in early in the release cycle we can get some testing and see if
there are subtle problems.
== Advantages ==
1) It will allow us to use HTML5 in the admin and other places, where it
is has browser support or is sufficiently backwards compatible (e.g.
<input type="email"> and <input type="text" pattern="..."> could be used
today with no issues as far as I am aware).
2) It will allow other people to use more advanced features of HTML5 as
they see fit. (Although you can argue that they can do so without an
HTML5 doctype, but they can't have document validity).
3) We avoid fragmenting the re-usable apps ecosystem into the different
dialects of HTML by encouraging everyone to move to HTML5. This is a
significant issue, and we are at the point where it is becoming
important, as more and more people will be wanting to use HTML5 features.
4) We will have a 'solution' for all the HTML4 related tickets:
http://code.djangoproject.com/ticket/6925
http://code.djangoproject.com/ticket/7281
http://code.djangoproject.com/ticket/7452
(Admittedly it is not a solution, because we will still not be providing
HTML4 support. But we will have an answer for people who object to XHTML
doctypes for whatever reason).
5) This is the 'right' thing - serving XHTML as text/html was never
really the best thing. It even causes failure with some validators like
validator.nu which compare the http-equiv Content-Type with the expected
Content-Type (from HTTP or doctype).
6) It could simplify things like Russell's proposed form rendering [2] -
one less variable and code path is definitely a plus.
== Problems ==
1) HTML5 is not finished.
But apparently it may be difficult to ever say that it is finished. [3]
And if we stick to the parts that are stable and well supported by
browsers in terms of what we actually ship with Django, this is not an
issue.
2) Lack of offline HTML5 validation tools
You can download the W3C markup validator, but it is a pain trying to
use it locally [4]. Ditto validator.nu [5]. Both of them are designed to
be used as web services running under a web server, rather than as a
simple command line app. I have got the latter one working with my
'django-output-validator' app, and it isn't too bad, but it is
significantly harder than, for example, using the 'validate' binary from
Debian package wdg-html-validator. It depends on whether people are
already accustomed to using web services for validation.
It is hard to know when this will be fixed, if ever, due to 1). It does
seem like validation is becoming a much less useful thing anyway - what
you really need to know is whether your document is going to be 'well
enough' supported by browsers, which cannot be answered by validation.
However, there will be some customers who require HTML validity
(especially for WCAG and Section 508), and I for one would prefer it.
If you take the approach of 'valid until proved otherwise', which I
think is sensible, then knowing that 100% of output is valid is perhaps
not too big an issue.
3) Potential problems if people have made use of actual XML features and
use elements from other namespaces e.g. MathML/SVG/VML in pages that
currently have XHTML doctypes, and need these features to work in
browsers that support XHTML but not HTML5.
I haven't done enough research to know which browser combinations are
likely to be affected. Modern browsers have increasing support for
MathML/SVG in HTML5 documents, and I suspect that in the vast majority
of cases people are already using more portable and capable alternatives
that won't break if we switch to HTML5 e.g. MathJax or <embed> for SVG,
Did I miss anything?
Overall, I think the advantages outweigh the disadvantages, that we have
to make the move sometime, and now is about the right time, or perhaps
slightly late.
Regards,
Luke
[1] http://groups.google.com/group/django-developers/msg/a65fbbc8effcd914
[3] http://wiki.whatwg.org/wiki/FAQ#When_will_HTML5_be_finished.3F
[5] http://about.validator.nu/#src
--
"If something is hard, it's not worth doing." (Homer Simpson)
Luke Plant || http://lukeplant.me.uk/
Carl Meyer
On 03/28/2011 12:38 PM, Luke Plant wrote:
> Overall, I think the advantages outweigh the disadvantages, that we have
> to make the move sometime, and now is about the right time, or perhaps
> slightly late.
100% agreed, for all the reasons you outlined. We've been using the
HTML5 doctype exclusively for a year and a half already, with no issues,
and quite a lot of benefits (i.e. Firefox 4 and latest Chrome will now
do client-side validation of things like input type="email").
It's quite clear by now that HTML5 is the future, we may as well get on
board sooner rather than later.
Carl
Paul Egges
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Paul McMillan
help move Django in the direction that the web is going, without
seriously breaking existing code (aside from the people who are really
using the XHTML features, and those people can almost certainly figure
out how to change back if they need to).
-Paul
Gabriel Hurley
Wim Feijen
will be released we will be right on time though a bit late.
In response to Gabriel, in my opinion, legacy problems should not be
addressed by not moving forward, but they can be resolved by either 1.
updating or 2. staying on a legacy django both of which are legitimate
options.
Calvin Spealman
No harm, as it breaks nothing currently using the templates.
Sets a great message that Django moves forward. I like it.
> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to django-develop...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
>
>
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
Russell Keith-Magee
> +1. All major browsers now support html5 and by the time django 1.4
> will be released we will be right on time though a bit late.
Statements like "All modern browsers support it" misses the point. It
isn't the *modern* browsers that are the issue -- it's the *legacy*
browsers. This is exactly the same reason why we can't drop support
for old versions of Python -- "modern" operating systems all provide
Python 2.6 or better, but older operating systems don't.
Like it or not, IE6 still exists, and still has a non-trivial market
share [1]. I have green field projects that I'm working on right now
for which IE6 compatibility is an issue. Do I like it? Not one little
bit. But I have to follow the golden rule -- whoever has the gold,
makes the rules, and it's an unfortunate fact of life that enterprise
customers have money, and they also have massive IT installations that
can't/won't move off IE6.
I'm all on board with the broad sentiment of this proposal -- that we
should be providing a way for people to use HTML5 when they can, and
probably even moving to HTML5 as the default rendering style. However,
we simply *can't* ignore old browsers in this transition.
As with Gabriel; call me a tentative +0; this will rapidly drop to -1
if means supporting IE6 is difficult or impossible as a result of the
change.
Of course, this depends a great deal on the details of exactly what is
to be done, and where. Luke's proposal says we should "use HTML5
features at least as an option in places like the admin", but the
provided patch is a unilateral switch to HTML5 doctypes in the admin.
Optional support is a completely different beast from only providing
HTML5 rendering.
And, to provide some context to Luke's point (6) -- part of my driving
motivation in the template rendering proposal was to provide a way for
end-developers to determine which doctype they want to use, and how
they interpret that doctype, rather than Django needing to mandate
anything.
[1] http://www.ie6countdown.com/
Yours,
Russ Magee %-)
Luke Plant
> Of course, this depends a great deal on the details of exactly what is
> to be done, and where. Luke's proposal says we should "use HTML5
> features at least as an option in places like the admin", but the
> provided patch is a unilateral switch to HTML5 doctypes in the admin.
> Optional support is a completely different beast from only providing
> HTML5 rendering.
The initial proposal is simply switch to HTML5 doctypes for supplied
templates. This means that if some people have widgets that rely on
HTML5 features, they can render those widgets in the context of the
admin and have them work and have them valid.
I'm not sure what you mean by "only providing HTML5 rendering". The
existing rendering of all widgets is already both XHTML and HTML5
compliant, so changing the doctype doesn't affect that.
I'm not aware that this doctype switch would cause any problems with
either validity or functionality for any provided or 3rd party widgets
that are outputting XHTML - really because we've never had true XHTML
output - we've had XHTML served as HTML, which works like HTML in almost
every respect.
The further enhancements I'm thinking of are things like an EmailInput
widget (which I'd suggest was the default widget for EmailField, but
could be just available in django/forms/widgets.py). This widget would
output <input type="email">. AFAIK, this is fully backwards compatible
with browsers that don't support it, since <inputs> default to
type="text" if the browser doesn't recognise the "type" attribute.
Regards,
Luke
--
If you can't answer a man's arguments, all is not lost; you can
still call him vile names. (Elbert Hubbard)
Luke Plant || http://lukeplant.me.uk/
Russell Keith-Magee
> On 29/03/11 03:10, Russell Keith-Magee wrote:
>> Of course, this depends a great deal on the details of exactly what is
>> to be done, and where. Luke's proposal says we should "use HTML5
>> features at least as an option in places like the admin", but the
>> provided patch is a unilateral switch to HTML5 doctypes in the admin.
>> Optional support is a completely different beast from only providing
>> HTML5 rendering.
>
> The initial proposal is simply switch to HTML5 doctypes for supplied
> templates. This means that if some people have widgets that rely on
> HTML5 features, they can render those widgets in the context of the
> admin and have them work and have them valid.
>
> I'm not sure what you mean by "only providing HTML5 rendering". The
> existing rendering of all widgets is already both XHTML and HTML5
> compliant, so changing the doctype doesn't affect that.
It's not the widgets I'm concerned about as much as the doctype, and
the way the browser interprets that directive.
> I'm not aware that this doctype switch would cause any problems with
> either validity or functionality for any provided or 3rd party widgets
> that are outputting XHTML - really because we've never had true XHTML
> output - we've had XHTML served as HTML, which works like HTML in almost
> every respect.
>
> The further enhancements I'm thinking of are things like an EmailInput
> widget (which I'd suggest was the default widget for EmailField, but
> could be just available in django/forms/widgets.py). This widget would
> output <input type="email">. AFAIK, this is fully backwards compatible
> with browsers that don't support it, since <inputs> default to
> type="text" if the browser doesn't recognise the "type" attribute.
If this is true -- that using a HTML5 doctype won't affect IE6
rendering, and a type="email" degrades gracefully to type="text" --
then that covers the bulk of my objections.
To be clear -- I'm speaking mostly out of my own ignorance here. When
I start hearing planning discussions predicated on the assertion that
"all modern browsers support HTML5", it makes me nervous. My daily
development work involves, in part, supporting IE6, so I haven't been
spending a whole lot of time investigating all the wonderful things
you can do with HTML5 beyond basic awareness of what I'm missing out
on. I certainly haven't done any great exploration of the
compatibility issues that exist -- it's easier to just not use HTML5.
I just want to make sure that supporting older browsers isn't
forgotten as a concern.
Yours,
Russ Magee %-)
Julien Phalip
> The further enhancements I'm thinking of are things like an EmailInput
> widget (which I'd suggest was the default widget for EmailField, but
> could be just available in django/forms/widgets.py). This widget would
> output <input type="email">. AFAIK, this is fully backwards compatible
> with browsers that don't support it, since <inputs> default to
> type="text" if the browser doesn't recognise the "type" attribute.
email) may possibly be the only one we can offer out-of-the-box if we
want to continue supporting IE6 without javascript. This would still
be welcome though, and certainly a step in the right direction. In
principle, the HTML5 doctype is fully backwards and forwards
compatible with any browser so that can't hurt [1].
Since the patch is small, then it would be very quick to test it in
all browsers right away, no? :-)
Julien
[1] http://ejohn.org/blog/html5-doctype/
Julien Phalip
myself yet, I hear that old browsers sometimes aren't able to apply
CSS rules to tags that aren't recognised or that have attributes that
aren't recognised. So if we test this patch with old browsers we
should also test how CSS is affected.
Julien
Gabriel Hurley
Stephen Burrows
information at http://diveintohtml5.org/.
Some of the highlights:
1. a change to the doctype of the admin from <!DOCTYPE html PUBLIC "-//
W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd"> to <!DOCTYPE html> should still keep ie6 in Almost
Standards Mode [1]
2. Browsers degrade the new form inputs gracefully [2]
3. There is a simple workaround going back to ie6 for handling the css
problems related to unrecognized tags. [3]
[1] http://hsivonen.iki.fi/doctype/
[2] http://diveintohtml5.org/forms.html#type-email
[3] http://diveintohtml5.org/semantics.html#unknown-elements
Julien Phalip
wrote:
> problems related to unrecognized tags. [3]
> [3]http://diveintohtml5.org/semantics.html#unknown-elements
The workaround works if javascript is enabled. So we can't consider it
if we want to support IE6 with javascript turned off.
However, in the case of inputs, the tag definitely is known by IE6 --
it's the 'type' attribute's values that will not be recognised. I'm
not sure if that affects CSS though.
Julien
Matt Harasymczuk
In my case it solves all problems with non existing tags (nav,
section, header, article, footer) in such browsers as IE.
We ship jQuery with admin, why not use modernizr to support legacy
browsers.
I am positive, about input types fallback to text.
I have tested this for a long time and it works.
Generally speaking converting contrib apps to html5 would be a very
good idea! Most django deployments does not depend on whether it has
html4 or 5.
Those who stick with 4, should have the same functionality provided by
fallback in their browsers, however the largest part of the remaining
group should benefit from transition.
Google dropped support for IE6 legacy browsers more than year ago!
http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html
Even microsoft wants IE6 dead
http://ie6countdown.com/
I think we should join this movement, and provide modernizr, for
example in conditional css tag
<!--[if IE 6]>
<script type="text/javascript" src="js/modernizr.js"></script>
<![endif]-->
It works for me, hence all should benefit from it.
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
Gregor Müllegger
work around with "document.createElement('article')" etc used by modernizr
But:
1. This will not work for IEs' that have JS disabled
2. Will break if you insert HTML5 tags by javascript into the "innerHTML"
attribute of tags (even those that were created with the workaround above).
Point 2 hit mit just a few weeks ago and is even valid for IE 8. The problem
is that even jQuery is using the innerHTML attribute in it's .append() method
and others which are very common to must jQuery users.
To be honest, there is a workaround for this as well. But it requires either
patching jQuery or to change ALL YOUR CODE that uses .innerHTML (including
all your uses of jQuery.fn.append()). [1]
Input types are not effected by this bug afaik.
Gregor
[1] http://jdbartlett.github.com/innershiv/
2011/3/29 Matt Harasymczuk <ma...@harasymczuk.pl>:
Luke Plant
> Switching to the HTML5 doctype won't hurt IE6 rendering (having dealt
> with this myself several times). To the best of my knowledge--from my
> own tests and third-party sources--using the new input attributes also
> doesn't hurt IE6. However, if we start delving deeper into HTML5 and
> using the new HTML5 elements, etc. we will definitely hit problems very
> quickly. Techniques for solving those problems are pretty readily
> available these days, but I don't think we have any reason to go there
> right now.
>
> All the same, I'd still rather give people the choice and ability to
> change output rendering rather than simply making a unilateral change.
> I'd love for our default to be the modern choice as long as it's an
> easily changeable option!
I don't think we can talk about "output rendering", as if internally to
Django we had an output agnostic document tree which we just have to
render. The reality is that in Django we've got XHTML markup.
I think that supporting multiple doctypes by rendering different output,
depending on the choice of the developer putting the site together, is
actually a bad idea - a bug not a feature. My reasons are:
* every attempt I've seen to get this working in Django has been as ugly
as sin, and incurs performance and API overhead.
* in reality, re-usable apps are going to go for one doctype or another,
thus fragmenting the app ecosystem.
* For those targeting HTML5, you *still* have to choose your features
very carefully in line with browser support, and for those targeting
older browsers you still have to be careful to work around browser bugs.
In short, I think it it neither realistic nor worthwhile to go for the
multiple doctype approach.
Instead, I think we should think about the ultimate goal, which is
compatibility with old browsers. And to address that, we should take the
same approach as HTML5, and the approach that we *have* to take even
with the very newest browsers, which is to carefully select features
that have good browser support, providing graceful degradation for those
that don't - and do this from a *single* output.
As Django is a framework and is used in many situations, we're going to
be pretty conservative. I think we need to support IE6 for some time,
which at least means everything that works now continues to work
correctly, although I'd allow for any older browser to suffer
degradation in user experience in new features, relative to newer
browsers. For an example of the kind of thing I mean, a new feature in
the admin might make use of spin boxes:
http://diveintohtml5.org/examples/input-type-number-min-max-step.html
We'd certainly have server-side validation, and ideally we'd have a
javascript fallback, but I would be happy for the feature to go in even
without the javascript fallback. But I think we should argue those
things out on a case-by-case basis.
> But hey, aren't we starting to stray into... ::gasp:: front-end
> territory here?! Where's our Benevolent Designer For Life ;-)
I for one would definitely like Idan's input here, I'm sure he has more
experience than me!
Luke Plant
> Since the patch is small, then it would be very quick to test it in
> all browsers right away, no? :-)
I've spent 20 minutes testing out the admin with this patch and IE6, and
haven't found any issues (at least, none that aren't already present
without the patch - I found that the list of deleted objects is not
indented as in other browsers in IE6, and I got the dreaded 'broken
pipe' error several times, with or without the patch).
I also found a handful of validity errors - at least according to
validator.nu, which happens to be very crashy when running on my
machine, making validation a bit tricky.
Finding more issues than this will only happen by putting it out there
in the wild, because so few people are using IE6, especially developers.
Carl Meyer
varieties of "using HTML5," two of which are clear wins and one which I
don't see any reason to do:
1. Switching to the HTML5 doctype in those few places where Django
actually renders a full page with doctype (the admin, databrowse, CSRF
failure page). This is fully backwards and forwards compatible, and
there is no reason (AFAICS) why we should not simply do it. It gives
people writing custom admin widgets more flexibility, without losing
anything. IMO "configurability" here is overkill; the admin (and
databrowse) are standalone apps: they just need to be internally
consistent and work well in all browsers.
2. Providing HTML5 form widget types (email, date, etc) in django.forms.
These are very useful in newer browsers, and fall back gracefully to
input type="text" in older browsers, so again I don't see a downside.
Unlike HTML5-only elements (see #3), these input types don't cause a
problem with CSS in IE.
3. Introducing HTML5-only elements (nav, section, footer, etc) anywhere
in Django-provided templates. This requires Javascript help to work with
most IE versions. Given that the current markup in Django works fine and
is already valid HTML5, I don't see why we would want to do this, short
of possibly in a full admin redesign later on.
My understanding is that Luke is proposing 1 & 2, but not 3 - and I
agree with that. Like others, I'm interested in hearing from Idan on this.
Carl
Matt Harasymczuk
Most of users has JS enabled browsers, if so, modernizr works.
Otherwise jQuery will not work either.
I can't remember when someone who has IE6 hit one of my django based
sites.
Maybe convert django to html5, and those who has to care about ie6
support should overwrite doctypes in templates and think about special
widgets. Give them {% block doctype %}<!DOCTYPE html>{% endblock %}.
As far as I know ie6 won't recognize difference if there is doctype
specified, it is specified invalid, or there is none. Therefore it
should not crash.
Probably for 1 developer who needs to support ie6, there is 20 who
does not need to.
For me, this situation is like minority terrorizing the whole nation.
Overwriting admin templates is easy, providing widgets to fallback
html5 input types to text fields seems not to be complicated.
Consider this:
from django.forms.widgets_legacy import *
and we're free to go, providing support for forgotten browsers.
Google on its search main page is using <!DOCTYPE html>, hence IMHO it
is nothing wrong with doctype.
BTW. Who is using proper mimetype with current django doctype in
cotrib admin?
I think that sticking with support for browser that even its creator
wants to die is wrong.
Django should go further and further, not stay in one place, because
of support for legacy features.
Django 1.3 is good, even very good, if someone wants to create django
based webapp with support ie6, should stick to 1.3 version.
Therefore 1.4 should have one of key feature: render with html5 by
default.
BTW. whatwg dropped from HTML5 its 5 in the name
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-December/024477.html
In that case IE6 is not HTML complaint and browser specific hacks
should not be a official and main part of framework.
There should be point of no return for this. And I think that 1.3 is
very good release to end support for legacy browsers.
Otherwise why not to support lynx and table based design?
I use terminal browsers from time to time. I think it is even more
important, because google bot which greatly influence on our potential
revenue sees pages like lynx does.
If not support html5 features now before the 1.4 release, then mark
support for ie6 like the XMLField, obsolete and on an accelerated
deprecation schedule.
I rest my case ;}
Łukasz Rekucki
>
> Most of users has JS enabled browsers, if so, modernizr works.
> Otherwise jQuery will not work either.
Most is not all. Even now the admin will work without jQuery, but it
won't work without modernizr if you put HTML5 tags in it.
>
> I can't remember when someone who has IE6 hit one of my django based
> sites.
>
A) That doesn't mean no one needs to support it. B) As it was
presented by now, there is nothing IE6 specific here. Newer versions
of IE don't support HTML5 section either.
I'm -1 on introducing a solution that "runs through a little loop in
JavaScript to enable the various elements from HTML5". If someone
wants to use it, they will. Adding it by default just to use a few
`section` elements and maybe a `header` is a bad idea.
Otherwise, +1 on changing the doctype and input elements' types.
--
Łukasz Rekucki
Issac Kelly
On 30 March 2011 06:55, Matt Harasymczuk <ma...@harasymczuk.pl> wrote:Most is not all. Even now the admin will work without jQuery, but it
>
> Most of users has JS enabled browsers, if so, modernizr works.
> Otherwise jQuery will not work either.
won't work without modernizr if you put HTML5 tags in it.
Julien Phalip
http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/
One interesting idea that was suggested is to introduce a setting for
controlling the type of HTML.
Luke Plant
With no objections that weren't addressed, I've committed this change now.
Just to re-iterate - we've switch the admin and other templates to an
HTML5 doctype, but that doesn't mean we are dropping support for older
browsers. We will continue to be selective and conservative in the use
of HTML5 features, ensuring backwards compatibility etc.
If we do find problems caused by this change, we may need to consider
reverting the change, but hopefully we will find other ways of dealing
with them.
Regards,
Luke
--
"I regret I wasn't born with opposable toes." (Calvin and Hobbes)
Luke Plant || http://lukeplant.me.uk/