Re: Proposal: switch to HTML5 for bundled templates

2011-04-20 Thread Luke Plant
Hi all,

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/

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-04-01 Thread Julien Phalip
FYI, I've just stumbled on ticket #7452 and this thread:
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.

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-30 Thread Issac Kelly
2011/3/30 Łukasz Rekucki 

> On 30 March 2011 06:55, Matt Harasymczuk  wrote:
> >
> > 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.
>

Modernizr is just a support detection library.  It does not ..um...
modernize any browsers


Issac Kelly

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-30 Thread Łukasz Rekucki
On 30 March 2011 06:55, Matt Harasymczuk  wrote:
>
> 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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Matt Harasymczuk
Maybe start thinking in other way.

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 %}{% 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 , 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 ;}

--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Carl Meyer
I think it would be helpful here to clearly distinguish three distinct
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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Luke Plant
On 29/03/11 04:29, Julien Phalip wrote:

> 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.

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/

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Luke Plant
On 29/03/11 05:52, Gabriel Hurley wrote:
> 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

-- 
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/

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Gregor Müllegger
Using HTML5 tags in IE _will_ break it at some point. There is ofcourse the
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 :
> How about delivering http://www.modernizr.com/ library.
> 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
> 
>
> It works for me, hence all should benefit from it.
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> 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.
>
>

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-29 Thread Matt Harasymczuk
How about delivering http://www.modernizr.com/ library.
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


It works for me, hence all should benefit from it.


--
Matt Harasymczuk
http://www.matt.harasymczuk.pl

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Julien Phalip
On Mar 29, 4:01 pm, Stephen Burrows 
wrote:
> 3. There is a simple workaround going back to ie6 for handling the css
> problems related to unrecognized tags. [3]

...snip...

> [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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Stephen Burrows
Anyone interested in reading about html5 can find a lot of great
information at http://diveintohtml5.org/.

Some of the highlights:

1. a change to the doctype of the admin from http://www.w3.org/TR/xhtml1/DTD/xhtml1-
strict.dtd"> to  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

On Mar 28, 11:36 pm, Julien Phalip  wrote:
> On Mar 29, 2:29 pm, Julien Phalip  wrote:
>
>
>
>
>
>
>
>
>
> > On Mar 29, 1:26 pm, Luke Plant  wrote:
>
> > > 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 .  AFAIK, this is fully backwards compatible
> > > with browsers that don't support it, since  default to
> > > type="text" if the browser doesn't recognise the "type" attribute.
>
> > This commodity with input types (particularly search, tel, url and
> > 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? :-)
>
> Further to this, although I haven't done a great deal of testing
> 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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Gabriel Hurley
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!

But hey, aren't we starting to stray into... ::gasp:: front-end territory 
here?! Where's our Benevolent Designer For Life? ;-)

All the best,

- Gabriel

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Julien Phalip
On Mar 29, 2:29 pm, Julien Phalip  wrote:
> On Mar 29, 1:26 pm, Luke Plant  wrote:
>
> > 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 .  AFAIK, this is fully backwards compatible
> > with browsers that don't support it, since  default to
> > type="text" if the browser doesn't recognise the "type" attribute.
>
> This commodity with input types (particularly search, tel, url and
> 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? :-)

Further to this, although I haven't done a great deal of testing
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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Julien Phalip
On Mar 29, 1:26 pm, Luke Plant  wrote:
> 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 .  AFAIK, this is fully backwards compatible
> with browsers that don't support it, since  default to
> type="text" if the browser doesn't recognise the "type" attribute.

This commodity with input types (particularly search, tel, url and
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/

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Russell Keith-Magee
On Tue, Mar 29, 2011 at 10:26 AM, Luke Plant  wrote:
> 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 .  AFAIK, this is fully backwards compatible
> with browsers that don't support it, since  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 %-)

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Luke Plant
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.

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 .  AFAIK, this is fully backwards compatible
with browsers that don't support it, since  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/

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Russell Keith-Magee
On Tue, Mar 29, 2011 at 6:08 AM, Wim Feijen  wrote:
> +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 %-)

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Calvin Spealman
+1

No harm, as it breaks nothing currently using the templates.

Sets a great message that Django moves forward. I like it.

On Mon, Mar 28, 2011 at 12:38 PM, Luke Plant  wrote:
> Hi all,
>
> 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.
>  and  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

Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Wim Feijen
+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.

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.

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Gabriel Hurley
While on a personal level I agree wholeheartedly about moving to HTML5, I do 
have reservations about it from the perspective of Django's "enterprise" 
customers (AKA the ones with legacy and bureaucratic issues).

Thankfully we don't have major backwards-compatibility issues to deal with 
from a functionality standpoint with the HTML5 doctype... but organizations 
with validation requirements certainly still have a stake in this decision.

Provided the template-based form widget rendering proposal gets implemented, 
perhaps the 1.4 documentation could give a full how-to on controlling the 
output rendering so that those folks who need valid output according to one 
spec or another have an obvious resource to turn to.

This is also probably an area where a third-party app could fill in the gap 
to offer various libraries of doctypes and widgets fairly easily.

On the whole I'm +0 in the name of progress.

All the best,

- Gabriel

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Paul McMillan
As with the others, I'll chime in to support this idea. It will really
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

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Paul Egges
I agree completely that we should move to HTML5. It seems like it will be
even more important as more and more people use Smart Phones or Pads for
surfing the net, and I believe all of these are supporting HTML5.  I've
started attending some HTML5 user group meetings, and I'm quite impressed
with the tools/libraries available for development.

Paul

On Mon, Mar 28, 2011 at 10:46 AM, Carl Meyer  wrote:

> Hi Luke,
>
> 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
>
> --
> 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.
>
>

-- 
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.



Re: Proposal: switch to HTML5 for bundled templates

2011-03-28 Thread Carl Meyer
Hi Luke,

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

-- 
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.