Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

sorry for more spam people :-)
a couple of things i don't have time to write about before i go to  
bed (tis gone 1am here)



http code 300 is what i was wanting, not 406 or making up a new one
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1

the "Suggest-Location" param already exists, and is just called  
"Location"

(same url)

agent-driven negotiation is already suggested by HTTP 1.1:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html
except that:
	1) the format of a 300 response is not defined and in fact doesn't  
make it clear whether UAs should look in the headers or body for the  
list of choices
	2) there seems to be no way to make apache (v1.3) generate a 300  
response, it does server-side negotiation with all the things i tried  
(which is where my new header would apply - make it generate a 300!).
	3) i've never seen a 300 response from any web server in the wild.  
if it's not even implemented, i'm not surprised no client apps do  
their own negotiation.



I am intrigued by what larry just write, and will look at it either  
tomorrow or in 10 days, as am away next week.
i'm sure all the HTTP boffins already knew this and are lookin  
skyward right now. sorry folks!


- Nicholas.




smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

On 7 Jun 2007, at 23:07, Rob Burns wrote:

PS, again my suggestion is for the client to request specific pixel  
dimensions for the media not the ppi/dpi/cmpi) If the the UA is in  
an environment with multiple displays or multiple resolution output  
of any kind it can use that in determining the pixel dimensions to  
request. Otherwise, it can re-request the image for the new output  
device..


Yeah, your earlier example used ppi, not dimensions. Could you please  
provide a new example of what you envisage, with all the relevant  
back-and-forth headers enumerated, although I think what I suggest  
below is better than sending any pixel data to the server. Let me  
know what you think on this, Rob:



On my previous CHOICES suggestion:

Thinking further about caching, creating a new request type that was  
a hybrid of GET and HEAD was a bad idea. A better way would be to use  
GET but supply a new header that disables content negotiation (which  
is what I was really trying to do, though I didn't quite realise it),  
forcing a 406 if any content negotiation would otherwise have been  
performed. The 406 would then be automatically handled (not presented  
to the user). It puts all choice in the hands of the client/user and  
not the server/author.


I expect it would go something like:

"Negotiation: disable"


So what happens now still works:

Old client requests image /foo and provides no disabling header
Server sends back 'optimum' resource foo, as best it can determine,  
taking into account quality-of-source and file length

Object is cached by proxy
Client uses result returned


New behaviour also works:

New client requests /foo and asks for content negotiation to not  
occur by including a new header.

Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.

-or-

New client requests /foo and asks for content negotiation to not  
occur by including a new header.
Server detects multiple resources to choose from, sends back a 406  
immediately

Result is not cached by intermediate proxies.
	(A smart proxy could even clear it's cache whenever it sees a URI  
return a 406,
	as it now knows that there are multiple representations for that  
resource and

that it's previous cached object would not be valid for all clients!)
Client parses (scrapes) the 406 response body (which will have to be  
more clearly spec'ed)
Client issues a new request for the choice it wants, using exact URI,  
can omit new header this time

Server responds without negotiation because there's only one choice.
Response is cached as normal by proxy.
Result is used by client.


The cost is one round-tip to the server per negotiable URI + one  
header on all initial resource requests.

The saving is no need to send any Accept-* headers anymore.


So basically:
• Content negotiation is a good thing for users
• Server-side negotiation defeats caching and gets so long-winded  
that usually a wildcard is sent anyway (e.g. Accept-Encoding)
• Client-side negotiation allows caching of the final URI, as long as  
the negotiable URI is not cached and a bad choice returned by the proxy.
• Client-side negotiation can be transparent to the user, a 406  
response doesn't need to be presented
• This can all be implemented as an extension to HTTP 1.1, and in a  
future version of HTTP, the new header can be made implicit.
• Whilst there could also be a "Negotiation: enable" for HTTP 1.2 or  
2.0, simply sending the Accept-* headers would be enough to indicate  
that you wanted server-side negotiation.
• The response could also include a Suggest-Location: header for  
clients that aren't able to/don't want to parse the choices and  
select one. This would probably be what the server would have picked  
if it had done negotiation anyway.
• Also, a new response code (418 Client Selection Required) could be  
used instead of a 406, with an XML body that the client is not  
allowed to show to the user. This would be much better than scraping  
a 406, more extensible in future etc etc. Clients without an XML  
parser just use the server's suggestion.



- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Rob Burns]

On Jun 7, 2007, at 3:52 PM, Andre-John Mas wrote:

Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css? A  
browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.


The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing  
and mis-rendering things on screen.


The other thing that must be taken account is that on a multi- 
headed computer you may have two screens each with different DPIs.  
If you were to send DPIs to a server, which one would you use? It  
is for reasons such as this, that I believe, that it is important  
that it the responsibility of the local system to work this out,  
with the appropriates hints from the web page.




It seems that you're not reading the proposal.  This does call for  
the client to use whatever algorithm it deems appropriate to request  
an image of a certain pixel dimension (though I think my copy of  
Nicholas example may have read ppi, I meant to list pixel dimension).  
In any event, the server works to accommodate the client.  This isn't  
meant to help the client determine the absolute dimensions its meant  
to deliver efficiently sized content. If its too large, it waists  
bandwidth (at a UI responsiveness degrading moment) and then gets  
down-sampled by the client anyway. If its too small, it may look  
poor. CSS will not solve this (except for CSS related images). It  
needs content negotiation. And even for CSS with media queries, this  
is even more flexible.


Also, as I said before media queries do not accomplish what you're  
saying they accomplish. They don't leave things in the hands of the  
client, they're in the hands of the author. So if the author (maybe  
years before), decides to deliver an image of a certain size to the  
client, that's what the client gets. WebKit isn't going to be able to  
request a different size. Presumably the authro will make it  
appropriate for the client (based on the media query), but the author  
does no necessarily know anymore about WebKit's image processing  
capabilities (whether it prefers an image twice the size to one a  
little smaller than the requested size). So the solution proposed  
here actually puts more control in the clien't's hands than CSS media  
queries (unless the client starts lying about its meda environment,  
but I don't think that would be good practice).


Take care,
Rob.

PS, again my suggestion is for the client to request specific pixel  
dimensions for the media not the ppi/dpi/cmpi) If the the UA is in an  
environment with multiple displays or multiple resolution output of  
any kind it can use that in determining the pixel dimensions to  
request. Otherwise, it can re-request the image for the new output  
device..

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

On 7 Jun 2007, at 21:52, Andre-John Mas wrote:

Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css?


Yes, but we want a solution that works where CSS is unavailable, the  
target destination may not be an HTML page either. An example could  
be an application that displays arbitrary images from file: and http:  
URLs. With file: we have metadata available, with http it has to be  
provided along with the image.


A browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.


Also, some, but by no means all images have pixel dimensions and DPI  
encoded into them, rather than how wide they are in cms. Either set  
of values will do the job though.


The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing  
and mis-rendering things on screen.


I wrote a webkit patch for that, which has a lot of comments on the  
issue:

http://bugs.webkit.org/show_bug.cgi?id=11644

There was a request for make it conditional on a user preference, but  
the tree got locked down, then I got a job and didn't have time to  
update the patch.


The other thing that must be taken account is that on a multi- 
headed computer you may have two screens each with different DPIs.  
If you were to send DPIs to a server, which one would you use? It  
is for reasons such as this, that I believe, that it is important  
that it the responsibility of the local system to work this out,  
with the appropriates hints from the web page.


I suggest sending the highest DPI and then scale back slightly for  
the lower res screen when windows are dragged across (they won't be  
too different I'd imagine). The patch took the DPI from the main  
display, which is probably the next best thing.


- Nicholas.




smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Andre-John Mas]

Surely all of this becomes moot if we specify objects in terms of  
inches, cm or mm, all of which are already supported by css? A  
browser that interprets these 'absolute' units properly should  
already know what DPI the current environment is in, or have access  
to the necessary API to display correctly.


The problem that we have today is that some environments don't tell  
the application the real DPI, so the application is left guessing and  
mis-rendering things on screen.


The other thing that must be taken account is that on a multi-headed  
computer you may have two screens each with different DPIs. If you  
were to send DPIs to a server, which one would you use? It is for  
reasons such as this, that I believe, that it is important that it  
the responsibility of the local system to work this out, with the  
appropriates hints from the web page.


Andre

On 7-Jun-07, at 16:38 , Maciej Stachowiak wrote:



On Jun 7, 2007, at 1:26 PM, Rob Burns wrote:


Macej,

I think you misunderstand the proposal. It does take scale factor  
into account. It also is meant to handle other cases (not just  
CSS). I do think you're right about the server advertising the  
possibilities, but that would probably complicate things a lot.


It can be done in the CSS file for CSS backgrounds using media  
queries, this allows things to work without any server-side  
changes. The only case that needs to be addressed better IMO is  
foreground images via . And that should probably be handled at  
the HTML or CSS level, not the HTTP level.


In any case its better than simply getting a one-size-fits all  
bitmap image.


The scale factor is the only thing that *actually* matters. The DPI  
is irrelevant. (And as Hyatt pointed out, the actual scaling an  
image gets might depend on the specific context in the page.)


 - Maciej



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

On 7 Jun 2007, at 20:58, Maciej Stachowiak wrote:

2) DPI is not really the relevant factor to make the decision,  
what's important is the UI scale factor. If I'm running at 144 DPI  
but at 1x scale, I want the same images as at 72 dpi 1x scale.


I presume you meant "72 dpi 2x scale" there. In that case just ask  
for 144 in the request. The server doesn't need to know whether it's  
a high res screen or a low res one zoomed in, only how many pixels  
you've got to fill so it can pick the 2 MB photo or the 30 MB photo.


I think the whole design of it is wrong. It's based on DPI instead  
of scale factor,


It is based on both, the client apply the scale to the output dpi  
before making the request, so it doesn't ignore scale factor, it's  
pre-multiplied beforehand.


it pushes the decision to the server when it should be made on the  
client side


This is a good example and something that cannot easily be done at  
present - client-side selection.
The only way i see to do that would be to preflight each request with  
a GET with "Accept: *;q=0" header, wait for the 406 response, and  
make a second request by selecting from the list given. The server  
would also need to provide the DPI of the images. The problem here is  
for most resources there is only one choice, but you have to make two  
trips to the server for it.


I know of no means for a client to say "I want this resource, send me  
a list of choices if there are any, or the resource otherwise".  
Perhaps there ought to be a CHOICES method that either returns a 406  
list if there are choices, or returns the 200 result like GET would  
have done if and only if there was one choice. CHOICES would never do  
server-side content selection. Then you would only have one request  
for most resources, and two for the negotiable ones, yet do the  
selection on the client side. The problem with GET is it might  
succeed in selecting a resource that you didn't want, and when it  
does, the Vary header isn't detailed enough to tell you what else  
might be more appropriate.


Also bear in mind it's infinitely easier for an administrator wanting  
to deploy high-res images to update his server software than to  
persuade all his users to upgrade theirs! Whilst I can't see a way of  
getting the result without updating both, further refinements on the  
server can improve all clients that send the new header, without them  
needing to update too.


and it handles things at the HTTP level that should be (and indeed  
are) handled by CSS media queries.


What about when CSS is not available?
What about when you don't control either the CSS or the image  
resource? (e.g. adverts on a 3rd party server)
What about when you don't know what variants of a resource there may  
be now or in the future?



What you care about with images embedded in web content


And what about images not in web content?
I agree, use media queries where HTML+CSS is available and you can  
control both the CSS and the images, but you need to fall back to  
content negotiation otherwise.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Maciej Stachowiak]

On Jun 7, 2007, at 1:26 PM, Rob Burns wrote:


Macej,

I think you misunderstand the proposal. It does take scale factor  
into account. It also is meant to handle other cases (not just CSS).  
I do think you're right about the server advertising the  
possibilities, but that would probably complicate things a lot.


It can be done in the CSS file for CSS backgrounds using media  
queries, this allows things to work without any server-side changes.  
The only case that needs to be addressed better IMO is foreground  
images via . And that should probably be handled at the HTML or  
CSS level, not the HTTP level.


In any case its better than simply getting a one-size-fits all  
bitmap image.


The scale factor is the only thing that *actually* matters. The DPI is  
irrelevant. (And as Hyatt pointed out, the actual scaling an image  
gets might depend on the specific context in the page.)


 - Maciej




Take care,
Rob

On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote:



On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing  
list that a HTTP header which specified a document's target  
resolution would be useful to allow clients to negotiate for high- 
res or low-res artwork and CSS referring to such (background- 
image, and the like), depending on their screen pixels, printer  
resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are  
possible which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple  
stylesheets in HTML/XML, or to select from multiple blocks in a  
single stylesheet.


This is meant for a more flexible approach that also works outside  
CSS.




2) DPI is not really the relevant factor to make the decision,  
what's important is the UI scale factor. If I'm running at 144 DPI  
but at 1x scale, I want the same images as at 72 dpi 1x scale.




Don't you mean 0.5x scale?

3) Passing the resolution to the server forces the selection logic  
to be on the server side, not the client. But that's not really  
sensible - if the server has multiple  resolution versions of a  
resource, such as an image, it should advertise them to the client  
and let the client choose. For example, at 1.5 UI scale factor, if  
the server has 3x and 2x images available the client could  
reasonably choose 2x (the next scale up) or 3x (since it is an  
integer multiple of the scale factor).




This is a valid issue, but perhaps it could be addressed in the  
proposal. Its better than the alternative of no non-css approach.  
However, keep in mind that In a purse CSS environment, the author  
doesn't take into consideration the processing needs off the client  
anymore than the server does. The CSS (written by the author) will  
determine which pixel dimension image the client gets).


This doesn't make sense with the way clients actually work. What  
you care about with images embedded in web content is the relative  
scale of CSS pixels relative to device pixels, which does not have  
any necessary direct relation to the physical DPI. You don't  
actually want to serve different images to different DPI screens if  
they are both running at the same scale factor.


I think you're saying the same thing in different language. Both Mac  
OS X and CSS were designed with resolution independence in mind. The  
distinction over devise pixels and CSS pixels merely muddies the  
issue. An image that's specified to be 4 inches square on a 96dpi  
display at 50% zoom is 192 pixels square (however you want to say  
it). Getting that pixel dimension image delivered form the server is  
what we're looking for (or perhaps a different pixel dimension if  
the client expects a resizing or immediate printing).



I think the whole design of it is wrong. It's based on DPI instead  
of scale factor, it pushes the decision to the server when it  
should be made on the client side, and it handles things at the  
HTTP level that should be (and indeed are) handled by CSS media  
queries.


I think you should take another look at it. Your objections don't  
really address the proposal.


Take care,
Rob


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Rob Burns]

Macej,

I think you misunderstand the proposal. It does take scale factor  
into account. It also is meant to handle other cases (not just CSS).  
I do think you're right about the server advertising the  
possibilities, but that would probably complicate things a lot. In  
any case its better than simply getting a one-size-fits all bitmap  
image.


Take care,
Rob

On Jun 7, 2007, at 2:58 PM, Maciej Stachowiak wrote:



On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing  
list that a HTTP header which specified a document's target  
resolution would be useful to allow clients to negotiate for high- 
res or low-res artwork and CSS referring to such (background- 
image, and the like), depending on their screen pixels, printer  
resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are  
possible which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple  
stylesheets in HTML/XML, or to select from multiple blocks in a  
single stylesheet.


This is meant for a more flexible approach that also works outside CSS.



2) DPI is not really the relevant factor to make the decision,  
what's important is the UI scale factor. If I'm running at 144 DPI  
but at 1x scale, I want the same images as at 72 dpi 1x scale.




Don't you mean 0.5x scale?

3) Passing the resolution to the server forces the selection logic  
to be on the server side, not the client. But that's not really  
sensible - if the server has multiple  resolution versions of a  
resource, such as an image, it should advertise them to the client  
and let the client choose. For example, at 1.5 UI scale factor, if  
the server has 3x and 2x images available the client could  
reasonably choose 2x (the next scale up) or 3x (since it is an  
integer multiple of the scale factor).




This is a valid issue, but perhaps it could be addressed in the  
proposal. Its better than the alternative of no non-css approach.  
However, keep in mind that In a purse CSS environment, the author  
doesn't take into consideration the processing needs off the client  
anymore than the server does. The CSS (written by the author) will  
determine which pixel dimension image the client gets).


This doesn't make sense with the way clients actually work. What  
you care about with images embedded in web content is the relative  
scale of CSS pixels relative to device pixels, which does not have  
any necessary direct relation to the physical DPI. You don't  
actually want to serve different images to different DPI screens if  
they are both running at the same scale factor.


I think you're saying the same thing in different language. Both Mac  
OS X and CSS were designed with resolution independence in mind. The  
distinction over devise pixels and CSS pixels merely muddies the  
issue. An image that's specified to be 4 inches square on a 96dpi  
display at 50% zoom is 192 pixels square (however you want to say  
it). Getting that pixel dimension image delivered form the server is  
what we're looking for (or perhaps a different pixel dimension if the  
client expects a resizing or immediate printing).



I think the whole design of it is wrong. It's based on DPI instead  
of scale factor, it pushes the decision to the server when it  
should be made on the client side, and it handles things at the  
HTTP level that should be (and indeed are) handled by CSS media  
queries.


I think you should take another look at it. Your objections don't  
really address the proposal.


Take care,
Rob
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Maciej Stachowiak]

On Jun 7, 2007, at 9:00 AM, Nicholas Shanks wrote:


Sorry,


Accept-Content: text/css, text/dsssl, text/xsl


should of course have referred to "Accept-Type"  :-)


Actually it should have been "Accept:". There is no Accept-Type header.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Maciej Stachowiak]

On Jun 7, 2007, at 6:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low- 
res artwork and CSS referring to such (background-image, and the  
like), depending on their screen pixels, printer resolution, etc.


I don't think it's a good idea to handle this at the HTTP level,  
because that requires server-side changes and approaches are possible  
which handle things purely on the client side.



I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


This is a bad idea for a number of reasons:

1) CSS already has media queries to select from multiple stylesheets  
in HTML/XML, or to select from multiple blocks in a single stylesheet.


2) DPI is not really the relevant factor to make the decision, what's  
important is the UI scale factor. If I'm running at 144 DPI but at 1x  
scale, I want the same images as at 72 dpi 1x scale.


3) Passing the resolution to the server forces the selection logic to  
be on the server side, not the client. But that's not really sensible  
- if the server has multiple  resolution versions of a resource, such  
as an image, it should advertise them to the client and let the client  
choose. For example, at 1.5 UI scale factor, if the server has 3x and  
2x images available the client could reasonably choose 2x (the next  
scale up) or 3x (since it is an integer multiple of the scale factor).





The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page  
zoom of 200% would request 233.33 dpi)


This doesn't make sense with the way clients actually work. What you  
care about with images embedded in web content is the relative scale  
of CSS pixels relative to device pixels, which does not have any  
necessary direct relation to the physical DPI. You don't actually want  
to serve different images to different DPI screens if they are both  
running at the same scale factor.





Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
"Content-Resolution: auto-adjust" header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.


• A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.



What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.


I think the whole design of it is wrong. It's based on DPI instead of  
scale factor, it pushes the decision to the server when it should be  
made on the client side, and it handles things at the HTTP level that  
should be (and indeed are) handled by CSS media queries.


Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

Sorry,


Accept-Content: text/css, text/dsssl, text/xsl


should of course have referred to "Accept-Type"  :-)

- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Rob Burns]

On Jun 7, 2007, at 8:27 AM, Nicholas Shanks wrote:

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low- 
res artwork and CSS referring to such (background-image, and the  
like), depending on their screen pixels, printer resolution, etc.

I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page  
zoom of 200% would request 233.33 dpi)



Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
"Content-Resolution: auto-adjust" header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.


• A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.



What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.




That's a responsive proposal process. Thanks for picking up on that.  
Let me just add a few of my own thoughts on how I think this should  
work.  Imagine three different clients all loading the same document  
over http. Also imagine that all dimensions are specified in physical  
dimensions (pixels complicate things and they're a moving target in  
terms of software interpretation)..


* The document includes an image with dimensions 6 inches by 4 inches.
* The clients are
- 1200 DPI printer printing via url request at 100% zoom
- Firefox on a 96dpi display at 67% zoom
- Safari on an iPhone with 160dpi display at 50% zoom


Each cleint calculates the resolution based on its current zoom (in  
other words base magnification) level (clients could get more  
sophisticated and request based on expected zoom level if it expects  
to change while displaying the image; but that should probably be  
left out of the spec). Following your suggestion, each client always  
rounds up to the next integer value and returns the pixel dimensions  
(both width and height). So for each client


- 4 inches at 100% on a 1200 dpi display equates to 4800 pixels
- 6 inches at 100% on a 1200 dpi display equates to 7200 pixels

- 4 inches at 67% on a 96 dpi display equates to 258 pixels
- 6 inches at 67% on a 96 dpi display equates to 386 pixels

- 4 inches at 50% on a 160 dpi display equates to 320 pixels
- 6 inches at 50% on a 160 dpi display equates to 480 pixels

Basically each client multiplies its device resolution by its base  
zoom level and returns its effective ppi resolution.


So I think the content negotiation should look more like (for the  
iPhone for example):


GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 80 ppi


So for resolution independence we want authors to specify dimensions  
in absolute (physical) units. However content negotiation of bitmap  
related content should be based on ppi. If the display is stretched  
in any way perhaps the protocol should allow for two ppi dimensions  
to reflect the different horizontal and vertical ppi resolutions.


Hope this is clear.

Take care,
Rob


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Accept- & Content-Resolution headers proposal

[Peter Speck]

Hi,


Accept-Resolution: 116.66 dpi
...
In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page  
zoom of 200% would request 233.33 dpi)


Why force a "next size up" if most UAs prefer a dpi which is "close  
enough"?


All the other Accept-XXX headers (except Accept-Ranges) uses a  
wildcard if other values are accepted, e.g. (RFC 2616)

  section 14.2:  Accept-Charset: iso-8859-5, *
  section 14.3:  Accept-Encoding: gzip, *
  section 14.4:  Accept-Language: da, en, *

All 3 supports adding a "quality value which represents the user's  
preference for that charset/...".  Could this be used to allow the UA  
to tell the server if it wants a "higher up" or "closest"?



I assume this would be used too when printing a web-page, so the  
printed output can use high-resultion images.  (I've implemented a  
page which uses high-resolution GIFs for icons, and it is a pita to  
maintain).


But how are the browser going to know which files it should re- 
request when printing the page? All, or only those with a "Content- 
Resolution"?


• A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.


As a web-server implementor, I would prefer keeping the standard as  
simple as possible (i.e. KISS), especially with options almost no  
browsers are going to use. Your scheme for selecting the proper css  
file works spendid with dpcm values converted to dpi.  If a webserver  
wants to support .css files named using dpcm, e.g. "default. 
30dpcm.css", that's fine, but don't make the protocol more complex.  
Continuing with this, I would remove "dpi" from the header value, and  
simply define both headers value to be dpi.



   - Peter Speck


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Your opinion on a CSS proposal

[Windy Road]

On 07/06/07, Mark Rowe <[EMAIL PROTECTED]> wrote:

> Anyone got any thoughts on how to deliver high resolution images to
> high DPI screens and low resolution images to low DPI screens.

 mentions using CSS 3's
media queries to target a portion of a stylesheet based on the devices
DPI.  See  for more
information.

On 07/06/07, David D. Kilzer <[EMAIL PROTECTED]> wrote:

Wasn't one of Hyatt's suggestions that the author of the web page provide
references to both a low-res and a high-res image so that the client

(which

knows most about which one to use) may chose the correct one?


Sorry guys, I should have been more specific.  David's reference to media
queried applies to background images, border images and the like (i.e design
constructs).  My question was in regards to img elements (jpgs, pngs, etc,
not svgs) and other types of non-textual content (movies, etc).

Cheers,

--
Tom Howard
http://windyroad.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Accept- & Content-Resolution headers proposal

[Nicholas Shanks]

It has been mentioned on the Safari WebKit development mailing list  
that a HTTP header which specified a document's target resolution  
would be useful to allow clients to negotiate for high-res or low-res  
artwork and CSS referring to such (background-image, and the like),  
depending on their screen pixels, printer resolution, etc.

I would like to propose this to the Working Group.
My ideas are as follows:


The client (a laptop, say) requests -

GET /style/default HTTP/1.2
Host: example.com
Accept-Content: text/css, text/dsssl, text/xsl
Accept-Resolution: 116.66 dpi


The server has the following to choose from:

default.72dpi.css
default.144dpi.css
default.288dpi.css
default.2400dpi.css


In this instance, the 144 DPI stylesheet would be returned, because  
it is the next size up, with a header:


Content-Resolution: 144 dpi

The client would thus know there was a resolution mis-match and  
(optionally) perform a correction on the CSS values.
(the mechanism assumes higher is better, and scaling down is  
preferable to scaling up from 72 dpi. Apple's iPhone has a screen  
resolution of 160dpi, and so would get the 288dpi stylesheet, even  
though the 144 is a closer match, and the laptop with a web page zoom  
of 200% would request 233.33 dpi)



Furthermore:

• Images served with a Content-Resolution header could have their  
resolution trusted (most web browsers today display one pixel on  
screen per pixel in the bitmap, and ignore the image's internal  
resolution parameter, if one exists). If they don't match, probably  
best to use the image's internal one. There could also be a special  
"Content-Resolution: auto-adjust" header meaning that the server  
doesn't know the resolution at content-negotiation time, but wants  
the client to scale it according to the image's internal value  
anyway, and not do a pixel-to-pixel mapping.


• A "dpcm" (dots per centimetre) parameter could also be understood  
by both ends and converted as necessary.



What do people think? I've only spent an hour or so pondering this,  
so it won't be bulletproof yet.


- Nicholas.

smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Your opinion on a CSS proposal

[Andre-John Mas]

Hi,

Is the idea to ensure that the image is displayed at about the same
size on both screens, or that less data is sent in the low-res
scenario?

One thing that should be noted is that the 'IMG' HTML tag has a 'LOWSRC'
attribute, which is intended for a low resolution version of the image,
but I don't think that ever made it into CSS.

If a low-res device happens to be a TV, then there is a media type 'tv'
which can be specified so the right CSS is used.

Just a quick look at CSS and I see that 'absolute' units are available
for specifying size, such as in, cm and mm. See:

http://htmlhelp.com/reference/css/units.html

Andre

On 7-Jun-07, at 01:35 , Windy Road wrote:


On 06/06/07, David D. Kilzer <[EMAIL PROTECTED]> wrote:

You may be interested in these blogs as well:

http://webkit.org/blog/55/high-dpi-web-sites/
http://webkit.org/blog/56/high-dpi-part-2/


Thanks for the heads up.  I did find them interesting.

Anyone got any thoughts on how to deliver high resolution images to
high DPI screens and low resolution images to low DPI screens.

Cheers,

--
Tom Howard
http://windyroad.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Your opinion on a CSS proposal

[Rob Burns]

On Jun 7, 2007, at 1:11 AM, David D. Kilzer wrote:

Wasn't one of Hyatt's suggestions that the author of the web page  
provide
references to both a low-res and a high-res image so that the  
client (which

knows most about which one to use) may chose the correct one?

Dave


That sounds familiar. However,  resolution specific content  
negotiation would be better supported through a rev to the http  
protocol. It could be done now with some javascripting or CSS media  
queries (for CSS urls anyway), but by adding it to http, it could  
just work with little effort on the author's or server admin's part.


Rob




Rob Burns <[EMAIL PROTECTED]> wrote:


Its not easy to do these days. In my opinion, this is one of the key
features needed for an HTTP  1.2 (along with event/change
notifications and a few other things). Apache can probably be
configured to do this, but I'm not sure that there's a way to easily
get the HTTP clients to request a particular resolution.

Take care,
Rob


On Jun 7, 2007, at 12:35 AM, Windy Road wrote:


On 06/06/07, David D. Kilzer <[EMAIL PROTECTED]> wrote:

You may be interested in these blogs as well:

http://webkit.org/blog/55/high-dpi-web-sites/
http://webkit.org/blog/56/high-dpi-part-2/


Thanks for the heads up.  I did find them interesting.

Anyone got any thoughts on how to deliver high resolution images to
high DPI screens and low resolution images to low DPI screens.

Cheers,

--
Tom Howard
http://windyroad.org






___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev