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

2007-06-07 Thread Mark Rowe


On 07/06/2007, at 3:35 PM, 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.


http://webkit.org/blog/55/high-dpi-web-sites/ mentions using CSS 3's  
media queries to target a portion of a stylesheet based on the devices  
DPI.  See http://www.w3.org/TR/css3-mediaqueries/ for more  
information.


- Mark

___
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

2007-06-07 Thread 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.

http://webkit.org/blog/55/high
-dpi-web-sites/ mentions using CSS 3's
media queries to target a portion of a stylesheet based on the devices
DPI.  See http://www.w3.org/TR/css3-mediaqueries/ 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


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

2007-06-07 Thread 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

2007-06-07 Thread 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

2007-06-07 Thread 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

2007-06-07 Thread 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 img. 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

2007-06-07 Thread 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

2007-06-07 Thread 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

2007-06-07 Thread 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