help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On markdown images


From: Yuri Khan
Subject: Re: On markdown images
Date: Mon, 3 May 2021 12:43:24 +0700

On Mon, 3 May 2021 at 02:31, Emanuel Berg via Users list for the GNU
Emacs text editor <help-gnu-emacs@gnu.org> wrote:

> I have the width here:
>
>   .images_right {
>       float:            right;
>       padding-top:      6px;
>       width:            206px;
>   } # [1]
>
> But the height vary from image to image, should I put it
> "explicitly" as attributes in the HTML [2] then?

I wouldn’t. Having width in CSS and height in HTML feels wrong.

> OTOH to have one CSS class for every image feels ... lame.
> And a lot of typing.

True.

I feel there are multiple distinct use cases for images, and they
warrant different approaches:

* Icons. You typically know the size beforehand and use the same size
for all icons. So .icon { width: 24px; height: 24px; }

* Large photos. You prepare them in as high resolution as possible and
let the browser scale them down to fit the window: .photo { display:
block; max-width: 100%; } You let the browser calculate the height on
its own, accepting the layout delay. Fortunately, the visual effect of
re-layout is not as annoying for block images as it would be for
inline images.

* Screenshots, pixel art, and line art. In contrast with photos, you
typically do not want to allow arbitrary scaling for these. So you
either specify the exact dimensions in HTML to help the browser lay
them out, or in CSS (but this leads to one class for every image), or
you let the browser sort it out on its own. (NB: The latter is bad for
HiDPI screenshots, as they will be displayed at twice their natural
size. Also, if displaying normal DPI pixel images at their natural
size, instruct browsers on HiDPI displays to use crisp image scaling
algorithm: .pixelart { image-rendering: -moz-crisp-edges;
image-rendering: -webkit-optimize-contrast; } otherwise it will come
out all blurry.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]