Re: DOCBOOK-APPS: Notes on graphics and HTML

[Ed Nixon <ed dot nixon at LynnParkPlace dot org>]

At 08:47 AM 03/05/2002 -0500, Paul Grosso wrote:
>Norm and I discussed this some more off line and we clarified
>several things for each other.

Mmmm...


>Some more comments embedded.
><snip>
> >I don't see how this could work given the variability of pixels/inch in 
> screen resolutions and settings. Can you explain?
>
>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.

> >Ok, that answers my question above but how portable is this solution 
> across platforms and workstation configurations, e.g. for people who, of 
> visual necessity, run their machines a low res.
>
>About as portable as HTML.  This is how browsers work.
>Sometime it gives lousy results, but usually no one
>seems to notice much.

Perhaps nobody who says anything notices; there may be a silent but 
significant minority that just shrugs and moves on; but that's another 
discussion.



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

> >Again, same objection as the last one.
>
>Which is what?  (Sorry, I'm not trying to be dense.  Must be
>too early still for me.)

Something got chopped out in your response and I don't remember precisely 
what it was. Let's assume it was related to converting inches to pixels/inch.


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

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.


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

Over all, it seems to me a question of trying to leave as much as is 
appropriate, as late in the rendering and viewing process as possible. To 
the extent choices about units of measure, dimensions and scaling are 
factored *out* before absolutely necessary is the extent to which the 
reader will have less choice in tailoring the display to his or her needs.

I'm aware that realistically we have browser non-compliance issues in 
abundance but I don't think they impinge on the design direction I'm 
suggestion be taken with this.

Regards.                         ...edN