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
	 tritan@agora.com
	 Agora Technology Group, Inc.

Wow that was long.
Sorry.

Received on Wednesday, 30 November 1994 01:37:32 UTC