- From: Dmitry Turin <html60@narod.ru>
- Date: Mon, 27 Aug 2007 08:36:29 +0400
- To: public-html@w3.org
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