Are they allowed? and do they work with all browsers?
Example:
<div role = "region"
id = "some-id"
class = "a-class another-class">
Yes, any amount of whitespace is allowed and will work in all browsers.
From the Attributes section of the HTML5 living standard on unquoted, single-, and double-quoted attribute value syntax:
The attribute name, followed by zero or more ASCII whitespace, followed by a single U+003D EQUALS SIGN character, followed by zero or more ASCII whitespace, [...]
One consideration - this will add to the page size, so if bandwidth and performance are concerns, try to limit the amount of whitespace you use.
Yes they are, and they will work in all major browsers, although I would say it should be considered bad practice to include unnecessary white-space as it pointlessly increases the size of the document.
HTML, XHTML, XML and others are all variants of SGML, so if you want to know what is/isn't allowed in general, have a look at that specification. You should always pass all your documents through the W3C markup validators to ensure they are valid.
Yes, it is perfectly valid markup. Whitespace is handled nicely by all browsers.
Any time you have confusion, you can validate your code at official W3 validation service:
http://validator.w3.org/
Related
How long is too long for an attribute value in HTML?
I'm using HTML5 style data attributes (data-foo="bar") in a new application, and in one place it would be really handy to store a fair whack of data (upwards of 100 characters). While I suspect that this amount is fine, it raises the question of how much is too much?
HTML5 has no limits on the length of attribute values.
As the spec says, "This version of HTML thus returns to a non-SGML basis."
Later on, when describing how to parse HTML5, the following passage appears (emphasis added):
The algorithm described below places
no limit on the depth of the DOM tree
generated, or on the length of tag
names, attribute names, attribute
values, text nodes, etc. While
implementors are encouraged to avoid
arbitrary limits, it is recognized
that practical concerns will likely
force user agents to impose nesting
depth constraints.
Therefore, (theoretically) there is no limit to the length/size of HTML5 attributes.
See revision history for original answer covering HTML4.
I've just written a test (Note! see update below) which puts a string of length 10 million into an attribute and then retrieves it again, and it works fine (Firefox 3.5.2 & Internet Explorer 7)
50 million makes the browser hang with the "This script is taking a long time to complete" message.
Update: I've fixed the script: it previously set the innerHTML to a long string and now it's setting a data attribute. https://output.jsbin.com/wikulamuni It works for me with a length of 100 million. YMMV.
el.setAttribute('data-test', <<a really long string>>)
I really don't think there is any limit. I know now you can do
<a onclick=" //...insert 100KB of javascript code here">
and it works fine. Albeit a little unreadable.
From HTML5 syntax doc
9.1.2.3 Attributes
Attributes for an element are
expressed inside the element's start
tag.
Attributes have a name and a value.
Attribute names must consist of one or
more characters other than the space
characters, U+0000 NULL, U+0022
QUOTATION MARK ("), U+0027 APOSTROPHE
('), U+003E GREATER-THAN SIGN (>),
U+002F SOLIDUS (/), and U+003D EQUALS
SIGN (=) characters, the control
characters, and any characters that
are not defined by Unicode. In the
HTML syntax, attribute names may be
written with any mix of lower- and
uppercase letters that are an ASCII
case-insensitive match for the
attribute's name.
Attribute values are a mixture of text
and character references, except with
the additional restriction that the
text cannot contain an ambiguous
ampersand.
Attributes can be specified in four
different ways:
Empty attribute syntax
Unquoted attribute value syntax
Single-quoted attribute value syntax
Double-quoted attribute value syntax
Here there hasn't mentioned a limit on the size of the attribute value. So I think there should be none.
You can also validate your document against the
HTML5 Validator(Highly Experimental)
I've never heard of any limit on the length of attributes.
In the HTML 4.01 specifications, in the section on Attributes there is nothing that mention any limitation on this.
Same in the HTML 4.01 DTD -- in fact, as far as I know, DTD don't allow you to specify a length to attributes.
If there is nothing about that in HTML 4, I don't imagine anything like that would appear for HTML 5 -- and I actually don't see any length limitation in the 9.1.2.3 Attributes section for HTML 5 either.
Tested recently in Edge (Version 81.0.416.58 (64 bits)), and data-attributes seem to have a limit of 64k.
From http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data:
Every HTML element may have any number of custom data attributes specified, with any value.
That which is used to parse/process these data-* attribute values will have
limitations.
Turns out the data-attributes and values are placed in a DOMStringMap object.
This has no inherent limits.
From http://dev.w3.org/html5/spec/Overview.html#domstringmap:
Note: The DOMStringMap interface definition here is only intended for JavaScript
environments. Other language bindings will need to define how DOMStringMap is to be
implemented for those languages
DOMStringMap is an interface with a getter, setter, greator and deleter.
The setter has two parameters of type DOMString, name and value.
The value is of type DOMString that is is mapped directly to a JavaScript String.
From https://bytes.com/topic/javascript/answers/92088-max-allowed-length-javascript-string:
The maximum length of a JavaScript String is implementation specific.
The SGML Defines attributes with a limit set of 65k characters, seen here:
http://www.highdots.com/forums/html/length-html-attribute-175546.html
Although for what you are doing, you should be fine.
As for the upper limits, I have seen jQuery use data attributes hold a few k of data personally as well.
I'd like to remove more unnecessary bytes from my output, and it seems it's acceptable (in practice) to strip what can add up to quite a lot of whitespace from HTML markup by omitting/collapsing the gaps between DOM element attributes.
Although I've tested and researched (a little in both cases), I'm wondering how safe it would be?
I tested in Chrome (43.0.2357.65 m), IE (11.0.9600.17801), FF (38.0.1) and Safari (5.1.7 (blah-di-blah)) and they didn't seem to mind, and couldn't find anything specific in The Specs about whitespace between attributes.
w3.org's Validator complains, which is a strong indication that this is not safe and shouldn't be expected to work, but (there's always a "but") it's possible the requirement for a space is only strict when no quotes are present (for obvious reasons).
Also (snippy but poignant): their SSL is "out of date" which doesn't inspire confidence in their opinion.
I noted also that someone's HTML compressor could (when enabled) strip quotes around attribute values where those values had no whitespace within them (e.g. id), which implies that at least most if not all HTML parsing is focussed on the text either side of the equals signs (except with booleans of course), and where quotes are in use, they'd be considered the prioritized delimiter.
So, would:
<!DOCTYPE html><html><body>
Yabba Dabba Doo!
</body></html>
▲ that ever go wrong, and if so, under which conditions?
What other reasons could there be to maintain this whitespace in production output (code "readability" is a non issue in this case)?
Update (since finding an answer):
Although I basically answered my own question insofar that there is a specification governing whether there should be a space between attributes, I still wonder if omitting them when using quoted values can be considered practically safe, and would appreciate feedback on this point.
Considering how often spaces may be omitted by accident in production HTML, and that the browsers I tested don't seem to mind when they are, I assume it would be very rare if ever that a browser failed to handle documents with these spaces omitted.
Although it's sensible to follow the specs in pretty much all situations, might this be one time cheating a bit could be acceptable?
After all - if we can magically save several hundred bytes without affecting the quality of the output, why not?
There is a specification (after all)
It turns out I should have looked harder. My bad.
According to these specs:
If an attribute using the empty attribute syntax is to be followed by another attribute, then there must be a space character separating the two.
and
If an attribute using the unquoted attribute syntax is to be followed by another attribute or by the optional U+002F SOLIDUS character (/) allowed in step 6 of the start tag syntax above, then there must be a space character separating the two.
and
If an attribute using the single-quoted attribute syntax is to be followed by another attribute, then there must be a space character separating the two.
and
If an attribute using the double-quoted attribute syntax is to be followed by another attribute, then there must be a space character separating the two.
Which unless I am mistaken (again), means there must always be spaces between attributes.
You could try online HTML minifiers like http://www.whak.ca/minify/HTML.htm or http://www.scriptcompress.com/minify-HTML.htm (search google for more) and find little things they change for hints to what can be taken out yet still render the HTML code.
On the first link your code:
<!DOCTYPE html><html><body>
Yabba Dabba Doo!
</body></html>
Turns into:
<!DOCTYPE html><html><body>Yabba Dabba Doo!
saving you 18 bytes already...
I know that technically HTML5 is a 'living spec' but I'm wondering if it's compliant to have trailing spaces inside of a class name. I didn't see any reference to this scenario in the spec, but one of my teammates said it was invalid. Maybe I missed something?
It'd be a pain to trim those spaces (I'm working inside of a large Java ecom application) and I want to know if it's worth doing for SEO, validation or any other purpose. I get the feeling it's not... haha
Yes, it is compliant.
From
http://www.w3.org/html/wg/drafts/html/master/dom.html#classes:
The attribute, if specified, must have a value that is a set of space-separated tokens representing the various classes that the element belongs to.
From
http://www.w3.org/html/wg/drafts/html/master/infrastructure.html#set-of-space-separated-tokens:
A string containing a set of space-separated tokens may have leading or trailing space characters.
As we can see in the link below, there is no restriction on what the developer can use in the class attribute.
http://www.w3.org/html/wg/drafts/html/master/dom.html#classes
In fact, after saying what the classes are and that they're used spliting in the spaces, the author(s) says:
There are no additional restrictions on the tokens authors can use in
the class attribute, but authors are encouraged to use values that
describe the nature of the content, rather than values that describe
the desired presentation of the content.
Our colleagues here have tested and it successfully passes W3C validation, so I can't guess why your friend thought it was invalid.
According to http://validator.w3.org/ under a <!DOCTYPE html> the following validates successfully.
<div class=" name1 name2 "></div>
Leaving a trailing and leading space may be acceptable, but it's not pretty and some people do not consider it to be best a practice.
Anything that knows how to handle class attributes should be fine with this. It is possible to give a tag multiple classes by separating them with spaces so anything which reads them had better know how to deal with spaces.
i have been working with HTML for some time, recently a question popped in my mind that when ever give tags
<input type = "text" name="c-id" />
<input type =text name=c-id />
with or without quotes there is no difference, when working with V-Studio, this IDE doesn't put quotes automatically, but while working with the Dreamweaver if i remember correctly it does put the quotes automatically...
what i want is to know is that at what point\s the absence of quotes makes a difference or creates a problem, and what is the best practice, always go quoted or quotes-less...
p.s. there is very good chance this question has been asked before but didn't show up in the search
It makes a difference when the attribute value contains a space, linefeed, formfeed, or tab character, because the attribute value will end at any one of those characters if the value is not wrapped in quotes.
From an IDE point of view, it's little more than a matter of preference whether to add the quotes or not when the attribute value does not contain one of those whitespace characters.
In XHTML syntax, the quotation marks are always required (but you can alternatively use single quotes, i.e. 'apostrophes'). This does not matter if the page is served with text/html content type, as it almost always is: browsers will parse it as sloppy HTML, not as real XHTML. But if the page is served with an XML content type, or if it is opened in a program that expects XHTML or other XML, then lack of quotation marks causes Draconian error processing: only an error message is shown, not the content at all.
In the example case, XHTML syntax is used otherwise: the “/” before closing “>” belongs to XHTML, not HTML. It makes little point to write XHTML in that respect but not consistently.
In HTML syntax, the formal rules depend on HTML version. HTML5 is much more permissive than HTML 4.01. For example, <a href=/foo/bar/ title=What???> is valid HTML5 but not valid HTML 4.01. This mostly matters in validation and depend on which version of HTML you wish to validate against (i.e., which one do you mostly try to comply with). In this issue, HTML5 reflects browser practices: browsers have long been more permissive than HTML 4.01.
By HTML5 rules, the quotes (though always allowed) are needed only when the attribute value contains any of the following characters: space, tab, line feed, form feed, carriage return, quotation mark ("), apostrophe ('), equals sign (=), less-than sign (<), greater-than sign (>), or grave (`), or is empty.
There are also opinions as well as coding style guides and other recommendations on the matter. Most people who think about such issues apparently favor the “safe” way of always putting quotes around attribute values. Some people think the quotes improve readability of code; others think they reduce it.
Not putting your values into quotes may cause some problems, ie you can't provide multiple css classes for your elements. Browser will only understand the first value, and the page won't pass validation.
You should always put your values into quotes. The markup is easier to read and you won't run into some unexpected browser behaviour.
For me, any practice that improves code/markup (re-)readability is worth making a habit, and having quotes on the attribute values visibly separates one property from another (readability again).
On the technical side, some attribute values have spaces and the whole tag might not work without the quotes on these. Those that come to mind: img's alt, multiple class values, title (for tooltips), an href with a url that has the equal sign (without quotes, the first equal in href= is doomed), etc.
And here is the almost same question in SO.
--
My thanks to Alohci for enlightening me. I can't up vote yet.
How long is too long for an attribute value in HTML?
I'm using HTML5 style data attributes (data-foo="bar") in a new application, and in one place it would be really handy to store a fair whack of data (upwards of 100 characters). While I suspect that this amount is fine, it raises the question of how much is too much?
HTML5 has no limits on the length of attribute values.
As the spec says, "This version of HTML thus returns to a non-SGML basis."
Later on, when describing how to parse HTML5, the following passage appears (emphasis added):
The algorithm described below places
no limit on the depth of the DOM tree
generated, or on the length of tag
names, attribute names, attribute
values, text nodes, etc. While
implementors are encouraged to avoid
arbitrary limits, it is recognized
that practical concerns will likely
force user agents to impose nesting
depth constraints.
Therefore, (theoretically) there is no limit to the length/size of HTML5 attributes.
See revision history for original answer covering HTML4.
I've just written a test (Note! see update below) which puts a string of length 10 million into an attribute and then retrieves it again, and it works fine (Firefox 3.5.2 & Internet Explorer 7)
50 million makes the browser hang with the "This script is taking a long time to complete" message.
Update: I've fixed the script: it previously set the innerHTML to a long string and now it's setting a data attribute. https://output.jsbin.com/wikulamuni It works for me with a length of 100 million. YMMV.
el.setAttribute('data-test', <<a really long string>>)
I really don't think there is any limit. I know now you can do
<a onclick=" //...insert 100KB of javascript code here">
and it works fine. Albeit a little unreadable.
From HTML5 syntax doc
9.1.2.3 Attributes
Attributes for an element are
expressed inside the element's start
tag.
Attributes have a name and a value.
Attribute names must consist of one or
more characters other than the space
characters, U+0000 NULL, U+0022
QUOTATION MARK ("), U+0027 APOSTROPHE
('), U+003E GREATER-THAN SIGN (>),
U+002F SOLIDUS (/), and U+003D EQUALS
SIGN (=) characters, the control
characters, and any characters that
are not defined by Unicode. In the
HTML syntax, attribute names may be
written with any mix of lower- and
uppercase letters that are an ASCII
case-insensitive match for the
attribute's name.
Attribute values are a mixture of text
and character references, except with
the additional restriction that the
text cannot contain an ambiguous
ampersand.
Attributes can be specified in four
different ways:
Empty attribute syntax
Unquoted attribute value syntax
Single-quoted attribute value syntax
Double-quoted attribute value syntax
Here there hasn't mentioned a limit on the size of the attribute value. So I think there should be none.
You can also validate your document against the
HTML5 Validator(Highly Experimental)
I've never heard of any limit on the length of attributes.
In the HTML 4.01 specifications, in the section on Attributes there is nothing that mention any limitation on this.
Same in the HTML 4.01 DTD -- in fact, as far as I know, DTD don't allow you to specify a length to attributes.
If there is nothing about that in HTML 4, I don't imagine anything like that would appear for HTML 5 -- and I actually don't see any length limitation in the 9.1.2.3 Attributes section for HTML 5 either.
Tested recently in Edge (Version 81.0.416.58 (64 bits)), and data-attributes seem to have a limit of 64k.
From http://dev.w3.org/html5/spec/Overview.html#embedding-custom-non-visible-data:
Every HTML element may have any number of custom data attributes specified, with any value.
That which is used to parse/process these data-* attribute values will have
limitations.
Turns out the data-attributes and values are placed in a DOMStringMap object.
This has no inherent limits.
From http://dev.w3.org/html5/spec/Overview.html#domstringmap:
Note: The DOMStringMap interface definition here is only intended for JavaScript
environments. Other language bindings will need to define how DOMStringMap is to be
implemented for those languages
DOMStringMap is an interface with a getter, setter, greator and deleter.
The setter has two parameters of type DOMString, name and value.
The value is of type DOMString that is is mapped directly to a JavaScript String.
From https://bytes.com/topic/javascript/answers/92088-max-allowed-length-javascript-string:
The maximum length of a JavaScript String is implementation specific.
The SGML Defines attributes with a limit set of 65k characters, seen here:
http://www.highdots.com/forums/html/length-html-attribute-175546.html
Although for what you are doing, you should be fine.
As for the upper limits, I have seen jQuery use data attributes hold a few k of data personally as well.