Page MenuHomePhabricator

Provide semantic wiki-configurable styles for media display
Open, LowPublic

Description

Type of activity: Pre-scheduled session.
Main topic: Handling wiki content beyond plaintext

The problem

Our image option markup should have the means of applying site-wiki image options, customized by the administrators of the wiki.

For example:

[[File:Foo.jpg|style=thumb]]  (replaces the existing 'thumb' option)
[[File:Foo.jpg|style=largethumb]] (used by nlwiki to apply a second "larger" thumbnail size)
[[File:Foo.jpg|style=fullwidth]] (appropriate for wide figures, timelines, etc)

These styles should be more semantic than the existing display-oriented image options, and more responsive display by adapting to the variety of different ways our content is viewed (including paper-oriented output). In addition to expressing semantic information about the intended use/display of the referenced image, this markup would reduce the reliance on ad-hoc templates for image styling.

Ideally these styles could be customized by the site operators, so we can determine evolutionarily what the best set of semantic styles ought to be. Something like:

[[Mediawiki:ImageStyle-largethumb]]
200x400px

would suffice to get started (the first line is the intended page title, the second is the page contents). Perhaps eventually this can be extended to use a separate content handler for GUI editing of the image style.

Note: The Maps extension currently allows for specifying width="full" for it's <mapframe> tag.

Expected outcome

Concrete next steps.

Current status of the discussion

There are a couple of strawman syntax proposals kicking around. One is above, a few more are in the comments below.
The basic idea has been the subject of an RFC meeting, a discussion session at Esino Lario, and discussion here on this phab task.
The use cases and basic idea of decoupling image layout are valuable here.
In place of the concrete syntax proposed here, we might actually want something more general, like a skeleton associated with T149532: Why Multi-Content-Revisions? Use cases and requirements. or T150461: Story Builder.

Links

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Here's a quick stab at a new syntax:

{{#file:Foo.jpg|type=illustration|caption=Hello and welcome to Wikipedia!|altText=Welcoming image of a person smiling}}

Old syntax items and their disposition

New

  • type: 'illustration', …

Replaced with "type"

  • type: 'thumb'/'thumbnail', 'frame'/'framed', 'frameless', ''
  • thumbnail over-ride (implicit): 'thumb=Foo_thumb.jpg'
  • border: 'border'
  • location: 'left', 'right', 'center'/'centre', 'none', ''
  • alignment: 'baseline', 'middle', 'sub', 'super', 'text-top', 'text-bottom', 'top', or 'bottom'
  • size: 'XYZpx', 'xABCpx', 'XYZxABCpx', 'upright', 'upright=MNO'

Kept in new syntax, renamed

  • caption (implicit): 'caption=…'
  • alt: 'altText=…'
  • link: 'linkTarget=…'

??? TimedMediaHandler options

  • noicon
  • start={temporal offset}
  • thumbtime={temporal offset}

??? PagedMediaHandler option

  • page={number}

??? Other options

  • class={html class}
  • lang={language code}

This is also an opportunity to scrap the <gallery> tag and replace it with a multi-image option, but I think that's taking on too much at once.

I agree taking over <gallery> would be ambitious, but I'd like to see a long-term strategy that allowed incorporating more of its functionality into core. So there should be at least thought about a core syntax for multi-image layouts that wasn't radically different from the syntax for single-image layouts.

As a strawman, type=XYZ|file1=A.jpg|file2=B.jpg|caption1=A|caption2=B ? Only one type; that would identify this as a "two image full width layout" or something like that.

Ideally, the sort of indirection described in the task description (and used by type in your proposal) could be used to actually invoke the <gallery> extension to do layout of some image "types", which would avoid having to hoist it all into core.

An alternative would be to approach this from the design side, as discussed in T112991#1654417, and try to come up with a restricted subset of <gallery>s functionality which it would be appropriate to bring into core, concentrating on the bare minimum needed to implement a specific article design.

There is also a quality option for JPEGs and a lossless/lossy option for DjVu; presumably those can be merged into type.

lang should be kept, it's for overriding the content language for multilanguage images. (Multilanguage is only supported a few SVG files for now, but it would make sense for subtitles as well and is generally something we want MediaWiki to have a great support of.)

A separate class parameter could maybe be replaced by automatically adding class="<type>" and allowing easy setup of new types with some kind of inheritance.

@Tgr lang is somewhat problematic; see T60920: lang support for SVG images using SystemLanguageAttribute ill-defined and not properly supported in browsers -- it's not consistent with how the spec defines lang and so prevents native display of SVG content in the browser: we always have to render it to PNG. But I agree that a multi-language mechanism of some kind is desirable.

re: lang attribute on SVGs -- this would probably have to be implemented as a postprocessing step when serving SVGs instead of PNGs. Eg, just like the thumbnails you'd have a separate URL for each language.

Note that parsoid itself should never need to be aware of implementation details like what format an image is rendered as, or whether a particular image invocation will be a thumbnail in an img element or a video or an iframe with a JS widget inside. That's something that only the relevant MediaHandler inside the MediaWiki instance can determine, and should be filled in either by a postprocessing pass or by calling into MediaWiki.

Quick thoughts and some accompanying use cases from the article Moon

On thumbnail images:

  • should they be square, do we run into problems with vertically long images? Should we let editors have this flexibility?
  • How would these images look on other devices, should we also provide flexibility for editors to decide how they display? (i.e.: Editors might want medium-sized thumbnail images to be full-width on mobile phones but not desktop)
  • There should be a fixed width for thumbnail sizes to avoid these kinds of ragged end of sentence patterns

Screenshot 2015-09-30 14.30.57.png (557×445 px, 231 KB)

Screenshot 2015-09-30 14.31.06.png (669×362 px, 228 KB)

  • An example of fix-width thumbnail sizes

Screenshot 2015-09-30 14.40.23.png (447×458 px, 192 KB)

Screenshot 2015-09-30 14.40.32.png (704×669 px, 457 KB)

On full-width images:

  • What about a full edge-to-edge screen image vs. bound by the full image width? A full screen width edge-to-edge screen image would typically be at the top of an article.

Small thumbnail
For use in lists

Screenshot 2015-09-30 13.51.01.png (117×176 px, 19 KB)


Medium thumbnail
To illustrate text, must be large enough to get an idea of image content

Screenshot 2015-09-30 13.49.44.png (471×1 px, 330 KB)

Screenshot 2015-09-30 13.49.54.png (322×1 px, 233 KB)

Screenshot 2015-09-30 13.50.02.png (574×1 px, 456 KB)


Large thumbnail
To highlight within an article

Screenshot 2015-09-30 13.52.20.png (582×356 px, 146 KB)


Full-width images
Panoramic images, timelines, long formulas, etc

Screenshot 2015-09-30 13.52.50.png (400×1 px, 241 KB)

Screenshot 2015-09-30 15.48.38.png (290×1 px, 33 KB)


Fullscreen-width images
For use at the top of an article page

People discussed this in E68: RFC Meeting on #wikimedia-office IRC channel (2015-09-30 UTC), see meeting log (starts halfway through). There was general strong support for the idea of semantics, many open issues about the implementation. Note there were no action items, except to continue discussion of this and T112991: Semantic image styles / beautiful layout and then schedule a full hour for discussion.

Late to the party, but I'd like to volunteer the CSS I baked for myself:
https://en.wikipedia.org/wiki/User:Magnus_Manske/common.css

This already does a lot of work on the bare HTML. It does tend to mess up with "non-standard" Infoboxes etc. but this could be solved with the usual means. Also, the [[Main Page]] looks quite ugly in this, as the layout there is quite different from the usual article.
My point here is that a lot can be done with CSS (and maybe JS) alone. New syntax is fun to come up and play with, but IMHO should be reduced to necessary minimum.

Example: enwiki [[Moon]]

Moon_-_Wikipedia,_the_free_encyclopedia_-_2015-10-01_10.36.35.png (15×1 px, 6 MB)

Off the top of my head, my thoughts for the key kinds of styles are:

  • Generic thumbnails. The default. Fills more or less the role that thumb does today.
  • Big thumbnails. This covers a few different kinds of images, most obviously:
    • Emphasized images, that are important to the subject matter
    • Detailed images, where we need sufficient resolution to convey the important bits of the image
  • Flow-breaking images. Big, centred images that break the flow of text. I think it's important to focus on it as "flow-breaking" rather than "full-width" because "full-width" is a bit more presentation than semantics. "Flow-breaking" implies that the image makes a point in the article, that you're supposed to stop reading text for a moment and look at the photo or diagram. For example, I could see exceptionally wide "generic thumbnail" images rendered full-width so that they're properly visible, but otherwise small, square images pushed front-and-center by the flow-breaking semantics. Possibly should be lumped in with "emphasized images"?
  • Icons. There are a few obvious kinds of icon:
    • Message icons, as in {{ambox}}. Not too small, but not a thumbnail.
    • List icons, e.g. for {{portal}}. Fairly small, but probably bigger than text.
    • Inline icons. Tiny images that fit alongside text, as in {{audio}}, or perhaps {{flagicon}}.
  • Grouped images. There are a variety of use-cases, and this is a hard one, but {{multiple image}}'s documentation shows off some of the most obvious ones. A selection fitting into the "grouped image" category:
    • Paired images: Think "obverse and reverse of a coin"
    • Series of images: Think "caterpillar, chrysalis, butterfly"
    • Galleries: duh. Think "we have too many damn images but want to show them all off"
    • Photomontages: Pretty obvious functionality (see e.g. {{photomontage}}), and similar in some respects to a packed-mode gallery, but often I see manually-constructed photomontages uploaded as a single image—which is probably something nice to be able to avoid.
  • Files that aren't images. PDFs, presentations, video, etc. may need different styles than we use for images.

Moreover, we probably want something semantic for some images, e.g. Flag of Japan.svg should have something on it to make sure it gets a border when on a white background. I seem to recall some discussion elsewhere that this ought to be done through file-specific semantics, indicating things like needing a border on certain backgrounds, or e.g. a bounding box for the most important contents of the image so that an image could possibly be cropped slightly in certain situations (obvious use-case: Hovercards). Image-specific semantics might not apply directly to this RfC, but seem relevant to at least the broader context.

Broadly, the {{#file:Example.png|parameter=value}} syntax looks good. I particularly like that it moves in the direction of implying transclusion with braces rather than implying linking with brackets.

An annoying case I forgot:

Independent of this discussion please do not use the keyword style= for semantic specification rather than CSS inline style, since I just proposed generic HTML attributes for the element in T118720, and I would prefer consistent usage of style= parameters.

@Nihiltres "full width" isn't actually the same as flow breaking. There are a number of images in our articles which are in what I'll call "extreme landscape" orientation --- very wide and not very tall. For example: timelines, panoramic images, "the distance between the earth and the moon, to scale" in [[:en:Moon]], some mathematical formulae. In a multicolumn layout, they want to span the page (not the column) due to their aspect ratio. In a mobile browser, they might be given some sort of horizontal panning affordance. I agree that "full width" borders on presentation, but the point of the style is not to "break the flow", it's just to warn that layout that the image needs special accomodation.

Your other comments (and taxonomy) seem very good.

Some other amorphous ideas for discussion tomorrow at dev summit:

  • Can/should this fit into a broader "page style" layout? For example, is there a default "page style" which dictates that "generic thumbnails" will be 300px wide float right, but for articles dealing with mathematics, the default image presentation is going to be in centered wide blocks numbered but unfloated? Is the "lead image at top of article" a type of "page style"?
  • How exactly does this interact with T91162: RFC: Shadow namespaces? Can/will that solve our cross-wiki semantics and inheritance issues?
  • What additional semantic information do we want to express? "Flag"ness? Focus points? Exact text range to which this figure corresponds? (Can we make the semantics extensible?)
  • What additional figure manipulation do we want to allow? Cropping?

Slides for strawman syntax proposal: https://docs.google.com/a/wikimedia.org/presentation/d/1LFzz4f4D6eMY25EVlFAH3TrvoWLkpU65AWmMdH54Hps/edit?usp=sharing

I agree taking over <gallery> would be ambitious, but I'd like to see a long-term strategy that allowed incorporating more of its functionality into core.

<gallery> has been in core since 2004 (r6232).

Regarding specific "rolls", there's always the exception that proves the rule. For example, the second image in en:Geomagnetic reversal would probably not work out terribly well using the standard thumbnail width, and would be awful if you tried to have a standard thumbnail bounding box.

@Nihiltres "full width" isn't actually the same as flow breaking. There are a number of images in our articles which are in what I'll call "extreme landscape" orientation --- very wide and not very tall. For example: timelines, panoramic images, "the distance between the earth and the moon, to scale" in [[:en:Moon]], some mathematical formulae.

@cscott I tried to make it clear that aspect ratios fall outside of the semantics of "flow-breaking" images:

In T90914#1701313, @Nihiltres wrote (emphasis added):

"Flow-breaking" implies that the image makes a point in the article, that you're supposed to stop reading text for a moment and look at the photo or diagram. For example, I could see exceptionally wide "generic thumbnail" images rendered full-width so that they're properly visible, but otherwise small, square images pushed front-and-center by the flow-breaking semantics. Possibly should be lumped in with "emphasized images"?

As a concrete example, the reaction diagrams in many chemistry articles, e.g. en:Wittig reaction, would probably qualify for flow-breaking semantics. The images aren't always terribly wide, but placing them in a flow-breaking way is important for their presentation in context.

This was a very productive discussion session at Wikimania in Esino Lario: https://wikimania2016.wikimedia.org/wiki/Discussions/Rethinking_the_layout_of_Wikipedia_articles

Nominating for the 2017 Developer summit to try to continue the momentum and build some consensus about prioritizing one or more of the ideas coming out of Esino Lario for implemention.

Please remember the next deadline in the selection process:

2016-11-14: Deadline for defining a good problem statement, expectations, and links to relevant resources.

That is next Monday.

@cscott Hey! As developer summit is less than four weeks from now, we are working on a plan to incorporate the ‘unconference sessions’ that have been proposed so far and would be generated on the spot. Thus, could you confirm if you plan to facilitate this session at the summit? Also, if your answer is 'YES,' I would like to encourage you to update/ arrange the task description fields to appear in the following format:

Session title
Main topic
Type of activity
Description Move ‘The Problem,' ‘Expected Outcome,' ‘Current status of the discussion’ and ‘Links’ to this section
Proposed by Your name linked to your MediaWiki URL, or profile elsewhere on the internet
Preferred group size
Any supplies that you would need to run the session e.g. post-its
Interested attendees (sign up below)

  1. Add your name here

We will be reaching out to the summit participants next week asking them to express their interest in unconference sessions by signing up.

To maintain the consistency, please consider referring to the template of the following task description: https://phabricator.wikimedia.org/T149564.

As a Summit proposal, this topic will be part of T151952: Media, Visualizations, and Layout at Wikidev'17.

This task has a live of its own though, so I am just removing it from the Summit workboard.

@cscott i also got some interesting insight into these problems with Wikipedia Signpost recently (rich formatting, that is pretty crappy on mobile). I've made some improvements there simply by using flex box overrides, viewport units and CSS columns, as (inefficient) workarounds for lack of media queries, but it shows once more that this is not just an 'image' problem.

This RFC seems to be stalled. If there is currently no interest in driving this further, it should for now be removed from the RFC work board.
If there is interest in continuing the RFC process, please let us (TechCom) known who will be working on this RFC, and who commits to implementing it if approved, and in what time frame.

This RFC seems to be stalled. If there is currently no interest in driving this further, it should for now be removed from the RFC work board.
If there is interest in continuing the RFC process, please let us (TechCom) known who will be working on this RFC, and who commits to implementing it if approved, and in what time frame.

This is mostly a product RfC with some TechCom RfC components. We don't really have a process for those… In terms of whether we in Audiences are going to resource making this product change, it's unlikely to happen very soon.

If you currently have no need for approval of a technical solution, perhaps it makes sense to replace the TechCom-RFC tag with plain #rfc. We use that for "internal" Wikidata RFCs and such. What do you think? The TechCom-RFC board is really for managing the TechCom process, and I don't see how this ticket currently fits into that.

If you currently have no need for approval of a technical solution, perhaps it makes sense to replace the TechCom-RFC tag with plain #rfc. We use that for "internal" Wikidata RFCs and such. What do you think? The TechCom-RFC board is really for managing the TechCom process, and I don't see how this ticket currently fits into that.

Maybe mark this and similar as Stalled and exclude Stalled RfCs from the default TechCom-RFC board view?

kchapman subscribed.

Untagging as not crosscutting enough to be a TechCom RFC

Resetting assignee as it does not seem like @cscott is actively working on this task (feel free to correct me).