- 浏览: 962544 次
- 性别:
- 来自: 上海
文章分类
最新评论
-
sscsacdsadcsd:
mike8625 写道react还要自己的一些标签 还得编译 ...
对于React体系的一点想法 -
mike8625:
说的都是给大公司听的,国内很多还是小公司,做个小项目, 说实话 ...
关于国内前端和JS技术发展的乱想 -
mike8625:
react还要自己的一些标签 还得编译 编译吧浏览器端说还慢 ...
对于React体系的一点想法 -
u012814086:
下意识想到了Golang
JavaScript语句后应该加分号么? -
xueduanyang:
我是水羊,年轻的时候觉得只要有好斧子就能做成好产品,各种产品都 ...
关于国内前端和JS技术发展的乱想
Taobao UED blog 上,刊载了段王爷的css日记一篇,我上去留言引起了一些讨论,记录于此。
段王爷的原文(摘录)
回复(摘录)
虽然用border很方便,但有一个缺点:border的高度跟着盒子的高度(在这里是行高)走,如果能忍受这样的高度带来的不美观,那我也没有什么话好说
等ie6淘汰之时,就可以放心用 :first-child了,相权衡的话,我觉得给第一项加上class="first"也不失为实用主义做法。
首先加“|”并不是没有意义的做法。其次用margin-left的方法也不见得好。比方说也有border高度的问题。
我觉得有人跟风你也别得意。因为我觉得这个方法一点也不好。很简单的一个理由:这只是一个trick,只适合这特殊情况,假设你要换用“-”来分割呢?
作为插入分割符号来说,真正合理使用css的,我给一个例子:
li ~ li:before { content:'-'; margin:0.25em; }
优点:含义非常清晰,维护性极高。你可以换任何的分隔字符,可以设定字体,可以设定颜色、大小等样式,甚至可以换用图片作为分隔。
好了,下面说缺点。
唯一的缺点:IE不支持。没错,这就是为什么我们大部分开发者的css水平老是不长进的原因。
不过老是用这个借口也有点寒碜。毕竟Dean Edwards都给我们搞了一个开源的ie7(自从真的MSIE7出来后,它改名叫FixIE)。
当然,我承认DE的ie7在很多方面不适用于taobao这样的网站。对于taobao这样的,甚至裁剪使用ie7都是不可行的,需要有足够能力借鉴ie7自己搞一个替代方案——而这个很难。
所以我在这里的意思是,margin-left对于taobao也许还算一个比较合用的小hack,但拿出来现就有点误导大家了。
方法都是拿来用的,没有好或者不好之分
我新的回复
我说段王爷误导,不是说你贡献的的方法不好,或者不实用,实际上作为taobao的设计师,你当然对于怎样权衡取舍最有发言权。
我说的是,你没有把权衡的前提条件说清楚,因此对读者有误导。特别是对于怎样写css有误导。抛开taobao的特定环境和限制性的需求,你对几个方案的比较,最后选择你现在这个,实际上理由并不充分,而且你也没有指出你自己方案的缺点。从一般角度说,相比较我所指出的缺点,前面三种方式所存在的缺点并不见得就更严重。
所以你的误导在于对整个取舍的过程,优劣的比较上。特别是你的方法,对于设计来说存在一些严重的约束,例如只能是竖线。技术是为设计服务的,而不是相反。(当然技术对设计有约束是正常的,但是要看是怎么样的约束。)
这里存在一个因果关系,对于你来说,可能因果是清楚的,有了taobao(竖线)需求的因,才有你选取这样的trick的果。但是对于其他人来说,就很可能混淆因果,将一个带有很大局限性的trick奉为圭臬,到时候也许你自己也会觉得可笑呢。
这里有些人讲什么“实用第一”,我建议应该好好反省一下。小马同志,按照这种逻辑,table布局很实用呢,font也很实用呢。也许你觉得冤枉,此实用不同于彼实用。Ok,这就是问题所在。你怎么分析到底实用与否呢?不能拿一句“实用第一”就搪塞过去了。那是废话。需时时警惕,不要用双重标准—— 对己有利的,就实用,对己不利的,就不实用。
还有恕我直言,拍王爷马屁,也要有点技巧。比如“方法都是拿来用的,没有好或者不好之分”的那位,段王爷不是在点评几种方法的好坏么,你这个马屁可拍歪了。
我在回过头来说说段王爷说的“最实际的一种”,你的实际,需要有一个判断标准,需要有前提的。你后面提到的“IE”和“竖线设计”就是你在原文中所遗漏掉的前提。
这些前提对你来说也许是自然的,但是不能想当然的就变成默认前提啊。那就变成绝对化的“最实际”了。“竖线”那个问题,我前面已经说过了,这里不再赘述。我这儿单说说IE。首先并非所有应用,所有网站都必须考虑IE。比如XUL应用,比如可以选择客户端部署的企业网站。
其次——这是我说的重点——为什么我们一定要确保所有浏览器里的样子是完全一致的呢?内容样式分离,以及css的内在之意,就包涵了graceful degradation的设计意图。在这个例子里,IE不显示分隔,的确不太完美,但并不损害用户对内容的理解和使用。
注意,我不是说taobao或者任何网站就应该采取我说的方法。这完全取决于各种外在条件下的权衡。我想要说的是,不要贸贸然的说“实际”和“实用”,还没有思考就预先排除了很多可选项。实际上绝大多数网站是可以采用graceful degradation的设计方法的。
再次,就算要同时做到“在IE下的完美呈现”,也不是没有其他方法。例如我说的Dean Edwards的ie7开源项目。它也许不适用taobao,但是可以适用于其他项目。
我个人比较喜欢的方式是,按照标准css2写,然后为ie单独写hack,通过css、css expression、behavior甚至一段script,都是可行的,包括对于taobao这种类型的(大型商业网站),我认为也是可行的。当然,这样一种方式,许多人可能不认同,认为太困难,或不如用一些更特例的trick有效。这个就看如何权衡了,需要另一篇文章来探讨。
最后顺便再对“实用论”说一点,关于table布局和实用主义的问题,在这个讨论(http://www.iteye.com/topic/95739?page=4)中,我有几小段思考,copy过来供大家批判:
段王爷的原文(摘录)
引用
现在就来说个淘宝首页上的一个小技巧。
类目之间的横线
从很久很久以前开始,类目间的横线无非都只有三种。
1、背景图
在a标签设置一个padding 用宽1px高不等的背景图来position到右侧。
缺点:最后一个还是要用class来隐藏掉背景。
2、符号
在每个a标签之间用“|”符号来填充。
缺点:html文件变大,文件维护变得很麻烦,而且在html中毫无意义。
3、a标签右侧的boder。
同背景图一样,只不过使用border-right来代替。缺点也同上。
其实现有是利用ul的overflow:hidden 再将li的margin-left:-1px的做法做出来的。这样的做法就可以同时避免以上的缺点了。
类目之间的横线
从很久很久以前开始,类目间的横线无非都只有三种。
1、背景图
在a标签设置一个padding 用宽1px高不等的背景图来position到右侧。
缺点:最后一个还是要用class来隐藏掉背景。
2、符号
在每个a标签之间用“|”符号来填充。
缺点:html文件变大,文件维护变得很麻烦,而且在html中毫无意义。
3、a标签右侧的boder。
同背景图一样,只不过使用border-right来代替。缺点也同上。
其实现有是利用ul的overflow:hidden 再将li的margin-left:-1px的做法做出来的。这样的做法就可以同时避免以上的缺点了。
回复(摘录)
realazy 写道
虽然用border很方便,但有一个缺点:border的高度跟着盒子的高度(在这里是行高)走,如果能忍受这样的高度带来的不美观,那我也没有什么话好说
等ie6淘汰之时,就可以放心用 :first-child了,相权衡的话,我觉得给第一项加上class="first"也不失为实用主义做法。
aoao 写道
在每个a标签之间用“|”符号来填充。也不是没意义。。
只是选择使用li时它才是没意义。。。
只是选择使用li时它才是没意义。。。
我的回复 写道
首先加“|”并不是没有意义的做法。其次用margin-left的方法也不见得好。比方说也有border高度的问题。
我觉得有人跟风你也别得意。因为我觉得这个方法一点也不好。很简单的一个理由:这只是一个trick,只适合这特殊情况,假设你要换用“-”来分割呢?
作为插入分割符号来说,真正合理使用css的,我给一个例子:
li ~ li:before { content:'-'; margin:0.25em; }
优点:含义非常清晰,维护性极高。你可以换任何的分隔字符,可以设定字体,可以设定颜色、大小等样式,甚至可以换用图片作为分隔。
好了,下面说缺点。
唯一的缺点:IE不支持。没错,这就是为什么我们大部分开发者的css水平老是不长进的原因。
不过老是用这个借口也有点寒碜。毕竟Dean Edwards都给我们搞了一个开源的ie7(自从真的MSIE7出来后,它改名叫FixIE)。
当然,我承认DE的ie7在很多方面不适用于taobao这样的网站。对于taobao这样的,甚至裁剪使用ie7都是不可行的,需要有足够能力借鉴ie7自己搞一个替代方案——而这个很难。
所以我在这里的意思是,margin-left对于taobao也许还算一个比较合用的小hack,但拿出来现就有点误导大家了。
小马 写道
实用第一。
段王爷的回复 写道
楼上说的几种方法我都考虑过,只不过我选择了最实际的一种。只要ie还存世一天,只要我们的设计还是“|”,这个方法终究是最实用的。我想不明白,谈何误导大家呢?
Fenng 写道
方法都是拿来用的,没有好或者不好之分
我新的回复
我说段王爷误导,不是说你贡献的的方法不好,或者不实用,实际上作为taobao的设计师,你当然对于怎样权衡取舍最有发言权。
我说的是,你没有把权衡的前提条件说清楚,因此对读者有误导。特别是对于怎样写css有误导。抛开taobao的特定环境和限制性的需求,你对几个方案的比较,最后选择你现在这个,实际上理由并不充分,而且你也没有指出你自己方案的缺点。从一般角度说,相比较我所指出的缺点,前面三种方式所存在的缺点并不见得就更严重。
所以你的误导在于对整个取舍的过程,优劣的比较上。特别是你的方法,对于设计来说存在一些严重的约束,例如只能是竖线。技术是为设计服务的,而不是相反。(当然技术对设计有约束是正常的,但是要看是怎么样的约束。)
这里存在一个因果关系,对于你来说,可能因果是清楚的,有了taobao(竖线)需求的因,才有你选取这样的trick的果。但是对于其他人来说,就很可能混淆因果,将一个带有很大局限性的trick奉为圭臬,到时候也许你自己也会觉得可笑呢。
这里有些人讲什么“实用第一”,我建议应该好好反省一下。小马同志,按照这种逻辑,table布局很实用呢,font也很实用呢。也许你觉得冤枉,此实用不同于彼实用。Ok,这就是问题所在。你怎么分析到底实用与否呢?不能拿一句“实用第一”就搪塞过去了。那是废话。需时时警惕,不要用双重标准—— 对己有利的,就实用,对己不利的,就不实用。
还有恕我直言,拍王爷马屁,也要有点技巧。比如“方法都是拿来用的,没有好或者不好之分”的那位,段王爷不是在点评几种方法的好坏么,你这个马屁可拍歪了。
我在回过头来说说段王爷说的“最实际的一种”,你的实际,需要有一个判断标准,需要有前提的。你后面提到的“IE”和“竖线设计”就是你在原文中所遗漏掉的前提。
这些前提对你来说也许是自然的,但是不能想当然的就变成默认前提啊。那就变成绝对化的“最实际”了。“竖线”那个问题,我前面已经说过了,这里不再赘述。我这儿单说说IE。首先并非所有应用,所有网站都必须考虑IE。比如XUL应用,比如可以选择客户端部署的企业网站。
其次——这是我说的重点——为什么我们一定要确保所有浏览器里的样子是完全一致的呢?内容样式分离,以及css的内在之意,就包涵了graceful degradation的设计意图。在这个例子里,IE不显示分隔,的确不太完美,但并不损害用户对内容的理解和使用。
注意,我不是说taobao或者任何网站就应该采取我说的方法。这完全取决于各种外在条件下的权衡。我想要说的是,不要贸贸然的说“实际”和“实用”,还没有思考就预先排除了很多可选项。实际上绝大多数网站是可以采用graceful degradation的设计方法的。
再次,就算要同时做到“在IE下的完美呈现”,也不是没有其他方法。例如我说的Dean Edwards的ie7开源项目。它也许不适用taobao,但是可以适用于其他项目。
我个人比较喜欢的方式是,按照标准css2写,然后为ie单独写hack,通过css、css expression、behavior甚至一段script,都是可行的,包括对于taobao这种类型的(大型商业网站),我认为也是可行的。当然,这样一种方式,许多人可能不认同,认为太困难,或不如用一些更特例的trick有效。这个就看如何权衡了,需要另一篇文章来探讨。
最后顺便再对“实用论”说一点,关于table布局和实用主义的问题,在这个讨论(http://www.iteye.com/topic/95739?page=4)中,我有几小段思考,copy过来供大家批判:
引用
……Sure。昨天晚上我拿DHH原文看了一遍,我觉得他只是不满于Adobe/Microsoft摆出一副解救众生于Web水火中的姿态,而许多人高声应和。
另外,看看comments,也有许多人反对他的意见的——其中甚至包括一个Adobe的Flex Marketing Team的……多数人的论调是:工具么,各有擅场。老实说,这种实用主义论调还真是不可爱,难怪好多人(包括dlee)要对老是引用南方公园中的愤青 Cartman的粗口的DHH崇拜有加。
从技术美感的角度说,我不能隐藏我是如此喜爱xhtml/css/javascript……
……但是回到现实中,现有的标准,现有的实现,确实有太多不足了。也难怪人家鼓吹新的银弹么。
另外,看看comments,也有许多人反对他的意见的——其中甚至包括一个Adobe的Flex Marketing Team的……多数人的论调是:工具么,各有擅场。老实说,这种实用主义论调还真是不可爱,难怪好多人(包括dlee)要对老是引用南方公园中的愤青 Cartman的粗口的DHH崇拜有加。
从技术美感的角度说,我不能隐藏我是如此喜爱xhtml/css/javascript……
……但是回到现实中,现有的标准,现有的实现,确实有太多不足了。也难怪人家鼓吹新的银弹么。
引用
……凡给定界面的都或多或少倾向于grid 布局,仅仅是复杂程度的问题。例如仿桌面的界面(蛮流行的)。因为桌面应用中,几乎大都使用各种类型的grid布局。我以前一直鼓吹在web上就应该使用 flow布局而不应使用grid布局。但是随着对交互设计的认识加深,我意识到应该从用户体验出发。从技术上说,flow布局的主要好处是灵活适应不同的 viewport,但是真正把一个1280*1024的界面转换到640*480或者更小的viewport里,不是那样简单的。他们的应用场景很可能有很大不同。理想上,我未来能使用css media query,来为不同的分辨率(应用场景)来设计,对布局乃至流程做完全不同的调整。但是理想不等于现实。无法实现或太晚实现……都可能导致我们不愿看到的情况。
另外一方面,我恰恰是想要完全否定table布局的,正是基于此,我认为出现这样讽刺的情况,即遵循标准的人活得比不遵循的人更累,是很有问题的。这种矛盾在我身上存在着,2001年的时候我在某bbs上发了个贴,大数table布局之罪,但是过了几天我又跑上去说table布局在某种情况下也可以用用。 dlee同志貌似到现在也跟我当时一样。如果你确实认为,table布局从实用主义角度无法被完全否定,那DHH同志采用实用主义的角度来力挺 html/css/js就也有点心虚,那个标题也就显得带点任性味道。。。
另外一方面,我恰恰是想要完全否定table布局的,正是基于此,我认为出现这样讽刺的情况,即遵循标准的人活得比不遵循的人更累,是很有问题的。这种矛盾在我身上存在着,2001年的时候我在某bbs上发了个贴,大数table布局之罪,但是过了几天我又跑上去说table布局在某种情况下也可以用用。 dlee同志貌似到现在也跟我当时一样。如果你确实认为,table布局从实用主义角度无法被完全否定,那DHH同志采用实用主义的角度来力挺 html/css/js就也有点心虚,那个标题也就显得带点任性味道。。。
引用
……再说table吧,从实用主义角度说,谨慎的table布局也许更简单,因为它更好的映射到了grid模型上。如果你转用div/span,标签是清晰了,但是css是混乱的!!为什么?因为你无论绝对定位也好,float也罢,这些属性是分散的,css代码无法反映整体,无法记录你的grid 布局意图!这是为什么我们经常说我有一个css trick的原因,它是trick而已,是你达到最终目的的手段,但是你的目的,你的意图,没有好好加入文档的话,那维护起来恐怕也不见得轻松:
table布局 其他css样式 = 清晰的布局意图和内容的混合体
vs
div容器 css样式 = 内容样式分离,但是从css代码中很难看出布局意图
关于div/css布局还有一些误区,简单的把table标签换成div是没有意义的(若干层级的div可能比table更糟糕)。实际上我们希望的是语义标签。所以我们希望避免无意义或仅仅为layout或presentational的div标签,但是有时候居然是css hack的代价(比方说在某些css圆角实现中)!
也许归根到底是怪css还不够好,怪browser的实现还不够好。比方说你要在一行上放两个东西,实际上可能需要的是css column支持。。。但是还是那样,开发者的耐心是有限的,勾画的美好蓝图从来不如微软的甜蜜诱惑。特别是他们许诺通过更智能(更邪恶的宝葫芦的秘密?)的ide,也能提供你所说的web标准网站的可维护性的时候。对于他们来说,html css js,或者是flash,只是开发者看不见的 presentation层而已(据csdn新闻上元红岗同志的说法是不依赖於表现层的表现层),它帮你抹平了,你不用担心。按照这种逻辑,现在的 WYSIWYG工具只是不够智能而已而已。。。
table布局 其他css样式 = 清晰的布局意图和内容的混合体
vs
div容器 css样式 = 内容样式分离,但是从css代码中很难看出布局意图
关于div/css布局还有一些误区,简单的把table标签换成div是没有意义的(若干层级的div可能比table更糟糕)。实际上我们希望的是语义标签。所以我们希望避免无意义或仅仅为layout或presentational的div标签,但是有时候居然是css hack的代价(比方说在某些css圆角实现中)!
也许归根到底是怪css还不够好,怪browser的实现还不够好。比方说你要在一行上放两个东西,实际上可能需要的是css column支持。。。但是还是那样,开发者的耐心是有限的,勾画的美好蓝图从来不如微软的甜蜜诱惑。特别是他们许诺通过更智能(更邪恶的宝葫芦的秘密?)的ide,也能提供你所说的web标准网站的可维护性的时候。对于他们来说,html css js,或者是flash,只是开发者看不见的 presentation层而已(据csdn新闻上元红岗同志的说法是不依赖於表现层的表现层),它帮你抹平了,你不用担心。按照这种逻辑,现在的 WYSIWYG工具只是不够智能而已而已。。。
评论
2 楼
hax
2007-09-08
To Tin:
很好的总结啊。只是后半部分转折有点突兀。因为我的原文的后半部分是顺便总结一下先前与dlee等同志对于DHH文章的讨论。虽然与前半部分一样,同样是指出当前CSS实践中的一些困惑,但前者,我已经提出一些解决的思路,后者则还没有什么好的方法(除了等待遥遥无期的CSS3的高级布局模块)。
很好的总结啊。只是后半部分转折有点突兀。因为我的原文的后半部分是顺便总结一下先前与dlee等同志对于DHH文章的讨论。虽然与前半部分一样,同样是指出当前CSS实践中的一些困惑,但前者,我已经提出一些解决的思路,后者则还没有什么好的方法(除了等待遥遥无期的CSS3的高级布局模块)。
1 楼
Tin
2007-09-06
hax,你这篇真的是非常有价值的文章。我2周前就想挖掘一下发表在InfoQ。
http://www.infoq.com/cn/news/2007/09/css_trick_to_be_or_not_to_be
感谢你的工作,希望我的mush up工作没有侵犯你的劳动成果,希望大家可以一起讨论。
http://www.infoq.com/cn/news/2007/09/css_trick_to_be_or_not_to_be
感谢你的工作,希望我的mush up工作没有侵犯你的劳动成果,希望大家可以一起讨论。
发表评论
-
ms is wrong AGAIN
2013-12-06 21:08 2976微软的Web工程师写了这篇文章Vendor Prefixes ... -
为后代选择器和ID选择器而辩护
2013-04-20 06:57 7077【本文译自 Zeldman (作为前端工程师,不要告诉我你不知 ... -
My Opinion about so-called "CSS Framework"
2012-10-27 12:54 2494There are many so-called " ... -
document.enableStyleSheetsForSet() 的兼容
2011-06-17 16:27 3506可能有不少同学已经了 ... -
再论“像素(px)”
2011-03-13 14:37 0两年之前我写了一篇文 ... -
再谈某些所谓CSS最佳实践
2010-12-23 01:59 10112最近看了国内某位前端工程师今年出版的新书,其中讨论CSS的部分 ... -
webkit上multicolumn的bug和解决技巧一则
2010-12-04 12:03 4047webkit开始支持多栏属性 ... -
关于lang()语言伪类选择器的提案
2010-10-26 00:36 0本文发端“中文HTML5同 ... -
关于样式类(Style Class)
2009-10-22 11:37 9952我们知道HTML和CSS是正交 ... -
Meta CSS —— 一个Anti Pattern的典型
2009-10-21 02:15 11724关于Meta CSS框架,可以 ... -
像素(px)到底是个什么单位
2009-04-25 01:46 40436px,对于许多网页设计 ... -
有关IE的CSS的几个偶得
2008-08-25 19:13 2221除了个别几个CSS属性,IE(包括IE7)并不支持一般性的in ... -
版本、兼容性以及标准 续(翻译)
2008-02-10 19:40 4762续前半部分。 Commitment ... -
版本、兼容性以及标准(翻译)
2008-02-10 06:03 4774本文译自Maciej Stachowiak在webkit团队b ... -
Web未来的分歧
2008-02-09 05:41 2286Dean Edwards的新的一篇blog是几段引用,抄录并勉 ... -
IE神经刀
2008-02-01 15:13 4946我想,你可能已经知道长期以来使用自定义标签的困难是什么。 对, ... -
《精通CSS》读书笔记(七)
2007-09-05 02:37 5596续上篇 在第5章的最后,作者对dl做了简短的说明,作者不是很 ... -
IE中IMG元素上应用padding的奇特bug
2007-09-02 23:43 6024最近又(又说了“又”)发现了一个IE的奇特bug。 我们知道 ... -
关于list(ol和ul)的padding和margin
2007-09-02 19:08 9460在《CSS Mastery》一书的第5章中,作者说IE和Ope ... -
《精通CSS》读书笔记(六)
2007-08-29 20:22 6332续上篇。 第5章 关于列表,首先,由于list-style ...
相关推荐
【CSS Trick-crx插件】是一款专为Chrome浏览器设计的扩展程序,旨在帮助用户快速、便捷地更改网页的颜色方案,从而实现对网站界面的个性化定制。这款插件尤其适合前端开发者、网页设计师以及对网页样式有独特喜好的...
"Trick"这一主题似乎与一套特别的字体资源相关,其中包括多种不同风格的图像文件(.gif)和TrueType字体文件(.TTF)。让我们深入探讨一下这个话题。 首先,.gif 文件是一种常见的图像格式,支持透明度和动画,常...
Hattrick球场上座率概算 Hattrick球场上座率概算
### 重修 Slope Trick 技术解析 #### 一、引言 Slope Trick,作为一项优化动态规划(DP)问题的技术手段,在算法竞赛领域里占有重要地位。该技术的核心在于利用函数斜率的变化来简化计算过程,尤其是在面对那些代价...
Python-trick,上传的事pdf文档
ARP欺骗,又称ARP缓存中毒,是网络攻击者利用ARP协议的缺陷,向网络中的设备发送虚假的ARP响应,误导目标设备关于其他设备的IP与MAC地址映射关系,从而达到中间人攻击的目的。这种攻击方式可以被用来窃取敏感信息、...
在机器学习中,核技巧(Kernel Trick)是一种非常重要的技术,它允许我们在高维特征空间中有效地进行线性学习算法的操作,而无需显式地计算出高维空间的数据表示。核技巧在诸如支持向量机(SVM)等算法中发挥了重要...
Hat Trick是Unity官方商店提供的5.5.0版本以上的一款游戏Demo。
### 神经网络训练Trick详解 #### 引言 神经网络训练是深度学习领域的一个核心环节,其效果的好坏直接影响着模型的性能。在实际应用中,开发者经常会遇到模型训练不佳的情况,这时就需要一系列的技巧(Tricks)来...
在这个模板中,可能会有特定的选择器如`.halloween`或`#trick-or-treat`来选取特定的元素进行装饰。 2. **盒模型**:CSS盒模型描述了元素如何占据空间,包括边距、边框、填充和实际内容。设计师可能通过调整盒模型...
db_trick.sql
由NASA约翰逊航天中心开发的Trick仿真环境是一个功能强大的仿真开发框架,使用户能够为航天器开发的所有阶段构建应用程序。 特里克(Trick)加快了仿真的创建过程,以进行早期飞行器设计,性能评估,飞行软件开发,...
Linux Shell技巧是Linux系统操作中的重要组成部分,它是一种命令行接口,允许用户通过文本命令与操作系统进行交互。Shell脚本可以极大地提高效率,自动化日常任务,并且是系统管理员的得力工具。...
VDR-Hattrick是一款专为视频磁盘录像机(Video Disk Recorder, VDR)设计的开源插件。这款插件的出现,旨在为VDR用户提供一个独特的体验,即在观看电视节目的同时,能够实时查看在线足球游戏“Hattrick”的比赛情况...
Hattrick Ranking,一款专为在线游戏Hattrick设计的CHPP(Hattrick个人程序插件)批准的应用程序,为玩家提供了一个独特的功能,即创建自定义的排名系统,以更深入地对比和分析Hattrick中的各支球队。这款开源软件的...
zoj 2247 Magic Trick.md
"支持向量机之Kernel Trick.pdf" 支持向量机(SVM)是一种常用的机器学习算法,特别是在分类和回归问题中。然而,在解决线性不可分问题时,SVM 需要使用 Kernel Trick。Kernel Trick 是一种将输入空间映射到高维...
《Hattrick Organizer Plugins——开源的力量与Java的魅力》 在当今的数字时代,开源软件已经成为了推动技术进步的重要引擎,而Hattrick Organizer Plugins正是这一趋势的杰出代表。这款基于Java开发的插件集合,为...
【原文地址】 Tip/Trick: Use the ASP.NET 2.0 CSS Control Adapters for CSS friendly HTML output 【原文发表日期】 Wednesday, November 29, 2006 11:01 PM 厌烦了内置的ASP.NET服务器端...