W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [webcomponents]: Building HTML elements with custom elements

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 20 Feb 2013 07:49:40 -0500
Message-ID: <5124C664.9060507@mit.edu>
To: Anne van Kesteren <annevk@annevk.nl>
CC: Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Erik Arvidsson <arv@chromium.org>, Alex Russell <slightlyoff@chromium.org>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>
On 2/20/13 7:26 AM, Anne van Kesteren wrote:
> These already cannot be just localName checks

They often are in practice for extensions and web script.

For browser code or better-written extensions and web script they're 
typically localName + namespaceURI checks.

> I also fail to see exactly what the problem is here, an
> example would help.

Here's a simple example.

Say you have a browser extension that hooks into the context menu code 
and adds items to context menus for images that do something the user 
wants.  How does it detect images?  Given that instanceof tends to be a 
broken puppy when multiple globals are involved (though we're working on 
finally getting that fixed), it would typically do things like (for a 
well-written extension):

  if ((isHTML(element) &&
       (element.localName == "img" ||
        (element.localName == "input" &&
         element.type == "image"))) ||
      (isSVG(element) && element.localName == "img")) {
    // Add my context menu items

(maybe with some extra complexity for <object>).

Now if you create a custom element inheriting from HTMLImageElement but 
not using "img" as the localName suddenly the extension won't show its 
context menu items on that image and the user will be unhappy because 
they can't do things with that image that they can do with all other images.

Received on Wednesday, 20 February 2013 12:50:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC