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

Re-pinging this thread. Who should I setup a meeting with regarding next
steps on partial styling?

~Greg

On Tue, Aug 18, 2020 at 6:23 PM Greg Whitworth <gwhitworth@salesforce.com>
wrote:

> 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.
>
>