W3C home > Mailing lists > Public > www-style@w3.org > September 2012

Re: [css3-fonts] FontLoader v2

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 10 Sep 2012 21:12:09 -0700
Message-ID: <CAAWBYDCNh3ELn74nGPaQsdRzA_7g=UHs5rCEcs-BM1WSGT2F9A@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:00 GMT