Re: The style agenda


 > |  > Margins aside, I think such things go in what I think of as another style 
 > |  > sheet, though this could be info in HEAD or a part of the rendering style
 > |  > sheet.  There's a large iceberg of nonrendering info people want to
 > |  > convey to the browser (browser buttons being a good example).  
 > | 
 > | Except for the button example, the others are rendering issues. As for
 > Okay.  Let me put it differently.  I don't see the what the problem
 > is with margins for the whole doc and font size for the whole doc.
 > That info can be attached to HTML or BODY; what do you mean by
 > "non-HTML info" wrt these items?

We agree on margins, they can cleanly be attached to head or body. (The
objection there, though, is that most users don't user <HTML> or <BODY>
and would rather (I'm guessing) refer to an imaginary <DOC> element
or whatever.)

 > | buttons, choosing to display or hide them is also a rendering issue
 > | since you gain/loose screen real-estate depending on your choice. I
 > | would hope the style sheet mechanism would convey rendering
 > | information peripheral to HTML as well. Users will ask for it.
 > You're assuming the buttons would be rendered in the text window,
 > which would not be a useful way to handle them (change the frame,
 > institute a toolbar; but these are choices for developers to make).

The most successful browsers allow the user to turn garniture on & off
through menus. I'm pretty sure you can set this in a defaults file as
well. Since this has to do with the rendering of the the browser
window (but not the HTML canvas), why not -- when designing a style
sheet mechanism -- include control for these "HTML-peripheral" items?

 > In any event, presentation of buttons is one of a large set of
 > ways people will want to affect browser behavior; that's why
 > I separate it from how the text itself is rendered.  For buttons
 > we don't have the issues of font and flow and so on (those are
 > presumably handled by the browser directly without instruction).

If you're visually impaired, you want control over button fonts. For
the user, setting the fonts for the buttons is as natural as setting
the fonts for HTML elements, and the same mechanism should be
used. For browser implementors, reusing code to allocate fonts etc. is

I'm not sure where I want to draw the line in this issue. Disableing
one single feature (e.g. the save button) will be asked for by some,
but I think this is beyond a style sheet. Removing all garniture to
allow the maximum size HTML canvas isn't.

 > | Are you suggesting we should have two style sheet mechanisms?
 > I'm saying that we have different types of info we want to convey.
 > Text rendering is one.  Buttons+ is another; style sheets for
 > link behavior (if we get to them) might be another.  The mechanism
 > we use for text rendering may not be best for the other types 
 > of info; if it is, okay.

I think we'll find a way. Who can come up with a good syntax?

 > Well, I might configure my server to send the style sheet first,
 > with some query (I don't know what) to see if the client has
 > received it.  Or I might rely on the HTML doc's instructions 
 > as to what style sheet was intended.  I would certainly want
 > to put up a text warning also ("use chair.sty or risk electrocution!").
 > But at the level of negotiation, I as publisher have to be able
 > to say no, whether or not I can enforce it.

We should also be able to come up with some finely tuned wording here,
Bert has a good start.

 > | No glue. And no nested boxes. Just a simple stack of boxes similar to
 > | how current browsers format HTML (tables and images in text flow
 > | excluded).
 > With this model, how are we to handle the case (widely desired) of 
 > overlaying text on a graphic?

Are you referring to the current wave of background images, or to a
future extension to HTML? I presume the latter. I don't think the
style sheet mechanism should be used to merge the two. The style sheet
would see a simple box, just as it sees any other box. Part of the
trick in writing a successful proposal is to keep it simple. I'm
willing to cut corners for tables, maths, text overlays on graphic

 > | Thus, one can control list indentations by setting margins. 
 > | 
 > | Text flow around floating images does not fit well into this model,
 > | e.g. you probably don't want to use the normal margins when placing
 > | text next to an image.
 > Could you expand on that?  Which margins become inappropriate?


 H1 has a 1 character left margin

 So does H2

      P starts here and could
      go on forever. Wow, a 5
      character left margin 
      sure looks great!
      | + + | Wow, you can do 
      |  @  | images as well?
      | --- | Then you'll 
      |_____| want a 1 character
      margin on the left side.
      Until, you're below the
      image that is.

This is where we the simple stacked box model is a bit too simple. Some
possible remedies are:

  P:  margin.left = 40pt
  P:  img.margin.left = 10pt


  IMG: margin.right = 10 pt

I'm sure there are other ways as well.

As you know, the WWW project is being evacuated from CERN. My
transition period to INRIA has started, and I'll be mostly without net
access for the next couple of weeks. I've enjoyed, and learned from,
the discusssions so far, and hope they will continue.


Hakon W Lie, WWW project CERN, CH-1211 Geneva 23