blog
blog copied to clipboard
wintercn
## 一、概述 attribute和property是常常被弄混的两个概念。 简单来说，property则是JS代码里访问的： ``` document.getElementByTagName('my-element').prop1 = 'hello'; ``` attribute类似这种： ``` ``` JS代码里访问attribute的方式是getAttribute和setAttribute： ``` document.getElementByTagName('my-element').setAttribute('attr1','Hello'); document.getElementByTagName('my-element').getAttribute('attr1','Hello'); ``` ## 二、区别 多数情况下，两者是等效的。在web标准中，常常会规定某attribute“反射”了同名的property。但是例外的情况还是不少的。 ### 1. 名字不一致 最典型的是className，为了回避JavaScript保留字，JS中跟class attribute对应的property是className。 ``` var div = document.getElementByTagName('div');...
HSEJ模式是最新研究出来的先进UI架构，它的特点是基于群众基础广泛的jQuery，学习成本极低，代码极其轻量。 它先进的理念使得它比MVC、MVP、MVVM和FLUX、REFLUX、REDUX等框架不知高到哪里去了。 首先是代码量，HSEJ模式依赖的jQuery大小仅仅34.5k，而相比之下react.js竟然达到惊人的133k。 我们先来了解一下HSEJ的名词： - H-HTML:就是我们写的HTML代码，这没什么好解释的。 - S-Selector:选择器，选择器是由jQuery首创的一种非常先进的操作HTML的方法。 - E-Event:事件，事件是jQuery的一些方法，经过高度封装之后，可以响应用户的各种操作。 - J-JavaScript:JavaScript是jQuery的一部分功能，提供了极其强大的图灵完备的拼接字符串的能力，其中最厉害的就是$字符。$在jQuery中有九种作用，其它任何一个框架的任何函数都没有这么强大。此外，JavaScript是基于对象的，而不是面向对象的。 下面我们来看看HSEJ模式的架构图，为了对比，我放上了最近特别火的FLUX的架构图：   两张图是如此之相似，那么各位一定有一个疑惑，那就是，到底为什么这么相似？ 没错，跟你想的一样，HSEJ模式随着jQuery发布就已经普及了，只是开发jQuery的大师们担心你们前端太low才没好意思提出来，React不过是最近几年的事情，谁抄谁的一目了然。 由此可见，React不过是窃取了广大jQuery开发者的智慧，改了个名字重新卖卖概念的二道贩子罢了，Facebook公司这样的人品，怎么能让它来到中国呢？ HSEJ的用户操作响应过程如下： 用户点击了HTML元素=>通过选择器和事件找到JavaScript代码=>在JavaScript中拼接HTML字符串=>通过选择器把字符串填回去 下面我们来看一段例子： ``` html Clicked: 0 times + $('#increment').click(function(){ $('#value').html(parseInt($('#value').html())++) })...
阿里巴巴无线前端团队
题目来自阿里巴巴无线前端团队，我们招聘Web前端工程师。 为什么会有这些题目？这些题目代表了我看重的技能和方向，如果你觉得自己有能力有才华，但是苦于自己没有大公司经历简历被筛掉，请试试发这些题目的答案给我。 为什么没有职位描述？这些题目就是职位描述。 选择下面题目中的一个或者几个回答，可以直接写在评论里，并请留下邮箱。也可以把回答写在简历里直接发到我的邮箱 csf178 [at] gmail.com - 你对前端职业发展有何看法？ - 前端和后端程序员应该如何合作？ - 讲几个你在项目中解决的让你印象最深的问题（难、匪夷所思、解决方案有趣都可以） - 在JavaScript面向对象方面，你有什么体会和实践？ - 谈谈JavaScript中的闭包，以及你的实践。 - 说说 http://m.taobao.com 前端做的最烂的地方，以及你的改进。 - 谈几个有趣的html标签，以及它们的语义。 - 讲一讲CSS的position/float/display都有哪些取值，它们相互叠加时的行为都是什么？ - 说几个你觉得有趣的CSS3选择器，以及他们有趣的用法。 - 自己问自己一道代表你水平的面试题，然后回答。 一些提示...
闭包概念考证
闭包这个概念第一次出现在1964年的《The Computer Journal》上，由P. J. Landin在《The mechanical evaluation of expressions》一文中提出了applicative expression和closure的概念。（在计算机领域，closure还有两个完全不同的意义：计算几何中的凸包，和编译领域的包含集） 文中AE的概念定义如下： > We are, therefore, interested in a class of expressions about any one of which it is appropriate to...
谈谈面试与面试题
起因，某日电话面试之后满心郁闷的我发了两条微博： > 面试的时候问个css的position属性能刷掉一半的人这是啥情况…… > > 其实这问题我本来打算的是可以顺着一路扯到normal flow、containing block、bfc、margin collapse，base line，writing mode，bidi，这样一路问下去的，奈何第一个问题（亲我真的只问了position有哪些取值和行为啊）就悲剧了…… 其中的一些回复让我认为非常有必要写这样一篇文章来说说面试和面试题的事情。 ## 关于题目 什么样的面试题是好的？我认为有三点衡量指标： - 区分度 - 深度 - 覆盖范围 是的，请注意我并没有使用“难度”这个词，因为这三个指标都与难度有关系。 > css的position属性有哪些取值，它们的行为是什么？ 这个题目几乎是我每次必问的，因为这个题区分度、深度和覆盖范围都很高。这个题的答案可以分成不同的层级: - position属性常用的取值static、relative以及absolute和它们的基本行为是每个前端都应该掌握的。这包括relative和absolute的定位原点。 - fixed旧版本IE不支持，但是一个对技术有热情的工程师也是应该了解的。 -...
声明：本文介绍的内容，不包含任何以伪造虚假信息为前提的技巧。 ## 关于面试题 面试题往往是准备面试时最受追捧的东西。我这里却想提一个有点不可思议的观点：不要准备面试题。 “下水井盖为什么是圆的？” “全世界有多少辆汽车？” 不知道有多少“微软面试题”，"google面试题"在网上到处流传。 其实恰恰反了，这些不着调的面试题，并不因为它是微软和google的面试题就变得高深莫测。之所以会有这样的题目出现，正是以其极度的不靠谱反衬了这些大公司对“过程比答案重要”的诠释，和对自己的面试官面试的把控能力的信心。 对于一个合格的面试官来说，问题只是话题的起点。所以精心准备的答案可能在面试官的一次追问后全盘崩溃，一开始支支吾吾的面试者，也可能在面试官逐渐的引导下展示出自己的能力。 我常常提一个观点，面试和考试不同，面试可能因为一个问题答得好而通过，也可能因为一个回答不好而通过。其实面试只有结果，没有分数。设想以下场景： ``` “能解释一下http协议中302这个状态码是什么吗？”，“我不记得了。” （0分） “能解释一下http协议中302这个状态码是什么吗？”，“哦，记不清了，我只记得404是找不到页面，304是可以从缓存读取，5xx是服务端错误” （加分，了解一定http状态） “能解释一下http协议中302这个状态码是什么吗？”，“啊，那个，应该是服务端错误吧？”（倾向于面试不通过，不了解的时候尝试猜测蒙混，这种特质对工作不利） ``` 你看，同样的一个问题，同样是应聘者不知道问题的答案的情况，结果却大相径庭。 所以，面对面试题，过程重于结果，纠结于题目、准备答案是不会有任何意义的。 面试时该如何做呢？以下是我的几点建议： 1. 厘清问题，必要时可以跟面试官沟通确认，避免误解，不但理解问题，还要同时思考面试官的意图 2. 不急于开始回答，可以先分析问题，列举实际案例，争取思考时间 3. 不限于回答问题，可以以对面试官意图的理解为基础，主动讲解相关知识，展示自己对相关领域的体系化思考 4. 正面承认自己了解和不了解的东西，不敷衍，不猜测，有记不清的地方，可以正面要求面试官提示 以上四点，都是只有面试场景才能够使用的，这也是为什么我说“面试和考试不同”。 ##...
# 谈谈UI架构设计的演化 ## 经典MVC 在1979年，经典MVC模式被提出。 在当时，人们一直试图将纯粹描述思维中的对象与跟计算机环境打交道的代码隔离开来，而Trygve Reenskaug在跟一些人的讨论中，逐渐剥离出一系列的概念，最初是Thing、Model、View、Editor。后来经过讨论定为Model、View和Controller。作者自言“最难搞的就是给这些架构组件起名字”。 因为当时的软件环境跟现在有很大不同，所以经典MVC中的概念很难被现在的工程师理解。比如经典MVC中说：“view永远不应该知道用户输入，比如鼠标操作和按键。”对一个现代的软件工程师来说，这听上去相当不可思议：难道监听事件不需要类似这样的代码吗？ ``` view.onclick = ...... ``` 但是想想在70年代末，80年代初，我们并没有操作系统和消息循环，甚至鼠标的光标都需要我们的UI系统来自行绘制，所以我们面对的应该是类似下面的局面： ``` mouse.onclick = ...... mouse.onmove = ...... ``` 当鼠标点击事件发生后，我们需要通过view的信息将点击事件派发到正确的view来处理。假如我们面对的是鼠标、键盘驱动这样的底层环境，我们就需要一定的机制和系统来统一处理用户输入并且分配给正确的view或者model来处理。这样也就不难理解为什么经典MVC中称"controller是用户和系统之间的链接"。 因为现在的多数环境和UI系统设计思路已经跟1979年完全不同，所以现代一些喜好生搬硬套的"MVC"实现者常常会认为controller的输入来自view，以至于画出model、view、controller之间很奇葩的依赖关系：  我们来看看Trygve Reenskaug自己画的图（这恶趣味的骷髅啊……）：  值得一提的是，其实MVC的论文中，还提到了"editor"这个概念。因为没有出现在标题中，所以editor声名不著。MVC论文中推荐controller想要根据输入修改view时，从view中获取一个叫做editor的临时对象，它也是一种特殊的controller，它会完成对view和view相关的model的修改操作。 ##...
响应式设计
## Responsive Web Design ## 响应式Web设计 ETHAN MARCOTTE原作 于2010年5月25日 http://alistapart.com/article/responsive-web-design > 设计师熟知的在印刷媒体的控制功能，常常也会期望Web媒体会有，但是他们仅仅限制在打印出来的页面上才能使用。我们必须接受这样的事实：web根本没有同样的限制和为这样的弹性准备的设计。但是首先我们必须接受这种落差和流程。 > > ——John Allsopp, “A Dao of Web Design” 英国建筑师Christopher Wren有一次开玩笑说他选择了一个"以永恒为目标"的领域，而这样的原则也有它吸引人的一面：不像是Web那种总让人感觉是以下星期为目标的东西，建筑是一个以他的持久性来定义的学科。一个建筑的地基决定了它的底座，底座决定了他的结构，结构决定了它的外观。建筑的每一个阶段都比上一个阶段更固定，更难以改变。创造性的决定极其确切地决定了物理空间的形状，规划好了人们几十甚至几百年间在这个范围中活动的方式。 然而在Web上工作则是完全不同的事情。我们的工作内容由瞬时性定义，经常在一两年里就要调整或者替换。不一致的窗口宽度，屏幕分辨率，用户偏好以及我们用户安装的字体仅仅是在交付工作时要衡量的奇怪东西中的冰山一角。经年累月我们逐渐变得不可思议地精于此道。 但是形势在变化，而且可能比我们想要的还快。移动浏览量预计三到五年内会超过桌面访问。在三个具有支配地位的视频游戏平台中就有两个有Web浏览器（而且其中一个还非常棒。）。我们为了鼠标和键盘设计，为T9键盘设计，为手柄游戏控制器设计，也为触屏设计。简而言之，我们现在要面对比以往任何时候更大数量的设备、输入方式以及浏览器种类。 近年来，我见到更多公司开始要求"iPhone版网站"作为他们项目的一部分。这是一个很有趣的说法：从表面来看，当然，这是说移动版WebKit完全达到浏览器的品质，同时也是跳出桌面思考的一个强有力的商业案例。但是作为设计师，我觉得我们经常从这样明确的要求中寻找安慰，因为他们允许我们把面前的问题划分开来。我们可以把移动体验明确地隔离到单独的子域和空间中，跟"非iPhone版网站"分开。但是接下来呢？一个iPad网站？再来一个N90网站？我们真的能一直这样保证为每一种新的用户代理提供专门为之设计的体验？从某种意义上讲，这开始感觉像是一个零和游戏，但是我们——以及我们的设计——该如何适配呢？ # 弹性的基础 让我们考虑一个设计的例子。我创建了一个简单的幻想杂志页面。它是在流体格上的直接的两栏布局，其中到处散布着一些弹性的图片。作为非固定布局的长期支持者，我长期认为它们更加"面向未来"仅仅因为它们不针对特定布局。在某种程度上，规则是：弹性设计没有对浏览器窗口宽度做任何假设，并且非常漂亮地适配了具有人像和景物图模式的设备。 ...