CSS和表格

今天看了hax的blog，不知道哪个项里面提到了CSS面对表格的col的时候的尴尬。后来深入思考了一下，发现这其实是一个本质性的困难。而且问题并不是出现在CSS上，而是出现在XML上。

由于XML要求任何一个元素（除了根元素）都必须有且只有一个父元素，这就导致XML的table模型有些不自然，因为，一个cell显然是一个row的子，但是我们也可以说它同时也是col的子，可是由于XML（DOM）强制的树状模型，导致这个没有办法实现。这可以说是层次型数据和关系型数据的一个典型分野。在关系型数据库中，col可以认为是描述row数据的数据，也就是元数据，或者叫做关系。想要真正的解决这个问题，也就是说，想要XML能够自然的描述table，显然需要打破只有一个父这个局限性，对于table来说，需要两个父，因为table是二维的。但是，一放纵未免再放纵，能够有两个父显然就要想到为什么不能有多个父……，这显然超出了XML最初的预想，也超出了层次型数据模型的能力，什么时候能够把层次型模型和关系型模型无缝的融合起来（还有网状数据模型，跟现在的Web本身一样：），什么时候table在XML描述就没有问题了。

上面提出的这个方案可以说有点太迂远，不适合作为真正的解决方案推荐给网页设计者们。我们考虑一个可以实现的。

本质上CSS只是给出一个或者一些元素的外观，所以，它本身不受层次和关系模型的困扰。而就算CSS中的C是层次型生效的，也不影响我们对一个元素规定多个样式，它们会叠加起来的。

就像很难用一个类型体系（分类体系）把知识组织起来一样，从CSS的表现角度来说，Web Page上的元素也很难分类一个特定的类，它们总是有可能隶属于不同的类，比如：它们可以归为高亮（强调）类，也可以同时归为楷体（内容）类。幸运的是，CSS从来没有限制自己的叠加，虽然它大多数情况下思考的角度是子继父样，然后叠加自己特有的样子，但是毕竟它提供了一个叠加的机制，这样我们就可以随意的叠加了。

现在的问题是，如果规定了col的样式，如何应用到隶属于col的cell上？我们看过委员会的解释，知道不能采用子继父样这个通用的CSS Render机制，是不是就没有办法了呢？

不是。仔细考虑col的本质，col规定了table的结构信息，也就是说，它其实规定了row中数据的元数据。规定col的样式的意义是什么？

这不禁让我们想起了一系列相关的元素，规定head的样式的意义是什么？规定base font的意义是什么？规定title的意义是什么？这些元素归根结底都是元数据。对于它们的规定要影响到它们影响到的数据才行。所以，规定base font的样式应该影响到font的样式，而规定col的样式应该影响到row（进而影响到cell）的样式。

焦点集中到“查找一个元素可以应用的样式”这一个步骤上，我们也只需要改变这一个步骤，能够区分出XML（XHTML）中的元数据和数据，并且能够理解元数据所描述或者关联的数据，就可以把该元数据的样式应用到其所描述的数据上。

这个方案应该是比较完善的，并且是可以扩展的。我想，除了XML本身的层次结果以外，元数据和数据这个层次结构（显然可以层层叠加，也是一个潜在的无限层次的树）也是一个重要的考虑维度，并且潜在的对于元素的外观的影响应该比XML本身的层次结构影响更大。

不知道W3C会不会增加这个看起来比较复杂的方案？

它们最初的方案似乎是改进table模型，但是，其实不仅仅是table模型本身，所有的数据都潜在的有这样一个问题。尤其是那些自说明文档，它们常常是自包含的，也就是说，是数据和元数据存放在一起的。所以，必须有一套机制用来指定这个层次关系。

之所以有这样的多个维度的层次关系，原因还是上面说的【很难用一个类型体系（分类体系）把知识组织起来】，不仅仅对于表现有影响，实际上，对数据的影响是通过对表现的影响展现出来了而已。