- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 10 Sep 2012 21:12:09 -0700
- To: Glenn Adams <glenn@skynav.com>
- Cc: John Daggett <jdaggett@mozilla.com>, www-style list <www-style@w3.org>
On Mon, Sep 10, 2012 at 8:47 PM, Glenn Adams <glenn@skynav.com> wrote: > What you appear to find obvious, I find irrational. Your suggestion has the > following negatives: > > * increases cognitive load on author, since there are two ways of accessing > similar/identical information Huh? There's not two ways. There's only one - through the event. Whether they hang off the event or "event.fontface.style" has no effect on "cognitive load". Unless you're trying to say that authors will somehow be confused by the fact that you can access font information both in an event *and* off of the CSSOM object. I'm not going to take this possibility seriously. > * increases effort on UA implementors, both in coding and testing > * increases UA code footprint unnecessarily These are insignificant, and author needs trump UA needs in the prioritizing of constituencies. (Strong problems for the UA can trump minor problems for the author, but if they're roughly equal, authors win.) They're wrong, anyway - since the current spec requires the UA to create a readonly copy of the CSSFontFaceRule, something which doesn't currently exist, there will be at least as much coding and testing necessary, particularly to ensure that cross-domain information doesn't leak accidentally. For example, one of the reasons we restrict cross-domain stylesheets is to prevent access to comments, which can be exposed by cssText, so we'd have to make sure to sanitize cssText properly. > * increases likelihood of one of the two ways of accessing this information to > become out of sync over time, leading to subtle differences in author's > usage, increasing overall complexity, increasing likelihood of author errors > * increases effort for spec authors, maintainers, spec test writers > * creates unnecessary possibility of fork in definition of functionality All of these are "make the spec writer's life slightly easier". Again, the ordering of constituents is user > author > UA > spec author. Minor convenience for the spec author is worth nothing against inconveniences at a higher level. > Need I continue? And what does one get from this? The ability to tell the > author that, for a functionality they don't yet have, they need type nine > fewer characters??? No thanks. I don't want to increase the already high > level of 'perl'-entropy present in these specs. Are you a doppelgänger of > Larry Wall? ;) It's 15 fewer characters, actually. I, um, don't know what to say if you think "event.weight" over "event.fontface.style.weight" in a FontFaceEvent is "perl-level entropy". I literally don't know what answer to give in response to that. ~TJ
Received on Tuesday, 11 September 2012 04:12:57 UTC