Re: appearance:none, UA stylesheets, and the like

Yeah, everything you outlined I don't disagree with although I have
arguments in the inverse as I feel there are some generalizations and
honestly don't hold up against the research I've seen. However, we can do
that later and on a control by control basis, heck maybe even at a
part-by-part basis.

Specifically regarding the controls that have parts that are external
windows. This is specifically addressed in our explainer regarding security
implications; so any control that opts in (yet to be defined) into allowing
fully styleable controls (in this example using the select) the windows
will not be able to escape the bounds of the viewport.

> The <select> popup currently has the capability to break outside the
window of the browser or of an iframe. Sites likely depend on this
behavior, but we would need to remove it for security reasons if <select> is
allowed to contain arbitrary content. So again this would need to be opt-in
to avoid breaking existing sites.

Ultimately, I think there is a path forward and I like us taking a few
concrete examples; looking at the research and determining what makes sense
for that control when it comes to partial styling. Florian, Cameron, would
you like to be included in the meeting I plan to setup with Tab & fantasai
regarding hearing their historical partial styling proposal? Or fantasai
would you prefer that Florian (Cameron?) and I sync up to rough this out a
bit further into an explainer form to at the very least be able to reason
about the pros/cons of something defined in such a manner?

~Greg



On Tue, Aug 18, 2020 at 5:59 PM Florian Rivoal <florian@rivoal.net> wrote:

> Hi Greg and heycam,
> (CCing fantasai)
>
> I had a brief follow up conversation with fantasai after the open UI call,
> where we did manage to resolve some of our philosophical differences
> exposed during the call (fantasai, correct me if anything I'm saying here
> is inaccurate), and I think there's a nice way forward from there.
>
> First, there's no disagreement at all that providing authors with the
> ability to write parts of their own controls and then telling the browser
> to hook them up correctly and inject the desired behaviors and relations is
> desirable. That's all good. What I am talking about the case where we're
> not doing that, and where authors are trying to some degree or other to
> restyle / influence the look and feel of existing html control elements.
>
> When we have a button, or a checkbox, or one of these controls that has a
> fundamentally simple structure, fantasai is fine with having the
> appearance:none structure be made explicit, and to have a default UA style
> be defined.
>
> However, it gets trickier for things like a select, or an type=range
> input, or other complex controls. With the select, the closed state is
> somewhat buttony, and so here too, having its appearance:none mode have a
> defined structure and a defined UA style would be fine. But what about the
> open state? She argues that that part should remain native-ish, and the
> browser should retain the freedom to do all sorts of UI adaptions to match
> devices/environment/window size/etc. To the extend we want to give authors
> control over what the open state looks like, it should be through fuzzy
> hints like accent color and possible other things along these lines, not by
> making appearance:none flatten the entire structure of the complex
> component into the lowest common denominator.
>
> There are actually open issues going in that direction in the current
> appearance spec, I think we can find a reasonable middle ground there.
>
> I need to define a few terms here to express what I want to say:
>
> * a component or of part of a component is *influenceable* if it can
> respond to things like accent-color, or color-scheme, or other future
> properties that give a fuzzy hint at what the other want, while leaving the
> precise way to interpret these propeties' effect up to the UA. Any and all
> hints can be ignored (although honoring then when practical is desirable).
> It may be reasonable to allow some traditional properties like color or
> font-family to be useable as hints by influenceable controls, but layouty
> things like padding or flex should not, as you cannot make any assumption
> about the structure of such controls.
>
> * a component or part of a component is *styleable* when the way is looks
> is precisely expressed using css-properties onto a DOM structure of some
> kind. We can distinguish:
>   * "shallowly styleable": the outer parts of a control are styleable, but
> some of its sub-components are not, and are merely influenceable.
>   * "fully styleable": the entirety of a control, recursively to any
> sub-component.
>
> Under appearance:auto, the UA can make controls influenceable.
>
> appearance:none makes controls styleable. It doesn't necessarily have to
> make them fully styleable though, and some of them could be shallowly
> styleable.
>
> What I think we need to do is:
> * define which controls are fully styleable, and for those that are, what
> the underlying DOM structure is (may be nothing more than a div, may be
> more, but we need to say), and what the UA stylesheet for this structure is
> * for those that are only shallowly styleable, define what the underlying
> DOM structure of the styleable parts are, how the unstyleable
> sub-components fit into that, and what the UA stylesheet for the styleable
> parts are. It's fine to say that some subcomponents aren't styleable, but
> for what is styleable, the complete UA stylesheet should be defined.
>
> I think it's important to agree on what is styleable and what is not, and
> when they are, how they work. For example, with appearance:none applied, it
> would be bad if the magnifying class icon of a type=search input, or the
> downwards pointing arrow of a closed select, are done via css on the
> ::after in some browsers, via css on some kind of ::search-icon or
> ::select-button in some other browsers, and done via native components in
> yet another browsers. Same logic for the checkmark in a checkbox. To me,
> all this should be styleable, and therefore have a known DOM structure with
> a standardized UA stylesheet.
>
> On the other hand, I don't have a strong view that something like the
> track and knob of a type=range input need to be styleable. Maybe they can
> be some kind of influenceable replaced elements slotted at a known place
> within the structure. But if so, it would be good to decide on whether they
> are 2 replaced elements whose placement is done via CSS on a known DOM
> structure, or if the combination of the track and knob is one styleable
> replacement element thingy.
>
> The lower bound of what needs to be styleable (and therefore fully
> specified, including DOM structure and UA stylesheet) is set by compat
> constraints. We might want to make more than that be styleable, but we need
> at least that.
>
> Maybe we also need an additional notion, to describe components whose
> appearance within the page is fully styleable, but which, when activated,
> pop up some influencable but not styleable overlay or full-screen dialog,
> like a clock face to pick the time, or a windowed color picker, or what
> have you. Or maybe all controls should always have the right to do that,
> and that needs not be observable to authors as such things are out-of-flow
> / out-of-page, and don't influence layout.
>
> Whether select is one of those, or a shallowly styleable thing, or a fully
> styleable thing is an interesting question onto its own.
>
> —Florian
> PS: This mail feels like it would be even longer if I needed to post it to
> some mailing list or github issue that doesn't have the context of the
> conf-call we just had, but nothing in it is meant to be confidential, so
> I've cced www-archive to make it linkable, and you may repost this to
> whatever other place feels appropriate.