- From: <bugzilla@jessica.w3.org>
- Date: Mon, 21 Feb 2011 20:19:11 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12148 --- Comment #3 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-02-21 20:19:10 UTC --- (in reply to comment #2) > Due to the way browsers work right now, there are sites specifying "false" as a value for boolean attributes and expecting the "true" behavior. Sad, but that's the web for you. I've investigated and asked around, and never found a single valid example of this. The only example, cited in the Mozilla bug thread I linked in my previous comment, was in one of Qooxdoo's feature tests. I asked the author of that test why, and he said essentially "there's no reason and it could easily be changed, and should be." I know there's plenty of fear that the exception for "false" would cause breakage, but I really haven't seen anything other than wild conjecture to support that claim. I'd love it if someone could find some real world examples to disprove my claim. I'd love to investigate just why on earth they'd do something like disabled="false" to mean disabled=true. If we can find any examples of that, I'm strongly bet those sites are doing so by mistake or misunderstanding rather than intentionally. And if the landscape of those incorrect uses is pretty small (and all accidental rather than intentional), and thus the breakage wouldn't really be as horrible as people assume it would be, I don't see why some evangelism to those sites couldn't address the problem. Of course, if someone could come up with even one solid counter-example of why blah="false" really needs to mean blah=true, then I'd give up this ghost. But so far I still contend every example that we *might* find is going to boil down to oops rather than intention. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 21 February 2011 20:19:12 UTC