User Details
- User Since
- Oct 8 2014, 8:32 PM (402 w, 4 d)
- Availability
- Available
- IRC Nick
- RoanKattouw
- LDAP User
- Catrope
- MediaWiki User
- Roan Kattouw (WMF) [ Global Accounts ]
Thu, Jun 16
That makes sense to me, let's go with #2
Should the ButtonGroup (1) create its child buttons itself based on a data object describing each button (like how Menu creates its child MenuItems), or (2) should its child buttons be created by the ButtonGroup's parent and passed into the default slot?
@bmartinezcalvo will add a link to the Figma spec sheet for the MVP once she has refined it.
Wed, Jun 15
Tue, Jun 14
Mon, Jun 13
@zeljkofilipin and I spoke about this on June 1st, and we agreed that we would create a proof of concept for Cypress component testing in Codex
The above would also address T310399: [Select] Entering a long default label extends the component's maxLength, which happens because we don't set a max-length on Select at all currently.
See T295506#8000560 for a proposal to fix a related issue that would also address this issue.
This happens because we have min-width: 280px on the dropdown, to prevent it from being too narrow. This causes it to grow outside of its box if the box is narrower than 280px.
Sat, Jun 11
Fri, Jun 10
You're right, I missed the fact that the transition was disabled completely, because of what Anne explains in her comment.
I've shared the Growth screenshot at T306025#7993774
Here's an example of a use case for ButtonGroup in GrowthExperiments. Note the groups of three buttons (1, 3, 7 and 1, 2, 6) under "Recent days" and "Recent months".
I think that might be because the font Firefox uses is slightly larger/wider? I feel like we see subtle differences like that with Firefox pretty often. @Volker_E probably knows more.
Thu, Jun 9
This seems to already be working on the test wiki for the current Vector patch:
Wed, Jun 8
One thing that I think we should clarify for ButtonGroup is what its function is. It could be:
- Purely stylistic: a way to display multiple buttons together in a way that looks good. This is what ButtonGroupWidget is in OOUI
- Similar to a group of radio buttons: allow the user to select only one of the buttons. The buttons would be ToggleButtons, and toggling one button "on" would cause the previously toggled-on button to be toggled "off". Code using this would be able to use v-model to read/write the value of the selected button. This is what ButtonSelectWidget is in OOUI (except that, in a ButtonSelectWidget, clicking an already toggled-on button doesn't toggle it off; this is more like a radio button and less like a ToggleButton).
- Similar to a group of checkboxes: allow the user to select multiple buttons. The buttons would be ToggleButtons, but toggling one button "on" wouldn't affect the state of the other buttons. Code using this would be able to use v-model to read/write the selected values as an array. This doesn't exist in OOUI.
We decided not to do this, and instead to migrate Vector from Vue 2 to Vue 3 and from WVUI to Codex in the same commit.
Tue, Jun 7
As part of making this change, I noticed that the hover transition looked a bit weird, and found that it was because the button appeared in 100ms but the border next to it appeared as part of the border color change transition which lasts 250ms. To make it look better, I slowed down the button appear transition to 250ms as well. But if that's not desirable, we could instead speed up the border transition to 100ms.
Mon, Jun 6
Can you name a specific browser that we support but that doesn't support RGBA hex notation? I ask because the way to stop the CSS minifier from outputting unsupported things looks like this:
// The es2015 build target doesn't include Safari 11-14, but we do support those // browsers. Including them here is important, because otherwise esbuild's CSS minifier // will output CSS that uses the 'inset:' property, which isn't supported in Safari 14 // and below. target: [ 'es2015', 'safari11' ],
Fri, Jun 3
This happens in all cases where there's only one item in a menu. Here's the same issue in the Lookup demo:
Why is this a blocker for T297025? I don't see how this bug affects TypeaheadSearch, because it requires opening the menu while an item is already selected, which is not possible in TypeaheadSearch (because selecting an item also navigates away to a different page).
This is de facto being done as part of T284838
I could not reproduce what Bárbara reported in Chrome, but I could in Firefox. @bmartinezcalvo were you testing in Firefox? Or in Safari?