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

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

From: Blake Kaplan <mrbkap@gmail.com>
Date: Wed, 6 Mar 2013 14:28:48 -0800
Message-ID: <CANTSQ3GHbdiMJKHRrXrYBF672shJqiECokKs47GFF39bm6_6RA@mail.gmail.com>
To: Rafael Weinstein <rafaelw@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Dominic Cooney <dominicc@chromium.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Dimitri Glazkov <dglazkov@chromium.org>, public-webapps <public-webapps@w3.org>, Elliott Sprehn <esprehn@gmail.com>, Yehuda Katz <wycats@gmail.com>
On Wed, Mar 6, 2013 at 10:12 AM, Rafael Weinstein <rafaelw@google.com> wrote:
> It seems to me like if public-by-default was a design mistake on the
> web, it'd be pretty clearly in evidence already. Is it?

This might depend who you ask. I know from experience that
public-by-default has bitten XBL1-implemented HTML elements really
badly (leading to tons of security bugs until we (Mozilla) figured out
how to lock them down). We've invested many hours of time avoiding a
different problem with our audio and video controls (also implemented
in XBL1) where we explicitly had to avoid exposing the guts of the
implementation of the control to prevent page authors from using the
non-standard internal API instead of the public one.

Outside of those cases, I've personally been bitten in other languages
and contexts where private state was exposed publicly on an API which
made what should have been a simple bug fix take days or weeks to
track down all of the (ab)users of the "easier" API. This is a classic
problem in computer science and there's a reason that it's taught in
many CS 101 courses. I don't have any specific anecdotes on the web,
but they simply must exist.
-- 
Blake Kaplan
Received on Wednesday, 6 March 2013 22:29:19 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT