Article 189021 of comp.infosystems.www.authoring.html: Path: news!global-news-master!newsfeed.concentric.net!winternet.com!www.nntp.primenet.com!globalcenter0!news.primenet.com!nntp.primenet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!europa.clark.net!206.1.179.76!newsrouter.icnc.com!psinntp!pubxfer.news.psi.net!abigail From: abigail@fnx.com (Abigail) Newsgroups: comp.infosystems.www.authoring.html,comp.infosystems.www.browsers.misc Subject: Re: how would you want HTML rendered in the dream browser of the future? Date: 23 Nov 1997 13:20:42 GMT Organization: FNX Ltd, Intelligent Risk Management Lines: 136 Message-ID: References: <65797o$3vt@examiner.concentric.net> <34780501.23D4B079@dircon.co.uk> Reply-To: abigail@fnx.com NNTP-Posting-Host: 38.220.93.3 X-Date: 1545 September 1993 X-HTTP: http://cthulhu.mandrake.net/%7Eabigail/ X-Perl-Wrapper: Version 0.1 (by Abigail) X-PGP-Key: mail abigail-pgp@ny.fnx.com to obtain PGP key X-PGP-Fingerprint: 76 2E 82 7A 69 93 5F 97 AE 01 80 75 67 F3 45 D0 X-Newsreader: slrn (0.9.3.2 UNIX) Xref: news comp.infosystems.www.browsers.misc:18727 comp.infosystems.www.authoring.html:189021 Steve Davis (steved@dircon.co.uk) wrote on 1545 September 1993 in : ++ Hi Bill, ++ ++ Bill Bereza wrote: ++ > ++ > Let's say someone was writing their own web browser that would parse ++ > HTML according to any DTD (whatever specified by the DOCTYPE, SYSTEM ++ > or PUBLIC). ++ ++ Good notion. But what about documents that don't *have* a DTD... what then? My ++ dream browser would have a sophisticated parsing engine/'expert system' that ++ would make the best sense possible of unstructured/improperly marked up ++ content, giving me usable access to as much of the information available on ++ the web as is possible. ++ ++ > And this browser would support CSS for all elements. So for most simple ++ > things, supplying a CSS style for it would be enough. ++ ++ Hurrah! At last a browser that supports CSS! (i.e. not a hacked version) Uhm, uhm, what makes people think that browsers that can do parse both DTDs and CSS are enough for viewable pages? Then we are back were we started. Sure, you can create a nice DTD for your page, and the browser parses it without problems. But how many CSS pages are you going to supply? Making one that suits your own preferences and hardware isn't a problem. But do you know what a proper stylesheet for speech browser is? How do you make a style sheet for web TV without access to a web TV browser? Do you want to spend time in creating a style sheet for a character cell display or a monochrome display? How do you create a style sheet for a platform that doesn't yet exist (or that you don't know about)? But you *have* to do that if you want browsers parse your own DTD and have the same impact HTML has now. I don't think style sheets are the hottest thing since sliced bread. It puts more work to the author of documents that is necessary. If we had a wider range of (structual) element, everyone would use the same elements, and you only need to think about presentation when writing (or configuring) a browser. Then at least you know the plat- form you are dealing with. But with CSS, it's suddenly the author of the document who has to worry how his elements will look, for the full range of platforms. It also makes it harder on users. They cannot look up what the elements are and configure their browser appropriately. No, documents either come with DIV and P with some CLASS defined (with unknow attributes), or in the case with specific DTDs for documents, with unknown elements. ++ > Are there any non-standard elements that you'd want it to support (e.g. ++ > FIG, AUTHOR, PERSON, WARNING, etc.) in the default style sheet? ++ ++ For non-standard elements (building on my comment above regarding parsing ++ undeclared doctypes), then: Explicitly, none. Implicitly, all. I want tons of new elements. But only *one* DTD. Simple example. An abstract. Had we one DTD with ABSTRACT, I can as an author use ABSTRACT and leave it to the user agent how to render it. On the other hand, as a reader I can configure my browser to render ABSTRACTs as I'm used to. (smaller font, left and right indented, italics). But with CSS and HTML as it is, one author might use

, the next one

, a third uses DIV, the fourth doesn't do anything special in HTML but uses CSS to have the first paragraph after an H1 rendered in glowing font, and the fifth uses SPAN. And with document specific DTDs the mess becomes even bigger. At the same time, as an author I have no idea how to tell my readers what the abstract is. I don't want to force my preferences how to render an abstract on them. And even if I would use CSS, what do I do for those platforms I don't know? ++ > ...And what do you think the default rendering of some standard elements ++ > should be? ++ > ++ > And for elements like FIG that can't be rendered just based ++ > on a CSS style, how should they be done? For example, would you like to ++ > see tables use internal scroll bars, so that if TABLE wouldn't fit ++ > inside the window, the TBODY rows would scroll while leaving THEAD ++ > and TFOOT rows at the top and bottom? ++ ++ I would want the 'default' rendering of elements to be entirely under my ++ control, meaning it shouldn't matter how it's set up when I install it, ++ because I would have the option to change the rendering of all properties of ++ elements to whatever I wanted (This is a *dream* browser, right?). How can a browser have a default rendering for elements that it doesn't know about? If I make a DTD full of s and s, what's your "dream browser"s default rendering? What if I make a DTD equal to HTML 3.2, with just the names of P and H1 reversed? ++ > (If you want to make up your own element, could you give a DTD fragment ++ > for it?) ++ ++ Well, for a long time, I thought that the following would be a really ++ excellent addition... I would scratch the current HTML and start over. And this time, do it right. Properly nest things into chapters, sections, paragraphs, even sentences. Do the basics _first_. If you have building blocks like SENTENCE and QUESTION, questions likes extra space after a period, or when to put an upside down question mark become easy. Those can be solved by the user agent, as configured by the reader; with possible different renderings based on the language. Get lots of 'text level' elements. PERSON, AUTHOR, ACRONYME, QUOTE, CITE, CODE, VEGETABLE, etc. Get more 'paragraph/div level' elements that indicate the role of the element. General ones as CHAPTER, SECTION, SUBSECTION (with an optional title). More specific ones like ABSTRACT, BLOCKQUOTE, INTRODUCTION, CREDITS, EPILOGUE, BIBIOGRAFY, GLOSSARY, EXAMPLE, POEM. I find that far, far more useful that all the IMG, OBJECT, EMBED, SCRIPT and Java combined. With lots of structual elements, people can use tools that build custom displays for them, grabbing just those elements from the documents they want, having it displayed on whatever device they prefer. *That* would be an interactive web. Abigail -- Anyone who slaps a "this page is best viewed with Browser X" label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. [Tim Berners-Lee in Technology Review, July 1996]