Is there any principle/decision process we can add for "don't make it worse"?

[bkardell]

There is definitely a tension and one that we will probably continue to have and I mentioned on the call today that it might be nice for us to think about this as a general problem and see if we can derive at least some kind of advice or agreed principles about how we deal with this, otherwise I think it could just take a long time and be very confusing and potentially frustrating...

As we add cool new features, it's sometimes the case that they are "close, but not quite" to something else entirely, for which they are not appropriate... .Often those "other" cases are also things we know need to be done, but aren't currently providing an answer to. At various levels, one can observe a general class of problem: If we make a very easy way to do something authors will tend toward trying to use that for the other cases to, and observe that that might be worse.

I'm sorry, I'm not sure I worded that very well, it's vague, but it's the fact that I can't articulate it any more clearly than that that makes me think it's a thing worth discussing a little. Two cases I've seen so far of this is that popup encompassed a bunch of use cases, and we decided recently that there were open questions around the "hints" use cases that we'd like to punt that to level 2. In #617 there was an observation that

One downside is that folks trying to build "hinty" things with the pop-up API will probably turn to popup=auto instead, which will likely make a11y worse for a while.

Similarly on our 'panelset' work, it was observed after the creation of our prototype that many of the use cases panelset is ideal for probably shouldn't have aria semantics, etc - and that if we made that really easy to do, people would definitely do it and that would make it worse than if they hadn't had aria semantics. Conversely, our solution wasn't great for most of the cases where aria tabs are universally seen as appropriate - but if we somehow found a way that we agreed was good without aria sematics (we still haven't entirely defined or tested that), and only shipped that then people who really needed aria tabs might choose this -- and thus again, make it worse. The nice outfall of this was that it led to separating the two things in #599 - but it's still not entirely clear how we don't wind up back to the same question unless we solve both at the same time.

To be clear: I think these are valid and worthwhile things to carefully consider and I'm not looking to specifically answer either of those, or change any minds - I'm just wondering if this is a thing worth somehow discussing in a general way how we plan to avoid or decide things like this, or at least narrow it down and define a kind of concern we can try to avoid.

[bkardell]

Maybe we should just close this - I don't see any articulated principles like this on the site. It would be nice if we had them but if we dont' I don't see a reason to keep this open

[css-meeting-bot]

The Open UI Community Group just discussed Is there any principle/decision process we can add for "don't make it worse"?.

The full IRC log of that discussion

<gregwhitworth> Topic: Is there any principle/decision process we can add for "don't make it worse"?
<gregwhitworth> github: https://github.com//issues/621
<gregwhitworth> bkardell_: we're all new to this and we need to figure out what we're doing
<gregwhitworth> bkardell_: we had a couple of things that went sideways a bit and it seemed like maybe we should document some things going forward - what are good and desirable or not
<gregwhitworth> bkardell_: but we haven't done any of that and maybe we should close this issue
<gregwhitworth> bkardell_: and I found some old issues it's probably going to sit there forever and ever so what's the point
<gregwhitworth> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> bkardell_: there are not a lot of things that are principles in the TAG but I don't think they're targeting this particular space
<gregwhitworth> dbaron: I think it's a good principle, it's specific to some piece to the order of constituencies is a pretty widespread thing that many groups need to think about
<gregwhitworth> ACTION: Greg to stand principles page following resolution of definition of interoperable styling
<dbaron> s/specific/related/
<gregwhitworth> Zakim, end meeting

[github-actions]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[bkardell]

ACTION: Greg to stand principles page following resolution of definition of interoperable styling

If there was something that was supposed to happen here after #688 (I think that is what is referring to), I am not sure it ever did, or if it ever will, realistically. Should we keep this open or close it? I am happy enough to close it.

[bkardell]

I am deciding as the opener to close this. Feel free to reopen if you disagree.