zoukankan      html  css  js  c++  java
  • html中不要忽略一些细节

    1.

    img必备和可选的参数都有写了上了,但是必备参数里的一个值alt没写(其实一些大型的专业门户网站其实也是有存在一些小问题的,只要我们细心一 点就能发现)。虽然这样alt不写,在页面中也不会有任何的问题,因为这个alt属性也只是在图像丢失、禁用或加载不到的情况下才显示,但是如果一些其他 特定的设备访问或一些其他条件下图片不显示的情况下,那这里就是一块大红XX和一大块白块,多影响用户体验。

      虽然只是一个小小的alt属性,但是有时候是细节决定决定成败,用与不用,表面上看不出有什么问题,但是在某些特定的条件产生的作用是无法估计的,也就是从这些小小的细节就可以看出一个前端工程师的水平如何。

      一些前端的新同学甚至什么也不填,放一张无任意命名意义的图上去就算了事,养成这样的习惯是非常不好的。

    添加文字链接的title属性
    <a hrehf="#" target="_blank" title="新闻新闻新闻新闻">新闻新闻...</a>,在一些限定字数的内容展示尤为重要,帮助显示不完成的内容显示完整,而不用考虑页面会因此而撑大

    2.基于前人的总结,个人认为高效的CSS书写应该要注意:

      1) 精简属性写法,提高可观赏性

      很多属性是有精简的写法的,如padding、margin、background等等,这些写法虽然可拆可合,但我们习惯了精简的写法后,会让css更加整洁、明了,看起来更加赏心悦目,感觉写css就是一个雕刻一件艺术作品。

      2) 使用多重选择器,提高可重用性

      多重选择器的写法相信很多人都会使用,但是多重选择器的使用与进行二次编辑或多次编辑的时候会有一个矛盾,多次的修改,有可能需要重新定义的样 式不同,这时候又需要重新的将原先的选择器进行分享出来单独定义,这不能不说是一件痛苦的事情,所以在使用多重选择器的时候,最好针对固定的版块使用多重 选择器,这样大大降低你日后维护、编辑的成本。当然,这是需要你的时间和经验才能积累起来的。

      3) 减少层级及继承的写法,一般不轻易用id

      相信很多人都会考虑到重用这一高效的写法,所以越少的层级、越少的继承就为重用这一方法的实现提供了可能。也许有人会说,那我可以采用上面的 “使用多重选择器”来提高css的可重用性啊。其实这里面还有另外一个原因,就是更少的层级,渲染所使用的时间更少。css的渲染与JavaScript 的方式完全不一样,JavaScript的筛选直接使用id,能够精准的定位到相应的dom,但是css的层级多的话反而会影响到性能,但具体没做相应的 测试。此处也许不严谨,请大家赐教,哪位大侠有空来测试一下,给一些相应的数据会有更好的说服力。但基于重用的原则,个人还是建议用最直接、有效的简短的 命名,也同样就是这样的一个原则,虽然id的唯一性解决了冲突问题,但违反了重用性的原则的同时也加大了维护和的成本,如非必要,尽量不用id。

      4) 命名面向属性和面向对象结合

      其实命名这个方面有很长的一个篇幅可以说的,因命名的方法和各个人的习惯也不样,有人喜欢用驼峰式,有人喜欢下杠线,有人喜欢缩写,也有人喜欢全写,个人认为这个主观色彩太重了,不予作过多的展开,不管哪一种,都是没有问题的。

      和大家分享的是另外一个问题,是样式的命名是面向属性还是面向对象呢?相信这个也会困扰着一些同学。现在就和大家分享一些我的心得。在分享我的 观点之前,先跟大家解释一下什么是面向属性、什么是面向对象。面向属性就是面向css的属性来进行命名,面向对象就是面向要重构的页面的模块这个对象来进 行命名。如下图:

      4.1 面向属性命名

      4.2 面向对象命名

      关于这个问题,有人觉得面向属性好,因为可以最大限度的利用好css的重用性;也有人认为面向对象好,因为面向对象可以让后期的维护更方便直接。既然各自都有好处,那我们可不可以将两者结合起来呢?答案是肯定的,而我个人也是这样做的。

      对于一些固定的、常用的、重用性非常高的css,可以将其按面向属性来进行命名,上面的“面向属性命名”的这个图这样,也可以说是一个小小的框架或是作为一个底层来方便自己的开发,放到哪里都是可以使用,具体可以见我整理的自已用的面向属性的css(点击下载aqy106_lib.css)。另外对于于具体的版块就应该使用面向对象,针对版块的对象来进行命名,这样也让后期维护或接手的人来编辑也不会困难。163采用的也是采用面向属性和面向对象结合的方法来进行命名的。

      作为一名前端开发的工程师,应该要有有利节流的思想,把css的书写当作一门艺术来学习、来追求。书写出一个高效、可维护的样式往往是通向大师之路的必走之路。

      样式不仅仅是写给自己看的,更要给团队开发或后来接手的人看的,如果能做到简洁、高效、重用性、可读性强,相信,你离大师的级别也不远了。

    3.

    3、 CSS Sprite(图片精灵、背景定位技术)

      现在的网页,各种各样的媒体、图标、背景都是多得眼花缭乱的,特别是背景图片、图标是我们网页中使用最多的,按照以前的使用的话,插入一个个的 小图标或图片用来控制来进行修饰,这些不和内容相关的图标图片也一并混排在内容中了,且页面中一大堆无关的图标图片,还不方便管理。并且还有一个很大的弊 病,一个图片在页面中是一个http的请求,页面中存在n个的这样的小图标的话,对服务器的请求也就有N个,也许对于一些小站来说没什么影响,但对于一个 大型网站来说的话,这个数字可就不得了,这时的服务器并发请求就会多上N乘以用户的个数,这样无疑加重了服务器的负担。

      而解决这个问题的最好办法就是CSS Sprite。

      将所有的图片整合到一张大图上,通过css来进行定位。首先能将内容和修饰的元素进行了分离;其次能减少页面请求的个数,那么减轻了服务器的负担;再次,能够提高页面加载的速度,加快页面载入速度,提升用户体验。

      另外,将图标图片作为背景来进行加载,都是在文档的主要内容进行加载完毕,再加载样式时才进行请求的(细心的大家也许也发现,网络不好的时候, 页面加载进来的是乱七八糟的,待一会样式加载进来后,页面马上正常了,其实这个就体现到了文档加载的先后顺序,如果不相信的话,可以用小bug或相应的工 具查看一下是不是这样的加载顺序)。

      当然,事物都是具有两面性的,将小图标小图片整合到一张图片上,虽说有百利,但仍有一害的,就是当需要更换图标或调整的时候,必须要在这张图片 进行处理和定位,需要在Firework等这些图像处理软件中定位好坐标再去写相应的CSS,会增加一定的工作量,如果身边没有这些工具,处理起来还是会 有些麻烦的。但总的来说,图片整合,利大于弊,我们为何不用呢?

      1、 兼容性

      2、 以Trident为内核的IE、以Gecko为内核的FireFox、以Presto为内核的Opera、以Webkit为内核的google chrome和Safari等四大内核的浏览器四分天下。

      兼容性的问题相信是很多前端工程师肯定会遇到且最头痛的一个问题,且不说目前市面上有这么多的浏览器,就仅仅单一的IE系列家族的问题也够多的 了,特别是IE6,虽然微软宣布了IE6的死亡和下台,但国内的机器仍以IE6为主流,IE6在国内的消亡还需时日,作为前端开发没法规避的情况下,暂时 也只能折衷的进行兼容。不过虽然繁多复杂,但我们可以化繁为简,重点问题重点处理,基本上IE6的问题解决了,也就解决最大的问题了。

      当然,这个IE6的问题太多了,需要用另外的篇幅去进行说明了,这里就不再跟大家再作深入的研究了,给大家提个醒,让我们一些新同学在成长过程中能够有目的地去学习、发现和处理问题就OK了。

  • 相关阅读:
    【带着canvas去流浪(14)】Three.js中凹浮雕模型的生成方式
    Stanford公开课《编译原理》学习笔记(1~4课)
    Vue源码中compiler部分逻辑梳理(内有彩蛋)
    Vue+ElementUI项目使用webpack输出MPA
    Vue-Router中History模式
    Vue中拆分视图层代码的5点建议
    如何正确使用Java泛型
    ZooKeeper的三种典型应用场景
    Tomcat多实例部署
    Tomcat常用的过滤器
  • 原文地址:https://www.cnblogs.com/mm2015/p/5124544.html
Copyright © 2011-2022 走看看