Skip to main content
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