![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
Entry tags:
Question thread #91
It's time for another question thread!
The rules:
- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.
The rules:
- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.
no subject
So:
(a) what are the default resizes? Is it to a specific pixel height or width?
(b) is there any way I can change it on my end so that my images show up as a % of container width instead of being forced to be too small?
no subject
Hrm... it looks like that's caused by the code trying to fit images into the screen height, not just its width. That's certainly a choice.
It doesn't appear to be documented anywhere, but looking at the code, I think you can add the
imageshrink-exemptclass to the<img>tags to get what you want (e.g.,<img src="..." class="imageshrink-exempt" width="80%">). At least, that seems to work poking at it in the inspector.no subject
no subject
Hello! I made the image shrinking CSS/JS.
If an image is inside either a
<table>or a<div style="...">element, we don't mess with its sizing, because we assume someone's trying to make it line up with something specific.So that's the official way to say "size it exactly like this" -- put it inside a table or a div with inline styles. The
imageshrink-exemptclass is an implementation detail, and we'd rather you don't rely on it, since we don't want your stuff to change if we change that implementation.We've done a few iterations on the shrink behavior already, and I've always got my eye out for more improvements we could make in the future. This case is an interesting one just because the "zoomed" size is so unusably huge; I'll need to ponder that.
There might be a way to treat the width/height attributes as the max size for the "zoomed" state; would that fit what you want to have happen? Where the "squished" state tries to respect the user's device, but the "zoomed" state tries to respect the size hints of the post's author (instead of the raw pixel dimensions of the image file)?
no subject
It'd definitely be nice if the "zoomed" state respects my width definitions! Or if the shrink wasn't trying to fit to screen height. There's definitely webcomics out there that have a reasonable max width but no max height considerations because nowadays people just scroll. (Instagram is changing that behavior again, but not fully). For example, SMBC (see example from smbc feed here: https://smbc-comics-feed.dreamwidth.org/1103365.html ). At least it's better than tumblr, which basically resizes things to fit to 1024 height, and therefore makes tall webcomics too low-res to actually read...
no subject
Yeah, it needs an inline style. Well, more precisely, it just needs a
styleattribute. An emptystyle=""attribute works fine.That exemption isn't really meant for "normal content" images like a photo or a comics page; it's meant for stuff inside some kind of decorative markup like a character sheet or a nav thingy, where the sizes of things need to line up just so. For casual images, the HOPE has always been that you just post it and it's fine (plus or minus a little bit of click-to-zoom). But we're kind of still getting there.
What's tricky is the amount of (kinds of stuff) x (ways in which stuff gets posted) x (ways in which stuff gets displayed). Like,
So for a portrait of a person, you definitely want to keep the image inside the viewport by default, which means constraining the height. But that plays hell with a 4-comi style strip, so you need click-to-zoom. But click-to-zoom only fixes strips that aren't inside links (the QC feed); the SMBC feed still looks kinda hosed. But you don't want to break link-clicking, so you need some other way to control zooming, maybe a little hover control or something? But making that work on EVERY JOURNAL STYLE starts getting kind of prohibitive, and besides, the link goes to a full size version of that image anyway, so I haven't gotten that one solved yet. And then we've got your issue, where the pixel dimensions aren't related to the intended display size.
Well, I'm rambling. Anyway, I figured out how to limit the "zoomed" state to the provided height/width attributes, but haven't figured out how to skip displaying the "zoomable" cursor in that case for images that are already the size they'd "zoom" to. Maybe that's not a huge problem; I'll mull it over a bit more.
no subject
It makes sense that you'd want photos or portraiture to fit vertically on the screen, so I just may be the odd person out in wanting to post comics, etc. And I've gotten in the habit of clicking through to SMBC nowadays to read a long strip, so it's not terribly inconvenient, especially since now I know the div trick!
Then again, maybe if either height or width is specified as a percentage on the image, the person might be wanting it a specific way? It was definitely a bit weird to me when my img tag refused to behave in the way I'd intended, and I didn't know why or how I could get around it. (though that might be a documentation issue). But I totally see your point re: random images being brought in that have unhelpful width/height attributes, combined with the wide range of widths for the post container (probably ranging from 300-1000px). Awkwardness regardless, tbh. Tumblr does it awkwardly, too -- inline images below an arbitrary pixel threshold gets displayed as-is (I think 320px wide), and over that gets forced into 100% wide, so if I wanted a 400px img to stay 400 px, I'd have to add 100px of whitespace, or add a "do not resize this" class to the image.
Anyways, thank you so much for the info about the div/table tags, and for doing all this to make it work better! I shall use the tags judiciously!
no subject
Hmm, now that you got me thinking about it again, I've thought of a few more improvements:
style="..."attribute! That's an extremely clear way for people to say "I'm handling it myself."That would still squish your comics more than you want, but if we used your width attribute to make click-to-zoom max out at "legible" instead of "stupid," maybe that wouldn't be that bad? Plus you could always just use inline CSS to do whatever specific thing you want.
no subject
Hi! Pardon the necro-post, but since I told you about the more awkward workarounds for image squishing, I wanted to let you know that there are now easier ways to deal with this!
style="(some css)"attribute on an image tag, we don’t squish it at all. So you can use that to set an exact size calculated however you want.Those are all things we discussed later in the thread, but now they’re live on the site. I hope they make things nicer!
no subject
Ah, thank you so much for resurrecting this post! I noticed the image changes on the smbc comics since the code push and rejoiced! And the other things make perfect sense re: image sizing. Thank you so much for making my dreams come true <333
no subject
no subject
no subject
no subject