W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > February 2011

[Bug 12148] I strongly believe disallowing 'true' and 'false' in boolean attributes will cause significant confusion in the future. Already, you can find respected web developers incorrectly referring to attributes as true and false. For instance: http://blog.getif

From: <bugzilla@jessica.w3.org>
Date: Mon, 21 Feb 2011 20:44:06 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Prcc2-0004tx-GH@jessica.w3.org>

--- 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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:41 UTC