[css-images-3] Define optimizeSpeed as nearest neighbor

[fantasai]

The spec preserves the old SVG optimizeSpeed and optimizeQuality keywords of the image-rendering property, defining them as alisases of crisp-edges and smooth.

However, in #6038 we confirmed that crisp-edges is not necessarily nearest neighbor, and that browsers may use a more sophisticated edge-preserving algorithm (which might not be as fast).

Would it make sense to simply define optimizeSpeed as nearest neighbor? This guarantees its speed and also gives authors direct access to nearest neighbor.

(Tangential follow-up: should optimizeQuality stay mapped to smooth or should it map to the new high-quality keyword?)

[cdoublev]

[...] defining them as aliases of crisp-edges and smooth [...] should it map to the new high-quality keyword?

I am sorry for the following aside/question but should it be aliases or mappings? FF handles them as aliases (Chrome does not support the CSS property). The spec suggests a mapping:

a user agent must accept them as valid values but must treat them as having the same behavior [...]

Mapped values are preserved and aliases are replaced, iiuc. I do not know when/why a legacy value should be aliased vs. mapped, or if consistency does not matter to you for this kind of minor detail.

[dbaron]

Further, if optimizeSpeed is different from all the other values, should it still be deprecated?

[tabatkins]

First and probably most importantly, I don't think the mappings really matter. They exist only because I'm reusing a good property name from SVG that already had some values, even tho iirc browsers didn't actually pay attention to them (other renderers might have). Giving them an approximately correct answer seems fine; we're not designing these values from scratch and don't care about whatever use-cases they might have been originally intended for.

In that light, I think it's fine for optimizeSpeed to continue to map to crisp-edges. It's approximately right, and altho the value allows for other algorithms, nobody does anything beyond NN right now, or is planning to.

---

optimizeQuality absolutely should not be mapped to 'high-quality'. That value comes with implications that definitely weren't present in the original value. For example, if you knew were rendering in a sufficiently powerful machine, applying optimizeQuality to everything would be reasonable, but applying 'high-quality' to everything is a no-op. 'smooth' is the correct analogue for it.

---

I am sorry for the following aside/question but should it be aliases or mappings? [...] I do not know when/why a legacy value should be aliased vs. mapped, or if consistency does not matter to you for this kind of minor detail.

I don't think it matters what the behavior is, but it is good to be interoperable in this regard. I specified them with "behaves as" to avoid the possibility of breaking any scripts querying computed value and expecting the legacy values. But it's very possible that this doesn't matter in practice, and if a value alias is easier for impls, I'm fine with switching to that.

[cdoublev]

I don't think it matters what the behavior is, but it is good to be interoperable in this regard.

Agree. Personally, I only care about interoperability. Aliasing possibly allows to later drop legacy values, and the author possibly can see he is using a legacy value. I think neither is easier to implement.

[css-meeting-bot]

The CSS Working Group just discussed [css-images-3] Define optimizeSpeed as nearest neighbor, and agreed to the following:

• RESOLVED: close, no change

The full IRC log of that discussion

fantasai: We have SVG values that correspond to SVG keywords
…It was observed browsers might be able to use better algorithms
…Should optimizeSpeed be the same as crispEdges?
TabAtkins: These legacy values are only around because I’m reusing names from SVG
…As far as I know, no browser ever did anything with them
…Other renderers might, not sure
…For the web, it doesn’t seem like it matters what we map them to
…I do object to adding bespoke behavior for these values
…If we want to do something with nearest-neightbor, we should do that
…If we do want to do that later, it would be fine to swap mapping
…For now, what exact value we define isn’t important
…I suggest we close, no change
fantasai: I think it’s an okay state for now, but is risky in the long run
…If there are people who would want nearest-neighbor, maybe we should add a keyword specifically for that
TabAtkins: I’m happy to switch the alias over in that case, but don’t want to do anything special for it now
fantasai: Seem fine; do we need a `nearest-neightbor` keyword?
TabAtkins: That woul db e a different issue
astearns: Proposed resolution is close, no change for now; can discuss separately if we need `nearest-neighbor` or any other
…At that point we could discuss whether to change the alias for `optimizeSpeed`
astearns: Objections?
RESOLVED: close, no change