Provide a programatic API for setting the active affordance

[rjgotten]

Yay on convenient switching between different presentational and interaction paradigms for what is essentially semantically the same thing. Nay on tieing it implicitly to media queries in any way shape or form. Especially now that container queries are on the horizon.

Consumers of this type of element areprobably best served if there is a basic 'dumb' form of use where the affordance is simply set via HTML attribute and can always be driven externally. Whether that is via a MediaQueryListener; a ResizeObserver or whatever custom set of logic any web-application; -site; or -page may need. And then add an additional layer on top of that to control it directly from HTML. Possibly along lines similar to the sizes attribute used with image source sets, where you have a list of values corresponding to media query conditions with a value (the chosen affordance). Just need to figure out an elegant way to express that either in context of the media or in context of the container, if you want to also support container query use cases.

[bkardell]

Thanks for the thoughts @rjgotten.

I'd like to try to separate a proposal from the custom element a bit...

re: what we might ultimately propose: There is no intention to propose something that only works for viewports, for example. There's just a lot to figure out.

This custom element has limits and constraints and choices that are not likely to be present in an ultimate proposal. It definitely requires you to use your imagination on some things and we've tried to note where we're handwaving. The means of expression is definitely one.

That said - you raise some interesting points about what is potentially interesting to explore with a custom element and what you can/can't today...

With what we have today, one can sort of provide something in their HTML which is reasonably srcset like via the style attribute. It isn't pretty but it is possible at least.. All of these will work if you include them in your HTML from the server...

<!-- its just tabs, always -->
<spicy-sections style="--const-mq-affordances: [all] tab-bar"> ... </spicy-sectons>

<!-- it's just tabs on the screen, or not in print -->
<spicy-sections style="--const-mq-affordances: [screen] tab-bar"> ... </spicy-sectons>

<!-- several conditions -->
<spicy-sections style="--const-mq-affordances: [(max-width: 40em)] exclusive-collapse |
     [(min-width: 60em) ] tab-bar"> ... </spicy-sectons>

But... aside from not being pretty, it isn't dynamic (that is, if you change it it won't update, it's only read once). I think it is a pretty strong point you make on the value of being able to, even at this stage of things, let folks experiment with managing this on their own (with ResizeObservers or anything else)

I guess I'm personally hesitant to introduce attribute 'sugar' for this at this stage because there is already a lot to figure out about the architecture, layering and relationship of attributes, properties, css and so on. At some point though, I think we can imagine that there is an internal state about which afforandance is deployed, and I think I would be considerably open (again, speaking only for myself) to provide a method to set that via an API.

So... What if we offered that - something like:

element.setActiveAffordance('collapse') / or tab-bar or exclusive-collapse /

Would that be enough to use to explore? I made a little fork that demonstrates use of this with buttons - there are no rules here or queries, just method calls...

https://spicy-sections.glitch.me/programatic.html

Idk, what do you think? Would that be helpful? Not enough?

[rjgotten]

That would already be helpful in an experimentation phase, definitely. But then: why stop there? I.e. why not go all the way with: element.affordance = "collapse". The nominal form of interaction to configure HTML elements from JS is via properties linked to similarly named HTML attributes, after all.

[bkardell]

The reason I stopped there was just not to get entangled in the followons and comparisons of linked properties/attributes, whether they are reflecting, and how people understand it in the context of the element vs a proposal. Possibly it could be that, we'll discuss... Given that the proposal is not to tie to MQ, and the actionable thing here for the element (this repo) seems to be to add a programatic API - would you feel ok about us changint the title to reflect that?

[rjgotten]

Yeah. That's fine. And the main point really. :) (Truthfully you're right about the hornet's nest of IDL-like element attributes/properties.)

[bkardell]

This seems to be done, tested and documented, so I am closing it. Feel free to reopen or open a similar issue if something remains