Re: [css-font-loading] FontFace objects and the FontFaceSet interface

On Fri, Feb 28, 2014 at 12:00 AM, John Daggett <jdaggett@mozilla.com> wrote:
> Comments related to the Font Loading spec from Jonas Sicking:
>
> One thing I don't know enough about to verify though is if the logic
> about when FontFace objects are added to the map makes sense. Has
> someone else checked that.

I probably need to specify that CSS-connected FontFace objects are
added when the CSSStyleSheet object they're created from is added to
the document.

> Something that strikes me as a bit strange is that FontFace objects
> seems to have an important identity.

I talked with Jonas about this in IRC, and I think this is a bit of
mental disconnect.  Jonas appeared to consider Array a more
"base-level" or simpler type of collection than Set.  I can't speak
for him, but it seemed like it was from his impression that a Set is
basically a Map whose values are meaningless, and so the fact that a
key is a FontFace object rather than an integer makes it more
complicated.

I don't agree with this; all of Array, Map, and Set are equally base
collections, with different constraints and information imposed on
them.  In particular, Array implies that there's a meaningful and
relatively stable ordering, so that the index is meaningful.  Since
that's not the case with FontFaceSet, I wanted to use Set.

> Since the FontFaceSet interface
> keys on the identity of FontFace objects, it means that you can't do
> lookups based on urls or names. I.e. you can't query the FontFaceSet
> interface to check "is the font at url http://example.com/font.woff
> loaded" or "is a font with name 'foopy' loaded".

This would require a query interface.  That's not a bad idea, but it's
not something I think is necessary for this first level.

I'm not sure what this has to do with the nature of FontFaceSet,
though.  Are you suggesting switching it from a Set to a Map, and
having the key be one of those values?  I'd be against this, for a few
reasons:

1. it bakes one type of query into the structure of the collection,
when none of them are really "primary"
2. it requires a multimap, since multiple FontFace objects can have
the same URL or name.
3. If url is used, some FontFaces aren't loaded from URLs at all.
4. It reflects a core aspect of the FontFace in the organization of
the collection, which implies that the collection is either readonly
or moving a FontFace around in the collection changes that aspect of
the FontFace.

> Though of course you could always enumerate the full set and see if
> any objects match what you're looking for.

Yup, that's easy to do right now.

> But if that's the only use case, then the set is just an Array and not
> a Set.

This reflects what I said up above - a Set isn't a Set necessarily
because the object identity of the things inside of it are important;
it's a Set because it's not meaningful to have more than one of a
given object in it, and the order is either unimportant or only weakly
important.

> Also, what happens if a FontFace is added to the set using .set()
> rather than through .load()?

This question is based on a mistaken premise; FontFace#load() doesn't
add a FontFace to anything.

> And what happens if a FontFace is removed
> through .delete()?

Already defined - the system only looks for fonts (when CSS or
something else is requesting a font) that are in the document's
FontFaceSet.

> And what happens if something other than a FontFace
> is added through .set()?

Handled by WebIDL - that's a TypeError.

~TJ

Received on Tuesday, 4 March 2014 23:12:06 UTC