Re: The style agenda

Thanks, Hakon.

Hakon writes:
|  > | I imagine this document going through several phases. Starting as a
|  > | scratchpad, it should end up as an I-D. I've changed the wording on
|  > | the top to better reflect this, thanks!
|  > 
|  > If it's going to be an I-D, does that mean it has to come under
|  > the aegis of some WG?
| 
| I would think so. Do you have a favorite?

It's your choice, I'd say.  But HTML-WG would seem to be appropriate
(there's always MIMESGML).
 
  ...

|  > | Agree, in principle. Conflicts arise when you want to specify style
|  > | for non-HTML information, e.g.
|  > |  - the whole document: "doc: margin.left = 50pt" -- I'm not sure
|  > |    we can convince people to use "html of "body" instead of "doc".
|  > |  - browser buttons: "browser: button.save = off"
|  > |  - html source: "source: font.size = 14pt"
|  > | These conflicts will arrive when we try to handle a DTD with <SOURCE>.
|  > | So, an item for discussion should be to what extent, if any, the style
|  > | sheet should be able to influence non-HTML properties, or take
|  > | non-HTML information (like AGE and LANGUAGE) into account when
|  > | rendering. The author of a document shouldn't decide how e.g. the html
|  > | source should be displayed, but certainly the user should. And if it's
|  > | not in the style sheet, where will in be? I hate .Xdefaults!
|  > 
|  > 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?

| 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).
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).

| 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 don't know about the current mechanism, but let me put the case for
|  > something like "legal."  As a publisher, I may need to insist that 
|  > my doc be read only according to a style sheet I supply.  I know that
|  > I probably can't find a mechanism to enforce that on the browser,
|  > but at least I have to be able to say it.  (Then if the user insists
|  > on rendering Warnings as gray text on a grey background, fails to
|  > read a Warning, and electrocutes himself, I'm in the clear.)
| 
| This seems to be the prevailing view among publishers, and it makes
| some sense. But, I don't think the style sheet mechanism is the best
| legal cover you can find. Since style sheets can be LINKed from a
| document (most proposals suggest this), it may or may not reach the
| browser. So, should the browser refuse to show a document just because
| the style sheet may include lagal hints? I don't think so. This is
| just one of the questions that arise if we decide to deal with
| legality.

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.

|  > | I'm proposing a simple stream of boxes where the style sheet controls
|  > | the margins of each box. The boxes are stacked on top of each other
|  > | (perhaps with a page break here & there), and children inherit the
|  > | parent's horizontal boundry + margins (i.e. to do indented nested
|  > | list). Paper delivery will require some extensions to this model.
|  > 
|  > Could you compare this model to Tex's?  No glue, obviously ...
| 
| 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?

 ...

| 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?



-- 
Terry Allen  (terry@ora.com)   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472
occasional column at:  http://gnn.com/meta/imedia/webworks/allen/

A Davenport Group sponsor.  For information on the Davenport 
  Group see ftp://ftp.ora.com/pub/davenport/README.html
	or  http://www.ora.com/davenport/README.html

Received on Monday, 23 January 2023 01:05:43 UTC