Re: FW: EOT-Lite File Format

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)?

Do IE 6/7/8 implement EOT-with-rootstrings or EOTC or 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.)

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


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.

(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.)

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 4 August 2009 17:42:46 UTC