[whatwg] register*Handler and Web Intents

Tue Apr 17 09:11:52 PDT 2012

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.

> 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