Re: HTML5 and XHTML5 documents

[Collin Anderson]

> serve Django Admin as 'text/html', and let other apps choose for
themselves.
Yes, DEFAULT_CONTENT_TYPE is deprecated, so the admin (soon) should always
return text/html, and other apps can choose for themselves. (see ticket
#23908 )

I think django should be encouraging html instead of xhtml, but it
shouldn't be too hard to use django with xhtml.

Forms are probably the next biggest issue after the admin, right? I agree a
3rd-party package would be best for that. Templates could probably handle
most if not all of it. I'd be fine changing that one line in
django/forms/forms.py as_table from  to . maybe render_css too.
(or maybe those need to get moved to templates?) The 3rd party package
could provide xhtml versions of template tags and filters where needed.

On Fri, Aug 17, 2018 at 4:08 PM James Bennett  wrote:

>
>
> On Fri, Aug 17, 2018 at 3:41 AM, Nils Fredrik Gjerull 
> wrote:
>>
>> I am talking about being able to serve pages as application/xhtml+xml,
>> this is defined by browser support as is the SGML version of HTML5. I
>> hardly think XML version of HML5 is more ill-defined than the SGML
>> version. I am not talking about supporting validators, as the browsers
>> are the validators. No need to use a validator if the browser makes it
>> clear when it is not. No need to limit what entities to use as long at
>> it is supported by the browsers.
>>
>
> If you're basing your understanding on browser support, you're not doing
> XML/XHTML. You're doing "a thing that looks like XHTML and works in my
> browser".
>
> I'm even *more* against having Django try to do that, since it's a moving
> target.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg9UEtSBEPnc0_OJWy4HHALSA-XOLhgKBnnF5Fq7%3Dr811Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S6LtuC7J3bpk1HjSyTaE9pEuN8OjWkSx%3DpL%2BqG3e6M4Rg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[James Bennett]

On Fri, Aug 17, 2018 at 3:41 AM, Nils Fredrik Gjerull 
wrote:
>
> I am talking about being able to serve pages as application/xhtml+xml,
> this is defined by browser support as is the SGML version of HTML5. I
> hardly think XML version of HML5 is more ill-defined than the SGML
> version. I am not talking about supporting validators, as the browsers
> are the validators. No need to use a validator if the browser makes it
> clear when it is not. No need to limit what entities to use as long at
> it is supported by the browsers.
>

If you're basing your understanding on browser support, you're not doing
XML/XHTML. You're doing "a thing that looks like XHTML and works in my
browser".

I'm even *more* against having Django try to do that, since it's a moving
target.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9UEtSBEPnc0_OJWy4HHALSA-XOLhgKBnnF5Fq7%3Dr811Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Nils Fredrik Gjerull]

Den 17. aug. 2018 12:07, skrev James Bennett:
>
> XHTML5 itself is neither well-specified nor robust; the new elements
> of HTML5 are more or less dumped by fiat into the old 1999/XHTML
> namespace, but who's to say parsers will actually be aware of that?
> Especially validating parsers? Can you point to a standardized XML
> DTD, XSD, RELAX NG or, well, anything that's broadly accepted as
> defining XHTML5? W3C doesn't publish one that I'm aware of, and the
> Editor's Draft for Polyglot does not provide guidance.
>
> And speaking of validating parsers: HTML5 has a large set of named
> entities. Validating XML parsers are required, as always, to accept
> only the base five of XML, and can fatal-error on anything else. For
> non-validating parsers, or for those which choose to accept more than
> the base five named entities, XHTML and HTML historically did not
> agree on the set (XHTML defined 253 named entities, HTML historically
> defined at most 252). More fun times there. XML-ENTITY-NAMES tried to
> alleviate this by defining and exposing entity sets documents could
> refer to, but see again: validating parsers don't have to accept them.
> Are we forbidden ever to use an HTML5 entity, or anything outside the
> base five XML entities, in Django, in order to make sure serving
> Django as XHTML works? I hope not.

I am talking about being able to serve pages as application/xhtml+xml,
this is defined by browser support as is the SGML version of HTML5. I
hardly think XML version of HML5 is more ill-defined than the SGML
version. I am not talking about supporting validators, as the browsers
are the validators. No need to use a validator if the browser makes it
clear when it is not. No need to limit what entities to use as long at
it is supported by the browsers.

As for Javascript and the difference between a XML-dom and and HTML-dom.
I have not run into this. I use Javascript to manipulate the DOM, but
not heavily. Do the browsers generate different DOM when using
application/xhtml+xml to server the pages? That is an argument to serve
Django Admin as 'text/html', and let other apps choose for themselves.

In my case it is only the use '/>' and giving attributes a value that
stands in the way.

Regards

-- 
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official title :) )


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ab2142a2-c4bc-0112-5fec-9cf537fc8959%40gjerull.net.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: ModelForms not allowing unbounded RangeField values

[Carlton Gibson]

Hey James, 

Thanks for your follow-up here. 

I think for me the thing that's compelling is the flow you describe in comment 
12 :

* A user renders an unbound model form, where all model fields have 
defaults. 
* The form is pre-filled with the default values. 
* The form is submitted without changes. (The default values are submitted.)
* A new model instance is created with the defaults in place. 

*Except* that doesn't work with range fields. 

In your case, where you've specified a default (and null=False) it makes 
sense that the form field would return
a `self.range_type(None, None)` rather than None here. 

What I'm not sure about is whether that always makes sense? 

What if I don't define that default on the model field? What if I want 
`None`? 

forms.CharField will always return it's empty_value here (by default `''`) 
but this is independent of the model default. 

Q: Do we want the same sort of behaviour for (forms) RangeFields? 
(Possibly we do...?)


C.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc76cfb5-39d9-4bee-8a00-6764855eb5c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[James Bennett]

On Fri, Aug 17, 2018 at 1:50 AM, Nils Fredrik Gjerull 
wrote:

> I still would like a technical answer to why not support both standards?
> And again XHTML5 is HTML5 with valid XML syntax. So valid XHTML5 is
> valid HTML5, so there is no problem for a framework to provide HTML5 it
> should just be done in the most compatible manner.
>

You probably won't get a "technical answer", because what you're proposing
is not a technical change.

So, look. I was someone who, in the 2000s, passed Evan Goer's "XHTML 100"
test, even if he didn't test my site as part of it. I bought into it. But I
gradually learned it's more of a headache than it's worth, and should be
discouraged as a default. People who do still have use cases requiring XML
toolchains are free to implement what's necessary to support that (for
Django, that's mostly templating changes, and I believe we make it easy
enough to supply your own overrides that you could do it as a 100%
third-party effort for anyone else who shares your desire for XHTML).

But requiring Django to maintain XML-serialization-of-HTML5 compatibility
is a non-starter. It commits everyone else on earth to keeping that
supported, to ensuring we never do anything that's not XHTML-compatible,
etc., in order to serve a very small subset of developers, and I don't
think you realize how much specialized domain knowledge is actually
necessary to do that (it's more complex than "/>" and specifying attribute
values).

And I suppose if you really want technical arguments:

JavaScript is not portable between XML and HTML contexts, full stop. This
isn't just about the CDATA dance you have to do with inline script
elements; it's about the fact that the HTML and XML DOMs are different. And
not just with respect to namespaced versus non-namespaced DOM methods:
XML's rules literally do produce a different parse tree from the same DOM
when compared to HTML's.

XHTML5 itself is neither well-specified nor robust; the new elements of
HTML5 are more or less dumped by fiat into the old 1999/XHTML namespace,
but who's to say parsers will actually be aware of that? Especially
validating parsers? Can you point to a standardized XML DTD, XSD, RELAX NG
or, well, anything that's broadly accepted as defining XHTML5? W3C doesn't
publish one that I'm aware of, and the Editor's Draft for Polyglot does not
provide guidance.

And speaking of validating parsers: HTML5 has a large set of named
entities. Validating XML parsers are required, as always, to accept only
the base five of XML, and can fatal-error on anything else. For
non-validating parsers, or for those which choose to accept more than the
base five named entities, XHTML and HTML historically did not agree on the
set (XHTML defined 253 named entities, HTML historically defined at most
252). More fun times there. XML-ENTITY-NAMES tried to alleviate this by
defining and exposing entity sets documents could refer to, but see again:
validating parsers don't have to accept them. Are we forbidden ever to use
an HTML5 entity, or anything outside the base five XML entities, in Django,
in order to make sure serving Django as XHTML works? I hope not.

While we're on the topic of characters: HTML5's character encoding rules
are not compatible with XML's. Compliant HTML5 processors *must* use the
8.2.2.2 encoding sniffing algorithm in their first pass, and this can
produce a different determined encoding than XML's rules (and let's not get
into the quagmire of default encoding varying with Content-Type headers).

And, well, I could go on for a while here because my rants on this topic
are pretty well-developed at this point, but I'll just leave it alone here.
I'm strongly against any attempt to have Django try to produce
XML-serializable polyglot HTML5.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg_NdtL2kO_VCO41hAprWi3r5%3DF1baD0ASchCoBoMQexmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Nils Fredrik Gjerull]

Den 17. aug. 2018 11:01, skrev Curtis Maloney:
> One of the more significant differences between the advent of XHTML
> and now, is that HTML5 introduced standard rules for how to deal with
> "invalid" markup, meaning its handling in browsers became consistent.
>
> XHTML was a great move to allow a shift to browsers only accepting
> valid markup, but it never happened -- in part because IE just
> wouldn't play along.

IE now supports XHTML, so now it seams to me the biggest stumbling block
is fashion. I cannot shake of the feeling that the arguments are "I
don't like giving attributes a value and ending self-closing tags with
'/>'" or perhaps "some engineer at Google says so".

> So a softer solution was found - moving to HTML5 with defined failure
> modes and handling.
>
> Currently, ISTM the only thing standing in the way of you using Django
> for generating valid XHTML is the form widgets, in which case I
> suspect writing your own widget templates would be far less work for
> everyone involved.
>
> You could also provide them, quite trivially, as a 3rd party app for
> other people facing the same issues as you. 

I suppose I could, but why? When giving attributes values and ending
self-closing tags with '/>' makes it work for both cases? I really like
Django with it excellent documentation and promotion of good practices.
I newcomer can learn a lot from how Django is made. Django has provided
valid XHTML markup for years, as far as I can tell.

I can update the pull-request and concentrate the changes on the actual
HTML generated by Django, and leave out the documentation and comments
if it helps to make it more palatable. However, I think it would be a
good thing to learn that there is a thing called XHTML5. Perhaps I can
update the documentation to make it clear, but give the examples using
the SGML syntax of HTML5?

Regards

-- 
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official title :) )


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/18954a92-fa91-549e-91be-d6cdd5ab9c66%40gjerull.net.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Curtis Maloney]

On 08/17/2018 06:50 PM, Nils Fredrik Gjerull wrote:

think, however, that it is more clear if we give it a value. By the way,
the syntax is not new it is the old syntax from HTML4. I have spent
quite some time cleaning up ill-formed HTML4.


One of the more significant differences between the advent of XHTML and 
now, is that HTML5 introduced standard rules for how to deal with 
"invalid" markup, meaning its handling in browsers became consistent.


XHTML was a great move to allow a shift to browsers only accepting valid 
markup, but it never happened -- in part because IE just wouldn't play 
along.


So a softer solution was found - moving to HTML5 with defined failure 
modes and handling.


Currently, ISTM the only thing standing in the way of you using Django 
for generating valid XHTML is the form widgets, in which case I suspect 
writing your own widget templates would be far less work for everyone 
involved.


You could also provide them, quite trivially, as a 3rd party app for 
other people facing the same issues as you.


--
Curtis

--
You received this message because you are subscribed to the Google Groups "Django 
developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42092148-d7b2-2047-287b-3c2278f7944d%40tinbrain.net.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Nils Fredrik Gjerull]

Den 17. aug. 2018 10:04, skrev Carlton Gibson:
> Only half-joking, the diff here makes me want to weep. For me, 150
> files and 1803 line changes is just too much to 
> enforce something that is of minority appeal.

The changes are simple. Use '/>' at end of self-closing tags and give
all attributes values. And most of it is test-code. It is only the
'attrs.html'-files that are the real change (when it comes to giving an
attribute a value).

> On XHTML5 generally, I have no problem with properly closing tags, and
> I guess `/>` if you must but I look at `checked="checked"` and my
> personal response is that I just don't want that.
> I understand the benefits of XML but I think trying to enforce it in a
> web framework in 2018 and beyond is skating to where the puck was, so
> to speak. Developers expect HTML5 and it we don't go with that as a
> default every PR that comes in will need "correcting" for the XML
> syntax, and we'll end up with a 10:1 increase in new issues asking why
> we're not taking advantage the new, more concise, syntax.

Unfortunately web-development has been and are plagued by fashion waves.
First everything should be XML, now everything should be JSON. We first
had web services and XML-RPC, then REST and now perhaps GraphQL. I agree
that `checked="checked"` is not cool, but that's beside the point. It is
the standard and frameworks and library need to be extra careful to
support them. It is possible to write `checked=""`, if that helps. I
think, however, that it is more clear if we give it a value. By the way,
the syntax is not new it is the old syntax from HTML4. I have spent
quite some time cleaning up ill-formed HTML4.

>
> You want to serve the pages you generate with XHTML. Fine. (Beyond
> custom widget templates what do you need?) But (from the PR) why do we
> need to serve (e.g.) the Admin so? Or have the examples in the docs
> (and code comments) be XHTML compliant? Or the template we use to test
> the email sending functionality? (I appreciate you probably scripted
> these changes.)

I avoided updating the docs myself. The revert of a previous commit has
changed it. The comments can be changed to the HTML (SGML) style if it
helps. I did not add the XML style of boolean attributes to the docs,
but I can remove the '/>' if it helps.

>
> Does it really matter if framework provided pages use HTML5? Why? (If
> it does matter can you not warp a middleware around HTML Tidy, or
> similar, to do the conversion for you?)
>
> If there are barriers to you creating XHTML pages, we can look at
> those, but I'd be -1 on bringing it back framework wide. 

I still would like a technical answer to why not support both standards?
And again XHTML5 is HTML5 with valid XML syntax. So valid XHTML5 is
valid HTML5, so there is no problem for a framework to provide HTML5 it
should just be done in the most compatible manner.

Regards

-- 
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official title :) )


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/6c958426-b4d1-a99d-c47f-2c106f8fc1cf%40gjerull.net.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Carlton Gibson]

Hi Nils. 

> ... and an issue (#29681), which was 
prematurely closed as wontfix. 

As per the when you already re-opened #29038 on this issue, there now needs 
to be a consensus here before 
we can (or will) consider a new ticket for this. That's not "premature" — 
it's just how the project management of 
Django works. The mailing list allows a wider discussion on issues that 
have previously been resolved. 
I ask you to respect that. 

The PR: https://github.com/django/django/pull/10308

Only half-joking, the diff here makes me want to weep. For me, 150 files 
and 1803 line changes is just too much to 
enforce something that is of minority appeal. 

On XHTML5 generally, I have no problem with properly closing tags, and I 
guess `/>` if you must but I look at `checked="checked"` and my personal 
response is that I just don't want that. 

I understand the benefits of XML but I think trying to enforce it in a web 
framework in 2018 and beyond is skating to where the puck was, so to speak. 
Developers expect HTML5 and it we don't go with that as a default every PR 
that comes in will need "correcting" for the XML syntax, and we'll end up 
with a 10:1 increase in new issues asking why we're not taking advantage 
the new, more concise, syntax. 

You want to serve the pages you generate with XHTML. Fine. (Beyond custom 
widget templates what do you need?) But (from the PR) why do we need to 
serve (e.g.) the Admin so? Or have the examples in the docs (and code 
comments) be XHTML compliant? Or the template we use to test the email 
sending functionality? (I appreciate you probably scripted these changes.)

Does it really matter if framework provided pages use HTML5? Why? (If it 
does matter can you not warp a middleware around HTML Tidy, or similar, to 
do the conversion for you?)

If there are barriers to you creating XHTML pages, we can look at those, 
but I'd be -1 on bringing it back framework wide. 

Kind Regards,

Carlton




-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba8245ff-85b4-4369-8504-eb080136d238%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: HTML5 and XHTML5 documents

[Nils Fredrik Gjerull]

Den 13. aug. 2018 14:52, skrev Tim Graham:
> Another discussion about HTML vs XHTML
> is https://groups.google.com/d/topic/django-developers/EdwwxxqcKVU/discussion.
>
> I think if you want to use XHTML, Django should make is possible, but
> as it seems the majority of projects use HTML5, I would stick to that
> as the default.
>
> Have you tried creating custom widget templates for XHTML?
> https://docs.djangoproject.com/en/stable/ref/forms/renderers/

By making simple changes to the HTML that Django, by default, uses we
can make it work for both XHTML5 and HTML5. When there is a choice
between making in work for one case and making it work for both cases,
why make it work for only one?

I have created a pull-request for this, and an issue (#29681), which was
prematurely closed as wontfix.

Regards

-- 
Nils Fredrik Gjerull
-
"Ministry of Eternal Affairs"
Computer Department
( Not an official title :) )


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4418411-9d1b-0ebf-e686-5cbaca633277%40gjerull.net.
For more options, visit https://groups.google.com/d/optout.