This task hasn't seen much movement recently, but I'd like to point out that it's still something I'm very interested in.

@zeljkofilipin yup, I think moving the portals deploy 30 minutes earlier would be good.

An update on this weeks changes to the patch sets:

• WikimediaEvents -creates the hook for pageIssues AB
  • There was some confusion with me and @Niedzielski regarding how the hook is executed, causing us to question @Jdlrobson's solution in PS21 (the problem being, that the pageLoaded event only set one sample group in certain situations). After looking in-depth at how the hook works, we realized this was the correct approach and reintroduced a similar solution in PS26.
  • There are no outstanding (known) bugs with this patch
• MinervaNeue - creates the events & event-bus PageIssues AB logging
  • Fixed to only run the AB on pages that have issues PS32
  • Only run on main namespace PS24
  • light refactoring in PS26, removing the onABStart method, as it looked like an async callback, which it wasn't.
    • associated patch removes onABStart from the AB class.
  • updating the pageIssues schema in PS28
  • this patch depends on 449432 which needs a rebase.
• MinervaNeue - adds events to page issues overlay
  • just needs a rebase

I noticed recently that the placeholder images on mobile tend to "flicker" a bit before they load. They appear grey, then white, then the image fades in.

ah, I see this issue has already been brought up, thanks @Jdlrobson :)

I don't think this problem is limited to mobile, the desktop site doesn't provide a link to the current "normal" version of the page as well.

@Tbayer I think #3 is the most accurate description.

LGTM. https://gerrit.wikimedia.org/r/449645 has been merged so I've merged the patch for this ticket https://gerrit.wikimedia.org/r/449646 and moving this to sign-off.

I don't think there's a great way to handle super short descriptions. One thing that I was thinking of doing was increasing the right padding from 8 to 16px, which I was hoping would push an extra word down to the second line. Typographically speaking, having just one word on a line is considered bad practice, but on the web this should be considered unavoidable.

Some minor schema updates:

1. I've pluralized the issueSeverity field to issuesSeverity since more than one issue can be present.
2. After merging @Niedzielski's icon severity patch, I've changed the issuesSeverity values to one of HIGH, MEDIUM, LOW, DEFAULT instead of severe, high, low, notice. The reason for this is Stephen's patch goes a long way in parsing page-issues, and using the same parsing logic for the instrumentation will give us a consistent concept of a "page issue" across the instrumentation and the feature itself.

After briefly discussing this task with the readers web team, a concern was raised that it might be difficult to coordinate the "Thanks" button with the "toast" component because the button lives in it's own extension, and the "toast" notification lives in mobilefrontend. Coordinating these two elements would mean creating a dependency between them, which might lead to breakage if one is not update updated without the other.

Just a quick update on this task. I think it's lookin' classy. @alexhollender I took your advice of using a media query on larger widths, while still truncating to two lines. I think that works pretty nicely!
I used the same breakpoint we use for tablets, (720px) . Here's a video of how it looks with short and long text.

@Reedy from the looks of it, I think three things should change here.

1. The compiled assets sprite.css, style.css, suffixed image files, png fallbacks, -- these files should not be committed to the repo.
2. These compiled files should live in their own build directory, separate from the source files (and gitignore that directory).
3. the package.json dependencies should be locked to specific versions, since changes might arise when different versions are used ( I see from T199825 that these could use an update).

yeah the fade shouldn't be x times wide as the text, it should 100% wide + some constant. I've updated the patch to achieve this. The fade is now 4em's longer than the text, and it turns Into solid grey 1em before the text "learn more" starts. Here's a GIF of the resizing behaviour now.

Yeah this looks like a bug, both the spacing and the word not showing up in Firefox. I've updated the description to reflect that. I'll look at this issue soon.

...and also updated the Page Issues schema with an issueSeverity field. From my local testing it seems like the data validates, so I'm moving this monster into the code-review column.

I've updated the readingDepth schema to add the option sample group fields. @Tbayer https://meta.wikimedia.org/wiki/Schema:ReadingDepth

Alrighty I think I got something nice. 2 lines of text with the "learn more" link placed on the last line of text. I think it's OK for basic text - tested in a few languages and I haven't come across situations where the line-height was thrown off for some reason* (yet).

Not sure if we need more discussion on this task, but as mentioned here https://phabricator.wikimedia.org/T191303#4282504
I have a POC patch that places the "read-more" link on the same line as the content here https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/440556/
I've put this up on http://readers-web-stephen.wmflabs.org for non-technical folks to check out ( ping @alexhollender )

@Volker_E The initial patch with screen-reader support has been posted on http://a11y.wmflabs.org/
Currently it just features the initial patch that enables screen-readers to read the previews.
Does not yet feature:

• closing popups via keyboard
• accessing popups settings via keyboard
• monobook skin

Correction. This fix is deployed everywhere now, so the changes are correct and caused by this patch. I was just confused because of the timestamps on Special:Version...

@alexhollender I don't know 🤷‍♂️ The change doesn't seem to be deployed on enwiki, but even the previews that were broken for me last week seem to be fixed now* ...

Just uploaded two patches that work on syncing the readingDepth & page issues test. From the page-issues test, the hooks sends an additional parameter with the name of the bucket to readingDepth. In readingDepth, an additional boolean parameter is set for every test/bucket that triggers the readingDepth test.

From the outset I don't see an easy fix here, at least not a CSS only one. CSS columns allow content to wrap up and down from column to column, but unfortunately content can't wrap from row to row.

@alexhollender thanks!

Bummer! I guess it basically just greps for keywords. I don't think defining functions as "polyfills" is a good approach because we might define a function named 'fetch' in one place, but then we might try using the native fetch function in another place, it won't spot that second error.

'http://url...ウィキペディア'.split('').reduce( (url, x) => {
    return (url.length < 1000) ? url += encodeURIComponent(x) : url;  
}, '' )

Do I get a gold star for using reduce?

Looking over the task description

Inside the Popups code, before sending a VirtualPageView event, ensure the source_url field is limited to 1400 characters.

I assume the length, 1400 characters (or 1000, from the conversation) refers to the uri encoded length of the source_url.

however out of all those, the only broken thumbnails showing up for me are

• We don't give a damn
• Music of the Marvel Cinematic Universe

just to follow up on that comment, here are the articles with non-standard page_images that I could query from the data dumps:

Just tested the new code coverage tool, and the report works.
Signing off.

Yup. Just ran the test and the coverage report works :)
Signing off

apologies, changes to this page follow the WMF deployment schedule now (deployed once a week through Git and Gerrit) and last week was a "no-deploy" week. The changes are live now though :)

@alexhollender yeah I don't really have a list of pages that have videos as the page-image of an article... I'll see what I can do...

I agree, I think sections issues should remain visible. With the work done on T191303 I think they look pretty on-par with the top-level issues.

@alexhollender in the description, could you add links to the image assets pls?

@alexhollender Originally, in this task description, making the the entire preview more narrow was half of a (my) two part solution:

1. make the entire preview narrow when necessary (this task).
2. add some sort of css border. (discussed in this task T191267).

With @Jdlrobson's approach however (placing a polyline element inside the svg) and per my comment here, we don't have to make the entire preview more narrow to achieve the desired effect. With this approach we can instead position the polyline element to same x value as the edge of the thumbnail. From an engineering perspective, I think this might be easier than fiddling with the CSS.

@Jdlrobson This looks promising! The patch doesn't yet account for thumbnails that are narrower than the maximum width (i.e. the Holy Roman Emperor example), but that use-case is easily addressed because we can position the line at the same x value as the thumbnail. II haven't tested in RTL yet, but in general I think we can move forward with this polyline solution ( I don't think their should be any browser-compatiliby issues either).

stripping all HTML from the content

@alexhollender that is not the case! we are leaving the HTML as is, and bending it to our will with CSS 🏋️‍♀️
I'll paste a link to the "read me" + fade shortly.

After poking around the summery endpoint, I realized that if we were to fix this issue there, I'm not sure what the correct response should be. The endpoint proxies the value from pageImages api, which, as seen here: https://en.wikipedia.org/w/api.php?action=query&format=json&prop=pageimages&titles=Completing_the_square&redirects=1&converttitles=1&piprop=thumbnail%7Cname%7Coriginal
returns the same non-image for "original".

from @ABorbaWMF 's screenshots, it looks like mobile and desktop use different fonts. Is that intentional?

late loading of icon and 'read me' - I know the usual way of placing an icon is generating it via JS with mw-icon, but man... can't it just be a css background image? what would the downsides be to that?

To my delight, I think this approach -- i.e. adding aria-describedby dynamically -- actually works, at least for VoiceOver on a Mac.
https://drive.google.com/file/d/1dEwRbzQfGtDaDos15s8MngJTROsGr-ZR/view?usp=sharing

I've created the branch named aria-testing for this feature.