W3C home > Mailing lists > Public > www-archive@w3.org > February 2021

Re: appearance:base etc

From: Greg Whitworth <gwhitworth@salesforce.com>
Date: Tue, 9 Feb 2021 12:35:22 -0800
Message-ID: <CALeAaptOFV3=2MTNSsbj+k2BNCkYnfZDda_x8QBRfTYXCGso1A@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>
Cc: www-archive@w3.org
Thanks Florian,

Alright - would you mind filing them as Github issues and while they may be
explainer questions, as noted they're generic questions since the route we
pick will impact other controls we tackle. I've started throwing together
some rough demos of the other options you all raised.


On Tue, Feb 9, 2021 at 11:04 AM Florian Rivoal <florian@rivoal.net> wrote:

> Hi Greg,
> I don't know if I'll find time to comment on the explainer when you have
> it out, so I'll write it down here.
> First, I'd like to reiterate that I am supportive of the general approach
> of having appearance:base and having that activate an explicit DOM for the
> control being brought into existence.
> But you wanted a resolution beyond that, and wanted us to resolve on the
> ::indicator pseudo, and I have questions to be able to make a full opinion
> on that. Maybe they'll be covered in the explainer already, but if not, it
> could be good to add that.
> If the default styling we wanted for checkboxes was based on a unicode
> code point rather than the SVG, and assuming we found a way (like a special
> origin) to have a UA style that only applies when appearance:base is on, I
> think we wouldn't actually need an ::indicator pseudo, and could just do
> something like ::before { content: "✔️"; }
> I am way out of my comfort zone as soon as we speak about shadow DOM and
> slots, but if I'm not misunderstanding too many things, authors who want
> something beyond the unicode ✔️ could inject a fancier svg checkmark
> through the slotting mechanism.
> That does mean that people would need to "reach to a graphical design
> program or library" to get that svg, but I'm not sure I feel all that bad
> about it, given than the amount of stuff you can do on a plain piece of
> text is already not too shabby, so that could be enough for people who
> aren't trying to control every last detail.
> As was mentioned on the call, when you're at the point where you want to
> replace the path, you should probably swap out a wholly different SVG
> anyway, and if you're only switching property on the existing SVG, sure
> what you can do there is a little different and a little richer than what
> you can do on text, but you can already do quite a lot on text.
> First, this assumes that I'm not misunderstanding how the UA styling and
> the slotting thing would work. Maybe I'm getting this wrong, and that
> wouldn't work.
> Assuming I am not wrong, maybe there is a common enough tweaks that people
> want to do on checkboxes that cannot be done with text and that justify a
> specific SVG where these tweaks are doable through style only.
> But in that case, I think I'd like to see evidence of those particular
> common customizations, and evidence that the particular SVG you're
> proposing to use as the default does enable them.
> —Florian
> PS: This is CCed to www-archive, so if you need to copy or reference any
> part of this, it's public.
Received on Tuesday, 9 February 2021 20:35:47 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 9 February 2021 20:35:47 UTC