Re: FW: EOT-Lite File Format

On Tue, Aug 4, 2009 at 12:41 PM, Anton Prowse<prowse@moonhenge.net> wrote:
> Tab Atkins Jr. wrote:
>>
>> The take-away point is that there is no compatibility difference
>> between the EOTL1.1/EOTC pair and EOTLwrip/EOT-with-rootstrings pair.
>> It's merely a question of whether the benefit of supporting EOTLwrip
>> (you can embed a rootstring in the padding, simulating same-origin
>> restrictions in nonconformant legacy IEs) is worth the possible
>> penalty (some people believe it may still open browsers up to
>> liability, though several have argued the opposite).
>>
>
> Thanks; that was exactly the clarification I was looking for.
>
> Presumably an EOTC file is necessarily an EOT-with-rootstrings file (it's
> just that the rootstring happens to be null)?

Not quite - the EOTC format has no rootstring area at all (see the
specification at http://www.w3.org/Submission/EOT/#Version1, and
compare it with the two format specifications following it, which are
EOT-with-rootstring versions).

> Do IE 6/7/8 implement EOT-with-rootstrings or EOTC or both?

Both.

> If both, then
> presumably there are no EOT implementations which are EOTC-only, and nor are
> any such implementations likely to appear in future given that there is no
> publicly-available specification for EOTC (as opposed to
> EOT-with-rootstrings.)

There is a publicly available spec (at the link provided above), but
it seems unlikely that an EOTC-only parser will exist, at least in a
common form.

> If EOTC-only implementations exist, do they render EOT+rootstrings files?

I don't believe there are any such implementations.  No common browser
is one, at least.

> So, if I understand correctly, neither EOTL1.1-compliant implementations nor
> EOTLwrip-compliant implementations can prevent "breakage" in a site which
> currently employs EOT+rootstrings (unless they also happen to implement
> either or both of the EOT formats), since an EOT+rootstrings file is an
> invalid EOTL1.1 file due to the non-null value of the rootstring field,
> whilst EOTLwrip-compliant implementations are required to "reject" the file
> (based on an embedded version number that all existing EOT+rootstrings files
> will have) despite the file format itself being /structurally/ compatible
> with EOTLwrip.

Yes, with the correction on why the EOTL1.1 file breaks.

> (Not that such "breakage" should concern us overly, seeing as this is no
> different from the current situation in which there are only a few EOT
> implementations, all of which intend to continue supporting EOT alongside
> any future EOTL format.)

Agreed.

~TJ

Received on Tuesday, 4 August 2009 18:10:05 UTC