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 <br>). 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 "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 -~----------~----~----~----~------~----~------~--~---
