Re[6]: <table presentation="pie"> (was: Re: <table chart="pie">)

Good day, James and Mike.

Excise me for a long break

(i was in territory, which has no electric communication).



JE> If <table> were

JE> actually used **solely** for the presentation of tabular (arrays of)  

JE> data, I would agree with Dimitry. Since it is also (and mostly) used  

JE> for the presentation of web pages, it is a problem.

You think about, what is <table>, used for make-up, with my @presentation ?

I don't know too :)

This way has no sense, i don't see necessity to discuss it.



MB> You'll need to clearly define rules for what happens if you mix your

MB> new "graph" values with the rest of CSS, which focuses on the box model:

MB> <table style="display:piegraph">

MB>    <tr style="display:block">What happens here?</tr>

MB>    <div style="float:left">Or here?</div>

MB>    <ns:foo style="position:absolute">Or here?</ns:foo>

MB>    <span style="display:piegraph">Or even here?</span>

MB> </table>

This is not actually, how table will looks, if anybody mix @presentation

(i think, it's necessary to change @presentation by property 'presentation')

with properties, un-suitable for 'presentation',

It's enough to detect (by external view of table), that mistake is made.



MB> doesn't clash with or complicate existing

MB> codebases

+

MB> You'll need to clearly define rules for what happens if you mix your  

MB> new "graph" values with the rest of CSS

These particular cases (not often cases) can be developed later.



---



JE> To attempt to use <table> both for LAYOUT and for tabular DATA  

JE> conflicts

If table cells contain only text string

(i.e. does not contain html-elements), then

<table>

  <a a1= a2= a3= >

  <a a1= a2= a3= >

  <a a1= a2= a3= >

</table>

__is more suitable, than <tr> and <td>__.



If table cells contain html-elements,

than this is __not table in general__ - this is case of LAYOUT.



JE> If there were an html tag which really was just for tables of data,

JE> many things would be possible. The data could automatically be  

JE> displayed just the way a spreadsheet would display it, including  

JE> adding commas and dollar (monetary) signs to money values, aligning  

JE> right for numbers and left for text

+1



JE> it would make sense to consider different chart styles and

JE> how to display the data in forms other than just rows and columns. It

JE> would no longer be necessary to add '@chart' or '@presentation'  

JE> because it would be obvious that it was just a different style, and  

JE> we already have 'style= ...' and 'style { ... }' to handle different  

JE> ways of presenting information on web pages.

To change @presentation by property 'presentation' ?

or anything else ?



---



MB> Areas I expect you'll need to cover are 3D rotation of graphs,

MB> extensions of slices from pies, position of text labels or markers on

MB> slices of pies, position, shape, size and style of call-outs to those

MB> labels... and PieGraphs are the easy ones. You've got bars, scatter  

MB> plots, line graphs, box-whisker charts, combinations of all of the  

MB> above against regular axes, logarithmic axes, axes with gaps, axes  

MB> displaying text or dates or floating point or fractions or every  

MB> third day of the month.

It's possible to make that by CSS, isn't it?

P.S.

Not all particular cases are necessary:

simple use cases should be done in simple way (e.g. by @presentation),

sophisticated use cases should be done in sophisticated way

(other methods, mentioned in previous letters).



MB> Then, of course, you'll need to persuade developers to set aside

MB> their time and resources to actually *implement* your idea. This  

MB> means a clear use-case

Yes! I intend my tool especially for simple use cases -

for use cases, which are used more often.



MB> it's clearly  

MB> defined, limited in scope

Yes, especially for that.





>> MB> this should be done ... not overriding tables

>> You think, this is non-table ? You are wrong.

>> This is __other presentation__ of table.

>>

>>                 QUANTITY OF ROWS

>>                   1-3      4-...

>> PRESENTATION

>> numerical          +        +

>> chart              +        -

>>

>>   "Plus"-es mean,

>> that three rows can be displayed both as numbers and as chart.

>> "Minus" means,

>> that it's impossible to display four (and above) rows,

>> because we can't draw 4D-space.

>>   I think to change @chart to @presentation with "numeric" as  

>> default value.

>> <table presentation="numeric / pie / etc">

>>

>> PNA> Why not "simply" create an XHTML type of <chart> that has a

>> PNA> <chart_datapoint> member or something like that?

>> MB> bet way to handle this is to use XHTML

>> MB>     <body>

>> MB>      <chartns:piechart>

>> MB>       <chartns:data key="this" value="123"/>

>> MB>       <chartns:data key="that" value="456"/>

>> MB>      </chartns:piechart>

>> MB>     <body>

>> (1) Recall about razor of Occam: don't enter entity without needs.

>> (2) Because your way is __more__ (comparison characteristic) difficult

>> for applied specialists (biologists, technologists, etc). For  

>> simple man.

>>

>> MB> A table is for tables, not charts.

>> PNA> it was not intended to be

>> Orthodox-ness. No more.





Dmitry Turin

HTML6     (6.4.0)  http://html60.chat.ru

SQL4      (4.2.0)  http://sql40.chat.ru

Unicode2  (2.0.1)  http://unicode2.chat.ru

Computer2 (2.0.3)  http://computer20.chat.ru

Received on Monday, 27 August 2007 04:36:49 UTC