- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Mon, 06 Jun 2011 09:46:04 +0200
- To: Robin Berjon <robin@berjon.com>
- Cc: Device APIs and Policy Working Group WG <public-device-apis@w3.org>
Le mercredi 01 juin 2011 à 23:27 +0200, Robin Berjon a écrit : > I know that adding a |uri| attribute that is only present when the URI > could be correctly inferred addresses that part. But it's still a > problem. It means that we need to specify the heuristics — for they > will be heuristics in some cases — that map from possibly arbitrary > values to URIs. I guess you're right we would have to define those; I think the work is minimalistic for photos and urls, and probably for emails. The algorithm would be: * parse the URL as defined in HTML5 http://dev.w3.org/html5/spec/urls.html#parsing-urls * if the parsing fails, abort * otherwise, stick the value in the uri attribute (emails would have to be appended with a mailto: scheme prior to that treatment) > I'm not saying it's necessarily huge work, but it's extra stuff. And > we also need to require that implementations validate those URIs. In > some cases, that's more of a burden than meets the eye. Do you have anything specific in mind? > > That's probably true for ims and phone numbers: > > * ims, because the type of instant messaging is not always recorded with > > the data, and when it is, it's not necessarily in a way that can lend to > > be turned into a URI scheme (when one exists) > > I think that handling IMs is very likely impossible in the general > case. I'd really rather we didn't try for these. Yeah, I agree it's probably too hard for too little benefit. > > * phone numbers, because they need to be complete enough to be turned > > into URIs (e.g. they need the international calling code?), and they may > > also contain non phone number information (e.g. manually indicated > > extension number) > > Actually, they don't. The tel: scheme allows for an awful lot of > variations, and my understanding is that that includes partial > numbers. That being said, it is a complicated scheme that would have > to take care of things like extensions, and a bunch of other aspects > that I believe are more complex than I feel comfortable with. I could live with leaving that one alone for now as well. > > It seems to me that these concerns don't apply to emails, photos, and > > urls (!). > > For photos I think it's an easy win. The current draft has Base64 or > URI. We could just have URI, indicating that if it's Base64 it can be > a data: URI (and it could also be a blob: URI). Photos are clearly my #1 request; having a field that can have both URLs and binary-encoded-data-but-not-a-data-URL seems like non-sense. > For the others, I'm still not convinced :) > > With email, what's the value of getting mailto:foo@bar.com over > foo@bar.com? The extra processing required to ensure that the former > is valid in the face of user error seems a high price to pay to me. Well, it seems to me that this price has to be paid sooner or later if these fields are going to be used; the number of usage of email addresses that doesn't include linking (or sending a message via our beautiful Messaging API) seems limited. > We'd also have to handle issues such as what to do if the user enters > foo@bar.com?subject=blah into their address book. I'm not at all > saying that's impossible, but it's a number of extra conformance > requirements, more testing, etc. It does raise the bar for > implementation more than it seems to be worth. I appreciate that it raises the bar for implementation; I'm not entirely convinced that it is more than it is worth. > As for URLs, I don't see that it's a given. We have to think about > round-tripping even if we don't support it directly (yet). I don't think we need to think about it if we keep dual value/url properties. > There are two options to convert user-entered URLs into proper URLs > when they aren't (users often drop the "http://"): modify the value > directly, or keep the value as is and add a corrected uri field. Again > the issues with testing, heuristics, etc. crop up. But we also have to > think about updates. What if I put two completely different values in > there? How does it get serialised? I don't understand what you mean here. > All in all, given that it can be handled in script with minimal > trouble, I think that we should change photos and keep the rest as is. I can live with that solution as long as photos is fixed. I guess we could always add the URL processing to a later version if needed; I'm hoping we're not under-delivering, though. Dom
Received on Monday, 6 June 2011 07:46:21 UTC