Leading Design Systems and UI Standardization efforts.
Fri, Jul 3
@Demian From the [[ URL | patch demo ]] linked by you above in latest Chrome/macOS:
Same is true for Firefox.
Thu, Jul 2
@Jdlrobson No, that's far too risky with our plethora of interfaces – special pages, gadgets other user generated content.
Wed, Jul 1
Resolved in https://github.com/wikimedia/wvui/pull/34
Additional screen from demo to show the expected mid-term outcome (as long as personal menu isn't in place):
Sharing here instead of T256373, with patch https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/585629 in:
Any slotted content is risky to me, we don't want a button that can carry an iframe to make the most extreme example.
What do we expect for a button to contain. Nothing interactive, nothing block.
We'll also need to update VE ('s toolbar) to make up for the toolbar not leaning against a border any more…
Tue, Jun 30
Figma's Storybook integration needs to be in our focus as well, this could be very powerful for upcoming WVUI work.
There truly are. In Product we adhere to WCAG 2.0/2.1 level AA as baseline.
Putting aside some thoughts about ideation and contributions to that task (see description history and patch set history), repeating, what means "give credit", what is the expectation here?
Mon, Jun 29
@Legoktm Thanks for the pointer, vaguely remembering reading through the comments in 2014-15:
There were two different questions discussed:
- Do normalize style rules belong into core
- Does normalize as external component suffice core's requirements to be added as library
Could one expand: “The most performant byte sizes and rendering. This derisks a major concern for the project as much as possible.” What risk do we have when relying on RL? How big is it, where are the byte size comparisons for this? Is this a known shortcoming? Asking as this should be flagged elsewhere (MediaWiki-ResourceLoader) if it hasn't already been.
Sat, Jun 27
Fri, Jun 26
@Iniquity I agree with you, but bumping up the font-size would be a too-narrow solution, as those buttons have all kinds of issues, including not following any Style Guide any more, nor any of our interface guidelines. But given that MediaWiki community is a different one than Wikimedia, it would need an agreement from a lot of stakeholders to move this forward and this task would need to have widened its scope or be part of a larger task addressing above.
@Demian Please don't reassign tasks and don't add to resolved tasks. That's an anti-pattern! And with “please” I mean don't do this. It makes them really hard to set into specifc timely context and leads to unnecessary confusion. If there's additional work needed we can always open another similar one and link to the original.
Flexbox doesn't seem acceptable to me from current browser support matrix.
Even in IE 11 the support is more than wonky. IE 9 & 10 would be put into graceful degradation position instead of solid support or progressive enhancement, which is our preferred approach with CSS.
@Nikki This tab navigation is workable with arrow keys. This is mentioned in the ARIA Authoring Practices for Tabs in keyboard navigation as desired behavior.
With no further arguments in, I'll declare this “invalid”.
Thu, Jun 25
Adding some notes: The sectioning element header now features label and sidebar navigation mw-sidebar before the sectioning header, which should be the logo. This is currently necessary to achieve a logical tab order. But we should keep this on the radar if there is a solution around this having logo first and then tabbable sidebar button connected to sidebar contents.
From the task description, there seems to be a misunderstanding in what *-system-sans refers to resulting in a misdirected request for consistency:
@font-family-serif -> @font-family-system-serif @font-family-monospace -> @font-family-system-monospace
serif in font-family-serif refers to the generic font family, that is chosen by the web browser and writable by the user. Some browser rely on so called web fonts that are system-independent for historic reasons, like Arial or Times/Times New Roman.
*system-sans refers to specifically chosen font stack of Operating System sans serif fonts that are stacked up so a user in a browser on each of the major (more specifically mobile) operating systems should see the site first in its system sans serif font, not a generic one.
Therefore renaming @font-family-monospace to @font-family-system-monospace is misleading!
@Niedzielski Please expand on ”Component can wrap any slotted content.“ What functionality do you have in mind?
@Demian We need to toggle a dynamic -active class for the button additionally to the keyboard treatment. Currently it's not completely off without through the button icon change, but it's also not very friendly UX.
Have shared on patches, will repeat here: From my perspective, custom scrollbars are a no-go. In contrast to everything within the canvas, scrollbars belong to the operating system and shouldn't be customized in wide-ranging project with most diverse audiences like ours ever.
It's a nice proof-of-concept, but we would sign up for a) confusion for average users seeing the otherwise rarely customized scrollbars and b) even the browser support is so low that it ends up as a customization that only shows up for users in one browser and as soon as they change device they need to re-orient themselves with something essential like a scrollbar.
Wed, Jun 24
Thanks @Bkudiess-msft! :)
@Jdforrester-WMF Yes, OOUI v0.39.2 – upcoming.
Tue, Jun 23
Putting on low, as there doesn't seem to be agreement by core maintainers on how and what way to proceed and given the refocus of resources, it doesn't seem appropriate to leave this as 'high'.
@Bkudiess-msft If you write "Bug: Task number", here "Bug: T253406" in the line before change id, Phabricator task will be automatically notified of the patch. Then you don't need to ping @Aklapper with the patch manually. I'll update the patch for your future reference. :)
My open questions in T253598#6193715 remain, the approach of preferring proprietary high contrast mode over any other mode and environment isn't sufficient for our scope and reach. If we can't address high contrast mode focus differently (and without a lot of extra code), taking away custom focus behavior will not be merged at current understanding.
Wed, Jun 17
Thanks @Iniquity for the proposal. It would be helpful to have this comparison also for a mobile canvas (375px).
@Krinkle Given that the release cut branch for REL1_35 is around the corner (July 13th), it seems preferable to wait for the final go until then to me.
Tue, Jun 16
@Bkudiess-msft Is this role=option behaviour applying to Narrator only? Or across products?
Thanks for taking care of it, @MusikAnimal!
I'd think in certain processes a simpler handover to development could be also a benefit. What Zeplin tried to cover.
The modifier colors have been added to WikimediaUI components overview in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/378
Hi @Abhir-24, thanks for reaching out. Have you already read through https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and made yourself comfortable with our environments?
I'd prefer an OOUI release tomorrow.
Mon, Jun 15
Repeating from patch set, @Bkudiess-msft please expand a bit more on the role parent > child relationship and what is missing, what would be gained and how to tailor this to the general library and Tool applications.
With that patch we would change <a> to role=option and this is not allowed for <a> elements. Was too quick in my comment on patch with contradiction of <a> and role="option". It's actually allowed, which preceeded ARIA 1.1 and were now allowed. Though we might have tools not carrying <a> as element.
See for example VisualEditor's use of tools in the toolbar. https://en.wikipedia.org/wiki/Front_end?veaction=edit