- From: Daniel W. Connolly <connolly@hal.com>
- Date: Tue, 29 Nov 1994 22:34:26 -0600
- To: Terry Allen <terry@ora.com>
- Cc: "Daniel W. Connolly" <connolly@hal.com>, www-html@www0.cern.ch, dsssl-lite@falch.no
In message <199411300027.QAA13804@rock>, Terry Allen writes: > >Suppose the mechanism by which you construct the style sheet (in >Panorama, a GUI) hid the process of giving the element an ID? In >your example, "tag abuse" solves the user's problem, but it won't >always, and a GUI-ID-inserter would give the user full access to >the style sheet's mechanisms. I'm not advocating it, just thinking. A successful GUI-based browser will completely obviate the need for this sort of hack. It will make maintaing stylesheets simple enough. >This could have potential if the syntax can be nailed down hard >and such things as the selection of units made standard. I really wouldn't mind if this stuff was haphazzardly specified. The point is that you can "skootch this paragraph down a little" without changing the structure of the document. Even if it's not completely portable across browsers, it's cool with me. >What if there's a mismatch? the PI says (space-before: 12pt) >but the element is inline markup (such as <EMPH>)? Well... I had originally thought that this technique would be just for inherited characteristics, but space-before: is a prime candidate, and it's not inherited. Since EMPH is inline markup (i.e. it's not a paragraph flow object), space-before: doesn't apply, and you lose. Ideally, you get a warning message. But since this is typically a manual edit-and-preview situation, failing silently isn't out of the question. > I suggest that >"error recovery" be discouraged for PIs in browsers, to avoid >"Mosaicization" of such PIs. I disagree. This mechanism is to address exactly the situation of "I want it to look just so on Mosaic" situation that currently motivates folks to change the _element structure_ of their documents. > I rather prefer >the pointing-to-IDs approach I'm sure most folks with a lot of experience with document management will use stylesheets with utmost discipline. They've been burned by inconsistent usage of Frame catalogs enough times to know better. But Joe Home Page that wants "a little more space, and skootch that over there" is the guy that's supposed to use this, rather than <h6> for font changes. > They might need a label: > <? DSSSL (space-before: 12pt)> Probably so. Good point. >In a more elaborate scheme the label might point to a nonadjacent >element: > <? DSSSL:child:2 (space-before: 12pt)> > <? DSSSL:child:3 (space-before: 12pt)> >or some such. I doubt browser implementors will go for this sort of thing. They'll argue for attributes or elements or some such HTML-specific technique. I'd like to keep it simple. >Another point to consider is verification. By their nature, >PIs can't be verified by SGML parsing (except to see that they >are well formed as SGML PIs). So an auxiliary tool would be >desirable that would test each labelled PI against a list of valid >commands, numbers, and units. I disagree. This is strictly a hack technique. "Use at your own risk." By using a processing instruction, you're admitting that this isn't essential to the information you're presenting. It just makes it look a little nicer. No need to get all anal retentive and start validating stuff. Dan
Received on Wednesday, 30 November 1994 05:34:57 UTC