Archive for category CSS架构技巧

div + css命名规则 有利于搜索引擎

页头:header
登录条:loginBar
标志:logo
侧栏:sideBar
广告:banner
导航:nav
子导航:subNav
菜单:menu
子菜单:subMenu
搜索:search
滚动:scroll
页面主体:main
内容:content
标签页:tab
文章列表:list
提示信息:msg
小技巧:tips
栏目标题:title
加入:joinus
指南:guild
服务:service
热点:hot
新闻:news
下载:download
注册:regsiter
状态:status
按钮:btn
投票:vote
合作伙伴:partner
友情链接:friendLink
页脚:footer
版权:copyRight

——————————————————->

1.CSS ID 的命名

外 套:  wrap
主导航:  mainNav
子导航:  subnav
页 脚:  footer
整个页面: content
页 眉:  header
页 脚:  footer
商 标:  label
标 题:  title
主导航:  mainNav(globalNav)
顶导航:  topnav
边导航:  sidebar
左导航:  leftsideBar
右导航:  rightsideBar
旗 志:  logo
标 语:  banner
菜单内容1: menu1Content
菜单容量: menuContainer
子菜单:  submenu
边导航图标:sidebarIcon
注释:   note
面包屑:  breadCrumb(即页面所处位置导航提示)
容器:   container
内容:   content
搜索:   search
登陆:   login
功能区:  shop(如购物车,收银台)
当前的   current

2.另外在编辑样式表时可用的注释可这样写:

<– Footer –>
内容区
<– End Footer –>

3.样式文件命名

主要的 master.css
布局,版面 layout.css
专栏 columns.css
文字 font.css
打印样式 print.css
主题 themes.css

Yahoo专家:怎样才能成为优秀的前端工程师

昨天,X负责了Yahoo!公司组织的一次面试活动,感触颇深的是其中的应聘者提问环节。我得说自己对应聘者们提出的大多数问题都相当失望。我希望听到一些对在Yahoo!工作充满激情的问题。在昨天的应聘者中,只有一个人的问题是我认为最好的,那个人问我:你觉得怎么才能成为优秀的前端工程师?我觉得很有必要把这个问题从面试房间里拿出来讨论一下。

首先,前端工程师必须得掌握HTML、CSS和JavaScript。只懂其中一个或两个还不行,你必须对这三门语言都很熟悉。也不是说必须对这三门语言都非常精通,但你至少要能够运用它们完成大多数任务,而无需地频繁地寻求别人的帮助。

优秀的前端工程师应该具备快速学习能力。推动Web发展的技术并不是静止不动的,没错吧?我甚至可以说这些技术几乎每天都在变化,如果没有快速学习能力,你就跟不上Web发展的步伐。你必须不断提升自己,不断学习新技术、新模式;仅仅依靠今天的知识无法适应未来。Web的明天与今天必将有天壤之别,而你的工作就是要搞清楚如何通过自己的Web应用程序来体现这种翻天覆地的变化。

计算机科学这个大门类下面的许多分支在人们眼中实际上都不外乎科学。但是,我们所说的前端不是什么科学,而是艺术。艺术家不仅要掌握谋生的技术,还要懂得如何运用。对同一个问题的解决方案在这种情况适用,在另一种情况下可能就不适用。对Web应用程序的前端而言,解决同一问题的方案经常会有很多。没有哪个方案是错的,但其中确实有一些是更合适的。优秀的前端工程师应该知道在什么情况下使用哪种方案更合适,而在什么情况下应该重新选择。

优秀的前端工程师需要具备良好的沟通能力,因为你的工作与很多人的工作息息相关。在任何情况下,前端工程师至少都要满足下列四类客户的需求。

产品经理这些是负责策划应用程序的一群人。他们能够想象出怎样通过应用程序来满足用户需求,以及怎样通过他们设计的模式赚到钱(但愿如此)。一般来说,这些人追求的是丰富的功能。

UI设计师这些人负责应用程序的视觉设计和交互模拟。他们关心的是用户对什么敏感、交互的一贯性以及整体的好用性。他们热衷于流畅靓丽但并不容易实现的用户界面。

项目经理这些人负责实际地运行和维护应用程序。项目管理的主要关注点,无外乎正常运行时间(uptime)应用程序始终正常可用的时间、性能和截止日期。项目经理追求的目标往往是尽量保持事情的简单化,以及不在升级更新时引入新问题。

最终用户当然是应用程序的主要消费者。尽管我们不会经常与最终用户打交道,但他们的反馈意见至关重要;没人想用的应用程序毫无价值。最终用户要求最多的就是对个人有用的功能,以及竞争性产品所具备的功能。

那么,前端工程师应该最关注哪些人的意见呢?答案是所有这四类人。优秀的前端工程师必须知道如何平衡这四类人的需求和预期,然后在此基础上拿出最佳解决方案。由于前端工程师处于与这四类人沟通的交汇点上,因此其沟通能力的重要性不言而喻。如果一个非常酷的新功能因为会影响前端性能,必须删繁就简,你怎么跟产品经理解释?再比如,假设某个设计如果不改回原方案可能会给应用程序造成负面影响,你怎么才能说服UI设计师?作为前端工程师,你必须了解每一类人的想法从何而来,必须能拿出所有各方都能接受的解决方案。从某种意义上说,优秀的前端工程师就像是一位大使,需要时刻抱着外交官的心态来应对每一天的工作。

我告诫新来的前端工程师最多的一句话,就是不要在没有作出评估之前就随便接受某项任务。你必须始终记住,一定先搞清楚别人到底想让你干什么,不能简单地接受这个功能有问题之类的大概其的说法。而且,你还要确切地知道这个功能或设计的真正意图何在。加一个按钮之类的任务并不总意味着你最后会加一个按钮。还可能意味着你会找产品经理,问一问这个按钮有什么用处,然后再找UI设计师一块探讨按钮是不是最佳的交互手段。要成为优秀的前端工程师,这种沟通至关重要。

无论从哪个方面讲,我都觉得前端工程师是计算机科学职业领域中最复杂的一个工种。绝大多数传统的编程思想已经不适用了,为了在多种平台中使用,多种技术都借鉴了大量软科学的知识和理念。成为优秀前端工程师所要具备的专业技术,涉及到广阔而复杂的领域,这些领域又会因为你最终必须服务的各方的介入而变得更加复杂。专业技术可能会引领你进入成为前端工程师的大门,但只有运用该技术创造的应用程序以及你跟他人并肩协同的能力,才会真正让你变得优秀。

12个顶尖设计师谈CSS应用技巧

想成为一名css专家,仅仅熟练使用CSS选择符(selectors)是远远不够的。还在于对工作的整体规划,工作流程的掌握以及提高样式表的可维护性和效率。在这篇文章里Jina Bolton从12个顶尖设计师那里精选出了10种css应用技巧推荐给大家。[4A创意工场]

  01.不要让css有过多的标记

  链接或者导入样式表听起来好像是一种无头绪的工作。但是我想要强调为什么这个那么重要。我看过很多的网站开发都有着整洁的、组织严密的css文档,但是慢慢的,由于可能达不到在短期内快速更新,或者直接懒得再去管理,这使得先前创建的精致的样式表变成了垃圾。

  想象一下,你工作在需要发布上百条内容的庞大网站上面。因为时间有限,所以你需要通过嵌套或者排列css来进行快速修改或更新。一年一年的过去了,这种习惯维持着,直到一天你被告知这个网站要完全推翻重新设计(但是内容还是一样)而且你只有一周的时间去创建(包括测试)。

  通常,更新样式表还算是一个非常简单的方法。除非你长时间对网站零散的区域做修改。你就不能对网站样式表结构有一个整体的把握。所以现在你有两个办法 a.把所有的内容进行整理,然后再一个月内重新设计(祝你好运)b.去找一份新工作。

  不要让你的工作变成这个样子。链接或者导入你的样式表不是那样随意的事情。创建干净整洁的样式表,并保持下去,你的工作就会更开心。

  注意:不要在你的样式表里加入太多标记。如果你试图在每次更新或者添加新内容的时候创建新的样式表,那你肯定是自找麻烦。过多的链接和导入样式表会使消除bug工作变得异常困难,让你的样式表很难维持。大一点的网站分别建立不同部分的样式表这是可以理解的。就是小心不要太走极端。

  比较值得一提的是添加很多的样式表,会增加更多的http请求,可能还会影响到后面的工作。此外,微软ie6浏览器对32连接式样表还有一定的限制。

  02.语义不仅仅只是个行业词

  要知道我不得不把它提上来说,语义会成为你的好朋友,除了选择最合适的,最有意义的元素来表述你的内容外,还要确定你选择class 和id属性值。在本职工作外,还会让你的生活变得简单(这也会让你工作团队里伙伴的生活变得简单—-如果你在一个团队中工作的话)。看看下面的定义:

  .l13k { color: #369; }

  如果你刚来参加工作,你看到在这个css文件里,你会立刻找到这个class吗?估计不太可能,因为这个类的名称可能是一种缩写,所以这里没有一个准确的方法能够让你立即说出来。或者可能是你把它放在那里,今天你知道它的意思,但是你能保证过了很多年后还知道它的意思吗?

现在,让我们来看看这个定义:

  .left-blue { color: #369; }

  你可能立即很明确的知道这个class选择符的用途就像你知道左边栏蓝色的模块在那里一样,所以这就表明它起作用了。我前面提到,可能你在一星期的时间需要重新设计。在重新设计的时候,这个模块被放置到了右边,而且还是红颜色。这个类就不再有存在的价值了。所以现在不得不选择,要么改变所有的属性值,要么放着它不动。(这可能导致更多的混乱。)

  最好不要在你的类属性里面去加入颜色或者长宽的尺寸。你应该避免任何的属性值都是直接的词汇。(比如box)直接属性可以会导致内容的分离。

  最后,让我们来看看更恰当的命名规范:

  .product-description { color: #369; }

  这里你可以看到。用这种样式定义的product-description(产品描述),不管你怎么改变,都很清晰。

  03.加注释的好处

  如果你的注释组织良好,且在css的控制范围,清楚的标注每节(section)。最好确保注释视觉突出,以便在内容滚动、一目十行时快速定位,那么注释你的css文档对你或者其他人在以后的开发中都会有很大的帮助。大部分基础的注释会提示为什么这个规则会用在这里。

  提示和注意

  添加注释可以帮助你或者以后的开发者避免出现不必要的混乱。保持这种习惯。看范例:

  /* Turn off borders for linked images */
  img { border: 0; }

  时间和署名

  一些设计师和开发人员喜欢在css文档最近更新中标明日子和时间,还有他们的名字和初始状态。这些信息可以提供给你谁参与了这些,也提示了最近的文档是怎样的。
  /* Sushimonster Typography Styles
  Updated: Thu 10.18.07 @ 5:15 p.m.
  Author: Jina Bolton
  —————————————————-*/

  这是个很好的主意特别是当你工作在一个团队中,请记住,有些团队需要省去这种信息(一些公司宁愿在文档里不出现这些名字和日期。)所以,最好就是看一下是不是需要这种信息。

  组织分类

  用注释简单说明css里的各个部分是个不错的主意。例如,如果所有的标题类型都放在一起了,你就需要注视来区分他们。

  /* HEADER
  —————————————————-*/

  我会稍后在讨论“区分不同类型”的时候详细地说明这个。

  注释加标

  如果你的css文档在组织零散样式的时候跟我上面说的一样,注释加标可以帮助你在你想要找到那部分文件的时候变得更简单。你可以用特征符号、关键词然后找到最终结果。

  /* =HEADER
  —————————————————-*/

  这在又长又复杂的样式表中很有帮助。你可以在Stop Design里读到这个。

  参考

  如果大家在制作样式表的习惯上有所不同,用注释作为参考向导还是很有用的。这个你在Steve Smith’s的css文件中,看到的就是包含一个规定色彩的参考标准。

  /* COLORS
  Body Background: #2F2C22
  Main Text: #B3A576
  Links: #9C6D25
  Dark Brown Border: #222019
  Green Headline: #958944
  */

  你可以把这个参考放在你css文档的最上面去帮助你记住什么颜色在你网站中用过。另外在这里你可以定义不同的部分,马上找到他们(也可以用注释加标)这就是那个例子

  /* GENERIC
  HEADER
  SIDEBAR
  FORMS
  TABLES
  FOOTER
  */

  /* =GENERIC
  —————————————————-*/

  04.知道什么时候添加有条件的注释和运用技巧

  很多文章写过一些关于问题解决的技巧,有条件的注释是控制ie发布的一个好方法。然后文章又说了其他的一些方面。我同意有条件的注释比在你的css文档里乱丢垃圾要好得多,但是最近我开始慢慢意识到,很多证据表明,这并不是最好的解决办法。

  想象一下。你想在一个元素中设置它的最低高度,但是ie6浏览器却不执行它,所以你知道你能够使用的高度,也同样会被同样的处理。重新建一个样式表,然后把有条件的注释加入到你的标识中,你所有的需要都是要遵循这个规定?保持最低的高度和高度的规则在一起,选择一个小技巧在同样的css文档里,这样会更好吗?在这种情况下,我觉得用这种方法很难奏效。

  另外一件需要考虑的事情就是:如果你风格的定位是多样的,过多的css文档和有条件的注释会让你的调试过程异常痛苦。所以,你需要改变一些事情(可能是上述表述中最低高度的值),你不得不打开不止一个文档来做这个修改。在很多情况下,这对你来说可能不是件大事,但是想象,如果你定义了一些事情,在你主要的css文档中,然后还要重新定义三个不同的ie样式表。

  如果你确定要用有条件的注释,我推荐把注释留一份在你主要的样式表里,让你或者下一位开发者知道这是ie特别规则的存在。这种方法就是当你不得不编辑一个高度或者别的东西的时候。你知道又会有不止一个文档开着。

  如果你确定要使用技巧,记得更新浏览器能够改变接下来的工作,这次技巧的使用对于后面的版本控制也起不到作用。

  05.组织选择及声明

  要一直一直的保持你的css有规则,有组织性。最好把你的选择符进行归类。

  • reset styles
  • typography styles
  • layout styles (header, content, footer, etc.)
  • module or widget styles
  • etc.

  然后,在每一个组里面,通过dom层组织选择符。

  • any parent styles (containing elements, working outside-in)
  • block-level element styles (paragraphs, lists, etc.)
  • inline element styles (links, abbreviations, etc.)
  • etc.

  其次在这里面,根据元素的类型工作:

  • paragraphs
  • blockquotes
  • addresses
  • lists
  • forms
  • tables
  • etc.

  最后,把css的声明也按上述进行归类。

  • positioning (with coordinates) styles
  • float/clear styles
  • display/visibility styles
  • spacing (margin, padding, border) styles
  • dimensions (width, height) styles
  • typography-related (line-height, color, etc.) styles
  • miscellaneous (list-style, cursors, etc.) styles

  有些人喜欢按照字母顺序来组织。这对我没有任何用处,但是可能会对你有帮助。不管你选择什么样的方法,一定要坚持下去。

  06.创建一个架构

  当你开始创建css样式表的时候,如果你发现你总是不断重复做同一件事情,那就考虑建一个库或者框架结构吧。一个框架就像是网站骨架一样,而且这回节省你建立网站的时间。你可能会在你的框架中发现以下比较典型的样式表:

  • screen.css – A screen CSS file can either have all your styles you want to be used for on screen, and/or can import additional styles, such as the following:
  o reset.css – A reset CSS file can be used to “reset” all the default browser styling, which can help make it easier to achieve cross-browser compatibility.
  o typography.css – A typography CSS file can define your typefaces, sizes, leading, kerning, and possibly even color.
  o grid.css – A grid CSS file can have your layout structure (and act as the wireframe of your site, by defining the basic header, footer, and column set up).
  • print.css – A print CSS file would include your styles you want to be used when the page is printed.

  构建框架其中一个范例就是,由0olav bjørkøy整理的框架蓝图(另外作者还包括杰夫豆和埃里克迈耶)。另外一个很流行的框架就是雅虎的用户界面库。很多开发者都感到这个预建立的框架包含臃肿的标记和css,而且也包含着直接的类名称。

  注意:当我还在起草这篇文章的时候,Jeff Croft已经发布了怎能不爱上css框架的书。在书的注释中他提到的,别人告诉他我强烈反对框架的存在,我不确定这种评论从哪里来的,但是我要声明,事实根本不是那样子,相反我非常喜欢框架。为取得最佳效果,我还是建议你创建自己的框架结构,它能更好的为您或您的工作服务。

  07.确保样式表的可读性和优化性之间的平衡

  风格格式化因人而异。有的开发者首先创建能够具有可读性的样式表风格,然后在文档还没有完全建好的同时就进行优化(去除评论,位,标签,运输效益等)。这是我想要推荐的一个好技术。然而,如果你不知道在什么情况下去做这些事,就尝试去找一种可以平衡样式表可读性跟优化性的一种风格。Steve Smith在这里有一个很好的建议就可以提供这个技术。

  此外,考虑到用连字符来代替下划线。Microformats用连字符作为分隔标准,某些旧的浏览器不兼容这种连字符。你可以在Underscores in class and ID Names.读到更多关于这方面的知识。

  08.掌握你的文本编辑器

  就像艺术家熟知他们的专业工具一样,对于一个设计者或者开发者去熟悉他们需要的工具也同样重要。对于css,你再用的时候,你就是个编辑者。

  这有很多文字编辑器可供挑选:TextMate, Coda, BB Edit, TextPad, DreamWeaver,我在这里不是要告诉你要采用哪一种;他们各有利弊,一个好的编辑者会选择适合自己的。然而,一旦你决定使用一种文字编辑器,就要去学习关于这个编辑器的所有知识。找到捷径,然后学习所有的你能学到的技巧和窍门。

  掌握好编辑器能够快速提高你创建样式表的时间,帮助你更有效的完成工作。

  09.使用版本控制

  顺畅的可维护性也是创建精美样式表很重要的一部分。这就是为什么版本控制也会成为你的左臂右膀。这不仅对团队很有帮助,而且也是单独设计师或者开发者的救生员。

  有些应用软件是内置软件,所以在资源方面就被控制了。DreamWeaver用的是一种check-in/check-out同步进行的系统(这可以帮助一个开发者在确定已经正确编辑中没有编辑一个文档)。这虽然很便利,但是在某些地方是被限制的。

  Subversion (SVN) or Concurrent Versions System (CVS)是一个不错的工具,他用来管理包括添加选择权,回复,察看修改(这对团队很有帮助—你可以查到谁添加,编辑,或修改了密码,什么时间做的)和解决冲突。Jonathan Snook写了一片很好的文章叫“Hosted Subversion”,你可以通过阅读这篇文章得到更多关于如何更快更简单的创建样式表的信息。

  10. 创造和保持一种风格规范

  在一些情况下,一种风格规范是一个作者关于语法规则和写作的标准。他也可以用来作为设计,发展和内容的大纲标准。一种风格规范是一本可以很好地阐明排版,表格,色彩,图片大小等的参考手册。

  当你创建了一种风格规范,它会在标记和css上起到有效的作用。这种参考可以作为手册用在发展团队和将来的开发人员。它可以包括界定的布局,其中你可以列出不同的版面设计,并提供相关的标记和风格。

  最后,你也为其他的开发者留下了规范的步骤(比如如核对验证和无障碍环境),来确保更高的质量。

  结论

  作为一个css大师,拥有先进的css技巧还是远远不够的。(即:充分认识层叠,箱模式,浏览器如何工作)。我鼓励你去思考一些你能够不断的持续不变的提高可维护性和功效的方法。想想超越怎样设计文本,甚至这就是你一直需要提高的。要是你的样式表即美观又智能,掌握规整完美的工作流程是必不可少。

Tags: