Let's make the full toolbar VE/OOUI like. Design team designed it to work with accessibility and usability focus. There's even a patch out by @Esanders in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikiEditor/+/509882/

I'd add to above comment, that the hamburger menu is not a universal solution on phones either. It was seen as simple answer from some designers to a complex problem. But research since then has repeatedly shown that it doesn't fully work universally (without additional label).

Like I've shared in T232003#5465798 it's not uncommon to have nothing in the format toolgroup and the dropdown indicator would be the only thing?
I feel putting a border to the right of undo/redo to separate the whitespace there and possible one at the end seems more like a „clean“ (how do we settle on what's clean? ;) ) version that is clearer to users…

HTMLForm now uses OOUI and features standard OOUI tooltip design.

IE7 is not of our interest any more. Declining this from Product point of view. https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

After another 3.5 years without any traction, let's close this.
Desktop Improvements is the project space where related questions are best-funneled into.

@matmarex Would you share a screenshot with \2022 alternative as well?
With all bullets, it always comes down to the specific font, and as we're not using a web font, we will have to deal with variations when not relying on an image.

From task description, I'm not sure anymore, if our components don't have all the use cases covered. Color palette seems covered now.
Most open questions are around a tab-like interface, not a certain color emphasis.
If something should be a button versus a normal link, that's an issue with the editors trying to put too much visual emphasis on too many elements of the page, not sure how much we can cover this as technical solution versus trying to clarify user-interface design and patterns.

Was also able to reduce image size by about 15kb.

Fixed in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/325/ – already merged, caching seems to still be in the way.

@Jdlrobson The merged-in task was caring about enhancing menu item's hover while current task is about selected and :active state as is.

@Jdrewniak @Jdlrobson Time to merge in with T225213?! :)

@Jdlrobson What about the child tasks in reach/out of reach?

• T169828
• T171114
• T171330
• T171023

Will monitor if this is the successful…

For future generations and myself later: https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/324
So the basic issue doesn't seem externalizing the code, but adding it in the right loading order (also only deferring/asyncing the right pieces of it. The normal analytics code adds itself into the document as script underneath the embedded code. In our setup it was inserted before the calling script.

@alexhollender While we're on this, let's please also care about the wrong opacity on disabled elements:

Looks and works like a charme now. Storybook for the win.

We don't do uneven px distances in our interfaces, but try to orient on an 8px base (4px is ok, 6px should be the absolute exception).
Therefore 8px looks like a viable candidate for the side hamburger-initiiated menu.

@alexhollender and myself have agreed, that 500 would be useful for now, but the whole interaction element group needs to be revisited to be improved later.

Re-citing @srodlund from IRC conversation:

Components is right because it is a list of components (more than one) and for the separate components as in buttons, because there are multiple buttons.
Singular would be possible, but wouldn't be any more"correct" or lend to more clarity. It's not worth the effort.

@Samwilson In my opinion, OOUI DateInputWidget and a normal text inputs for time and timezone (without jQuery UI?) would be the best option as we want to get rid of jQuery UI asap in MW core.

fyi, I've updated T91148. tl;dr: From user-experience perspective it's preferable to have separate date and time inputs and not one DateTimeInput widget. It's overly complex for users and the mid-term plan is to deprecate it in core.

Current routing doesn't take adding safemode=1 into account. But only user script https://en.wikipedia.org/wiki/User:Volker_E._(WMF)/dark-mode.js seems to actually be the source of the issues without clear cause.

In T240390#5730145, @Volker_E wrote:

Currently waiting for Twitter support to get back about a profile verification step.

https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/317 for DSG

After revisiting the two widgets in several contexts, I think the DateTimeInputWidget is only usefully crafted for one special use case, APISandbox. It fulfills the needs there, but is generally too complex on a user experience and component level.
It seems more performant, less complex and also general better approach to have two different components, a DateInputWidget and a TimeInputWidget for those two tasks. No other web framework is providing a combination for the complexity of mixed inputs, Boostrap has none, Material Design only Date picker.

This is ready to be reviewed @Pginer-WMF…

@alexhollender Not fully convinced if the tabs need more boldness, we have already the article headline, the “article” and “talk” link boldened. My first reaction is, do all the interaction elements be bold? There's some kind of imbalance between those three groups of elements, boldening should be the last resort IMO.
Content is king.

As my assumptions seem to have been backed by shared user research, single-underline inputs are confusing to a number of users:

• https://medium.com/google-design/the-evolution-of-material-designs-text-fields-603688b3fe03

And further on label position

• https://twitter.com/lukew/status/872845844965240835

Resolved as much as this ancient collection is able to be resolved.

So in order to make this really useful, it should be a label element with a for attr in order for screen reader users to be clearly connected to the element.
See for example https://doc.wikimedia.org/oojs-ui/master/demos/?page=layouts&theme=wikimediaui&direction=ltr&platform=desktop#FieldLayout-aligned-top-with-inlined-help

Adding on to discussions above, (re-)defining DOM structure is carved out into T240489.

@Krinkle Does above fully answer your question in T237636#5699004? My guess from reading T231168 is that you'd see the logo as part of first 14kb, not all of #mw-panel…

If we think about Vector in MW outside of only Wikipedia, there are two navigation structures that seem reasonable to me:

1. logo/site identifier (“Wikipedia”)
2. tagline that is skipped on subsequent pages (“The free Encyclopedia”)
3. Skip links (to define if nav (which is personal nav here), content and search)
4. content
5. content links (“edit“, “talk”, “language”(?), “categories”(?!?)…)
6. personal navigation
7. sidebar navigation
8. footer

Current “skip to navigation” link is weird in the sense, that it brings you to the personal navigation. The portal links in the sidebar come after content and after personal links and article actions.

#page-actions .mw-show-on-map seems to sit in a gadget? @TheDJ?

More systematic question funnelled into T240514: Define and add another Base color between Base10 and Base20?

#717171 results from relying on opacity to simplify hover interactions. WikimediaUI Base defines @opacity-base--disabled: 0.51 for this to result in #7d7d7d, closest to #72777d. In future, T198770 might be the perfect way out, for now, opacity seems to result in closest feasible compromise.

That slipped in at 3c55b23d6171871e5ee42d4105f04e30df08263d for no stated reason…?! @Jdrewniak knows maybe more. #4a4f53 is actually exactly passing triple AAA with #eaecf0 at 7:1.
We could consider this for the header and other elements on Base80, but that should be done systematically. In OOUI we use #444 as modifier color in some places (as hover modifiers) so there could be space for consolidation here.

@alistair3149 https://gerrit.wikimedia.org/g/wikimedia/portals/+/refs/heads/master it is.

@Pginer-WMF Yes, this is connected as in a direct result of T220671: Replace `em` based sizing in favor of `px` based where applicable as the line-height in ems together with the top&bottom pixel values of buttons result in a lower than necessary box to fill the button box.
This could be addressed by

.oo-ui-buttonElement.oo-ui-labelElement > input.oo-ui-buttonElement-button, 
.oo-ui-buttonElement.oo-ui-labelElement > .oo-ui-buttonElement-button > .oo-ui-labelElement-label {
    line-height: 1.375em; // Equals to 22px 
}

Reason is difference in base font difference in UI of 14px and 16px and we thought to accommodate both worlds best possibly.

This very-well stated question seems to me better having user research and Design involved before any implementation. Not Front-end-Standards-Group at this moment…?!

Currently waiting for Twitter support to get back about a profile verification step.

@ovasileva Yes, indeed.

In short: We should fix the loading, not hide the loading.

Patch provided at https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/316. Also clarifying language a lil better and resolving an error in a sentence.

With above, I close this task as successfully “resolved”.

@schoenbaechler Singular vs plural is an interesting question. Guess it came out of a) using plurals for many fo the “Visual Style” subsections and b) because “Buttons” stand for various types of buttons? But I'm open for majority vote here, will put this into a task of its own though. Captured in T239971.
Search goes alongside a non-static website, which was once started in T164449, but ran into technical cost-benefit issues. It's currently not possible and we have to rely on our SEO being so good, that we can lean back and let “Wikimedia UI dropdown” be googled for us.