On Wed, 2009-01-28 at 14:33 +0100, Gertjan Klein wrote: > Malcolm Tredinnick wrote: > > >In HTML, the requirement for errors of this form (<input /> instead of > ><input >), is that the parser *must* recover in a way that forces it to > >treat it as "<input >" -- 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 -~----------~----~----~----~------~----~------~--~---
