I am using maxlength at a textarea, and using a JS to check the number of characters left. if i try to input a simple string
i.e:
1234567890
repeatedly the maxlength works perfectly but if i try to input a string like this:
Welcome!
1. this is a test
2. this is a test
3. this is a test
hahaahahahahahahaahahahahahahahhahaahahahahahahahahahahahaaaaaaaaaaaaaasddddddddddasdaasdasdasd
it stops on 6 characters left, but on FF it works perfectly.
I was trying to do some research on how maxlength works but it was to no success, so i was wondering why is maxlength not working perfectly on chrome. could it be because of the spaces and special characters inputted?
thank you
The issue can be demonstrated using simple code like
<textarea maxlength=5 rows=2 cols=10></textarea>
On Firefox, you can then e.g. type “12”, press enter, and type “34”, and then you can’t type more. On Chrome, if you try to do the same, you cannot type any more after the “3”.
It seems that Chrome works correctly, Firefox doesn’t. The maxlength attribute for textarea is an HTML5 novelty, so the best definition for correctness is either the newest W3C HTML5 draft or the newest WHATWG HTML document, and they agree on this issue (and most other issues too).
By the W3C HTML5 definition for textarea, a line break in the value is canonicalized by the browser to CR LF (carriage return, linefeed, i.e. two control characters). So if you type “12”, press enterm, and type “3”, you have entered five characters, since the line break counts as two characters.
Spaces count as characters, and so do special characters. By the W3C HTML5 draft, some very special characters, namely characters outside Basic Multilingual Plane (BMP), are relly special: they count each as two characters, since the length is counted in 16-bit code units. But most people never used non-BMP characters.
Related
I'm trying to make an input field of 1 character, but I'm finding it's impossible to paste Emoji or use the OSX emoji picker launched by the browser.
<input maxlength='1' value='👼'>
The emoji is shown and it's possible to paste in a 3-byte Unicode like ★, but not another Emoji. It also works fine for a maxlength of 2.
Is this a browser bug or is it compliant with HTML spec? I'm seeing same on Chrome and Firefox.
Demo
This behaviour is compliant with the HTML spec. The definition of the maxlength attribute says:
Constraint validation: If an element has a maximum allowed value length, its dirty value flag is true, its value was last changed by a user edit (as opposed to a change made by a script), and the code-unit length of the element's value is greater than the element's maximum allowed value length, then the element is suffering from being too long.
(My emphasis.) As a general rule, the web platform treats strings as sequences of 16-bit code units, rather than as sequences of Unicode characters, so characters such as emoji that are outside the basic multilingual plane are treated as having length two.
The obvious workaround is to set maxlength=2 (or ditch it altogether) and do the validation in JavaScript.
Is there a HTML character that, on all (major) browsers (plus IE8 sadly) displays nothing and doesn't add any extra space?
So, an alternative to but which doesn't add whitespace to the page, and which won't ever show up as an ugly "unrecognised character" marker or ?.
Why: in my case, I'm trying to work around a problem on an old, proprietary CMS that is removing empty but necessary HTML elements that are required because other parts of the system will fill them dynamically.
Imagine something like (simplified trivial example) <span class="placeholder" data-type="username"></span> which is populated with a user's username if a user is logged in - but this old-school CMS sees it as being empty and removes it.
There seem to be two options that mostly fit the bill. They seem to reliably not show anything when in a <span>, but they (particularly the second option) might have a minor effect on copy/paste and word breaking in some cases.
Zero-width space
aka which behaves the same as the (now in HTML5) <wbr> - used to make words break at certain points without changing the display of the words.
<h1>This text is full<span></span> of spans with char<span></span>acte<span></span>rs that affe<span></span>ct word brea<span></span>king but don't show up</h1>
<h1>Especially in das super<span></span>doupercrazy<span></span>long<span></span>worden.</h1>
Seems to work fine on modern browsers and IE7+ (not tested on IE6).
Soft hyphen
- like a zero-width space but (in theory) adds a hyphen when it breaks a word across a line.
<h1>This text is full<span></span> of spans with char<span></span>acte<span></span>rs that affe<span></span>ct word brea<span></span>king but don't show up</h1>
<h1>Especially in das super<span></span>doupercrazy<span></span>long<span></span>worden.</h1>
<h1>Example where das superdoupercrazylongword contains no spans.</h1>
Fine on modern browsers and IE7+ (not tested on IE6), though as some comments note there are issues with these turning into regular hyphens when copied and pasted, for example, here's how it pastes from Chrome to Notepad, on Windows 8.1:
Within a span, it seems to never add a hyphen (but still better to use zero-width spaces if possible).
Edit: I found an older SO answer discussing these as a solution to a different problem which suggests these are robust except for possible copy/paste quirks.
The only other issue with these I could find in research is that apparently some search engines may treat words containing these as being split (e.g. awesome might match searches for awe and some instead of awesome).
There are two characters that are graphic characters but defined to be zero width: U+200B ZERO WIDTH SPACE and U+FEFF ZERO WIDTH NO-BREAK SPACE. The former acts like a space character, so that it is a separator between words and allows line breaking in formatting, whereas the latter explicitly forbids line breaks. It depends on the purpose and context which one you should use. The can be represented in HTML as and .
There characters work well in most browsing situations. However, in IE 6, they tend to be rendered as small rectangles, since IE 6 does not know these characters and tries to render them as if they were graphic characters (which lack glyphs).
There are also control characters that are allowed in HTML, such as U+200E LEFT-TO-RIGHT MARK and U+200D ZERO WIDTH JOINER. They have no rendering as such, though they may affect rendering of graphic characters, e.g. by setting writing direction, affecting ligature behavior, etc. Due to the possibility of such effects, it might be risky to use them as “dummy” characters.
Trying to get the 1/3 and 1/8 symbols to show on IE 8-9. It shows fine on earlier versions of IE and all other browsers.
Code I'm using:
⅓
¼
IE 9 and older do not recognize the references ⅓ and ⅛ (the latter is obviously what you meant, instead of ¼, which is well supported) but instead render them literally. These references were not defined in HTML 4.01, and they were added to browsers relatively late (around 2011). Use the numeric references instead: ⅓ and ⅛ (or type the characters themselves, using a suitable editor and UTF-8 encoding).
You would still have a font problem, because the font you use for normal text may not contain these characters. In some situations, browsers are unable to use a fallback font unless you give them a helping hand with a font-family declaration. Besides, there is a risk of getting these characters in a style different from other characters, including more common vulgar fractions like ½. Thus, a careful choice of a font list is recommended; see my Guide to using special characters in HTML.
They aren't in the HTML4 spec, which is what IE9 and lower use. Only 1/4, 1/2 and 3/4 are supported.
Here is a list of what works and what doesn't.
http://stanford.library.usyd.edu.au/symbols/entities.html#Math
Does anyone know what is the maximum length I can enter for the html title attribute and whether special characters are allowed?
There is no limit for title length based on the current HTML 4 and 5 specs; but IE explorer has a limit of 512 characters for HTML 4.01.
Other browsers have trouble with long titles (you have to test it yourself each time). Also you may use almost anything, including alphabets, numbers, special chars (symbols) etc. in your title. But avoid Unicode.
Unicode titles creates some trouble. Refer to this Stack Overflow post Unicode HTML titles displaying as boxes in IE, Chrome.
From a comment by #Jukka K. Korpela:
The reason to avoid anything except the most common characters is that title attribute values are rendered, on mouseover, by browser routines that typically use a specific font, with limited character repertoire. There is no formal prohibition, just lousy implementations.
Practically there is no limit to the length.
However beyond certain characters, your browser wont show the whole title.
Special characters are allowed.
There is no limit in the specifications.
But when you go past 64 characters, browsers will treat it differently
Internet Explorer breaks the text to two or more lines
whereas other browsers do not.
Why make a title very long? Short and concise does the trick.
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.