Although this task sets out to actually try and build a new "throwaway" header, I've identified some ground-work that has to happen before we can even begin building a new header:

I'm unable to reproduce on Chrome on Windows, but we have gotten reports of this issue sporadically.
Currently I'm seeing a disappearing icon on Mac Safari on the Wikimedia beta cluster. https://en.m.wikipedia.beta.wmflabs.org/wiki/TemplateUsageArticle392#
I also noticed this issue when using the VoiceOver screen-reader on iOS, in which icons disappear after the focus has been placed on them.

Hope that does it.

Since this is only a linting change and only adds comments, I figured it's ok to skip QA.

@Quiddity mentioned that the prototype doesn't do a good job of loading certain language specific templates, such as the French Wikipedia's infoboxes

@SpookyGhost8 what browser/OS is this occurring on?

We also had a conversation about DOM order during our offsite in regards to accessibility. My intuition says that rendering the content first, as Vector currently does, makes life easier for screen-readers & assistive tech, since they don't have to skip through the navigation to get to the content.

Currently in the Vector skin, the header HTML, (along with the sidebar & other navigation) are placed below the content. (The header is made to look like it is above the content with CSS).
My understanding is that this was done for performance purposes - so that page content loads first, as well as for accessibility reasons - so that page content is the first thing presented to screen-readers.

I tried to update the peer dependencies, but this led to the following error when building a binary with node-gyp :/ so I think a revert is in order here.

Since there's already a patch up for this task (thank you @Jdlrobson!) I think this can be estimated and moved to the code-review column.

Looks like this task has been thoroughly analyzed and followup conversations are planned, so this task can be resolved. Looking forward to the Modern Event Platform!

As this just affects print styles, I didn't see the harm in merging the proposed patch. Moving to design review in case @alexhollender has any comments on this. (Merged patch should be visible on the beta cluster).

@Jdlrobson yes that issue was addressed just after the branch cut last week, so it should appear solved soon.

As @Jdlrobson mentioned earlier, the Web Team intended to make a decision on this by October 31 🎃.
I've updated the task description with our decision under the heading "RFC Outcome". Instead of forking Vector as originally proposed, we will be implementing the Desktop Improvements project inside Vector. Every option has it's trade-offs, and after considering the points made in this discussion, we felt that working in Vector was the most pragmatic way forward.
Thanks to everyone who contributed to this discussion!

@Bawolff thanks for your comment. I agree that in an ideal world, a new skin would be the most sensible option. However, given the state of the skinning system, extension compatibility, gadget compatibility, community buy-in, etc. I don't think the ecosystem is in a state where an additional skin is maintainable. As you mention, the "current experience maintained in parallel" line in Proposal 2 recognizes that realistically, we can't get rid of the current Vector "experience" anytime soon.

I made one followup patch to fix an issue in non-amc mode with the labels.

A couple of weeks ago @santhosh reached out to me to show his side-project https://wikivue.netlify.com
(source code at https://gitlab.com/santhoshtr/wikivue/tree/master/src)

we (the Reader’s Web team) have been giving a lot more thought to the new-skin & update-vector proposals recently.

Thanks for confirming @EBernhardson, one of the key learning from this task is that if we're to change the search experience on desktop as part of the Desktop Refresh project, we should consult the Search Platform team beforehand because changes to the UI can impact your key metrics, that and any new UI should maintain compatibility with the SearchSatisfaction schema.

If our statsv client is producing request urls with multiple query strings, that's a bug indeed.

Thank you @Jdlrobson and @Isarra for the additional proposal of starting a new skin from scratch (and everyone who’s chimed in so far). During previous conversations with the web team, the option of a brand new skin was disregarded off-hand as being impractical. However, when considering the startup cost of fixing Vector vs. Building a Vector-like skin from scratch, I can see how the two might be comparable (having never written a skin myself though, it’s hard for me to judge).

Also, please thing about different languages. English looks really nice, but I'm afraid that in other languages those labels can be pretty long. For example in Polish language "unwatch" would become "przestań obserwować" or "usuń z obserwowanych".

@Jdlrobson , @phuedx thank you for further investigating the instrumentation aspects! I added some more details to the instrumentation section in the document.

HI all, so tldr;

I think adding a min-width/min-height to .mw-ui-icon:before can fix this.

I've tried debugging this issue and I was able to locate an affected page (GW501516 in my case) and inspect it from my iPhone using the Safari inspector.

after syncing with Jon, realized we can align this be removing the .flush-top and adding 10px top-padding to the container instead of 20px

@alexhollender @Volker_E Sorry I didn't get back on that, but yeah I think some of the negative margins used to position the icon flush-right and flush-top, combined with fact the icons don't go edge to edge make it look a bit weird, but I don't see an easy fix here :/

@Jdlrobson thank you! 🙏

The patch above aligns the header as such that the "x" is in the corner, inside the padding and the word "citation" is vertically middle-aligned with the bookmark icon. The bookmark icon however, isn't perfectly aligned with the edge of the padding because the SVG doesn't touch the edges of its canvas.

@Jdlrobson that seems fixable, will do!

There's a minor style issue with the top portion of the page where the description and "edit your list of watched pages" button is.

We've tried enabling this change on the beta cluster, but for unknown reasons it doesn't appear to work there (works locally :/). This requires further investigation, the fault might be with the beta cluster or with the change itself.

This has been on production fro a couple of weeks with no issue, so I 'm signing it off.

That's a screenshot from the deletion log page. @Zoranzoki21 , the recent changes does look wrong. (sorry but it's easier for me to spot the problem on enwiki)
I think this summarizes it:

@Zoranzoki21 is this the correct order of the words?
(summary) is deleted page (name of page).

@Zoranzoki21 I' trying to understand what the problem is. Is it

1. that the summary is not aligned with the rest of the text, like in this screenshot: