Timeline for Allow down-sizing of double-resolution community ads
Current License: CC BY-SA 3.0
12 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
May 23, 2017 at 12:36 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
Mar 20, 2017 at 10:31 | history | edited | CommunityBot |
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
|
|
Jul 7, 2016 at 21:34 | comment | added | SevenSidedDie | “Technically challenging” as in, it's asking for a non-trivial code change in at least two parts of the codebase (the parser/tidier and the renderer at least, but possibly others) and all the time and programmer salary (and inevitable bugs and more programmer salary) that go with that, for a relatively tiny feature gain. The technical aspects of the change are an inherent challenge for the feature request to overcome — that meaning of “technically challenging”. ;) | |
Jul 7, 2016 at 19:04 | comment | added | E.P. | I'm not sure it's that technically challenging, though. All that's needed, on the html route, is a syntax parser for a format that can be very rigidly defined beforehand in the specs on the question. The mardown resizer is similar but it does require adding capabilities to the existing display engine. (But those capabilities are welcome anyway!) | |
Jul 7, 2016 at 19:02 | comment | added | E.P. | Sorry, scratch my last comment - images aren't resized server-side when the client is low-res. The ideal solution is a Markdown or html-based resizing, which are not subject to the downsides you note. | |
Jul 7, 2016 at 18:54 | comment | added | SevenSidedDie | It doesn't show the ad as displayed. Currently on an iOS device and the two images above are obviously different: the second is badly blurred compared to the first. The m suffix reduces resolution server-side, which is what the double-sized ads are deliberately avoiding in order to give better images on high-res screens. The HTML option would work in that regard—its resizing is client-side and would serve the correct image—but yes, is technically challenging. | |
Jul 7, 2016 at 18:52 | comment | added | E.P. | On the other hand, I'm not sure it doesn't show the ad as it will be displayed, at least on normal-res devices. The images are resized anyway when served to low-res devices, so it might actually show a better impression of the ad as it will be shown. But hopefully a team member can comment on the details? | |
Jul 7, 2016 at 18:49 | comment | added | E.P. | @SevenSidedDie For sure, the ideal solution is the html-based one, or an explicit markup notation for image size. An alternative is altering the display engine for those threads (so the post shows the ad as it will be displayed) but that's not ideal to say the least. | |
Jul 7, 2016 at 18:44 | comment | added | SevenSidedDie | Note that the m suffix serves a different, lower-resolution image file, so that would only replace the problem of not showing what the ad will look like with a different (possibly worse, even) problem of not showing what the ad will look like. | |
Jul 7, 2016 at 15:50 | history | edited | E.P. | CC BY-SA 3.0 |
added 444 characters in body
|
Jul 7, 2016 at 12:59 | history | edited | Shadow Wizard |
edited tags
|
|
Jul 7, 2016 at 12:53 | history | asked | E.P. | CC BY-SA 3.0 |