Re: Grid In 1.2?

On Jul 8, 2004, at 3:49 AM, Doug Schepers wrote:
> A grid can allow the author to very easily create a UI that makes best 
> use
> of the space it has available, and keeps the controls in a consistent 
> order
> with respect to one another.

I think at the heart of this debate is the same dichotomy that has been 
causing other battles in SVG - the split personality of 
SVG-as-graphics-markup and SVG-as-pixel-level-control-UI tool (and the 
third part of the 'di'chotomy, 
SVG-as-UI-tool-but-with-uncontrolled-system-widgets camp.)

I now understand the desire to use a grid to layout labels and content, 
to control a UI. What I'm not yet sure of is whether this is 
appropriate for SVG.

I haven't been following the 1.2 spec recently; has it decided that SVG 
should attempt to be all things to all people? (Or, to be fair and less 
melodramatic, has it been decided that 1.2 will attempt to satisfy both 
camps, allowing SVG to be used for pure graphics representation as well 
as a good UI/interaction interface?)


> A grid can be very good for accessibility... each cell can have its own
> title and desc, letting screen readers know what the content of the 
> cell is,
> and when used for tabular data, such as a calendar or keypad or 
> spreadsheet,
> can let a sightless person navigate with relative ease.

While I'm normally a huge accessibility fan (and have occasionally been 
known to argue with others that one of the merits of SVG is its 
plaintext, search-engine-crawlable nature) the above seems like an 
argument ill-suited for the inclusion of grids in SVG.

SVG isn't about accessibility, is it? It hasn't been in the past; is 
there a push to make it so in 1.2? Most SVG markup is meaningless to a 
sightless person, so what does it matter if a new element included 
happens to be accessible?


> * It could have manually resizable columns/rows; these are going to 
> resize
> anyway, when their values are relative and the viewport resizes, so 
> why not
> let the author specify that they can be resized by the user?

Sweet for UI. Often desired in HTML. Appropriate for SVG?
(If we go this route, shouldn't we have 'draggable' and 'resizable' 
attributes for all elements, so the UI can let the user interact with 
it easily. Maybe even showBoundingBox and showResizeHandles :p)


I think I'm seeing a pattern in my point-by-point arguments that helps 
explain to me what my position is:

While I am an SVG-for-UI guy, I think I'm bothered by the inclusion of 
any "I'll figure out where to place this stuff for you" features. While 
at some point in the future I'll probably be screaming for a table, 
right now I think I'm falling into the camp of "1.2 is long overdue as 
it is; let's get it polished and get some UAs deployed, ASAP. No spec 
will ever be perfect; some feature will always be missing. We've got so 
much new and needed coming in 1.2 (from what I saw a while ago)...let's 
delay the decision on tables until the next round."

Such are my thoughts :|


--
(-, /\ \/ / /\/

Received on Thursday, 8 July 2004 10:45:10 UTC