- From: Håkon Wium Lie <howcome@opera.com>
- Date: Mon, 1 May 2006 16:02:12 +0200
- To: Steve Zilles <szilles@adobe.com>
- Cc: www-style@w3.org, www-html@w3.org, www-font@w3.org
Also sprach Steve Zilles:
> >The CSS specification can not and should not require support for any
> >specific formats. Further, CSS cannot make rules about how to
> >interpret other formats. CSS cannot demand support for JPEG and
> >certainly cannot specify how to interpret the EXIF bits in JPEG. So,
> >while I'd personally insist that Opera respects the embedding bits of
> >Truetype, the CSS specification cannot do so. This is the job of the
> >TrueType specification [1].
> >
> >[1] that is, the fsType field in the OS/2 table, as described at
> > http://www.microsoft.com/typography/otspec/os2.htm
>
> The role of the TrueType or OpenType specification is indeed to define what
> its contents mean. It is, however, perfectly within the scope of the CSS
> standard to (a) define what formats can be used with CSS and (b) for each
> of those identified formats to define what conformance means for a CSS UA.
> So, the CSS specification could say that, "a conforming CSS UA must respect
> any usage information included in the fonts used to display content styled
> with CSS." That does not limit what formats can be used, it simply says
> that a UA does not conform to the CSS specification if it does not respect
> the DRM information. (Note that the font format in question must define
> what "respecting the DRM information" means for that font format.)
>
> Note that it is important to separate what CAN be said in the specification
> (what mechanisms can be documented) versus what SHOULD be said in the
> specification (what policies should be advocated). My comments in the
> paragraph above are intended solely to say what CAN be said.
You're right. W3C Recommendations CAN say whatever W3C members want
them to say. They CAN require UAs to respect usage information, just
as much as they CAN require UAa to NOT respect usage information.
I would, however, argue that making binding statements about other
specifications is something W3C Recommendations shouldn't do and that
there is a long-standing principle to avoid it. It's no accident that
HTML doesn't specify which image formats a UA must support. In the GIF
vs. PNG wars, it was tempting to require HTML UAs to support the PNG
format. After all, PNG was the first W3C Recommendation and it could
need some help from HTML (the fifth W3C Rec). Still, HTML 3.2 refers
to image formats in non-binding manner:
"for instance a GIF, JPEG or PNG image file" [1]
HTML 4.01 is equally non-commited:
"Examples of widely recognized image formats include GIF, JPEG, and
PNG." [2]
Likewise, CSS and other W3C Recs have been non-commited in the past.
I think the priciple of specification independence, as far as
possible, is important. There are several reasons:
- it makes specifications simpler to implement; simplicity is good
- it makes specifications more reusable; you can reuse a
specification in new contexts without dragging along a bunch of
other specs
- it makes specifications prove their worth in the market. I believe
in specificational Darwinsim. If a specification can't survivive on
its own, perhaps it shouldn't. PNG proved its own worth, and so did
TrueType. However, if we accept the idea that one specification can
require support for another, it might tempting to rescue a
failing format by requiring support for it.
[1] http://www.w3.org/TR/REC-html32-19970114
[2] http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.2
-h&kon
Håkon Wium Lie CTO °þe®ª
howcome@opera.com http://people.opera.com/howcome
> Separately, I am also arguing that such a statement SHOULD be made, but
> that is, as I well understand, a point of debate. I have given my reasons
> why I think the specification should have a conformance requirement on font
> usage; I would be interested in the reasons why people think it should not
> have such a requirement. (Saying CSS cannot say such things is not such a
> reason.)
>
> I, of course, also recognize that people may wish to build and distribute
> UA's that do not respect DRM information and, therefore, do not conform as
> proposed above, but my main argument is that many important users will want
> to use UA's that do conform and protect them from allegations of misuse
> (either inadvertent or intentional).
>
> Steve
> =====================================
> Steve Zilles
> 115 Lansberry Court,
> Los Gatos, CA 95032-4710
> steve@zilles.org <html>
> <body>
> At 02:42 AM 4/27/2006, Håkon Wium Lie wrote:<br>
> <blockquote type=cite class=cite cite="">Also sprach Steve
> Zilles:<br><br>
> > The DRM bits are not "protection measures"; they are
> usage information. It <br>
> > tis the User Agents that have an obligation to implement
> correct usage so <br>
> > that the user of the UA does not have to concern himself with
> the rules and <br>
> > can count on his UA to do the right thing for him.<br><br>
> To clarify: do you refer to the embedding bits of TrueType/OpenType<br>
> [1] as DRM? The way I understand the term "DRM", it should have
> an<br>
> "active" component, one that shuts off access when it smells
> something<br>
> abnormal.</blockquote><br>
> Yes, as you note in your excerpt below I do support requiring UA's to
> interpret and obey the bits.<br><br>
> <br>
> <blockquote type=cite class=cite cite=""> > Having the CSS
> specification require that UA's implement detection of and <br>
> > correct respect for the DRM information is a proper and
> correct function of <br>
> > the specification.<br><br>
> The CSS specification can not and should not require support for any<br>
> specific formats. Further, CSS cannot make rules about how to<br>
> interpret other formats. CSS cannot demand support for JPEG and<br>
> certainly cannot specify how to interpret the EXIF bits in JPEG. So,<br>
> while I'd personally insist that Opera respects the embedding bits
> of<br>
> Truetype, the CSS specification cannot do so. This is the job of the<br>
> TrueType specification [1].<br><br>
> [1] that is, the fsType field in the OS/2 table, as described at <br>
>
> <a href="http://www.microsoft.com/typography/otspec/os2.htm" eudora="autourl">
> http://www.microsoft.com/typography/otspec/os2.htm</a></blockquote><br>
> The role of the TrueType or OpenType specification is indeed to define
> what its contents mean. It is, however, perfectly within the scope of the
> CSS standard to (a) define what formats can be used with CSS and (b) for
> each of those identified formats to define what conformance means for a
> CSS UA. So, the CSS specification could say that, "a conforming CSS
> UA must respect any usage information included in the fonts used to
> display content styled with CSS." That does not limit what formats
> can be used, it simply says that a UA does not conform to the CSS
> specification if it does not respect the DRM information. (Note that the
> font format in question must define what "respecting the DRM
> information" means for that font format.)<br><br>
> Note that it is important to separate what CAN be said in the
> specification (what mechanisms can be documented) versus what SHOULD be
> said in the specification (what policies should be advocated). My
> comments in the paragraph above are intended solely to say what CAN be
> said. <br><br>
> Separately, I am also arguing that such a statement SHOULD be made, but
> that is, as I well understand, a point of debate. I have given my reasons
> why I think the specification should have a conformance requirement on
> font usage; I would be interested in the reasons why people think it
> should not have such a requirement. (Saying CSS cannot say such things is
> not such a reason.)<br><br>
> I, of course, also recognize that people may wish to build and distribute
> UA's that do not respect DRM information and, therefore, do not conform
> as proposed above, but my main argument is that many important users will
> want to use UA's that do conform and protect them from allegations of
> misuse (either inadvertent or intentional).<br>
> <x-sigsep><p></x-sigsep>
> <b><x-tab> </x-tab>
> Steve<br>
> =====================================<br>
> Steve Zilles <br>
> </b>115 Lansberry Court, <br>
> Los Gatos, CA 95032-4710<br>
> steve@zilles.org</body>
> </html>
Received on Monday, 1 May 2006 14:02:40 UTC