24796 2014-02-25 08:07:03 +0000 setSelectionRange() should be supported in other input types as well. Use case: in a mobile app when focusing a number input, allow selecting the entire number so you can overwrite the value without [...] 2017-03-10 05:30:16 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#input-type-attr-summary blocked on getting each use case filed as a separate bug P3 normal Unsorted 1 contributor ian aaron.labiaga andyearnshaw+w3 andyearnshaw brandonlwhite d ian jayd.lawrence justinbmeyer kevinsheedy MattN+w3 mike sampo.niskanen stephen.cunliffe contributor oldest_to_newest 101316 0 contributor 2014-02-25 08:07:03 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html Multipage: http://www.whatwg.org/C#input-type-attr-summary Complete: http://www.whatwg.org/c#input-type-attr-summary Referrer: Comment: setSelectionRange() should be supported in other input types as well. Use case: in a mobile app when focusing a number input, allow selecting the entire number so you can overwrite the value without having to first wipe it out. In practice this works in all browsers, except Chrome 33 where support was removed because of this spec. See https://code.google.com/p/chromium/issues/detail?id=346270 and https://code.google.com/p/chromium/issues/detail?id=324360 Posted from: 80.220.231.181 User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/32.0.1700.102 Chrome/32.0.1700.102 Safari/537.36 101322 1 sampo.niskanen 2014-02-25 11:16:26 +0000 Additional info on the use case: On mobile devices you must use a 'number' input type so that you get the numeric keyboard open when focusing on the field. In this case you also need a way to select the number, so that you can immediately type a replacement for the value. Specifying the select() method to apply for all input types would be sufficient, setSelectionRange() is not necessary (at least for this use case). Currently select() is also limited to the same input types as setSelectionRange(). 101325 2 aaron.labiaga 2014-02-25 12:50:07 +0000 Yes I never understood why the specs don't support this. It is also odd that an input of type number can allow for 101333 3 brandonlwhite 2014-02-25 14:56:46 +0000 I would like to see the selection API permitted on <input type="number"> as well. In fact, browsers like Chrome did support this until very recently. For many people this is a breaking change in the name of 'adhering to spec'. Here is one use case that immediately comes to mind: In many of my applications it is desirable to have real-time instantaneous validation of user input, particularly for numbers. What this means is that instead of allowing malformed input (eg "123foo456") and then later rejecting this only when then user attempts to submit, rather we wish to prevent any keystrokes, etc, that would result in an invalid input immediately as they occur. Usually this is paired with some kind of visual feedback (eg flashing red border, textual message). This requires the use of `selectionStart` and `selectionEnd` in order to compute the resultant value after the keystroke or paste event. Essentially, if the user has the ability to create a selection or move the caret position in the <input>, the DOM API should allow script to at least query the selection. 101355 4 ian 2014-02-25 18:30:28 +0000 If the value is "123456", and you select characters 4 through 6, what would be selected? Hint: the browser is allowed to render that as: [ 000,123,456.000 |^|v] It's also allowed to render it as: [ One hundred and twenty three thousand, four hundred and fifty six ] It's also allowed to render it as: [+] ..... ..... ..... ..... ..... ..... ..... | | | 0 | | 1 | | 2 | | 3 | | 4 | | 5 | >> | | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | << | | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | ''''' ''''' ''''' ''''' ''''' ''''' ''''' [.] ...or as: 0 100k 200k |----------------------v-------------| 123,456 101422 5 sampo.niskanen 2014-02-26 06:14:55 +0000 At least select() should be supported, which selects the entire value (if applicable). From a practical, implementor's perspective: The variability of the allowed input element styles is a major pain in mobile web app development in general. You have to use 'number' type so that the keyboard is for numeric input, but you have to run through hoops (and browser specifics) to control the styling. (And yes, controlling styling is important.) In practice, no browser could switch their number input from a relatively simple text-based layout (with possible up/down controls) without breaking a lot of web apps. 101433 6 ian 2014-02-26 15:20:55 +0000 *** Bug 24814 has been marked as a duplicate of this bug. *** 101434 7 ian 2014-02-26 15:23:07 +0000 How would it break Web apps? I don't really understand why you need to be manipulating the selection of a type=number field at all. What's the use case? 101439 8 aaron.labiaga 2014-02-26 16:23:44 +0000 I too have an issue with the lack of support for selectionstart and selectionend for input type number. The use case I can think of is when we want to limit the min/max number the user can input depending on the the number place. Lets say we want to only allow the user to input 43-67. When the user highlights the first digit and inputs a number, I'd like to know to know what range the user is doing it so I can restrict the number value, where x is the user input and has to be x >= 4 || x <= 6. I understand there is a min and max attribute value but that doesn't stop the user from inputting that number directly unless they use the spinner control. I know we can achieve that using input type text but to me it's very confusing as to why input type number even allows the input of non numbers in the first place. Why is maxlength and pattern not supported, amongst other things. These things should just be available to all inputs in general. To me it sounds like input type number is only valuable in the mobile context. 101442 9 stephen.cunliffe 2014-02-26 17:05:17 +0000 Hi all I'm jumping in this late (had I known these changes were going in I would have spoke up earlier!) Since Chrome just updated to remove this from number fields app(s) I work on now fail in Chrome. Similar to others I've used the selectionStart, selectionEnd, and setSelectionRange() props/methods on fields to validate, add, remove, insert content on many fields (mostly type="text") but also for email, number, url etc. There's 2 underlying problems. 1.) Currently (AFAIK) all user agents render an <input type="number"/> field as a text box... the only difference is that on modern mobile (phones/tablets) when the OS provided on-screen keyboard pops up, it *defaults* to the one that best matches the field type (e.g. the number pad). From a usability perspective, this is awesome! and thus has been adopted wide scale on any numerical field in web apps (and apps with WebView's) everywhere. However the web is a living, moving thing... and many apps need to support all kinds of devices/OSes including older ones, and including touch-screen devices that were created *before* touch-screen devices had a decent on-screen keyboard solution. (I'm gonna quote this as any touch screen before the iphone) As a result in *many* enterprise situations (think the kiosk in your local mall, office/floor directory in a skyscraper, Point Of Sale, Hospital, Restaurant, Book store/library, etc.) developers needed to create a software based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input where no phyical keyboard was available (and using the Windows "104" onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc. that could take down the terminal) Long story short, these on-screen keyboards need to use JavaScript to know where they are inserting characters, or "moving" the cursor within a field to let the user input values correctly. There's also cases where a number field will invoke a "special" tool (tax/tip/percentage/standard calculator) that can be used to clear, add/remove/overwrite values into a field. My vote for what it is worth is 100% in favor of bringing full support back for these properties/methods. Problem 2. If the powers that control the specs here disagree with web developers about the importance of these properties/methods... there's little we can do - however like all good coders should I was already testing to see if the JavaScript object reference to the field I was working with supported the "setSelectionRange" method (side note, Internet Explorer's previous lack of support for these props/methods required this test to use their legacy text-selection methods). Sadly Chrome passes the test and tells me that my field does indeed support this method only to throw an exception in the log if I try to use it. e.g. I have: if(typeof(field.setSelectionRange) == 'function'){...} or if(typeof(field.selectionStart) != 'undefined'){...} IMHO this is almost worse. I'm being told that these members are valid, yet they most certainly are not with this latest change in Chrome. Sadly I'm now stuck... customers are auto updating to the latest version of Chrome and I'm in panic mode trying to determine what to do. Do I change all my <input type="number|email|url|..."/> fields back to <input type="text"/> to ensure that Chrome (and future browsers that adopt this behavior) are not completely borked at the cost of deliberately adding a major usability failure for all other mobile devices... or wait and hope that these oversights get reverted/fixed right away. 101444 10 stephen.cunliffe 2014-02-26 17:24:38 +0000 On further thought... if we insist on keeping this regression it would be even better that *if* a user agent decides on a device that they are *not* showing a number field as a textbox control, *only* then they can either mark the properties/methods as undefined... OR better yet keep them... whereby they report the selectionStart and selectionEnd as (n-1) (ditto for range: (n-1 - n-1)) until the user blur's the field at which point the selection updates to start=0, end=(n-1) range matches full selection. 101653 11 ian 2014-02-28 21:18:07 +0000 (In reply to Aaron Labiaga from comment #8) > The use case I can think of is when we want to limit the min/max number > the user can input depending on the the number place. Please don't do this. It drives me crazy as a user. Take the example you gave of 43–67. I have entered "67". Now I want to change it to 57. I put the cursor at the front, I type "5" (so now it says "567") and then I delete the "6" (so now it says "57"). Why should that not be possible? > I understand there is a min and max attribute value but that doesn't > stop the user from inputting that number directly unless they use the > spinner control. Right. And so what? Let the user type what they want. When the user tries to commit the value, then report it as out-of-range if necessary (the browser will even do that for you if you invoke the right API). Seriously, limiting user input in this way is incredibly bad UI. > I know we can achieve that using input type text but to me it's very > confusing as to why input type number even allows the input of non numbers > in the first place. What it allows is up to the user agent. > Why is maxlength and pattern not supported, amongst other things. What's the use case? > These things should just be available to all inputs in general. That would just encourage authors to do things like you've described. (In reply to stephen.cunliffe from comment #9) > > 1.) Currently (AFAIK) all user agents render an <input type="number"/> field > as a text box... the only difference is that on modern mobile > (phones/tablets) when the OS provided on-screen keyboard pops up, it > *defaults* to the one that best matches the field type (e.g. the number pad). _Currently_ being the operative word here. > As a result in *many* enterprise situations (think the kiosk in your local > mall, office/floor directory in a skyscraper, Point Of Sale, Hospital, > Restaurant, Book store/library, etc.) developers needed to create a software > based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input > where no physical keyboard was available (and using the Windows "104" > onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc. > that could take down the terminal) > > Long story short, these on-screen keyboards need to use JavaScript to know > where they are inserting characters, or "moving" the cursor within a field > to let the user input values correctly. That's a pretty horrifying thought, but let's put that aside for now: why would these apps need to use type=number when they show the on-screen keyboard? (Or even <input> for that matter.) If they're showing their own keyboard, the <input> isn't really being used as a text input at all, it's just being used as an output widget. If you're going to go to the trouble of designing an entire on-screen keyboard, just go the whole hog and design your own widget, don't try to reuse the proper widget. (But really, if you find yourself designing your own on-screen keyboard in HTML, you've probably made some fundamental design mistakes.) > There's also cases where a number field will invoke a "special" tool > (tax/tip/percentage/standard calculator) that can be used to clear, > add/remove/overwrite values into a field. Not sure how this would have any impact here. Nothing stops you from clearing, adding, removing, or overwriting values. You don't need to manage the selection to do that. > if(typeof(field.setSelectionRange) == 'function'){...} > if(typeof(field.selectionStart) != 'undefined'){...} This isn't unexpected; the browser _does_ support these features, they just don't apply to <input type=number>, <input type=button>, etc. Since you're not supposed to use them with type=number at all, it's not something we've tried to make easy to detect. You can detect it, though, in theory, by checking to see if an exception is raised or not. > Sadly I'm now stuck... customers are auto updating to the latest version of > Chrome and I'm in panic mode trying to determine what to do. Just rely on the browser to provide the interface. 101743 12 sampo.niskanen 2014-03-03 06:24:24 +0000 Our use-case is implementing customized numeric inputs. Consider the input elements in the screenshot I've attached. The user can tap on the hours, and the number is automatically selected. They can enter two digits, and the focus jumps to the minutes, which is automatically selected to allow overwriting that number as well. What we currently have to do is use number inputs, which are positioned such that any possible spinners are hidden behind other elements. Needless to say, any browser that switches their number input to something other than a text field + spinner buttons will break all such designs. The layout could be achieved easier with a text input, but on mobile devices / tablets this brings up the text input keyboard, not the numeric input keyboard. This would be unacceptable from a UX perspective. I'm not arguing this is the best possible element for entering a time / number, I'm arguing this type of custom input element should be possible. I don't see any reason why selecting the entire number (in case it is shown in a text field) should be prohibited. Mobile IE actually does not support setting the selection of a number field, and the UX is clearly inferior. 101744 13 1444 sampo.niskanen 2014-03-03 06:25:44 +0000 Created attachment 1444 Example of custom input element usage Example screenshot relating to my previous comment. 101753 14 jayd.lawrence 2014-03-03 11:01:07 +0000 (In reply to stephen.cunliffe from comment #9) > As a result in *many* enterprise situations (think the kiosk in your local > mall, office/floor directory in a skyscraper, Point Of Sale, Hospital, > Restaurant, Book store/library, etc.) developers needed to create a software > based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input > where no phyical keyboard was available (and using the Windows "104" > onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc. > that could take down the terminal) This is exactly my use case. The company I work for makes a Point Of Sale solution and we have just been stung by this bug. We can't just change the inputs to text instead of number as we need them to work correctly on mobile devices, as people have already mentioned. 101763 15 ian 2014-03-03 18:47:45 +0000 (In reply to Sampo N from comment #12) > > The layout could be achieved easier with a text input, but on mobile devices > / tablets this brings up the text input keyboard, not the numeric input > keyboard. This would be unacceptable from a UX perspective. Would <input type=text inputmode=numeric> solve this use case for you? I wouldn't recommend using type=number if you're designing your own widget. As you say: any browser that switches their number input to something other than a text field + spinner buttons will break all such designs. The lack of selection is the least of your concerns. (In reply to Jayd from comment #14) > We can't just change the inputs to text instead of number as we need them to > work correctly on mobile devices, as people have already mentioned. Why don't you just use type=number on mobile and type=text when you have the fake keyboard showing? It's trivial to just switch the "type" attribute when you show the keyboard. In general, if your widget is type=number, you can't rely on a keyboard making any sense. In fact, at that point, you're not relying on the widget at all, you're just using it as an output field. Personally, though, I would recommend using another approach for securing the kiosk. The strategy you describe seems like a losing proposition to me. 101781 16 stephen.cunliffe 2014-03-03 19:58:34 +0000 > > 1.) Currently (AFAIK) all user agents render an <input type="number"/> field > > as a text box... the only difference is that on modern mobile > > (phones/tablets) when the OS provided on-screen keyboard pops up, it > > *defaults* to the one that best matches the field type (e.g. the number pad). > > _Currently_ being the operative word here. Yes currently. As is currently no OS presents anything different so why go changing the way the code works and break things? I'd also argue... that unless the field is actually trying to allow input within a *very* restricted range (and there is a field type for that!) that I'd be hard pressed to dream up any other control type for the entry vs. an input box. Since I've used electronic devices where a mouse/cursor/caret/keyboard has been available none to my knowledge have seeked (& found) an alternative and better solution. This change to the API (without a need to actually remove it (e.g. a control implementation being pushed forward that WON'T work with the selection props/methods - that CAN'T easily side step the non-applicable parts) just seems like a quest for Astronaut Architecture in an Ivory Tower. > > > > As a result in *many* enterprise situations (think the kiosk in your local > > mall, office/floor directory in a skyscraper, Point Of Sale, Hospital, > > Restaurant, Book store/library, etc.) developers needed to create a software > > based (e.g. JavaScript) keyboard (and/or numberpad) to allow easy user input > > where no physical keyboard was available (and using the Windows "104" > > onscreen keyboard would provide insecure access to Alt, Tab, F1, F2... etc. > > that could take down the terminal) > > > > Long story short, these on-screen keyboards need to use JavaScript to know > > where they are inserting characters, or "moving" the cursor within a field > > to let the user input values correctly. > > That's a pretty horrifying thought, but let's put that aside for now: why > would these apps need to use type=number when they show the on-screen > keyboard? (Or even <input> for that matter.) If they're showing their own > keyboard, the <input> isn't really being used as a text input at all, it's > just being used as an output widget. If you're going to go to the trouble of > designing an entire on-screen keyboard, just go the whole hog and design > your own widget, don't try to reuse the proper widget. > > (But really, if you find yourself designing your own on-screen keyboard in > HTML, you've probably made some fundamental design mistakes.) If you have an alternative for a touchscreen kiosk device (w/o physical keyboard) running an OS like Windows and a web application running in a browser (with no OS supplied S/W keyboard) I'm all ears! However this has been solved many times over in JavaScript... you might be surprised just how common this actually is. > > if(typeof(field.setSelectionRange) == 'function'){...} > > if(typeof(field.selectionStart) != 'undefined'){...} > > This isn't unexpected; the browser _does_ support these features, they just > don't apply to <input type=number>, <input type=button>, etc. > > Since you're not supposed to use them with type=number at all, it's not > something we've tried to make easy to detect. > > You can detect it, though, in theory, by checking to see if an exception is > raised or not. > > > > Sadly I'm now stuck... customers are auto updating to the latest version of > > Chrome and I'm in panic mode trying to determine what to do. > > Just rely on the browser to provide the interface. Similar to the suggestion below... our only alternative at this moment is to force a change to the field's type attribute on the fly. Realistically this is just a hack to overcome this regression... and we're going to have to be careful as this won't work in IE8 or below, or any IE browser running content that is not in Standards mode... <sarcasm>Yay browser detection!</sarcasm> Maybe I am really missing something here but AFAICT the type="number" attribute applied to the HTML input tag is no different than every other implementation I've seen over the years at other software levels. It provides "hinting" to the field that can determine that this string field: a.) might be best shown with a spinner b.) might be best shown right aligned (in a LTR locale) c.) might be best to limit the character input to digits, and valid delimiters (as per locale) d.) might be best to enforce validation upon submitting However since a number can be any value from (-infinity to infinity) and that number is essentially a string of digit characters in a rectangle that displays the characters horizontally with no UA imposed restrictions on *how* the user decides to populate the string I find it really frustrating that we're intentionally trying to hinder developers by removing the basic selection methods. If someone has come up with a new (desirable) & future way of entering a number like "1250" that doesn't render said number into a horizontal string I'd be curious to know about it. 101853 17 stephen.cunliffe 2014-03-04 20:30:34 +0000 Sadly it looks like trying the hack of converting the field to a type="text" to get the selection fails (at least in Chrome) because it resets the selection. The new, current hacky solution is to have an onload handler (pick your favorite library) that creates a dummy input of type="number" that is NOT added to the DOM... attempt to call setSelectionRange() on it and if it fails, scan the entire document for input elements of type="number" and forcibly convert them to type="text" because this particular browser has dropped support for the useful properties/methods. Hopefully no other browsers follow suit before this issue is addressed. Sigh 101901 18 kevinsheedy 2014-03-05 14:57:13 +0000 I've been maintaining the jquery.alphanum library for the last 18 months. This change has broken the library which has been very inconvenient for it's userbase. https://github.com/KevinSheedy/jquery.alphanum/issues/19 There has been 18 months worth of work done developing, testing and fixing this library on the basis of the selection api being available. Quoting the w3 design principles: "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new." http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths This feature has been available in all browsers for a long time now and has become widely adopted by developers. I think this is one case where the spec should follow the implementation rather than the other way round. 101902 19 brandonlwhite 2014-03-05 15:14:30 +0000 https://github.com/Mottie/Keyboard is affected by this as well. I rely on this library to supply on-screen keyboards and numpads for industrial automation controllers. These are kiosk-style systems where the UI/HMI is a Single Page Application. This is not a public-facing website, eCommerce app, etc. The HMI is also remotely accessible from any device with a browser. We enable the use of the virtual keyboard via a query string. For PCs, phones, etc. the absence of the query string foregoes our custom keyboard in favor the native keyboard (which for PCs, we expect that it's a physical keyboard). As such, we like to using numeric inputs as appropriate so that we get the best result from the user agent. We also rely on min, max, and step attributes as well to automate the validation. We also use step to enforce floating point vs. integer fields. It is also noteworthy, that our UI/HMI does not fit the classic model of a web form where there is a separate and distinct submission action. 102304 20 stephen.cunliffe 2014-03-13 14:58:19 +0000 Since this change has had major impact on production environments that were using the properties/methods that were previously available we've had to hack a workaround to get the proper behavior back. I've posted a question on StackOverflow that includes my answer on how we are currently solving this. http://stackoverflow.com/questions/22381837/how-to-overcome-whatwg-w3c-chrome-version-33-0-1750-146-regression-bug-with-i If other developers are stuck during this interim period and need a solution please feel free to use this code (or any other solution answers posted) As for the committee that designs these specifications, I sincerely hope you reconsider these changes. I see no upside to removing these properties/methods and a whole pile of downsides. 103832 21 ian 2014-04-14 21:10:58 +0000 (In reply to stephen.cunliffe from comment #16) > Yes currently. As is currently no OS presents anything different so why go > changing the way the code works and break things? Nothing in the spec has been changed here; the selection APIs didn't apply to type=number from the beginning. The idea is that in the future, browsers will get better, and selection will no longer make sense. It would be sad for us to paint ourselves into a corner and prevent progress. > I'd also argue... that unless the field is actually trying to allow input > within a *very* restricted range (and there is a field type for that!) that > I'd be hard pressed to dream up any other control type for the entry vs. an > input box. Since I've used electronic devices where a > mouse/cursor/caret/keyboard has been available none to my knowledge have > seeked (& found) an alternative and better solution. There have been lots of kinds of numeric controls, especially for the cases of limited ranges. Dials and sliders, for example. The clock widget in recent Android releases is a numeric control over a narrow range. But actually, even if it's just a text field with up and down buttons, it still varies: commas used for thousands separation, how many decimal places are shown, and other locale-specific adjustments, are all things that you can't predict and that are commonly different in different numeric controls. > This change to the API-- There hasn't been a spec change here. > If you have an alternative for a touchscreen kiosk device (w/o physical > keyboard) running an OS like Windows and a web application running in a > browser (with no OS supplied S/W keyboard) I'm all ears! I recommend running an OS that isn't like Windows, and using an OS-supplied soft keyboard. Android, for example, is particularly well-suited for this kind of deployment, as it is open source and can be completely locked down. > Realistically this is just a hack to overcome this regression... Having a Web-based on-screen keyboard is already a hack; making the input field into a text field is far less of one, since it is actually turning the control into what you need. At the point where you're providing a software keyboard, it's not longer a numeric input field. It's a custom input field, and the best basis for that is type=text. > and we're > going to have to be careful as this won't work in IE8 or below, or any IE > browser running content that is not in Standards mode... > <sarcasm>Yay browser detection!</sarcasm> I thought we were talking about a kiosk situation? Surely you control the software running on this kiosk? Maybe I don't understand the use case. > Maybe I am really missing something here but AFAICT the type="number" > attribute applied to the HTML input tag is no different than every other > implementation I've seen over the years at other software levels. The type="" attribute specifies the kind of input so that the browser can provide a different UI. For example type=button is a button, type=text is a text field, type=password hides input. Well, type=number is a numeric input field, where the displayed value is adjusted by the user agent and might not match the submitted value. > It provides "hinting" to the field that can determine that this string field: > a.) might be best shown with a spinner > b.) might be best shown right aligned (in a LTR locale) > c.) might be best to limit the character input to digits, and valid > delimiters (as per locale) > d.) might be best to enforce validation upon submitting e.) might render different values than are submitted f.) might not be a text field at all > However since a number can be any value from (-infinity to infinity) That depends on the attributes, in particular min/max. > that number is essentially a string of digit characters in a rectangle Nothing in the spec says that. > displays the characters horizontally with no UA imposed restrictions on > *how* the user decides to populate the string Nothing in the spec says that either. In fact, I would suggest that every UA does provide some limits on how the UA populates the string, for example, I don't know of any that currently support speech input on type=number. > If someone has come up with a new (desirable) & future way of entering a > number like "1250" that doesn't render said number into a horizontal string > I'd be curious to know about it. In particular on mobile UAs it is not uncommon for controls to show popup dialogs when they are selected. For example, this is how a date control gets shown on some versions of iOS: http://www.deque.com/wp13/wp-content/dquploads/iphone-input-type-date.png There's no reason to believe some browsers won't do this for numeric inputs also. (In reply to stephen.cunliffe from comment #17) > Sadly it looks like trying the hack of converting the field to a type="text" > to get the selection fails (at least in Chrome) because it resets the > selection. You should apply this hack early (as soon as you know you're going to be managing the input for the control). I don't recommend waiting until the control is focused or anything like that. > The new, current hacky solution is to have an onload handler (pick your > favorite library) that creates a dummy input of type="number" that is NOT > added to the DOM... attempt to call setSelectionRange() on it and if it > fails, scan the entire document for input elements of type="number" and > forcibly convert them to type="text" because this particular browser has > dropped support for the useful properties/methods. Why would you use type=number for UAs where you're going to be providing the input UI anyway? (In reply to Kevin Sheedy from comment #18) > I've been maintaining the jquery.alphanum library for the last 18 months. I don't understand the point of this library. Could you elaborate? > Quoting the w3 design principles: > "When a practice is already widespread among authors, consider adopting it > rather than forbidding it or inventing something new." > http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths > > This feature has been available in all browsers for a long time now and has > become widely adopted by developers. I think this is one case where the spec > should follow the implementation rather than the other way round. The problem is that this practice has always been non-standard (you haven't been following the standard), and the standard behaviour is intended to protect the ability for innovation on the Web, which is good for users. http://www.w3.org/TR/html-design-principles/#priority-of-constituencies (In reply to Brandon White from comment #19) > https://github.com/Mottie/Keyboard is affected by this as well. I rely on > this library to supply on-screen keyboards and numpads for industrial > automation controllers. These are kiosk-style systems where the UI/HMI is a > Single Page Application. This is not a public-facing website, eCommerce > app, etc. I don't understand why anyone with an HTML-provided on-screen keyboard would want to use type=number instead of type=text. > The HMI is also remotely accessible from any device with a browser. We > enable the use of the virtual keyboard via a query string. For PCs, phones, > etc. the absence of the query string foregoes our custom keyboard in favor > the native keyboard (which for PCs, we expect that it's a physical keyboard). When the string is there, change it to type=text. > As such, we like to using numeric inputs as appropriate so that we get the > best result from the user agent. We also rely on min, max, and step > attributes as well to automate the validation. We also use step to enforce > floating point vs. integer fields. Yeah, that'll be harder for you (you'd have to reimplement that logic and, when changing the type attribute, move the data to data-* attributes). Fundamentally you have to make a decision: either rely on the UA to do the input control logic for you, including providing an on-screen keyboard if appropriate, or, implement the control yourself. (In reply to stephen.cunliffe from comment #20) > > As for the committee that designs these specifications, I sincerely hope you > reconsider these changes. I see no upside to removing these > properties/methods and a whole pile of downsides. I've explained the upside multiple times here, if you're not seeing it then you're not looking for it. 103875 22 stephen.cunliffe 2014-04-15 14:37:23 +0000 I see this as a few separate issues that are all getting muddled together. Issue #1: The spec only gets questioned when the new implementation breaks things. When browsers implemented the <input type="number"/> field to behave **exactly** like an <input type="text"/> field (with the exception that it also supported min/max/step etc. and on modern mobile devices was a hint to open the numeric keyboard on focus) developers **continued** to depend on built in JavaScript properties/behavior available to all existing text/password/textarea fields. Should we have expected/depended on this? yes/no/maybe... this was also tricky because browsers that didn't support number yet, just fell back to text anyway. Should we blame the browser developers for not adapting to the strict guidelines of the HTML5 specs (which only went CR on Feb 4th, 2014) for leading web developers down the garden path? The answer depends on knowing the final outcome of this "change". I'm using quotes because depending on your viewpoint this is either a change, or was never supported. (a question of implementation vs. spec) Issue #2: The spec has chosen not to implement properties/behavior that web application developers obviously want for reasons that are currently theoretical only. I get that there is nothing that states that a numeric input control must render a single line rectangle container that contains character input... however ALL current implementations DO. Please do not point to date widget implementations as an argument for a number field (that's Apples vs. Oranges) We all agree that if you have a very limited range of numbers you are accepting (e.g. a scale of 1..10 that rendering those values in a select list, set of radio buttons, or the way-more-appropriate <input type="range"/> field makes **perfect** sense!) however for the generic <input type="number"/> where the 'range' is essentially potentially from negative infinity up to positive infinity... There is NO user interface control that I can think of that will adapt to that level of flexibility other than the "rectangular input box". I have not seen in any application, on any device, on any platform that has provided a better solution... in fact if there was one, it would already be gaining traction/adoption. Issue #3: Developers are smart people! If one is building a new rendering control for <input type="number"/> in their browser that doesn't let users insert characters where they want e.g. I had "35" and I meant "345" but more importantly won't be able to provide a meaningful interaction for JavaScript attempting to get/set the selection range... the solution is simple!... just provide a stub method that does nothing or returns the overall min/max indexes (since it doesn't apply). In the long run the field still contains a value... that value is presumed to be numeric (level of enforcement TBD) but it is a String... when the form is submitted over HTTP to the server it is a String... the server still needs to parse it back into a number and validate that it got one because it is a String... in fact every single input control sending data back to the server is sending a String(*1) and the most basic manipulation methods on Strings require the ability to get/set/manipulate substrings. I really don't get what possible advantage we are gaining by not letting web application developers get or set the cursor position or get or set the selection ****IF**** the user agent is rendering the value in a single line input box. (*1)Ignoring Blobs, and binary file attachments of course. 103942 23 sampo.niskanen 2014-04-16 08:15:47 +0000 There is a valid concern that setSelectionRange is problematic, since even in a rectangular box browsers can render a number either "1234567", "1,234,567", "1 234 567" or a number of different ways, while the value will always return "1234567". (It might be possible to describe a proper logic here, e.g. select the digit range that would be selected if the number were formatted without localization.) However, I see no reason why select() method should not work *in case it is rendered as a selectable text field*. The method would be a no-op if character selection is not applicable. According to the spec the proper way to make a number input that renders like a text box would be <input type="text" inputmode="latin digits">, however *no* browser supports opening a numeric keyboard in this case. I created a test page for the various input types: http://sampo.kapsi.fi/files/numeric-input.html 105742 24 ian 2014-05-12 18:35:29 +0000 (In reply to stephen.cunliffe from comment #22) > Issue #1: The spec only gets questioned when the new implementation breaks > things. > > When browsers implemented the <input type="number"/> field to behave > **exactly** like an <input type="text"/> field (with the exception that it > also supported min/max/step etc. and on modern mobile devices was a hint to > open the numeric keyboard on focus) developers **continued** to depend on > built in JavaScript properties/behavior available to all existing > text/password/textarea fields. > > Should we have expected/depended on this? yes/no/maybe... this was also > tricky because browsers that didn't support number yet, just fell back to > text anyway. > > Should we blame the browser developers for not adapting to the strict > guidelines of the HTML5 specs (which only went CR on Feb 4th, 2014) for > leading web developers down the garden path? > > The answer depends on knowing the final outcome of this "change". I'm using > quotes because depending on your viewpoint this is either a change, or was > never supported. (a question of implementation vs. spec) This particular part of the spec went to "CR" at least as far back as 2010, FWIW. (It is marked as "Ready for first implementations", and the state was last edited in 2010.) But yes, more earlier review would definitely be great. I don't know what we can do to encourage this. > Issue #2: The spec has chosen not to implement properties/behavior that web > application developers obviously want for reasons that are currently > theoretical only. > > I get that there is nothing that states that a numeric input control must > render a single line rectangle container that contains character input... > however ALL current implementations DO. > > Please do not point to date widget implementations as an argument for a > number field (that's Apples vs. Oranges) > > We all agree that if you have a very limited range of numbers you are > accepting (e.g. a scale of 1..10 that rendering those values in a select > list, set of radio buttons, or the way-more-appropriate <input > type="range"/> field makes **perfect** sense!) however for the generic > <input type="number"/> where the 'range' is essentially potentially from > negative infinity up to positive infinity... There is NO user interface > control that I can think of that will adapt to that level of flexibility > other than the "rectangular input box". I have not seen in any application, > on any device, on any platform that has provided a better solution... in > fact if there was one, it would already be gaining traction/adoption. I think this oversimplifies the situation (e.g. it ignores that some UAs put thousands-separators in the displayed value, which is a relevant point for the selection API, because it interferes with the precise positions that would be selected). But sure, the UIs are all very similar today. Consider this, though: Forms came in April 1993. Mobile Safari introduced a new form control set in June 2007, fourteen years later. I don't want to be the reason we can't introduce a new form-factor decades hence. > Issue #3: Developers are smart people! If one is building a new rendering > control for <input type="number"/> in their browser that doesn't let users > insert characters where they want e.g. I had "35" and I meant "345" but more > importantly won't be able to provide a meaningful interaction for JavaScript > attempting to get/set the selection range... the solution is simple!... just > provide a stub method that does nothing or returns the overall min/max > indexes (since it doesn't apply). I agree that this would be fine for many authors. On the other hand, we've experienced many times over the years that some authors rely on the weirdest edge cases in the most obscure of ways. Look at the HTML parser's crazy edge cases for some examples. The smart developers aren't claiming that their UTF-8 pages are encoded as UTF-16, but there are still sufficient UTF-8 pages labeled as UTF-16 that we have to explicitly have that mapping in the spec, as crazy as that is. The spec is _full_ of stuff like this. What about if the page somehow depends on the position of the cursor to function right? What if the page somehow relies on the selection changing from the whole thing being selected to nothing being selected to know when to do something critical to furthering interaction on the page? We don't know what people will end up depending on. > In the long run the field still contains a value... that value is presumed > to be numeric (level of enforcement TBD) but it is a String... when the form > is submitted over HTTP to the server it is a String... the server still > needs to parse it back into a number and validate that it got one because it > is a String... in fact every single input control sending data back to the > server is sending a String(*1) and the most basic manipulation methods on > Strings require the ability to get/set/manipulate substrings. Yes, but these strings are already today in some browsers not the string that is displayed. > I really don't get what possible advantage we are gaining by not letting web > application developers get or set the cursor position or get or set the > selection ****IF**** the user agent is rendering the value in a single line > input box. The same advantage as we got, in 2007, from the decision, in 1993, not to require that all select widgets show a drop-down box in the specific way that browsers in 1993 all did. (In reply to Sampo N from comment #23) > There is a valid concern that setSelectionRange is problematic, since even > in a rectangular box browsers can render a number either "1234567", > "1,234,567", "1 234 567" or a number of different ways, while the value will > always return "1234567". (It might be possible to describe a proper logic > here, e.g. select the digit range that would be selected if the number were > formatted without localization.) > > However, I see no reason why select() method should not work *in case it is > rendered as a selectable text field*. The method would be a no-op if > character selection is not applicable. That could work. I've filed bug 25663 for this. > According to the spec the proper way to make a number input that renders > like a text box would be <input type="text" inputmode="latin digits">, > however *no* browser supports opening a numeric keyboard in this case. It's inputmode=numeric, actually. Where did you see "latin digits"? (Not that I found browser support for inputmode=numeric yet either, unfortunately.) 105811 25 sampo.niskanen 2014-05-13 06:28:53 +0000 http://www.w3.org/TR/2003/REC-xforms-20031014/sliceE.html and http://www.w3.org/TR/2006/REC-xforms-20060314/sliceE.html specify inputmode="latin digits". I was unable to find any spec that would define inputmode="numeric". The recommendation dates to 2003, and no user agent to my knowledge has adopted it. 105883 26 ian 2014-05-13 18:06:51 +0000 That's XForms. HTML's inputmode="" attribute is defined in the HTML spec: http://whatwg.org/html#attr-fe-inputmode 105905 27 stephen.cunliffe 2014-05-13 20:01:19 +0000 I ran a set of tests for the inputmode attribute (number, tel, email, url) on various current devices / browsers that have an onscreen keyboard that pops up on focus. Sadly at this time (May 12/2014) I've found NO mobile browsers on any OS that support the attribute. This included iOS, BlackBerry10, Android, FirefoxOS & WindowsPhone... on all default browsers and (in the case of iOS/Android) on extra installed browsers (Firefox, Chrome, Opera). Not a single browser supported the attribute. This is sadly quite frustrating as it would solve a lot of the text selection issues that developers are facing due to some browsers already "removing" the text selection options on the "specialized" input fields. :-( 106065 28 ian 2014-05-15 18:13:33 +0000 Yeah, agreed. Can you file bugs on the big ones for that? 107700 29 andyearnshaw+w3 2014-06-12 08:05:17 +0000 (In reply to Ian 'Hixie' Hickson from comment #11) > (But really, if you find yourself designing your own on-screen keyboard in > HTML, you've probably made some fundamental design mistakes.) I'm sad to say that some of the most popular Smart TVs around do not allow apps to use a System-provided keyboard. Instead, we're forced to use JavaScript and HTML-based keyboards from their libraries that rely on .selectionStart and .selectionEnd to get and set the position of the caret in an input box. The top two manufacturers' (Samsung & LG) on-screen keyboards are poorly coded and don't support most HTML5 input types, though, but my point is that sometimes we don't have a choice. > If the value is "123456", and you select characters 4 through 6, what would > be selected? Hint: the browser is allowed to render that as: > > [ 000,123,456.000 |^|v] While I get the reasoning for disallowing selection manipulation on <input type="number">, I don't get the reasoning for the same on <input type="email">. This input type is always going to work like a text input, isn't it? 107732 30 ian 2014-06-12 16:40:25 +0000 The poor design choice there might be trying to target a device with such a poorly implemented browser. :-) For type=email, have a look at the GMail "To" field for an example of what an e-mail entry widget might look like. Notice that it's not a simple text field. 107772 31 andyearnshaw+w3 2014-06-13 08:16:38 +0000 > --- Comment #30 from Ian 'Hixie' Hickson <ian@hixie.ch> --- > The poor design choice there might be trying to target a device with such a > poorly implemented browser. :-) I almost wrote that myself in my first reply! > For type=email, have a look at the GMail "To" field for an example of what an > e-mail entry widget might look like. Notice that it's not a simple text field. Yet it handles text selection just fine by excluding the "complete" email addresses that were already entered. :-) Technically, URL, tel or even ordinary text inputs could be handled the same way (it's really no different to the "Tags" input at http://stackoverflow.com/questions/ask). My point is that, unlike type="number", that could be rendered many different ways graphically and interacted with in different ways by the user, type="email" will always need some kind of direct input via a keyboard. User selection is just as likely as it would be on a text input. Arguably, this *is* the spec's fault for the following part of http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#textFieldSelection: > For input elements, calling these methods while they don't apply, > and getting or setting these attributes while they don't apply, > must throw an InvalidStateError exception. Otherwise, they must act > as described below. When it should (in my opinion, of course) just work in cases where the input rendering for those types is similar or identical to a standard text input field, and silently fail otherwise. That would seem like the least destructive course of action to take, in terms of backward and cross-browser compatibility. Even on type="number" elements, using your examples, [+] ..... ..... ..... ..... ..... ..... ..... | | | 0 | | 1 | | 2 | | 3 | | 4 | | 5 | >> | | | 1 | | 2 | | 3 | | 4 | | 5 | | 6 | << | | | 2 | | 3 | | 4 | | 5 | | 6 | | 7 | ''''' ''''' ''''' ''''' ''''' ''''' ''''' [.] and 0 100k 200k |----------------------v-------------| These kinds of graphical interfaces could just silently do nothing on attempts to programmatically set selection, and getting could just return 0 for `selectionStart` and `selectionEnd`. This would give developers the means to work any required magic on elements of this type when the browser or OS doesn't do anything special with them and just renders them in the same way they all do at the moment. 107793 32 ian 2014-06-13 18:31:00 +0000 But it's not that simple. For example, in the numeric case, the display could be: "12,345.6700" ...while the value is: "12345.67" What should selecting characters 2 to 4 do? For e-mail, the display could be: "foo@افغانستا.example.org" ...while the value is: "foo@xn--mgbaal8b0b9b2b.example.org" What should selecting characters 6 to 7 do? 107823 33 andyearnshaw+w3 2014-06-14 10:03:56 +0000 (In reply to Ian 'Hixie' Hickson from comment #32) > But it's not that simple. > > For example, in the numeric case, the display could be: > > "12,345.6700" > > ...while the value is: > > "12345.67" > > What should selecting characters 2 to 4 do? Perhaps we could transparently pretend the selected value is: "1|234|5.67" and display it as: "1|2,34|5.6700" I don't think this would particularly matter to the user as any changes to the selection would be handled identically in either situation. > For e-mail, the display could be: > > "foo@افغانستا.example.org" > > ...while the value is: > > "foo@xn--mgbaal8b0b9b2b.example.org" > > What should selecting characters 6 to 7 do? Of course, this is trickier, but any of the following seem like they'd be better alternatives than throwing an error that wasn't always thrown: - screw with the developer and pretend they didn't select anything, but adjusting .selectionStart should still move the cursor/caret based on a "best guess". For example, whilst the cursor is outside the arabic text, move it normally. Whilst inside the arabic text, treat the passed value as more or less to move the cursor by at least 1 "displayed" character. - Introduce a "displayed value" property and have the selection reflect that instead. At least then we're offering a way to fix the broken code. It would just be nice if we could have a solution where code didn't have to change the input type to "text" before it could work with these elements. 108204 34 sampo.niskanen 2014-06-23 06:06:03 +0000 (In reply to Ian 'Hixie' Hickson from comment #32) > For e-mail, the display could be: > > "foo@افغانستا.example.org" > > ...while the value is: > > "foo@xn--mgbaal8b0b9b2b.example.org" IIRC, the recommendation is that applications supporting IDN use the Unicode format for domain names internally, and the domain is converted to Punycode only for legacy applications / protocols. I definitely hope no browser will start converting type="email" input values to Punycode! Some user-provided formatting can easily be lost, e.g. capitalization. 110750 35 ian 2014-08-29 00:14:16 +0000 (In reply to Andy Earnshaw from comment #33) > (In reply to Ian 'Hixie' Hickson from comment #32) > > But it's not that simple. > > > > For example, in the numeric case, the display could be: > > > > "12,345.6700" > > > > ...while the value is: > > > > "12345.67" > > > > What should selecting characters 2 to 4 do? > > Perhaps we could transparently pretend the selected value is: > > "1|234|5.67" > > and display it as: > > "1|2,34|5.6700" > > I don't think this would particularly matter to the user as any changes to > the selection would be handled identically in either situation. If we do that then how would you maintain the selection when the user has selected: "12|,345.670|0" ...or: "12,|345.67|00" > > For e-mail, the display could be: > > > > "foo@افغانستا.example.org" > > > > ...while the value is: > > > > "foo@xn--mgbaal8b0b9b2b.example.org" > > > > What should selecting characters 6 to 7 do? > > Of course, this is trickier, but any of the following seem like they'd be > better alternatives than throwing an error that wasn't always thrown: > > - screw with the developer and pretend they didn't select anything, but > adjusting .selectionStart should still move the cursor/caret based on a > "best guess". For example, whilst the cursor is outside the arabic text, > move it normally. Whilst inside the arabic text, treat the passed value as > more or less to move the cursor by at least 1 "displayed" character. This is not the way to write good APIs. If you want to move the caret around arabic text, use a text field, not an e-mail field. > - Introduce a "displayed value" property and have the selection reflect > that instead. At least then we're offering a way to fix the broken code. What if the "displayed value" is a bitmap, because the control is a pen input control? There's nothing in the spec that disallows browsers from making that implementation choice. > It would just be nice if we could have a solution where code didn't have to > change the input type to "text" before it could work with these elements. I don't understand why you would _not_ want to use type=text if what you want is a text input. (In reply to Sampo N from comment #34) > (In reply to Ian 'Hixie' Hickson from comment #32) > > For e-mail, the display could be: > > > > "foo@افغانستا.example.org" > > > > ...while the value is: > > > > "foo@xn--mgbaal8b0b9b2b.example.org" > > IIRC, the recommendation is that applications supporting IDN use the Unicode > format for domain names internally, and the domain is converted to Punycode > only for legacy applications / protocols. I definitely hope no browser will > start converting type="email" input values to Punycode! It's actually required by the spec right now. See bug 15489. Note that I intend to make select() work with these controls, since that can be done interoperably. See bug 25663. 110751 36 stephen.cunliffe 2014-08-29 00:47:40 +0000 I'd still very much like to argue that **IF** a user agent renders an input field as a horizontal string of characters (e.g. as it currently does for text, password, number, email, url, tel etc.) that providing options for a selection start/end via JavaScript is not only helpful but darn near FUNDAMENTALLY IMPORTANT/EXPECTED. Yes, in theory, a user agent **Could** decide to render a input of type number field as a triangle field with random placement of digit characters and delimiters above, below and offset from each other... but **UNTIL** the rendering arrangement changes to anything other than a **HORIZONTAL STRING OF CHARACTERS** there is no point in removing these useful API calls from the fields. [1] If the W3C is still determined that they want to play the game of "well maybe a user agent might..." then lets at least not remove these properties/methods **UNTIL** the attributes to provide a keyboard hint to user agents is available. e.g. if I can still use a text field, but hint I want the numeric keyboard then fine (this sucks but is at least better than the current spec) <input type="text" inputmode="number"/> <!--request numeric keyboard since we want numeric input... but don't add the type="number" because the current spec removes JavaScript access to the selection if we set the type.--> Notes: [1] I'm willing to place bets that for as long as I plan being a developer (+/-25 more years) that numeric input will remain as a horizontal string of characters. Yeah it may be smartly filtered to not let users type "purple" as a numeric value... but it will still be a horizontal field of characters. 110756 37 sampo.niskanen 2014-08-29 07:02:59 +0000 I agree with Stephen (comment #36). Ideally, we'd have a way to specifically ask for a textual input that can only contain digits. But until there's a way to do this in a widely supported way, removing this functionality is very detrimental. "When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new." http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths 110757 38 sampo.niskanen 2014-08-29 07:09:26 +0000 Bug 25663 does alleviate the problem significantly, I believe. At least it covers our use cases. 110759 39 andyearnshaw 2014-08-29 08:51:01 +0000 (In reply to Ian 'Hixie' Hickson from comment #35) > (In reply to Andy Earnshaw from comment #33) > > Perhaps we could transparently pretend the selected value is: > > > > "1|234|5.67" > > > > and display it as: > > > > "1|2,34|5.6700" > > > > I don't think this would particularly matter to the user as any changes to > > the selection would be handled identically in either situation. > > If we do that then how would you maintain the selection when the user has > selected: > > "12|,345.670|0" > > ...or: > > "12,|345.67|00" I'm not entirely sure, I'm just suggesting potential alternatives to gimping the things we can do in the browser, hoping that we can hammer out the details of a solution once we decide there's going to be one. Do you have any examples of browsers implementing number elements like this? Because presumptuously formatting a number against how it may have been intended to be displayed seems like bad UI design. Maybe the <input type="number"> element should accept an LDML-based number pattern[1], giving the developer more control and knowing what to expect when playing around with the selection. > This is not the way to write good APIs. If you want to move the caret around > arabic text, use a text field, not an e-mail field. Why shouldn't JavaScript be able to move the caret around an email field, though? Because it's easier to just disallow it than think up a working solution? > > - Introduce a "displayed value" property and have the selection reflect > > that instead. At least then we're offering a way to fix the broken code. > > What if the "displayed value" is a bitmap, because the control is a pen > input control? There's nothing in the spec that disallows browsers from > making that implementation choice. If the displayed value is a bitmap, then it's no longer an input accepting text and the user wouldn't be able to control text selection on it either. Just like an <input type="checkbox|radio|hidden|etc">. Perhaps "displayedValue" isn't the correct term to use. "selectableValue", then, or "textValue", or whatever you like. > > It would just be nice if we could have a solution where code didn't have to > > change the input type to "text" before it could work with these elements. > > I don't understand why you would _not_ want to use type=text if what you > want is a text input. Sometimes things like that aren't in our control. Going back to my earlier example of the IME, for example. It's open source, someone wants to use it, they have an email input in their app because they want to take advantage of the native browser capabilities. The open source IME can't write to it because of how the API currently works. JavaScript coders can work around nitty gritty discrepancies between selected text and element value if we're given enough information, we've been doing it forever with everything else. I just have a hard time believing that there's no workable alternative to just tearing out pre-existing functionality. [1]: http://www.unicode.org/reports/tr35/tr35-numbers.html#Number_Formats 110776 40 ian 2014-08-29 19:14:14 +0000 This thread is not being productive; we're just going around in circles. You explain that you need the API and are willing to put up with the API only being available on browsers that don't do anything clever, I explain that the API can't work and that making it work only in some cases would lead to interop issues and force browsers to not provide the good UI they are supposed to be able to provide. We basically have two positions: you are arguing for enabling authors to do more now, and I'm arguing for enabling user agents to do more later. These are mutually exclusive. We're basically arguing about whose concerns should be rejected. Here's an alternative proposals for how to make progress here: For each use case that you have — having a script-provided IME that works with any text control, being able to determine whether a user's input will result in valid input or not so that the user can't enter invalid data, whatever the use cases are — file a bug specifically for that use case. That will help us focus the discussions on specific use cases, and will help us make sure we're arguing about how to solve solutions in ways that address everyone's concerns. 110783 41 stephen.cunliffe 2014-08-29 20:11:04 +0000 While I believe that creating a new bug will "lose" a lot of the thoughts in this conversation I do see that this is starting to cycle. I've therefore taken your suggestion and created a new bug to deal with the bad-timing implementation of the *removal* of JS APIs before the *implementation* of the only native 'correct' solution. https://www.w3.org/Bugs/Public/show_bug.cgi?id=26695 " Request that user agents implement the inputmode attribute BEFORE removing the selection properties/methods on extended HTML5 input types" 110871 42 ian 2014-09-02 17:20:21 +0000 *** Bug 26695 has been marked as a duplicate of this bug. *** 110973 43 stephen.cunliffe 2014-09-04 03:39:51 +0000 So this seems to be going in circles and attempts to mitigate this issue by ensuring that inputmode is supported before removal [1] of these methods isn't making any traction as it appears the w3c has no intention of suggesting that vendors implement a simple new feature before removing [1] an old feature. Thus this now seems to be a battle of technicalities in the spec vs. what application developers were used to (and continue to expect). For every example of currently-in-use-in-production use of these APIs on number fields @Ian Hixie shoots these down on the premise that in the future we can't guarantee that numeric input fields will be rendered in the browser as a horizontal box of characters. 2 thoughts a.) I have no issue with @Ian's thoughts here - I know my web history and thus admire Ian and his tremendous efforts... as one professional to another I merely want to open up the discussion and our minds to the possibilities/realities that we are dealing with. b.) Although I concur that agents may render a numeric input any way they please and it may not reflect our current concept of a number field - I'd like to challenge that in concept this is true, in reality it is not (see below) Keeping the APIs available (e.g. the status quo) on number fields sees its biggest challenge with those that feel these APIs may make no sense if vendors render these input fields differently. I agree (technically) however I'll argue that (realistically) this isn't possible. To explain why, lets look at the "requirements" of implementing a numeric input control. Requirements: 1.) User should be able to enter any valid floating point number from NegativeInfinity to Infinity 2.) Obvious invalid values should likely be blocked e.g. "chocolate cake" isn't a number in any language that I know of 3.) If the OS of your browser presents a soft-keyboard when this control is focused... be a sweetie and show a numberpad of some kind UX FTW So... how can we render such a control? we could use a slider! and the user slides over a range to pick a value! Well yes, but the granularity required to provide selections would require 2xInfinity pixel precision (just for integer values, not including decimals) thus that won't work... in fact the range slider is already its own field type "range" that takes a min/max/increment to solve the cases when you have a limited set of values. How about a dial like a volume knob? spin clockwise to increase, counter-clockwise to decrease! Well... same problems... decimal values can't be done easily and if you need to spin several thousand times to get to 100k this isn't going to work. Ok, how about a standard ~text~ box with up/dn spinners! (e.g. I think Opera does this) yup... that works... and the UX is improved if the user wants to bump up/down the value an integer at a time. However as history has shown... over the last 40 years that we've had GUIs... that we have yet to find an alternative to the "horizontal text box control" that meets the full requirements of being able to enter any number possible. e.g. the requirements are just way to broad to provide a better control. Yes you can add spinners... you could render negative values with red text by default... set the text alignment as "right" by default for LTR locales that feel this is a better default... and the control can be smart enough to not let you enter non (digit/decimal/comma/scientific notation characters)... but no one in 40 years has dreamed up a better control (usability wise) than the horizonal input to serve this need. (with the exception of course of a limited range of numbers (often integers only)... which we now have a range field type for. But wait!... when the iphone came out it used a funky calendar widget that was better than a plain input box! so we can't blah blah blah.... Agreed, calendar widgets have long been a better way for users (again usability) to input dates. Users can pick "This Saturday" much easier than having to know that it is "2014-09-06" and have to type that in to a text box. We know this because every OS/App we've seen over the past 20-30 years has implemented something special for this very specific **constrained** input purpose. As much as I'm open to the idea that browsers could render a different type of control for a number input in the future... the REALITY is that they very likely won't because it just isn't practical. What if the user wants to paste a value? what do they focus before pasting if there isn't a box to paste into? What if they are typing a big long "serial number" type number (all digits) and they realized they mistyped. Do we not want them to be able to put the cursor back in the correct position and edit their value? e.g. before: "123567890" (woops! I missed the 4!) "123|567890" (place mouse/cursor in-between 3 & 5 to type/tap "4") "1234|567890" What if they are typing in their odometer reading? "34538398|" "3453839|" (wait, it just changed (backspace!)) "34538399|" (wait, it just changed again) "34538|" (wait, it just changed again (backspace!)) "34538400|" (wait, it just changed again) Again, if someone can point out a better usability based control for numeric input that meets the requirements for a number field that doesn't render as a horizontal string of number characters in a box of some kind - please do so! I haven't seen one in the history of 40+ years of GUI programming. However if we can't come up with one, lets please put this issue to bed that some vendor "might" come up with something new that isn't capable of having a JS selection API! [1] Re: Removing these APIs from number fields. Yes it is understood that technically they are not being removed since they were "never" defined... except that they were... <input type="unrecognized"/> defaults to an <input type="text"/> rendering in HTML (and always has)... when <input type="number" came along if a browser didn't recognize it, it just rendered a "text" field which was a fine fallback. However if it was a modern touch device it used this "hint" to tell the OS... when this field gets the focus, show the numeric input field - not the alpha keyboard. (essentially this mimic'd the inputmode attribute's intentions) - sweet! So every developer that cared about usability switched their type attributes to number (where applicable) and boom! the mobile web took off! Then the specs for HTML5 pushed onwards and it was determined (back whenever) that the text selection methods shouldn't apply to the number field and thus in the spec they were not available as properties/methods. However since I can only presume that most browser vendors created number fields as a "subclass" of input text fields (or a flag on a text field) that by default they inherited all the properties/methods of a regular input field. Alas when Chrome dug deep into the spec and realized that these properties/methods did not apply, they *removed* them from their implementation. AFAIK they were the first (and ONLY to-this-date) browser vendor to REMOVE these properties/methods. We can argue till we are blue in the face that these APIs were never part of HTML5... but as a migrating spec... migrating from HTML4.x which did contain these APIs on input elements of type=text (or type falls back to text) they were implemented by ALL browser vendors already... e.g. they were the cow paths that developers were expecting would be paved. 111026 44 ian 2014-09-04 18:45:39 +0000 I encourage you to file a bug for each specific use case for which you want these APIs, as suggested in comment 40. The argument that we can't think of a better UI today so we should make it impossible for someone to come up with one later is IMHO a flawed premise. This isn't academic — we have seen this exact thing happen before with existing select controls. <select> had the same UI for literally a decade before Apple changed it in Mobile Safari. If we had constrained how the <select> UI should work, they wouldn't have been able to do that. 111033 45 stephen.cunliffe 2014-09-04 20:43:09 +0000 > I encourage you to file a bug for each specific use case for which you want > these APIs, as suggested in comment 40. There's no point because we've posted several already but they get turned down on the fundamental mis-match with this idea that a new solution for the UI will come along and render the past 40 years of 'textbox' input obsolete. > <select> had the same UI for literally a decade before Apple changed it in > Mobile Safari. If we had constrained how the <select> UI should work, they > wouldn't have been able to do that. This isn't quite correct. <select> as I understand it is a control that renders a set list of user-un-editable options. If the multiple flag is not set, then the control allows for a single selection of any of the options and a change event fires for developers to handle that selection. How this renders *is* up to the browser vendor. Windows has always shown a [_items_][v] box. Mac OS has a similar box (much prettier) but with an up/down arrow. Both will open the list (up or down on the screen depending on position) when focused to allow a selection. In fact in Windows 8/IE10 Microsoft changed their rendering to a open a box of options with a 2px border, an animation as it loads, and the list opens "centered" on the selected value for a better touch experience. In Mobile Safari (as well as Android & BlackBerry & Firefox) a different styled list pops up but the fundamental ability to select an option still persists. In theory a user agent could choose to render a select list as a "horizontal pillbox" but the fundamental concept is the same... render an ordered list of options, let the user select one. <input/> elements are inherently different. They expect the user to enter a *custom* value (not select from a set list). This is the root of this discussion. <select>, <input type="radio"/>, <input type="checkbox"/>, <input type="range"/>, <input type="date"/>(* [1]) are all forms of *constrained* input to a limited set of known values. [1] Ok, a date can be almost any value... but it is really 1 of 365 values for every year that we consider valid (for most people this is *currently* a value between 1800 and 2100) Providing a UI control with good UX for a set list of values is fairly easy and we've been improving these every year for the past 20+ years. However the opposite are *custom* value elements. <input type="text"/>, <input type="password"/>, <textarea/>, <input type="number"/>, etc. In these field types a user can enter almost any value they want, cut, copy, paste, edit, delete. My argument is that even though it is *technically* possible for someone to invent a new way to input a number... the reality is that for a number field that handles all of the requirements... there is nothing beyond a horizontal input box that can improve upon what we've already got. If there was, we'd have 100's of sample UI's for a number input to chose from (and Google, Apple, Microsoft, Mozilla) would all already have these controls in their OS's because they would provide a superior experience. I challenge anyone to provide a control for numeric input (that meets all the requirements) that does not at its core include a horizontal input box. I'd be willing to put money on it. However if we can't even dream up a single example that improves upon the existing horizontal input box - then why are we fighting over removing developer access to get/set the selection within this field? This is "cutting off our noses to spite our face". 111083 46 ian 2014-09-05 17:12:32 +0000 I'm offering to try to address your use cases. I can do that if you file bugs for those use cases. 112209 47 ian 2014-09-25 22:38:27 +0000 *** Bug 17986 has been marked as a duplicate of this bug. *** 128443 48 justinbmeyer 2017-02-13 19:14:39 +0000 I work on https://github.com/bitovi/syn. This library is used to simulate user interaction for testing purposes. It allows people to click and type much like a user does. We use setSelectionRange to control the cursor position. Currently, the library doesn't work in FF 51.0.1 with number and similar form controls. 128444 49 d 2017-02-13 19:21:48 +0000 As noted in https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796#c4, this is not possible in the form requested. In the two years since the last activity on this bug, nobody has taken the time to file their separate use cases as a bug (note: a use case is not "use setSelectionRange()"; it's something you actually want to be able to accomplish for a user of your website). Let's close this. If you have actual use cases, please file them at https://github.com/whatwg/html/issues/new. Again, follow the process at https://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F and do not focus on a particular solution (like making setSelectionRange() behave a certain way), but instead focus on what an actual user of your website is trying to accomplish which they cannot do with the current set of APIs in HTML. 1444 2014-03-03 06:25:44 +0000 2014-03-03 06:25:44 +0000 Example of custom input element usage time-entry.png image/png 13349 sampo.niskanen iVBORw0KGgoAAAANSUhEUgAAAScAAACyCAIAAACP5J5SAAAgAElEQVR42u19eXwURfr+W333nLkg kJBAEiC4JCxHYDkW5BIQs6CrCH5VRJSFFbzwwF3UXREWEQ9AcRdxAQ9UxAP8IXiC4qIIBNQETAIJ SSAJCZNrkszVR/3+6JnJ5JpMwkwEUw983s+ku7re7qr36XrrraNRZWUlEBAQdCIoUgQEBIR1BASE dQQEBIR1BASEdQQEBIR1BASEdQQEBIR1BASXHevOrZieHjXY5/+I2eMf3PaVpQMq6r66Jz1q9t6y ZifKDr1687KDZQDgzFwwNn3klnOkPgi6Ahh/J2NGPnFrMg8AzvrygpyPPn5/9lk4sGNeKh8U1XUZ Wz/e70wEAAB9SloqH2Mg9UFAWDdu3q3jzJ6/FqY9NPDJL98t+L/UZC7Id8En3v/ialIZBKRf1xTm mHBTowNVh7avHD8pPWpweuz0vy3/9JzDe8aZ/87Kh4aMSI8afNvMlQfPuZpnVvXO7XPmHgPIXDdw 8KL/FPh4mM7MBWPTZ+78csU982MHp0eNmH/z+oyykoPL774tdnB61NhFSz72Kmr9BggIrlTWOeuK SsqKSsqKSs5lHtv78MrDztRZ89wNXd2xtQ/NXJvBT7vnjY3LV42u2/bYfQs+rdLI8OGDD937flXa /Y/ueHFW38zNDx9rnnX4DWueW5kMkHzH7o+euqVn09OHVm3OGrP4673/3jGL27/1H6Nmbyufuuzr vRteGl337pPrPrL4vwECgivXw8x8ZcJ0378T7ntjUj/tp+Xg8u3lcbc+t/uRAQIAjEmNq71r9oad mRP+klqy+9nvpDErnt88IxwAJqX1sk7/x0fN8hZiesUbAZzhfROizc7ypqfTFrx067BogH53zhi2 /ZVzEx58aVaqANBv0eT1n+3eX+C6BVq/AZ5UK8GVy7o+1750/1AzAIBUY8nfv/39DXMfhjc2PDmI q8k5nAVh86YmCu6khrRpifxnxw9VQPeczDOQsGh0uPuMMXlOGvtRSftuKy450d2f5MMFgLi0XkLD n5IDwM8NpMaQaiW4clkXlTp9wihPNGXcLdOSHZNWbdhw+P7XxjkqqpxQvWnunzc1ukB/2uJyVtQD 6Ls3NDicOZKDdrKOj2QFvwn83ADEcKReCa5Y1jWBMXFMAuyz5JfDuO6RBoDuC198dE6jhoUz9+HM JXqA+vJaAKOne1jrCvp9C63fAKlUgis5mtIElsx9Z4GPSe4OYE4YmQLlxyzhqckDtP/mnN2Pr//y nAvMg0amwPl3DnlGxZ05Hx6Tgn7ffm6AgOBKbutKDm7bXqa5ik7L+f0ff3XI1X3homFmAIiZtGrG zpmrHrq5ZN68tHBHzr6nNxyumfBoXyOA8donZrw/e9VDt9fOm5fg2r998+sVAFHNc+fMRhZ+3rdh O3fD1PB237ifGyAguJJZd/jptYc9f7BxqSOfWLH4/kGaC2cYs+KlHX02Pr193dytAMbuE299dNV9 46IBAAyTlm94w7huxX/WzXbpU2bMe2nq2/cWtMC6lDtnDjv2/qa1r9YkL23/nfu5AQKCyxqI7FZE QHAZ9+sICAgI6wgICOsICAgI6wgICOsICAgI6wgICOsICAjrCAgICOsICK5sMKQImqDw/IXHn9uc mZN/vvQiKY1OQ6+e3VKTE1c+vKB3rx6/+YclM8KaUm78nPvCjDqeZWkKASCEAAMgIDJUEgAwxqqq 2h2S1Wb/+t0Nv3niEdY1wm33P30yJ08n8BRNIURRCDAgQoyQSgCMMShYxYpic7gGJie9tf4J4mF2 IWTl5gs8S9M0zdAUohAFgAk1QiwRwiqmVFUB4Dk2Kzef9Ou6Fs6XXhyQFEcxNEMzFE1RQKkII0AY iAyVBIyBBllRAIABfL6olMQwu2BUF1GI0gAIaIqiEAqSNExYuvylOb1595Hw8Uv/vuX5u8dHuNPw fW946ZlbR+rayoeNveMfyx5NEYJ5b6HIMzCJKIQQomkKURSFqK5hYwRNeroUAgQIIYwBUQhj0F7H wZD1OT9W6JISI7Ujhvgx3etK7ZFj+uoxBkB0j4HxbPkv2fYAcoMg3lUo8wxAAiBAABghSvtFRg66 HjAGhEEFTCMKYwyAgigtOfk1U+ITjXChFovxqT2qfn4z+3e3p8WIR0/bsT55gGD5Ps8KICZevXD2 iJQIBuxlR3bv2nKsUsZU5OBrF88YFG+SLdm5FSwAxkzM5JV/jcnJZpKTzGYRSn/cs27HaSvGYtKE hbOH+1xeITOR42Zff2NKtI6VawpPvfvWvqNVKm4pTwC61x/S75zSP97EADiKTnyxccfpuHn3zYdd y17LtQPCfMLi5enSto2v5qnBKhnQus8qxl3Fn7pyXxgMo9Pp9Hq9yWQKCwsLDw83Go0Gg0EURYa5 xLdJqIIHcnlOjhw5IoYDEBKHR9uyf8n6sUiKGZQoYDDGDg+vO5FXD+GDH7h7hPj9u0sfe3bZu8Vx N946J55iuo14YHZixd5Nix7buLUkMllk3HmKsYlV+55a8eK9L3wPg6fdGE9B+NAH7h4ufr9j6WNr PJczYsq0OUnFm576192P/fdje//bZ/YRAbeYJxMzfvFNMfnbN9798Op7Nxxnh1xzY28p59t86D0k WUAAWEwanizlf1mohiqi2VFjEEXRYDAYDIbw8HDNHrQ/g2EPXZ51CCFRFM1ms8FgYFmWZVmEEACo qkrTNE3TPM/r9fqwsDBRFLVT7W3rMADGOCRSLjtSCHEpkTTdfUy8nHXCYiv5OQdixsTSdM+retrz T5TJESnDk+zH3/y2qEaSLScPfJAnjBgb2z1tSM+q7985WiHJ9dmffXHELmPQWgbLF9+W2DCWqvJy 7EIPIxMxMC3JfvzNg4U1smLJ0i6Poe2yZEq8emLqwPC6/732wr1b82wAkS3lKZV//+ya19/Jq6d5 U6TorJEYk8DYzhzJgtirkzgMfPKoWOnk8UIpBOUDHWnrRFE0mUx6vZ7neZqmGYZRVVWzB4ZhvPZg MplEUSQeZkfA87wgCB56YP+S4ziO4xwOh9Pp7GCDF3zpzDtawU6JjYqJTISiLSUKyGVHCpk5A6OT mGgpb0+RTMd3E8A04p/PjGi4k0JjJAiStcam5SPXF1nlFO235LS5PPnLAAxt7i6AacQ/1/herpez d72865oZo655cOKfwFp8aPeuN36sM0e0mKeQPDH9psGxZqgrLalhWcYCAHLx11nyklG9xUJ6cm/H kU/K5FCVT/uMgeM4iqICsQeEEMdxDMO4XK4O2kPXZJ1Op2MYBrfzhai9Am02W7vY5q0whFBwZU3B SYspechws67ky0IJA3KeOVKmm/q74SAU7S2TsGyrckDZkUefPWzBGCFEh0WEKTXM2KvZGLOIsR0h THM9Rca3YcAYe+Z5KPWVDig7+sia7yoRwhizEVEmqUoK74XPfL722z2Yjxg67aYlcyYfyfrgYqWj eZ6Ro268K6XiP2vWHKmUEdt78T/nmAEwlvO+y5X+MmRIMhNvP/VmuRL0ktG8jPYag7emAneU2m8P XdXDpChKr9fTDI0xxoDbK2ma1hv03pdim1WDMYBmCqGQ1WczrbHThxuKjhTYEcIYW/NPlUYM/WNE 2aECByBUmnm8KGL07WN7iggJPdOWPrxoSZr5wrGjRRFjbxkdJdBc4tVTRpgYQAhjb/yn4feFkyeK IkbNHRcrYCzGjnjwoYX3jgg3pUxeuvhPw8MocNZftMqS3VmPcUt5MoyRAclZY5MBGfpPmZAqMkBj QEgqPv6DvfdN18XWfJ9ZKoWmZFBAjR1FUXqDnqbpDlhCh+yhS7Z1GEAQBIQQVnGHnRYESBCEepsN ta3O09Zpb2JvSxI0WXUiz3FddN2RPKdmadiad6Ly2iT5ZF4tYMCo/OjzW8L+Ouv2jdczINXlHd35 0v4KDBUvvGm+96aFG2+CmjM/ZVqjdc3aOvfvsiMvbDEvmnWb9/INX1kqmV1v975+7hOPLQKwleXt 2vp5vgy47EizPOULB/cdSLph2b+WS/bqohNHdhVHT+gdRv9YpsiW/52omzJJ/vy4BYJfJoG2dW5j 0IKfl+DEBm4PIYlNXP7zMHleYFkmKG6MoqgOh92PrqjB6QOS4hmGoRmGpshgZiOYhs9bPe7kk88f rQhB5oqqKrIsy3J2XpHlxz2tJRMEkaapYLm1bdpDF/UwKZpmGNoblbpESVGIbjOI7HXbAgjYdBXJ m3r0/t2sqZFFB09ZQqalzcaOpmmKQkGxhAZ7oGnCukZQVVXgeRWrABAsyXGsVuKtN//enlLwQylX qGR7jXvs/htSyw++frwuRFq0MvfTrVMxZlgmiJagSYZlOn9w/rLu1zEsq2IVAVIhmJJmGayofsbr 3HMmEKVijAAFXwqxo6eNnpjaOylCAACQ6koL8/Z/dfDrbKurSUpj78lTR49N7R1vYgDAVXkhJ/Po e5/+dM7RYe1c39FTbhqX1DfawAJI1gu/ZB55f09moSOAlBUOlkGqHJIy8cxT8TMOTlOICro9UIhi GFpVVNKvAwBQFFWv14Uo8/p6G01TLffrEuNphmYYFlEoFLPs9UkTly4c3Zdt4a5KDr235v3T1T4p ly0c3bt5Smveto3vfV2utls7EzFx/p13XNXsg5zWnH+ve/9wVYdSBkkqqqLKiiTLOfkt9OsUVRUE IZCetuOXV65deqCm29Rtm+8eFNi3shVVdTgcndmNv3w9TBxi+B2tAy1EFnxp6L+oFcoBQMyYm+8d Z3KnFBLn3tUS5QDAlDRv4cREur3aqfj0W1ogEgCYkv9616ieHUkZbNm6A0IhFFC9Oipzz1bl5lfa A7YEyjvu0sVZp2KMaKpjozGBSERRqn/ihUb2GDFxkIdI1Zmfr16x+q6HX1zxXk61R3XfSeMSGQAA 05CJI0VvG/jhE39bfdcTb753RnYfihh2/VV8+7Qbk/9vdJj7cnvO1rUv/vWJN3d4M4wdff0Avt0p O2VqCsaYolCg9duQU3vsASHcicy7XFmnqqC9/lQcCumNYrVYxyGTptQRns9n2rI3v33klwpZkuvP HNq9OdNj06bYARGAMZeU6klZ9tX6nacKbbJUW/jZhxmeHZSYnr3NbOP8e6QveWPd46+ve/yNdUtm daOaaBeThl7lIfwvH35yoLi+3lrwyXsHPV+MF4aOiRXbmTLI5dNKLEVRVQAIuH499dgee0DIraVL R1NkRWUZCmOsjYcGXwKWFZVpMWqM3NsKeKJqwZMsKxUXnJENZqNBV34qz+Y967KcrYNUrXlhwhgK kOv4f1bfpQuLj4+OUopLG/IBr8sp1TqlJvk3eYpGZ6n4Qd4tgCwZeTb38Yrs45UTYyIAALjeSVFs fpEUeMqglo+qepbctWAMDEKeofk267eh0WyXPSit2UPXYR3GmGMZwKBiFSEUdClwXK1kg9YbO4wx 9ppysKRk2f/6m/ubBUwBc5F9DN5wQKFV0Q67bNVnsqvPeFMykX+8fpjH87uw/1Q1bpw/btIrbnRW 6Bnr6adJ1SU2z1m5rtAKEOFuZnsyuFAKPCUEsXxw620dxljgOFUNqGa9uaiqCjhQe+BZzums7+pt nXsoUwsT+5HW8oLaJtEwzhQbHub/KkAqVlvzMBVVAUXFoFJqZ7nfEb+/YZCnIi78nFPlkpskMA64 a/6UtIRuYe6Wzn7qnR2flzRNZs3LPRoTzgGAVJVba5d9TzMR0d5lLpLVYXd5zqpWmwTuFpSPYF2y PeCUtcHtyauqoigqbtEYWq1Hx6mHpi7d2nyyTMUXU9K+8D0Qd9tLR5b15Vu3h87s112urMPY4XTx HOt/vCX7vUdHrS9vfGn3J3dvuz+hjVEal0tuNZqCMcYIN8zzCzHEXrf8ZUY/j5mf+vx4cbMbYyOu GtW/m94T3zi1c9Pqby1Ss5yqf/r4+Z9acx6EMG9VS7KrIYiLJZvs4RJjFmlcE3BKLAc7ZN3y9BQV Y5vdKQpcC7UZeCVhbVi8ZXuwO1wqYR1gcEkyxzKAtInIrUj/4ZDWr3VJsr/qCtkyn6aSjZux+K6Z cR69+Z+/driueUomIkrvQ9PfzXrg+X67n9lytFhq31Ia7+NJPk/XaFZC04UzbaQMwWIf7Mf3aaE2 uYT7//38Lc6GxeiO7G03r8x0Goe+vO7WflzDcb5nL6F1q1DVTh0lv0xZhygkyRIGHqtYW23Qoux7 538t85tXIVb9XoVVLCkSQzOtkxZhVUUUjVUVEAqV1CXOefCO6+M88RHbqfWbvitWcfOU0ukPljxa VS2H/37KjfdPi+cAug+e+fTt1iVbsm0B6qIbvWQYVdWeERDtY+eypBl34CmDWBoA0IrpUwhJsqz1 65rVJturf/84n9p34jAewMmFJ6X0HyY0so1WckBYxZIsM504IfMyHTmgELI5nKEL4tvsTqr1zR06 Y0qxmDD30bt9KJe/bc27h2paTu+quXjRKrtsF4/t2rb+R7drqR8+7eqIwDXabV6XlGU4n7Oszvv2 kavtcntShmACdIvGQFH1dkfA+XSkHuvtjs5cbneZtnUURcmy4u5bhWDfIFlWWitlrRpUjGnAKgAC CL4UE+YuW3CdNz5vy938zJufl8kBXGs/efQiDI4BAIBuw2P5TyyOgDRKtvN2ALPGJSPDYJC0s7Qo egcjasvqMQSeEgezTABr8Ufc0lAOkmRFkmSGodusWW8v1B0fCcAeZFmRZKUDW+z81ljH0BTPcRXV tZFmY9DH66pq6nmOY+iWWafVBRW6fcKYbtfed2cD5Wp+Wrfm3UMVTVIafj/q9wPjunWLDIeTe9Yd vOg9y/rMEWPbobeu5IIEPVgAADYsVgc/2gEBYCY8weS9k5ISqV0pg1kyDfRryRhEnrfW2cPN+kDq 1/cFGkh6a51d5PnW7KFrtXUCx5ZV1oSb9N5ZC8GSlda66Ahzq20dAMKgYghNWydcdeuCOxNZL+Ve fPqdQ9ZmKZluo29On6DN/e419L1DnxbL2lnD4FHdvA1OgUVSMfZeZRp8/V/GhbMAIFV9vn3XMatv ntLZE95GsvvofvpPLHUqADIlDPfMgXHl556XMLQjZXDbOlBb8TFpihJ5ruRipUHPa70vP/XbMDdF m3jSlj3IilJRUxvTLYImHiaFEM+xHMuUWqp6RIYFMVZWerGKYxmeY/3365DPJg5BlEy/aQ+MNnoV FZ8s0v1+xDWNZmk4Th/5qcBR9HWWfcIIEQAgavw/F1jXfXT8bH3YkBk3L072MNby0+elkmdREsIY 6xKSR6SEAwBAZcFHzNEayVd79ckfcuGG/gAA0H/2rMml7x2qjZ4yb1qsZ0DiyDeFEgC0J2WQyweg NQ+TYxmR5yyVtT26hfmvXz7lodyMhz1zHNq2B0tlrchzHMsQD1PryTMmvVhWUW3TO0We88agLkXW 2ex1Nkd0ZBjb+opyrKqIprCqAkVhd9QrWFI3/saR4T66Ykf/aeHoJvpr9+Sf3FrkOvnhvqwhf05h AQDCh8x4asiMJskOvPl5gQwYN+TfaNcwT4yxQXv10a3fXL366ggAAF3ywr8/sdA3v6Iv3jvpcJtj 4CmDVz5+YpgAwDC0yaArtVQZbHa9KFy6JXjtodbu6BkVzjCduqL88l3pQ9OUThSMel1B8UVZUbQp y5ciJUkuLLEY9TqdKND+nfgQxS0jU6YkBjRgDADYcnjNugO5UospKv+36eVNJx3+Y4DNzsq57/x3 U1ZL24TUZL2w8X/FHUkJnRPJpClKJ/BGnVhUWiFJ8iVagtceikorjDpRJ/CdvEfOZb1bkaqq9XZn eWW13elKiO1GUx3fpkaS5YISi8hz3SPC9CLfWqcuanB675huNIUwQjRFBXcgWBw4f8uDA7g2Htq6 56lnthRJ7qt0va+5cfLUlKSEKBYAXDXluTnHPnz/258qO7wjJd9//PTZkwcO7GniAFw15SdPHHjr g4yztktJGQSJAbCiYAwFJRdb3K1Ixbje5iivqrE7nH1ioljmkjawctuDwHcPN+t1AoUQYV0DFFW1 1tnKKqvrbY6E2G46ge9AJjaH82zxRb1OiI4IMxl0fl5sGusoBEBRnVwTXRwqxqCqKobCVlgHALKi 1NbbL9EYmtiDUS8ynb5h0eW+HyZNUQadqK19KiixhBt1PaLC2pXDBUt1Va1NrxOiwkwGndi2L+Ht iRMqdCIC2SaMoWmvMeQXX4w06aPCje3ijKwolqraCmu9wWMPzK+xR9gVsAstw9Bmg56mqMqa2uo6 e3WtrVuE0T2O59eRqLLWl1daASGzQRdhNhp0YqCdZhya9XVE+pftMQaWqaupt1dY63pGhhn1QpsO pyTLtfWO0opqhmbCTYYIk6Ed9tAFWYcAWIY2GXQMTfMcV1NXX1ZRW2qp0QmcSS9wDEPTlMhzGGO7 06UoqkuWrfUOm8NFIUrgWbNBbzbodGKgPWbsWWSJKQpU1b3gksgQS215P27rY1qaMWhuIc+ytTZ7 WWVtcXmVXsf7GoNWj772UG9zMgyjF0WjTjQbdKLA/Sqt3BXDOq+rqRd5lmV0Amett9scTkmSy6vq VEXFDZuKUgiAoimGovSioBN4k17UCrgds+y0926wQylEtrEfppt+gbV4NK3XCTzHGnSCtc5mczid LqmJMTSxB5NBpxN4TTIM/et22q+kb/pQFCVwFEvTOoF3uiSHS3K4XLKsKqoiKyoAMDRFUzTDUALH CRzLcyzLMHR7Z/poHx/wjNeFcM0BkS2sOQiUDBRCHOtu2VySbHe67E6n1xhUVaUoymsPIs9rQ+EM Q18OG+lfeV9IpmmKpjmOY/WqKisqxlhVVc1DobQPyiPE0BR1CUHIhndwCD6jQaQ/2X4PiOYojmVE gZMVXYMxIADcyB60YafLJVRxhYa8KIQomg6Fa4619cXaenKEQrLmgMjGUmmYTdqR1aUIISY0xhAq 6yUxa18Y9CKo2PPedW+XSFqhkEpVVRECwBgBKLIa2yPqN29mDGGaL/6YNuiHjJ8NekFVVQohFWOE IFiz/ohsTWJVBaBAVW1O1x8GDvjNm9kV8P26zkTh+QtXz76XYxDPMjRFQQe6GgQdGBrCoCiq3SXJ Knyz46XevXoQ1nU54i1fuzkzJ6/4goWURqchtkdUanLSqkcW/OYpR1hHQECiKQQEhHUEBASEdQQE hHUEBASEdQQEhHUEBASEdQQEhHUEBIR1BAQEhHUEBIR1BAQEhHUEBIR1BAQEhHUEBIR1BASEdT7Y e0961PSNmc6GI6e3zI8anB77YEZNw7GqD29Pj7p+Z5Gf7J2ZC8amj9xy7td9yLJDr9687GDZZXM/ BIR1LSBlQgKUZGfUNhDs2IFy4MD588HTXio6z+8rgLgxw7pf7s9Yl7H14/0lLgAA0KekpabFGEjF E1x2rItPS42D81/l1Ln/rs3+KIeduGhsXEXG3gLNfMFR8P2xWjZtQi/hCnpcPvH+F1e/PC2cVDzB 5devixk1xihlfVfu0AiWc/CYK/GGCdPTjNX7j1VpSWpyMs/BgBuSOY2W2558aOTY9KjB6VEjbpu6 bPex2hYcvQ8fnB01+N4VP2tkrjq0feX4SelRg9Njp/9t+afnHC37qBk3j0gfv73M23B9dU961Oy9 Xndx6va9D91+W9Tg9Kixi27fklHW9Pqqd26fM/cYQOa6gYMX/afAx8N0Zi4Ymz5z55cr7pkfOzg9 asT8m9dnlJUcXH73bbGD06PGLlrysfeWArtVAoJLYh2fMD0Vzh3LrgEAcJ0+kGntM3JMQsINqZD1 aWYZAEBd1oHzkDp2mBEAyt558OGHD3DTH1m++7WnXl2UeO6zzXPXZzc2zbqvVv7tLwf0C19b/eQg A0DdsbUPzVybwU+7542Ny1eNrtv22H0LPq3qwANkrN18ZsKykz+8e/yZ1HMb/jFzfX5jveE3rHlu ZTJA8h27P3rqlp5NLz+0anPWmMVf7/33jlnc/q3/GDV7W/nUZV/v3fDS6Lp3n1z3kQWCeKsEBH5Z B4Zh0xLg7OGsWgAo23+oOm7MsO7awZyDWbUAzvN7f5b6TkiNBoDa88cgYc4zy5+cMWpM2rA/z390 ZRqUZ+aXN+RWf2zL32a/75qz8flVaQYAAMvB5dvL425dvfuR6dPHjJr3+Oo3pnL7Nuz0jd8E6jOO fvDV+anRvCF+zOLN93U/8/7bhxo3s0JMr3gjABfeNyHa3Pz6tAUv3TqsX0zcpDtnDAMQJjz40qzU fjGJtyya3Bfy9xe4gnirBAQaWt2FNjp1WF/Xl/tLXJMiM/cW6Mc83ksAEFLH9XW9/1GOa1JMTkaF fkxaNACAcdjzrw0DgBrLudMF50/nZH50FiCq4Yva5z5+dmZBOT9h+aox4R7v9HAWhM2bmujpExrS piXynx0/VAHxJXvXHzrvdXTvn9HGA6RMS432/I5LS+2+IWN/iWtSMhfg88clJ7qpyIcLAHFpnm4q Hy6A5PB7q6kxxH4Igso6iBmZFvn+oZ+ryqK+zeKSH9XsOGbYpJjX9x46Xzbo8Glj6hMJmnG7Tn+8 ccnarzJqAYCNSx0Q36RrVlA1LC0s48Dm9TnDnkzmAMBRUeWE6k1z/7ypUUL9aYur/Of3N2z1NJMx 3C0zUv0/gGBkfRo+PQ/15bXtaSojWf/RID+3CjEcMSCCoLKO73VDMrv3u/wsLt+ZvCDF6D44PZXd dCw7oyIfkhdrBx05225/8ivnjHt2Lxo3LMYgQN3eu+f4unndb1q9+xF4+oaHNzy5+5Yds/oBCJEG gO4LX3x0TqPmgjP34eIHbbHMbxRNafzxaammMalqLPUAnpGA2vIa0McZg1lAfm6VWA9BcPt1AGBI mdbLmbNvW2a9jxfHpUwbwBd8te1Yfb8JydFudzHzDPRauGj6mBiDAAC1OXvPAjhd3oxMMXqBH/Do 8pGmnNcf3lkGAOaEkSlQfswSnpo8QPtvzhr+tAAAABPgSURBVNn9+Povz7ma3wYn8FCeU+WOkdTm 7ytodDrr4wzPMH1dxs5MqzF1UlD50J5bJSC4VNZBdOqwuJLj+0rCxqQ1DHCZU8em1ObsL+k+0XPQ 3GdAdzi/af3eQz/nHzu096F7Vr5bAeCqbxJuMI9Z/Nxo9tDajR9aAGImrZoRlrHqoZvXf7n3UMaH W1bOfPLbTH5AX2NLTW4qW/7xs/du/3Lvp7uX3PPs3iYJMl+ZuWznh4cOblv5t5s/qx9z37wxfFPe mo0s5OzbsP3gsdr2l1Dgt0pAcOmsg5iRYyIBjKnTfVuPqNTpfQCMyd6DwqA7djwy0vzdKzPn3jdz 1T7ntBUHViRASU5m088EhP/58XnDXMcfXvt9DRjGrHhpx30Dyj9eN3fxP/6yNb/frY9+9sy46BZu Inz6isefGA1frV0398nd5WkPvDGj0WSYvjctmF67+97Fzy7/jpuzYsMbs5rnwaXcOXMYn7Np7avb CqT2F1Hgt0pAEBCu5O8cODMXTP5b5p3/Pjw/jlQkwW+lrSMgICCsIyAgHiYBAQFp6wgICOsICAgI 6wgICOsICAjrCAgICOsICAjrCAgILgEMKYImKDx/4fHnNmfm5J8vvUhKo9PQq2e31OTElQ8v6N2r x2/+YckoeVPKjZ9zX5hRx7MsTSFACJFCCTEwAMZYVVW7Q7La7F+/u+E3TzzCuka47f6nT+bk6QQe 0YhCNIUAAwLAQGTIJAJQMVYxVmXF7nQNTE56a/0TxMPsQsjKzRd4jqYpmmEphBCFAGNARIZSAsYY VEVVEOIxzsrNJ/26roXzpRcHJPWiGYamaYamABAg0h6FVlIYVMAqUrEMDKueLyolrOtyoBCFEEXT FEIUIPe/UNodP/rBpXfGNruP4j1L34v++5KYD1e8cdQeVI10zG1/v7XHBxueO+W8HJiHVUwhBBgo iqKULhFUJ6xr1tMFzesB8ARSMMYIUMik84fXNuYwCAOXctvdc+T/t/rdc/WAkVxvM3bXtEOQNQLu jOcKWCKkYtX9fusa0asrmHUMw3AchxCiKIqmaYSQJEkAoCiKJEmyLHc0pIYAY4wQIABAGHCopVxr tQAGEGpkGSTbxapqOyAAzBgRsPqUmXfMGR5rBkfR0X3rdmTb4qeu+Wvkm09t/9GBMNPztr/f1vOD 9S9WjVv515j8EvOIJCbr7Z0nrppyY0q0jpVrCk+9+9a+o1UqBipy8LWLZwyKN8mW7NwKVosdMr1G pt85pX+8iQFwFJ34YuOO03Hz7psPu5a9lmsHhIWExcvTpW0bX81TQ1oCCFEKUrS/O2wMLMvSNA0A LMtqZA6KPYTEn7oS+SaKotFoNBgMLMuyLEtRFACoqsowDE3TPM/r9XqTySSKYkdYh8HTwvwKUmuH fI6EpTDH1z2+5tFXT+mGX3NjHOVzn9j3NyvGxhXveXzV6+/BuDlJxZv++a+7H/vvbnv/22f2FjBm uo14YHZixd5NC5dt3FoSmSwyAED3HL/4ppj8tzbe/fC/lqw/zg655sZ4KefbPOg9JFkAjLGYNDxZ yv+yUOmkEugQ6URRNJlMer2e53maphmGUVU1iPZAWAc8zxuNRo7jKIryX4UIIY7jjEYjz/Pt8zC1 8AlCGHe2BAwAjY+AZd/erCK7Upl/4kSl0COS9XJTS6PRVEv55bdnSysrquplyZQ4ftKggeF13732 4r1b8x0IRaYN6Vn1/TtHKxTFlv3ZF0fsMgZQLh5+ds3r7+bbaN7cTeeskRizyNrOHM2C2KuTeISE 5FGx0skThVJnlQAgjDtiDJpfGiJ76Ooepk6nYximyWu+LQoh7RVos9na1dapGFMIqdg9mtQ50tvW NRyRnNU27YgsAbA+D6769NB8U9Zn73p51zUzRk1+cGI6WIsP7d71+o915ghBstbYtKvk+iKrnAKg Yj55YvpNg2PNUFdaUsOyjAUwyMUHsuR7R/XmC+nJvR0/fHJBdvcAQ/7sanvaug4YQ8fsoeuyjqIo URRpmtb89fZKmqYNBoPNZtN8jwC6dr9aSK+J9ib3AwBYlgEYxn1EMIvuCBB40rDh0Tjvi7Xf7sFC 5NCpNy6ZM/lI1gcXKx1sjFkEsANghu8pMgAQNerGu1Iq/rNmzZEqBTHxi/85xwyAQcn/Llf6y5Ch yUy8/dSb5UpnlkCAxqDT6bztWyfYQ1f0MDGAIAiIQqqqYsAdkwAgiAIOVOFl0q9raHyxp7sp11bU sNHjh3QXaFPKlLGpLNOkL2pKmbz0nvThYRQ46i5aZcnurMf4wrGjRRFjbxkVKdBc4rhrRpgYAJox MiA5a2wygL7/lAmpIgM0BgCp+PgP9t43XRdb831mqdSZJRCYMYiC1gnsLHvokm2dwAsURWEVI4Qu RSJAoiA6HPY23RCMAdr/Bg2CdGvHmnZPE+Y+6/5t/em/uxIXXXf3xpvk0hNHDpRFxjdOWfH97rd7 z5z7xGOLAGxlebu2fp6vIFx25IW3zPfeuHDjTVBz5qdMa7QOyxe+/fRA0vXL/rVcslcXnTi6qzh6 Qp8w+scyRan434m6KZPkz49bOq8cVBVQ2wEVURC14HIn2kMIRqcu83mYmm8ZxAp2Op2KorSmLmpw +oDEeIZlaJqhaarLThgxjZi3etzJJ58/WtFZGhWsKpIsK3J2XpHlxz0t1o4WkAwu4f3bQ1f0MFWM OY4LrhvDsqzq35Xp4nO0eHOPPr+bNTWy6OCpil+ra9uKMbAsG3S3tm176GoeJssw2pA1Boy04dRL lwgxDK0qqt9unSdsh7U5S11IsrFjH1vye/jl82eO1+FO1d5Gx45haO8slk61hy7FOkVVWY5zv5NQ MCXNMJLkoCnq14tickmjp8wal5QUbWABJOuF7MwjO/dkFjk8aZjef11x+x/aGtTN/u/aZ7Jc7dQu JI2+prHqozv3/FTkcKeR8v7f/Q/uCSRlsKXqJ4qpqCrLc4HUr/3UxmuXHqjpNnXba3cP4oJlD12G dRgDRSGs4oYaCZKk/I7GYs86S/ebXmvxgijpiAl33TnvqoZPxLKmHqljZqSmJr+ybucPle4FfYE4 PdjzSgpUOxs5YX5z1X9KTe3/yrqdP1R1KGWQpKfMWzcGbQZZW/WLnZW5Z6tqaivtnkHAS7SHLtSv wxjTNBW6ILXWk/41mjo6/k+3+FpzA0zJ99w1umc7hq5kmyS3Rzsdn+5XdUdSdsaAHcaYohFc0sS6 S7OHLtLWKapKURRgUEFFgIIvESiqytB0S4zDvm5tkOfXG5P/b3SYW5M9Z+vLnxyxdht/xy2z+zIA ALGjr08+9u9sF5YuHvho7xmRbtoPYWKn/mlgNwAAqD7+4evZivs4xghQj+uWrJmsZV6951+v7CxX G2k39PdRnb3t5X2HrZET7/i/m72qB2S8ku1oX8rglYyfWSaaMWg9ujZr1oerKuAg2EMXYp2sqCwK tKA7IDFgRWmtlEO4wkDsO/Qq1q3ml48+OVBsAyj45L2DY/8+MQYAQBg6ppeYnWcD2y9HMn5p1htM nTtOoxyU/bD+7dzqpvn7ewpd3zQf1fv2F9cB1O9575s//n2SR3WsLjvf1p6UQS0ftaWncBsDg1Cg r2Dc0E8I3H782kNX8jA5jtEKLhSSZzmltdlAIZx7QcWnevfhsWScqXcfr8g+7hk05XonRTEt56Ab cN09QzWvr/qzt78603zWSOMCbCzpOO+35cGScbrOfbwyJ6OiQXUk3a6UnbTmAGMscFzg9euZmxok e+g6bZ02Qa7tmFVtWaG1Sd+ANcdEmAOIXPnx492ZBT+SIvSM9XSWpOoSm+e4XFdoBYjQOk6xPRko kppdy8ReP2ugHgAA6o9//GGB0jx/e0Fexi9mFgCkmjy70visEOOjutTuOS7VFdUCRLpVx7BQJAee Mpjlo0XNWuSdqqqt1qPj1NKpS7dWNLum4ospw77wPRB328tHHksSOmQPXYZ1GAcSvczd8ejI9eWN L+3+5MfbHujTduSqtbFRRZEBqSpWaIoO8qQnOjzaOxggWR12l0vSzipWmwSgeXV8BOtyWZtea/rD NdM0i4dzb7yXa5VbyP/i8Y+eO9GKdjYiWmhQbbc5ZUU7q1rrG1SHM04ZAk4pB3OOCAasyIqq4paN obXoJQS+TgFj9wKH9tlD1xo5sDmcosC12QVv0SFpc8sDm93pf9AChcTJFMO85S3JLp+zkk32GDRj FmkAudG1dOxN17m/vV79/SffWX1CPoFKIYz1Ue1zVrI3qA7TMdgacMpKOehOZmsD5Ta7UyfwLdQm l/DAv1+4xdXg6jiyt968MtNpHPryutv68Q3H+ZheQuubVvi3hy41Sq5or8CGuGIz2Xf+Fsv8Flij Yn9XYcCKqvjpUoLb38BBjo03MiksYc9gW6P3NcNi7N3dRJP630282qydvbj3s3OuDuzR2Ug3dmGs aUWNzJxhtWdvT8qgzQPD2P2/FWNQsdpSbbK9kvv38knpwGE8gJML75vafxjfpM1UO2APXSiaQiEk S4pGulBIWVKotjbGwSGTvi+8ZsdlqelxQ9qU/px2Mv+7r8suVS8AsC0fl6X2pwxd+TQxhoDr12cI KKj28Ntv6yiKqrfXmwy6EI3X1dsd4WZjG80dBNvRx/Z6yWvOWpvmPsGI3oqQq2xSoze+6arpie6f ud+erO5Y96Mdqjt0k8GIWrfWZdCMwWgQAxqvwz4tGw6OPXSVtg4hJCmKJAe/54AxlhVFUhS/m8D5 9DGCKGV7iXcxF2tkGe9ZRi96+1K1F+sbXWUeOLSP+1TJN7l1HdQu2RqpZr1n6Uaqbe1JiUNTSq0Y g6wo7VkaG1x76BptHUNTIs/X1NkiTIagz8OssdpEnmdoqtWXrhbSohCoKqAgSmvxBQl6sAAAbFiM Dn60qYAQUObeJo/6mpJiCXDDVWK/YT09g2e5WRdV3Hr+YYNmLBgXwQIGufqLtz46Wut7tq641Ee1 oP5oQ6CqwIY3Uu1UMQSeMpjl42ceptsYrLaIMEPb8zB9GrsA52H6t4cu1NbRFCXyXGVNnaTIuCG+ EQQpyXKltU7kOX9zzH22TgiqlAtOeL/O1X1MP737uDlxRJT7qCs/t1jyuYqOGh7nbmHqz+Ze9Ju/ LiF5REr/ISnJQwb376djGp+VCn70Ud3f4D5uSmikWm5XyuCWT1vGYK2TZLnN+uVTH87N2HXh8/uG 8sGzh67jYXIsI/KcpbIWBxWWylqR5ziWadWjwCFEVdbhXI+e/rNnTe6jFyMSZs6b5tlw3X7km0KX 7wVizz7u6CWUZ5e5/OcOjSMJHVXd7psMHlrzMENkDAHZQ5caOWAY2mTQlVqqDHZeLwpBGYq1O121 dkfPqHCGaXvGXUgm1lsztn4zfvXVEQAAuuSFf39ioa/Koi/eO+nwTc9Exnf32HrxBQe0ZxF20zTW jC3fjH/Gr2pob8oQ7I/m3xiMDkHkuWANzbfLHroE62iK0gm8UScWlVYkxXVnacY9mbWjUlHUwhJL hNmoE3g/7gTGGGFo9D2AYEop953/bopcsjCl2ZLVmqwXNv6vGDdKz5rC9R7WlddIGPvLv/iDZ278 wM/gh3Q6ANXtTBk86Xe8zmsMhSWWvnHRNE1diiW0yx66kIfpfcOZDTq9TjhbfNElS96Bzg5IWVHy i8v1OsFs0LX5YgvtFnTyxc9e/Ndjb35/otTq0rpJNeUnvt7x0ONv/M/SbFcP0Ts7Sy53XbJ2qfzz dasfe+P7E6W1vqqXLn/9UEVHUwZ5AnTbxpBfXC4rSoctoQP2EPwO1GW+R5isKLX19rLK6nqbo09M VMdcTbvTdbb4ol4nREeEGfWinwUdUYPTe/eMoiiEEaIp6lfYnK+rSgyAVRVjKCy52NoeYb7GkBDb rcOuZuD20OU8TE/UmDboRG0VxtkSS6RJHxVu1IopkHenJMuWqtoKa71BJ0SFmQy6gIrYO4GLyE6T qud3gMaQX3zRawyBt6Uds4cuxzqPa6GnKYpl6mrq7RXWuh6RZlNbryhZUaz19gsVNQzNhJsMESaD QScGHkRRMaa17xwQ2SkSIKBZ/x0zhkuxhy7KOgTAMrTmCfAsW2uzl1fWlZRX63W82SCyNM3QtMCz CCGbw6moqkuSa+uddTYHwzB6UTTqRLNBJwpc4G+1ht2Xf72t17uo7KgxGHSCUc9zLKPFXTRnMlj2 0BVZ5/Uu9DqB51iDTrDW2WwOp9MllVXWqoqKPatgKYpCABRNMRRlMuh0Aq9JhqHbMbfV97tw5Lvh nbb3rDuG2XFjKK+q8zWGoNlDV2YdAFAIcSxD05TIcy5JtjtddqdTllVFVWRF1aYO0RTNMJTI89rQ J8PQHQkKN3xpgMhOktDOydT+jUFVVYqigmYPXZl13qEbmqM4lhEFTlZ0GGNVVbU1yBSFKIpCCDE0 RVNUx2YbaF9HxqqKKAqrqvbhCyJDLUHb1audQ1mtGgMCwMGxB8I6H/8eIe0LICHIWftkKlI14pG2 KPTS7WEiCrB6WRlDVxwl73wY9KLWNwBVxQhURXGPIxEZMqlijLVV3qqqKDi2R9Rv3swYwjRf/DFt 0A/HfzboBAygxbM15yeEa8mI9JmHaXM4/zA0+TdvZpf73JRORuH5C1fPvpdjEM8yNEX5/7YTQdCG hjAoimp3SbIK3+x4qXevHoR1XY54y9duzszJK75gIaXRaYjtEZWanLTqkQW/ecoR1hEQkGgKAQFh HQEBAWEdAQFhHQEBAWEdAQFhHQEBAWEdAQFhHQEBYR0BAQFhHQEBYR0BAUGH8f8BeyM9BarpuMgA AAAASUVORK5CYII=