- From: Paul Kinlan <paulkinlan@google.com>
- Date: Wed, 25 Jan 2012 18:11:00 -0800
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). P 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 [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? > > > Yes, that's completely abhorrent. > > Remember, <video> uses new tags, like <source>, so it can get away with such > trickery. > <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. > > > -Charles > -- 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 18:11:00 UTC