Date: Fri, 2 Dec 94 16:28:38 GMT From: firstname.lastname@example.org (Paul Grosso) Message-Id: <9412021628.AA25458@texcel.no.texcel.no> To: email@example.com Subject: Re: Processing instructions for style tweaks? Cc: firstname.lastname@example.org, email@example.com Of course, we are agreeing about most things: we agree that one should generally separate basic information content from (especially "ad hoc") presentation information, and yet we also agree that authors do need some flexibility to specify formatting info sometimes. > Subject: Re: Processing instructions for style tweaks? > To: Paul Grosso <firstname.lastname@example.org> > Date: Thu, 1 Dec 1994 16:32:15 -0500 (EST) > From: Murray Maloney <email@example.com> > > > From Paul Grosso <firstname.lastname@example.org> > > > > The advantage of using PIs for formatting-specific markup is that it's > > easy to strip/ignore them when one wants to slough off the "pollution" > > of embedded format-specific information. > > But that is also true of attributes. The advantage of attributes > is that they can be parsed and verified as conforming by > an SGML parser and by an application, but the application > can choose to ignore them. > > . . . > > So, what I was hoping is that we could define a few sets > of attributes (attribute architectural forms) that could > be attached to elements to provide for formatting control > at the element level. > . . . > I don't think we're talking about quite the same thing. Of course, if you have attributes that distinguish among your classes of elements, you can assign different styles to the different classes via your style sheets--and that's all architectural forms is doing. I agree that's a good thing to do. But I don't think that is addressing the problem. If it *is*, then fine, by all means, let's add the necessary attributes to the DTD and be done with it and forget about PIs, and I'm all behind you. But that's not what I'm hearing. The problem I thought that needed a solution was the less predictable "I need to do something different for *this* element, and I don't already have something in my DTD that allows me to distinguish this element from others (other than the ID method which for whatever reason I'm not willing to use)." Like, I want *this paragraph* to have a different indent than all the other types of paragraphs I have attributes/architectural forms for. So, I need to be able--without changing the DTD!--to give this paragraph some distinction that can be keyed in on by the style sheet's "element class distinguisher" (aka the "location model" or "qualified gi") so that I can, effectively, create a new class of paragraphs (that will, perhaps, only have this one paragraph in it) on the fly and then define the style I want for it using the SAME style sheet language as all other style sheets. > > With PIs, I can just strip everything of the form <?DL...>, or if my > > software handles it, just say "write -nopi" and get a depolluted > > version of the SGML. And, if I send the SGML--PIs and all--to another > > conforming SGML system that hasn't been programmed to do anything > > special with <?DL...> PIs, 'no harm, no foul,' it just works and the > > PIs are ignored. > > Right. And with attributes you can simply ignore them. > Or you can ignore them selectively according to the > user's wishes -- as specified via a dialog. No harm, no foul. > The big difference is that you don't have to use a special > filter or paser to ignore attributes, and you do have a > syntax that is verifiable by an SGML parser. > > By definition, PIs are ignored by applications that don't understand them. How much easier can you make ignoring them? > > Finally, using formatting elements doesn't solve many of the problems > > because they either can't be used everywhere one might want, or their > > content models have to be so lax as to destroy the structure of the > > original DTD. PIs don't have to drastically change the ESIS tree of > > the document. > > I am not in favor of a proliferation of formatting tags. > I am in favor of using attributes to associate formatting > with an HTML/SGML element. You already can use attributes to associate formatting with an element. That's a basic part of DSSSL Lite (and FOSIs and other style sheets). If you've got the attribute or can add it to your DTD, that is definitely the way to go. PIs should not be used to distinguish a structure that can already be distinguished using information (elements and attributes) in the DTD. But, as I've said above, I'm hearing that this won't always do. > > Finally, I have some practical issues with PIs. > > -- We cannot define a DTD for PIs in an HTML document. > So, we'll have the same mess we had with HTML before > Dan started his effort to write a spec. Nobody will > know for sure and there won't be any way to verify > it except for the "Mosaic test". Heaven forfend! I don't think this is quite true. I suggested a format for PIs in my other message that, if followed, would always make them "parsable." The result would be a name (the PIs "gi") and optionally some attribute specification. If the name (or names of the attributes) aren't to be found in the style sheet [by this I mean the result of merging all style sheets for this doc], then nothing is done, and this seems fine. If the name is found, then how it affects the format is specified in the style sheet using the exact same form as for the style of DTD elements. > > -- Placing PIs before and/or after elements will force > applications to save formatting instructions until > the next element is encountered or to look ahead > in case there are formatting instructions coming. > > I am not a browser implementor, but I don't think > that that is clean. In fact, I think that it is > unnecesarily complex and will discourage browser > developers from implementing this functionality. No! If you use PIs like I'm suggesting, they just give you another "handle" into the style sheet. The formatting instructions come from the style sheet just like for elements. In fact, the application can probably treat them exactly like elements as far as formatting. > -- Forcing authors of HTML documents to learn another > language syntax to include their formatting hints > will discourage them from doing so. > No, they don't have to learn something different--that's the point of my suggestion. The formatting attached to the PI is *in the style sheet* and uses the *same* language as elements. If you had a DTD element called <foo> that allowed you to markup all bits of your document to which you wanted to associate the style of "12pt serifed italic caps/small caps", you would mark up you document using <foo>the appropriate text</foo> and you would put an entry in your style sheet with qualified-gi=foo and whose contents sets up the font as desired. Now, if you didn't have that element, but you had an <emphasis> element with an attribute that could have 12 different values, you can mark up your document using <emphasis specialclass=type8>the appropriate text</emphasis> and you would put an entry in your style sheet with qualified-gi=emphasis and whose constructor picked out those <emphasis> elements with the specialclass attribute set to type8 and set up the entry to indicate the necessary font. But finally, if you've already used up all of those 12 values to map to something else--or if the <emphasis> element wouldn't be allowed in the context where you want to do this font change--then you could mark up your document using <?DL foo>the appropriate text<?DL /foo> and you would put an entry in your style sheet with qualified-pi=foo and whose contents sets up the font as desired [in my example, I just used "qualified-pi" instead of "qualified-gi" as earlier]. The style sheet entry for the PI=foo and for the ELEMENT=foo would be IDENTICAL.