gecko-dev/layout/style/ImageDocument.css
Daniel Holbert 0414682ea1 Bug 1701510: Zero out the 'body' margin for all ImageDocuments (including iframes and printed images). r=emilio
This makes us match Blink and WebKit on how to render an iframe whose src
attribute is an image URL.  They seem to have always used 0 margin in this
case, and this seems preferable from an author's perspective (since the
standard HTML-body margin feels kind of arbitrary, when viewing an image).

Note that this change does also mean that images will be slightly closer to the
upper-left of the page, if they're viewed directly and then printed.  This
shouldn't cause them to be clipped or cause other issues; they'll still be
offset from the page edge by the printed-page margins, as well as any
unprintable areas that we get from the printer.

Differential Revision: https://phabricator.services.mozilla.com/D110294
2021-04-01 00:24:10 +00:00

39 lines
1.1 KiB
CSS

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/*
* This CSS stylesheet defines the rules to be applied to any ImageDocuments,
* including those in frames.
*/
body {
/* To give the image access to our document's full viewport, we need to
override the margin that the html.css UA stylesheet would otherwise apply
to our body. */
margin: 0;
}
@media not print {
.shrinkToFit {
cursor: zoom-in;
}
.overflowingVertical, .overflowingHorizontalOnly {
cursor: zoom-out;
}
}
@media print {
/* We must declare the image as a block element. If we stay as
an inline element, our parent LineBox will be inline too and
ignore the available height during reflow.
This is bad during printing, it means tall image frames won't know
the size of the paper and cannot break into continuations along
multiple pages. */
img {
display: block;
}
}