Setting false value vs. removing an attribute - html

I was reading something about boolean attribute here, which says that for a boolean attribute (in this particular example, loop attribute of <audio>), whatever value you set, it is going to be recognized as "true". In order to really set to falsy, you cannot set it like loop=false or with javascript as ['loop']=false, but have to remove the attribute such as by doing removeAttribute('loop'). Is this true?
I first believed it, but as far as checked it with Chrome, it seems that setting to ['loop']=false will actually do make it be recognized as falsy. I am not sure how robust this fact is when considered cross-browserly. Is there any difference among browsers?

Boolean attributes are explained here:
http://www.w3.org/TR/html4/intro/sgmltut.html#h-3.3.4.2
Some attributes play the role of boolean variables (e.g., the selected
attribute for the OPTION element). Their appearance in the start tag
of an element implies that the value of the attribute is "true". Their
absence implies a value of "false".
Boolean attributes may legally take a single value: the name of the
attribute itself (e.g., selected="selected").
So, while some browsers may interpret the string "false" as if the value was not set, others may not decide to (which is the correct behavior). Actually, as far as I know (or thought), any non-empty string usually sets the value to on/true (regardless of what the spec says is a legal value). I believe this is also undefined behavior, so this may change as well or be different from browser to browser (don't rely on it).
The bottom line is, just because a browser or two may deviate from the spec doesn't mean that you should. Removing the attribute entirely is the way to go.
Addendum: Looking at your comments and question a little closer, I think you may be confused about attribute values in general. In HTML, attr=false and attr="false" are exactly the same. Quotes are not required in any version of HTML (unless they are needed to remove ambiguity when the value contains spaces). For instance:
<input class=required>
<!-- This is fine -->
<input class=title required>
<!-- this is fine too, but "required" will be parsed as an attribute -->
<input class="title required">
<!-- To have two classes, we need the quotes -->
All attribute values (on elements that have them) are treated as strings. In other words, there is no such thing as a true boolean value (or NULL value) in HTML like there is in javascript.

Just so anyone who needs this in the future:
loop=false remains true unless the entire loop attribute is removed. Basically, the presence of just loop is what a tag needs to do something else. You need to use something like jQuery to remove the entier loop attribute (or at least that's what I would do). Now, if you set a different undefined attribute to false, then you are able to recognize it as false.

The audio element is an HTML5 element, so regarding its meaning, you should consult the HTML5 drafts. In this case, see the definition of boolean attributes in the developer version of the WHATWG draft. It says, in effect, a) that the presence or absence of the attribute determines whether the DOM attribute value is true or false, and b) as a requirement on documents, the value must be empty or (case-insensitively) the attribute name, in this case loop='' or loop="loop". The use of quotation marks around the value are defined elsewhere.
Thus, browsers are required to recognize loop=false to mean the same as loop=loop or loop=true, but authors must not use such constructs, and HTML5 checkers issue error messages about them.
(Basically, you’re supposed to use just loop in HTML serialization of HTML5 and loop="loop" in XHTML serialization.)
Thus, if you have a variable x in JavaScript with an audio element object as its value, x.loop has the value true or false whereas x.attributes['loop'].value indicates the value used in HTML markup (which is usually not interesting as such).
There’s a further complication as regards to Firefox: it still does not seem to support the loop attribute (see the question HTML5 Audio Looping). This means that if you set e.g. loop="loop", x.attributes['loop'].value will be loop but Firefox does not even set x.loop (i.e., it is undefined), still less implement the functionality.

You're confusing strings and real Boolean types. Javascript has a Boolean datatype with two possible values of true and false (without quotes). Strings can contain any text, so can they contain "true" and "false" with quotes. Setting a property to non-null and non-false yields true, so the following will accour:
var a = true; // true
var b = false; // false
var c = "true"; // true
var d = "false" // true
var e = null; // false;
var f = 0; // false
var g = 1; // true
Note the similarities with C.

Related

W3 and WCAG requirements collide on attributes disallowed to be false

According to W3, we should not use false but rather omit the attribute all together. Also, according to W3, when toggling parts of the accordion, the aria-expanded is toggled between true and false.
To me, it sounds as a oxymoron and I'd like to get a pointer on how to design the control according to both the W3 guidelines and to WCAG requirements.
One approach is to declare that aria-anything is excluded from the true or nothing paradigm. Another one would be perahps setting an attribute such as folded and expanded with no value, simply knowing that the one is negation of the other.
Is any of them accpetable and embraces both W3 and WCAG? Are there alternative best-practice approaches?
A Boolean attribute is a specific "microsyntax" in HTML. As you noted, there are certain rules around their usage:
If the attribute is present, its value must either be the empty string or a value that is an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace.
There are only certain attributes which use this microsyntax. These can be found in the HTML 5 specification in the Attribute index, where the Value column notes that it is a "Boolean attribute". Commonly used examples are disabled, readonly and async.
The aria-expanded attribute, while it accepts true and false, is not defined as conforming to the Boolean attribute microsyntax. It is defined under a different specification than HTML 5, the Accessible Rich Internet Applications (WAI-ARIA) specification. It is actually referred to as a state in that specification, not an attribute, and can have the value true, false, or undefined.

Why is the "true" boolean value the "wrong attribute value"?

I have the following button:
<button id="=" style=width:150px;height:150px;font-size:100px; onclick="equalFunction()" disabled="true">=</button>
however in the disabled="true" my IDE recognizes the "true" value to be the "wrong attribut value" does anyone know how to solve this? The code still works, its just annoying to see it be highlighted.
You don't need to set it to true. Do something like this:
<button id="=" style=width:150px;height:150px;font-size:100px; onclick="equalFunction()" disabled>=</button>
According to the HTML5 spec:
A number of attributes in HTML5 are boolean attributes. The presence
of a boolean attribute on an element represents the true value, and
the absence of the attribute represents the false value.
If the attribute is present, its value must either be the empty string
or a value that is a case-insensitive match for the attribute's
canonical name, with no leading or trailing whitespace.
So with a boolean attribute like disabled, it's presence alone is enough and it needs no value, although virtually every web browser will still accept it. Therefore, you should use either disabled (alone) or disabled="disabled"

Is it safe (cross-browser) to omit the value of the contenteditable attribute?

According to W3C spec...
The contenteditable attribute is an enumerated attribute whose keywords are the empty string, true, and false. The empty string and the true keyword map to the true state.
All of the examples and documentation I've found represent the "empty string" as follows:
<div contenteditable="">...</div>
I'm wondering if the following is equally valid (cross-browser) for the sake of cleaner, briefer code:
<div contenteditable>...</div>
It works just fine - at least on current versions of Firefox and Chrome. I'm just wondering if it's valid and reliable cross-browser. My thinking is that it's comparable to form attributes like readonly, disabled, selected, etc - which are commonly and reliably used without assigning a value.
SOLUTION:
Marc B pointed out the following from the W3C spec:
Note that empty attribute syntax is exactly equivalent to specifying the empty string as the value for the attribute.
...which basically confirms the interchangeability of absent and empty values for boolean attributes/properties, meaning both code snippets above are valid and (should be) treated identically across browsers. Thanks to all who answered!
As per the W3C specs:
In the following example, the disabled attribute is given with the empty attribute syntax:
<input disabled>
Note that empty attribute syntax is exactly equivalent to specifying the empty string as the value for the attribute, as in the following example.
<input disabled="">
Now, that's what the W3C says, and then there's what the browser makes read. You can be sure that Internet Explorer will translate/read that as "argle bargle screw the specs woofle" and do its own thing, probably treating "disabled" as "do_the_stupidest_possible_thing_repeatedly=true".
According to WHATWG leaving out the value should lead to inherit, and not true as the empty string does. Being different values, I would say it is not safe.
But if you want clear code, why not write true, since you need to ask this question you can't even read your own code. And I had to look up both what "" does and the missing value default for the attribute, that is not what I would call clear.
Here's a helpful link from Mozilla that should accurately answer your question.
Extract:
According to MDN the contentEditable property when set to true, or an empty string, indicates that the element is editable. Because the contentEditable attribute is enumerated and not Boolean if you leave off the value it is inherited from the parent element.
This is supported back to IE6, Chrome 11, Firefox 3.0 (Gecko 1.9), Opera 10.6, and Safari 3.2.

are attributes without value allowed in HTML4?

I wonder if HTML 4 allows attributes without value, as being equivalent to attributes with an empty value. For example:
<h2 section>foobar</h2>
instead of:<h2 section="">foobar</h2>
Are the two snippets equally valid? If not, are they valid in HTML version 5?
thanks!
Boolean Attributes, Yes they are completely valid.
From W3C: (On SGML & HTML)
Some attributes play the role of boolean variables (e.g., the selected
attribute for the OPTION element). Their appearance in the start tag
of an element implies that the value of the attribute is "true". Their
absence implies a value of "false".
Boolean attributes may legally take a single value: the name of the
attribute itself (e.g., selected="selected").
This states that Boolean attributes are valid in HTML4 as well, but if you use something like, would be invalid.. because that boolean belongs to option tag.. Thanks to #Ronni Skansing for clarifying the doubt..
<p selected>Hello</p>
HTML5 Docs :
From W3C :
Empty Attribute Syntax
Certain attributes may be specified by providing just the attribute
name, with no value.
From W3C: (HTML 5.1 Nightly )
A number of attributes are boolean attributes. The presence of a
boolean attribute on an element represents the true value, and the
absence of the attribute represents the false value.
BUT
section is an invalid attribute, if you want to define your own attributes, HTML5 provides a way to do that.. you need to use data- prefix, for example, your section should be written as data-section, this way your attribute will be counted as valid.
If you hesitate to do so, we always have a validator to check - W3C Markup Validation Service
^ Validated As HTML5
NOTE: Though I provided data- is applicable for HTML5, using custom
attributes in HTML4 is invalid, no matter even if you define data-
before the attribute name, but, boolean attributes are valid in HTML4
as well.
As formally defined, HTML 4 does not allow attributes without a value. What is commonly regarded as attribute without value, as in <input checked>, is formally an attribute value without an attribute name (and an equals sign). Though misleadingly characterized as “boolean attributes” with special minimization rules in HTML 4 specs, those specs normatively cite the SGML standard.
By the SGML standard, whenever an attribute is declared by enumerating keywords that are the only allowed values, an attribute specification may, under certain conditions, be minimized to the value. This means that in HTML 4, the tag <input checkbox> is valid; the attribute is a minimized form of type=checkbox. No browser supports that (they parse checkbox as attribute name), but in validators, the construct passes.
In practice, the part of the attribute minimization rules that browsers support consists of just the special cases where an attribute is declared as allowing a single keyword value only, such as the checked attribute, which is formally declared with
<!ATTLIST INPUT checked (checked) #IMPLIED>
So it depends on how the attribute is declared in the HTML 4 spec.
But this means that the minimized attribute checked means checked=checked. The value is not empty but the keyword checked. On the other hand, browsers treat such attributes as “presence attributes”: what matters is whether an element has that attribute or not, not its value.
In HTML5 serialized as XHTML (i.e., as XML), things are simple: every attribute specification must be of the form name="value" or name='value', so the equals sign is required, and so are the quotation marks; logically, the value is always there, though it can be the empty string, as in alt="".
In HTML5 serialized as HTML, some attributes are defined so that an attribute value (and an equals sign) is not required. Rather confusingly, they are the attributes declared as being “boolean attributes” (it’s confusing e.g. because the values true and false are not allowed, but the name partly reflects the principle that the corresponding DOM property, or “IDL attribute” as they call it, has the truth values true and false as the only permitted values). For such attributes, by definition, the value is even immaterial; only the presence of the attribute matters. For example, for the checked attribute, no value is used, but if a value is given, it must be either the empty string (checked="") or identical with the attribute name, case insensitively (e.g., checked=Checked). Any other value is nonconforming but is required to work, with the same meaning (e.g., checked=false means the same as checked).
Regarding the specific example, it is not valid in any version of HTML, since there is no attribute section declared.
Both snippets are syntactically valid in html4 and html5. The first is not valid xhtml, because in xhtml an attribute value is required.
On the other hand, section is not a defined attibute, but it is a valid tag in html5. Therefore your code is not valid.

Is there any difference for data-attribute=false with data-attribute="false" in html element?

I have data attribute in html element as <button data-verified=false>Update</button>. It have boolean value for data attribute.
Is there any difference with following element <button data-verified="false">Update</button> as the data-attribute is wrapped with double quotes.
Is boolean values are supported in html?
Boolean attributes are supported in HTML, but data-verified isn't one of them, no matter how it appears in the markup. data-verified=false and data-verified="false" both create an attribute of the type string and value "false", which if tested in JS as a boolean will be treated as true
This is only the case because false doesn't contain spaces. As a contrary example, data-verified=not true is invalid and not at all the same as data-verified="not true"
There are no differences in the values - however, always prefer to quote around attribute values, because:
Looks cleaner
Easier to maintain
Every editor can deal with it easily
It's a standard, nearly all HTML code examples you'll see use the value quoted
My answer corroborates from Do you quote HTML5 attributes?
I think it is just a convention that attributes always have double quotes.
However. In jQuery, you can use the .data() method. It is smart enough to recognize booleans and numeric values.
The only difference is that only the latter is allowed in XHTML. In HTML syntax, they both are allowed, and they are equivalent: the difference is lost when the HTML markup is parsed, and the DOM contains in both cases only the string false.
This follows from general principles in HTML and does not depend on the name of the attribute in any way.
“Boolean value” is a vague term. In HTML5, some attributes are called “boolean attributes”, but this is strongly misleading – especially since values true and false, far from being the only values allowed, aren’t allowed at all for such values. You need to read the specification of “boolean attributes” to see what they really are.
When you use data-* attributes, it is completely up to you what you use as values and how you process them.