Re: The style agenda

Hakon writes:
 ...
| 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.)

I don't quite see the problem in this context.  I should think that
a style sheet for HTML would use HTML rather than DOC.  The stylist
has to know at least the element names in the DTD.  For SGML
in general, there is another question.

Suppose I have an instance with a doctype that is not the most general 
possible element in the DTD.  (I use Docbook here rather than HTML,
because it's hard to find an element in HTML the use of which doesn't
imply HTML as the doctype, and because of the convention that you
throw away the doctype of an HTML instance.) For example:

<!doctype para system "docbook.2.2.1.dtd">
<para>a paragraph</para>

Now given a style sheet for Docbook that specifies formatting
for Set, Book, Chapter, etc., what expectation should there be
that the paras in this instance will inherit the formatting of
some parent (such as Chapter)?  Note that para can be the child
of various parents, and that if you're rendering Chapters 
differently from Appendices, you're up the creek here unless you
specify base font size, etc., on every element.  (I'm copying 
Eve Maler on this because I think this question must have cropped
up in her FOSI work.)

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

Fine with me if we do it in the same style sheet where we specify
rendering.  But we ought to recognize the difference, so that when
and if we arrive at a point where we should modularize the style
sheet we'll recognize that these could be different modules, 
accepting different plug-ins.  I'll put in a plug here for the
need for a UA specification distinct from HTML, style sheets, HTTP,
etc.

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

Yes, indeed.  I was thinking of it from the author's end.  I would
then also want control over other aspects of the GUI, for example,
to enlarge the fonts on all the buttons, not just those in the main
window.  Another item for a UA spec.

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

I haven't seen any text overlaid on a GIF, am I missing something?
Point me at it, please!  I think we're talking about the same thing,
although 

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

Okay, good solution.  You do it in the markup.  Dave's current FIG
gives us, in relevant part:

<!ELEMENT FIG - - (OVERLAY*, CAPTION?, %body.content;, CREDIT?) -(FIG|IMG)>
<!ATTLIST FIG
        %attrs;
        %needs;                  -- for control of text flow --
        src  %URI;  #REQUIRED    -- URI of document to embed --
        %url.link;               -- standard link attributes --
        %block.align;            -- horizontal alignment --
        noflow (noflow) #IMPLIED -- noflow around figure --
        width  NUMBER #IMPLIED   -- desired width in units --
        height NUMBER #IMPLIED   -- desired height in units --
        units (em|pixels) pixels -- specifies units as em's or pixels --
        imagemap (%URI) #IMPLIED -- pass background clicks to server --
        >
<!ELEMENT OVERLAY - O EMPTY -- image overlay -->
<!ATTLIST OVERLAY
        src  %URI;  #REQUIRED    -- URI of image overlay --
        %url.link;               -- standard link attributes --
        units (em|pixels) pixels -- specifies units as em's or pixels --
        x      NUMBER   0        -- offset from left in units --
        y      NUMBER   0        -- offset from top in units --
        width  NUMBER #IMPLIED   -- desired width in units --
        height NUMBER #IMPLIED   -- desired height in units --
        imagemap (%URI) #IMPLIED -- pass background clicks to server --
        >

I note that OVERLAY is misnamed.  If I overlay a picture on text
(and it's FIG, not OVERLAY, that may contain text), it will obscure 
the text (except for any transparent or translucent part, but then if 
it's totally transparent it isn't worth much and if only translucency
is dealt with the model is incomplete).  This would better be called
BACKGROUND or BG.  But that's an issue for another list.

I'm sure there will be further discussion of FIG, but for the purposes
of this discussion, it would appear we need only be sure that we
can attach rendering info to the text contents of FIG.

|  > | 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?
| E.g.:
|  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
| or 
|   IMG: margin.right = 10 pt
| I'm sure there are other ways as well.

Glad you brought this up and provided so nice an example.  I recently
did a demo coded for Netscape (stop laughing) and made use of the 
hspace and vspace atts they've added to IMG:

<IMG align=right hspace=18 vspace=12
SRC="graphics/ueethumb.gif" ALT="book cover">

Now this is real crude (you can't vary the padding top/bottom
or left/right, and the padding appears to be added to the margin of the
column of text, exactly the wrong thing to do as a default).  But
the info is attached to the object, not its container (the para),
as the flow info is.  This is a sort of stones-in-the-stream model.

Elsewhere we seem to fall into a boxes-next-to- or -within-boxes
model, and it seems just slightly odd to me not to attach this
flow and margin info to the container (the para, its div, whatever),
saying, "within this div all IMGs in Ps get treated thus-and-such."

Which model is preferable, and under what circs?

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

Happy evacuation, and look forward to your return to emaildom.


-- 
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:49 UTC