Text Wrapping and StartOffset

Hi-

Sorry if this is a double post...

I'd like to make a special request for you to look at the possibility of
adding a "lineOffset" attribute to flowDiv. It would function similarly to
"startOffset", except that the offset unit would be the line height (which I
believe is variable based on the height of glyphs in that strip). Like
"startOffset", the value of "lineOffset" can be negative.

The reason for this is to enable a simple scrolling mechanism (assuming
editable flowDivs). If a user types enough text that the next line would
exceed the size of the flowRegion, the author could have script that offsets
the flowDiv by -1, "scrolling" it up. A user-defined scrollbar could easily
scroll up and down this text by manipulating the lineOffset, and not have to
worry about expensive transformations. Similarly, for a dropdown list, an
author could have each item as a flowSpan/flowLine (or maybe a flowPara),
with the list area defined as the flowRegion. ("flowRef " will also be very
nice here, for scoll-list checkboxes.) This solves a tricky problem in
creating an arbitrary scrolling area for text, with fixed dimensions and
position relative to the objects around it.

My initial thought was that this effect could be achieved by simply allowing
"startOffset", which the author could set as multiples of flowRegion width,
but that would only work for rectangles. Still, having "startOffset" would
be nice way of defining a paragraph indent/outdent on the first line. Also,
with a single-line flowRegion and "startOffset", a textbox would exhibit the
expected behavior of scrolling the text to the left as the user types beyond
the bounds, preventing the unfortunate exceeding of the bounds of the rect.

"lineOffset" could be in replacement of or supplemental to the CSS property
"overflow-x: scroll", and "startOffset" (in this context) to "overflow-y:
scroll". This would expose "lineOffset" and "startOffset" to both
declarative (CSS) and scripted options.

And while I'm asking for favors, I'll ask also for the ability to set the
background color for text. This area is clearly already being defined,
judging from the fact that you can click on spaces in editable text. Being
able to change the color of this area would allow for scriptless
(SMIL-based) mouseover-highlighting, and would prevent the need for a
background rect, reducing code size.

Can you tell that I'm working on a combobox widget?

Thanks-
-Doug

Received on Saturday, 23 August 2003 14:15:30 UTC