[whatwg] <banner> as a dedicated tag
Tab Atkins Jr.
jackalmage at gmail.com
Wed Feb 23 11:12:47 PST 2011
On Wed, Feb 23, 2011 at 8:03 AM, Martin Stender <martin at stender.com> wrote:
> Hello list
> I've been searching the archives for some discussions about the need for a dedicated banner-tag, but found only some WAI-related discussions about using the 'role'-attribute for this.
> But semantics and/or accessibility is not my primary reason for raising this issue.
> I work as a frontend-developer at a leading Danish media-company, and we are - as many others - mainly funded by our ad-sales.
> As I'm sure many of you are aware (and probably challenged by every now and then), banner-ads come in all thinkable variations: simple text links, simple images/animated gifs, elaborate Flash-creations and so on.
> Now, the way you chose to actually insert these into your page, can vary a great deal, but if you are a large site where your advertisers continuously change, you have some sort of ad-management system and a team of people dedicated to performing the job of taking in campaigns, uploading them to the system and taking them live.
> Dom-injection is the most common way of doing this, so in our case, here is what happens:
> Several places on our site, we have markup like this:
> <div class="banner_300">
> So the ad-managing system injects whatever is supposed to sit inside that div-tag, into our dom.
> I believe that is the way most commercial sites handles this task.
> While we trust both our ad-team, our ad-management system, our customers and their ad-agencies - *nothing* really prevents either a human error or some 'evil-doers' (tm) from taking over the entire page this way. In reality, of course, human error would be the case in almost all cases of mishap, but everything is possible.
> So it would be great to have the ability to just insert a <banner>-tag, knowing that whatever goes on in side that tag, cannot alter the page itself.
> You should be able to grant the tag access to read various values of the surrounding page, though.
> Also, the possibility to postpone execution of the banner-tags content including scripts (until everything else has loaded) would also be highly useful, as we sometimes experience high load times due to banners.
> The ever-present issue of accessibility / semantics would also gain from this, as robots and screen-readers should/could just skip the tag altogether.
> So something like this:
> <banner deferred="deferred" pageaccess="read | write | both | none"> [here goes whatever your ad-manager system needs] </banner>
Let me attempt to summarize your use-case:
I have untrusted markup from a third party which I would like to
safely insert into my page, knowing that the rest of my page is safe
from whatever the untrusted markup is doing. Also, the untrusted
markup may be doing expensive things, particularly on load, so I'd
like to wait until after the rest of the page is loaded before loading
Is this accurate? Correct me if not, but I'll assume it is for now.
This is precisely what <iframe sandbox> is designed for. You can use
a sandboxed iframe to isolate things from the rest of your page while
still allowing them to run script and generally do arbitrary unknown
If the network request that <iframe>s normally kick off is
undesirable, you can use the @srcdoc attribute to get around this.
Using @srcdoc, you can either safely embed the untrusted markup
directly in your page (it'll still only run in the sandbox), or easily
set it from script. ( var bannermarkup = "<p>some markup here</p>";
banneriframe.srcdoc = bannermarkup; )
I know that iframes don't stop the rest of the page from rendering
while they load. I can't recall off the top of my head whether they
delay the load event or not. If they do, and this is a problem, you
can easily just set up a script which listens for the load event and
then sets the @src or @srcdoc of the iframe.
More information about the whatwg