^_^

图标库

  • 我对ul和dl语义的理解

    昨天和同事Toepy讨论了几个问题，其中提到了ul和dl这两个东西的用法。今天仔细想了一下他们语义上的细节差别，说一下个人的理解和发现。

    当时的题设是这样的：

    这样的列表，应该使用什么结构来写？

    　　看上去简单得很，我想一般都会直接使用 +

      来写吧，标题+无序列表，多么清晰明了通俗易懂啊：
      [code]

      FTP下载

      • ...
      • ...
      • ...
      • ...

      BT下载

        ...

      分段更新包下载

        ...

      [/code]
      　　可是当对方问：那用

      来写如何呢？
      　　当时我的大脑用了4分之1根烟的时间（囧），飞快地转了一下：dl？啊，定义项目列表！表达一些从属关系应该特别适用。恩，那么把标题放在dt里，然后把这个标题下所包含的下载地址们放在其后的dd中，这样四个列表块依次写开，从结构上看，每个列表块都摆明了是从属于相应的标题dt中的，意义也很清晰，嘿，看上去好像也不错嘛：
      [code]

      FTP下载
      ...
      ...
      ...
      ...
      BT下载
      ...
      ...
      ...
      ...
      分段更新包下载
      ...
      ...
      ...

      [/code]

      　　可是总感觉哪里有点别扭，有点牵强。到底是哪里别扭和牵强呢？
      　　又四分之一根烟的时间……

      　　我们都知道，dl的本意是定义一组“定义列表”，什么是定义列表？首先，他是对事物的定义和解释；其次，他的组织形式是一个列表；连起来，也就是对若干事物的定义和解释所形成的一个列表。例如这样：
      [code]

      低成本

      这个产品新版本所花费的成本要远远小于旧的版本
      更易用
      我们改变了产品设计使它更容易使用
      适合儿童
      本产品和孩子同处一室，你也可以安心的离开，因为它不会让孩子受伤

      （描述若干特性） From w3.org
      [/code]

      或者引申为这样：
      [code]

      张三
      男
      30岁
      已婚
      王二麻子
      不男不女
      40岁
      二婚

      （描述若干人物）
      [/code]

      这样也可以：
      [code]

      主题：上班
      时间：9点半
      地点：华星时代广场
      过程：边干边偷懒
      结果：啥也没干好
      主题：吃午饭
      时间：12点半
      地点：外婆家
      过程：胡吃海喝
      结果：吃多了

      （描述若干事情）
      [/code]

      　　通过和之前下载地址的ul列表的对比，可以发现一些有意思的细节。
      　　首先，dl列表中的“描述”、“解释”和“补充”意义较ul列表更为明显，dd中的内容对dt而言，可以是dt的一个分支、补充修饰和阐述，dd和dt之间有明显的逻辑联系：dd是从属于dt的，并且一个dt下的多个dd仅从属于这个dt；而li本身很单纯，只是展示和呈现数据列表，它对于hX标题，虽然可以视为hX所代表内容的一部分，但是没有dd的“描述”“解释”等意味，并且li对于hX标题没有严格的逻辑联系和从属关系，li甚至可以不需要标题去对应（例如某导航）。
      　　其次，dd之间虽然是平行关系，但并不是像li那种单纯的“同维度”关系，例如上例中的“时间”，“地点”，“经过”，“结果”等，都是用“不同维度”的关系来描述一个事物；而li之间则是很“纯洁”的并行关系，例如题目中的“下载地址1”“下载地址2”，都是属于“同一维度”，这个维度的可以看做“内容”的维度。
      　　再举更明显一点的例子来说明此处“维度”的含义：

      [code]
      例1

      下载这个文件

      • 下载地址1
      • 下载地址2
      • 下载地址3

      [/code]

      [code]
      例2

      下载这个文件
      文件大小
      更新时间
      下载地址

      [/code]

      　　这下明显了，例1中的li都是属于同一个维度（“下载地址”）的，其他的维度还包括“文件大小”，“更新时间”等。由此可见，同样是描述一个主题，用ul和dl却有着这些很细微的差别。

      　　最后再总结一下我对ul和dl之间语义细节差别的理解：[size=10][b]
      　　1.逻辑关系：dd和dt之间有明显的相对应的逻辑从属关系，而ul中几乎没有这些逻辑关系。
      　　2.语义差别：
      (1).dd对dt有比较强烈的“描述”、“解释”和“补充”等多种意味，而li本身是将列表内容单纯的“展示”和“呈现”，li对hX几乎没有意味或仅是很弱的单一意味。
      (2).dd之间是多维度的关系，而li之间单维度关系更为适合。[/b][/size]

      　　那么回头再看一下开头的题目，我们可以发现，用dl去设计这个下载列表，除了语义上可以让dd和dt之间形成逻辑联系（让标题和下载列表之间联系的更为紧密）这一个特点外，其它地方并不适合，因为下载地址仅仅是将内容“展示和呈现”，没有“解释”“补充”等含义，也没有其他维度呈现。况且，设计所传达的意义并不是以“描述”、“解释”和“补充”为主。所以，在权衡以上各点之后，还是用hX+ul组合更为恰当。

      =================快要结束的分隔线=================

      引申话题：
      这样的列表，你会用什么结构实现？

      期待讨论！[F17]

    归类于： WEB 评论： 8 SMbey0nd @ 2009-02-04 下午 10:46

  • 【跨浏览器的垂直居中】总结整理

    总结了垂直居中的多种情况，包括：

    1.文本垂直居中(3)
    2.图片垂直居中(4)
    3.其他元素垂直居中(2)

    详见DEMO：
    【跨浏览器的垂直居中】总结整理

    归类于： WEB 评论： 1 SMbey0nd @ 上午 11:35

  • 【PPT】前端基础知识培训

    上周搞的一个基础知识培训：
    前端基础知识分享 – 领略WEB的魅力

    目标人群是网站运营组和编辑组。
    由于培训安排的时间比较紧并且公司笔记本配置比较无敌，很多地方没有深入全面去讲，再加上参与人群水平差距较大，效果不是特别理想。如果有下次，会注意。

    有兴趣的同学点击这里下载PPT文档。

    归类于： WEB 评论： 2 SMbey0nd @ 2009-01-09 下午 9:20

  • Javascript重修笔记（3）开发环境和调试方法

    • 适合写JS的文本编辑器：
      记事本
      JSEclipse
      EditPlus
      MSInterDev
      MS VStudio
      1st Javascript Editor Pro
      JS Builder
      等

    • IE6.0支持JScript5.6，基本上符合ECMA v3标准；支持1级DOM事件模型和IE增强事件模型，部分支持W3C的二级DOM事件模型。

      IE7.0支持JScript5.7，该版本在JScript5.6上有所增强，基本上符合ECMA v3标准。

    • 数据交互方面，JScript5+支持MSXML4.0组件
      外部接口方面，JScript5+完全兼容COM+/DCOM标准

      数据交互方面，Javascript1.5实现了W3C的XMLHTTP接口，除了命名规范和部分函数参数的缺省校验之外，Javascript1.5实现的XMLHTTP接口和MSXML实现的基本一致

    • 浏览器中的源代码不能被调试程序定位，大多数是由于：
      1.客户端脚本临时构造和动态生成的代码
      2.服务器构造的特殊请求页面的代码
      3.调试器本身配置原因或者系统进程本身原因

    • JS代码中的命名和调用对象方法时，尽量使用camel命名规范
    • Try/catch/finally：
      catch从句跟在try后，当try内某个部分发生异常，catch能够捕获它们。finally块一般跟随在catch后，它的内容指令不管是否产生异常都会被执行。catch和finally从句都是可选的，但try从句后至少应有一个catch或finally。

    • finally不是用来恢复异常的，而是用来在异常发生时做一些不论异常是否发生都应该做的正常处理。比如保留数据或者记录状态。
      如果要让系统从异常中恢复，应该通过catch块而不是依赖finally块。

    • 在OOP中，声明对象可能抛出的异常是一个良好的习惯（JS不能throws声明，但可以把throws作为注释添加到对象或者方法的后面）
    • JS核心内置的5种异常对象：
      Error
      EvalError（表达式计算错误）
      RangeError（数值/数组下标越界）
      SyntaxError（语法错误）
      TypeError（数据类型错误）

      SyntaxError比较特殊，它的产生阶段通常是在词法分析时，很难被catch。除非故意实例化了一个SyntaxError对象。
      需要另一种处理错误的方法：window.onerror事件。

    归类于： WEB 评论： 发表 SMbey0nd @ 2008-12-25 下午 5:42

  • Javascript重修笔记（2）浏览器中的Javascript

    • 规范推荐：
      在什么地方装载Javascript代码（页面上的Javascript代码）？

      1.将全局变量和全局变量的初始化放在一个单独的<script>中，置于<head>和<body>之间，尽量采用额外属性标记，如<script region=”global”>
      2.将闭包和孤立函数放在<head>的末尾（</head>前）。
      3.将页面装载期间执行的指令、DOM对象初始化以及DOM相关的全局引用赋值操作放在<body>的末尾。
      4.将需要引用到的外部Javascript文件按照相互依赖的次序放在<meta>之后，<title>之前。

    • 结果是啥？
      function A(){
      alert(1);
      }
      A();
      function A(){
      alert(2);
      }
      A();
      A = function(){
      alert(3);
      }
      A();
    • 依赖和冲突：
      管理依赖：在文件头部进行充分的描述和预防性的检测。
      避免冲突：某些模式可以很好的预防和消除冲突的产生，例如面向接口。
    • 通常情况下，闭包起到作用域限定的作用，而
      (function(){
      …
      }());
      起到了创建闭包的作用。
    • Javascript的缺陷：
      1.自身的缺陷
      alert(45.6 * 13);
      2.兼容性问题
      alert(document.all

      • [0].outerHTML);
      一个解决方式是坚持原则，而这个原则通常是指业界标准。

    归类于： WEB 评论： 发表 SMbey0nd @ 2008-12-22 下午 5:25

关于SMbey0nd

Avatar of SMbey0nd SMbey0nd
F2EDevigner 83/07/03
USE.com.cn|TaobaoUED
hangzhou china
handsome kuso sb
我爱花夏小小

Category

不迟到我会死……

Search

不迟到我会死……

Comments

不迟到我会死……

Blogroll

不迟到我会死……

Resources

不迟到我会死……

Logos

  • logo1
  • logo2
  • logo3
  • logo4
  • logo5
不迟到我会死……

Other

  • RSS

    rss

  • Follow SMbey0nd on Twitter

    twitter

  • QR Code

    QR Code for SMbey0nd.com
不迟到我会死……
Creative Commons: 署名/非商业用途/保持一致
折叠 图标库

© 2010 SMbey0nd.com Some rights reserved. iFLM 2.0 By SMbey0nd. Powered by WordPress.