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 16:45:33 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PrYtB-00012g-OH@jessica.w3.org>

Kyle Simpson <w3c@getify.myspamkiller.com> changed:

           What    |Removed                     |Added
                 CC|                            |w3c@getify.myspamkiller.com

--- Comment #1 from Kyle Simpson <w3c@getify.myspamkiller.com> 2011-02-21 16:45:33 UTC ---
> 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: 





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: 


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.

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 16:45:37 UTC

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