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"
Related
I have a question to the sense of the html specification at:
https://www.w3.org/TR/html5/infrastructure.html#boolean-attributes
This is clear:
The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.
But why I am not allowed to use "true" or "false" as values?
The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.
Since the presence of the attribute is enough to have a "true" value I could use ANY value like "blablabla". But why not "true" and "false"? Just to avoid confusion?
Since the presence of the attribute is enough to have a "true" value I could use ANY value like "blablabla".
No. That's invalid. You can specify either the attribute name alone, or the name and the defined value (which is the same as the name).
But why not "true" and "false"?
It's a holdover from SGML.
When boolean attributes were originally implemented they used a feature which allowed you to specify only the value.
This meant less typing and smaller, more readable files.
Obviously <input type="checkbox" checked> is much easier to understand than <input type="checkbox" true>, so the value and the name is the same.
HTML 5 doesn't define itself in SGML terms, so it says that you can specify the attribute name alone rather than the value (even though they are the same) but it needs to be backwards compatible with existing HTML parsers.
I know that a boolean attribute can optionally have a value. From the HTML5 spec:
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 an ASCII case-insensitive match for the attribute's canonical name, with no leading or trailing whitespace. Note: The values "true" and "false" are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.
I suppose there is a valid historical reason that explains why a value is allowed (and only allow a case-insensitive name match)... but my question is: What are the benefits, if any, of having a value for these boolean attributes? (Or disadvantages, if any.)
For example:
<option selected="selected">...</option>
...
<input required="required" ... />
versus
<option selected>...</option>
...
<input required ... />
If you need to do XHTML for whatever reason, you'll have to do that since attributes must have values in XML.
Using an empty string is consistent with having the attribute without a value. If you set a boolean attribute to empty string then the attribute will show up as unset (without a value) in Chrome dev tools.
There are attributes in HTML that only specify a boolean value. These include multiple, disabled, selected etc.
In XHTML, due to the strict XML syntax, you must give the attributes a value. This is normally the name of the attribute.
<select multiple="multiple">
But HTML also supports just the name of the element.
<select multiple>
And, as seen here, browsers (at least Firefox) also allow for other values with the same result.
<select multiple="yes">
Which one of these is the generally used one, or is there one? What is the official recommendation?
From the spec
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.
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.
So multiple, multiple=multiple, multiple='multiple' or multiple="multiple". Nothing else (case insensitivity aside), even if browsers recover from the error.
I'd lean towards either the short (multiple) or the XML parser-friendly with the more conventional quotes (multiple="multiple").
Are the names of input tags allowed to simply be integers?
<input type="text" name="34" />
Just asking in case I were a lazy programmer. Or if I have a ton of arbitrary fields and it's not important what they are named.
Yes, the name attribute is declared as taking CNAME value, which means any string of characters, without imposing constraints. HTML5 does not change this, except by disallowing the empty string; its definition explicitly says: “Any non-empty value for name is allowed”.
People sometimes confuse the name attribute with the id attribute, upon which there are various constraints depending on HTML version (e.g., some versions forbid a value that starts with a digit).
Yes, they can. I wouldn't recommend it, but there's nothing wrong with using a number as a name attribute.
No. Using integer is valid, yet it will be converted into a string.
The content attribute is the attribute as you set it from the content (the HTML code) and you can set it or get it via element.setAttribute() or element.getAttribute(). The content attribute is always a string even when the expected value should be an integer. For example, to set an element's maxlength to 42 using the content attribute, you have to call setAttribute("maxlength", "42") on that element.
ref: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes
It's valid in HTML5, but I'd avoid it. However, your code is still not valid HTML5 because of the self-closing tag. It should be:
<input type="text" name="34">
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.