所谓“键盘可访问性”,指的是用户只使用键盘访问网站的能力。例如,我们的iMac鼠标没电了,或者鼠标坏了,或者在智能电视中访问我们的网站,此时就只能依赖于键盘访问了。
我们只要平时注意HTML语义化,例如按钮不要使用<span>,<div>等标签,不要重置outline,基本上键盘可访问性就已经及格了。
若想再进一步提供,就需要看看本文的内容了……
所谓“键盘可访问性”,指的是用户只使用键盘访问网站的能力。例如,我们的iMac鼠标没电了,或者鼠标坏了,或者在智能电视中访问我们的网站,此时就只能依赖于键盘访问了。
我们只要平时注意HTML语义化,例如按钮不要使用<span>,<div>等标签,不要重置outline,基本上键盘可访问性就已经及格了。
若想再进一步提供,就需要看看本文的内容了……
常见的交互效果我们要不JS直接控制样式,要么添加一个具有我们希望样式的类名,但是,这两种实现都有不足之处,就是样式和行为耦合,对于日后的维护带来了隐患,怎么办呢?可以试试本文的基于active,checked等状态类名的web前端交互开发,说不定会为你打开另外一扇窗……
前端发展迅猛,除了自身更加厚重外,往前以及往后都有了发展和延伸,当前对前端的要求更高,而人的精力总是有限的,这个时候,就需要我们把有限的精力放在更适合自己发展的方向上,那应该放在哪个方向上呢?本文就将通过我自身的经验、观察和认识,为大家指明前进的道理。
做前端的应该都听过Node.js,偏开发背景的童鞋应该都玩过。
对于一些没有计算机背景的,工作内容以静态页面呈现为主的前端,可能并未把玩过Node.js,且很有可能对Node.js都没有一个比较立体的认识——知道这玩意可以跑服务,构建很多前端工具,看上去很厉害的样子,但是,可能就仅限于此了。
实际上,就算你JS一般般,你也能搞出一些有意思,可以提高自己生产效果的小工具小脚本什么的,本文就将通过示例演示,玩Node.js,只要懂中文,会毛毛雨程度的JS就够了……
传统的响应式实现往往基于基于media query查询,这是基于CSS的布局控制,因此,当我们缩小浏览器窗口,可以即时看到布局变化。但是,这种实现在我看来,除了让总监大人可以方便体验窄屏效果外,就然并卵了! 而反倒是有可能增加了额外的资源消耗和开发成本。
那有没有什么办法既能满足响应式的需求,同时我们开发这边不要那么烦心呢?
试试使用screen.width来做伪响应式开发……
本文属于波澜不惊,平铺直叙版本。如果想看有有激情有思想的版本,可以去ISUX官博:“顺势而为,HTML发展与UI组件设计进化”。
目前很多Team和团队都有自己的一套web组件体系,模块化开发,封装良好,上手简单。然后希望该web组件可以应用到接手的各个项目中,节约日后的开发成本。甚至考虑开源。
这其实是很棒的,但是呢,希望一套web组件各个项目通用?在我看来,除非对项目没有追求,否则不太现实。
但是呢,希望一套web组件各个项目通用?在我看来,除非对项目没有追求,否则就是妄想。
为什么说传统web组件想一统天下不现实呢?因为就像秦始皇一统天下一样,要牺牲很多很多东西…
基本上每天微博、博客以及邮件都会受到很多同行的问题咨询,我个人是非常欢迎交流与学习的,因此有问必答。但是,毕竟一个人精力有限,我又没有财力请经纪人或者小秘之类的,如何高效利用时间就是对于我来讲就是非常重要的事情。毕竟,我的本职工作不是技术咨询师,而是在厂子里干活。其中一点就是固定时间处理邮件,蛋的!就是这个邮件沟通,有好几次,几位同行的提问让我很火大,早就想写篇文章,教教这些人怎么才是高效地邮件沟通之道……
undefined behavior可以算是计算机世界中特有的一个名字,中文意思是“未定义行为”,维基百科上有解释。在C以及C++语言中,这可以算是一个比较明确的概念。
实际上,在web前端领域,也有undefined behavior未定义行为,且广泛程度远远超出了你的想象。
undefined behavior从web标准出现之后,实际上就广泛存在web网页前端技术中,我们很多时候遇到的浏览器兼容性问题,可能就属于……