I just want to get the ID and at the same time the adddate.
I have this selection in my html
<select id="days" name="days" onchange="periods(this)" required>
<option>-----</option>
{% for perfume in s %}
<option value="{{perfume.id}}" value="{{perfume.adddate}}" data-days="{{perfume.adddate}}">{{perfume.product}} - {{perfume.adddate}} Days </option>
{% endfor %}
</select>
In HTML you cannot have multiple values on option elements.
As the spec says:
The value content attribute provides a value for element. The value of an option element is the value of the value content attribute, if there is one, or, if there is not, the value of the element’s text IDL attribute (which may be the empty string).
If we can set multiple values that would lead to ambiguous behaviour.
You can try to create a string which contains perfume.id and perfume.addate joined by some special character and use this string as a value. Then you will just split it and will have both id and addate. However, you will need to carefully pick a special character, that would not be included in any the id or addate value, because your splitting will not work correctly otherwise.
Related
I am accustomed to seeing key value pairs inside HTML tags like so
<div class="someclass" data="somedata"></div>
But I came across an HTML element with a single string (which appears to not be part of a key value pair), of the form
<div randomstring class="someclass" data="somedata"></div>
What is this random string that is not a key/value pair?
Reproducible Example
Please see the following element from this page source
<div data-datacamp-exercise data-encoded="true" data-height="300">
Note
The reason for my interest is I am trying to get the xpath to access an HTML element identified by that string
The string is likely a Boolean Attribute:
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.
disabled is a good example.
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").
I noticed that some elements have attributes which are boolean. I wonder why the values are not true or false? or 1 and 0? Are there any reason behind why they are like this?
<option selected="selected">Ham Burger</option>
or
<input type="button" disabled="disabled" />
Thanks in advance!
In SGML, an attribute may be minimized so that its value alone is short for both the name and the value, with the only possible value for the attribute in this case obviously being the attribute's own name. HTML uses this for boolean attributes, where the presence or absence of the attribute is what's meaningful, and its value is irrelevant. But in XML, minimized attributes were disallowed, so we wound up with the awkwardness that is selected="selected" when XHTML came into vogue. If you're writing HTML rather than XHTML, you can just write selected.
The exact definition is:
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".
Also:
Boolean attributes may legally take a single value: the name of the attribute itself [...] In HTML, boolean attributes may appear in minimized form
Basically, this implies that there are only two possible statuses for boolean attributes, true and false, but there isn't a not set status.
For the disabled attribute I think it's the presence of the attribute that disables the element regardless of its value.
It guess one of the reasons could be to allow more values than just yes/no in the future. For instance, instead of visible=true/false, you can have visibility=visible/hidden/collapsed
the HTML standard (Not the XHTML) is to have simply selected instead of selected="selected"
See here: http://www.w3.org/TR/html4/interact/forms.html#adef-selected
When XHTML was created to allow a a better integration with XML in HTML, (see http://www.w3.org/MarkUp/2004/xhtml-faq#need), the parts that do not fit to the XML-like structure requirements of HTML were corrected. So wordings like selected got transformed into selected="selected" to fit the standard
Readability, a lot of HTML is not coded by people with computer science backgrounds so the concept of "Boolean" would be foreign to them in those terms. Also it improves readability for Computer Science and other technical users by providing reinforced clues as to the function of a given statement.
As vc74 has said, it doesn't matter what value you have for selected or disabled.
<option selected="selected">Ham Burger</option>
will do the same as
<option selected="sjkhdaskj">Ham Burger</option>
i think this is just for ease to user to specify the attribute value in most human readable form if he/she dont know what is true/false
<html>
<body>
<select>
<option>1</option>
<option selected="blah">2</option>
<option >3</option>
</select>
</body>
you see in above code i have not use selected=selected, i used what i want it still select the option value, or you can simply use <option selected>2<option>.
I was just wondering what valid characters can be included as the value for a <option>
i.e. is this valid?
<select>
<option value='0dbl,2sgl'>0 Double and 2 Singles</option>
<option value='1dbl,0sgl'>1 Double and 0 Singles</option>
</select>
Yes, that's perfectly valid. See the specification: it says the content of value should be CDATA, in which pretty much everything is valid, with the following caveats:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
For HTML4:
OPTION Attribute definitions
selected [CI]
When set, this boolean attribute specifies that this option is pre-selected.
value = cdata [CS]
This attribute specifies the initial value of the control. If this attribute is not set, the initial value is set to the contents of the OPTION element.
label = text [CS]
This attribute allows authors to specify a shorter label for an option than the content of the OPTION element. When specified, user agents should use the value of this attribute rather than the content of the OPTION element as the option label.
Source: http://www.w3.org/TR/html401/interact/forms.html#h-17.6
So we go to the definition of CDATA:
CDATA is a sequence of characters from
the document character set and may
include character entities. User
agents should interpret attribute
values as follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and trailing white space in CDATA attribute values (e.g., " myval " may be interpreted as "myval"). Authors should not declare attribute values with leading or trailing white space.
For some HTML 4 attributes with CDATA
attribute values, the specification
imposes further constraints on the set
of legal values for the attribute that
may not be expressed by the DTD.
Source: http://www.w3.org/TR/html401/types.html#type-cdata
As there is no constraint noted, the valid content of value must have properly escaped entities, properly defined entities, and be within the scope of the document's encoding.
I want to know what is good practice for select option values.
Example
<select name="select">
<option value="0-9">Sample</option>
<option value="a-z">Sample</option>
<option value="this is sample value">Sample</option>
<option value="this-is-sample-value">Sample</option>
<option value="this_is_sample_value">Sample</option>
<option value="this & is | sample ** value">Sample</option>
</select>
I'm a little bit confused here. Is the select value same like input text and textarea
There are no limits real to the type of data that can be set in the value attribute of the option element. Characters with special meaning in HTML do, of course, need to be represented by the appropriate entities (& as & for example (although the one in the question meets the "followed by a space character" exception to the rule)).
The attribute is defined as containing CDATA:
<!ELEMENT OPTION - O (#PCDATA) -- selectable choice -->
<!ATTLIST OPTION
%attrs; -- %coreattrs, %i18n, %events --
selected (selected) #IMPLIED
disabled (disabled) #IMPLIED -- unavailable in this context --
label %Text; #IMPLIED -- for use in hierarchical menus --
value CDATA #IMPLIED -- defaults to element content --
>
— http://www.w3.org/TR/html4/interact/forms.html#h-17.6
CDATA is a sequence of characters from
the document character set and may
include character entities. User
agents should interpret attribute
values as follows:
Replace character entities with characters,
Ignore line feeds,
Replace each carriage return or tab with a single space.
User agents may ignore leading and
trailing white space in CDATA
attribute values (e.g., " myval "
may be interpreted as "myval").
Authors should not declare attribute
values with leading or trailing white
space.
For some HTML 4 attributes with CDATA
attribute values, the specification
imposes further constraints on the set
of legal values for the attribute that
may not be expressed by the DTD.
— http://www.w3.org/TR/html4/types.html#type-cdata
The specification doesn't impose additional limits for the option element's value attribute.
Same as a text-type input -- it can be string, float, etc. This is more a question of which is most reliable to parse when you process the form data.
The posted value will be the one corresponding to the selection.
In that regards, it is treated the same way as an input type text is.
Yes, it is a string type, and could have any value. The value goes when you submit a form, and there are limitations.
The limitations depends which technology you are using on server end.
As in case of ASP.Net when you try to post special characters like & or especially < script > some script < / script > or the similar characters which are part of html tags or could be a dangerous script. The asp.net checks the posted data and throws exception. means some special characters are not allowed in value of select box with regards to asp.net
However the samples you given (except of having & it should be prefixed by amp;) are allowed and could be set in option tag value attribute.
Hope your understanding are build.