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