W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2012

Re: [whatwg] [canvas] Path object

From: Glenn Maynard <glenn@zewt.org>
Date: Tue, 2 Oct 2012 20:01:38 -0500
Message-ID: <CABirCh9BJdj-O_WX325O17LZNm3ZQ-aQ6jFoxap14h_TSHRAUw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Elliott Sprehn <esprehn@gmail.com>
> On Tue, Oct 2, 2012 at 4:58 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
> > What of the fact that this breaks existing pages with <input
> > id="Path"> that access it as just Path? Historically this has been a
> > non-starter for new APIs.

Surely it's not a non-starter in general, or else no new APIs could ever be
added to the platform--at worst it just means picking a less generic name.
I assume that's not strictly needed; "URL" must be a more common ID than
"Path".  ("Path" makes me think of URL paths, though.  Something like
"DrawPath" would be a little clearer.)

FWIW, and I'm guessing this isn't news:

<!doctype html>
<div id=URL></div>

logs the <div> in WebKit (Chrome 21), and the original window.URL in
Firefox.  This probably means adding a new API named "Path" would break
pages in Firefox, but not in WebKit.  WebKit's behavior seems much safer
for web compat, but more annoying for people who behave themselves and
don't use window.id lookups.  (It would be nice if you could just say
"window.disableIdLookups()" once to opt out of this mess...)

On Tue, Oct 2, 2012 at 7:16 PM, Charles Pritchard <chuck@jumis.com> wrote:

> I think moz already made the move to require document.getElementById for
> these cases.

It looks like they did in FF13 (in standards mode, not quirks mode), but no
longer in FF15.  I'm surprised this was even considered, never mind
deployed--it must break tons of pages.

Glenn Maynard
Received on Wednesday, 3 October 2012 01:02:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:46 UTC