然 而通过JavaScript生成的应用程序，需要创建这样一个拥有`name`属性的标签。是的，可以通过document.createElement 创建节点，然后赋予属性`name`值。事实应该是这样的，不过IE有些让人失望，这样赋值的`name`值无法通过 document.getElementsByName('input name')引用，也不能用document.forms['form name'].elements['input name']的方式引用。不过IE提供了另外一种方式创建节点：
// 查看Microsoft: createElement Method
document.createElement('<tag attribute="value">');
这个方式不兼容于非IE浏览器，创建时需要进行浏览器检查。
创建form时，Hangring的做法是，`name`,`method`,`enctype`三个属性一同在标签中创建；一般赋值方式，会导致IE无法上传文件。
另 外，对于何时用document.getElementsByName方法，这样看哪些标签拥有`name`属性。在合适的标签用 document.getElementsByName，而其它的用document.getElementById，避免混淆。因为在IE下，前一个方 法如果取不到`name`，会去取`id`的值，程序达到一定规模，将是个噩梦，而且这样的方式根本不兼容其他浏览器。
创建input标签后，首先应设置属性`type`，然后再调用appendChild()方法，IE不支持添加到节点树后改变input类型。
一般的隐形，或是直觉上的，可以这样理解：所谓隐形，是某个人或物突然看不见，从所在的位置消失了，而且其他人或物不能简单的触碰到他（它），其实并不是真的消失了，因为作为本体，他（它）还是存在的。
这出现了两种情况：
一、隐行可以连带身上的衣服等配件一起隐行
二、隐行只是身体隐行，其它非身体所属部分自动脱落
情况一、不知道为什么大多情况下会认为是可行的，因为关联到自身的羞涩感？因为如果自己拥有隐行的能力，可不希望一隐行就变成了裸奔那样的糟糕情况？于是那么多导演也是这么想的？假设他们也是一般人（本来他们就是一般人：P），也是这样的想法，他们也没有挑战这个似乎不合逻辑却看起来相当合情理的玄妙问题？
情况二会更加合理，反而合理到使人惊愕，所以从视觉上要排除Yellow的成分。可以理解有所遮掩是必要的。不过，如果你自己练习，请忽略这一情况^ ^。
要是所有的隐行都按照情况二的发展，那真是索然无味了。
《神奇四侠》，《时间旅行者之妻》就是按情况二的方式，不过后者不是隐行，而是时间旅行，而且还是被动时间旅行。
关于时间旅行或时空旅行下面谈论。
对情况一做延伸讨论吧。在这之前先说说《哈利·波特》里的隐行衣。一个问题一直没想明白，为什么那隐行衣一穿上就能隐行了呢？有两点，1、人隐行了，2、隐行衣也隐行了。不可否认，不能简单的来看那件隐行衣，罗琳有给那件隐行衣下个定义吗？这似乎不重要，即使下了定义，出现悖论也会有争议吧——不过那段回去过去的故事实在很棒。
隐行衣的疑点同样是情况二的疑点，隐行衣可以看成是情况二的特例。这样就集中到一个点上：是什么触发这个事件——也是就是隐行——的发生？既然物体是“死”的，焦点自然转向了人这一边，启动的因素应该是由人决定的，这个就可以解释为什么在未被人使用时事件没有被启动。不过在《哈利·波特》中又没有看到在使用时进行命令的下令过程，这就存在疑点了。不过别忘了，回想一下里面的故事，你会发现，那些都是魔法道具，就是说可以为一个物体下咒，使其在特定情况下或着是响应某种召唤而启动事件发生。
回到宽泛的情况二上，虽然不知道其他隐行类型，不过大抵上都有无形的驱动事件发生的过程。
如果看了 《hunter x hunter》，可以获得另一种视觉上的理解。里面讲的也是超能力：念力。那是从人体内发出的，需要一定的技巧,
-
XX: “那是什么样的技巧呢？”
Hangring: "别问我，白痴。"
-
通过精神力来控制，可以防卫，也可以伤人。故事发生在小杰和奇讶进入贪婪之岛，在进行念力训练时出现的，比斯基要他们两个用铲子挖一座座小山丘一直到YY城(忘了名子了：P)。起初他们用平常的方式挖土，没多久就累趴了，然后接下去他们才意识到，可以通过念力传递到铲子上，将铲子视为身体的一部分，这样挖起来就轻松多了。
发现通过念力作用于物体上以便它也成为身体的一部分。那么是不是可以理解为，人因为隐行了，然后将隐行的因素作用于身上的其他物件上呢？
飞行的能力有没有相似之处了，是的，飞行的能力似乎不需要考虑隐行牵连的物体性质改变的问题，因为人体在飞行时足够力量托起身上的东西了。但，飞行和时空旅行或瞬间移动（简称瞬移）有共通的因素。
飞行可以看作是瞬移的特例了，当然行走、跑和跳跃都是瞬移的特例，瞬移是在一段时间内移动的距离，至于途径确是有很大差别的。飞行构建于人的期望上，显然每个人都想知道它的途径，不过，我看还是算了吧，脚踏实地做人为好：P。
不过时空旅行确有更大的吸引力。游戏《家园》里的太空船有时空跳跃的过程，就是在两个空间之间开启了一个虫洞，这就达到了瞬移的目的，而这个虫洞就是上面说的途径了。
还记得《暗黑》里的时空门，难道那不是虫洞吗？
关于时间旅行，也可以说就是不同时空里面的瞬移了。不过当你没办法主动控制（产生）虫洞的能力，是不是就像《时间旅行者之妻》的男主角了呢？希望你运气不错:)。
所以瞬移也是不需要改变身体之外其他物件的性质的。
相信的人抓住它，怀疑的人审视它，否定的人无法从中获得任何东西。
文章：http://www.cnbeta.com/articles/52410.htm。读一读，能获得更多的了解。文章里的比喻很有趣。
最近在看《禅意花园》，最近因为可用性、可访问性而发现之前考虑的东西还不全面，也许之前是为设计而设计。
如果说table是为表现而设计的，那么div就是为区分内容而设计的；table涉及的呈现方式的部分，而div则只作为容器而存在，因为这个不同，所以通过CSS控制div更加灵活。
一个页面应该包含尽量多的内容，尽量少的标签。
也许可以这么做：尽量少用奇怪的css hack。真的没有hack不行吗？(并非指不同浏览器自身的专属属性。)
图片替换技术是针对可访问性问题，具体是用来帮助屏幕阅读器使用者能正常浏览页面。具体可浏览http://www.alistapart.com/articles/fir/。
有一种布局方法使用http://www.alistapart.com/articles/negativemargins - 负边距解决方案。
关于浏览器渲染问题，在能用visibility属性时，不应该用display属性，前者的效率比较高。(尚不知道IE与Mozilla是否相同)
JavaScript是解释型的，代码的多少，表示每一次就要下载多少，执行多少，功能效果和代码数量存在矛盾了。C/C++, Java, C#等等就很舒服啦。
事情一拖再拖，本来想早早的完成一个基本功能，真是惭愧。现在已经有了些进展，所有的思路也都比较清晰，接下去做的就是整合起来让它能运行得通了。
了解具体的功能说明请移步：[ayd]SQLite Browser。
View image
View image
View image
var str = '<font color="#ff0000" face="Arial Narrow" size="1">\
gfdjdsfl;dsjfdsl\
</font>'; var arr =
/<font\s+
(?:(size="[^"]*?"\s*)|(color="[^"]*?"\s*)|(face="[^"]*?"\s*))+
\s*>
((?:(?!<font>).)*?)
<\/font>
/.exec(str); // 由于显示问题，因此格式化为当前显示方式 alert(arr); // Firefox 与 IE的结果不一致。
此处暂时标注。
End.我们看到桌子上有一些纸样，这是直接从设计师那里传过来的最新设计图样，工匠们会根据纸样上的图案做出金属样品，将每一粒宝石的大小和镶嵌位置准确地呈现出来。当一切都准备完成，真正的工程就开始了。金属工匠制作出金属框架，负责清洁的工匠会精心地将每一个细小的角落都清洁干净，专门打磨宝石的工匠会小心地将每一粒宝石都打磨出要求的形状和大小。然后由镶嵌工匠负责将宝石合金属框架和成一体，最后还要经过打磨和抛光，一件价值连城的珠宝作品才真正完成了化蛹成碟的漫长经历。—— 摘自<VISION>
母系社会早在成文史出现之前已大部消逝(请自行翻墙)。在原始母系社会，女性从事采集和原始农业，制备日常衣食并主持家务，重要的是部落首领是女的。——光阴似箭，日月如梭，不知过了多久——大约在四千年前，开始了父系社会。不知道父系社会是怎么产生了，就如同不知道母系社会是怎么产生的。区别于其他动物的人类的意识更加的活跃。能说明的应该是从女娲开始，人类是由女娲造出来的，所以女性崇拜也是理所当然。事实上，可以以为证据的可以说因为女性是孕育的新生命的载体。关于崇拜，这个只是人类的事，就这样产生了。
父系社会的出现，也许是因为女性的体力方面的限制，无法从事一些体力方面的劳动吧。不过有所偏颇。按罗素说的，母系社会是出于自然的冲动或本能，而父系社会却不是出于本能。
关于母系社会转为父系社会的种种因素，讲的许多也会变成摘录，因为许多大师级别的人做了研究，了解可以看看罗素的书(这里)。
关注并非自始至终在一个点上，不管怎么开始的母系社会，又怎么转变为父系社会，再到现在处于模糊期，将来处于平和。或者三十年河东，三十年河西吧。难道说人类本能有一种不安定因素，或者人类一直在寻求并实现平和。也许绝对的发展将达到一定的极限状态，极尽完美阶段，在相当长时间里停止前进，或转入其他状态。
在还没达到极限之前，需提升所有层面使其相应协调。设计师的设计图样、金属工匠、清洁工匠、打磨工匠、镶嵌工匠，这些层次上的人员都是发展使其协调的对象，或者说他们也许在不同的历史时期有着不同的关注指数。某个时期我们在赞颂设计师的设计技艺，因为有他的完美的设计才成就了价值连城的珠宝。而在另一个时期我们会赞颂金属工匠或镶嵌工匠。但，那样的时期在慢慢削弱，因为一直保持那种情形会使更多的能量更快的转化为熵。
所有的非本能的更多的新的思考和需求，属于人类的，在进化的过程中。
.......
下次继续。
End.如果不用component来开发，可以想象花费的时间需要多长。虽然可以像以往用Flash来开发，应用一般自定义皮肤等等，但我们想快速开发——别人是快速开发吗？我不知道——不过问题转移到了另一边。
问题开始于对DataGrid的单元格自定义，那时想为某个单元自定义一个类，如可以定义那个单元显示为下拉列表等，这个问题从现在来说应该是没有挑战性，种种迹象表明只需要设置itemRenderer属性，而且也是在看文档和在网上找到了解决方法(文档与网上资料都是标签式的解决方式)。在这个问题解决之后，发现困难转移到了另一边：如何获取单元格的自定义对象？这个问题足足折腾了快要一周吧，阿斌和我可真具有耐心啊，研究并继续发现问题，哈哈。在早之前，阿斌通过debug去查找DataGrid里的内容，发现所有的东西都可以在那里找到，我也持续的在做这件事情，不过发现所有的东西都在私有变量中，无法从外部直接引用，那时可真是昏了头了，没有想到应该通过继承去获取那些值，而这是几天后的事了。
问题没有结束，以为能引用到内部的对象就可以“造火箭”了，这是我那时跟阿斌说得笑话。事情上，Flex中的组件存在一个问题：控件容器在于标签形式呈现时，是可以设置百分比的；而以脚本的方式书写确没办法设置百分比（或者我没找到这样做的方法）。在这问题上，我绕了个弯才把这个问题解决了。如mx.controls.Tree，先定义成module，然后通过脚本实例化，这样转换个角度进行操作；还有以上DataGrid的定义（包括可以访问单元格对象的功能），可不是这样简单做就可以了——如果不包含访问单元格对象的功能，那么操作的方式与Tree是一样的——首先，继承DataGrid类的oDataGrid拥有访问单元格对象的功能，然后通过oDataGrid自定义一个component名为：<controls:oDataGrid>，接着定义一个模块mDataGrid，模块里应用<controls:oDataGrid>component，最后一步就是通过脚本实例化mDataGrid，实例化的对象会以高宽百分百的方式占据它的父容器，这样才算完事，过程如下：
DataGrid -> oDataGrid -> <controls:oDataGrid> -> mDataGrid
老实说，这个用起来相当的效率不高，也许应该把拥有访问单元格对象的功能独立出来，这样可以减少以上步骤。
遇到的问题也都在解决中，此处仅作为标记。
End.我们留下了Email在个人主页上，或回复别人的Blog文章，或给别人留言，我们的本意是想尽可能多的与人交流，但是这让SPAM机器人有了可乘之机，它们是这么容易的从网页上获取Email地址然后无耻地狂发垃圾邮件。
为了阻止裸露的Email被SPAMBOT提取，需要采取一些措施来防止。之前有人会这样写：you AT host DOT com，这虽然可以防止SPAMBOT，却对用户不友好，而且也增加了用户需要手动修改Email地址，这就降低了用户与你交流的可能性。或者有人这样写：
<script type="text/javascript"> document.write("<a href='mailto:you@example.com'>email me</a>"); </script>
虽然这是通过JavaScript来执行，可以正常显示Email给用户，但是并不能阻止SPAMBOT的提取，因为SPAMBOT在很大程度上只是查询所有html代码，并且匹配Email格式的内容。
有一些处理方式，在很大程度上达到组织SPAMBOT的效果，可以用Email Address Encoder来编码你的Email，或者使用The Enkoder Form。这两个都是在线提供Email编码的，还有这里（Special Characters - notes and investigations 1）提供特殊符号的对照表。
另外，ALA提供了一个现成的PHP程序可以用来编码(Win the Spam Arms Race)。
如果你想了解更多，请看下面链接，希望你能获得更多有趣的内容。下次我再介绍另外一篇文章所讲的内容（Graceful E-Mail Obfuscation），希望你感兴趣:-)。
正在写这篇文章的这个时候，在10分钟前刚删掉20左右封SPAM，现在已经又有两封了 :')。
End.
