- From: Mason Freed via GitHub <sysbot+gh@w3.org>
- Date: Sun, 04 Oct 2020 03:36:01 +0000
- To: public-css-archive@w3.org
> But again, "here's some colors, do _something_ with them" is not actually an option on the table. That's not a spec, and I will formally object to attempting that; it's _giving up_ on there being a spec, and I'd rather be more honest and continue not having a spec instead. I understand you'll formally object, but I do actually think this **is** an option on the table. It's "option B". And there are several people (many developers, surprisingly to me) that appear to be advocating for option B. I'm less pessimistic that we could define an "option B" in a way that is close enough to a "spec" that there is some level of usefulness to the feature. > Continue iterating on the spec and reaching consensus on the details; trying to push for an even more explicit "yes" on (1) feels like attempting to lock down a solution before there's consensus. The reason I created this issue, and continue to want to reach an **A** or **B** conclusion first, is that the shape of the solution to **A** is vastly different from **B**. Without this decision first, we'll never reach consensus on a specific spec text, because we'll still be implicitly debating the basic A vs. B question. @bradkemper I'm going to mark your response as a definite vote for Option B. One point though: > Suppose I am an implementor 10 years in the future, when skeuomorphism is popular again, and computer screens are typically the size of the top half of a large office wall (they stick to the wall like contact paper, and only cost 25ยข per square foot). So I design a "switch" control to be an actual photo of a late 20th Century light switch and switch plate, with a bit of a perspective angle. The overall shape is a vignette, so some yellow wallpaper with brown stripes shows around the outside of the switch plate. In an "option A" world, the intent would be to get ***current*** controls to all behave the same. If you read my proposal (again, to over-extra-super-emphasize, this is merely one potential example of an option A solution), it is pretty clear to spell out that **if** a control you're working on looks like one of the ones listed in the non-normative section, **then** you should follow the behavior listed. In your example, clearly your new control looks **nothing** like the ones in the list, and you should do what makes sense. There's a whole section emphasizing that innovation should not be limited by the spec. Perhaps when you finish your new control in the future, you should also file an `accent-color` spec PR to define your new way of thinking about switches, and include it in the non-normative section. And then other implementations that copy yours will want to follow your lead so there's still interop. -- GitHub Notification of comment by mfreed7 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-703196621 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 4 October 2020 03:36:03 UTC