- From: Matt Giuca <notifications@github.com>
- Date: Sun, 12 Jul 2020 22:06:10 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/530/657360518@github.com>
Thanks for elaborating, Daniel. I think it's also important to note that basically every example using `display-override` is an edge case (that's exactly the point: it's for when the "usual" ordering of `display` isn't good enough for you). So even though these examples look awkward because the developer is having to think through the effects both with and without support for the new member, they are awkward *because they are edge cases*. In the normal case, that we continue telling developers to use in our public guides, which 99% of sites can use, you won't even know about `display-override`, and continue to say `display: standalone`. I think that's important to keep in mind, since we've had [a lot of feedback](https://github.com/dmurph/display-mode/issues/10) saying "why not design it so that developers set `display` for legacy browsers and `display-override` for new browsers?" The problem with that is that 100% of developers now need to consider the distinction between the two, and consider how legacy and new browsers will react (`display` + `display-override` is the new normal, not an edge case). Whereas with the current proposal, `display-override` is only something that 1% of developers need to be concerned with. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/530#issuecomment-657360518
Received on Monday, 13 July 2020 05:06:22 UTC