Re: Frames spec & the NOFRAMES tag

[ I've posted this to www-html because I'm responding to a message there. If
this thread is to go on, it should probably migrate completely to www-style,
so please send replies there. I monitor both lists ]

On Mon, 9 Mar 1998, Hakon Lie wrote:

>  > I'll repeat my mantra against frames (it's been repeated again and again on
>  > this list...). I think that 99.99% of current applications of frames would
>  > be greatly simplified if you could simply define the content of frames
>  > within a document, in something like <div style="frame: top">content</div>.
> 
> The CSS2 Working Draft proposes functionality similar to what you
> describe [1]. We are interested in feedback -- please send your
> comments to www-style@w3.org.

You're absolutely right, Hakon, fixed positioning is exactly what I had in
mind. Excuse me for not referring to the spec, I've been a little out of
date lately.

[ The following is obviously not addressed directly to you... you wrote the
thing, I'm sure you know what's in it :-) ]

The reason I got rather excited is that I made this proposal when
NOTE-layout [1] first came out (08 June 96, gosh, have I been on this list
for so long?); NOTE-layout did exactly what the HTML 4.0 frame
implementation did, only it did it in CSS instead of HTML. Essentially it
defined fixed-position elements, but offered the option to replace their
contents with other documents/resources. I had argued that if you removed
that last bit, the proposal was perfect. I had gotten responses varying from
flames to praise, as is usual for any proposal on this list :-)

[1] http://www.w3.org/TR/NOTE-layout

But the fixed-positioning in CSS2 is definitely the way to go for frame-like
layouts. It addresses what 99% of people use frames for, eliminates all the
problems (and actually will cost less bandwidth, despite what the
duplicate-content people will say, because you won't need a server request
for each frameset/frame, again, and again, and again, while caching the
stylesheet conveniently for site-wide stylesheets, essentially doing what
all the people suggesting things like <link rel="frameset"...> wanted to do)
and provides a clean solution which is backward compatible (remove the
stylesheet and the only difference is that the elements in question will be
part of the normal document flow) and won't require wicked client-side
manipulation in order to achieve the desired effect.

Concerning the CSS2 spec in general, I have one or two comments (the
document is obviously still under heavy development, so I won't get into
technicalities):

This has arisen because a recent XML parsing project of mine has reached
critical mass and is threatening to become a full-featured browser (don't
hold your breath though), and it was important for me to keep good
principles from the start (which is why it grew).

Section 2.3, "The CSS2 processing model" [2] is one of the most enlightening
to most people, and should be stressed. As a programmer, it makes absolute
sense to me that any user agent would be designed this way. Sadly, the
dominant browsers are not. But you should point out that it is possible to
do the rendering WHILE processing the document and creating the tree. This
is very important, and you must take into account that any fully featured
user agent will probably offer some sort of client-side scripting, and have
the capability to dynamically alter the layout of the document after it has
been initialy displayed. Once you build this functionality into the user
agent, it is very easy to do on-the-fly rendering; you just render your
"best guess" of what you're parsing, and if by the end it turns out that it
was wrong, you can update it. This also makes for good client-side
scripting; the object tree that the user agent is building has to be exposed
to client side methods like Java Applets or ECMAScript scripts, which can
act on a document before it has been parsed completely.

[2] http://www.w3.org/TR/WD-CSS2/intro.html#h-2.3

IN FACT, this is one of the most important advantages of IE over NS; IE is a
newcomer, and was designed with the content-manipulation thing in mind from
the ground up, while NS carries with it code from time immemorial when it
did simple HTML parsing and display. This means that client-side
manipulation of a document is much easier for IE (hence its support of
display:none and dynamic manipulation thereof), as is rendering, because its
rendering engine isn't hard-coded. Of course, IE's first goal was to be
transparently compatible with Netscape so that it could gain the user base
of all the people who wanted to view broken documents, but that's another
story.

Though it's not critical to CSS2 itself, it's a critical lesson that browser
programmers have to understand that HTML is no longer a simple markup
language that it was in 2.0 times (hell, Netscape 1.0 broke even THAT! We
all know what happens if you don't put end-tags on your paragraphs!) and any
rendering engine has to have SOUND design principles from the parser all the
way to the renderer, and not hardwire code like Netscape does. Anyone who's
read the stuff on mozilla.org can guess that Netscape is incredibly ashamed
of what their code looks like and is encouraging people to "modularize"
before adding new features... mainly because Netscape, like the Pentium II,
is probably too much of a huge extension of a simple, limited-purpose
architecture stretched to its limits to meet market expectations. But (ahem)
I'm straying from the subject here.

So, to make a long story short, I think you should emphasize this bit
slightly more.

The second gripe I have is that there's still no way to bind a stylesheet to
XML documents. This is VERY bad. With CSS2 taking over tables and
fixed-positioned elements, it is know able to express the rendering of
EVERYthing on an HTML/XML document, and make specific element names
obsolete; hence, the ideal stylesheet language for XML, since you can bet
next month's paycheck that most people won't bother to get used to DSSSL-o.
CSS2 is perfect for XML, and we should at least get an indication of what
you guys have thought about this. Implementations are bound to pop up any
minute now (ahem) and we all know what will happen if someone uses an ugly,
broken, proprietary method that gets to stick: the Browser Wars all over
again.

Anyway, sorry for the long letter, but I felt these points were rather
important. Those with the patience to get this far, feel free to respond
with all your passion.

-- Stephanos Piperoglou -- sp249@cam.ac.uk -------------------
All I want is a little love and a lot of money. In that order.
------------------------- http://www.thor.cam.ac.uk/~sp249/ --

Received on Monday, 9 March 1998 12:18:17 UTC