[whatwg] Proposal: <intent> tag for Web Intents API
paulkinlan at google.com
Wed Jan 25 18:11:00 PST 2012
Understood. The case still stands that we can use the <intent> tag in
the body, have script fallback if the publisher decides to add the
shim by way of adding the dom Element or just always including the
proxy code - or just have a nice piece of text/dom for some other
fallback mechanism of completing the action (such as a link to a
scriptlet). We don't get this ability with the other methods
discussed (<meta> - <link>).
Note: I added a script element inside a video element and a supporting
browser still executed the code. It is a shame because I think it is
a nice solution (in theory).
On Wed, Jan 25, 2012 at 5:14 PM, Charles Pritchard <chuck at jumis.com> wrote:
> On 1/25/2012 5:06 PM, Paul Kinlan wrote:
>> [Merging the digest reply from Charles]
> Thanks, sorry about breaking the subject line.
> For others: this mini thread is in relation to <intent><script
> src=""></script></intent> behavior.
>> I would prefer to treat it like a embedded content element  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  with the added script restriction.
>> Is this a completely abhorent solution?
> Yes, that's completely abhorrent.
> Remember, <video> uses new tags, like <source>, so it can get away with such
> <script>, like the <img> tag, is old magic. We would have to change the HTML
> parser or otherwise alter DOM semantics to make it work.
> Image content and script content in the dom, with a src attribute, will be
> loaded regardless of tags, with the exception of noscript.
> <video><img src="content.jpg" /></video> -- that'll still load the image,
> though it won't display it.
Developer Advocate @ Google for Chrome and HTML5
More information about the whatwg