- From: Laurens Holst <lholst@students.cs.uu.nl>
- Date: Tue, 05 Jul 2005 16:00:51 +0200
- To: Orion Adrian <orion.adrian@gmail.com>
- Cc: www-style@w3.org
Orion Adrian schreef: > Beyond the gross misuse of table semantics, let's take a look at your > data. Now remember nothing ever said you had to fill every cell with > data. Secondly, what you're saying isn't a problem since there is no > need for rowspan or colspan here. If what I'm understanding is > correct, you're using a column with rowspans to specify labels into > assembler code. There’s not really a ‘direct’ mapping like that. It is a document which documents the function of addresses (with assigned labels). > It breaks one of the fundamental promises of a table. That the rows > and columns can be reorganized or sorted and it's going to be alright. I’m not saying that HTML’s solution is ideal :). > Code in it's linear nature would make no sense sorted. What you're > looking for is <ol> to represent your code. The data is in no particular order. It is also tabular data, not a simple list. > In this case though you're using list (or more likely text) semantics > in a table and complaining you're not getting the proper effect. Of course I’m using list semantics. A list is a list of items. This is a list with different aspect of an item (e.g. address, label, description), in other words tabular data (‘arranged in rows and columns’ my dictionary says). Every table is a list. Just like ordered lists, unordered lists and definition lists are also lists. >>Additionally: this also removes redundancy in the content (which is >>something else than saving bytes). I would say that is desirable as well. > > It's not redundant though. The additional data is very important at a > minimum because it can change. No one has yet dealt with the problem > of what happens when a cell in the middle of a span changes. It's > quite ugly. It cannot change, this data is fixed and has been for about 20 years. >>So, how the mechanism works precisely I do not care about, but there >>must be a means to do this. Right now we have col- and rowspan, so col- >>and rowspan I shall use. The semantics could be better, but it does the job. > > Unless you want to leave the door open for any data manipulation whatsoever. Table sorting is possible with col- and rowspans... Although in the latter case it is slightly limited and the algorithm is not straightforward. ~Grauw -- Ushiko-san! Kimi wa doushite, Ushiko-san nan da!!
Received on Tuesday, 5 July 2005 14:01:47 UTC