072012
 

前两天逛网站,突然发现一个通过box-shadow来制作3层叠加效果


具体的见这个demo
乍看的时候觉得有点奇怪,于是就跑去W3C的网站又仔细瞅了下box-shadow的定义:

The ‘box-shadow’ property attaches one or more drop-shadows to the box. The property is a comma-separated list of shadows, each specified by 2-4 length values, an optional color, and an optional ‘inset’ keyword. Omitted lengths are 0; omitted colors are a UA-chosen color

乍一看,自己也没觉着有啥的,估计英文水平比较搓导致…

因为,在自己日常工作中,经常看到并使用的,大多是下面这种形式:

box-shadow:npx npx npx rgba() inset,n为数字;

其中,第一个代表水平偏移(往右偏移为正数),第二个代表垂直偏移(往下便宜为正数),第三个代表模糊半径(不允许为负值),inset用来调整展现为内阴影还是外阴影(可选,默认缺省,为外阴影)

这些都是耳熟能详的东西,回归到demo中的代码,我们看到
box-shadow:0 1px 1px rgba(0,0,0,.15),
0 0 0 10px #e3e3e3,
0 10px 1px -4px rgba(0,0,0,0.15),
0 20px 0 -10px #e3e3e3,
0 20px 1px -9px rgba(0,0,0,0.15)

问题的关键就在于第四个数字的出现,那这个究竟是干啥的?

原来,W3C里面有解释…

The fourth length is a spread distance. Positive values cause the shadow shape to expand in all directions by the specified radius. Negative values cause the shadow shape to contract. See below. Note that for inner shadows, expanding the shadow (creating more shadow area) means contracting the shadow’s perimeter shape

即,第四个数字所代表的是一个扩展距离,为正数则阴影形状向外按指定半径扩大,反之则缩小;当然内阴影与外阴影情况又要反一次

box-shadow:0 1px 1px rgba(0,0,0,.15),
0 0 0 10px #e3e3e3,/*叠加的第2层*/
0 10px 1px -4px rgba(0,0,0,0.15),/*第2层的阴影,以第1层为基准来计算延展距离*/
0 20px 0 -10px #e3e3e3,/*叠加的第3层*/
0 20px 1px -9px rgba(0,0,0,0.15)/*第3层的阴影,以第1层为基准来计算延展距离*/

052011
 

在遥远的时代,我们知道有那么一个循环,叫做鸡和蛋的故事——先有鸡来产生蛋,还是先有蛋才会出现鸡?这里不是来讲解这究竟谁先有,只是想和电子商务里面的一个实例找个原型

在电子商务中,后进者总会遇到这么一个问题:卖家少导致买家少,买家少导致卖家少——卖家少,必然带来货物的缺少,因而给用户的吸引力减少;买家少,导致卖家缺少产品的销量;这种无限劣势策略的循环,是否可以考虑宏观切断?先满足买家,让卖家多精品;继而通过高回头率来吸引卖家,通过口碑相传等方式带动买家——循环有破的希望;先增加卖家?卖家的增加固然会带来种类繁多的产品,但是考虑到现实社会存在的一些问题,以及多卖家所潜在的价格竞争,不一定能吸引顾客前来

对比一下两方式,一种通过少而精的方式垂直营销,另一种通过广涉猎来平铺营销。二者无所谓孰对孰错,只是看适合与否。在我自己从一个学设计的学生毕业到走上网站重构的路,也一直经历着两种方式的折腾。

一专多长,很好理解的嘛——某一方面钻的透彻,很深入,可以号称所谓的砖家;同时广泛涉猎,铺广知识以及各方面的能力。以前,总是简单的以为,可以先潜心于某一个方面,细心去琢磨研究而之后再去平铺,亦或者先逛涉猎然后再就某一点而去下苦功。但是,现实告诉我们,成长不可能在这种单一环境下进行,彼此的对冲才会促使双方不断增强。

潜心钻一个,你会发现牵涉很多东西;广泛涉猎,你会发现自己心有余而力不足;鱼与熊掌不可兼得……

可是,我们为什么要纠结于兼得?就像流量与请求,二者虽不可兼得,但是我们总能想办法实现一个动态的平衡,那么,为什么不去平衡而要去追求某一个极致?

高处不胜寒,不胜寒吧…

十一 082010
 

关于RDFa Processing的翻译,其实已经很早就翻译了一遍,但是总觉得自己的翻译不够给力,有过一些修改,考虑到缺乏一些实例的直观性,后期打算整理一份详细点的文档,这里先把译文贴一下吧

解析一个文档的RDFa triples是从文档对象开始,然后按文档顺序依次访问它的每一个子节点,逐一应用解析规则,通过递归循环进行至其子孙元素(注意:在某些环境下,起始的位置可能不是文档根节点而是文档本身。之所以这样定义主要是由于某些环境下,重要信息是在document对象上展现而不是根节点)

随着进程的执行,会有许多依照规则产生的triples,同时由于解析环境的迁移而进行到其后辈元素(这里要注意的是,在RDFa 1.1的规范中并没有说明应该如何衍生triples,或者解析程序怎样产生更多的triples。但是有一点可以证实的是,一个RDFa处理器至少需要像本节内容一样来应用规则,产生一个单一的RDF图表。正如RDFa processor conformance中讲述的,任何额外产生的triples都不能出现在默认的RDF图表中)

解析环境(Evaluating Text)——在进程进行时,规则都会依次适用于相关的解析语境。在进程刚开始的时候,会初始化一个环境,该环境有以下几部分:

Base: 这通常是被解析的文档的URL,但也可能是一些由其他机制所设置的URL,例如XHTML的base元素。Base的重要性在于它提供了建立相对URL的基础,以便相对路径可以被解析(说明一点,RDF图表都是绝对地址)

parent subject: 它的初始值和base的初始值一样,但是在解析程序进行的过程中会发生变化

parent object: 有时候,一个语句的object可能会成为另一个嵌套语句的subject, 而parent object这个属性通常可以传递这个值。需要注意的是,这个值可能是一个空白节点bnode, 因为某些情况下会有许多嵌套的语句集合在一个空白节点bnode上。这就意味着bnode必须设置在容器语句上并且传递下去,即parent object所做的事情

A list of current URI mappings 一个当前作用范围的URI映射列表

A list of incomplete Triples 一个 未完成的triples 的列表:关于未完成的triples,详见hanging rel(ww)

language 请注意没有默认的语言

Term mappings: 一系列的terms以及相关联的URIs

Default voculabory: 当term使用的时候作为前缀URI的一个值,这里没有指明默认的词汇。Host languages 可能有一个初始化设置

在处理期间,新的解析过程会递归到每个子元素。下面阐述的规则会决定语境中的items值。此外,一些规则会结合由解析环境所处元素提供的信息创建一些triples。在处理期间,以下一些局部作用值是需要的:

一个初始化为空的URI映射列表,即URI映射本地列表(local list of URI mappings)

一个初始化为空的问完成triples 列表,即未完成triples本地列表(local list of incomplete triples)

一个初始化为空的语言值(language)

一个递归标志位(recurse flag)——解析程序一般通过递归循环来遍历整个元素树。但是,如果作者声明一些分支应该按照XML文本来进行处理,那么处理程序就不会对该分支进行解析,而这通过设置递归标志为false就会有这个效果。

跳过元素的标志(skip element flag)——它声明当前元素是否可以直接跳过,因为该元素未使用相关的RDFa属性。需注意的是,其子孙元素依旧会被解析。

一个新的subject值(new subject)

一个表示当前object literal 的值,创建有文本object的triples时使用的literal

一个表示当前object resource 的值,创建有resouce的triples时使用的resource

一个term及其相关联的URIs列表(local term mappings)

一个本地默认词汇,在使用一个term时作为一个前缀映射到URI (local default vocabulary)

链锁作用(Chaining)——之前一片文章提到过google对于语义支持的书写范例,在那里我们可以清楚的看到这样的写法:

<div xmlns:v="http://rdf.data-vocabulary.org/#" typeof="v:Person">
   My name is <span property="v:name">Bob Smith</span>,
   but people call me <span property="v:nickname">Smithy</span>.
   Here is my homepage:
   <a href="http://www.example.com" rel="v:url">www.example.com</a>.
   I live in
   <span rel="v:address">
      <span typeof="v:Address">
         <span property="v:locality">Albuquerque</span>,
         <span property="v:region">NM</span>
      </span>
   </span>
   and work as an <span property="v:title">engineer</span>
   at <span property="v:affiliation">ACME Corp</span>.
   My friends:
   <a href="http://darryl-blog.example.com" rel="v:friend">Darryl</a>,
   <a href="http://edna-blog.example.com" rel="v:friend">Edna</a>
</div>

很简单的一段代码,但是由于大量无用的span进行着嵌套,这不是我们所期望的,实际上RDFa是可以解决这些的,解决方式就是这里的链锁作用chaining。在RDFa中,链锁是RDFa的一个特性,它使得RDF语句可以链接在一起的同时减少一些不必要的标签重复。具体实例,可以参看RDFa 1.1文档中的chaining部分。但是,由于由于google未采用这点,因而其书写方面显得相当之臃肿,而这也不是我们所期望的方式

CURIE和URI 处理——RDFa本质上是传输RDF的一种方式,所以其核思想就是resource和它的URI表现。RDF处理的是完整的URIs,而在RDFa转化为triples的时候,会通过一些已经定义的算法,根据base URIs将相对URIs解析为完整的URIs. 代表RDFa属性值的URIs有三种格式: URI,SafeCURIE or CURIE or URI, TERM or CURIE or AbsURI. 这些通过进程处理后都回映射到相应的URIs.对这三种属性值的操作如下

URI            内容为一个URI时,直接使用该URI

SafeCURIE or CURIE or URI

当值被尖括号包围时,尖括号内的内容会被作为CURIE来处理;一旦该值不是有效的CURIE,那么该值就会被忽略

没有被尖括号包围时,该值会被作为CURIE处理,如果是有效的CURIE,将使用计算出来的URI,若不是,则作为URI来处理

TERM or CURIE or URI

如果属性值为一个命名空间,那么它会被作为一个项目(General Use of Terms in Attributes)来处理。注意这一步可能意味着该值会被忽略.

如果值为一个空的CURIE,那么会使用resulting URI

如果值为一个绝对URI,那么直接使用该值

否则,忽略该值

(注意的一点是,可能一个属性的所有值都会被忽略,如果这种情况出现,该属性直接视作空的)

常用CURIE方式: 通过XML的命名空间的方式xmlns来进行URI的缩写,作为使用者,可以从任意位置将URI进行断开,但是必须从左侧开始; 由于复用性比较大的是一些管理terms的书库,例如,像dbpedia就包括了许多resources的列表,用dbpedia就比使用自己创建的要更高效,如下

<div prefix="dbr: http://dbpedia.org/resource/">
  <div about="dbr:Albert_Einstein">
    ...
  </div>
  <div about="dbr:Baruch_Spinoza">
    ...
  </div>
</div>

上面说了处理方式,这里简单说下在属性中常用的CURIE使用方式,尽管很多属性可以使用CURIE,但是解析却不同:

1)  一个属性可能允许多个CURIEs和URI混合的属性值,这种情况下,任何值都不是CURIE,会被作为一个URI来处理

2)  属性值如果被方括号包裹,那么方括号内的内容按照CURIE语法来处理,如果该内容不是CURIE,那么直接无视之,即不产生RDF意义(此处需要注意的是typeof,即使是空的,也是一个CURIE)

例如,about属性可以接CURIE/ URI,about=http://dbpedia.org/resource/Albert_Einstein亦可写作about=”dbr:Albert_Einstein” 、或者about=”[Albert_Einstein]”形式的safe CURIE,需要注意的是about=”Albert_Einstein”也会设置一个subject,尽管不是一个CURIE,但是是一个有效的相对URI

Prefix的作用范围——prefix定义的元素及其子孙元素,例如

<div prefix=”dbr: http://dbpedia.org/resource/>

<div about=”dbr:Albert_Einstain”>…</div>

</div>所作用的范围就与

<div prefix=”dbr: http://someotherdbpedia.org/resource/>

<div about=”dbr:Albert_Einstain”>…</div>

</div>的作用范围不一样

TERM在属性中的应用——有些RDFa属性允许term作为其值,定义这种使用语法如下:

Term         :=      NCName

当一个RDFa属性可以带term属性值时,其值的解析与上述term介绍的解析一样,遵循以下逻辑:

如果term是一个本地term映射,使用相关联的URI;

如果有一个本地默认词汇,URI按照该规则进行解析;

如果没有本地默认词汇且term没有相关联的URI,那么就直接忽略掉该term

注意:该规则的一个衍生是,如果一个属性具有TERM/CURIE/URI的数据类型,其值符合term介绍中的但是没有一个本地默认词汇,那么该term会被忽略掉

302010
 

之前有提过google通过rich snippets的方式改变搜索结果呈现,来直观的表达使用RDFa、microformats、microdata所能带来的搜索引擎友好性。具体的展示情况,大家可以在google里面进行搜索,会发现搜索里面有许多采用了rich snippets的搜索结果,例如附带图片、视频预知播放时间、显示商品评星等等
这里,主要将google目前支持的语义方面的主要有以下几点:
1)食谱recipe
2)评论review——对于仅包含单条评论的网页,使用【单条评论】格式;而对于包含一系列评论的网页,则使用【汇总评论】格式;如果溶蚀存在的时候,选择一种;如果同时存在的话,google默认会用【汇总标记】予以显示。
2)评论评分review rating——这里需要注意的一点是,无论您在网页上以何种方式表达评分信息(例如,通过数值字符串、百分比、图片或图片拼接),都可以使用微数据、RDFa 或微格式标记向 Google 提供此信息。(除非另行说明,否则 Google 会假设您采用的是”1 表示最差,5 表示最好”的评分制;此外,请勿添加单独的隐藏文本块指定评分,因为隐藏的内容不显示)
4)人物people
5)事件events
6)商户和组织organization,即关于组织信息
7)产品products(目前不显示此类信息,除非产品是评论的一部分)
8)视频video(尽管 Google 支持视频标记,但是目前仅将它用于改善视频搜索结果)
9)面包屑breadcrumbs(rich snippets检测工具暂时无法显示)
10)嵌套项nested item——实体或项是一种信息类型,如人物、组织或评论。某些实体可以包含其他实体:例如,餐馆评论中可包含人物和组织信息(如,评论者的职位和商家的地址信息)

目前,按照google声明的,主要适用的是评论网站和社交/个人主页类别,而且video已经能够被识别并且在google的video搜索结果中显示出来,但是,没有办法预演;同样的还有,organization和product能被识别,但是没以前还没有对其搜索结果的显示产生影响。尽管如此,这些都可以实际去使用(即不必担心因为preview中无法产生数据而不用)

除此以外,google给出了microformats/microdata/RDFa的使用方法,具体的每一个如何去书写,大家可以自己去阅读一下google的Creating Google-friendly sites目录下关于Rich snippets (microdata, microformats, RDFa)的那部分内容,有详细的实例介绍。

在该介绍的最后,google提供了一个rich snippets test tool,尽管目前只是一个beta版,但是通过自己拿个人博客的实验,在该tool中确实可以抓取页面中经过描述的数据(本人采用的是RDFa来描述那些数据),可以用本站的abotme的链接进行测试

尽管google给出了他自己的确切的使用方法,但是,其公开的对于RDFa的支持仅仅是一部分,譬如其放弃了那些在semantic web中常用的命名空间foaf等;反观microformats,由于使用时间和范围已经有一定优势,就目前而言似乎是能迅速更替到网站中的,但是考虑到其扩展性的问题,个人觉得有很大局限性;至于microdata,从google给出的实例来看,其代码书写还是相当之臃肿。究竟,我们该使用神马来最好的为搜索引擎提供那些数据?

242010
 

圆角的使用,逐渐的增多;实现圆角的办法,也相对的丰富起来;自己稍微记录了一下使用过的方法,主要如下:

思路一,直接采用圆角图片作为背景

例如:

.bor{background:url(images/bor.png) no-repeat;width:50px;height:24px;}

<div class=”bor”>圆角制作好简单的嘛</div>

但是,由于很多情况下页面中的内容宽度/高度不确定,此时我们有两个方法来解决:

第一,切出所有的背景图,然后做CSS Sprite图片(具体制作就不演示)

第二,做宽度高度可自适应的圆角:这里主要是通过一下做法来实现的

<div class=”box”>

<div class=”top”><b class=”lt”><b class=”rt>

<div class=”middle”><div class=”content”>这里是内容区域部分</div></div>

<div class=”bottom”><b class=”"></b></div>

</div>

思路二,采用模拟圆角的方法,主要是通过边框来模拟出圆角效果

模拟方法一:

.box2{margin-top:2em;}

.ct{border:solid #F00;border-width:0 1px;padding:0 1em;background-color:#e3e3e3;}

.l,.r{border:solid #F00;height:1px;display:block;background-color:#e3e3e3;}

.l{margin:0 2px;border-width:1px 0 0;height:0;}

.r{margin:0 1px;height:1px;border-width:0 1px;}

<div class=”box2″>

<div class=”tp”><b class=”l”></b><b class=”r”></b></div>

<div class=”ct”>文字内容部分</div>

<div class=”bt”><b class=”r”></b><b class=”l”></b></div>

</div>

模拟方法二:

.wrap,.wrap_b,.cont{border:solid #f00;display:inline-block;*display:inline;*zoom:1;position:relative;}

.wrap{border-width:1px;}

.wrap_b,.cont{border-width:0 1px;*left:-2px;background-color:blue;}

.wrap_b{margin:0 -2px;}

.cont{margin:1px -2px;padding:0 6px;line-height:1.5;}

<div class=”wrap”>

<div class=”wrap_b”>

<div class=”cont”>这里是文字开始的玩意</div>

</div>

</div>


模拟方法三:

.box{margin-top:2em;}

.top{border-style:none dashed solid;border-color:#f00 transparent;border-width:3px;}

.center{background-color:#F00;padding:5em 6em;color:#FFF;}

.bottom{border-width:3px 3px 0;border-style:solid dotted none;border-color:#f00 transparent transparent;}

<div class=”box”>

<div class=”top”></div>

<div class=”center”>撒旦法地方 放松的</div>

<div class=”bottom”></div>

</div>

思路三,通过CSS3的属性来实现(鉴于IE系列对于CSS3支持的问题,只能无奈…或者采取灰度使用)

方案1)通过CSS3border-radius属性来制作

<div class=”circle”>文字部分的东西有一大坨玩意,究竟是什么东西呢</div>

.circle{border-radius:5px;}仅仅需要这一个属性就可以随心所欲的制作出圆角;而且,可以制作出不同大小的圆角

方案2)通过CSS3border-image属性来制作

<div class=”circle_bor”>文字部分的东西有一大坨玩意,究竟是什么东西呢</div>

.circle_bor{border-image:url();}

综合来看的时候,如果可以的话,个人还是推崇渐进增强,对于高端浏览器采用CSS3属性,ie低版本保持直角形式;如果过确实需要圆角的时候,最好还是通过边框模拟,相对而言,边框模拟的第二种和第三种相对于而言更好一些

 Posted by at 12:15 上午  Tagged with:
262010
 

由于中秋玩的比较high了,以至于这篇文章出来的比预计时间晚了,对自己提个醒,下不为例….

关于XHTML+RDFa Definition

先讲一段历史:RDF(Resource Description Framework,一种描述数据的语言)的产生,最初是基于XML模式产生的,但是,由于其繁琐的使用方式,一直得不到人们的大量使用;继而后续来了RDFa(RDF in Attribute),在使用方面简单了许多,但是还是基于XML模式的。
幸福的是,尽管RDFa是基于XML模式的,我们依旧有办法使用XHTML+RDFa:
方案一:通过XHTML+RDFa XML Schema的声明来使用;
方案二:通过XHTML+RDFa DTD的声明,将RDFa带入我们日常习惯的XHTML文档类型。
因此,我们可以说XHTML+RDFa是属于XHTML标记语言的;因为它仅仅是通过在RDFa core中定义的一些属性扩展了XHTML,是兼容XHTML和XML的。

故事听完了,我们就来了解XHTML+RDFa。在我了了解的过程中,由于W3C关于RDFa的成员滴活跃,北京时间的8月3号出台了XHTML+RDFa 1.1(之前的版本为1.0),因此我就主要讲述一下这个:
XHTML+RDFa 1.1 的变化:
1)包含了使用XML schema的实现
2)关于lang的使用(此处要注意,lang属性与xml:lang并存的时候,后者优先级更高,并且二者的属性值必须一致)
3)不赞成version的使用(1.0版本中需要在html元素中声明 version=”XHTML+RDFa 1.0″)
4)DTD声明中的版本号进行了变化
5)在继承了原有的基本处理规则,移除RDFa terms的知识到一个默认的RDFa文档资料中
6)有一些RDFa处理规则(如通过base元素指定基准,默认词汇的URI是未定义的等)
由此可见,该定义中对于原有的版本进行了许多完善

看过新旧版本的区别,那么,对于我们想要使用的人,一个严格遵守XHTML+RDFa的文档必须遵循的规则有什么?其实主要是以下几点:
1)文档必须严格遵守XHTML+RDFa XML Schema and XHTML+RDFa DTD(即你有两种可选方式)
2)文档的根节点必须是html
3)根节点的开始标签必须明确的指定一个默认的命名空间,针对XHTML的命名空间URI被定义为:http://www.w3.org.1999/xhtml
起始标签也可以是XML Schema Instance Namespace and an XML Schema Instance schemaLocation attribute

由于接触XML模式较少,就重点说说XHTML+RDFa 1.1 DTD.
至于为什么要用这个DTD?首先,这是W3C规范,既然作为规范咱就得遵守(不遵守标准你就永远不会懂得标准甚至去创造标准);其次,你不写也可以,但是像XHTML中你有机会尝试被带入怪异盒模型中(无尽的深渊…);另外,对应的DTD里面对于标签进行了定义,使用不合规范的标签,只会让自己永远走在别人后面…其实,总结起来就是说:Document type definition 定义了文档类型,让浏览器解析的时候知道该文档是什么,以及其中所规范了的标签等。明白了这些,我们就不再去探讨XHTML中的transitional/strict/framework的区别了,直接进入XHTML+RDFa DTD的知识。
首先,该文档类型由XHTML modules 组成,下面的元素列表作为参考,但是XHTML模块中的定义更有权威性
body, head, html, title,abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var, a, dl, dt, dd, ol, ul, li, object, param, b, big, hr, i, small, sub, sup, tt, del, ins, bdo, area, map, img, meta, noscript, script, base, link, button, fieldset, form, input, label, legend, select, optgroup, option, textarea, caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr
这里面主要是a元素需要注意一下href属性,该属性在该定义中是可以使用在任何元素中的。(可能有人会说有些标签已经淘汰了,例如hr等,尽管该定义中尚未去除这些,但是相信会慢慢休正)
除上述定义外,还定义了一些元数据描述的属性:about / content / datatype / typeof /property / rel、rev / resource / vocab

附一份元数据属性简表:

属性 属性值类型 备注
about CURIE or URI
content CDATA
datatype CURIE or URI 如果没有进行类型标注,默认将其作为字符串对待
typeof TERM or CURIE

or AbsURIs(绝对地址)

resource CURIE or URI
property TERM or CURIE

or AbsURIs(绝对地址)

rel TERM or CURIE

or AbsURIs(绝对地址)

rev TERM or CURIE

or AbsURIs(绝对地址)

prefix ( NCName ‘: ‘ URI )+
vocab URI 当一个CURIE定义为木有prefix和冒号的时候;作为一个定义了prefix的URI

那么,我们到底该如何书写DTD?
先写一个XHTML+RDFa 1.1的,如下:
<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML+RDFa 1.1//EN>”http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd”>
<html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”en”>

</html>

下面这个是XHTML+RDFa 1.0的DTD:
<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML+RDFa 1.0//EN” “http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd”>
<html version=”XHTML+RDFa 1.0″ xmlns=”http://www.w3.org/1999/xhtml”>

</html>
可以自行简单对比一下书写上的区别,不过就目前而言,大多数都是用的1.0,毕竟1.1刚出来没有多久(注意一下的是编码问题,)

最后要说的一个事情就是关于验证,可以直接去W3C的验证网站:validator.w3.org,其中有一项XHTML+RDFa的验证(通过选择more options里面的document type为XHTML+RDFa即可。)

162010
 

不知道该怎么说自己,尽管有些问题自己想的明白,但是还是会不由自主的觉得没有一种工作的满足感…
记得自己之前曾经说过,对于重构,有种找到猎物的感觉,但是,当长期没有感受到自己的成长时,就怀疑自己的猎物了…尽管我知道,人要耐得住寂寞,寂寞是成长它妈。
由于困惑,所以和Tcm聊了一下,先感慨一下:T总真的很牛X,或者说自己从他的话语中总能看到自己的一些问题和一些解决的方式。很感激,一年前T总把我带来了这个平台,其实在这里确实很有意思;也明白了,自己有点困惑的原因在于自己对于计划/规划/执行力度上除了问题。计划,在我这里比较空;之前和室友聊天,人也指出我对事务的逻辑规划不够;今天的聊天,有些东西T总说的很在理,感觉可能有些东西就算自己明白,但还是要有人去旁敲侧击你。就像他说的事例,结果今天下午我就遇到了这个类似的问题,自己于是在那进行善后…通过这个简单的善后,一下子就发现了自己融入的不够,好多变更都不知道有这回事,豁然明白,真的没有简单的工作,只是看你是否全身心的投入。
说了这些,可能很多人不明白自己的想法,但是至少,我知道了自己想清楚了一些问题;心里不纠结了,工作也就顺畅了,继而人就happy了,接着就好好执行自己做的一些计划,顺赞一下,SMART这个东西有点意思,感觉自己的很多问题都在其中明显暴露出来了,很好!干掉这些问题,不就是工作的激情嘛 哈哈

142010
 

之前在组内做了一个RDFa的分享,自己也一直在回想那次讲的东西…简单总结:多而杂,一个字就是…糟…

之后的这一段时间,自己一直在不断关注RDFa的知识,之前整理了一些不过不太满意,但是长期不记录下来,感觉自己思绪越来越多;所以规划了一下,十一之前就把自己整理的东西逐步放上来吧:/p>

言归正传,RDFa,即Resource Description Framework in Attributes。一个众所周知现实是:当前的互联网可以说是一个由无数的HTML/XHTML文档页面组成的,而这些页面中包含了大量的信息数据。可惜,这些数据对于许多工具和app而言,是缺乏意义的,因为他们不懂数据。

像上面这个例子中,机器根本不知道你一个<h>标签就是标题了,也不知道下面<p>标签中的文本就是作者;在机器眼中,标签的不同只是表明了一些权重问题,他不具备人的思维。甚至于,从某种角度来说,网络中的那些页面,是依据我们人类的主观认知去定义的其逻辑结构。而我们书写的标签也并没有准确的去描述那些重要信息。这里扯个事例,爱好摄影的人,肯定都知道EXIF信息;那这个信息有什么用?其实,它就是通过一些具体的信息来描述了这个照片:譬如具体的描述出照片的拍摄时间、曝光时间、相机类型等等…这些信息,直观而又明确,简直让人可以不看照片就能评价这张照片。

同理,在网页中可不可以像对照片信息一样来对我们的网页进行一些描述呢?这个问题,先扯扯自己喜欢的一个实验:从一个网页中拷贝下它的文本段落或者标题到word中的时候,word能够识别它是一个<h>标签,还是一个>p&lt段落等,这只是个简单的关于标签的例子。但是试想一下,如果某一天有一个工具可以完全按照我们人类的思维去解析一个网页,去分析获得网页的作者、文章、标题、参考文献等等,是不是会让网页变得更加利于搜索引擎来抓取数据呢?又假如,某一天我们只需要点击一下鼠标,就可以把网页中结构化数据直接导入另一个软件中,这是不是大大增加用户的体验?就比如说,自己写一大串个人简历,而我只需要一键,就可以提取其中的重要数据,譬如姓名/地址/电话/公司/家庭成员等等……这个想象好美好!可是到底要怎么样才能让机器理解我们的网页,让机器来读懂我们网页的信息呢?怎么样让这些美好变为现实?

对于上述的种种疑问,W3C很早就推出了RDF来解决信息的语义化。但是,由于基于XML的RDF语法过于繁琐,长久以来一直停滞了。于是,更为灵活的RDFa带来了新的变革,RDFa通过增加一些属性及属性值来描述信息,产生RDF(W3C定义的表示互联网中资源的一种语言) 图表(可能有人会说,microformat不也会产生结构化的数据么?关于microformat会在以后进行研究)。经过自己一段时间的阅读整理,这里先介绍一下以下内容:

第一,RDFa的现状
1.yahoo搜索很早就支持了RDFa,而google也在10年3月支持了RDFa,可能这些没有HTML5和CSS3在一瞬间让所有人激动(事实是的确没有),但是,请关注你的搜索引擎对信息的呈现(至于搜索引擎的重要性,不用赘述了吧):

看到这种搜索结果,是不是比单纯的一大段文字对你更有指导性?如果旁边附带一张相关产品的图片,是不是会更加合你口味呢?其实,这一切,google已经在显示结果中出现了,它通过rich snippets来丰富自己的搜索结果。而这些rich snippets,则是由一些结构化的数据描述索衍生出来的。根据google的声明,目前已经支持RDFa的属性如下:xmlns / typeof / property / content / rel ,对于microformat的支持仅限于以下几种:reviews / products / businesses and organizations / recipes / events / people/ review ratings ,但是,从google的相关态势中可以发现,其在不断完善支持的RDFa属性和microformat。

第二,RDFa的优势
一个新的事务,人们总是期望它能带来效益上的勃起(一如CSS3给人打的鸡血…)。那么,RDFa能给我们带来什么益处?
1)对于搜索引擎的友好。即未来我们可能不必依照现在这种繁琐的方式去专门做SEO,可能我们只需要在我们制作页面的时候在页面中嵌入一些属性标签就OK了。
2)带来流量上的引入。就目前形势而言,网购由于其价格的相对优势,已经逐渐成为大家的喜爱支出。试想,人们在网购前在网上的一番搜索,是不是无具体产品意识?即,一个良好的搜索结果,对于吸引点击方面的优势更大。而这,对于成熟的大型商业网站,尤其是电子商务网站,会带来很可观的流量。不需要额外的花销,就可以通过搜索引擎导来更多的流量,相信大家都是开心的。而这个,根据已经采用了此方法的bestbuy的数据显示,对其带来了30%的信息流量增加。
3)网页数据的跨平台跨终端。采用RDFa这种形式,使得网络中的数据可以直接从网络中到许多混搭式的应用中,即不必再将数据与多个api结合以致需要维护多个api。
4)无形的价值。互联网行业中的竞争,不仅仅是效益上的竞争,对于技术上的优势,也可能会给公司带来许多潜在的价值,譬如人才的吸引,业界的口碑等等;如此会产生一个良性循环,继而更加促进发展。
5)……还有更多的优势,需要我们去实践后总结出来,推动更多人
第三,RDFa的未来
当所有人都对HTML5和CSS3而兴奋的时候,当大多数人为HTML5中的canvas / video / audio等标签而惊叹的时候,人们大多无视了HTML5所带来的语义化标签,因为这些没有绚烂的视觉效果和直观的性能优势。但是,试着想一想,为什么HTML5会诞生?语义化的标签出现又是为什么?或许,每个人的想法不一致,但是,在我看来,这是一种趋势,因为,互联网的未来将不会限定在一个庞大而且臃肿的信息网络之中,毕竟,信息量的激增会伴随无数垃圾信息,而作为信息本质的数据,却一如后台的数据表陈列着,是量化的。这些是某次听@twinsenliang的一些分享时所理解出来的,欢迎大家提出自己的看法!另外一个促使自己对RDFa的兴趣增加的是当时公司内部一个关于google与facebook的分享,让自己对于搜索数据的概念有了一个确定,在此表示谢意。

这些,是整理的一段时间一来关于RDFa的初步知识,希望借此提升所有人对语义以及语义网的一个认识;接下来自己会整理出最近一段时间以来关于RDFa实现原理的认识。

052010
 

不知不觉,工作了已经一个月了

这一个月,感觉自己的日子有点平淡,不知道是自己不会的太多还是想学的太多,总是对一个东西三分钟热度:js看了一段时间,php也尝试去了解,但是结果,却都没有掌握住

后来,导师jeanne问我有没有自己的兴趣点;当时懵了:重构?js?PHP? HTML5+CSS?……貌似自己都有去了解,但是也只限于都了解…..看来,自己需要沉下心去钻研一个东西,在广度的同时一定要拓宽深度。之前,总觉得自己不是计算机的,学东西的时候心态不好,现在想起表哥的一句话,学习是需要自己规划一段时间,提高效率的。所以,接下来的一个月,准备潜心去看RDFa的东西

之所以会接触这个,其实是jeanne和ivane提供的一个方向

刚接触的时候,自己去好好的瞅了瞅W3C的RDFa文档,总算了解了其机制,简而言之,RDF in attributes,注意关键词RDF 和attributes

不过,这几天继续看了一下感觉还有很多不明白的,而且由于实际的项目利用好难找,对于确定他的未来感觉有点艰难,就靠着自己的这个BLOG来慢慢改版中实现吧

附带一个:接下来一个月,好好思考一下,如何让自己的代码在后续开发中最大程度的减少修改难度

182010
 

实习了两个月,回去了一段时间后,开始了自己的职场生活。

对于工作,有激情,也有一丝困惑;不知道是不是由于接触计算机的东西太少,对于新知识的获取始终缓慢;不知道是不是太浮躁了,总是想学很多东西;不知道是不是太放纵了,总觉得工作的挑不起那种拼劲。

其实,挺怀念当时做教育网的那种状态,每天尽管只睡很短的时间,但是每天都觉得自己特充实,每天都看得到自己的成长;或许,自己有点耐不住寂寞了,不能平心静气的去学习自己想学的;又或者对于工作的执着不够,总是想这想那的

看到同组的成员的分享,挺佩服,对于自己,也有点小小滴失望咯;不过不在意,自己先好好的打扎实基础,多多练习一下自己的各方面能力。

输在起跑线,不代表失败;勇敢的冲刺,必定迎来终点线