Re: [css-font-loading] maintaining invariants of a FontFaceSet’s set entries

On Sat, Mar 21, 2015 at 6:59 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Before the spec was change to make FontFaceSet setlike, there were a few
> requirements on how the FontFace objects in a FontFaceSet were to be
> maintained.  We need to add some of these back.

Thanks for catching that I dropped these!

> 1. It used to be required that CSS-connected FontFace objects all
> appeared before the other FontFace objects in a FontFaceSet.  Now there
> is no such requirement.  It is required that they are kept in document
> order, but doesn’t say anything about how they are placed relative to
> the other FontFaces.

Done, ordering restored.

> 2. Calling FontFaceSet.add() with a CSS-connected FontFace object used
> to throw an InvalidModificationError.  I don’t think there’s a good
> reason to allow CSS-connected FontFaces in multiple FontFaceSets.  So
> how about we throw in that situation, and ignore it if you try to add a
> CSS-connected FontFace to the FontFaceSet it is already in (which is the
> behaviour of a standard Set’s add method).

Done.

> 3. Similarly, FontFaceSet.delete() used to throw when trying to remove a
> CSS-connected FontFace.  Whether an exception is thrown or the request
> is ignored, I don’t particularly mind.  Ignoring the request is probably
> implied by the requirement to keep all CSS-connected FontFaces in there
> by §4.2, but should be made explicit somewhere.  That would be
> consistent with having clear() not throw because it is attempting to
> remove the CSS-connected entries, too.

Done, it's specced as a no-op.

~TJ

Received on Wednesday, 8 April 2015 23:03:45 UTC