- From: Dmitry Turin <html60@narod.ru>
- Date: Wed, 29 Aug 2007 08:33:57 +0400
- To: public-html@w3.org, www-style@w3.org
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