Currently mediawiki constrains image size primarily by width, which doesn't work so well for images which are taller than they are wide. There is no way to ask for an image which has a height equal to the "default thumbnail size" (without explicitly specifying a size in px)!
It would be nice to fix this. VisualEditor/Parsoid would really prefer to use a simplified model where all bounding boxes are square, including the default thumbnail size.
Please see https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxesfor two concrete proposals for how this might be achieved, and discuss!
Thanks... --scott
On Mar 27, 2014 12:32 PM, "C. Scott Ananian" cananian@wikimedia.org wrote:
Currently mediawiki constrains image size primarily by width, which
doesn't
work so well for images which are taller than they are wide. There is no way to ask for an image which has a height equal to the "default
thumbnail
size" (without explicitly specifying a size in px)!
It would be nice to fix this. VisualEditor/Parsoid would really prefer to use a simplified model where all bounding boxes are square, including the default thumbnail size.
Please see
https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxesfor
two concrete proposals for how this might be achieved, and discuss!
Thanks... --scott
-- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Unless I misunderstand, I cant imagine this going over well with people who use images. Images are square pretty much never.
If there are issues with how to display really tall images, that can be worked out. I fail to see why square boxes are neccessary.
-bawolff
A square bounding box does not change the aspect ratio of the image. It just says "limit the largest dimension to X px".
The 'upright' option is a failed workaround for this issue. It is described in some documentation as limiting the height of the image, but that it incorrect. It is still a width-based limit. If you set 'upright' to equal the aspect ratio of the image you get consistent thumbnail sizes in a gallery, but that computation is manual and is almost never actually done. --scott
On 03/27/2014 08:32 AM, C. Scott Ananian wrote:
Currently mediawiki constrains image size primarily by width, which doesn't work so well for images which are taller than they are wide. There is no way to ask for an image which has a height equal to the "default thumbnail size" (without explicitly specifying a size in px)!
I support moving to square bounding boxes by default in the longer term, but am sceptical about the feasibility of doing this cleanly in the short term. A short-term solution based on adding more parameters that interact in subtle ways with other image parameters has a longer-term cost. We'll need to support those options for a long time, and I'm not sure that this cost is outweighed by the benefits.
For now Parsoid will use the existing upright option with the appropriate scaling factor. The main downside of this is that the image won't adhere to a square bounding box when the image aspect ratio changes. While not optimal, I believe that this case is rare enough that we don't need to rush on this.
Gabriel
Our goal should be to relinquish control of image sizing to the view, not build in more or different ways to specify it in the model.
Images should be given semantic classifications, and the skin should decide how to best display the image. Maybe it will be inline with the content, maybe it will be in a separate column which scrolls in sync with the content. Maybe it will be full width, floated right, a small thumbnail which when clicked expands to full screen. Maybe multiple images will be grouped together to make automatic galleries. Etc.
So, what we should be doing instead is deprecating the image size, type and style properties in exchange for a new semantic system where images are identified as primary, figure, aside, etc. (names are just examples). We can support both for a long time, and eventually drop support for the old properties. We could also interpret common sets of properties within certain thresholds as equivalent to semantic names, either on the fly or as a mass conversion change.
- Trevor
On Thu, Mar 27, 2014 at 9:39 AM, Gabriel Wicke gwicke@wikimedia.org wrote:
On 03/27/2014 08:32 AM, C. Scott Ananian wrote:
Currently mediawiki constrains image size primarily by width, which
doesn't
work so well for images which are taller than they are wide. There is no way to ask for an image which has a height equal to the "default
thumbnail
size" (without explicitly specifying a size in px)!
I support moving to square bounding boxes by default in the longer term, but am sceptical about the feasibility of doing this cleanly in the short term. A short-term solution based on adding more parameters that interact in subtle ways with other image parameters has a longer-term cost. We'll need to support those options for a long time, and I'm not sure that this cost is outweighed by the benefits.
For now Parsoid will use the existing upright option with the appropriate scaling factor. The main downside of this is that the image won't adhere to a square bounding box when the image aspect ratio changes. While not optimal, I believe that this case is rare enough that we don't need to rush on this.
Gabriel
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Mar 27, 2014 at 12:45 PM, Trevor Parscal tparscal@wikimedia.org wrote:
So, what we should be doing instead is deprecating the image size, type and style properties in exchange for a new semantic system where images are identified as primary, figure, aside, etc. (names are just examples). We can support both for a long time, and eventually drop support for the old properties. We could also interpret common sets of properties within certain thresholds as equivalent to semantic names, either on the fly or as a mass conversion change.
I support this goal. Some wikis have already made small steps in this direction with templates. {{Largethumb}} is used, for example, to get a second "standard size" for thumbnails. The template-based solution is not terribly compatible with VE.
Right now the only "semantic" markup is using thumb without a specific image size, which works for landscape-format images only. Moving to a square bounding box helps encourage broader use of markup without specific image sizes, which furthers the long-term semantic goals.
But I'd also be interested in seeing a concrete counter-proposal for semantic markup. Presumably from the Visual Editor UX perspective, this is just a drop down labelled "Style", along with (presumably) some discouragement of manual resize. But what would this look like in wikitext and/or Parsoid DOM? --scott
ps. although knowing our long-term direction is important, I don't believe we should let the beautiful future prevent us from making concrete improvements to the present.
On 03/27/2014 10:00 AM, C. Scott Ananian wrote:
But I'd also be interested in seeing a concrete counter-proposal for semantic markup. Presumably from the Visual Editor UX perspective, this is just a drop down labelled "Style", along with (presumably) some discouragement of manual resize. But what would this look like in wikitext and/or Parsoid DOM?
We already have different image styles, for example thumb or framed. The wikitext and DOM representation can work the same way for new types.
Identifying a good set of types and possibly necessary options should be based on a thorough analysis of current usage patterns. In any case, both new and old types need to work well out of the box without parameter work-arounds like upright.
Gabriel
On Thu, Mar 27, 2014 at 12:45 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
We can support both for a long time, and eventually drop support for the old properties.
What about the page history, though? Suddenly showing completely-wrongly-sized images in the history when you eventually drop support seems like it might be a bad idea.
On Thu, Mar 27, 2014 at 1:17 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Thu, Mar 27, 2014 at 12:45 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
We can support both for a long time, and eventually drop support for the old properties.
What about the page history, though? Suddenly showing completely-wrongly-sized images in the history when you eventually drop support seems like it might be a bad idea.
The long-term plan here, as I understand it, is to (a) store better software version information with page sources, and (b) archive parsed versions of old pages. When viewing an old page, you'd also be using an archived copy of the page parser, etc. Without getting into the details, there are plans to provide better archive/migration support so that we can introduce new features/behavior changes without breaking all history.
That said, my preferred proposal (adding a new 'square' image option) is explicitly for the short/medium term. It doesn't break backward compatibility, and it doesn't overly complicate the already-very-hairy image options parser (see https://gerrit.wikimedia.org/r/120856). In the future we can move to semantic options / change all the defaults to square / have cats and dogs living together. By then we'll have built good migration mechanisms and can remove 'square' when it's no longer needed. --scott
On Thu, Mar 27, 2014 at 1:31 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
(b) archive parsed versions of old pages.
That's not really a solution.
1. Vandal puts something oversightable in some template used on many pages. 2. People, not realizing it's in the template, edit the many pages trying to fix it, getting these bad old versions in your cache. 3. Template is fixed. Do you reparse the many pages, breaking the whole idea behind your "archive parsed versions of old pages" plan? Or not reparse it, requiring wiki users to go through all million transclusions of the template to see if any revisions were vandalized (and still missing the ones where the current version no longer transcludes the template, even though it did earlier) and manually suppress them?
Option (a) would be workable, although bitrot might be a concern.
On Thu, Mar 27, 2014 at 2:13 PM, Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Thu, Mar 27, 2014 at 1:31 PM, C. Scott Ananian cananian@wikimedia.orgwrote:
(b) archive parsed versions of old pages.
That's not really a solution.
Let's not get off-topic. The archive/storage proposals aren't mine, and aren't the subject of the RFC. I mentioned them just to point out that people have been Thinking about compatibility/migration issues and they can be treated as orthogonal if we're talking about The Future. --scott
In response to comments, I've added a third proposal to https://www.mediawiki.org/wiki/Requests_for_comment/Square_bounding_boxes which minimally addresses the "square thumbnail of default size" issue without trying to solve any broader issues. This adds a new "auto" value for the existing "upright" option, which would get the upright factor to the current aspect ratio of the image. --scott
wikitech-l@lists.wikimedia.org