We should probably have a proper test image eventually, so that
we can use e.g. image dimensions to double-check the results, but
this way at least our tests won't get broken by unrelated changes
in other repos.
Change-Id: Iffffd94fde99c53da59217a5181ad0560fce314c
- rearrange DOM structure of above-fold part of the metadata panel:
- rename .mw-mmv-controls to .mw-mmv-above-fold
- the above-fold part is a single positioned div now, with height
explitcitly set
- less LESS gymnastics, above-fold height is a single variable
- add paddings to the p elements instead of the containers
- make all title elements align to baseline (except the logo which
would look horrible)
- discard some CSS which was superfluous
- overspecified sizes/positions
- some top/bottoms for staticly positioned elements
- get rid of the .mw-mmv-drag-affordance div, since a full-width bar
wouldn't really make sense on the bottom of the above-fold section
- flip the chevron and place it to the bottom of the above-fold part;
add colors etc. per spec
- fix stripe button horizontal spacing
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/706
Change-Id: Ic37b4150288055c3fae8d22919ed7b1249db1f09
- fix sizing error so that the image actually fits the screen
- hide some stuff that didn't work properly in fullscreen anyway
(commons/survey buttons just exited fullscreen, reuse menu
did not fade with the metadata panel, view terms link didn't do
anything)
- move metadata scroller CSS rules into metadata scroller LESS file
- disable invite animation which broke the opacity transition
- move opacity transition to the main metadata panel element;
remove background-color transition which is pointless since there
is an opacity transition
Change-Id: Ib26160cc6431ea007dab8441c634d0faf9ee1d0a
Several people complained that "Learn more on Wikimedia Commons"
is not clear: it can be interpreted as a link to the Commons
main page, the text does not suggest that the link will be related
to this specific file. The new wording tries to address this.
Change-Id: Ia605cc30c4ca57598f7cebdde60061800a10b6e7
This uses best-effort logging (like most other links do), not the
blocking call that's used by the other file page link, since
analytics folks had severe misgivings about that.
Change-Id: I35204420c834fa4fce3dcf81403cb78b92811caf
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/726
Instead of setting the parent's height as max height of the
<img> element, find the first parent which has a non-automatic
height (that would be .mw-mmv-image-wrapper).
With the old structure, the height of the parent element could
be determined by the height of the image, which would then be
written back into the max-height of the image, messing up the
aspect ratio. I did not see this in the wild, but it was easy
to reproduce by changing the timing of the resize handler (in
particular, I tried to call the resize handler before loading
the new resolution, to make the UI more responsive, and ran
into this problem). This cannot happen anymore now.
This also fix a bug on some browsers (IE 10, maybe iOS Safari)
where the size of the image could be slightly larger than the
available space, and the bottom of the image was obscured by
the metadata panel. I am still not sure how exactly that
happened, but it was related to the <img> parents with automatic
heights having incorrect height. After making sure the <img>
has a max-height derived from an element with non-automatic
height, I cannot reproduce the bug on IE 10 anymore.
Change-Id: I193aefc42e6d6072717643659a9e4c0c8b7c7e93
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/698
Bug: 66244
This got swapped up - created is the one which is parsed from a
template and can have all kinds of weird values. Uploaded comes from
MediaWiki and is always a proper localized date.
Change-Id: I12f60770f9841c9b379280cdf2190275fa04e5cb
