标签：html

在网上看到一篇好文章 ，以前都是加入收藏夹，以后可以打开来看。

其实想转这篇文章好久了，但一直在犹豫。众所周知，如今的pad上的文章、HTML网页，都在尝试着改变。如果让人还在不停的向上拖动页面，好象就会被人所诟病。
于是乎翻页就显得至关重要。
从最早ipad上可见的ibooks中的书籍可了解，翻页其实是一件很痛苦的事情。它需要将你的文章内容由程序自己算好，然后将它分页，于是这里面的代价消耗就非常大。一篇文章如果有上千页，当你选择改变字体大小的时候，ibooks就象死机一样，无法拖动。毕竟这个时候程序在计算页码，重绘页面。超级痛苦，而pad又不象台式机那样CPU强劲。带来的郁闷可想而知。
于是更多的人尝试PDF阅读，毕竟当一篇文章转为PDF后，带来的好处也是显而易见，格式固定，编排方便，可以随意跳转，而且PDF的格式公开，任何人都可以尝试制作它，更关键的是，ipad内建支持pdf(如ibook)。但同时也会有一点小问题，比如，不能调整字体大小，不能插入广告（我想这个对于想赢利的企业来说恐怕是最痛苦的），容易被人打包下走所有数据（企业会更恨这个原因）
当kindle出第二版的时候，很多人都在惊呼，阅读的时代要改变了。国内有个做kindle系统打包的叫做“多看”，它对PDF也做了处理，能够对PDF进行分页，很多国内的电子书用户都选择了多看系统，因为看书更方便了。（它实现的也是类似ibook的效果）
好了，先看原文吧，我废话太多了。。。。原文来自：http://apple4.us/2012/02/card-pagination-scroll-lawrence-column-for-blogweekly.html，我部分摘抄
正如原文中所说：

关于分页与否的讨论自 1980 年代就已开始。苹果 Macintosh 的创始人杰夫·拉斯金用「卡片」和「卷轴」来比喻分页与不分页这两种对信息的呈现方式。到目前为止，万维网（web）基本是卷轴的天下。但电子书的勃兴令情况开始有了变化。

互联网时代大家都清楚，鼠标滚动。。。

和大部分软件一样，电子书软件的设计也能找到真实世界中的对应。正如早年的图形介面系统设计者根据桌面、文件、文件夹、垃圾桶这些办公环境中的标配物件想象出了一套譬喻，电子书软件从一开始就沿袭了纸书的习惯，以「页」为基本单位。另一方面，因为一些不必在此深究的原因，大部分主流电子书软件所用的技术恰恰就是万维网的技术──HTML, CSS, JavaScript，亚马逊的 Kindle 与苹果的 iBooks 都不例外。电子书事实上就是「分了页的网页」。

电子书的读者对于分页与否各有偏好，不过技术潮流由赢家设定。从过去几个月的发展看来，分页是大趋势。亚马逊不久前宣布将推出 Kindle Format 8 格式，将更多平面排版的元素引入 Kindle 书中。苹果的 iBooks 2 与电子书制作软件 iBooks Author 也做了类似的事情，且完成度更高。（其实苹果一直是卡片式设计的支持者。万维网出现之前最成功的超媒体系统 HyperCard 就出自苹果之手，他们甚至把「卡片」一词写进了软件名称。）Flipboard 和 Zite 等热门阅读软件用分页的方式对网页进行了重排，老牌浏览器 Opera 亦于去年启动了实验性的 Opera Reader 计划，目标类似。

这里的终极问题是：设计师应该拥有多少控制权？在发轫于互联网时代的「赋权于民」的大潮流下，设计的权力是否也应该下放给普通用户？如上所述，从信息设计的角度而言，卡片式 / 分页设计的好处显而易见。它为设计师提供了一种具象而直接的限制（没有限制就没有设计）。对于读者来说，上下左右四条固定的边界也对注意力形成了一定程度的约束。这是用户权力的收缩，也是对设计师和内容生产者的控制权的重新认可。若卡片式设计能取代卷轴成为明日的主流，对于内容方实为幸事。

卡片还是卷轴，其实真的很让人难以选择。原文中Kindle Format 8 和Opera Reader 都有链接，有兴趣的可以看看。
说来说去，这又回到了开始：

在纸张出版的世界里，无页不成书。分页的重要性不太会被提起，因为它早已像空气一样无处不在。页界定了包裹内容的边界，是对信息的一种切割──我让你看到的不是全部，而是我挑选过的局部。以页为单位，给了设计师与编辑（编辑也是设计）做选择的可能──没有限制就无需做选择，而做选择就是设计。（包括选择今晚去哪家餐厅吃饭。）

电子书也需要越来越向纸书那样有页码吗？不过，如果真的没有页码，跳转的时候会比较痛苦吧。从程序设计的角度来说，如果没有页码，也就是说几乎要将所有的内容放到一个容器中，而有了页面，为了翻页速度可以直接读取该页码附近左右的各5页内容，会更方便，也更减少资源的消耗。
然而，真的很痛苦，HTML分页太痛苦了。其他的呢？国内的几个ipad上的阅读软件现在都在好象慢慢放弃HTML分页了，而flipboard越仍然在坚持。
那，我们又是否应该再坚持呢？HTML分页有优点，它的优点在于可以很方便的为HTML网页做一些特别的效果。但带来的问题是大量的精力和开发资源都耗在这上面。（国内的专业做javascript开发的，真的很少啊。专业做这一行的，对于切入HTML排版好象也很排斥，不知道为什么。）
如果你是BOSS，你会怎么选择？

最近被人劝唆，准备捡起HTML了。。想从事一下DIV CSS的工程，准备转行做前端吧。。。说说而已，能力太差。
早上借了强哥的书在看，随手一翻，居然翻到了一页，说是在HTML页面里把HTML标记正常显示出来，这个标记好象以前都没有看过。以前只注意了把HTML内容格式化输出。

这两个标签是xmp和plaintext。

例如<xmp><input type="text" /></xmp><plaintext><input type="text" />

这两个标签里的内容，在firebug里可以看出来，被转成类似htmlspecialchar处理过的代码，所以，它们就直接显示在页面上了，也就是说，它里面的内容，如果想再转为标准的DOM结构，还得再作处理，怪不得很多大网站在做DOM转换的时候，都是情愿存存储到textarea里，毕竟在文本框里面，HTML都不用做转义，那是多么开心的事情啊。。。

PS:plaintext是单标签，所以，在它之处的所有内容全部变成了HTML输出了。。。小心使用啊。

白激动了。

今天在RPC里面，阿刁提出个问题，FORM表单中，submit提交的时候，有时候有值，有时候无值 ，想问清楚是什么原因

状态描述：

1、FORM表单中，submit的name是Submit。即 <input type="submit" name="Submit" value="提交表单" />

2、当点击submit按钮时，FORM被提交，提交后获取的数组中有Submit下标的值

3、回到FORM表单，直接敲回车提交，这时候发现获取的数组中没有Submit下标。

纠结的是：为什么会有两种情况的不同

查找原因，最后基本确认，这是由于form在不同情况下，可以直接使用回车进行提交表单而导致的问题。这里有几篇参考文章：不同浏览器对回车提交表单的处理办法和表单提交按钮input和button的取舍。那么，为什么敲回车和点击submit不一样呢？怎么样才能让他们一样？

尝试将focus移到submit按钮上。敲回车提交。这时候，是带有Submit值的。如果focus不在submit按钮上，则无效。知道了问题的原因，那就有解决方法了。对于submit，不要设name值 。如果确实需要传递值 ，请使用hidden域进行值的提交。以防止数据产生偏差。

Zen Coding 一个用来简化编写 HTML，XML， XSL （或是其它一些诸如此类格式的编辑器）。其主要是用一种缩写方式的语法来书写大量重复和无味的HTML，很像CSS语法。下面是一个例子：div#page>div.logo+ul#navigation>li*5>a

效果就是：

<div id="page">
<div></div>
<ul id="navigation">
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ul>
</div>

这玩意是我在PHPRPC群里缘起缘灭推荐的，看了一下，效果还不错。。再去官网看了一下，居然有支持notepad++，很兴奋的下载下来使用了。效果还不错。

如果你一直是在用手写HTML代码而不是用IDE，确实 推荐一下。

上面的演示内容来自：http://coolshell.cn/?p=2406，官网请点击：Zen Coding

PS：如果你真的不会用，没关系，这里还有一个PDF下载下来看看就行了：splitarchivepage.rar

很多做站的朋友都会有一个问题，在显示摘要的时候，如果摘要前有很多图片，那么显示出来的页面是不太正常的。比如，摘要显示100个字符，可是如果前面有很多图片，去掉图片代码后，100个字符已经几乎用完了。怎么办？
我个人是这样处理的。在PHP中，先用strip_tags去除内容中的标签，然后trim一下，再进行截取。这样的话就几乎没有什么问题了。
而这篇文章就有点意思，用作者的话来说，是无损html。来吧看看他写的内容。

最近在做一些内容搜索的工作，搜索出来的内容为html格式，列表部分需要显示每项内容的一部分。因为是html格式的内容，直接截取内容的前多少字符显 然不合适了。而如果直接去掉所有html格式然后再截取又无法达到想要的效果，再网上搜了一通之后，写下如下代码应该可以满足基本的要求了。(js写的， 因为容易调试)

var br = {};
br.spTags = ["img","br","hr"];/*不需要成对出现的标记*/
br.contain = function(arr,it){
for(var i=0,len=arr.length;i<len;i++){
if(arr[i]==it){
return true;
}
}
return false;
}
br.subArtc = function(article,worldNum){
var result = [];
/*首先截取需要的字串*/
var wcount = 0;
var startTags = [],endTags = [];
var isInTag = false;
for(var i=0,len=article.length;i<len;i++){
var w = article[i];
result.push(w);
if(w=="<"){
isInTag = true;
}
if(!isInTag){
wcount++;
if(wcount==worldNum){
break;
}
}
if(w==">"){
isInTag = false;
}
}
/*对字串进行处理*/
var j=0;
isInTag = false;
var isStartTag = true;
var tagTemp = "";
while(j<i){
w = result[j];
if(isInTag){
if(w==">" || w==" " || w=="/"){
isInTag = false;
if(isStartTag){
startTags.push(tagTemp);
}else{
endTags.push(tagTemp);
}
tagTemp = "";
}
if(isInTag){
tagTemp+=w;
}
}
if(w=="<"){
isInTag = true;
if(result[j+1]=="/"){
isStartTag = false;
j++;
}else{
isStartTag = true;
}
}
j++;
}
/*剔除img,br等不需要成对出现的标记*/
var newStartTags = [];
for(var x=0,len=startTags.length;x<len;x++){
if(!br.contain(br.spTags,startTags[x])){
newStartTags.push(startTags[x]);
}
}
/*添加没有的结束标记*/
var unEndTagsCount = newStartTags.length - endTags.length;
while(unEndTagsCount>0){
result.push("<");
result.push("/")
result.push(newStartTags[unEndTagsCount-1]);
result.push(">");
unEndTagsCount--;
}
return result.join("");
};

基本思路：

1.绕过标记，取得实际内容字数 ，如需要显示内容前100个字，绕过标记检索，得到第一百个字实际的索引。然后截取此索引前面的字串。
2.根据一得到的字串，得到这个字串中存在的开始标记和结束标记。注：此处的开始标记标识以"<"开通，且下一个字符不为"/"。
3.剔除2中 得到的开始标记中的不需要成对出现的标记。如br,img,hr等。
4.对比经过3处理的开始标记和2中得到的结束标记，没有配成对的在合适的位置为其配对。

此功能没有经过严格的测试，大家若有兴趣可以可以帮忙测试，有更好的想法的也可以回帖讨论。

--EOF--http://www.cnblogs.com/bravfing/archive/2010/05/02/1725924.html

我没有用PHP的试过，因为在PHP中本身对多字节的支持就不是特别的好不象js，认为中文就是一个字符。不过思路可以考虑一下，但真正要显示摘要的话，当然还是不要含 HTML代码，因为那可能会影响页面布局。

rtf是一种富文本格式，根据RFC的规范，可以将其转为各种文件，如doc,wps等，但如果真的要根据RFC规范一点点的写程序，那就真的太累了。所以。。。我用wps转换了。
以前写过wps生成文档的程序，就是这篇闲着无聊，用WPS生成文档，现在，这个RTF转换到HTML也可以用PHP来完成

<?php
$wps = new COM('WPS.Application');
$wps->Visible = false; //不显示wps界面
$filename = realpath('./RTF_to_HTML_Converter.rtf');
$stime = microtime(1);
for ( $ii = 0; $ii < 1000; $ii++ ){
$savedfile = "c:\\convert\\{$ii}_test.html";
$doc = $wps->Documents->Open($filename);
$doc->SaveAs($savedfile, 8); //参考Document.SaveFormat 属性
$doc->Close();
}
$wps->Quit();
echo( sprintf( "%0.6f" , (microtime(1)-$stime) ) );
unset( $doc , $wps );

测试了一下，生成1000个文件，花了257秒，4分多种，可以接受这个时间，只是在转换的时候，CPU超过50%，而且是在命令行下的。如果是在网页界面肯定是没有这么快的了。
PS:转换后，中文编码实体化了，&#30475;&#30475;&#20013;&#25991;&#24590;&#20040;&#36716;，变成这样的格式，它是什么内容呢？它们就是：【看看中文怎么转】<-- 可以看一下源码，就知道这7个字是什么样的了

这个问题我从来没有遇到过，所以感觉很新鲜。
希望遇到这个问题的朋友看到后能够有恍然大悟的感觉。当然事实上很多情况是，不会有人在头部加注释。。

原文：http://blog.linym.net/archives/474（全部翻译成简体了。。原文是繁体）
前几天学弟问我一个问题，说他CSS排版的网页在大部分浏览器都正常，唯独IE怪怪的，网页中的DIV元素怎么样都无法居中，困扰了他许久，他的原始代码内容大致如下：

<!-- Head area -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Test Page</title>
<style type="text/css">
<!--
#content {
	margin: 0 auto;
	width: 500px;
}
-->
</style>
</head>

<body>
<!-- Content Begin -->
<div id="content">Content</div>
<!-- Content End -->
</body>
</html>
嗯。看起来不应该会有什么问题，那是什么原因让IE无法将DIV居中呢？突然注意到他网页头问那一行注释，因为自己写网页到现在从未在头部使用过注释

果然，拿掉以后就一切正常了。IE，还真是搞不懂你啊！
(注：全系列 IE 都有此现象)

HTML重构，以前是一个新鲜的东西，我也没有理解，博客园上有人在介绍，还写了三篇。。。

我这里只简单的复制点东西，还是以链接为重吧。（战略篇全文如下）

《Refactoring HTML: Improving the Design of Existing Web Applications》是一本精彩的HTML重构指南，作者给出了HTML重构的实践路线和方法。本文是《Refactoring HTML》的读书笔记，按照我的理解将全书的分为：战略篇，战术篇，工具篇。

本文是战略篇：全局方略的角度介绍重构的内涵，原因，时机，目标

嗯哼，我们开始：

进行重构就像打一场仗，而战争的发起是要慎重考虑的，《孙子兵法》里面讲“兵者，国之大事，死生之地，存亡之道，不可不察也。”所以动手重构之前首先要回答下面几个问题：

• 什么是重构？
• 为什么进行HTML重构？
• 什么时候进行HTML重构？
• HTML重构的目标是什么？
• 面对质疑：还要重构么？

什么是重构 Refactoring?

本书侧重实战，没有《UML Distilled》那样高屋建瓴的抽象，即使有抽象，抽象层面牵扯的细节过多(这一点在后续的阅读中也可以发现)。这一部分内容我援引了《Refactoring: Improving the Design of Existing Code》对重构的定义：

Refactoring (noun): a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactor (verb): to restructure software by applying a series of refactorings without changing its observable behavior.

为什么进行HTML重构？

抽象地讲，HTML重构的可以让代码更能适应变化，应对系统和领域需求为新功能的开发提供更优秀的基础。

具体地讲，HTML重构可以：

• 让代码更具有可读性，更容易理解
• 重构过程中往往有意外的收获：发现隐藏的系统Bug
• 增强页面可用性， 关注点从设计者开发者转移到使用者
• 缩短提高页面的呈现时间(Slow pages -Rendering Times)
• 解决页面浏览器不兼容问题
• 搜索引擎优化Search Engine Optimization

进行HTML重构的时机?

• 每一次进行重新设计之前；新功能将构建在一个更稳固的基础之上
• Refactor When You Need to Fix a Bug
• Refactor As You Do a Code Review
• 一个原则:勿以善小而不为；重构的过程往往是断断续续的，很少有一个连续的时间给我们进行重构。所以我们只要有机会进行重构，就动手去做吧

HTML重构的目标（What Refactor To） ?

• XHTML
  理由：XHTML更加严格，浏览器不再解析乱作一团的标签而是格式规范的页内容，这时负担从浏览器转移到页面开发者。内容聚合，搜索引擎优化，样式表都可以更好的应用基础。开发者能够更容易调试和解决问题，因为问题更容易定位了。XHTML不能完全解决浏览器兼容问题，但是它能够消除大部分的浏览器不兼容问题已经居功甚伟。主流HTML编辑器都提供对XHTML的支持。XHTML是未来Web应用提供坚实的基础，如：MathXML MusicXML SVG。
• CSS

理由：将展现层从内容中分离出来。为不同的阅读者提供高可读性。减少代码重复，节省带宽。

• REST

REST(Representational State Transfer表述性状态转移)是一种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了一些设计概念和准则：

1.网络上的所有事物都被抽象为资源（resource）；

2.每个资源对应一个唯一的资源标识（resource identifier）；

3.通过通用的连接器接口（generic connector interface）对资源进行操作；

4.对资源的各种操作不会改变资源标识；

5.所有的操作都是无状态的（stateless）。

REST之所以能够提高系统的可伸缩性，是因为它强制所有操作都是stateless的，这样就没有context的约束，如果要做分布式、做集群，就不需要考虑context的问题了。同时，它令系统可以有效地使用pool。REST对性能的另一个提升来自其对client和server任务的分配：server只负责提供resource以及操作resource的服务，而client要根据resource中的data和representation自己做render。这就减少了服务器的开销。

重构的目标不是金科玉律，你没有必要逐一进行实践。你可以按照XHTML->CSS-->Rest的顺序按部就班步步为营，也可以根据实际情况调整重构目标和计划。但是只要你做了，你就可以从重构过程中得到好处。

面对质疑：还要重构么？

重构的本质决定了它不是生产性的，重构的完成并没有新功能的产生。所以重构往往面临来自各方面的质疑：

• 重构就是在浪费时间，我们还是开发新功能吧

面对质疑我们给出这样的答案：

• HTML重构从长远来看为后续开发提供了一个良好的基础，实际上是节省了时间。因为系统更容易添加新功能，更容易维护。重构的过程能让开发者对以前的工作有一个思考，对新人是一个熟悉系统的机会。
• HTML重构本身并不会占用太多的时间，因为我们有很多自动化的工具可用。
• HTML重构不需要一个连续的时间，断断续续的时间未尝不可，对于开发者来说，进行重构就像日行一善。

HTML重构：战略篇

HTML重构：战术篇

HTML重构：工具篇

之所以再写一次，是因为看到了IBM上的一篇文章，时间也比较早，我在以前也写过一篇简单的文章来进行介绍，不过这篇IBM的写的比较全，而且我以前的写的也仅仅是评论，并没有就COMET的技术进行详细的介绍。

IBM上是这样说的，这只是简单的摘录一段，详细的还是到该页面去看吧，因为IBM的页面说明了有版权限制，而如果要申请复制文章的话，又比较复杂和繁琐，因此，只能这样了：

传统模式的 Web 系统以客户端发出请求、服务器端响应的方式工作。这种方式并不能满足很多现实应用的需求，譬如：

* 监控系统：后台硬件热插拔、LED、温度、电压发生变化；
* 即时通信系统：其它用户登录、发送信息；
* 即时报价系统：后台数据库内容发生变化；

这些应用都需要服务器能实时地将更新的信息传送到客户端，而无须客户端发出请求。“服务器推”技术在现实应用中有一些解决方案，本文将这些解决方案分为两类：一类需要在浏览器端安装插件，基于套接口传送信息，或是使用 RMI、CORBA 进行远程调用；而另一类则无须浏览器安装任何插件、基于 HTTP 长连接。

将“服务器推”应用在 Web 程序中，首先考虑的是如何在功能有限的浏览器端接收、处理信息：

1. 客户端如何接收、处理信息，是否需要使用套接口或是使用远程调用。客户端呈现给用户的是 HTML 页面还是 Java applet 或 Flash 窗口。如果使用套接口和远程调用，怎么和 JavaScript 结合修改 HTML 的显示。
2. 客户与服务器端通信的信息格式，采取怎样的出错处理机制。
3. 客户端是否需要支持不同类型的浏览器如 IE、Firefox，是否需要同时支持 Windows 和 Linux 平台。