- From: Doug Schepers <doug@schepers.cc>
- Date: Sat, 23 Aug 2003 14:15:15 -0400
- To: <www-svg@w3.org>
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