W3C home > Mailing lists > Public > www-style@w3.org > June 2011

Re: [css3-fonts] mutiple formats in src descriptor

From: timeless <timeless@gmail.com>
Date: Wed, 1 Jun 2011 14:29:52 -0400
Message-ID: <BANLkTikN+m5KW-n1K0HEhO=6-3d-VR1fhQ@mail.gmail.com>
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:

GET /bar?stuff HTTP/1.1
Accept: application/x-opentype, application/x-intellifont

Content-Type: application/x-opentype
Vary: Accept, Cookie

GET /bar?stuff HTTP/1.1
Accept: application/x-intellifont, application/x-opentype

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

[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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:01 UTC