Hi list.
I recently emailed a few indie font developers to get their opinions
on EOT and @font-face. Here's the first response worth reading on the
matter. Ray has given permission for his comments to be distributed to
any interested browser developers.
— Nicholas Shanks.
Content-Type header,
so will probably appear as high‐byte Latin-1 or invalid UTF−8
diamonds, depending on the user's default encoding. Needless to say
neither will work with find‐in‐page or copy & paste.
— Nicholas Shanks.
smime.p7s
Desc
ich states that the order the fonts are listed
is the order that they have to be used.
You can also use the fact that internet explorer ignores any src value
with a format() specifier.
src: url(font.ttf) format(truetype), url(font.eot);
— Nicholas Shanks.
smime.p7s
Description: S/MIME cry
I think someone should land these even if the fork is dead, so that
anyone looking at the code in future (perhaps contemplating a similar
port) won't have as many bugs to consider.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic sign
On 30 Nov 2007, at 00:27, Maciej Stachowiak wrote:
• Support for the navigation elements in HTML headers and an
API to be exposed with Safari implementation.
The DOM API is sufficient for WebKit clients to implement this if
they choose to.
Well that could lead to incompatible or buggy im
On 29 Nov 2007, at 10:56, Maciej Stachowiak wrote:
We may post more details about some of these soon. I'm curious what
is of interest to other WebKit contributors. I'm especially
interested in areas where particular organizations or individuals
might be interested in directly contributing.
Hi Peter.
I recommend you take a look at what Larry Masinter pointed out. It
becomes clear that all of this has already been solved 9 years ago,
but because it (apparently) isn't enabled in Apache by default, I and
many others never even realised it existed:
Content negotiation for HTTP
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
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
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 eithe
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
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
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
Nice. You may also want to mention accessibility, public advocacy
(i.e. to web devs) and a high degree of visual polish (e.g. anti-
aliasing), though the latter may come under "platform-native HI
conventions".
You may also consider sorting them into priority groups or an ordered
list. I re
On 9 May 2007, at 07:32, Maciej Stachowiak wrote:
I propose we create a branch where feature work, as well as non-
critical compliance, compatibility and performance work can go.
I for one would welcome such a development, as I would be able to
resume the patches supporting CSS font-weight a
On 5 May 2007, at 00:02, Maciej Stachowiak wrote:
We'd prefer not to have GPL code the repository. I think for green,
red and amber images, recreating them is best.
Or output inline SVG instead.
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
___
16 matches
Mail list logo
