Michael added a comment.
In T230326#5475526 <https://phabricator.wikimedia.org/T230326#5475526>, @Pablo-WMDE wrote: > Hanna however was kind enough to point a key difference between the "primaryprogressive" button as used in termbox and the one we can observe in the bridge spec and the related OOUI demo for "process dialog <https://doc.wikimedia.org/oojs-ui/master/demos/?page=dialogs&theme=wikimediaui&direction=ltr&platform=desktop#demo-section-dialog>": the "primaryprogressive" itself exhibits rounded corners (`border-radius: 2px`) but these are removed <https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/src/themes/wikimediaui/windows.less;06af8554a827416bfba64974ca63a86bfe30fa6c$148> from the element when used as a part of a header ("processDialog actionWidget" in OOUI terminology) as intended in bridge. > We now have clarity on the requirements' side but face a bit of a technological challenge. OOUI implements this by implementing a selector specific to this case (button inside dialog). For our vue components we, so far, followed the BEM approach <https://gerrit.wikimedia.org/r/plugins/gitiles/wikibase/termbox/+/f3ad6c7606e09524bc9e8b8f60364655743f235e/docs/styles.md> and the component's appearance are organized in so-called modifications ("primaryprogressive" is an example of this) and we usually refrain from influencing these modifications' styles from the outside but rather create a new component modification. Parents typically call for one concrete modification of a component. So how do we tackle this? This is relevant for the story overall, though unrelated to the different considerations underlying the two approaches discussed above. It seems to me that this modification, while affecting the button, is conceptually more part of the header component. While we could add a configuration option for the styling of each corner to the button, I'm not sure that adding the overhead of this interface is worth it, especially since this would amount to the parent writing direct CSS into the child. In this case, I find it to be more simple and honest to leave this just to the parent component's CSS and to utilize the cascade there. I found some discussion <https://en.bem.info/forum/63/> about this issue, but nothing authoritative. There seems to also be the approach of adding an extra class <https://medium.com/fed-or-dead/battling-bem-5-common-problems-and-how-to-avoid-them-5bbd23dee319#8e52>, but I'm not sure that this approach works with our setup. TASK DETAIL https://phabricator.wikimedia.org/T230326 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Matthias_Geisler_WMDE, Michael Cc: alaa_wmde, Hanna_Petruschat_WMDE, Lucas_Werkmeister_WMDE, Lydia_Pintscher, Charlie_WMDE, Jakob_WMDE, Michael, Aklapper, Pablo-WMDE, Hook696, Daryl-TTMG, RomaAmorRoma, 0010318400, E.S.A-Sheild, darthmon_wmde, Meekrab2012, 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, B20180, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
