Date: Tue, 29 Nov 1994 19:37:04 -0500 From: Wilfredo Sanchez <email@example.com> Message-Id: <9411300037.AA02055@dill.lcs.mit.edu> To: firstname.lastname@example.org Cc: email@example.com In-Reply-To: <9411292338.AA08400@ulua.hal.com> (firstname.lastname@example.org) Subject: Re: Processing instructions for style tweaks? | 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. Very true. Definately. | But presentation _is_ important. Also true. This is difficult, however, if you want to give the browser room to think, which is also important... | What if we support little bits of DSSSL inside processing instructions, | ala: | | <ul> | <? (space-before: 12pt) > | <li> xlkjdlfkj | <li> ablkjasdf | </ul> | | <dl> | <? (font-weight: 'bold font-size: 14pt)> <!-- get the right font --> | <dt>Slug | <dd> explanation | </dl> Well, you're syntax is a little awkward, but that's not important... Problem: you say '12pt'. Bad. Already loosing. Part of the whole motivation behind a content-based, rather than a formatting-based markup language is to leave as much of this responsibility to the browser, and the readers customizations to the browser. Part of the problem with the push that Netscape is making is that it deteriorates this purpose. Tags like <blink> are completely formatting and say nothing about the meaning of the content. So we don't want things like '12pt'. It's too restrictive. I'm OK with the idea of giving the browser hints as to how to show things, so this might be a little smarter: <em size="+1"> So the browser knows that for some unkown reason you want the font to become a bit bigger, *realative to the current size*. Maybe that means increasing by 1 point for +1, 2 points for +2, etc, or maybe that means something else. Exactly what the number means may depend, sort of like <Hn> implies different sizes on different browsers. This is still not optimal. Better, because if I set my font size to 34pt by default (I'm viewing on my HDTV set and sitting far away), then you attempt to make things bigger by "increasing" the point to 18 will loose, and "+1" will always mean bigger. But the problem remains that the browser does not know *why* you want it bigger. So let's be smarter. We have some smart tags like <Hn> to mean "this is a header, you probably should make it big, but maybe you have a better idea..." Say we add more smart tags. Let's make <img> smarter, for example. People do this a lot: <img src="beach.gif"><br> <h5>Day at the beach</h5> This is nice, because it puts small print under the photo, sort of a caption. Of course, <Hn> means header, not caption. So let's fix it. <img src="beach.gif" caption="Day at the beach"> Much better. Now the browser knows what you mean. It can even do cool things like draw a box around the photo and the cpation, like in a newspaper, or embed the text into the photo, whatever. Yep. Better. And we can keep on going... Hmmm... Well, there's an awful lot of different things to add. Captions, chapters, footnotes, appedixes, poetry, ... They're all kind of different and a browser may want to render each such thing in it's own way. We run into a scalability problem: 1) The damn spec is getting huge 2) A really good browser is REALLY hard to write 3) The poor document writer has to remeber all these crazy tags So there's a good question... Do we expect the number of different styles to be finite and not too much to manage? If not, what the next smartest thing? Style sheets might be... I don't know. The problem is that Mosaic and other browsers are already out. The world is writing HTML in a broken way. So it's impossible to write a smart browser, because most documents will only confuse it, as the example with headers - you can't make a table of contents based on headers, becuase not everyone uses headers as headers. People do this instead: <h3> <ul> <li> ... </ul> </h3> That could be a gross item in your table of contents, I think. It's somewhat like CD's, only worse. The CD data format has all these great features. You can label every track with a song title, author, and artist, you can index within a track, etc. But the CD players didn't use it, so nobody put the data onto the CD's, so no CD players will ever use it. So browsers format bad HTML, everyone writes bad HTML, and nobody with write a browser that doesn't format bad HTML. What to do? -Fred email@example.com Agora Technology Group, Inc. Wow that was long. Sorry.