[whatwg] Stay in touch with me through LinkedIn
LinkedIn I'd like to include you in my network to share updates and stay in touch. - Davis Davis Peixoto Developer at LojasKD Móveis Curitiba Area, Brazil Confirm that you know Davis Peixoto: https://www.linkedin.com/e/-oqt7pm-hf5e02s2-5f/isd/12219062950/ZT9k3h_q/?hs=false&tok=0GqqTZV4sCbBI1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-oqt7pm-hf5e02s2-5f/xLoZhT8gr-Lt5HZcgLGH2Yrv2PTH/goo/whatwg%40whatwg%2Eorg/20061/I4049169318_1/?hs=false&tok=1ZqkVTWQ4CbBI1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.
Re: [whatwg] onLoad event
Interesting question indeed On Wed, Oct 27, 2010 at 11:15 AM, Diogo Resende wrote: > Hi, > > Is there a way to know that a has been loaded (and processed)? > I'm more interested in CSS links than others but the process should be > the same. In my opinion it's a better way of loading stylesheets than > downloading using XmlHttpRequest and then creating the
Re: [whatwg] Changing punctuation value of input element in telephone state
> > > The goal of fool-proofing phone fields is a quite noble one but, let's > be honest: it's quite near to an utopia. Any "solution" that may cause > valid inputs to break is definitely bad. If fixing wrong inputs risks > valid ones to break, we are not only not solving the problem, but we > are moving it somewhere it doesn't make sense: if you had to choose > between wrong inputs breaking or good inputs breaking, is there any > sane reason to chose the later? > This is what I was saying. It is noble, but utopic (Yeah, you put it better in words). But now I realized: UA handling of type=tel is just a possibility, not a mandatory feature. Thus, I think even it is documented in somewhere in HTML 5 spec, it won't be used/implemented at all due to all the drawbacks we were discussing about in this thread. -- Hugs, Davis
Re: [whatwg] Changing punctuation value of input element in telephone state
> > > Other than that, the only safe alternative would be to leave the > values untouched, so the page can say what it wants, the user honor > it, and the server get it as expected; or gracefully degrade to an > error message that actually points to the user error (rather than an > error introduced by an UA trying to be out-smart the user). > This goes in the opposite direction from the initial idea of creating a interface that intend to avoid type mismatches, unfortunately. > > For sites that are ready to sanitize values from a specific locale; > but which are accessed through an UA with different settings (ie: on a > public place while abroad), the UA adding locale-specific stuff to a > phone value is very likely to render whole forms unusables. > I just mentioned another drawback. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
> > When I was using MacOS X, I hated how the contact application was > restyling my phone numbers. > By the way, it lets me think about something: the telephone state can > still be used for autocomplete with phones from contacts. > > -- > Mounir > Good one, Mounir. Tab, this does not means only formatting, but the input length will differ too much. Uruguay for example, has only 6 digits number, 8 with international leading code. Brazil has 9 or 10, depending on the region, plus 2 with international leading code. That's the point. But as I said, when we have some standard for it (I doubt of this, but let's suppose it), we can put this inside locales configuration. This is a nice idea. Anyway, backend programmer will still need to sanitize this input somehow. Yeah, I do not see much light for this matter. -- Hugs, Davis.
Re: [whatwg] Changing punctuation value of input element in telephone state
Hello fellas, I agree with Mounir. Thing is UA is allowed to do that, but without clear rules, this can be a mess. If for date and time, where we have a lot of formats and standards for internationalization, how can UA specify and be no type mismatch, if we do not have any standard about phone numbers? I mean, american format differs a lot from brazilian, which differs a lot from indian, which differs from... you got it. But it would be great if this kind of data becomes part of i18n packages, meaning that any user, with a UA tunned to its native language can input that, and let it do the job, like for date and time. However, not like date, which is a fixed number, phones can vary a lot from one region to region in length, and prefixes. I think this is open to UA devs and RFC writers to take care, but I am not sure if these statements will be useful someday at all due this lack of pattern among regions. -- Hugs, Davis.
