最近较多地使用到了960gs,我更喜欢把它的所有css文件压缩成一个,作为公共库被页面包括起来。期间倒是遇到几个让人抓狂的问题,导致莫名其妙的状况出现,还得我很长一段时间都不知道是为什么。最终目标锁定到压缩的960gs,经过严密排查才发觉症状所在!正好,引以为戒,自己动手修改了其中某些地方,也算加深了对一些浏览器之间差异的了解。

以下便是曾经遇到过的一个头疼问题:

先来看页面1:/wp-content/uploads/2009/11/ie-bgi-bug-1.html。非ie下是正常的,ie中背景图无法显示。仔细查看css,没啥大问题啊,难道是第8行默认设置(960gs就把所有元素的背景色设置为透明)搞的鬼?

把第8行删了,页面2一切恢复原状:/wp-content/uploads/2009/11/ie-bgi-bug-2.html。十分搞不懂这是为什么,或许是个很低级的问题吧,忘知道的人赐教。

再来看页面3:/wp-content/uploads/2009/11/ie-bgi-bug-3.html。依旧保持第8行默认样式,但为ol设置了一个高度,于是乎ie6完美呈现,其它的只显示一半。很简单ie6会自动撑开高度。

最后是页面4:/wp-content/uploads/2009/11/ie-bgi-bug-4.html。保持第8行默认样式,不为ol设置高度,但为ol的li设置了个宽度(width:1px;高度也一样),于是乎所有的浏览器都皆大欢喜。

这个bug原本的表现是在一个很复杂的页面中,为一个ul的li设置backgroundimage出现的。结果ie6下出现了闪烁,鼠标移入移出都会造成其不稳定的显示、消失或闪烁。我本以为是老bug了,借用document.execCommand便可搞定,哪知道根本不起作用。最后花了好多时间,才弄清楚。

高亮环境

说到为网页添加代码高亮功能,使用服务器端语言处理无疑是更高效、更兼容的做法(比如基于PHP的GeSHi)。然而这一方式主要面对的问题有三个:

  1. 加重了服务器负担,每次读/写都要将代码解析成正确显示的结果,而且代码过多时传输解析结果也会浪费一定的带宽。
  2. 增加语言种类或者维护升级时更新高亮程序相当费事,倘若支持热部署并且没有集群时还轻松些。
  3. 服务器存储的结果是原始的代码还是高亮后的结果?前者会使得每次读操作都要解析一下浪费资源;后者在修改原始代码的时候则会造成一定困难。引入缓存机制或许是个解决办法,但缓存本身就会增加技术维护量。

抛开服务器端,倘若这一切采用web端来做会是怎样的结果?

  1. 每次读时都要将代码解析成正确显示的结果,然而这一切是在客户端做的,与服务器无关,也不会浪费带宽。
  2. 维护高亮程序就是维护前端程序(js或者as等),成本要低得多。
  3. 服务器存储的是原始代码,不影响代码本身的修改,只需做简单的过滤即可,完全脱离了高亮逻辑。

也正是如此,web端语法高亮成为了主要的潮流。目前web端流行的编程语言无非js和as,silverlight尚需时日。其中js虽然有点兼容性问题,但在前端开发工程师手中早已有无数破解之道;as拥有跨平台、高性能以及良好的OOP支持(这里as主要指as3,下同),却未必如js那般近100%的支持。由此,现在能见到的web端高亮器几乎都是js写的,除了jssc(jssc前3版也是js写的,名称前缀即因此而来)。

对比参数

既然目标锁定了web端语法高亮器(废话,要不然文章标题不是白起了),那么衡量一款语法高亮程序就有了针对性。无非从以下几个方面进行对比:平台支持和兼容性支持语法种类程序体积大小解析速度(性能)解析结果正确性功能体验可扩展性

  1. 平台支持和兼容性

    无疑只有js和as的对比。

    兼容性不说,as生成abc字节码跨平台支持,只需有avm虚拟机(Flash Player的虚拟机)支持即可;js虽然在各个核心中表现不同,但对前端开发工程师来说并不构成问题。

    可到了平台支持上as就不完美了,毕竟它要依靠avm才能运行——这可能是用as来编写高亮程序唯一的弱点了,尽管Adobe吹嘘fp的普及率有97%;而js却在现代浏览器中得到普遍支持,除非客户端手动关闭它。

  2. 支持语法种类

    这个要看作者原意提供多少种语法支持了。提供的语法当然是越多越好,但同时出现的问题就是写程序的人必须通晓所有语法特性才行。不可能幻想一个高亮解析器能够自动对所有编程语言进行正确解析,除非掌握这门语言的基本语法知识。

    这对作者来说是个相当大的挑战,因为不可能一个人能够知晓所有编程语言的特点。良好的做法是设计好接口,让其它有兴趣的人参与进来,编写未实现的语法高亮程序。

  3. 程序体积大小

    这点其实和上面一条互斥,支持的语法越多自然体积会更大。可行的办法无非一方面尽可能减少程序本身大小,提升代码复用读;另一方面用按需装载或按需组合只加载用到的那一部分(JSI?)。

  4. 解析速度(性能)

    as在这方面有着先天性的优势。js则不一样了,依赖于引擎的不同,各浏览器的表现也不一致。而且,为了优化算法提高性能,js编写的高亮引擎往往需要牺牲一定的准确性来达到目的。

  5. 解析结果正确性

    这个上面提到了,最正确的做法无非是针对某种语言的词法分析。然而这样做势必对实现语言有着很大的性能要求,js目前还是远远不能够胜任的,它只能采取某些方法进行折中,使得结果尽量正确。当然那些难以高亮的代码很少有人去写。

  6. 功能体验

    行数、复制和折叠功能是最基本的。行数统计无需任何干预,html本身的ol节点就是顺序列表,自动支持行数;复制在各个浏览器下表现不一,最终还是需要通过flash player来实现(从这一点上说,无论任何前端高亮器其实都用到了js和as,只是侧重点不同);而折叠功能只能通过词法分析来准确实现,as的优势再次体现出来。

  7. 可扩展性

    和第2点一样,要增加语法种类同时就考验了程序的可扩展性。目前所有高亮器都有着不错的支持,js高亮器需要注意的是提取所有语言的逻辑共性,词法分析则要针对每一种语言编写lexer,提取同类语言的通用部分。

高亮解析方式

这可能是初心者最关注的问题之一了。我们最终的目的是正确将一段代码解析成能够在网页上显示的结果,因此如何实现这个解析器(我更习惯这样叫它,因为jssc就是基于词法分析的,倘若是其它方式,称呼为高亮器可能更准确一点)的逻辑,便成了核心。从2007年的jssc 1开始,我大抵尝试过3种基本模式,这也是目前前端高亮器中被广泛采用的。以下将一一叙述它们的优缺点:

  1. 正则模式

    说到高亮一段未知代码,可能你第一反应就是使用正则。没错,基于模式匹配来高亮程序代码,这个方法至今都被大部分人所采用,只是在它基础上进行了许多加工。考虑到如下js代码(以后例子都将以javascript举例):

    典型的编程语言主要需要高亮以下几个部分:关键字(保留字)数字(整数和浮点数)字符(字符串)注释

    其中关键字无法精确匹配,但每种语言对关键字的结构都有明确规定,如:以美元符号、下划线或者字母开头,后跟美元符号、下划线或者数字字母,如此用正则找出所有这种组合,再比较是否预留关键字即可;然而数字、字符、注释都具有一定的格式,采用正则很容易做到:

    /^[$_a-z][$_a-z0-9]+/i、/^\d*?(\.\d+?)?$/、/^(“|’).*?\1$/、/\/\/.*?\n/。

    这里面其实有很多问题,等到以后我们就会知道。

    /*这个例子很简单,只需用正则匹配出多行注释、单行注释、关键字、字符串和数字即可。*/
    for(var i = 0; i < 10; i++) {
      var s = "NO. " + i;
      alert(i); //循环10遍
    }
  2. 分区正则模式

    最大的问题来自于交叉混合。试问:引号中出现注释该怎么办?注释中出现关键字怎么办?字符串跨行怎么办?数字在字符串里怎么办?这些都还只是初级问题,就能把正则模式完美KO掉,因此高亮器不可能只采用正则匹配便解析出所有。

    仔细观察,问题的关键点在于交叉混合,只要把这个解决了,那么一切都如见天日。简单的做法便是在开头增加个预处理过程,将代码分成区块。

    我们遍历代码字符串,遇到引号(无论单双引号)便寻找下一个引号。找到后要看是否被转义?一般情况下回答是否,那么这个区块也被分隔出来;但总有需要的情况出现,此时我们忽略它继续循环往下找,直到找到没被转义的字符串为止。

    同样的,注释也是一样,不过注释有个好处是不存在转义问题。单行注释直接到行结尾,多行注释直接到结束注释符(*/)。

    /*这个例子只用正则是做不到了,注释中有"字符串",字符串里可以有数字或关键字。
    因此首先要做的是将代码分区,提出可能混淆的部分。*/
    for(var i = 0; i < 10; i++) {
      alert("alert 10 times, this is NO." + i);
    }
  3. 词法分析模式

    新的问题来了。perl风格的正则表达式该怎么办?回答依然是分区,不过这可能有点困难,因为你很难将跨行除法与正则表达式区分开来。当遇到一个除号时,它可能就是一个除号,也可能是一个正则表达式的开头。想弄清它就需要回溯,根据之前的语境来判别。另外perl风格的正则表达式的flag亦是一个难点,分区很难将它们包括进来。正则表达式的字符集([]内的特殊符号可以省略转义)允许省略转义符,它处理起来也是相当得麻烦。

    那么,有没有更好的解决办法呢?我们需要一个圣杯,来完美地实现解析要求。最终,埋藏在宝藏中的词法分析浮出水面。

词法分析概念

那么什么是词法分析?

简单来说,它是《编译原理》的基础入门知识。构造出来的编译器,在对我们平常书写的程序代码进行分析时,第一步所做的就是词法分析。具体的工作是,从左到右遍历源代码字符流,根据构词规则识别单词。比如如下代码:

var i = 0;

经过分析器后生成:

  1. var 关键字;
  2. i 变量名;
  3. = 赋值符号;
  4. 0 数字;
  5. ; 分号。

可以看出,词法分析将源代码切割为一个个最基本的逻辑单元(token),并去除了注释、空白等无用的符号。这和语法高亮很相似,借助其基本原理便可做出一个相当不错的解析器来。

jssc5正是采用了这种方法。

web端语法高亮器到底是什么时候开始流行的?

SyntaxHighlighter发表于2007年;SHJS的网站上写着copyright © 2007的字样;google-code-prettify的开源项目主页,最早的反馈亦是Mar 2007;就连jssc的雏形也是出生在2007年初的一堂《编译原理》实验课上。这一年,似乎成为高亮web代码的热潮期。

然而,一切仅仅是开始。随着Yahoo官方采用sh(SyntaxHighlighter),用js编写的它一夜成名。sh的确是目前所有已知web端语法高亮中最出色的一个,许多网站都在使用这家伙,它的地位可以称得上是霸主。不过,开源世界的代码永远是竞争激烈的,其它高亮器如雨后春笋般诞生,互相之间无不在攀比性能、功用、大小等等。记得在jssc 2发表的时候,还是个学生的我就把矛头直指sh,意欲一较高下。当然,结果就是另外一回事了。

时至今日,jssc历经5个版本,各方面都已发展至成熟。然而技术推动却一直只有我一个人,各种因素都有,技术门槛肯定是最重要的一个。于是,我决定开写一个系列文章来介绍web端语法高亮原理——不仅仅是帮助jssc的发展,更是为了共享经验、推动web端高亮技术的进步。本篇文章就是作为序言而写的。

以上即是简单的概念介绍,下面是系列文章的目录,链接不定时更新:

  1. web端语法高亮原理:走进jssc的世界(一)
  2. web端语法高亮原理:走进jssc的世界(二)
  3. web端语法高亮原理:走进jssc的世界(三)
  4. web端语法高亮原理:走进jssc的世界(四)
  5. web端语法高亮原理:走进jssc的世界(五)

十月 30th, 2009

修复了jssc 5 beta中的两个错误

No Comments, jssc, by army8735.

本着想写系列文章《web端语法高亮原理:走进jssc的世界》,介绍jssc的历史和核心算法的,结果无意间发现两个bug,真是丢脸啊。

一是数字高亮的bug,最终处理上居然一小步布尔逻辑写错了,造成长串数字的误认;二是ie下的复制按钮,定位的复制对象居然是“关于”,而不是源代码(少了个parentNode)。

这么明显的失误啊,真想跳楼谢罪了……

话归正题,系列文章会逐步出炉的,将jssc的一切毫无保留地叙述出来。这次失误的收获倒是知晓了其它几个web端的语法高亮器(以前只知道syntax highlighter,貌似也是最知名的),其中最吸引我的是prettify,貌似是google官方的东东。不愧是大佬啊!拿我常用的一段js代码测试了下,prettify是目前我所知js解析器中最为准确的!当然还有一点点小瑕疵,那就是正则的flag(i、m、g)没有跟随正则一起被高亮。不过最让我搞不懂的是,相对简单的flag没有解析正确,反而更难的跨行除法却做到了。

以下是我常用的测试代码,如果web端语法高亮器能解析到jssc的程度,才能够说明是正确了。

//javascript
function none(){
}
/** javascript
jscript
*/
var reg = /[\/][*]([\S\s]*?)(?:[*][/;\[\]]|$)|[\/][/g;](.*)|"((?:\\\\|\\"|[^"])*)"|'((?:\\\\|\\'|[^'])*)'/gm; ''; /\d/.test(1);
reg = 12;
a / b
/reg/;
var num1 = 0.541f;
function f(test) {
    return (test/*
    /* //
    ' "
    { ;
    \*/ && // /* // " ' { ; \
    test &&
    " /* // \
    \" ' \
    { ;" &&
    ' /* // \
    " \' \
    { ;' &&
    test);
}

十月 29th, 2009

获取元素的绝对位置

1 Comment, 前端开发, by army8735.

要说getPosition()的起源,可能没人说得清楚。但是网上广为流传的这段代码,却是许多人使用的:

function getPosition (el) {
    var left = 0, top = 0;
    do {
        left += el.offsetLeft || 0;
        top += el.offsetTop || 0;
    } while (el = el.offsetParent);
    return {x:left,y:top};
}

它真的正确吗?答案当然是否定的。至于为什么,看完Mootools的Element类的相关实现,一切就会大白于天下。

Element.implement({

	getScroll: function(){
		if (isBody(this)) return this.getWindow().getScroll();
		return {x: this.scrollLeft, y: this.scrollTop};
	},

	getScrolls: function(){
		var element = this, position = {x: 0, y: 0};
		while (element && !isBody(element)){
			position.x += element.scrollLeft;
			position.y += element.scrollTop;
			element = element.parentNode;
		}
		return position;
	},

	getOffsetParent: function(){
		var element = this;
		if (isBody(element)) return null;
		if (!Browser.Engine.trident) return element.offsetParent;
		while ((element = element.parentNode) && !isBody(element)){
			if (styleString(element, 'position') != 'static') return element;
		}
		return null;
	},

	getOffsets: function(){
		if (this.getBoundingClientRect){
			var bound = this.getBoundingClientRect(),
				html = document.id(this.getDocument().documentElement),
				htmlScroll = html.getScroll(),
				elemScrolls = this.getScrolls(),
				elemScroll = this.getScroll(),
				isFixed = (styleString(this, 'position') == 'fixed');

			return {
				x: bound.left.toInt() + elemScrolls.x - elemScroll.x + ((isFixed) ? 0 : htmlScroll.x) - html.clientLeft,
				y: bound.top.toInt()  + elemScrolls.y - elemScroll.y + ((isFixed) ? 0 : htmlScroll.y) - html.clientTop
			};
		}

		var element = this, position = {x: 0, y: 0};
		if (isBody(this)) return position;

		while (element && !isBody(element)){
			position.x += element.offsetLeft;
			position.y += element.offsetTop;

			if (Browser.Engine.gecko){
				if (!borderBox(element)){
					position.x += leftBorder(element);
					position.y += topBorder(element);
				}
				var parent = element.parentNode;
				if (parent && styleString(parent, 'overflow') != 'visible'){
					position.x += leftBorder(parent);
					position.y += topBorder(parent);
				}
			} else if (element != this && Browser.Engine.webkit){
				position.x += leftBorder(element);
				position.y += topBorder(element);
			}

			element = element.offsetParent;
		}
		if (Browser.Engine.gecko && !borderBox(this)){
			position.x -= leftBorder(this);
			position.y -= topBorder(this);
		}
		return position;
	},

	getPosition: function(relative){
		if (isBody(this)) return {x: 0, y: 0};
		var offset = this.getOffsets(),
				scroll = this.getScrolls();
		var position = {
			x: offset.x - scroll.x,
			y: offset.y - scroll.y
		};
		var relativePosition = (relative && (relative = document.id(relative))) ? relative.getPosition() : {x: 0, y: 0};
		return {x: position.x - relativePosition.x, y: position.y - relativePosition.y};
	}

});

var styleString = Element.getComputedStyle;

function styleNumber(element, style){
	return styleString(element, style).toInt() || 0;
};

function borderBox(element){
	return styleString(element, '-moz-box-sizing') == 'border-box';
};

function topBorder(element){
	return styleNumber(element, 'border-top-width');
};

function leftBorder(element){
	return styleNumber(element, 'border-left-width');
};

function isBody(element){
	return (/^(?:body|html)$/i).test(element.tagName);
};

以上即是摘抄的部分代码,其中每个方法我会逐步叙说一遍。至于牵扯到其它一些关于mt核心的内容的,只做简单介绍,看不懂的话就会比较吃力了(尤其是mt的OOP理念)。

  1. getScroll()
    这是最简单的方法,判断当前元素是否是Body元素。是的话返回window对象的scroll;否则返回元素自身的scroll值。
  2. getScrolls()
    多了一个s,直接从命名上就能猜出获取的是当前元素相对于顶级body的scroll值。相对于上一个方法来说,它只是多了一个循环而已。
  3. getOffsetParent()
    获取元素的父偏移节点。首先,需要判断当前元素是不是Body,如果是的话,那么它爸爸自然就是null了;其它情况下,循环向上找,直到position不是static的为止(不是static自然就是relative、fixed或者absolute)。
  4. getOffsets()
    获取总偏移量。这是最难的方法,也是为什么说开始的那段代码是错误的原因所在!仔细看看合模型就会发现,开头的代码在每次循环时会少计算元素的border宽度,但是这个在不同浏览器和版本中的表现却是不同的。比如IE8反而将其包括进来,不再少算border宽度。只是我们无需再用循环的办法来做,因为有更好的东西——getBoundingClientRect()。
    这里不会叙说历史,介绍getBoundingClientRect()如何如何(我也不知道),但是较新版本的浏览器(FF 3.0+和Opera 9.5+)都已开始支持这一方法,用它可以直接获取页面元素的绝对位置。看代码的第29~39行,逻辑很清楚:getBoundingClientRect()的值赋予bound;然后分别取left和top转换成数字;再减去自身的scroll()加上scrolls()——这两个方法刚刚介绍过;最后根据元素本身是否是fixed定位,来减去documentElement的scroll()值;得出的结果减去clientLeft或clientTop即可。
    getBoundingClientRect()是很好,那么那些低版本或者不支持的浏览器呢?没办法,老套路,循环了。循环前依然要判断是否是Body元素,那样就直接返回0。
    在循环体的内部,我们发现mt对不同内核的浏览器分开了处理。gecko核心(Firefox为代表)在51行有个borderBox判断,这是什么?94行的方法给出了解答——box-sizing的值是否为border-box(改变css2.1合模型组成模式,width=content,而不是border+padding+content,具体请翻阅手册),是的话无需多计算元素本身的border。随后的56行判断父元素的overflow属性是否为visible,否的话要包含计算父元素的border。
    对于webkit引擎的浏览器(Safari为代表),处理显得简单多了:只需包含计算父元素的border即可(不包括自己)。
    循环完毕后,结果就出来了。只是针对gecko还需做一步处理:box-sizing不是border-box时要减去元素自身的border值。
  5. getPosition()
    这个方法名字有点误导,实际上是需要传入一个元素参数的,返回当前节点相对于参数元素的偏移量。当然,Body元素还是会直接返回0。
    首先计算出自己的offset、scroll,两值相减得出position;然后计算参数元素的position(注意,同样使用了getPosition()方法,只是没有传入参数,这样82行就不会产生计算,直接返回offset – scroll);最后,将元素的position减去参数的position就是返回值了。

88行以下的一些方法是mt的内置方法,上面的介绍中可能用到,我一一简单例举出来,就不多做解释——当然它们也是非常简单的。搞定绝对位置这个烫手山芋之后,想要做出兼容的拖动效果,便是水到渠成了。