- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 25 Sep 2013 08:23:32 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Simon Pieters <simonp@opera.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Sep 25, 2013 at 8:17 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Sep 25, 2013 at 10:58 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> They needed *some* common prefix to avoid clashing with userland code, >> and DOM seemed to be a decent one that covered roughly what all they'd >> be used for. > > They do? We've been trying to stay clear of using DOM for anything new > and on top of that we haven't used prefixes new things generally, such > as Path or ImageData. Note that Path is garnering compat issues *immediately* upon being introduced in betas. It's just too simple of a name, and too likely to be squatted by user code or libraries. The same is almost certainly going to be true of Point, Rect, Quad, and Matrix. ImageData doesn't have quite that issue. > The new JavaScript global-exposed objects > System, Symbol, etc. also will be introduced as such. If they *can* do so. Those names are also simple enough that they risk compat issues. > If they are more general than viewport rectangles (which suggests > ClientRect) and you cannot use Rect, RenderRect or LayoutRect or > whatever subsystem is responsible for them seems more suitable. "DOM" > is largely legacy and a hack. "Client" is an opaque word that doesn't mean anything to normal people (I don't know what it actually refers to, for example). We discussed Layout or Render, but decided against it, as these classes are usable for more than that. There's no single subsystem that's going to use these. "DOM" was short, easy to type, familiar, and also nobody cares. ^_^ ~TJ
Received on Wednesday, 25 September 2013 15:24:19 UTC