Re: Django Forms in HTML 4.01 Strict
Isn't there a broader problem than just django.forms? Now that Django 1.0 seems to stand on the XHTML side, it encourages re-usable app authors to generate XHTML instead of HTML in their default templates as well as in any markup their apps might be generating programmatically. I have to admit that I've been ignorant re the HTML/XHTML debate, and only now I skimmed through a pile of arguments on both sides. It doesn't look like there will be a consensus any time soon (although the HTML side convinced me better today). To make sure most re-usable apps can serve both standards, too, Django probably needs to provide appropriate tools for developers, right? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
Here's some food for thought on the subject of HTML 4.01 in Django (as it's been discussed a lot before): James Bennet brought up the HTML4 argument on the Django developers list some time ago: http://groups.google.com/group/django-developers/browse_thread/thread/a233bb5b3b39e147/7c9bf930a533345b and later blogged about why he chose HTML4 for his personal blog: http://www.b-list.org/weblog/2008/jun/18/html/ > I have not suggested such thing though. From a brief look at the source > code, it appeared to me that it would be easy to create a setting that > specifies whether to include the slash or not, and based on that setting > write either " />" or ">" at the end of input tags (and ). This has been written some time ago and shot down by Jacob: http://code.djangoproject.com/ticket/3568 In the comment of the wontfix change he mentions he'd support a template filter for this, along the lines of what django-html is doing already. I personally believe, if Django should choose only one doctype as its default, it should choose HTML 4.01 and provide a filter for XHTML. But I think I'm in the minority on that. :) Cheers! -Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
On Thu, 2009-01-29 at 15:18 +0100, Gertjan Klein wrote: > Malcolm Tredinnick wrote: > > >On Wed, 2009-01-28 at 14:33 +0100, Gertjan Klein wrote: > >> Malcolm Tredinnick wrote: > >> > >> I disagree. When I develop web pages (using Django or otherwise) I use > >> the Firefox HTML validator extension. This helps me write > >> standards-compliant HTML -- a big red cross indicates a problem in my > >> page. It is annoying if that big red cross no longer indicates anything > >> (there might be problems *I* caused, or it might just be Django stuff). > > > >You realise that you're effectively confirming what I said, right?. The > >big red cross is a cosmetic issue. The fact that it makes precisely zero > >difference to the practical matter of how a real-world web browser > >processes the page means it's not fatal/tragic. > > No, I think you may have misunderstood me. The XHTML slash is cosmetic; > to my knowledge, all current browsers are capable of dealing with that > (thus deviating from what the standard dictates them to do, but > practicality beats purity, I guess ;)). XHTML, being XML, is consumed by much more than just web browsers and should be targeted at being correctly parsed and rejected by any conforming XML library (feed readers being one example). Conformance to the XML requirement that errors are fatal is therefore important. HTML is sufficiently screwed up that it's not really possible to level that requirement against it. > However, *my* HTML (as opposed to Django's generated HTML) may contain > errors as well, and regularly does. The big red cross in an invaluable > indicator that I messed something up, and losing that functionality is > annoying. In other words, there is a slight, but annoying, problem with such tools, in that they don't differentiate between errors that are going to cause real problems and those which aren't. That happens to interact with a slight, but annoying, problem in Django. No harm, no foul. Things could be better on both sides and one day people might change them. I'm completely in favour of 100% valid HTML code wherever possible. But I'm more in favour of knowing why that isn't compulsory and not always possible, and why there does need to be some differentiation. > Now, when using HTML as opposed to XHTML, I can no longer see > if I did something wrong, as the page is *always* in error (from a > standards compliance POV). > > >Then you'll have no trouble creating a parallel set of form widgets or a > >form framework that can handle this and everybody will be happy. :-) > > No, I have no desire to do such a thing. As I stated before, the > practical solution for me was to switch to XHTML. > > >Or look at the django-html project on Google Code, where various ideas > >are being tried out. > > I did, briefly, and didn't like what I saw. They overcomplicate things, > IMHO. I don't want DOCTYPE management, for example. Which shows why it's a harder problem than it looks on the surface, once you start looking at the details. Explains why it isn't in Django yet. > >(you're certainly paid just as much to work on Django as me, for > >example). > > This payment thing comes up regularly here, and pollutes the discussion. > I have been using Django for a while, and found it to have good things > and downsides (both IMHO). I have not even critisized Django here (yet > ;)), just expressed mild curiousity. I don't think I've given you reason > to bring up that you're not payed for your work on Django. Take it in the spirit it was offered, dude. Exactly the same tone as you used. It was part of a broader explanation about why this feature/enhancement isn't in Django and was only mentioned as part of a sentence in the second or third response because you kept going on about how the cosmetic thing was much more important to you. Let's keep some perspective, please. I wasn't intending to cause offence. If you're going to go on about something, I'm going to give you the full list of reasons why the state of play is as it is and how it can be made better. If you don't want the answer, don't ask the question. > >Maintaining two copies of everything certainly adds to the workload. > > I have not suggested such thing though. From a brief look at the source > code, it appeared to me that it would be easy to create a setting that > specifies whether to include the slash or not, and based on that setting > write either " />" or ">" at the end of input tags (and ). It's a question of which compromises should be made and where. You've indicated you'd be happy without that, for others, it would still be a hack if they don't have the DOCTYPE control (for the record, I have precisely no opinion on that yet). That's the fun of working with this stuff: never able to please everybody immediately. I think we should probably move on now. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups
Re: Django Forms in HTML 4.01 Strict
On Thu, 2009-01-29 at 06:36 -0800, Andrew Ingram wrote: > On Jan 29, 2:18 pm, Gertjan Klein wrote: > > This payment thing comes up regularly here, and pollutes the discussion. > > I have been using Django for a while, and found it to have good things > > and downsides (both IMHO). I have not even critisized Django here (yet > > ;)), just expressed mild curiousity. I don't think I've given you reason > > to bring up that you're not payed for your work on Django. > > Off-topic: > > For what it's worth I agree with you. I've lost track of the number of > times i've found bugs in open source software and been not-so-subtly > told to contribute the fix myself. Or asked about something that I > think should be included and been told to write it myself. > > As a consumer of software libraries it is not my job to fix them, It's rarely anybody's job to fix them, in the greater scheme of things. That's the whole point and why I think Gertjan's comment above is an over-reaction. We are *all* on a level playing field here. If somebody says something like "I wondered why it isn't in; it doesn't seem like a lot of work" in a light-hearted manner, they will often get a reply in the same tone, pointing out one of the many reasons why it isn't in there is that the person in question hasn't contributed a patch to add it. Itches get scratched by the people who have them, particularly enhancement requests. Sure, sometimes you can't fix the things, but then that's life. You made that risk evaluation going in. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
On Jan 29, 2:18 pm, Gertjan Klein wrote: > This payment thing comes up regularly here, and pollutes the discussion. > I have been using Django for a while, and found it to have good things > and downsides (both IMHO). I have not even critisized Django here (yet > ;)), just expressed mild curiousity. I don't think I've given you reason > to bring up that you're not payed for your work on Django. Off-topic: For what it's worth I agree with you. I've lost track of the number of times i've found bugs in open source software and been not-so-subtly told to contribute the fix myself. Or asked about something that I think should be included and been told to write it myself. As a consumer of software libraries it is not my job to fix them, maybe there will come a time when I choose to spend some time contributing back to the projects, but there is a lot of overhead involve in learning enough of how a library works to write patches and not everyone can spare this. Additionally some of us simply aren't smart enough to fix/add features we want. Your reasoning for wanting this functionality is reasonable, as is Malcom's explanation for why it has yet to be done (nobody has agreed on the best way to do it) Regards, Andrew Ingram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
Malcolm Tredinnick wrote: >On Wed, 2009-01-28 at 14:33 +0100, Gertjan Klein wrote: >> Malcolm Tredinnick wrote: >> >> I disagree. When I develop web pages (using Django or otherwise) I use >> the Firefox HTML validator extension. This helps me write >> standards-compliant HTML -- a big red cross indicates a problem in my >> page. It is annoying if that big red cross no longer indicates anything >> (there might be problems *I* caused, or it might just be Django stuff). > >You realise that you're effectively confirming what I said, right?. The >big red cross is a cosmetic issue. The fact that it makes precisely zero >difference to the practical matter of how a real-world web browser >processes the page means it's not fatal/tragic. No, I think you may have misunderstood me. The XHTML slash is cosmetic; to my knowledge, all current browsers are capable of dealing with that (thus deviating from what the standard dictates them to do, but practicality beats purity, I guess ;)). However, *my* HTML (as opposed to Django's generated HTML) may contain errors as well, and regularly does. The big red cross in an invaluable indicator that I messed something up, and losing that functionality is annoying. Now, when using HTML as opposed to XHTML, I can no longer see if I did something wrong, as the page is *always* in error (from a standards compliance POV). >Then you'll have no trouble creating a parallel set of form widgets or a >form framework that can handle this and everybody will be happy. :-) No, I have no desire to do such a thing. As I stated before, the practical solution for me was to switch to XHTML. >Or look at the django-html project on Google Code, where various ideas >are being tried out. I did, briefly, and didn't like what I saw. They overcomplicate things, IMHO. I don't want DOCTYPE management, for example. >(you're certainly paid just as much to work on Django as me, for >example). This payment thing comes up regularly here, and pollutes the discussion. I have been using Django for a while, and found it to have good things and downsides (both IMHO). I have not even critisized Django here (yet ;)), just expressed mild curiousity. I don't think I've given you reason to bring up that you're not payed for your work on Django. >Maintaining two copies of everything certainly adds to the workload. I have not suggested such thing though. From a brief look at the source code, it appeared to me that it would be easy to create a setting that specifies whether to include the slash or not, and based on that setting write either " />" or ">" at the end of input tags (and ). However, like I said, I have not researched this thouroughly, and I most certainly have not requested the Django developers to implement this. I may have overlooked more complicated things, and besides, if I wanted this badly I'd try and write it myself and if successfull, attempt to get it included in Django. Regards, Gertjan. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
On Wed, 2009-01-28 at 14:33 +0100, Gertjan Klein wrote: > Malcolm Tredinnick wrote: > > >In HTML, the requirement for errors of this form ( instead of > >), is that the parser *must* recover in a way that forces it to > >treat it as "" -- it has to ignore the invalid characters and > >recover in a particular, well-defined fashion. > > Do you have a reference for that? It is my understanding that there is, > indeed, a well-defined meaning the SGML specification for HTML: the > slash inside a tag introduces a so-called "shorttag". This treats > everything up until the next slash as the element's contents. Browsers > don't treat it as such, but that is a deviation of what the standard > asks them to do, not error recovery per se. I don't have a reference to hand, since the SGML spec is proprietary (yay for ISO... not) and it's been a while since I looked up chapter and verse. However, you may well be correct and I may be confusing the lexer/parser error recovery with something more semantic. Net effect is the same, though: that's how HTML browsers have to behave to work in this reality. > >That's why non-validity for HTML, when it's this kind of non-validity > >isn't a really big deal. It's cosmetic, rather than tragic. > > I disagree. When I develop web pages (using Django or otherwise) I use > the Firefox HTML validator extension. This helps me write > standards-compliant HTML -- a big red cross indicates a problem in my > page. It is annoying if that big red cross no longer indicates anything > (there might be problems *I* caused, or it might just be Django stuff). You realise that you're effectively confirming what I said, right?. The big red cross is a cosmetic issue. The fact that it makes precisely zero difference to the practical matter of how a real-world web browser processes the page means it's not fatal/tragic. Note, that at no point did I say it was perfect or ideal. But there's a difference in the severity. If we're going to implement only one side of the equation, it has to be the XHTML side, since XML parsers require that and HTML parsers can handle it. Seeing a big red cross every now and again is less than ideal, but only an inconvenience. > > As a result, I decided to switch to XHTML when developing with Django -- > also not fully standards compliant (the doctype is wrong), but at least > when I see a big red cross I know *I* did something wrong... > > Before I decided to switch and stop worrying about it, I also wondered > why Django didn't make this configurable. It didn't seem like a lot of > work, Then you'll have no trouble creating a parallel set of form widgets or a form framework that can handle this and everybody will be happy. :-) Or look at the django-html project on Google Code, where various ideas are being tried out. I'm sure they look forward to your patches to help improve the situation, since you're just as involved in this as the rest of us (you're certainly paid just as much to work on Django as me, for example). > but I haven't really researched it. Maintaining two copies of everything certainly adds to the workload. I feel like a broken record here a bit, but pragmatism is a very important part of software maintenance, even in the Open Source world. As long as we're aware (and we are) of the trade-offs, it's sometimes deemed acceptable. Whilst I fully appreciate it can be frustrating for some people to not see the big green tick of "HTML validity", it's also important for the same people to see the bigger picture, which is why I take the time to reply in these types of threads. There's no functionality loss with the current choices, which is significant in drivintg the priorities of those us donating time to work on general stuff that doesn't scratch any of our own itches. If you want things to be better, contribute and come up with a solution that adds minimal (preferably zero) overhead to the maintainability. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
Malcolm Tredinnick wrote: >In HTML, the requirement for errors of this form ( instead of >), is that the parser *must* recover in a way that forces it to >treat it as "" -- it has to ignore the invalid characters and >recover in a particular, well-defined fashion. Do you have a reference for that? It is my understanding that there is, indeed, a well-defined meaning the SGML specification for HTML: the slash inside a tag introduces a so-called "shorttag". This treats everything up until the next slash as the element's contents. Browsers don't treat it as such, but that is a deviation of what the standard asks them to do, not error recovery per se. >That's why non-validity for HTML, when it's this kind of non-validity >isn't a really big deal. It's cosmetic, rather than tragic. I disagree. When I develop web pages (using Django or otherwise) I use the Firefox HTML validator extension. This helps me write standards-compliant HTML -- a big red cross indicates a problem in my page. It is annoying if that big red cross no longer indicates anything (there might be problems *I* caused, or it might just be Django stuff). As a result, I decided to switch to XHTML when developing with Django -- also not fully standards compliant (the doctype is wrong), but at least when I see a big red cross I know *I* did something wrong... Before I decided to switch and stop worrying about it, I also wondered why Django didn't make this configurable. It didn't seem like a lot of work, but I haven't really researched it. Gertjan. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
On Mon, 2009-01-26 at 10:35 -0800, Ty wrote: > Thanks for the link. > I'm supprised there nothing "built-in" to allow this. Django's > essentally pushing you to use XHTML over HTML. > > Not really a big deal though, I suppose. Precisely. In XHTML, validity errors must be handled by not parsing the remainder of the page, and hence, not rendering (XML's required error handling technique). In HTML, the requirement for errors of this form ( instead of ), is that the parser *must* recover in a way that forces it to treat it as "" -- it has to ignore the invalid characters and recover in a particular, well-defined fashion. That's a requirement of the SGML specification (on which HTML is based). So HTML parsers interpret what Django produces correctly, even though it isn't strictly valid. That's why non-validity for HTML, when it's this kind of non-validity isn't a really big deal. It's cosmetic, rather than tragic. It's also why the django-html project exists and why, maybe, one day, such an option will exist in Django. But the right API and how much parallel maintenance it will require is, as yet, highly unclear. So an external project or two experimenting with the possibilities is absolutely the right way to go about things. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
Thanks for the link.
I'm supprised there nothing "built-in" to allow this. Django's
essentally pushing you to use XHTML over HTML.
Not really a big deal though, I suppose. I'm just starting the project
out so it won't take much to convert the whole page to XHTML. I'll
probably just go that route.
On Jan 26, 1:28 pm, "Eduardo O. Padoan"
wrote:
> On Mon, Jan 26, 2009 at 4:23 PM, Ty wrote:
>
> > I write HTML 4.01 strict documents and I'm using the django.forms form-
> > handling library.
>
> > Currently when printing input fields on the template, the output
> > includes the ending slash: "".
>
> > Is there any way, other then manually writing the input field to the
> > template, to get these variables to output in an HTML 4.01 strict
> > compliance mode?
>
> Django-html[1] provides a {% doctype %} and a {% field %} tag. You
> declare your doctype and the field output will be always correct.
>
> [1]http://code.google.com/p/django-html/
>
> --
> Eduardo de Oliveira Padoanhttp://djangopeople.net/edcrypt/
> "Distrust those in whom the desire to punish is strong." -- Goethe,
> Nietzsche, Dostoevsky
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Django Forms in HTML 4.01 Strict
On Mon, Jan 26, 2009 at 4:23 PM, Ty wrote:
>
> I write HTML 4.01 strict documents and I'm using the django.forms form-
> handling library.
>
> Currently when printing input fields on the template, the output
> includes the ending slash: "".
>
> Is there any way, other then manually writing the input field to the
> template, to get these variables to output in an HTML 4.01 strict
> compliance mode?
Django-html[1] provides a {% doctype %} and a {% field %} tag. You
declare your doctype and the field output will be always correct.
[1] http://code.google.com/p/django-html/
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
"Distrust those in whom the desire to punish is strong." -- Goethe,
Nietzsche, Dostoevsky
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Django Forms in HTML 4.01 Strict
I write HTML 4.01 strict documents and I'm using the django.forms form- handling library. Currently when printing input fields on the template, the output includes the ending slash: "". Is there any way, other then manually writing the input field to the template, to get these variables to output in an HTML 4.01 strict compliance mode? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
