High DPI devices currently fetch and cache hi-res images on page read, but when switching to edit in VE all we get are the standard res images, which have to be fetched from the server. Parsoid needs to support the srcset attribute to avoid this unnecessary performance hit.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Dbrant | T115488 Integrate the app fully with the Content Service. | |||
| Resolved | • bearND | T108777 Use Parsoid for new mobile-html-section routes | |||
| Resolved | cscott | T56844 Image / media handling (tracking) | |||
| Resolved | tstarling | T88827 Parsoid should return the full srcset for high DPI devices | |||
| Resolved | tstarling | T117003 ParsoidBatchAPI: Provide srcset attribute info for imageinfo requests |
Event Timeline
Comment Actions
Just a warning note -- native browser support for srcset is still a little spotty, so if you're not engaging the jquery.hidpi() transformation some browsers may still show the 1x versions.
Whereas if you do engage the jquery.hidpi() transformation, those non-native browsers will see the 'src' change to one of the values from the 'srcset' at runtime and this may confuse the editor system...
For simplicity I would probably recommend just using srcset, not engaging the jquery.hidpi() polyfill on the edit area, and letting the browsers that don't grok srcset yet (Firefox and IE mostly?) continue to show the low-res images knowing that support is coming.
Firefox - support is present in latest revs but not yet enabled - https://bugzilla.mozilla.org/show_bug.cgi?id=1018389
IE blog note, should appear in IE 12 - http://blogs.msdn.com/b/ie/archive/2014/12/08/status-roadmap-update-srcset-lt-main-gt-element-and-date-inputs-in-development.aspx
(Latest Safari and Chrome should support srcset natively, while some older versions might not.)
Comment Actions
Also I kind of prefer things like srcset here to be implementation details that a syntax parser shouldn't know about - sizing the links requires knowing the maximum size of the image, etc.
Ideally it should just ask for a multimedia blob from the wiki's file type handlers and get it back and insert it, otherwise you're going to have to reimplement every new media type perhaps. :(
Comment Actions
Our implementation should match the read mode, the main issue here is a performance one with downloading different images for read and edit. If jQuery.hidpi isn't used, or doesn't run in time to prevent the loading of the 1x image then we don't need to worry about it - we just want to catch the case where the browser only ever loaded the 2x image in read mode.
Comment Actions
Aside from performance, it's also parser parity bug. This is a bug in Parsoid due it not matching MediaWiki PHP parser output. How is this not causing parser tests failures in Parsoid? Or have they been suppressed or excluded somehow?
This is also a blocker for Parsoid to usable for reader views.
Comment Actions
This is a dup of T90911, which was forked from T63786.
Like other "Parsoid HTML for views" issues, there is a strong architectural argument to be made that this should *not* be part of the Parsoid DOM, but (like redlinks, default alt attributes, etc) be added as part of a post-processing step on the DOM. ("Parsoid DOM as canonical data representation" -vs- "Parsoid DOM as viewable HTML")
We may, of course, implement that post-processing step inside Parsoid, as some sort of extra option you can pass when you request the DOM for a particular page. Or perhaps all the post-processing should be client-side. Maybe this is a VE bug.
What I'm saying is: there are some architectural issues we need to sort out before we can go off and implement this in Parsoid.
Comment Actions
Change 249947 had a related patch set uploaded (by Tim Starling):
Add srcset attribute if imageinfo supplies it
Comment Actions
Change 249948 had a related patch set uploaded (by Tim Starling):
Provide URLs for img srcset