- From: regme please <regmeplease@gmail.com>
- Date: Wed, 8 Apr 2009 09:05:48 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Brad Kemper <brad.kemper@gmail.com>, "L. David Baron" <dbaron@dbaron.org>, "www-style@w3.org" <www-style@w3.org>
2009/4/7 Tab Atkins Jr. <jackalmage@gmail.com> > > > Anyway, some clearer statement in the above mentioned chapter #17.5.4 > > would help a lot both users and implementers, in my opinion. > > Well, the implementers already know the problems with it, but what > would you like to see for authors? > > ~TJ First of all, what'd be your interpretation for chapter 17.5.4? Implementers very often misunderstand the standards: just give a look at public bug tracking systems. Clearer statements with no ambiguity won't harm anyone. And what I expect (or would like to see) follows here. Rows and columns, besides their syntactic position in a byte stream (tables are 2D, streams are somehow 1D) should just be cell containers meant for grouping and ordering. You put the data in cells grouped and ordered by rows and columns. The style will define the appearance of everything with the aid of classes and ids assigned to cells, rows, columns. Define a default inheritance rule (any rule will be ok) and then allow for a user defined one. It seems to me that something goes here, something goes and something else needs both. Which is confusing, at least to me. In my case the HTML+CSS code is generated on the fly by software (as opposed to "authoring tools") with a DB back end. Appearance and data come from different sources and a separation would simplify the design and the implementation a lot. In my mind anything that's not data is just style that should stay all together. I'm not a W3 guru, of course, just putting my thoughts in an email while studying my own problems. Your answers here are very precious to me as they shed more light on this world. <VR42 />
Received on Wednesday, 8 April 2009 07:06:24 UTC