omiga

简单就好

不同浏览器对表格边框处理差异

3条评论»

最近一直和表格打交道，发现各浏览器对表格边框的处理不尽相同，以致影响到最终的显示。这一问题主要是Firefox与非Firefox浏览器对表格边框处理上的差异。

可简单地用以下表达式表示（tableWidth为表格的视觉上的实际宽度，width为定义宽度）：

FF：tableWidth = width+borderWidth/2

非FF浏览器：tableWidth = width;

测试l链接

FF中可能导致的问题

补充：尽管FF中表格在视觉上的宽度大于定义宽度，但其在文档中的实际宽度仍是最初的定义宽度，故其不会在文档中占用其定义大小外的空间。测试链接

W3C推出移动Web标准

发表评论»

2008年7月29日，W3C发布了移动Web标准移动Web最佳实践 1.0，该标准可以让用户更容易使用移动设备访问 Web。

移动Web最佳实践 1.0W3C的移动Web最佳实践工作组提出，该最佳实践集众多移动Web实际经验，旨在指导移动Web运营者创作移动设备友好的内容（mobile-friendly content），以便让用户在使用各种手持设备访问网站的时候改善浏览体验。

W3C同一天还发布了另外一个标准，XHTML Basic 1.1 Recommendation，该标准，连同Open Mobile Alliance (OMA)使移动置标语言（mobile markup languages）有了一个完整的集合。工作组同时还发表了移动Web程序最佳实践第一草案，该草案针对的是移动 Web 程序。

W3C移动Web验证（mobileOK）地址：http://validator.w3.org/mobile/

SimplePageNavi页码bug

4条评论»

昨天发现SimplePageNavi的页码计算有误，我原本不到130篇日志，页码却显示到16。

查看SimplePageNavi源文件发现以下代码：

$postsnum = $wpdb->get_var("SELECT COUNT(*) FROM $wpdb->posts where post_status='draft'");

问题就在这里，查看WP的表结构发现这条查询条件有误。仅仅过滤掉了草稿，但是数据表中还存在post_status=inherit的数据项。所以将原代码做如下修改即可解决问题：

$postsnum = $wpdb->get_var("SELECT COUNT(*) FROM $wpdb->posts where post_type='post' and post_status='publish'");

（7月31日更新）

除了日志数量读取bug外，还确实在页码计算上存在一个bug。问题代码：

$pagenum=intval($postsnum/get_option('posts_per_page'));

解决办法：

$pagenum=ceil($postsnum/get_option('posts_per_page'));

td之overflow:hidden

1条评论»

table-layout

语法：
　　table-layout : auto | fixed
　　参数：
　　auto : 默认的自动算法。布局将基于各单元格的内容。表格在每一单元格读取计算之后才会显示出来。速度很慢
　　fixed : 固定布局的算法。在这算法中，水平布局是仅仅基于表格的宽度，表格边框的宽度，单元格间距，列的宽度，而和表格内容无关

隐藏对象内的多余文本，一般做法：

selector{width:*px; white-space:nowrap; overflow:hidden;}　但是这段代码用在td上不会生效，单元格依然会被撑开～···

解决办法：同时为其table定义width:*; table-layout : fixed OK：多余文本已经被自动隐藏。