5 ms·

With the solution I propose, it seems like the server could be blissfully dumb, and the client could be smart and choose whether to request 2x images if the pag

by tpenzer 14y ago

With the solution I propose, it seems like the server could be blissfully dumb, and the client could be smart and choose whether to request 2x images if the page author indicates they're available. I don't see the advantage in this regard.

napillo 14y ago
The solution I propose is just to leave everything the same and have browser vendors make a compatibility view which will increase the size of the text and images.
skeltoac 14y ago
Adding new HTML conventions puts too much responsibility on authors. HAIR requires very little of authors: store your images according to some new convention. This burden exists in other systems, too. HAIR is unique in that this is the only burden placed on authors. They don't have to worry about making their HTML or CSS match their uploads. They don't have to compare dozens of competing JS solutions every time they start a project. Blissfully dumb machines are a less worthy goal than blissfully dumb authors. Raising the bar for millions of people--especially without a standard to bind them--is impossible. OTOH it takes a handful of people working on server and browser software to add HAIR to millions of clients and servers. Another handful of people will make macros to help designers export images into the new format.
- tpenzer 14y ago
  I guess I set up my proposal the way I did so that authors could explicitly flag assets as being available or unavailable in 2x in the most convenient way conceivable to me, because it would add inefficiency to force a choice between assuming all assets are available in 2x and that none are, as some requests will fail if they're not all available in 2x. I will mention that for my proposal, if you want to assume all assets are available in 2x, the extent of the work for authors would be to add '<meta image-scaling={2:"@2x"} />' to the page. It is potentially more work than HAIR, but I figured it would pay off with server resource efficiency, accessibility to authors, and powerful flexibility. That said, I could totally get on board with HAIR, assuming my concerns are unfounded (which is likely). How does that system affect server capacity and performance? Is there a significant performance penalty for having the server determine whether each asset is actually available in 2x or not before fulfilling the client's request? Is this information which would automatically be cached, and thus not have a significant impact? Or will each image request have an additional operation to perform? Also, does this system force you to have your 1x and 2x assets share the same exact filename? In the example, are the 1x images in the 'img' directory, and the 2x in 'image' with the same filename? I'm sorry if my confusion is making me ask the wrong questions; maybe evidence of the challenge of explaining this system to clueless people like me. [Upon further review, it looks like an img src link to '/img/bob/' would load the 'index.jpg' file from inside the 'bob' directory by default, and then your system would have it load the 'dpr=2.jpg' file if the client wants that. So this imposes even more stringent file naming and organizing restrictions than I had in mind, and it works nothing like what I thought upon first glance (never knew you could even link to a directory for an image asset, and have it load index.jpg, though it does make sense). I am embarrassed to admit that I'm not completely sure where I'd even put those parameters, though I assume it would be in httpd.conf for apache, or maybe .htaccess otherwise. Also, does this require a separate entry for each image on the site?]
  - skeltoac 14y ago
    I am working on an implementation in Apache/PHP. The first part is an internal redirect in .htaccess to a PHP script which decides what to serve. Obviously a PHP script is not optimal for broad use. A better implementation would be an Apache or nginx module. But PHP is handy for experimentation.

by tpenzer 14y ago

napillo 14y ago

The solution I propose is just to leave everything the same and have browser vendors make a compatibility view which will increase the size of the text and images.

skeltoac 14y ago

Adding new HTML conventions puts too much responsibility on authors. HAIR requires very little of authors: store your images according to some new convention. This burden exists in other systems, too. HAIR is unique in that this is the only burden placed on authors. They don't have to worry about making their HTML or CSS match their uploads. They don't have to compare dozens of competing JS solutions every time they start a project. Blissfully dumb machines are a less worthy goal than blissfully dumb authors. Raising the bar for millions of people--especially without a standard to bind them--is impossible. OTOH it takes a handful of people working on server and browser software to add HAIR to millions of clients and servers. Another handful of people will make macros to help designers export images into the new format.

tpenzer 14y ago
I guess I set up my proposal the way I did so that authors could explicitly flag assets as being available or unavailable in 2x in the most convenient way conceivable to me, because it would add inefficiency to force a choice between assuming all assets are available in 2x and that none are, as some requests will fail if they're not all available in 2x. I will mention that for my proposal, if you want to assume all assets are available in 2x, the extent of the work for authors would be to add '<meta image-scaling={2:"@2x"} />' to the page. It is potentially more work than HAIR, but I figured it would pay off with server resource efficiency, accessibility to authors, and powerful flexibility. That said, I could totally get on board with HAIR, assuming my concerns are unfounded (which is likely). How does that system affect server capacity and performance? Is there a significant performance penalty for having the server determine whether each asset is actually available in 2x or not before fulfilling the client's request? Is this information which would automatically be cached, and thus not have a significant impact? Or will each image request have an additional operation to perform? Also, does this system force you to have your 1x and 2x assets share the same exact filename? In the example, are the 1x images in the 'img' directory, and the 2x in 'image' with the same filename? I'm sorry if my confusion is making me ask the wrong questions; maybe evidence of the challenge of explaining this system to clueless people like me. [Upon further review, it looks like an img src link to '/img/bob/' would load the 'index.jpg' file from inside the 'bob' directory by default, and then your system would have it load the 'dpr=2.jpg' file if the client wants that. So this imposes even more stringent file naming and organizing restrictions than I had in mind, and it works nothing like what I thought upon first glance (never knew you could even link to a directory for an image asset, and have it load index.jpg, though it does make sense). I am embarrassed to admit that I'm not completely sure where I'd even put those parameters, though I assume it would be in httpd.conf for apache, or maybe .htaccess otherwise. Also, does this require a separate entry for each image on the site?]
- skeltoac 14y ago
  I am working on an implementation in Apache/PHP. The first part is an internal redirect in .htaccess to a PHP script which decides what to serve. Obviously a PHP script is not optimal for broad use. A better implementation would be an Apache or nginx module. But PHP is handy for experimentation.