- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 26 Aug 2013 13:30:50 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>, Kent Tamura <tkent@chromium.org>, Alexey Proskuryakov <ap@webkit.org>, Norbert Lindenberg <w3@norbertlindenberg.com>, Richard Ishida <ishida@w3.org>
On Aug 22, 2013, at 1:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Aug 21, 2013 at 8:19 PM, Alexey Proskuryakov <ap@webkit.org> wrote: >> FWIW, this is tracked for WebKit as <https://bugs.webkit.org/show_bug.cgi?id=120030>. > > I think Darin's comment about the server component makes sense. My > remark was mostly as to what is exposed to JavaScript. I don't think > we expose an API to measure the number of grapheme clusters in a given > string at the moment and writing such a function might be rather hard. > (Although if maxlength was redefined to work this way...) Yeah, I do see a benefit in matching what JavaScript does. However, that's not the most intuitive behavior for users. > Considering end users makes sense too, but we should also consider > what applications people want to write. From limited testing I believe > Twitter currently counts Unicode scalar values. This is somewhat > better than code units, but e.g. U+0041 U+030A still subtracts two > from your 140 limit. (This also means the example in the specification > that makes a jab at Twitter is technically incorrect.) (Not that > Twitter's current control could be implemented with a plain <input> or > <textarea>.) If measuring the number of code units is what the author wanted, then he/she could manually check inputElement.value.length. As you've just pointed out. different websites use different encoding schemes and have different requirements for the number of bytes or sequence of code units they can store. I don't think we can solve that problem in HTML. - R. Niwa
Received on Monday, 26 August 2013 20:31:26 UTC