- From: Alan Karben <karben@interactive.wsj.com>
- Date: Fri, 18 Apr 1997 12:12:29 -0400
- To: www-style@w3.org
Todd Fahrner: >| > But seriously, given that CSS is clearly the next wave of client-side >| > style, couldn't DSSSL be deployed effectively on servers, or at "publish" >| > time, to generate HTML+CSS? At The Wall Street Journal Interactive Edition, that's essentially what we're doing (though not with DSSSL but with engines based on non-standard transformation languages). I'm convinced that authoring documents using SGML (or XML) with tags that model the *content* of what's being marked-up (i.e., <byline> and <company-name>), and then transforming at "publish" time, allows you to take most advantage of HTML + CSS + JavaScript. Authoring in SGML lets you naturally derive the HTML 'class' attributes, and add onMouseOver-type events where appropriate. And when our editors change their mind about output formats as new HTML/CSS/JavaScript/VB-Script/JSSS/DynamicHTML features come out, they speak in the vocabulary of "Let's make our company names do this now..." or "Let's make links to external web sites have a different color, and make the target show up in a new browser window...." These requests are then easily fielded. Also important to remember: The game has always been to make the content look as good as possible in the latest browser releases while maintaining a decent look for past generations back to Netscape 1.2. The resulting Tag Juggling can get pretty complicated -- and for all practical purposes well beyond hand-tagging and common HTML authoring tools. Paul Prescod: >| 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. It is important to >| remember though, that shipping dumbed-down documents over the web is >| second best. There's nothing wrong with shipping content in a formatting language, if basically all you want you folks to do with the information is read/link/print. It's only when you want to let them search, reorganize, reformat, or otherwise reuse the content *they've already downloaded* in ways you haven't imagined that makes HTML "second best." In other words, when you can't, or don't want to, make your *servers* do all the work. Todd Fahrner: >| > In short, is there a transition path from CSS to DSSSL, or is all lost >| > already? :^) The transition is to author now & forever using tags chosen for content, not presentation. Use any of a host of commercial or freeware transformation tools [1] to produce great looking HTML/CSS/etc when you want to reach the Browser 4.0 and below market, and XML/DSSSL/Java output if/when you want to offer readers features that a formatting language alone cannot offer. Paul Prescod: >| I'm not sure how these questions address that, but yes, there is a >| transition path from CSS to DSSSL. CSS goes into 4.0 level browsers, >| for use primarily with HTML ,and DSSSL goes into 5.0 level browsers >| for use primarily with XML. At one point I thought that there needed >| to be some relationship between CSS and DSSSL in order to have a >| migration path from one to the other, but now I ask: "why?" Use CSS >| when it is convenient (small,simple documents). Use DSSSL when it is >| convenient (large, complex, structurally marked up documents). Jon Bosak: >That's exactly where I ended up on this. CSS is simple and enables a >lot of functionality but is inherently incapable of handling the hard >cases; DSSSL can handle anything but is a bitch to learn. >Implementation is a wash. So let's use both. CSS is great for non-programmers to author in Notepad, and has the momentum of popular implementations. DSSSL is built cleanly from the ground up to transform and present SGML, but needs GUI tools before it is fit for widespread acceptance. I've always thought that DSSSL needed a 'standard' baby language, which would essentially give non-programmers an authoring tool (notepad) until better tools come on the market. Maybe CSS could be that language; then a lot of questions would be answered, as long as someone volunteered to write a CSS-to-DSSSL style sheet converter and promised to keep it current. Taking this point to an (admittedly unrealistic ;-) extreme, a browser implementer could just program for DSSSL, and as the CSS syntax gets pulled along for multicolumn layouts and other fancy stuff, could 'turn on' the "new" features right away. Kind of analogous to how SoftQuad offers a new HTML DTD plug-in for it's HoTMetaL engine, which at its core can handle any tag. Alan. [1] For links to info on SGML conversion tools, see: http://www.sil.org/sgml and http://www.falch.no/people/pepper/sgmltool/convert.htm <!-- Alan Karben Manager, Multimedia The Wall Street Journal Interactive Edition karben@interactive.wsj.com phone: 609 520 7361 http://wsj.com fax: 609 520 7137 -->
Received on Friday, 18 April 1997 12:10:47 UTC