Change minlength/maxlength behavior around linebreaks #1712
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As discussed in #1467, the current situation around these attributes is not very interoperable. Some browsers count line breaks as two characters (per the spec before this change), others as one character. Per discussions, this updates minlength and maxlength to count line breaks as one character. We believe this is the most developer-friendly approach, as evidenced in part by repeated complaints against Chromium for its behavior following the previous standard. While here, updated the textLength property to return the code-point length of the element's API value, instead of the element's value, since as per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4304 that is what browsers actually do. Fixes part of #1467, but the debate remains about code-unit length vs. code-point length vs. number of grapheme clusters.
domenic
added
normative change
do not merge yet
|
lgtm though I'm not sure if we should convert "normalize" to "normalise" in this change. |
|
Yeah, treating CRLF as a single character for the purpose of applying max/minlength seems like a good idea and it will improve the interoperability of browsers. |
| transformation applied:</p> | ||
| <p>The algorithm for obtaining the element's <span data-x="concept-fe-api-value">API value</span> | ||
| is to return the element's <span data-x="concept-textarea-raw-value">raw value</span> with the | ||
| <span>textarea linebreak normalisation transformation</span> applied. The <dfn>textarea linebreak |
There was a problem hiding this comment.
24 hits for "line break" in HTML, 0 for "linebreak"
|
Updated linebreak vs. line break. New suggested commit message including the bit about the conformance requirement: |
domenic
removed
the
do not merge yet
|
Thanks @domenic! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a successor to #1517 which concentrates on the less-controversial part of the change, of changing linebreaks to count as 1 character (aligning with Edge and Firefox and with @tkent-google's suggestion for Chrome).
/cc @tkent-google, @rniwa, @kojiishi. In particular I'm hoping to hear from @rniwa if he is willing to change this aspect of the behavior. Let's mark this as "do not merge yet" until he weighs in.
As discussed in #1467, the current situation around these attributes is
not very interoperable. Some browsers count line breaks as two
characters (per the spec before this change), others as one character.
Per discussions, this updates minlength and maxlength to count line
breaks as one character. We believe this is the most developer-friendly
approach, as evidenced in part by repeated complaints against Chromium
for its behavior following the previous standard.
While here, updated the textLength property to return the code-point
length of the element's API value, instead of the element's value, since
as per http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4304
that is what browsers actually do.
Fixes part of #1467, but the debate remains about code-unit length vs.
code-point length vs. number of grapheme clusters.