Dan writes:
[ some stuff, thoughtful as usual, deleted ]
| II. The need to make individual documents "look right." I see lots
| of noise like:
[ ... ]
| It's a shame that folks compromise the structural integrity of their
| documents to convince Mosaic to display documents the way they'd like.
| It discourages folks from, for example, developing tools to build a
| table of contents out of the <Hn> tags in HTML documents, since those
| tags are used for font changes, rather than to mark headers.
| But presentation _is_ important.
| And even when (not if) some sort of stylesheet mechanism gets deployed,
| do you think somebody's going to:
| * give an element an ID and construct a stylesheet that gives
| the element with that Id a little more space, and maintain
| the association between the document and the stylesheet
| or
| * add a <p> tag before the element
| Yup. Thought so.
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.
| So what if we gave folks an option that's as simple as adding a <p>
| tag, but doesn't affect the structure of their document at all?
| What if we support little bits of DSSSL inside processing instructions,
| ala:
| <ul>
| <? (space-before: 12pt) >
| <li> xlkjdlfkj
| <li> ablkjasdf
| </ul>
This could have potential if the syntax can be nailed down hard
and such things as the selection of units made standard.
| This has the following features:
|
| * It's simple to maintain
that's to be seen
| * It's independent of the DTD. You could use it in HTML, HTML+,
| DocBook, etc.
yes, a great selling point
| * The semantics can be defined in terms of DSSSL, a (draft)
| international standard with zillions of person-years of
| work behind it
it's the value of the input that counts, not DSSSL's ISOness. After
all, look at SGML.
| (if a different stylesheet mechanism gets deployed, the same
| sort of thing should work. But DSSSL-Lite seems as good
| as any right now.)
| * It doesn't affect the structure of the document
best of all
| When you get to the point that there are so many processing
| instructions in there that it ceases to be "simple to maintain," you
| have the option of creating a suitable stylesheet.
So SGML editors should have a mode for deletion, even global
deletion, of PIs with certain characteristics.
| The only tricky thing is to decide what the scope of a given
| processing instruction is. I propose that processing instructions go
| right before start tags, and their scope of influence is the element
| that the tag starts. In other words,
What if there's a mismatch? the PI says (space-before: 12pt)
but the element is inline markup (such as <EMPH>)? I suggest that
"error recovery" be discouraged for PIs in browsers, to avoid
"Mosaicization" of such PIs.
| <? (characteristic: value ...)> <tag> ...
| has the same effect as
| <tag id=xxx123> ...
| with a declaration like this added to the stylesheet:
| (id xxx123
| (sequence
| characteristic: value
| ...
| (process-children)
| ))
| Well, there might be some kinks to work out, but you get the idea.
| Does this seem like a good idea?
A very good one, Dan. Given your last example, I rather prefer
the pointing-to-IDs approach, but it is appealing to have a way
to standardize PIs. They might need a label:
<? DSSSL (space-before: 12pt)>
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.
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.
And one also wants to be able to have multiple sets of such PIs
to work with multiple presentations ("normal" vs large type,
for example). so then one wants version numbers or something
similar inside the PIs, too. Gets into the kinds of problems
we all have heard about with the various parts of a URL, but
it's doable. (Still, that consideration kinda persuades me
to the pointing-to-IDs approach.)
Anyway, yes, a really neat idea, Dan.
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 103A Morris St. Sebastopol, Calif., 95472 A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html