Re: Unordered setsmaps, for when ordering is hard/expensive/unwanted?

On Sun, Sep 1, 2013 at 2:25 PM, Brendan Eich <brendan@secure.meer.net> wrote:
>> Tab Atkins Jr. <mailto:jackalmage@gmail.com>
>> September 1, 2013 11:38 AM
>> There's nothing wrong with the current "insertion-order" semantics for
>> author-level Maps and Sets. Those are fine. However, "insertion
>> order" is meaningless for some *UA-provided* Maps and Sets that we're
>> producing now or will in future APIs.
>
> It doesn't matter who wrote a map or set in what language. If a spec
> defineds a map or set, we (Mark first, I'm right behind him) want
> determinism. Quoting Mark:
>
> "For spec'ed abstraction X that inserts into a visible table M, if we want
> the spec of abstraction X to be deterministic we need to specify in what
> order it inserts into table M, since that order itself is visible."
>
>
>> We thus have to define an
>> alternative ordering,
>
>
> That does not follow. We have to define an ordering. Best if it can be
> defined as if the map or set were self-hosted, so insertion order suffices.

The problem is that "insertion order" simply does not exist for some
types of things, or if it does, it's an artifact of individual
implementation ordering, and thus not reproducible across browsers.

I gave two examples of this:

1. The property name->value map returned by getComputedStyle().  (As I
said, for normal CSS properties it's actually an object, not a Map,
for legacy reasons, but the same point holds, since there's still an
observable order.) There's an ordering for the individual properties
that enter the CSS cascade process, but not for the output of the
cascade, which is what gCS returns.  For custom properties
specifically, defining an alternative order is expensive - we have to
define and invoke unicode-aware sorting solely to provide a
predictable order for the properties, which seems distasteful.

2. I plan to define a FontSet API for exposing the loaded fonts
available to a given document/worker.  This is a mix of UA-loaded
fonts, from @font-face rules in CSS, and author-provided fonts, from
explicit constructor calls (either referring to a font by url, or
constructing it straight from a TypedArray, for pdf.js use-cases).
It's possible to define an analog of "insertion order" at first as the
stylesheet-order of @font-face rules, but as you change what
stylesheets are loaded and load fonts manually, the ordering becomes
harder to define and racy.  For example, what if you disable a
stylesheet, then re-enable it?  Should the fonts generated by
@font-face rules in that sheet move to the end of the Set's ordering,
since they were "removed" and then re-added?  This sort of ordering is
annoying to maintain, and of seemingly no value. If you load a
stylesheet and a manually-constructed font, do you rely on execution
order of the load start to dictate the Set order, or race the network
loads against each other and insert them whenever the loads
individually complete?  If we have off-main-thread parsing, or you're
in an isolated-process worker, can you get a manual load in the middle
of a stylesheet's parsing?

These two cases just recently came up in my work; I doubt they'll be the last.

~TJ

Received on Monday, 2 September 2013 07:38:44 UTC