[whatwg] Proposal: <intent> tag for Web Intents API

[Merging the digest reply from Charles]

I would prefer to treat it like a embedded content element [1] and
have the intent spec define how fallback content should be presented
and parsed - so we would define that <script> is ignored in a
conforming UA. ?In our case we would want to work like the video
element [2] with the added script restriction.

Is this a completely abhorent solution?

If it is the solution in our case still works (although has a network
request) because the shim defers to Web Intents if detected -
otherwise we could still use the solution you presented and have it
inline in the intent (or somewhere else), no conforming UA's can then
be styled to make the other content visible.

[1] http://dev.w3.org/html5/spec/content-models.html#embedded-content
[2] http://dev.w3.org/html5/spec/video.html#video




On Wed, Jan 25, 2012 at 12:36 PM, Charles Pritchard <chuck at jumis.com> wrote:
> On 1/25/12 12:08 PM, whatwg-request at lists.whatwg.org wrote:
>>
>> 2. We can add the script polyfil in seamlessly - conforming UA's will
>> ignore internal content, non-conforming UA's will treat it as an
>> element they should descend into and thus load the required script.
>> <intent ...>
>> ? <!-- Load the polyfill shim -->
>> ? <script src="http://webintents.org/webintents.min.js"></script>
>> </intent>
>
>
> I don't think you can use the fallback content as a method of optionally
> loading the script tag.
>
> The resource is loaded as part of the DOM, the only way to get around that
> is with <noscript>, which would get awkward.
>
> I learned this while exploring <img> content in fallback tags:
> <canvas><img src="loaded.png" title="this image tag will always be loaded"
> /></canvas>.
>
> This is more typical:
> if(!self.Intent)
> document.head.appendChild(document.createElement('script')).src='shimaddress.js';
>
>
> -Charles
>

On Wed, Jan 25, 2012 at 12:04 PM, Paul Kinlan <paulkinlan at google.com> wrote:
> Sorry for the delay in replying.
>
> Yes we are ok with it being in the body. ?Having the intent tag in the
> body allows us to have a strong graceful degradation story for Web
> Developers and Publishers. ?The <intent> tag in the body allows us to
> do several nice things such as:
>
> 1. ?Giving the user another way to handle the action and allowing for
> custom styling of the element:
> <intent action="http://webintents.org/share" ... style="background-color:red;">
> ?<p>Add our bookmarklet <a href="javascript:.......">Drag to bookmark
> bar</a></p>
> </intent>
>
> 2. We can add the script polyfil in seamlessly - conforming UA's will
> ignore internal content, non-conforming UA's will treat it as an
> element they should descend into and thus load the required script.
> <intent ...>
> ?<!-- Load the polyfill shim -->
> ?<script src="http://webintents.org/webintents.min.js"></script>
> </intent>
>
> 3. It opens up the possibility for intent specific sub-tags - much
> like <source> in <video> that we might need in the future.
>
> P
>
> On Fri, Dec 16, 2011 at 2:18 PM, Adam Barth <w3c at adambarth.com> wrote:
>>
>> To be clear, you're ok with not being able to include the <intent>
>> element in the <head>.
>>
>> Adam
>>
>>
>> On Fri, Dec 16, 2011 at 2:13 PM, Paul Kinlan <paulkinlan at google.com> wrote:
>> > I know James mentioned [1] that we are leaning towards having the tag
>> > in the body which opens up the possibility of unsuported browsers
>> > showing the content of the element. ?This had some general consensus
>> > [2]
>> >
>> > [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034084.html
>> > [2] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-December/034087.html
>> >
>> > On Fri, Dec 16, 2011 at 9:44 PM, Adam Barth <w3c at adambarth.com> wrote:
>> >> On Fri, Dec 16, 2011 at 11:35 AM, Paul Kinlan <paulkinlan at google.com> wrote:
>> >>> There isn't always a href, if left out the value action should be
>> >>> launched on the current page.
>> >>>
>> >>> 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. ?If the answer when defining a new
>> >>> declarative standardized platform feature is to just arbitrarily add
>> >>> new attributes to the meta data element we will get to a point where
>> >>> either ?we have attributes that are used in multiple contexts or use
>> >>> of basic attribute name spacing such as "intent-".
>> >>>
>> >>> Looking at the spec[1] it appears there would still be a relatively
>> >>> large change to the html5 spec to accomodate these new attributes and
>> >>> conditional parsing guidelines.
>> >>>
>> >>> A new tag is simple, concise and encapsulates the features and
>> >>> requirements of the new platform feature and gives us scope to iterate
>> >>> for future versions without stepping on the toes of the other features
>> >>> that might use the meta tag.
>> >>
>> >> Does that mean you're not interested in declaring this information in
>> >> the <head> ?
>> >>
>> >> Adam
>> >>
>> >>
>> >>> [1] http://dev.w3.org/html5/spec/Overview.html#the-meta-elemen
>> >>>
>> >>> P
>> >>>
>> >>> On Fri, Dec 16, 2011 at 9:54 AM, Anne van Kesteren <annevk at opera.com> wrote:
>> >>>>
>> >>>> On Wed, 14 Dec 2011 23:05:37 +0100, Greg Billock <gbillock at google.com> wrote:
>> >>>>>
>> >>>>> The big ergonomic sticking point there is probably the |href|
>> >>>>> attribute, which we envision
>> >>>>> being able to do same-origin registration. Perhaps a similar <link
>> >>>>> rel="intent"> tag
>> >>>>> modification would be able to do that, though. Is that what you'd
>> >>>>> suggest? Do you think
>> >>>>> having two tags involved would be confusing?
>> >>>>
>> >>>>
>> >>>> If there's always an href attribute you could just go for <link> instead. I think you should go for one element and just add attributes as required. And if we want to put inside <head> that would be either <meta> or <link>.
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Anne van Kesteren
>> >>>> http://annevankesteren.nl/
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Paul Kinlan
>> >>> Developer Advocate @ Google for Chrome and HTML5
>> >>> G+: http://plus.ly/paul.kinlan
>> >>> t: +447730517944
>> >>> tw: @Paul_Kinlan
>> >>> LinkedIn: http://uk.linkedin.com/in/paulkinlan
>> >>> Blog: http://paul.kinlan.me
>> >>> Skype: paul.kinlan
>> >
>> >
>> >
>> > --
>> > Paul Kinlan
>> > Developer Advocate @ Google for Chrome and HTML5
>> > G+: http://plus.ly/paul.kinlan
>> > t: +447730517944
>> > tw: @Paul_Kinlan
>> > LinkedIn: http://uk.linkedin.com/in/paulkinlan
>> > Blog: http://paul.kinlan.me
>> > Skype: paul.kinlan
>
>
>
>
> --
> Paul Kinlan
> Developer Advocate @ Google for Chrome and HTML5
> G+: http://plus.ly/paul.kinlan
> t: +447730517944
> tw: @Paul_Kinlan
> LinkedIn: http://uk.linkedin.com/in/paulkinlan
> Blog: http://paul.kinlan.me
> Skype: paul.kinlan



-- 
Paul Kinlan
Developer Advocate @ Google for Chrome and HTML5
G+: http://plus.ly/paul.kinlan
t: +447730517944
tw: @Paul_Kinlan
LinkedIn: http://uk.linkedin.com/in/paulkinlan
Blog: http://paul.kinlan.me
Skype: paul.kinlan

Received on Wednesday, 25 January 2012 17:06:41 UTC