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

Good day, Charles.

======= Branching into two manners
CM> Without fixing
Already done. To time of this letter, i already
(1) work out new manner, which has __no alphabet analogue__
[and can draft several graph on one chart -
may be it's necessary to change name TABLE to another], details are in
http://html60.chat.ru/site/html60/en/author/looker_eng.htm#several


<table several="stacked/side2side/frontal/behind">
  <tbody id="id1">
    <a a1= a2= a3= >
    <a a1= a2= a3= >
    <a a1= a2= a3= >
  </tbody>
  <tbody id="id2">
    <b b1= b2= b3= >
    <b b1= b2= b3= >
    <b b1= b2= b3= >
  </tbody>
  <tbody id="id3">
    <c c1= c2= c3= >
    <c c1= c2= c3= >
    <c c1= c2= c3= >
  </tbody>
</table>

table, tbody {
  x:            §a1;
  y:            §a2;
  z:            §a3;
  f1:           §a4;
  f2:           §a5;
  f3:           §a6;
  point-type:   §a7;
  point-color:  §a8;
}

tbody#id1 [r > 5] {
  point-color: red;
}
tbody#id2 [f > 3] {
  point-color: green;
}

Let's refer to 'x,y,z,r,f1,f2,f3' as to 'distinations'
  (instead of 'properties'),
'x,y,z' are coordinates,
'f1,f2,f2' are for drafting vector field (in decart or polar chart)
  and are component of vector,

   2  2  2      2    2    2
r=x +y +z , f=f1 + f2 + f3

Request in database is:

select '<table several="stacked"><tbody id="id1">'
union
select '<a a1='  + a1 + 'a2=' + a2 + 'a3=' + a3 + '>' from a
union
select '</tbody><tbody id="id2">'
union
select '<b b1='  + b1 + 'b2=' + b2 + 'b3=' + b3 + '>' from b
union
select '</tbody><tbody id="id3">'
union
select '<c c1='  + c1 + 'c2=' + c2 + 'c3=' + c3 + '>' from c
union
select '</tbody></table>'; 

(2) and i saved old, discussed manner for auto-table
(http://html60.chat.ru/site/html60/en/author/looker_eng.htm#chart ),
because auto-table used for input of data __even in chart representation__:
fields, on which chart is built, can be
(2.1) duplicated in <input> (chart is automatically updated)
(2.2) entered from other DBMS-table by <select> (updated too)
and
(2.3) charts can be in relation "master-subordinate",
e.g. different slice of pie [part of master chart] correspond to
different subordinate chart [whole chart, pay attention] -
but only one subordinate chart is displayed in any moment
depending of focus on slice of master chart.

<table name="M" action="./scriptM.cgi"               id="id1">
  <select name="B" action="./script.cgi">m2</select>
</table>
<input    name="M" value="m1" type="text">
<input    name="M" value="m2" type="checkbox">
<input    name="M" value="m3" type="pic">
<table name="S" action="./scriptS.cgi"               id="id2" master="id1"></table>

table#id1 {
  presentation: decart;
  x:            §m1;
  y:            §m2;
  point-type:   §m4;
  point-color:  §m5;
}
table#id2 { ... }

======= about old manner, used now in auto-table
CM>   - It increases the complexity of implementation.
  Your way is 'atom-building':
you and others propose to user to write by "assembler" -
by *additional* XSL-code, by *additional* JS-code, etc.
Yes, translator from mnemonic code into executable code has easier construction,
than translator from Prolog.
But even i can assembly by atom, even i can make by hands (manually) -
i don't want to make, i want that machine make instead me.
  Let's put __large-block panel, which is HTML-element__, into document !!
CM>   - There are other ways of doing this
  Other ways exist for all - not only for chart,
but also for <line>, for <table> and <ul>, "reflexiving" into DBMS.
In time, when programming languages lifts to HTML
(look, for example, at Delphi, CBuilder, PowerBuilder, Oracle Developer, etc),
HTML itself degrades to level of elementary primitives of XServer !
CM> So I don't think this is a very high priority,
CM> and should not be in the first version of HTML 5
  Elementary primitives (with following assembling by JScript) and
__aggregated__ primitives of HTML are
things of absolutely different semantic levels.
*New atoms* (like <canvas>, xmlHTTPrequest, etc) are tumor
on body of large-grain building.

CM>      + laying out a table or pie chart (since they probably take different
CM> amounts of space) will slow down the browser,
(1) amounts of space is not in deal: time of rendering is true parameter
(2) <table presentation="pie"> and XSL/JS/etc should be
used in _comparison characteristic_,
<table presentation="pie"> and <table presentation="alphabet">
are _not alternatives_ for each other!!
Thus your objection has no power.

CM>      + defining what to do with incompatible tables (just 1 column, of
CM> text? 3 columns? ...)
And what are you (corrent commercial browsers) doing with incorrect HTML-4.01-code ?
You draw as you want, 'if only' author see, that he is writing incorrectly. Also for
table, tbody {
  x:            §a1;
  y:            §a2;
  z:            §a3;
  f1:           §a4;
  f2:           §a5;
  f3:           §a6;
  point-type:   §a7;
  point-color:  §a8;
}

CM> As far as I know, no browser implements this
  Never [will] do, because [was] never done?

---

I don't understand, what are you ask:
CM>   - It gives no clarity about how to do layout
  How to do layout ?
CM> Optimising the presentation of graphics is very important for clarity.
  What is the "Optimising the presentation of graphics" ?
CM> we would need to increase the complexity of the proposal - IMHO
CM> significantly.
  What are you imply in "increase the complexity of the proposal" ?


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 Wednesday, 29 August 2007 04:35:27 UTC