Comments (12)
@hax 评论:
主动和被动并没有啥差异啊,为啥要用不同的术语。。。
from css-secrets.
我参与讨论的语境下,都是使用的「选择器」。
HTML 中文兴趣小组翻译的 CSS2 规范中也是使用的「选择器」。
from css-secrets.
CSS 「选择器」 比较普适,参见:http://yisibl.github.io/css-vocabulary/
from css-secrets.
再加一点今天想到的:英语中动词 + er
/or
本身就表示施加动作的人吧?所以 selector 在英语中似乎也应该是一个主动的关系?
from css-secrets.
我以前都是用”选择符“,因为最开始接触的就是这个。另外确实有一定的道理,它们是像通配符的一样的符号。后来看”选择器“多了,也转向”选择器“。
我觉得你那样的细分理由并不充足,又增加了负担,用我们的行话说,没有为用户考虑。
二者究竟选哪个?我实际上倾向于 ”选择符“。
from css-secrets.
我不推荐“选择符”,是因为selectors不是简单的“符号”,而是本身有结构的DSL。
关于主动与否,我同意@Justineo ,selector一词本身就是主动的。querySelector
按照道理应该是queryBySelectors
,只是为了简化api才是现在的名字。
from css-secrets.
@Justineo:HTML 中文兴趣小组翻译的 CSS2 规范中也是使用的「选择器」。
这个页面光是目录就错误连篇(“子代择器”、“before和after伪类”等等),我就暂时无视了吧……
from css-secrets.
谢谢大家的评论,我来说一下我的想法。
“选择器”
直译
诚然,它最普遍的译法,普遍到了轶灵兄 (@Justineo) 所提到的这种程度:
我参与讨论的语境下,都是使用的「选择器」。
它为何如此普遍?因为它是直译,而直译是最安全的。不论它是否是最贴切、最形象的,但只要是知道英文原文 “selector” 的人,看到这个译法都可以不加思索地映射过去——是为 “安全”。这是它最大的优点。
而我为什么不喜欢它呢?因为直译是最不需要动脑筋的译法。很多术语,由于最初译者的不动脑筋(或是根本没理解原意吧),结果让不那么贴切、甚至是有误导性的直译流传开来。比如滑动门(sliding door),比如浮动(float)。
“选择器”,完全中立,直接对应原文,没有任何为便于理解而添加的辅助信息。这当然没有错,但效果就不一定是最佳的了,因为存在理论上可能的提升空间。
有一些术语,最开始普及开的可能是直译,但经过译者和读者长时间的理性选择之后,最终流行的并不是直译。比如 timeline(这里特指动画或历史的时间推进方向),有译 “时间线”,但胜出者是 “时间轴”。相对于安全而平直的 “时间线” 译法,“时间轴” 提供了更多的信息;或者说,它把原文中平实中立的宽泛信息(“线”)替换为更利于理解的具体信息(“轴”)。后者是一个经过思考的翻译,而不是机械的转换。
歧义
另外,“选择器” 一词在前端开发中文圈内可能存在歧义(多种解读):有相当多的人把 jQuery 的 $()
函数称作选择器,诸如 “jQuery 的选择器很好用”、“jQuery 的 DOM API 把选择器作为入口” 这样的表述(大家可以搜一下 “jQuery 选择器” 这样的关键字)。这可能是以讹传讹,也可能就是中文读者和中文作者的自发选择——“选择器” 一听就是用来(从 DOM 树中)选择元素的,它是一个实施动作的主体。
贺老 (@hax) 认为 “selector 一词在 JavaScript/jQuery 和 CSS 中所指的是同一件事,应当使用相同的译法”——前半句我是认同的,英文语境下确实是指同一件事物。但显然广大人民群众在中文语境下的自然选择不是这样的。很多人在写 jQuery 教程时用到了 “选择器字符串” 这个词,你可以猜到它指的是什么、以及同一篇文章当中的 “选择器” 指的又是什么。
鉴于这种歧义普遍存在,我主张:
我本人倾向于将 JavaScript/jQuery 中通过 CSS selector 匹配查找元素的
.querySelector()
/.query()
/$()
函数称作 “选择器”,而将 CSS selector 译作 “选择符”。
这个想法以贺老的观点来看,在理论上显然是 “不完美” 的,但我自认为是一种务实的做法。
“选择符”
出处
我最早接触的译法应该是 “选择器”,毕竟它流传最广嘛。而最早看到 “选择符” 这个译法应该是在某本不错的 CSS 书籍中。我记忆中以为是《CSS 权威指南》,但实际上后来发现我记错了,真正的出处应该是《CSS 实战手册》或《CSS 实战精粹》或类似的教程书。
该书的译者特意在译注中解释了为什么采用 “选择符” 这个译法,而不是 “选择器”。大体的意思就是 selector 是便于匹配元素而设计的描述符,用 “选择符” 这个译法更精确。
我对此印象深刻,而且十分赞同,从此以它为准。(其实对我来说,完全不存在痛苦的转换过程,因为这一堆书都是我在初学 CSS 时几乎同时看完的。甚至可以认为这个译法对我来说就是先入为主的。)
优点
跟 “时间线 vs 时间轴” 类似,这个译法在中立的宽泛信息(“器”)之上增加了更利于理解的具体信息(“符”)。这样做可能是危险的,但如果得当,将是更加贴切的。
缺点
首先,不够流行。跟 “选择器” 相比,这个译法在互联网上的使用数量存在明显差距(38,300 vs 250,000)。但流行度又能说明什么呢?我假设我们是在讨论译法的优劣,而不是使用率的多寡。而且这个差异还真没有我想像的那么大。
接下来的质疑,就在于 “符” 这个字了。比如贺老是这样说的:
我不推荐“选择符”,是因为selectors不是简单的“符号”,而是本身有结构的DSL。
如果是叫 “选择式”,我觉得还更有说服力一些。
乍一听很有道理,我甚至动摇了。但当我清醒之后,我发现自己不过是又一次受到了贺老的现实扭曲力场的影响。在我们每天都挂在嘴边的一些技术术语中,有很多 “符” 都不是常规概念上的 “符号” 或单个字符:
- 标识符(identifier):往往是由字母、数字等构成的字符串。
- 描述符(descriptor):CSS 的
@font-face
规则中的unicode-range
就是一个描述符。 - 统一资源定位符(URL, Universal Resource Locator):各种字母、数字、标点符号所构成的复杂语法,简直不能更乱。
- 占位符(placeholder):UI 的中的占位符可能是任意对象——文本、图片、控件等等。
还有其它缺点吗?
我(目前)的选择
虽然经历了短暂的动摇(尤其是在收到我的偶像 @Justineo 和我的导师 @hax 的反对意见之后,以及当我发现《CSS 权威指南》和《精通 CSS》所采用的都是前者时),但随着翻译进程的推进,我越来越相信 “选择符” 是一个更好的选择。
这是一本近十年来最重要的 CSS 图书,没有之一。十年前的译法就让它随风而去吧。
当然,这是我目前的选择;而在付印之前,一切皆有可能。我仍然期待更好的反对意见,我仍然期待被说服。
from css-secrets.
:-)
from css-secrets.
我仅就“符”的几个例子讲下我的意见:
- identifier 可以有结构,但本身是opaque的
- url 尽管有结构,但如作为uri意义上使用时本身是opaque的,仅在需要dereference或resolve时需要考虑结构
- placeholder 可视为特殊的 identifier
以上三者实际上均为identifier,和selector都有比较显著的区别,就在于其本身是opaque的,所谓opaque,即在主要使用场景下是完全不考虑内部结构的,可视作纯粹的“符”号。selector如果有什么使用场景是不考虑内部结构的,那也是jQuery的场景(即和你现在的分立是相反的)。
关于URL
url确实有使用场景需要考虑结构。然而url也有“定位器”的译法(见维基百科词条),google搜索两种译法在一个数量级(3万和2万条)。且以我看法,确实更推荐“定位器”和“标识符”的分立。只是今天whatwg的规范将uri和url合一了,这是术语本身的演化。而且现在whatwg的规范里根本不提 locator,对url的定义是“universal identifier”(如翻译,则为“统一标识符”),而不再使用缩写定义,即实际统一在uri的意思,但用了url的名字。
descriptor
这个问题就比较复杂了。
首先,此词在CSS规范的场景下,我称之为“弱术语”。所谓“弱术语”就是并非有spec给出明确定义的技术词汇,它本质上只是一个普通词汇,以一种符合spec写法的,以比较严谨和一致的方式使用而已。比如css property也是一个弱术语。
那么考虑descriptor本身,其意思其实是,用来描述和指示某些东西的那么个玩意儿。所以descriptor是一个本身有很大弹性的词(参见https://en.wikipedia.org/wiki/Descriptor ),比如搜索关键词也可以叫“descriptor”。
编程术语里,“descriptor”通常是有结构的,比如js里的property descriptor,包含了3个特征。python的descriptor也是类似的。所以“描述符”的译法在这个场合下(按照我的观点)是不对的。property descriptor根本不是符号,而是(描述特征的)数据。js中的pd确实被翻译为“描述符”,但是更多人是不翻的(包括我),我自己觉得以及我猜许多人直觉也是如此——“描述符”的译法反而增加了理解困难。
但是为什么我们常见“描述符”的译法?恐怕是来自于Unix操作系统的“file descriptor”(文件描述符)以及类似的process descriptor、socket descriptor等。它的形式为整数,实际是表索引(指针),符合前述的opaque的特征,译为“描述符”倒也还行。不过这仅限于Unix中的这个特定语境。一旦用到了别的场合,就会造成理解困难。
另外即使英文术语本身而言,descriptor也不如handle(句柄)好。注意我是说概念理解上,但你不能换成handle,因为两者在细节上是不一样的。
所以“file descriptor”在本来场合(我认为)就不是一个最佳术语,因为它和descriptor的其他用法不太一样。而把file descriptor的译名用到其他descriptor就很糟糕了。这种问题其实在译名也屡见不鲜,比如frame的译名帧/框架之混乱。
descriptor本身比较好的直译译名或许是“描述子”或“描述元”(大陆常见xx子,**常见xx元)。当然,如能根据具体场合,将“子/元”换为带有更多信息的字(器/符/式等),自然是极好的。不过绝大多数人也就随手搬运,根本不会想那么多,那还不如老老实实用“子/元”的译法。
回到CSS规范的场景下,我也不建议用“描述符”来翻译。因为显见它并非identifier。实际上,css descriptor和css property几乎是一样的(在句法层面根本不区分),只不过property用于qualified rules(即selectors { ... }
),而descriptor用于at rules(即@xxx { ... }
里)。如分别用“属性”和“描述符”来翻译,完全不对等。不过这里的descriptor到底用什么译法好,我也暂时没有想好。
from css-secrets.
**古代有“合符”这个词,就是匹配的意思:http://baike.baidu.com/view/1172082.htm :)
from css-secrets.
投票给CSS“选择符”。以表明它的确只是描述性质的匹配符,而不是执行某些操作的工具(器具)。窃以为,译者是应当具有 CSSMagic 老师这样的使命感的。
from css-secrets.
Related Issues (20)
- [注解] [508] 现实中的文字效果
- [注解] [509] 环形文字
- [注解] [603] 自定义复选框
- 提交勘误 HOT 3
- [注解] [607] 交互式的图片对比控件
- 线性渐变 HOT 2
- 第59页勘误 HOT 2
- [注解] [705] 垂直居中
- [注解] [706] 紧贴底部的页脚
- [注解] [801] 缓动效果
- [注解] [802] 逐帧动画
- [注解] [806] 沿环形路径平移的动画 HOT 6
- [注解·加强版] 如何正确编写 Fallback 样式
- 复杂的背景图案实践中的疑问 HOT 5
- fill="%23fb3”,%23fb3怎么理解?fb3是颜色,23是什么? HOT 3
- p161:第 34 滚动提示,关于 `background-attachment` 代码问题 HOT 5
- [注解] [306] 简单的饼图
- 提交勘误 HOT 2
- p49页的蚂蚁行军边框问题 HOT 2
- 网站挂了,会修一下吗 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from css-secrets.