W3C home > Mailing lists > Public > www-font@w3.org > July to September 2009

Re: EOT-Lite File Format

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 31 Jul 2009 08:21:01 -0500
Message-ID: <dd0fbad0907310621x4f508bbfgee6bf98b678469e7@mail.gmail.com>
To: Thomas Lord <lord@emf.net>
Cc: Sylvain Galineau <sylvaing@microsoft.com>, www-font <www-font@w3.org>
On Thu, Jul 30, 2009 at 10:01 PM, Thomas Lord<lord@emf.net> wrote:
> On Thu, 2009-07-30 at 21:53 -0500, Tab Atkins Jr. wrote:
>> On Thu, Jul 30, 2009 at 9:45 PM, Thomas Lord<lord@emf.net> wrote:
>> > On Fri, 2009-07-31 at 02:06 +0000, Sylvain Galineau wrote:
>> >> >The EOTL proposal says "is not loaded" if the
>> >> >root string is non-nil.  That's a rootstring check.
>> >> >It is very distinct from ignoring the rootstring,
>> >> >at least as stated.
>> >>
>> >> The proposal is here.
>> >>
>> >> http://lists.w3.org/Archives/Public/www-font/2009JulSep/0780.html
>> >>
>> >> There is no rootstring check.
>> >>
>> >> The header version proposed in the latest amendment has no rootstring.
>> >>
>> >> Last chance.
>> >
>> >
>> > I'm confused because on the one hand you say there is
>> > no rootstring and on the other you say that EULAs might
>> > require the rootstring to be set so that older versions
>> > of IE enforce a simulacrum of appropriate origin restrictions.
>> >
>> > I would like a clear, positive statement that the intent
>> > here is that a UA may come across a font file which
>> > contains a non-nil root string, where that root string
>> > does not match the URL of the page linking to that font, and that
>> > the UA may then go ahead and render with that font anyway
>> > without, in doing so, being non-conforming.  This behavior
>> > of a UA should not only be permissible, but suggested ("SHOULD").
>> A conforming UA MUST ignore the rootstring.  Phrased probably a little
>> better it MUST treat certain parts of the header (specified precisely
>> by people who know the details a little better than me, informally
>> being everything that isn't explicitly checked) as meaningless padding
>> and MUST NOT take any action based on information from those sections
>> of the header.
> As I said, you are braver than I am in that regard.
> My thought was SHOULD rather than MUST so that older
> IE gets retroactive conformance (else what's the point
> of EOT-lite at all?).

The point of EOTL was never to be conformant with IE<=8.  It was to be
*compatible* with IE<=8.  That's probably a better way to put my
"technical"/"actual" conformance distinction I made previously.

IE<=8 do not conform to the EOTL spec.  They never will.  In order for
them to do so, we'd have to implement plain EOT.  Those browsers are
*compatible* with the EOTL spec, in that they will consume EOTL files
authored according to the guidelines without complaining.  If you want
to exploit browser hacks to get some slightly different behavior out
of IE<=8, that's on your head.

That's exactly the same situation I, an author, am in when I use the *
hack to elicit special CSS behavior from legacy IEs that is ignored by
a good, compliant browser.  I'm utilizing knowledge of browser hacks
to author invalid CSS that is nevertheless guaranteed to work
correctly by compliant browsers, but has a special known affect in
certain non-compliant ones.

Are you arguing that every spec that can be circumvented via browser
hacks should be thrown out?

Received on Friday, 31 July 2009 13:21:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:01:40 UTC