[html5] making standards-compliant charts

Tue Dec 30 19:19:05 PST 2008

My practice is:
==========
If the data changes frequently or is hand-edited; or needs displayed in a 
variety of formats:
1) The data should be stored as XML; so that it can be expressed differently 
easily and can be easily distinguished
     from the means of presentation.
2) Then, using DOM interfaces and JavaScript (or even a CSS style sheet ) 
you convert the data to a <TABLE>,
     or a VML/SVG graph. or whatever is needed as appropriate. That's why 
you keep the data seperate from the presentation method via XML -- to make 
it an easily re-used object. <CANVAS> is basically useless for displaying 
technical information that requires text.

If the data is basically a static picture use external packages to generate 
a nice graphic:
==========================================================
add a good description that
can be read as an explanation of the graph's significance.  If the text is 
out-of-place or clutters the document, make
the text appear only if you hover over the graph or click a button to see 
the text. Make sure the button is labeled
properly so that common software for those with impaired senses can easily 
locate it.That way, the graphic representation can be scaled and labeled 
easily, increasing accessibility.  If the data is static, you are probably 
providing a detailed description of the data's significance anyway. Charts 
rarely stand by themselves as a complete
document (although grand exceptions exist such as steam table properties and 
sub-atomic particle charts and the
period chart, I admit).

A picture's worth a thousand words. The fact that people are using CSS to 
generate something as basic as a simple
plot or chart shows just how much farther there is to go in defining 
standards that define browser content and
presentatio

Not much I have is publically available, but I found a good mix is:
1) make a high-level chart generating program that can write your plots as a 
simple "pseudo file" in java that is composed of calls to functions to draw 
lines and polygons and text strings; it will end up looking a lot like a 
program
written in basic CALCOMP calls if you're old enough to get the reference.
2) Make java functions to render the drawing that
detect if your browser supports VML or SVG or CANVAS. Make javascript 
routines to draw text using Hershey
fonts; use CANVAS only if VML or SVG is not available. The program should 
also write the data as XML that a
style sheet is defined for; or as a <TABLE>. Your functions should also 
allow for zooming of your plots. The tables
can be hidden and evoked with a button.
3) Add more high-level functions to your "CALCOMP" library. Ultimately, you 
will find you will create widgets that
    read curve data and let you pan and zoom it and change things like 
linear versus log scale, time scales, and so on.

A nice addition is to make the program write the plot as visible SVG or VML 
or CANVAS HTML so you can
easily cut and paste the data into other applications. I made mine write out 
xfig(1); which is a basic figure editor
that can let you edit your chart as a simple graphic; but then write it out 
in many different formats.

That is, you will be re-inventing the wheel and evolving basic charting 
facilities! The path was blazed before --
storage tubes and pen plotters -> raster devices ->  graphic 
entities/objects ->  animation and 3d scenes, ....
(CALCOMP,GKS,Template,Figaro,GL, OpenGL, Mesa and so many others ....)
Just like you didn't do 3d graphics with pen plotters,  you can't do them 
with HTML (yet).

 If you are going to step
outside of basic browser content, use JAVA and applets. Ultimately, you'll 
probably use a 3rd-party javascript library to cut your
maintenance costs once things have become established enough that reliable 
things like that are available.

But more simply, XML is the equivalent of HDF5. Keep your data 
self-desciptive and seperate from the rendering
engine. It will be useful longer that way. HTML leans towards organizing 
textual information; it's quite weak at
handling large amounts of numeric information. Then the answer as to what to 
do begs another question -- how much
time and effort is it worth?

----- Original Message ----- 
From: "Matt Bonner" <mateubonet at yahoo.com>
To: "Benjamin Hawkes-Lewis" <bhawkeslewis at googlemail.com>
Cc: <Help at lists.whatwg.org>
Sent: Monday, December 29, 2008 8:38 PM
Subject: Re: [html5] making standards-compliant charts

>> "Graph" (etymologically) comes from a word meaning to mark or engrave. 
>> "Graph"
>> is often a synonym for "chart" nowadays, so I don't see why "graphical" 
>> implies
>> the absence of character data.
>
> As far as I know, your etymology is correct.  But, recall the original 
> exchange in this thread:
>
> | > I am especially interested to hear how HTML experts view efforts to
> | > create bar or line charts in HTML/CSS.
> |
> | Graphs are, well, graphical. HTML would generally be inappropriate. :-)
>
> | I'd recommend using SVG or PNG for static graphs, with SVG or <canvas> 
> for
> | dynamic graphs, and providing tables for people who can't view the 
> graphs.
>
>> > Rendering chart text in an image means bigger, slower pages, ugly
>> > zooming
>>
>> With a _bitmap_ image, yes.
>
> Right.  Sorry, in my day job we often use "render" to imply raster output.
>
>> > and little hope for assistive technology to extract meaning.
>>
>> I'm not sure that's true. OCR might actually be the simplest part of the
>> challenge of extracting meaning from a bitmap chart. (Not that typical 
>> web AT
>> uses OCR!)
>
> Well, we tried several OCR packages on a fairly simple table not long ago,
> and I think I'd stand my ground on this point.  OCR *and* extracting 
> meaning
> would be hard problems for AT on rasterized graphs.
>
> So, my thinking remains that there's an opportunity to express most graphs 
> and
> charts using markup rather than raster images. Unless I misunderstand, it 
> seems like
> the language intended for this purpose is SVG.  If anyone sees a better 
> approach,
> by all means say so!
>
> Finally, I forgot to thank you for this excellent point:
>
>> It's arguably a good idea (from an accessibility and general usability
> perspective) to
>> explicitly and visibly state any trends shown by the
> graphs too, rather than leaving
>> people to try to guess at them.
>
> thanks again,
> Matt
>
>
>
> ----- Original Message ----
>> From: Benjamin Hawkes-Lewis <bhawkeslewis at googlemail.com>
>> To: Matt Bonner <mateubonet at yahoo.com>
>> Cc: Ian Hickson <ian at hixie.ch>; Help at lists.whatwg.org
>> Sent: Monday, December 29, 2008 5:05:04 PM
>> Subject: Re: [html5] making standards-compliant charts
>>
>> On 30/12/08 00:52, Matt Bonner wrote:
>> > Benjamin Hawkes-Lewis wrote:
>> >
>> >> Matt wrote:
>> >> calling charts graphical to me seems overly simplified.
>> >
>> >> I don't really see how the presence of characters makes this a
>> simplification.
>> >
>> > Well, to me, saying a chart is "graphical" implies that it is *only*
>> graphical,
>> > when clearly there are also textual elements in many charts, as your 
>> > test
>> > implies.
>>
>> "Graph" (etymologically) comes from a word meaning to mark or engrave. 
>> "Graph"
>> is often a synonym for "chart" nowadays, so I don't see why "graphical" 
>> implies
>> the absence of character data.
>>
>> Compare: http://www.merriam-webster.com/dictionary/graphical
>>
>> > Rendering chart text in an image means bigger, slower pages, ugly
>> > zooming
>>
>> With a _bitmap_ image, yes.
>>
>> > and little hope for assistive technology to extract meaning.
>>
>> I'm not sure that's true. OCR might actually be the simplest part of the
>> challenge of extracting meaning from a bitmap chart. (Not that typical 
>> web AT
>> uses OCR!)
>>
>> Much harder would be working out how the diagrammatic elements relate to 
>> the
>> text, and the meaning of the whole composition.
>>
>> >> Failing that, create a separate page and add a visible link to it.
>> >
>> > That was my thinking, I just wasn't sure how that would be seen from an
>> > accessibility standpoint.
>>
>> Better than nothing!
>>
>> --
>> Benjamin Hawkes-Lewis
>
>
>
>
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org 