Thank you @ovasileva! The TOC menu also has an interesting behavior (please see video below) where it not only appears without javascript when the user clicks the button in the toolbar, but it also moves to the sidebar when the viewport becomes a larger width and goes back to being under the toolbar when the user shrinks the viewport -- all without javascript. Is this a requirement for the article tools as well?

https://jumpshare.com/v/llsfg2L9VhdBQq0KbeQ5

@nray @Jdlrobson so the way the prototype currently works is: when both the TOC is pinned and the article tools menu is pinned, at 1200px the article tools menu is automatically collapsed, and then at 1000px the TOC is automatically collapsed. However what I realized the other week when talking to a community member at office hours: for people who have manually collapsed the TOC, they are going to want the article tools menu to remain pinned for as long as possible (let's say down to 1000px). Would it be possible to do something like that?

• if TOC + article tools menu are pinned, collapse tools at 1200px and TOC at 1000px
• if TOC is collapsed, don't collapse article tools until 1000px

@Jdlrobson @ovasileva discussed at offsite: we might want to hide the Move to sidebar button from logged-out people (i.e. that pin/hide functionality is only available if you're logged-in)

Change 842506 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] POC: Accessible pinned article tools in right sidebar

https://gerrit.wikimedia.org/r/842506

If the menu is pinned it should automatically collapse at 1200px (the same as the table of contents)

To note about this AC, if we want the ToC and article tools to share the same markup for the pinnable toggle (I assume we would), we probably want to consider doing T318178 and T320451, as they both touch the ToC pinnable toggle and label

Change 844527 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] POC: Generic pinning JS and styles

https://gerrit.wikimedia.org/r/844527

The pinning mechanism should share the same code as the table of contents so this task should be used to generalize that work.

@Jdlrobson I started doing some exploratory work here and I think this AC is quite large on it's own. Would it be possible to pull this into it's own task, as it involves refactoring the TOC code including JS, cached HTML and CSS changes. Even with the feature flag there's a good amount of complexity here.

POC here: https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/844527

Change 845059 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Update TOC to use PinnableHeader, update 'collapsed' naming convention to 'pinned'

https://gerrit.wikimedia.org/r/845059

Change 845062 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] POC: Make more menu pinnable

https://gerrit.wikimedia.org/r/845062

(documenting a design decision — prototype & task description have been updated)

originally, in order to avoid a situation where the content is too squished between the TOC and the page tools menu, I thought it would be good to automatically collapse the page tools menu at 1200px:

above 1200px	1200–1000px	below 1000px

however, after thinking a bit more about this, since the pin-able page tools menu is a power user feature (and we know that some power users use narrow/side-by-side windows), I think it would be best to give as much control as possible to the user. this allows them to achieve more configurations; for example, at 1100px the user can choose to have:

TOC + tools pinned	TOC pinned	tools pinned	neither pinned

in the future we could even consider not automatically collapsing the page tools menu at all, and leaving that completely up to the user. that would allow people to get this kind of layout, for example (cc @AntiCompositeNumber @Quiddity):

Change 842506 abandoned by Bernard Wang:

[mediawiki/skins/Vector@master] POC: Accessible pinned article tools in right sidebar

Reason:

https://gerrit.wikimedia.org/r/842506

In T317897#8335679, @alexhollender_WMF wrote:

(documenting a design decision — prototype & task description have been updated)

originally, in order to avoid a situation where the content is too squished between the TOC and the article tools menu, I thought it would be good to automatically collapse the article tools menu at 1200px:

above 1200px	1200–1000px	below 1000px

however, after thinking a bit more about this, since the pin-able article tools menu is a power user feature (and we know that some power users use narrow/side-by-side windows), I think it would be best to give as much control as possible to the user. this allows them to achieve more configurations; for example, at 1100px the user can choose to have:

TOC + tools pinned	TOC pinned	tools pinned	neither pinned

in the future we could even consider not automatically collapsing the article tools menu at all, and leaving that completely up to the user. that would allow people to get this kind of layout, for example (cc @AntiCompositeNumber @Quiddity):

So is automatically collapsing the article tools menu not part of this task then?

So is automatically collapsing the article tools menu not part of this task then?

Collapsing is not in scope for this ticket. The purpose is to understand what it would take to generalize the table of contents pin functionality. That will be handled in T318168.

following up on my comment above (T317897#8335679), and @bwang's question: we've decided that we won't automatically collapse the page tools menu at all...we'll give full control over to the person using the interface

For logged-out users, the "pin to sidebar" button will not appear (will not be pinnable)
For logged-in users, the menu will be pinned by default

I chatted with @nray about this today, and I believe we cant meet these two AC until T319349 at the minimum, and ideally after T320927. Specifically we cant yet have the page tools menu pinned by default

@ovasileva Based off our convo from task sync yesterday, should we create a new task for automatically unpinning page tools when it reaches a certain viewport? Or are we still going with not auto unpinning per @alexhollender_WMF's comment above?

I updated this ticket to remove the default rendering requirements (whether the menu is in the dropdown vs. end column) as that has now been split off into T322051

Change 844527 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add generic PinnableHeader template, CSS & JS

https://gerrit.wikimedia.org/r/844527

Due to caching concerns, https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/845059 can only be merged Tuesday at earliest.

Change 853404 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] [Technical] Add DropdownContents.mustache

https://gerrit.wikimedia.org/r/853404

Change 853404 merged by jenkins-bot:

[mediawiki/skins/Vector@master] [Technical] Add DropdownContents.mustache

https://gerrit.wikimedia.org/r/853404

Change 854584 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/skins/Vector@master] Replace 'more' menu with page tools pinnable dropdown

https://gerrit.wikimedia.org/r/854584

Change 845062 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Add ColumnEnd.mustache and new grid styles to support third column

https://gerrit.wikimedia.org/r/845062

Change 854584 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Replace 'more' menu with page tools pinnable dropdown

https://gerrit.wikimedia.org/r/854584

Change 845059 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Update TOC to use PinnableHeader

https://gerrit.wikimedia.org/r/845059

@Edtadros I've updated the description to have QA steps, I basically just moved most of the TODOs into QA, as they seem valid as testing steps to me.

• The more menu if empty is not shown

@ovasileva One thing to note, this step is not yet complete. I'd recommend this step to be capture in a different ticket, I think it would make the most sense in T320927. Doing it alongside T320927 would simplify things a good bit and allow us to avoid writing code for this multiple times.

Change 859076 had a related patch set uploaded (by Jdlrobson; author: Bernard Wang):

[mediawiki/skins/Vector@wmf/1.40.0-wmf.10] Update TOC to use PinnableHeader

https://gerrit.wikimedia.org/r/859076

Change 859076 merged by jenkins-bot:

[mediawiki/skins/Vector@wmf/1.40.0-wmf.10] Update TOC to use PinnableHeader

https://gerrit.wikimedia.org/r/859076

Mentioned in SAL (#wikimedia-operations) [2022-11-22T21:52:03Z] <samtar@deploy1002> Started scap: Backport for [[gerrit:859076|Update TOC to use PinnableHeader (T317897)]]

Mentioned in SAL (#wikimedia-operations) [2022-11-22T21:52:24Z] <samtar@deploy1002> samtar and jdlrobson: Backport for [[gerrit:859076|Update TOC to use PinnableHeader (T317897)]] synced to the testservers: mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug2001.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-11-22T21:58:15Z] <samtar@deploy1002> Finished scap: Backport for [[gerrit:859076|Update TOC to use PinnableHeader (T317897)]] (duration: 06m 11s)

In T317897#8403121, @bwang wrote:

@Edtadros I've updated the description to have QA steps, I basically just moved most of the TODOs into QA, as they seem valid as testing steps to me.

• The more menu if empty is not shown

@ovasileva One thing to note, this step is not yet complete. I'd recommend this step to be capture in a different ticket, I think it would make the most sense in T320927. Doing it alongside T320927 would simplify things a good bit and allow us to avoid writing code for this multiple times.

Added to AC in T320927: Create Dropdown and Menu Skin component classes

@Edtadros Those all look like a pass to me, thanks for the videos!

This all looks good to me. Noting that this didn't go through design review. @alexhollender_WMF, @Jdlrobson - do we want to do this as a separate task for the whole feature, or review and make fixes as we go?

Talked about this in kick off meeting. I think it would make sense to do a design review / fix up patch after we've got the technical parts in place. We can perhaps switch focus to design as soon as this is ready to be enabled on the beta cluster.