- From: Todd Fahrner <todd@verso.com>
- Date: Thu, 17 Apr 1997 15:23:04 -0700 (PDT)
- To: Paul Prescod <papresco@calum.csclub.uwaterloo.ca>
- Cc: www-style@w3.org
At 8:29 PM -0400 4/16/97, Paul Prescod wrote: > Let be clear: most SGML users would NOT advocate an <initialpara> tag in > an SGML DTD! I think the case for such was in fact a case for "<intro>" or something similar. > DSSSL has been deployed to generate HTML (in Jade -- I have built a > whole website this way), and Jade will generate HTML+CSS as soon as CSS > is supported in a standard way by major browsers. I am very interested to see how this works. > It is important to > remember though, that shipping dumbed-down documents over the web is > second best. In the most general case, sure. But in particular situations (currently predominant), shipping "smart" documents is not such a nifty idea, as when a large part of the intended readership might not be equipped to enjoy the smarts, or even to access the documents at all, much less to re-use the data as such. For operations of any significant scale, however, I will be interested in XML+DSSSL as document design and management tools, if not initially as final publication formats. > > Should we really be dealing in pixels anymore? > Don't we want styles to be portable across displays? I understand the downside very well. Points and picas, however, are grossly misinterpreted across platforms for display at least, so they're not useful here. If a UA's pixel density were very far from the 90 dpi reference, or the reader's eyesight were poor, however, I would expect the UA stylesheet to override my specification. This is one meaning of cascading, no? In the meantime, a particular rasterization for type is more important than a nominal size in determining its character, legibility, etc. Consider the case where word-images must maintain a consistent visual relation to (bitmap) images. As soon as UAs and hardware will allow for bicubic interpolation on variable-size images to keep in synch with variable-size type, I'll stop wanting to specify pixels. > > Percentages or rendering area (width and height)? > > I believe that those would have to be added. I can't find anything that > would indicate that they are available in DSSSL-Print or DSSSL-Lite. > That extension for online is about to begin. It is part of the XML > effort. This is essential for preserving typographical grids in areas of varying aspect. (By grids I mean divisions of the canvas into harmonic units, like 3x4, not graph paper). CSS is weak in this area, but without percentage units (on the horizontal) it wouldn't go anywhere at all. > I'm not sure if there is a CSS analogue to cascading! I haven't yet seen > this idea put in practice, with the many obvious kinks (oops! black on > black!) worked out. Once we understand this, it could probably be > incorporated into DSSSL, but right now it looks to me like a nice idea > that wasn't practical. The stylesheet author MUST provide a list of > reasonable alternatives: either as options or as separate style sheets. The "@media" selector proposed in the CSS Printing Extensions WD could be generalized to accommodate multiple stylesheets on a single document based on rendering environment variables, including reader needs/preferences. So, for example, you could go from one- to two-column layout as the rendering area (say the browser window) went from portrait to landscape aspect, all without a lick of scripting or other non-declarative stuff. (if only css could accommodate multi-column layout....) > > or to multiple choices for, say, fonts? > > That is done through definitions at the beginning of the specification. > On the dssslist, we have started work on a DTD that will allow WYSIWYG > editors (or browsers) to load DSSSL style sheets and provide the most > salient choices to the user: "This stylesheet allows the font to be > changed to one of these options, the margins to be scaled from 0 to 2 > inches and offers three different colour schemes." As a matter of taste, I'd class this with "click here for the shockwave version" at the index page. Draws too much attention to the machinery. Cascading aspires to transparency, at least. > I feel that this is a > much more workable solution than ad hoc combinations of user stylesheets > and author stylesheets that were not designed to work together. I share your suspicions about the practicality of cascading, but I'm still optimistic. A really good implementation and a large body of test cases will deliver a convincing answer, I think. We don't have either yet. > I am planning on creating flow > objects for 3D display as part of a project I am doing. keWl. blinking 3D? :^) __________________ Todd Fahrner http://www.verso.com
Received on Thursday, 17 April 1997 18:39:08 UTC