- 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:36 UTC