Hmmm. Actually I seem to the forest ranger, having to
walk from camp to camp and trying my hardest not to
settle in for the night at any one of them.
Yes, I am familair with style sheets. In fact, I am participating
on the DSSSL-Lite discussion even now. I am in favor of style
sheets -- really I am. But style sheets don't solve all problems.
>
> You wrote:
> >I think that an author/publisher should have the ability
> >to specify their formatting preferences in a document that
> >they are providing over the Web. I also think that it would be
> >a mistake for browsers not to provide a way to override
> >the author's preferences, or to assign weighted ranking
> >to author/reader preferences.
>
> >From my point of view (and there are others who share it) the author should
> NOT be putting their formatting preferences in the document. Those belong in
> a style sheet. If the user wants to override the author's preferences, then
> the reader can have their own style sheet which can be merged with that of
> the author. However, IMHO the reader's style sheet should always win.
Ya, I understand and actually appreciate that point of view.
I just don't agree entirely. Certainly I agree that the reader
should always win. I also agree that, ultimately, style sheets
are a much happier solution to the problem. But, there are
plenty of information providers who want to specify some author
or publisher preference information in with the data. They are
going to do it whether we like it or not, so we had better make
it easy enough to put some style info into the document and
make it just as easy for a reader to ignore it.
After all, the information provider is at least as important
on the Web as the reader. If they can't achieve what they
need to achieve -- even if we think that they just don't understand
-- then they will just litter the Web with PostScript or RTF.
Other browsers are coming down the pike. Let them try to answer
the needs of publishers and readers of info-domain-specific markup.
There is just no way that HTML can ever be everything to everyone.
So why not think of it as a Volks-language? It's not what you
would drive under many circumstances, but its easy enough to use
and gets you where you are going.
>
> Regarding <UL TYPE=value> we wrote:
> >> Nope. A browser might reasonably put this under control of the user, or
> >> maybe a style sheet, but in the markup? No way.
> >
> >Yes way. Again, as a provider of information I need some control
> >over presentation of information.
>
> Again, this should be a style sheet issue. One important aspect of presenting
> information is that it should presented in a consistent way. A document that
> had list dingbats that varied from one list to the next would be confusing to
> the reader.
You are absolutely right about consistency. But so what?
If I, as an informatio provider, chose to serve up lists
that were presented with a variety of dingbats witin the
same list, then you as a reader will probably not read my stuff
after a while because it irritates you. My loss. So why
should anyone get to say that I can't do something awful?
I think that it is important to encourage "best practice".
I try to. But I don't think that it helps to tell the WWW
community that they "should not" do what many of them want to do.
I've been around the SGML for 9 years now. I know about
separation of form and content. I just don't agree that
it is the key doctrine upon which SGML was based.
>
> However, as it happens, there is a way for you to override the dingbats in
> HTML3, which is to use <LI SRC=uri>.
So, why is this "better" than an attribute that allows me
to select one of 3 or 4 specific dingbats?
>
> Regarding START=value:
> >> Maybe, as an attribute, but definitely not as a tag.
> >
> >Yes, I think that there is probably a terminology problem here.
> >I am sure that they meant attribute.
>
> Upon re-reading it, I am sure they did too.
>
> >> >> <IMG WIDTH=value HEIGHT=value>
> >> These might have value, but should be strictly treated as hints.
> >
> >What else could they be used as?
>
> Absolute values which the browser has to scale the image to. Personally I would
> rather not see that happen, simply because it adds that much more overhead to
> using images in a document. Scaling images might be acceptable for something
> which is going to be printed offline, but when it has to be accessed,
> formatted, and displayed interactively, excess processing is to be avoided.
Sorry, I was not clear enough in my question.
What I meant was, how could any browser be required
to do anything but accept the values as hints?
In the HTML 2.0 spec, the working group has been very
careful to note "typical rendering" of elements.
Browser developers are left a lot of discretion.
My experience with SGML has led me to conclude that
"attributes are cheap, anybody will give you one".
So, I have little problem with adding attributes
that only a small set of applications will actually use.
No harm. No foul.
>
> >> >> <IMG BORDER=value>
> >> This is something that should be under user control, not author control. The
> >> thickness of borders should be consistent throughout a document.
> >
> >Maybe, maybe not. This is, again, something that the author
> >should be able to declare a preference for.
>
> See my previous comments about consistent presentation of information.
And mine.
>
> The remainder of the stuff we have varying levels of agreement on, but they
> obviously need to be discussed.
>
> This whole discussion is a clear example of why it is a bad thing for people
> to do what MCOM (NCOM?) did, which is to unilaterally monkey with standards.
I'm not so sure about the conclusion that you have reached.
Is it not the case that most browser developers are adding
features to the language even as we exchange mail? Certainly
Dave Ragget is with Arena, and I suspect that Spyglass has.
I know that we, at SCO and IXI, have experimented with our
browsers and will have ideas to offer as a result.
I think it is a shame that Marc and his team took so much heat.
I also think that it was regretable that they did not work
with the HTML Working Group before they announced these extensions.
And while I do not have a copy of Netscape running here, I have
heard a lot of positive remarks about what they have done.
>
> Michael Johnson
> Relay Technology, Inc.
Murray
===========================================================================
---------------------------------------------------------------------------
Murray C. Maloney Internet: murray@sco.com
Technical Publications Writer/Architect Uucp: ...uunet!sco!murray
SCO Canada, Inc. My Phone: (416) 960-4031
130 Bloor Street West, 10th Floor Fax: (416) 922-2704
Toronto, Ontario, Canada M5S 1N5 SCO Phone: (416) 922-1937
===========================================================================
---------------------------------------------------------------------------
Sponsor member of Davenport Group (ftp://ftp.ora.com/pub/davenport/)
Member of IETF HTML Working Group (http://www.hal.com/%7Econnolly/html-spec/)
Member of SGML Open Internet and WWW Technical Committee
===========================================================================