Leading Design System and User-Interface Standardization efforts.
See also related tasks T290815: Bump basic and modern supported Android browsers to v5
Fri, Dec 3
Design members had an async conversation about TypeaheadSearch which led to T297025: Design TypeaheadSearch component for Codex.
Server settings related, such URL results also in fun: https://doc.wikimedia.org/codex/main/icons/
Storing this here for a moment.
Thu, Dec 2
It's the 5th item at T273785: Deal with release of npm 7. If you've got LibraryUpgrader active on your repo, it will always return to package-lock.json v1, no matter if you (on npm v7) have made dependency upgrades and locally have v2 that you'll commit.
Wed, Dec 1
Need to put video on GDrive as too big for Phab: https://drive.google.com/file/d/1IfOoQROUnaetLOzrbrLnd0GsDhiZyseO/view?usp=sharing
Can reproduce on latest Safari. Same issue like y'day sidebar link href points for example to /codex/main/components/text-input and Safari doesn't transform to /codex/main/components/text-input.html.
@AnneT Does it work for you on Safari? It seems Chrome is behaving differently than all other browsers here.
Hi all, I've just noticed this task for the first time (no surprise having all the focus and progress on Codex over last couple of weeks).
Late comments therefore: From a design system perspective the quiet progressive button with dropdown seems the preferable choice here.
The primary progressive button would be a wrong treatment as those buttons are aimed to signify the single, primary action in a view.
- The icon element uses SVGs fill=currentColor. With that it defaults to the wrapper HTML element's color style. And can be easily overwritten by a CSS class or even an inline style (not advised).
- The size setting is similarly easy with classes amending the min-width or width of the Codex Icon component when placed inline. See demo for an example of those inline Icons. The remaining question is if the icon should be specifically set-able or if a number of specific typography wrapper bound styles could be sufficient. Thinking of all block level elements direct icon component children here.
@Izno Several fair points. Acknowledge that the task description hasn't been outlined bullet-proof at point of writing due to time scarcity. Please note that IE9 and IE10 are though the biggest blockers from the to be updated list of basic support browsers. They have a 10+million pageviews base per day (equals ~0.05%), while for example all Android 4 comes down to 3.8 million including statistics outliers and earlier versions lower than 4.4.
They also got historically provided the largest amount of browser specific workarounds and code in MediaWiki core and beyond, with the biggest maintenance relief and performance impact in comparison to mentioned Android 4.4 or Firefox 27 to be removed from basic support (in a different task).
This will probably live in 'packages/vue-components/src/styles/mixins.less'
As we'll need to differentiate between theme and functional mixins.
Setting to “low” until component addition with usage for hidden text is requested.
To provide some extra context here on comment above,
- gzip is taking good care of such repetitive code blocks
- it could be considered to have a Less mixin call that outputs several callers in a combined selector
Tue, Nov 30
Not sure I completely follow the task description and the problem statement here with the outlined improvements? The ComboboxWidget comes in different variants of interaction currently. Only the “filtering on input” doesn't show all values when input is already provided.
Rephrasing for myself, even if there's a value selected, focussing the input field or clicking the dropdown button would show all available options again, correct? With the selected one highlighted? As soon as keyboard input is provided the options list is filtered again?
It would be helpful to have a before and after screenshot in the task description.
Mon, Nov 29
Behavior is just true for the user menu links and not for any other links. Not even if we're providing some sort of focus for the menu item clicked, I'd see a user benefit here. If you click Watchlist and another link on the Watchlist page and then go back twice, suddenly the user menu is still open. It's more confusing than anything else IMO.
This has been resolved successfully with the decisions in the Vue.js designer workshop and developer summit and follow-up at the Vue taskforce.
Codex is the (documentation, repository) shared toolkit and component library for Wikimedia (Foundation, Wikimedia Deutschland et al.).
Tue, Nov 23
Sat, Nov 20
Fri, Nov 19
Thu, Nov 18
Wed, Nov 17
When working on the tokens patch, I've discovered a detail I think would still lead to confusion regarding wikimedia-codex.json + wikimedia-legacy.json:
We have a design-/theme-agnostic library “Codex” that carries theme “wikimedia-codex.json' as one of it's themes.
That's why "Wikimedia UI" still makes sense to me and makes things more obvious.
Tue, Nov 16
- is reasonable, but out of scope and also questionable for end of this quarter.
Mon, Nov 15
Is it necessary to have either codex- or vue- presiding components?
Do we think we might have different implementations in the same repo? Isn't components sufficient for the directory?
#2 is a no-go for Design Systems approach from my current understanding, as it would disable combining tokens and icons into a different technical implementation – think for example Apps using only tokens or a React implementation of the Design System, where tokens and icons are essential.
In comparison, OOUI has come to these interaction elements:
We could make a quick patch release, it would currently only contain this patch. Would like to checkin with @Catrope first on the progress for https://gerrit.wikimedia.org/r/c/wvui/+/738470 as a combined patch release would be preferable. With such, it would be either end of the coming or second-next week until it's released and put into MW core to production use.
Sat, Nov 13
Sorry, that it came late. I had a memory flash about composition-api and WVUI this afternoon after reading your comments above and search immediately brought it up.
For one, this is great progress. Also I like the idea of changing to toggle switches, as long as the update is dynamic.
From a usability perspective it would make sense for the show and hide code to be either quiet toggle buttons (not yet part of Codex) or to stay as quiet buttons with an additional icon.
Hi @valerio.bozzolan, thanks for your feedback, and even if it's critical, I appreciate the honesty and the delivery. :)
I was waiting for @lucamauri to chime in and provide a final feedback. Aware that the lastly settled on is only related to the original proposals.
Fri, Nov 12
Updated Gerrit commit message guidelines with footer section.
Refined for unifying to docs: and tests: plural over singular for those changes.