- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Tue, 17 Apr 2012 18:11:52 +0200
On 04/03/2012 01:23 AM, Ian Hickson wrote: > On Tue, 6 Dec 2011, Anne van Kesteren wrote: >> >> You could also have >> >> <meta name="intent" content="http://webintents.org/share image/*"> >> >> or some such. Splitting a string on spaces and using the result is not >> that hard and a common pattern. And seems like a much better alternative >> than changing the HTML parser. > > Trying to fit the registration components listed above into <meta> really > doesn't work all that well, IMHO. <meta name="viewport"> does that and is widely used AFAICT. > On Tue, 6 Dec 2011, James Graham wrote: >> On Tue, 6 Dec 2011, Anne van Kesteren wrote: >>> >>> Especially changing the way <head> is parsed is hairy. Every new >>> element we introduce there will cause a <body> to be implied before it >>> in down-level clients. That's very problematic. >> >> Yes, I consider adding new elements to <head> to be very very bad for >> this reason. Breaking DOM consistency between supporting and >> non-supporting browsers can cause adding an intent to cause unrelated >> breakage (e.g. by changing document.body.firstChild). > > That is true, but adding this to the body seems weird too. How bad would that be? Do we expect a lot of breakage? Can't we simply assume websites would use the programmatic registration if the declarative one doesn't work/break some old browsers? > On Tue, 6 Dec 2011, James Hawkins wrote: >> >> Originally we envisioned using a self-closing tag placed in head for the >> intent tag; however, we're now leaning towards not using self-closing >> and having the tag be placed in the body with fallback content, e.g., to >> install an extension to provide similar functionality. >> >> <intent action="webintents.org/share"> >> Click here to install our extension that implements sharing! >> </intent> >> >> What are your thoughts on this route? > > How common will fallback be on the short term and on the long term? I think the fallback is quite useless here. > I don't think wildcard matching really makes sense. In particular, I'm not > aware of any service that can honestly say it supports image/*, or indeed > any other topleveltype/*. Doesn't @accept on <input> allows "image/*", "video/*", "audio/*"? We should at least accept those values. But maybe it would be safe to allow foo/* if a service and client would be connected only if they both marked they "foo/*" as a type? > On Fri, 16 Dec 2011, Paul Kinlan wrote: >> >> We didn't want to add additional attributes to the meta tag or link tag >> just for intents, this seems to open up the flood gates for future >> platform features to also extend the meta syntax, the meta element then >> just becomes a dumping ground. > > That's not a big concern, so long as the semantics make sense. > > With intent registration, I'm not sure they do. > > e.g. with <link href=""> you'd want to be able to register a URL with a %s > segment for content/protocol handlers, but that's no longer a valid URL, > so it's weird to use href="" which currently requires a valid URL. > > Similarly, using type="" to mean the filter rather than the type of the > content at the href="" URL would mean the type="" attribute has a > different meaning based on context. > > Similarly, we have an action="" attribute on <link> that defines the > disposition, but it has different values than what we're talking about > here, so it would be weird to reuse it, and would be weird not to. > > <meta> is also a weird case because we'd basically be reusing the element > but none of the attributes, and it already has three different roles. AFAIUI, <link> is far from ideal for what we want. IMO, <meta> would match quite well our needs. We could put all the information in @content like <meta name='viewport'> is doing. However, IIUIC, we can have only one <meta> with a given @name which means a page will not be able to register declaratively more than one intent. Otherwise, we could come with a very complex syntax to allow more than one declaration in @content. > On Wed, 15 Feb 2012, James Hawkins wrote: >> >> We, the designers of the Web Intents draft API, have always seen Web >> Intents as a superset of the functionality provided by >> registerProtocolHandler (RPH) and registerContentHandler (RCH). To >> follow this to the logical conclusion, we should be able to provide >> functionally equivalent counterparts to RPH/RCH in Web Intents. This >> proposal provides a means of deprecating RPH/RCH, replacing this >> functionality with equivalent functionality from Web Intents. > > I don't think it makes sense to deprecate them. We should design intents > to incorporate them, not deprecate them. Given that Web Intents would deprecate/supersede RPH and RCH, I wonder why we should bother incorporating them. > - Using URLs as intents, especially for the default intents, is overly > verbose. I highly recommend just having a wiki page be a registry of > widely used intents, and saying that if people want specialised ones for > their own communities, they can then use URLs, but otherwise it's fine to > just use simple identifiers like "edit" or "share", so long as they are > registered in the wiki. This is what we're doing with rel="" and it seems > to work fine. I fully agree: URLs for common/default intents is a wrong idea. -- Mounir
Received on Tuesday, 17 April 2012 09:11:52 UTC