连接
◆《重构之美》总目录
上一篇:重构之美-走在Web标准化设计的路上[复杂表单:Reloaded]
下一篇:The End.
首先,大家儿童节快乐,我要去买份儿童套餐来温习温习。^_^
问题:XHTML中的列表Tag(ul/ol)和表格Tag(table)区别何在?对于单列多行下的数据表,如何判断和选择?
这是我在培训中提的第二个问题。如果说上一个问题“理解h系列的不合理”能够把人带入对结构,代码结构的思考中,那么这第二个问题我认为则是把人带进对语义,语义结构的思考中。
说到标题“深入语义”,其实并不是从现在才开始的,大家应该发现在之前的文章中,我总是会回到语义这个点上去展开思路,论述结构。关于语义这个概念非常重要,什么是语义?这个我想一展开又是一长篇大论,我现在也很难说得清,所以,我还是回到这篇文章的主题,泛泛而言吧。
我想大家肯定变狡猾了,先去W3查过对ul/ol和table的定义,嘿嘿,我也是。但是很遗憾的是该死的W3给的答案是Define a List, Define a Table. 这不是废话嘛?NND!说了等于没说,完全就好比等于是一团大便。什么是List嘛?什么是Table嘛?还有办法,金山糍粑!
好像也得不出什么所以然的结果,虽然好像已经有所提示了,怎么个提示法?问题的最关键在于单列多行的时候如何抉择?好,待我磨拳擦掌搓脚磨牙,试试看。
首先严正申明:由于没有准确的List和Table定义,所以和之前有法可依,有矩可循不一样,这次真正纯粹是个人的理解了,您完全可以视为胡说八道。我想还是和上次一样分两方面来分析,理论和实践。
理论先行,我先闭嘴,咱们看图说话,分别用List和Table列一段单行数据如下:(unorder和order并不是关键,随便了)
数据一 |
数据二 |
数据三 |
数据四 |
数据五 |
看出来什么没有?好像什么也看不出来,ul和ol的圆点数字说明不了什么问题,ul/ol的代码量比table少很多,也不能说明什么问题,table的边框?我故意加的。好,我们接着继续看,让我们把数据扩展一次再看。
数据一 | AAA |
数据二 | BBB |
数据三 | CCC |
数据四 | DDD |
数据五 | EEE |
现在看出来了吗?仔细看看?还没有吗?还需要我继续扩展吗?
我直接说我的认知了:
table和ul/ol都能产生数据行,但是table的重心应该是在产生数据列,而ul/ol的重心应该是在产生数据级。
所以对于单列多行的数据,扩展的趋势是产生级的时候,使用ul/ol。扩展的趋势是产生列的时候,使用table。。
是的,我是这么区分的,趋势、级、列。我认为是隐藏的语义。
我想,你可能不会认可,觉得牵强,其实我也不是非常确定。
那么好,现在我再回到实践中来分析我的观点。
最常见的是网站中的新闻列表,特别是首页上的各栏目新闻列表,绝大部分都在使用ul/ol。我认为是种滥用,应该用table。这里要到后台程序开发中走走,新闻列表从数据库里产生出来,在数据库里,一条新闻由许多字段组成,首页上的简短新闻表和内页中的完整新闻表在一些情况下有可能是调用同一个存储过程或者SQL语句。不同的仅仅是数据的绑定,首页上的我可能只是绑定标题和时间,内页中或许会更完整一点,比如加上点击数、作者之类。如果一个新闻表有三列以上,你肯定不会使用ul/ol了。那么两列的和三列的有本质区别吗?我知道两列可以很容易用ul/ol实现,增加span嘛,那么三列呢?你说可以,给span加class。好吧,四列了,你还说可以吗?是的,我承认仍然可以做到,你烦不烦啊!
再说了,本来一个样式就可以内外定义完同样的新闻表,分开后你又要定义ul/ol,又要定义table,不是多此一举吗?最重要的还是在扩展的趋势上,如果数据一旦向列扩展,ul/ol将非常困难。你说是吗?
ul/ol不是用来取代或者模拟table的,table用于表状数据,什么数据是表状数据,扩展趋势是列的数据,哪怕它只有一列也应该视为表状数据而使用table。那么什么时候使用ul/ol?级。具体点菜单上,树上。
当然有些时候数据又有列又有级,这时就会出现混用的情况,相对复杂点了,但我觉得判断还是在级和列上,谁为重?
连接
◆《重构之美》总目录
上一篇:重构之美-走在Web标准化设计的路上[复杂表单:Reloaded]
下一篇:The End.