Matthias_Geisler_WMDE added a comment.
Meta note: To be honest I do not like, how this discussion is now starting –
putting somewhere a -2 and start a discussion without a appropriate pointing
on the concrete thing where you see the problems.
| As written above, I think trying to generalize the Termbox
EventEmittingButton to be used everywhere in Bridge is an approach that is
flawed in its premises. This creates an overly complex component that does
multiple jobs (Link and pure Button) and tries to conform to multiple
conflicting styles (Termbox and Bridge/OOUI). |
|
Why you think it's flawed in its premises? Where do you see the growing
complexity? (It would be very helpful where you think it's to much in the code,
so we might fix that [together]. I do not think it's fair just to say it and
not point on it) Or do try to say in a sneaky way Termbox did a bad job?
To the concrete points:
- I do not see that OOUI, Bridge and Termbox conflicts - Termbox/Bridge can
simply just not reuse OOUI less directly at this point in time. Actually what
you are suggesting mean currently we making Termbox and Bridge also excluding
in each other, which is the exact opposite of the ground idea of this ticket.
The consequence is, that we increase 2 to 3 implementations for the same thing.
- I do not think that it is to hard for devs to be aware that a component can
have a different HTML-tag, especially when he just a minor influence on the
appearance or behavior. But:
- since OOUI uses a a-tag as well as Termbox, we can simply rollback to the
given behavior, if you do not like it.
- the reason, why it's there is just, because I agreed with you, that from
a semantic perspective button is in the most cases the superior choice, but
there is a very good reason why OOUI and Termbox have simply a a-tag (just in
terms of non js-users to make the ui still working)
- the a-tag is not optional for Termbox - otherwise the SSR behavior is not
working as intended anymore. (See the edit button for that in Termbox when you
disable your js)
| IMHO, the better approach is to incrementally implement a reusable button
in bridge that follows the OOUI design correctly and for the use-cases where we
need it. That currently means the Publish button, later we will add the Cancel
button and likely more. This button component could be extracted into a
component library, when such a thing exists. |
|
I do not get this, because those buttons existing already in the
EventEmittingButton of Termbox (and more things). Why to get rid of them to
reimplement them and make then the library unusable for Termbox?
| Termbox can then reuse this button if they have a use for a button with
these OOUI styles. (That might be the case for the publish button, based on the
storybook). |
|
I guess, I pointed out why this not working with the current suggestion.
My suggestion for this: we can go with corrected EventEmttingButton of
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/532292/ or
we going all the way up to
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/531963/ . I
like to pitch the 2nd one of course (since it gives us much more button types)
but I can live actually with both.
TASK DETAIL
https://phabricator.wikimedia.org/T230326
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Matthias_Geisler_WMDE
Cc: Jakob_WMDE, Michael, Aklapper, Pablo-WMDE, Hook696, Daryl-TTMG,
RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, joker88john, DannyS712,
CucyNoiD, Nandana, NebulousIris, Gaboe420, Versusxo, Majesticalreaper22,
Giuliamocci, Adrian1985, Cpaulf30, Lahi, Gq86, Af420, Darkminds3113, Bsandipan,
Lordiis, GoranSMilovanovic, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden,
LawExplorer, WSH1906, Lewizho99, Maathavan, _jensen, rosalieper, Wikidata-bugs,
aude, Lydia_Pintscher, Mbch331
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
