Also see T166055: Sunset Skin:Blueprint

From the description:

• All links should provide textual content:
  • a.navbar-brand &
  • <a href="//commons.wikimedia.org/wiki/File:Nadine_Gordimer_01.JPG"> both don't

From the description:

• <span class="blackout"> should be attributed with aria-hidden to provide similar treatement to screenreader users

Hey @prakamya do you have a working Mediawiki installation (its pretty easy to setup with Vagrant) with MultimediaViewer?

Is this in parallel to T156874: The constructive flag in the OOUI Apex theme should be deprecated in favor of the progressive flag?

In response to T172834: Tool "styleguide" redirects to GitHub without consent, I have removed the redirect, and added a notice instead.

This would be my fault from T154703: Remove old MediaWiki UI tool labs instance, http://tools.wmflabs.org/styleguide/, sorry! I have removed the redirect now and added a notice instead.

I had two general queries about the methodology.

Summarizing some of the things discussed with @dchen during the Editing design meeting. We need to test the visual diffs in two scenarios. It seems that it might be easier to test them on the history page than on the "preview changes" step of visual editor. It might be a good idea to use the history page use-case for the pilot test because...

@MarcoAurelio I am not able to see any redlinks. Could you please add a screenshot, and possibly raise a separate task?

…instead of links? Is this Accessibility related?

Not sure which screaming you're referring to

We use lodash?

In T170235#3469886, @Esanders wrote:

So, the issue to be filed is that when Moving and reordering the References list isn't being updated?

Yeah, pinging @Tchanders

In T170235#3468454, @Esanders wrote:

The reference list itself does not currently detect moves which is the issue in all three of your examples

In T169325#3467368, @Tchanders wrote:

I'm not sure the moved content should be shown twice in its entirety - it could make the diff quite complicated in cases where multiple paragraphs or whole sections are moved, or where multiple moves are made...

@Volker_E These changes are a definite improvement. Will you be adding a patch for the focus state of frameless buttons too?

@matmarex How do we want to implement this? Should we add multiple FieldLayouts in CheckboxMultiselectWidget or just add frameless PopupButtonWidgets?

If I understand this correctly, each new field in an HTMLForm creates as HTMLFormField which uses a FieldLayout. A FieldLayout is the only element that allows a help attribute that shows up as as icon with a popup. The HTMLMultiselect uses a CheckboxMultiselectInputWidget which uses a single FieldLayout to wrap the label and the checkboxes, and so the help attribute can only take a string, not an array.

In T150079#3466163, @Huji wrote:

Yes. It is already linked above: T168724

There are three types of reference moving that I can come up with.

In T170235#3448693, @Esanders wrote:

Just to be clear, this behaviour should not be happening and should go away once T170269 is fixed.

In T171332#3465431, @matmarex wrote:

Thanks for the detailed bug report!

In T169325#3421408, @Esanders wrote:

• Requires extensive i18n work, probably multiple messages per annotation (and there are quite a few annotations + plus extensions could add annotations)

In T169325#3424197, @Pginer-WMF wrote:

…I updated the mockup in the description with one possible approach…

@Volker_E Yep, its on my list. Got distracted with other tasks!

In T150079#3464428, @Huji wrote:

… the current "tooltips" to be somehow displayed in the new layout, but HTMLMultiSelect does not support any tooltips, so we need to add that feature upstream in OOjs-UI first…

Is there a phab task for this? Could you please create/link to it?

2: Select "Sort by creation date" [creationSort=1]

...

URL: https://meta.wikimedia.org/w/index.php?title=Special%3AGlobalUsers&username=&group=&creationSort=1&limit=500

I guess this is happening because we're using a multiselect field…

Caused by rMW283ee7238b7f: Special:ListUsers: Use HTMLForm and OOUI T111999: Convert Special:ListUsers autocompletion to use OOUI (Widget or HTMLForm)

Borrowing the yellow from T169325, and the icons from T170134 we could:

In T170134#3422388, @Tchanders wrote:

This is a bit more complicated than it looks - we don't have a way yet of describing changes for a newly inserted/deleted node - only changes to an existing node. We should think about other cases that this would apply to (e.g. invisible templates) and come up with a general solution.

E.g. in how much detail do we describe the inserted/removed item? Do we just show the green/red highlight in the document, or a bit more, e.g. to indicate that it's a comment? Or if we show too much in the document are we wandering into editing rather than reading territory? Or should we have some generic icon for an invisible item?

See also T170804: CheckboxMultiselectWidget should have an option to use a HorizontalLayout.

In T111117#3445653, @Volker_E wrote:

This has been established as a task combining mixed topics on different products. We've been successfully tackling the technical parts of it, testing and documentation don't need this as umbrella task any further.

In T170275#3444097, @Jdforrester-WMF wrote:

Looks like we've done all of them? Mark as Resolved?

In T114975#1718609, @matmarex wrote:

Note that modern versions of both Chrome and Firefox (but not Internet Explorer) apply :hover styling of <input> elements also when their associated <label> is hovered by the user, which magically supports the biggest recommendation of the article you linked.

Thanks for the report @gabriel-wmde. The documentation was being (correctly) inherited from OO.ui.InputWidget but we forgot to implement it.

@Jdforrester-WMF Just to be clear, this would mean that when I add an item it gets added to a location in the list which is pre-decided, not necessarily the end? Something like:

Yes, functionality that is used more often should be easier to access. I couldn't find any information on why the menu items are ordered the way they currently are, links? Also do we have any data on which of these items are used most often, or do we just infer it by looking at the content on the pages?

In T170156#3436415, @Pginer-WMF wrote:

I used a placeholder icon trying to pick from the existing ones in the repo, but we still need to come with a good icon to represent the "new feature" concept. There are many possible options but not a clear winer yet (we used to have a circle with a kind of burst inside that was removed from the repo, a rocket was considered at some point, a gift box is also used by some products...).

In T169325#3425945, @Lea_WMDE wrote:

In T169325#3424197, @Pginer-WMF wrote:

One minor issue with the move as you have it designed, is that part of the point of the move feature is that we can show changes within a moved paragraph (a big improvement on the current differ), so painting the whole thing green wouldn't work.

FYI: WMDE's technical wishes team is in the final stages of implementing just this in the current differ (i.e.wikidiff2): T139603: Show text changes when moving text chunks (#2)

In T166012#3426653, @kaldari wrote:

@Prtksxna: Where is the repo for the living style guide? I couldn't find anything in https://github.com/wikimedia/ besides https://github.com/wikimedia/WikimediaUI-Style-Guide, which is a different guide.

Do report the results either way. Documenting screen reader quirks is important.

In T117794#3424619, @Volker_E wrote:

I agree, I don't think it's necessary here as long as it's always those five possible options.

A part of the UI is slightly tricky, when you select two revisions you get a table of radios.

I have added a deprecation notice, and I think that should suffice.

Added the PDF - https://www.mediawiki.org/w/index.php?title=Design&type=revision&diff=2511181&oldid=2510774
@kaldari Could you please add appropriate categories to it https://commons.wikimedia.org/wiki/File:Livingstyleguide.pdf

How is this going to translate on mobile?

#p-search has an <h3> with a <label> of Search, this isn't hidden but is clip: rect'd, so its accessible.