> Already, you can find respected
> web developers incorrectly referring to attributes as true and false.  For
> instance: http://blog.getify.com/2010/12/on-script-loaders/ refers to the
> script tag "async=false" (near the end).

For clarification, since I'm the one who wrote that blog post... the references to "async=false" are *NOT* about `async` attribute in markup, but about the newly spec'd feature implementing my proposal for "async=false" on the dynamic script element's `async` (IDL) property.

You can read more about that proposal being adopted into the spec, here: 

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295

and

http://ln.hixie.ch/?start=1296711456&count=1

---------------

The issue with `async` aside, I've actually believed for a LONG time that the HTML specification for boolean attributes should include a special exception that if any attribute in markup is set with value "false", then clearly the author is expressing the semantic desire to disable that attribute (or treat it like that attribute isn't even present).

I believe the processing rules should have a very narrow exception that any boolean attribute with value "false", and only that value, should be interpreted exactly the same as if the attribute had not even been included.

For reference, see this discussion I had over on a Mozilla bug thread about that suggestion: 

https://bugzilla.mozilla.org/show_bug.cgi?id=620852#c13

I think if any markup author says something like

<input disabled="false" />

They are clearly indicating the intent of 

<input />

And the processing rules should interpret that as such. Just my 2 cents.

I was shot down pretty handily in that Mozilla thread, saying this change would never occur. But I think it makes more semantic sense for boolean attributes to have that exception. I can't really think of a single example where someone is setting the value in markup of a boolean attribute to the string "false" and yet still intending for that attribute to be turned on. That's completely opposite semantics and makes no sense at all to me.

> Surely the last example cannot be equivalent.

It is.  Try it in any web browser.

The behavior of boolean attributes is something HTML4 required and that has been implemented correctly by every single browser for well over a decade.  There's no way to change it without breaking sites.

> I understand some of this comes from the original guideline

Indeed.

> while expanding the definition to include the human friendly variants "true"
> and "false".

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.

> There is exactly one conflicting case, where the attribute is named "false". 

You're assuming all sites serve up validating HTML 4.  This is a bad assumption.

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

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

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

This is a bad assumption, sadly.

> I don't see why some evangelism to those sites couldn't address the problem.

Evangelism is not free.  Are you volunteering to contact all the sites involved, however many are discovered, and get them to change what they're doing?  Or is this a case of "it should be really easy for someone else to do this"?

> is going to boil down to oops rather than intention.

It doesn't matter whether it's intention or not, as long as there's enough of it.  Again, data would be good.

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

> How would you propose that this burden of proof could possibly be met?

For pure markup stuff like this, there have been a number of studies of web content out there; some done by Google using their data others done by people examining dmoz pages and whatnot.

> There was FAR less of a standard of proof necessary for the async=false
> breakage.

That was a situation where UAs disagreed and a behavior had to be chosen, no?  This is a situation where every single browser for the last 10-15 years has done something and you want to change to doing something else.  Or am I missing something here?

> Would something like that be sufficient to move the ball forward,

That would make it a lot easier to convince implementors, yes...  Whether it would be enough, I don't know (I can't even speak for Mozilla here, much less other implementors).

> I'm suggesting that this is a whole different class of problem

No.  It's really not.  The content is still there, and fixing it is just as much work.  It doesn't matter that much what the _intent_ was of it being there, and even the mechanics only matter if there are some sort of tools generating this sort of markup.

(In reply to comment #1)
> I can't really think of a single example where someone is
> setting the value in markup of a boolean attribute to the string "false" and
> yet still intending for that attribute to be turned on. That's completely
> opposite semantics and makes no sense at all to me.

The way it happens in practice is:

1) Author fiddles around with the page, not sure exactly how everything works because they're not HTML experts.

2) Author is trying different things to see what works, and sets some boolean attribute = false somewhere to see if that helps.

3) Page works, author goes on his merry way.  Author does not realize that the "foo=false" actually means the same as "foo=true" or just "foo", because he's not an HTML expert, only has a vague idea of what "foo" is supposed to do to begin with, and can't really be bothered in figuring it out now that the page works.

It should be fairly easy to search public web pages to look for boolean attributes set to false.  http://www.dotnetdotcom.org/ has a publicly-downloadable index snapshot.  Experience suggests that you'll find a nontrivial number of sites that misuse the attributes this way, but you're welcome to try.

Just to expand on the "experience suggests" part: with every new release, browser implementers all get lots of bugs filed complaining about broken pages.  They get a very good idea of what sorts of changes will result in an unacceptable level of compatibility complaints from users.  So realize that you are, in fact, probably wrong about the compatibility impact, if browser implementers think you are, since they know about this sort of thing first-hand.  But if you want to try making a case anyway, go ahead.

I agree that there's confusion, but I strongly disagree with changing the language. The language has had this confusing design pattern since HTML 2.0 and the confusing design pattern has been interoperably implemented by several generations of browsers. If we were starting from scratch, it might be a good idea to avoid this confusion, but I think now interoperable implementations should trump desire to 'fix' the language.

FWIW, this is something that running a validator helps with.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: 

I agree that the current design is poor. This is actually why I encourage the use of value-less boolean attributes (<input disabled> rather than <input disabled=something>).

However, changing it is a non-starter. It would be an absolutely huge change to the specification and to implementations — the sheer number of places that test for attribute presence that would need to change to test for attribute value is simply phenomenal. It would be a very high-risk change, since it's quite likely that there are pages that accidentally say things like checked=false but mean it to be checked. It would lead to several years of pain for millions of authors, as browsers slowly migrate from one behaviour to another. It would mean massive efforts updating HTML documentation, books, tutorials, etc, the world over.

mass-moved component to LC1

*** Bug 16805 has been marked as a duplicate of this bug. ***