[Bug 12148] New: 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

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

           Summary: 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
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: contributor@whatwg.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Specification: http://dev.w3.org/html5/spec/spec.html
Section: http://www.whatwg.org/specs/web-apps/current-work/#top

Comment:
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.getify.com/2010/12/on-script-loaders/ refers to the
script tag "async=false" (near the end).

I'd like to compare such attributes to properties in Apache Ant.  Ant
properties up until version 1.7.1, the only string allowed as "false" was the
empty string.  Nonetheless, enough people kept trying to write "false" in the
property, that 1.8.0 finally accepted the "false" as a valid negative value. 
I expect HTML5 will follow a similar, if not in the spec, perhaps in the
multiple browser implementations of the spec.

Even now, the HTML5 authors seem confused on this matter.  In the checkbox
example, it says...
   disabled
  ... could be equivalently written as ...
    disabled=disabled
   ... the following is still equivalent ...
    disabled=""
Surely the last example cannot be equivalent.

I understand some of this comes from the original guidelines of how SGML & XML
parsers interpreted a missing attribute or a valueless attribute.  We can
still recognize the those two allowed strings in the current spec, while
expanding the definition to include the human friendly variants "true" and
"false".

There is exactly one conflicting case, where the attribute is named "false". 
Not only it is outside the current spec, but its use is so inherently
confusing that we can safely assume it will never be called upon.

Please expand the definition of boolean microsyntax and all boolean attribute
to recognize the values "true" and "false" with well defined values.

Posted from: 76.168.54.24

-- 
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:29:34 UTC