- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Feb 2023 17:52:25 +0000
- To: public-css-archive@w3.org
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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8259#issuecomment-1440505703 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 February 2023 17:52:26 UTC