组件化CSS--管理你整站的CSS文件

为什么要拆分样式文件?

更易于查找样式规则. 简化维护,方便管理. 还可以针对某一页面提供特定的样式.

为什么要添加桥接样式?

你可以随时添加或移除样式而不需要修改HTML 文档.

为什么要定义两种媒体类型?

NN4 不支持@import ,故识别不到桥接样式.

@import ‘header.css’;

@import ‘content.css’;

@import ‘footer.css’;

@imports 如何工作?

它将所有CSS 规则从一个文件导入到另外一个文件[email protected] 不能被老的

浏览器所识别.

对于 大型站点 来说,这是一个理想的概念.

 

Hack-free CSS

处理诸如IE 这样烦人的浏览器 的兼容性是我们最头疼的事儿之一.

很多朋友使用CSS Hack 来解决这些问题.

问题是当IE版本进行升级更替,改进对CSS的支持后,之前使用的hacks将会无效 !

你是怎么解决这个问题 的呢?

“我们要求你在不使用CSS hacks 的情况下更新你的页面.假如你想针对IE或者避开IE,你可以使用条件注释.”

条件注释 如何工作?

步骤一、针对IE,创建一个心得样式文件

步骤二、在HTML文档的开头添加条件注释 代码

只有指定的IE浏览器版本识别这个心的样式,其它的浏览器将会彻底忽略 它.

平常的浏览器识别:(非IE浏览器,如火狐、Chrome等等)

特定IE 版本识别:

举个例子, 大多数浏览器会将补白加进容器的宽度里,但是IE5 不会. 这种情况下,IE5 显示的是一个比较小的容器.

main.css (被包含IE5在内的所有浏览器识别):

#container{ width: 600px; padding: 100px;}

ie5.css (只有IE5识别):

#container {width: 800px; }

为什么条件注释是一个好的解决方案呢?

1.  No hacks
特定的CSS 规则仅出现在新的样式表里.

2.  文件分离
针对特定版本的IE 定义的样式脱离了主样式表,可以在IE 浏览器升级更新对属性支持时轻松移除这些文件.

3.  针对性
可对不同版本的IE 浏览器有针对性的进行相关属性的定义。

组件化CSS--管理你整站的CSS文件

时间: 2024-08-02 21:20:40

组件化CSS--管理你整站的CSS文件的相关文章

笔记一:高效的可维护的,组件化的CSS

书写高效CSS 1.使用外联样式替代行间样式或者内嵌样式. 不推荐使用行间样式: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html lang="en"> <head> <meta http-equiv="content-type" conten

2015前端组件化框架之路(转)

https://github.com/xufei/blog/issues/19 1. 为什么组件化这么难做 Web应用的组件化是一个很复杂的话题. 在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本.但是在Web前端这个领域,并没有很通用的组件模式,因为缺少一个大家都能认同的实现方式,所以很多框架/库都实现了自己的组件化方式. 前端圈最热衷于造轮子了,没有哪个别的领域能出现这么混乱而欣欣向荣的景象.这一方面说明前端领域的创造力很旺盛,另一方面却说明了基础设施是不完善的

2015前端组件化框架之路

特别声明:本文转自@民工精髓的<2015前端组件化框架之路>.谢谢@民工精髓的分享!著作权归作者所有. 编辑推荐: 掘金是一个高质量的技术社区,从 CSS 到 Vue.js,性能优化到开源类库,让你不错过前端开发的每一个技术干货. 点击链接查看最新前端内容,或到各大应用市场搜索「 掘金」下载APP,技术干货尽在掌握中著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处.原文: http://www.w3cplus.com/components-in-webapp.html ? w

【转】前端组件化框架之路

1. 为什么组件化这么难做 Web应用的组件化是一个很复杂的话题. 在大型软件中,组件化是一种共识,它一方面提高了开发效率,另一方面降低了维护成本.但是在Web前端这个领域,并没有很通用的组件模式,因为缺少一个大家都能认同的实现方式,所以很多框架/库都实现了自己的组件化方式. 前端圈最热衷于造轮子了,没有哪个别的领域能出现这么混乱而欣欣向荣的景象.这一方面说明前端领域的创造力很旺盛,另一方面却说明了基础设施是不完善的. 我曾经有过这么一个类比,说明某种编程技术及其生态发展的几个阶段: 最初的时候

Android组件化之终极方案

Android组件化项目地址:Android组件化项目AndroidModulePattern Fragment或View如何支持组件化 如何管理组件 Fragment或View如何支持组件化 距离 Android组件化方案 发布已经半年有余,虽说这个方案已经能够解决一些项目的需求,但是依然不够完美.很多开发者也在博客和GitHub中留言甚至发邮件问我,Fragment怎么办? 目前市面上APP的风格还是类似于微信界面的比较多,好几个Fragment摆在主界面中,然后点击NavigationBa

Gradle自动实现Android组件化模块构建

背景 随着App的不断迭代,业务会变得越来越复杂,业务模块会越来越多,且每个模块的代码也会变得越来越多.为了应对这一场景,我们需要把不同的业务模块划分成一个个组件,在修改业务代码的时候只需要在对应模块修改就可以了.通过高内聚,低耦合的业务模块来保证工程的健壮性和稳定性.现在问题来了,当组件的数量变得越来多的时候,我们如何管理业务组件呢? 原创声明: 该文章为原创文章,未经博主同意严禁转载. 为什么我们要用Gradle管理组件呢? 先来看看Android组件化需要实现的目标.(什么是组件化构建?)

如何通过 Vue+Webpack 来做通用的前端组件化架构设计

如何通过 Vue+Webpack 来做通用的前端组件化架构设计 转载 作者:伯乐在线专栏作者 - 新空气 链接:http://web.jobbole.com/86977/ 点击 → 了解如何加入专栏作者 目前如果要说比较流行的前端架构哪家强,屈指可数:reactjs.angularjs.emberjs.avalonjs.vuejs. 我个人接触使用过:avalonjs.angularjs.vuejs.因为工作以及前端团队能力的问题,所以在不同的公司,在开发工作中选用了不同的前端架构. 以下仅仅是

高仿富途牛牛-组件化(一)-支持页签拖拽、增删、小工具

目录 一.概述 二.效果展示 三.实现方案分析 1.第一阶段 2.第二阶段 3.第三阶段 一.概述 好久没有做业务相关的UI功能了,比较炫酷的交互效果也写的少了,最近花了2天时间写了一个简易的高仿富途牛牛组件化的功能,当然了这只是一个初步的效果,而且没有做贴图.美化等工作,但是基本的功能已经有了.本篇文章只是作为组件化的一个开始,后续还会陆续引入更多关于组件化的介绍,相信功能也会越来越丰富.除此之外,富途牛牛的一些其他高级功能也会陆续引入,不乏有k线.分时.五日.指标.自选这样的复杂功能. 自选

CSS组件化思考

为什么组件化? 分层设计,代码复用,减少冗余: 维护方便,弹性好: 如何组件化? 目前代码分成三级: 第一级粒度最细,是基础,主要包含字体配置,颜色配置,UI框架(比如MUI或者pure.css): 第二级是组件层,项目中出现两次及以上的样式单独抽离成一个组件,如果组件小于15个,单独放到一个component.less文件中,大于15个(界限自己把握),考虑放到几个不同的less文件中.因为样有些样式依赖于一定的DOM,所以需要针对less文件写一个HTML文件一一对应后于组件对应的DOM: