- From: timeless <timeless@gmail.com>
- Date: Wed, 1 Jun 2011 14:29:52 -0400
- To: John Daggett <jdaggett@mozilla.com>
- Cc: Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style@w3.org
On Thu, May 26, 2011 at 2:26 AM, John Daggett <jdaggett@mozilla.com> wrote: > The original working in the old CSS2 spec [1] gives an example: > >> src: url("http://cgi-bin/bar?stuff") format("opentype", "intellifont") >> a full URI, in this case to a script, which can generate two >> different formats - OpenType and Intellifont > > I'm not quite sure how this was supposed to work (based on what > information does the server generate one format or the other?). HTTP has support for negotiation [1]... Technically this could have worked as: --Send: GET /bar?stuff HTTP/1.1 Accept: application/x-opentype, application/x-intellifont --Receive: Content-Type: application/x-opentype Vary: Accept, Cookie ... --Send: GET /bar?stuff HTTP/1.1 Accept: application/x-intellifont, application/x-opentype --Receive: Content-Type: application/x-intellifont Vary: Accept, Cookie ... or something like that. The script is free to use whatever it feels like to decide which format to provide, in the examples above the client used HTTP [2] Accept (14.1 Accept) to indicate preference. The script would be encouraged to use sane inputs (Accept, Cookie [2]) to make that determination and it's encouraged to indicate which inputs it used in its HTTP [2] Vary (14.44 Vary) response. Note that I'm not advocating keeping the feature you're discussing, merely offering an explanation of how it presumably was intended to work. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html [3] http://tools.ietf.org/html/rfc2109
Received on Wednesday, 1 June 2011 18:30:19 UTC