[whatwg] register*Handler and Web Intents
mounir at lamouri.fr
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.
<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!
>> 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.
More information about the whatwg