Re: [whatwg] proposal for new inputmode: digits
On 25 July 2016 at 14:59, Nils Dagsson Moskopp < n...@dieweltistgarnichtso.net> wrote: > Eitan Adler <li...@eitanadler.com> writes: > > See also the remainder of my email. > > I do not understand. What do you mean? > Please re-read the original email of the thread. I am arguing that *neither* nor are correct. While I could understand a keyboard which only allows "allowed tokens" this is entirely infeasible given modern regular expressions are Turing complete. In fact, they are infeasible even as DFAs considering valid values depend on future input. There is room for a "digits only" inputmode which is *already* a mode supported by some mobile browsers. I'd only like to make this explicit and non-magical. -- Eitan Adler
Re: [whatwg] proposal for new inputmode: digits
On 25 July 2016 at 13:32, Nils Dagsson Moskopp < n...@dieweltistgarnichtso.net> wrote: > Eitan Adler <li...@eitanadler.com> writes: > > > At the moment if you'd like the user to enter *only* digits (no > separators, > > +, -, etc.) you must resort to a hack > > > > > > > > This results in a correct "digits only" keyboard on some mobile keyboards > > (and nothing on desktops). > > Why do you see a problem with that? > Since this is semantically confusing and quite magical behavior. I don't expect a different keyboard if i provide pattern="hello+ (world|to you)" > > > There are several use cases for digits only, but the main ones that come > to > > mind are TOTP codes, CVV codes for credit cards, etc. > > > > > > > > might work, but is non-obvious and still results in buttons for "+", "-", > > and "." in some mobile browsers. > > This is wrong; text containing only digits is not a number. > I know its wrong. Hence this post. > In addition, it may be useful to allow minlengt and maxlength for numeric > > inputs. This can result in better error messages where the value to be > > entered needs to be copied from somewhere, and so the minimum and maximum > > are really proxies for length. > > Please continue to use text input elements and the pattern attribute. > See also the remainder of my email. -- Eitan Adler
[whatwg] proposal for new inputmode: digits
At the moment if you'd like the user to enter *only* digits (no separators, +, -, etc.) you must resort to a hack This results in a correct "digits only" keyboard on some mobile keyboards (and nothing on desktops). There are several use cases for digits only, but the main ones that come to mind are TOTP codes, CVV codes for credit cards, etc. might work, but is non-obvious and still results in buttons for "+", "-", and "." in some mobile browsers. In addition, it may be useful to allow minlengt and maxlength for numeric inputs. This can result in better error messages where the value to be entered needs to be copied from somewhere, and so the minimum and maximum are really proxies for length. -- Eitan Adler
Re: [whatwg] A plea to Hixie to adopt main
On 15 November 2012 19:20, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett ...@gmail.com wrote: Con: Adding a main element adds redundancy to the [role=main] attribute. I don't see why this is a con, if main is mapped to role=main in the browser it means that authors won't have to. Also adding aside/article/footer etc adds redundancy to the matching ARIA roles. Redundancy tends to be a source of error if they get out of sync. If one browser supports [role=main] and another supports main, both would be needed to provide compatibility. Obviously this is a bit contrived, as browsers supporting main would likely also support [role=main], but older versions would not support main . Going forward, this would mean that authors wanting to use main would have to use main role=main for backwards compatibility. Actually, there's a good point: I would actually add this: if main or an element with @role=main exist on the page, there is no need to run the Scooby-Doo algorithm and that element can just be chosen as the main element. What if both exist but are different elements? -- Eitan Adler
Re: [whatwg] Regarding Downloading a webpage.
On Sun, Aug 1, 2010 at 6:06 PM, Narendra Sisodiya naren...@narendrasisodiya.com wrote: A html webpage can contains js, css, image files. If we leave the server side scripting part then all resource files will static. JavaScript may load a resource (like another js/image/css file or DataURI) dynamically. If I want to download a webpage, I have to look at the source code of html and also JavaScript code which may load otherfiles on user interaction. Is their any specification exist by which i can tell 'webpage downloader' application about 'list of all files which may be use under a give web application' ? Take a look at http://www.w3.org/TR/html5/offline.html Specifically http://www.w3.org/TR/html5/offline.html#manifests -- Eitan Adler
Re: [whatwg] input type=location proposals
Seeing your 2c and raising you a citation needed. ;-) But to the point at hand Would the @pattern attribute cover the use case of lat/long inputs? (albeit without a nice UI) Possibly. I personally think that the UI is worth adding it to the spec. -- Eitan Adler
Re: [whatwg] input type=location proposals
1. Maps are heavy to get, this means UA should heavily cache and/or it should own whole maps data (huge!) 2. If 1) didn't exist because UA can, for instance, get maps data in a blink of an eye: whose data are we gonna use? 3. Maps data are often non-free and non-open, reliable maps data are always non-free and non-open. For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. -- Eitan Adler
Re: [whatwg] select element should have a required attribute
On Fri, Jun 18, 2010 at 12:58 PM, Gordon P. Hemsley gphems...@gmail.comwrote: I'm not sure how you interpreted, but I wanted to clarify, in case it wasn't clear. I'm pretty sure this person is asking why @required isn't allowed on select elements. As in: http://dev.w3.org/html5/markup/forms-attributes.html#shared-form.attrs.required I don't know what the exact reasoning is for it not being on there, nor do I know exactly how @required is supposed to be enforced, but I do think that the method suggested in the bug is a bad one. Sometimes, authors will include an empty option on purpose in order to allow for an empty option to be selected. Perhaps the @requires attribute could be handled somewhat differently. If present the default value becomes the not allowed value and the browser would require you to change the value before submitting the form. -- Eitan Adler
[whatwg] input type=location proposals
Two separate use cases 1) For entry of locations into something like Google Maps or MapQuest. In this case the form should look as it does now (a text box) but browsers would be able to assist you in entering locations like it can for for emails. 2) For entry of Lat/Long coordinates which can be entered either manually or with some kind of map like interface. These are two separate proposals and I both could co-exist one as type=location and the other as type=gps -- Eitan Adler
[whatwg] input type=upload (not just files) proposal
A lot of websites let you upload either from a file on your hard drive or from a link on the web. Most of the time this is done by having two different inputs: One for a file and the other for a URL. If there were some type of input like upload' which will allow for any complete input. Something like file:///home/eitan/file_to_upload.pdf or http://example.com/file.pdf or ftp://user:passw...@example.com/file.pdf It would then be the server's job to fetch the file unless the user passed it a file:// scheme it which case the file would be provided by the UI. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton glsim...@indiana.edu wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: It would then be the server's job to fetch the file unless the user passed it a file:// scheme it which case the file would be provided by the UI. I imagine this would be a UI decision - not one made by the spec. However I, with very limited experience in UI creation, am envisioning a dialog box as you mention. Another option would be to have buttons to the side of the textbox one that has a web icon and another that has a folder icon. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? Yes - exactly. -- Eitan Adler
Re: [whatwg] Need document.available_fonts() call
Please note there's a rather strong privacy issue here. I don't want a web page to be able - without my prior consent - to query the list of fonts available in my system. You already have this problem if a website were to create a list of elements with a list of different fonts and use Javascript to determine which font is being displayed. [1] I'm not advocating opening another hole just because one already exists - I'm just pointing this out. [1] http://www.lalit.org/lab/javascript-css-font-detect
Re: [whatwg] RFC: input type=username
The way I see it is that instead of browsers traversing the DOM looking for an input field of either id=username or name=username or even class=username, they now only have to look for an input of type username. Makes it a lot easier for both developers and browser vendors as they now only have to look for an input of type username and gives developers the freedom to use any name, id or class. But in many cases the username is an e-mail address, then you get a conflict with type=email. type=email is expected to (depending on the browser) allow you to search into/autocomplete from your address book. I really don't see a conflict here, it's not about syntax, it's about semantics (otherwise, just use a pattern= constraint). The input type='email' isn't only about semantic. The browser has to check if the email is valid according to HTML5 specifications. Please, have a look at: http://dev.w3.org/html5/spec/forms.html#valid-e-mail-address If the entered email address is invalid, the element will suffer from a type mismatch. Here are some possible solutions to allow the use of something like input type=login/username along with an email 1) change type=login to role=login (and thus allow a text/selec/email/whatever). Based on the feedback so far this is now my preferred solution. 2) add a role to form element and have the browsers continue to rely on id/name/class
Re: [whatwg] Keywords for the pattern attribute [was: RFC: input type=username]
input type=text pattern=email input type=username pattern=email What if for some strange reason I wanted to only allow the text e-m-a-i-l ? There would have to be some way to differentiate between a keyword and a normal pattern.
[whatwg] RFC: input type=username
Use cases: 1) A screen reader that sees a form with a type=username and a password field. The screen reader could just ask Log in to this site? [y/n]?. No further context would be needed. 2) UAs can more easily discover login forms and offer things such as Firefox's Account Manager [1] or a remember me feature 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Furthermore some websites offer a find other members feature where you could type in a username. I've often seen these fields filled in automatically with my name. 4) I'm sure there are others The proposal: A type=username is added to the input element. type=username would MUST only be used for the name that is used to log in to the site. It MUST NOT be used for registration forms or anything else that requires a username. A form MAY have up to one (but not more) type=username input field. [1] http://www.mozilla.com/en-US/firefox/accountmanager/
Re: [whatwg] RFC: input type=username
I don't think type=username is good solution, but I agree that autofill needs help. Sites often use e-mail address as login. There would be conflict between type=email and type=username. I could imagine one two solutions here. 1) Change type=username to role=username which makes more sense anyway (a username field is actually a text field) 2) Allow multiple types per input field. This IMHO is a bad idea. Another problem is the same login form appearing in multiple places on the site (usually slighly different form is part of site's layout, and different one is presented when user is forced to log in). Sometimes autofill sees such forms as same, and sometimes it doesn't. Auto-fill information is often lost when sites are redesigned. The goal of type=username is to indicate to the UA which form is the login form. This would allow features such as remember me and autofill to be done in the UA instead of in the browser. It would be nice if autofill could remember values from registration form and automatically use them for logging in. Users usually aren't asked to log in after registering, so there's no opportunity for the browser to save login details immediately. Firefox is fairly good about this - asking me to remember passwords from registrations forms. The goal of my type=username proposal was to provide some indication to the UA that a particular form is a login form. Another idea is to allow forms to have roles. form ... role=[register|login|search] would be a decent alternative to input type=username There are two major places I could see this improving things. One was already mentioned: autofill. The second is screen readers. Instead of having to read out the entire form the UA could just ask Register for this site? or Log in now?. -- Eitan Adler
[whatwg] link by name instead of url
This is an idea I've had in my head for a while and I think it might make an useful addition to HTML5 standard. As this is just an idea I didn't work out all the details. I'm just looking to see if this is something that might be accepted. Use case 1: A document author wants to provide a link to some site. This site has multiple versions of the page depending on where you live (think google.co.uk, google.co.hk, google.com etc) Use case 2: A document author wants to ask users to share his page via the users preferred social network. Something like Please a href=http://facebook.com;tell your friends/a about this site! Use case 3: A document author wants to provide a link to search for more information on a preferred search engine. I'd like to leverage the user's bookmarks in these cases by allowing authors to specify markup like case 1: a goto=googlegoogle/a case 2: a goto=social-networktell your friends/a case 3: a goto=searchsearch!a The UA would be responsible for determining which site to link to. A href could be provided as a fallback for old browsers or for sites where the user did not yet make a choice.
Re: [whatwg] Two propositions for the autofocus attribute
- multiple autofocused elements per page are valid, but only one per form Is it possible to focus on multiple elements at the same time even in different forms? If they are both text boxes and a user types which element gets the keyboard input? Autofocus only really makes at load time - for any other dynamic focus I think .focus() should be used.
