| 00:30 | <Domenic> | terinjokes: yeah, IMO conversions should throw; we've been adding a few tests for that. |
| 00:30 | <Domenic> | That said symbols should maybe get a special exception? |
| 00:33 | <terinjokes> | Domenic: as a user, i would be a tad surprised by console.log throwing |
| 00:34 | <Domenic> | I mean, would you be surprised if the argument was { toString() { throw x; } }? |
| 00:35 | <terinjokes> | i think this goes back to the conversations about if console logging is observable |
| 00:35 | <terinjokes> | i don't remember the resolution to those |
| 21:48 | <Domenic> | How do you rename things on MDN? https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs |
| 21:49 | <TabAtkins> | Domenic: There's an "Edit Page Title" right under the page title when you're editting. |
| 21:49 | <Domenic> | TabAtkins: thank you.... -_- |
| 21:49 | <TabAtkins> | ^_^ |
| 22:31 | <pygy> | Hello, I just noticed that some types of input elements (like `input[type=number]`) do not provide selectionStart/selectionEnd getters (and related methods/properties).) |
| 22:33 | <pygy> | There's Bugzilla issue on the topic, closed as wontfix because the W3C spec doesn't mention that functionality for type=number... It would be nice to have those though, for UA whose widgets are plain text inputs that can be selected. |
| 22:35 | <pygy> | Should I open an issue at https://github.com/whatwg/dom, or is it a lost cause (if so, I'd love to know why). |
| 22:56 | <TabAtkins> | They're not provided because type=number/etc don't necessarily have text-based input; there's no guarantee that a selection can even exist. |
| 22:57 | <caitp> | it should be mandatory that they don't have text-based input. I hate entering dates and stuff on mobile browsers without the keypad UI :< |
| 23:03 | <pygy> | TabAtkins, That was my guess, but it would be nice for UAs that do implement them as text fields to provide them (be them noops on other platforms). |
| 23:04 | <TabAtkins> | UAs shouldn't do that in the first place, and having APIs that work differently like that encourages bad design - it's easy to test on the one browser you usually use, and not realize you have a broken site for someone using another browser. |
| 23:05 | <TabAtkins> | (By "shouldn't do that", I mean "provide text-based input"; like caitp said, giving better input methods is *way* better for the user.) |
| 23:05 | <pygy> | My current problem is: I have a client that wants me to emulate `maxLength` on an input[type=number] field. It can be done in JS, except for taking care of selections. |
| 23:06 | <pygy> | If the field has reached the limit, you can't select some of it to type over. |
| 23:08 | <pygy> | What would you suggest as a better input method for numbers on devices with a physical keyboard? |
| 23:08 | <Domenic> | pygy: you can do max="999" |
| 23:09 | <Domenic> | pygy: a better input method is e.g. a keypad (with no selection allowed) |
| 23:09 | <pygy> | That won't limit the text size |
| 23:09 | <TabAtkins> | Instead of preventing typing, just show a validation message if the .valueAsNumber is too large? |
| 23:09 | <Domenic> | Yes it will... |
| 23:09 | <Domenic> | It will limit it to at most 3 |
| 23:11 | <pygy> | The field will be marked as invalid, but you can type more http://jsbin.com/kalijiridi/edit?html,output |
| 23:11 | <Domenic> | Sure, yeah, that's what I meant |
| 23:11 | <Domenic> | You can never stop people from typing more, even with maxlength="" |
| 23:12 | <pygy> | But maxlength doesn't work for numbers |
| 23:12 | <Domenic> | (Well, depends on the browser UI, but again, you're using browser UI, the browser gets to make the decisions.) |
| 23:12 | <Domenic> | Indeed, you're supposed to use max="" instead for numbers |
| 23:13 | <pygy> | Are we going 'round in circles? |
| 23:13 | <Domenic> | Yeah, seems like |
| 23:13 | <Domenic> | maxlength="" is not a guarantee that you can't type longer. Several mobile browsers just make the field invalid, I believe |
| 23:13 | <pygy> | Around a hole in the spec? |
| 23:13 | <Domenic> | The spec doesn't prescribe UI |
| 23:13 | <Domenic> | So this cannot be a problem with the spec |
| 23:14 | <Domenic> | It is valid per the spec for input type="number" to accept the string "nine hundred and ninety nine" |
| 23:14 | <Domenic> | Or perhaps more realistically, 三百五 |
| 23:14 | <pygy> | The hole is the lack of support for selections in text fields |
| 23:15 | <Domenic> | How would you "select" a numeric keypad? |
| 23:15 | <Domenic> | It's not a text field |
| 23:15 | <Domenic> | If you want a text field, use input type="text" |
| 23:15 | <Domenic> | Another valid UI is a dial |
| 23:15 | <pygy> | If the UA falls back on a text field, provide selction-related properties/methods. |
| 23:15 | <pygy> | Noop out otherwise |
| 23:15 | <Domenic> | As explained above, that doesn't work because of cross-browser issues |
| 23:16 | <pygy> | What wouldn't work? |
| 23:16 | <Domenic> | 19:04:48 <TabAtkins> UAs shouldn't do that in the first place, and having APIs that work differently like that encourages bad design - it's easy to test on the one browser you usually use, and not realize you have a broken site for someone using another browser. |
| 23:17 | <Domenic> | (having APIs that work differently depending on platform, like you suggest with your "if... noop out otherwise") |
| 23:17 | <TabAtkins> | It's also valid, in particular, to type "00009", which will contain the numeric value 9, and send "9" when submitted. |
| 23:17 | <TabAtkins> | There's no reason to prevent people from typing that if it's a number. |
| 23:18 | <TabAtkins> | If it's not a number, but just a string that only contains digits, then you want to use type=text and inputmode=digits, if I recall the attribute value correctly. |
| 23:18 | <TabAtkins> | And then you can just use maxlength like normal. |
| 23:18 | <Domenic> | Yeah, if your goal is to limit people to e.g. between 0 and 999, trying some maxlength="3" equivalent will fail badly on 三千 (=3000) |
| 23:19 | <Domenic> | Maybe that can be helpful in convincing your client :) |
| 23:19 | <pygy> | I'll see how `inputmode` gels with the accessibility team, thanks. The site is French/English only... Arabic numbers only. |
| 23:21 | <Domenic> | Sure but lots of people visit French/English sites from other-language phones or computer OSs, which is what input type="number" will care about (the OS's settings) |
| 23:22 | <pygy> | Positive integers... So I'm already filtering out non-digits with JS. Those are weird requirements, I agree... I'm several steps removed from the people who make those decisions, so it's not easy to argue... |
| 23:22 | <Domenic> | Heh, yeah, I've been there... |
| 23:23 | <Domenic> | All I can say is HTML designed min/max for this use case, so hopefully that'll work for those folks... if not then they probably don't want an actual number input, but a text input with some restrictions, yeah. |
| 23:23 | <pygy> | It's an insurance site, to order insurance products in Canada. |
| 23:23 | <Domenic> | I hear Canada has a lot of Chinese expats |
| 23:24 | <TabAtkins> | What's the actual "number" you're putting in? |
| 23:25 | <KiChjang> | Domenic, truth, i am one |
| 23:25 | <TabAtkins> | Again, is it a real number, or just a string that's limited to digits? (That is, is doing math on the value meaningful, or is it just an identifier?) |
| 23:25 | <KiChjang> | vancouver is dubbed as little Hong Kong |
| 23:25 | <pygy> | Money amounts. |
| 23:26 | <pygy> | Used either to for comparison, or to be sent over the network (as floats, yuck) |
| 23:27 | <TabAtkins> | Okay, so then yeah, just use <input type=number max=999> or whatever. That's literally all you need. |
| 23:27 | <TabAtkins> | (Remember that you have to do validation on the value on the server side, too - there's no way to prevent the client from sending whatever random data it wants.) |
| 23:28 | <pygy> | I know, the server is none of my business. All I have is a schema, and an endpoint. |
| 23:28 | <TabAtkins> | Also: um, you might want to kick it up the chain that representing money as floats can sometimes have legal consequences when pennies are added or lost. They should be integers representing cents, or whatever fraction of cents you're legally required to work in. |
| 23:29 | <pygy> | I already did |
| 23:29 | <pygy> | to no avail |
| 23:30 | <pygy> | I asked for amounts in cents, as integers, it fell on deaf ears. |
| 23:31 | <pygy> | The server sends non-integers amounts, and I convert them immediately to integer cents amounts |
| 23:42 | <pygy> | Thanks for the discussion guys :-) `input[inputmode=numeric]` is the actual value (which isn't reflected as poperty on the element) |
| 23:45 | <pygy> | Well "numeric" is the value, and "inputmode" isn't reflected... the previous sentence didn't make any sense :-) |
| 23:45 | <pygy> | Bye |