Subject: Re: Proposed extensions to HTML Message-Id: <MICHAELJ.email@example.com> From: firstname.lastname@example.org (Michael Johnson) To: email@example.com (Murray Maloney) Cc: firstname.lastname@example.org (HTML discussion list) Date: Fri, 18 Nov 94 14:30:30 EST Murray, it seems to me that you are of the camp that thinks that HTML should be a page description language, not a semantic markup language. I obviously am of the other camp. There is a compromise between the two, and that is style sheets. 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. 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. However, as it happens, there is a way for you to override the dingbats in HTML3, which is to use <LI SRC=uri>. 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. >> >> <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. 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. Michael Johnson Relay Technology, Inc.