- From: <bugzilla@jessica.w3.org>
- Date: Mon, 21 Feb 2011 20:44:06 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12148 --- Comment #5 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-02-21 20:44:05 UTC --- (in reply to comment #4) >> I'd love it if someone could find some real world examples > I would too; the burden of proof in this case is on those proposing backwards-incompatible changes, imo. How would you propose that this burden of proof could possibly be met? Are you suggesting that an exhaustive search of every single HTML snippet on every single site in the world is necessary to prove my claim? That's certainly not the burden of proof applied to all breaking changes. There was FAR less of a standard of proof necessary for the async=false breakage. I'm not suggesting that no burden exists... I'm just saying that leaving it open-ended like that really sets the battle up for failure before it even starts. I can't possibly prove exhaustively that no site ever does this. But we could, for instance, crawl the first HTML page of the Alexa top 100,000, to get a representative sample of if there are any examples of it present. Would something like that be sufficient to move the ball forward, or is that just spitting in the wind? >> why on earth they'd do something like disabled="false" to mean disabled=true. > You're assuming HTML authors necessarily "mean" something when they write some HTML, as opposed to trial-and-error or cargo-cult copy-paste or a bug in some CGI. No, I'm not assuming that. I'm suggesting that this is a whole different class of problem if we can rule out that there's any intentional usage of the "false" quirk in the way things are now. I'm saying that if there really is no legitimate reasoned use for that behavior, and the only cases we may find are accidental, that makes the argument for change more viable, than if someone could actually point out a valid reason for "false"!=false. > Evangelism is not free. Are you volunteering to contact all the sites involved, however many are discovered, I would absolutely volunteer the time to contact any libs or sites that may be found where this breaking change would affect them. That's not a promise that they'll all comply, but firing off an email to explain the problem and the reason for change is more than reasonable and I'm perfectly willing to do so. If the only sticking point is "who on earth will contact all those sites", I freely volunteer to be that "who". And I agree to volunteer for that because I don't think we're gonna find many sites at all. Furthermore, I think if we do find sites, they'll be very non-mainstream, so the potential risk of breakage is less impactful than say if I were proposing a change that would break Twitter (hint, see the async=false discussion). > It doesn't matter whether it's intention or not, as long as there's enough of it. Again, data would be good. It *does* matter. But it's not sufficient. You're misunderstanding my argument. I'm simply trying to narrow the playing field, by inviting anyone to suggest a counter-example or counter-argument, and if none can be found, redfining the problem to be more manageable. If we get to the point where we can agree on the premise that disabled="false" usage is silly and mis-guided, then we have a somewhat easier thing to grasp. I fully recognize the likely futility of this effort. But I think it's right, nonetheless, and I'm glad the OP brought it up, so I'm not the only one. -- 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:44:08 UTC