Re: DOCBOOK-APPS: Notes on graphics and HTML

[Paul Grosso <pgrosso at arbortext dot com>]

At 11:15 2002 05 03 -0400, Ed Nixon wrote:
>At 08:47 AM 03/05/2002 -0500, Paul Grosso wrote:
>The short answer is that, in general, pixels don't work.  They are
>>terrible things to use when specifying style.  However, the HTML
>>language and browsers don't give you much of a choice.
>
>Don't understand this assertion, I'm afraid, unless you are referring solely to images. And I think the cut/paste below contradicts this assertion.

I've answered below.

>>>>Or just say that it is an error for docbook::graphics.{width,depth} to be
>>>>assigned a value whose unit is "em".
>>>
>>>If I understand this correctly, aren't you taking away my ability to create HTML output that conforms with WAI and 508 guidelines? Via CSS?
>>
>>I don't understand how saying we shouldn't use "em" does this.
>>Can you explain?
>
>My interpretation of what is being suggested is that the image attributes you set via XML --> XSL --> HTML processing will be imbedded as attribute values in the HTML source code output; 

Yes.  If the DocBook source gives sizing attributes, they 
will/should be passed through to the HTML, I would think.

>if I'm not mistaken these values will override any values I may choose to establish in my customized external CSS; if that is the case then you are taking away my ability and that of the end user to customize at view time in favour of customizing at, say, serve time.

Then you shouldn't have put those values into the DocBook source.
The stylesheets aren't trying to take anything away from you, they
are just translating the DocBook input into HTML output.  If you
have a different plan for how images should be scaled, then I assume
your DocBook input wouldn't have any sizing attributes.

> Further, I'm not convinced customizing at "serve" time is necessary when it can be done (in many cases) adequately and more simply/flexibly at view time, i.e. with CSS and/or alternative CSS files.

I don't know how to scale images via CSS in such a way as to
provide much greater end-user flexibility than you can get
with straight HTML.  In any case, as I've said above, if you
put size info on the DocBook source, the stylesheets have to
assume you meant it and want it so they translate that, as
best they can, to the HTML.


>>> Perhaps you're trying to over specify these measures in order to accommodate XSL processing issues which, in tern, are an over specification of the HTML output. Why not leave the Image attributes in HTML for final and dynamic sizing to an external CSS? With a CLASS or ID attribute selector? Surely the admin and upkeep overhead are similar to that of tweaking parameters in the XSL kit and better located in the processing flow. And maybe better understood or learn.
>>
>>I don't understand what you are suggesting here.
>>What do you mean "leave the Image attributes in HTML?"
>>The only attributes on the IMG tag are width and height
>>and their values must be a unitless number of pixels.
>
>I've pasted in a section from the HTML 4.01 specification (sorry for the formatting.) Things may have changed in subsequent versions of HTML but I don't have them handy.
>
>It seems to indicate that, at minimum, percentages may be specified and length units. In addition, there are other attributes associated with IMG: style, vspace, hspace, align, etc. All, in one way or another, potentially inter-related to the discussion. Here's the clip:
>
>//***
>height = length [CN]
>Image and object height override.
>When specified, the width and height attributes tell user agents to override the natural image or object size in favor of these values.
>When the object is an image, it is scaled. User agents should do their best to scale an object or image to match the width and height specified by the author. Note that lengths expressed as percentages are based on the horizontal or vertical space currently available, not on the natural size of the image, object, or applet.
>The height and width attributes give user agents an idea of the size of an image or object so that they may reserve space for it and continue rendering the document while waiting for the image data.
>**//

vspace, hspace, and align have nothing to do with image sizing.

Only html::img.{width,height} have anything *directly* to do
with image sizing.  Note that the spec says %Length; is "nn 
for pixels or nn% for percentage length" (that quote comes
straight from the DTD).  

So the only capability beyond given a dimension in pixels is
the nn% which, as you note, is a percent of the available width.

This is precisely what Norm and I were discussing in an earlier
message where we exhanged:

-----
>       Percentages are problematic. In the following discussion, we speak
>       of width and contentwidth, but the same issues apply to depth and
>       contentdepth
>
>       1. A width of 50% means "half of the available space for the image."
>          That's fine. But note that in HTML, this is a dynamic property and
>          the image size will vary if the browser window is resized.
>
>       2. A contentwidth of 50% means "half of the actual image width". But
>          the stylesheets have no way to assess the image's actual size. Treating
>          this as a width of 50% is one possibility, but it produces behavior
>          (dynamic scaling) that seems entirely out of character with the
>          meaning.

Worse, mapping docbook::graphics.width="200%" to html::img.width="200%"
guarantees that the graphic will be twice as large as the window which
is almost never what the user wants to see.
----- 

So I still don't see what you're suggesting the stylesheets should do.

>All of this aside, we also have the DIV element, into which an image may be imbedded and with which a great deal can be done in terms of space.

Norm and I discussed this, and he's going to look into this some more.
Actually, I believe he decided that you can't set dimens on div tags,
but we might be able to get somewhere by using a one cell table.  All
of which sounds pretty gross to me, but maybe it'll help.

Still, I think you are optimistic in thinking that "a great deal" can
be done in terms of sizing the image.  I just don't think HTML and
browsers give us much to work with here.  If there is a trick that
Norm and I are missing, please let us know.


>>What are you suggesting?
>>
>>Also, can you tell us more about "dynamic sizing to an external CSS"?
>>If there is some way, say via properties in the style attribute, that
>>would allow us to tell browsers how to size graphics, I'd be happy for
>>us to use that.  But I'm unaware of such.
>
>If relative in addition to pixel level units are permitted and they can be used in the context of CSS, then it is possible to change the relative amount of space occupied by an image by changing the CSS that is being used. This should and can (in at least one instance -- Mozilla/Netscape) be done by the user from the View menu; alternatively, similar things can be done with scripting and/or user style sheets. If width and height allow for scaling, as seems to be indicated by the quote, then I believe this can most easily and most accessibly be done with CSS.

You say "if width and height allow for scaling".

I assume you are referring to html::img.{width,height}.  I'm not sure
I agree they do really allow for scaling the image size independent of
the viewport.  See the discussion about about what nn% means.

I'm still unclear how you propose we scale HTML images, either via HTML 
attributes or CSS.  Maybe some more detail would help me.  Or maybe I'm 
just not smart enough, and Norm will have all this figured out for you.

paul