[openable] Does defaultopen as a separate attribute make sense?

[lukewarlow]

Currently the openable explainer uses a defaultopen attribute.

This was based on the previous proposal for initially open popovers. Naming aside does it make sense to be a separate attribute here, or should an alternative approach be taken?

[lukewarlow]

What if we want a way to define initially open openables and then in future we also want to do the same for popover, the two will conflict and we'll have to decide which one wins.

Perhaps it's good that they'd conflict because if we had a separate mechanisms and both were used we'd still ultimately have to define a winner (or perhaps both should lose?).

[sorvell]

Some related points and questions:

• is this only for the initial state? Having a property based API is pretty nice for declarative frameworks which can more easily set properties than call methods.
• given <dialog popover=... openable>: my understanding is that popover provides extra functionality v. just <dialog> but does openable?
• given <div popover=... openable>: is popover basically a superset of openable and if so, should it win out?
• if the functionality is mostly duplicative perhaps with the most capable mode winning out, since <dialog open> exists, open could just be used in lieu of defaultopen; however, <details open> means "open contents" which is different from openable's open.
• if open could otherwise be used and <details> is the only outlier, perhaps it could/should not support openable and open could then be used instead of defaultopen?

[lukewarlow]

It's only an attribute for initial state, we're definitely not doing state reflection to an attribute. That being said we can possibly have a property that can be used instead of methods. But I suspect it should be methods because it will probably do various things (such as maybe setup focus ordering and stuff).

[mfreed7]

Seems to me that a content attribute should be the way to go here, which specifies only the initial state (timing needs to be defined carefully) of the openable. And I do have somewhat strong views on the name, that it should be initiallyopen. The word "initially" concretely says what it does. The word "default" is somewhat close, but doesn't imply anything about timing.

Side note: content attributes usually always have to reflect to IDL, so it'll need a div.initiallyOpen. And that's why the timing needs to be carefully designed - does setting that on an element and then inserting it into the DOM cause it to be open?

[lukewarlow]

I think yes we'd need an element insertion steps to account for setting it before inserting.

I also agree on the name fwiw. I was going for the bad name first change later approach.

I think my main concern is around clashing with popover.

I also think the reason initially makes more sense than default is because it's not "resettable" like the default value is on form elements.

[css-meeting-bot]

The Open UI Community Group just discussed [openable] Does defaultopen as a separate attribute make sense?.

The full IRC log of that discussion

<masonf> +1 to "bruce" as the name
<keithamus> lwarlow: defaultopen/initiallyopen - it has a conflict on whether it should be open as popover or openable
<keithamus> lwarlow: in the case of dialog it opens as non-modal dialog.
<keithamus> lwarlow: some folks want this for popover, so if we were to add it would use the same attribute
<masonf> q+
<masonf> ack lwarlow
<sorvell> q+
<keithamus> lwarlow: so we could have separate attributes, or an enum attribute (with missing), third is that we have 1 attribute and specify a way to handle this
<keithamus> lwarlow: I imagine it wouldn't be super common but it's possible
<keithamus> masonf: my vote for the eventual name is initiallyopen, but +1 bruce for now so we can get to initiallyopen (half kidding)
<masonf> ack mason
<masonf> ack sorvell
<keithamus> masonf: I like your idea of a missingvalue default, initiallyopen would pick, but if you want to override it to be the popover or openable or whatever you didn't have as default
<masonf> q+
<keithamus> sorvell: it seems like we've modelled this after details, details has an api open/not open, it's not initial. It's state via property. Based on my current understanding I'd be more in favour of some name - open or not open like details. That would be my desire
<brecht_dr> q+
<keithamus> masonf: please no; both of those have issues, particularly around removing the element from the dom and putting it back, what happens when you add and subtract the attribute, and so on. It's a lot cleaner if it's only initially opened, what happens when you first insert the element, but not after that.
<keithamus> masonf: reflecting current state seems to be much cleaner, more ergonomic, with a pseudo class. :open just works, no edge cases for removal/insertion
<keithamus> masonf: however an attribute is good for initial state
<keithamus> masonf: it is infact semantic. This element is open to start with
<masonf> ack mason
<keithamus> masonf: attribute feels right, reflecting attribute feels wrong
<keithamus> sorvell: this is why we're doing it in the platform - to deal with the hard cases. I care less about the attribute than a property, but every single web framework could use it out of the box. It's tied to the functionality we want so not a slam dunk but it's a big win to have a declarative attribute
<keithamus> sorvell: every single web framework that exists has a way to alter properties
<lwarlow> q+
<keithamus> sorvell: I don't understand the whole feature of openable well enough to have an opinion on this though
<keithamus> masonf: how is property different to calling .matches?
<keithamus> sorvell: can't do it in react without a ref
<masonf> ack brecht
<keithamus> brecht_dr: I just want to drop a bombshell; as a developer the most common use case I want to do personally, I want it initially closed on a small window, but open on a large window
<bkardell_> YES
<keithamus> brecht_dr: so more of a question, but can we consider that idea?
<masonf> hmm interesting
<masonf> ack lwarlow
<keithamus> lwarlow: would you need it to have a trigger on a large screen? Or always showing?
<bkardell_> yeah always showing is probably fine ;)
<keithamus> brecht_dr: in most cases not... but thats most cases
<keithamus> sorvell: a drawer can often have this. sometimes open, sometimes an overlay like popover
<keithamus> lwarlow: having it open you can do - force it to display block even when closed, the button linked wont say aria-expanded.
<keithamus> lwarlow: popover vs openable case... you wouldn't be able to do initiallyopen declaratively, you could do two buttons though
<keithamus> lwarlow: hide or show based on screen size, command attribute determines behaviour
<keithamus> lwarlow: on small screens initially closed, command=showpopover, another with command=openopenable, on large screens hide both and set to display block
<keithamus> brecht_dr: so with hidden buttons no ax tree. That _could_ work.

[mfreed7]

I'm tentatively removing Agenda+ - feel free to put it back if you'd like to discuss this again.