特色文章

js获取不到div.style.left,解决方案

element.style.left 只能获得element的行内样式,一般写在style或css文件内的left就无法获得。

解决方案,通过字符串截取和隐式转换

var oBox=$(“box”);
document.onkeydown=function(evt){
var e = evt||window.event;
var addNum = 10;
var _left = strToNum(oBox.style.left);
var _top = strToNum(oBox.style.top);
if(e.keyCode==37){
oBox.style.left=(_left-addNum)+”px”
}
if(e.keyCode==38){
oBox.style.top=(_top-addNum)+”px”;
}
if(e.keyCode==39){
oBox.style.left=(_left+addNum)+”px”;
}
if(e.keyCode==40){
oBox.style.top=(_top+addNum)+”px”;
}
}
}
function $(id){
return document.getElementById(id);
}
function strToNum(str){
var index = str.indexOf(“px”);
return str.substring(0,index)-0;

}

特色文章

href与src的区别

 

SRC (Source)
src用于置换元素[1],即使说这个元素的内容通过src的地址获得,且不受css样式限制。比如

<script /> 
<img /> 
<video /> 
<object />

等。浏览器在解析到此处时会暂停所有渲染,加载直到此处内容被加载完成。
所以建议<script>放置在页面底端。比如:

<script src="dom1.js"></script>

HREF (HyperText Reference)
href 用于建立链接关系,比如

<a>, <link>

元素,浏览器在解析到此处时之道这里是个外部链接(或锚点)而并不需要加载这个链接的内容。因此页面解析不会被暂停。比如:

<a href="#yourAnchor">Click me</a>
URL (Uniform Resource Locator)
狭义来讲,在这里url代表了CSS的一个数据类型,它指定了一个数据的链接位置。通常的用法是用url()函数。比如

#your-element{
  background-image:url(http://placekitten.com/500/500);
}

There is a differentiation between src and href and they can’t be used interchangeably. We usesrc for replaced elements while href for establishing a relationship between the referencing document and an external resource.
href (Hypertext Reference) attribute specifies the location of a Web resource thus defining a link or relationship between the current element (in case of anchor a) or current document (in case of link) and the destination anchor or resource defined by this attribute. When we write:
The browser understands that this resource is a stylesheet and the processing parsing of the page isnot paused (rendering might be paused since the browser needs the style rules to paint and render the page). It is not similar to dumping the contents of the css file inside the style tag. (Hence is is advisable to use link rather than @import for attaching stylesheets to your html document.)
src (Source) attribute just embeds the resource in the current document at the location of the element’s definition. For eg. When the browser finds

The loading and processing of the page is paused until this the browser fetches, compiles and executes the file. It is similar to dumping the contents of the js file inside the script tag. Similar is the case with img tag. It is an empty tag and the content, that should come inside it, is defined by the src attribute. The browser pauses the loading until it fetches and loads the image. [so is the case with iframe]

引用
http://stackoverflow.com/questions/3395359/difference-between-src-and-href

特色文章

不定宽度的div始终居中(css方式)

//需求:ul不能定具体宽度,只能根据li的个数来计算宽度。
22

<!DOCTYPE HTML>

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>特殊性</title>

<style type="text/css">

*{padding:0; margin:0;}

ul,li{ list-style:none;}

.wrap{ float:left; position:relative; left:50%;}

.wrap ul{ background:#f00; height:30px; line-height:30px; left:-50%; position:relative;}

.wrap ul li{ float:left;}

.wrap ul li a{ color:#fff; display:block; padding:0 10px;}

</style>

</head>

<body>

<div class="wrap">

<ul>

<li><a href="#">首页</a></li>

<li><a href="#">网站地图</a></li>

<li><a href="#">网站地图</a></li>

<li><a href="#">网站地图</a></li>

<li><a href="#">网站地图</a></li>

<li><a href="#">网站地图</a></li>

<li><a href="#">首页</a></li>

<li><a href="#">首页</a></li>

</ul>

</div>

</body>

</html>

 

 

 

//可以实现不定宽度居中,可是元素左右两侧空白宽度之和(绿色箭头部分的)要大于ul本身不定宽度元素的宽度。不然就会出现滚动条。

//so不建议使用,用js解决吧,纠结的同学们

特色文章

viewport

<meta name=”viewport” content=”target-densitydpi=device-dpi, width=device-width, initial-scale=1, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0″>
appcan header内的自适应

Viewport语法

 <meta name="viewport" content="target-densitydpi=device-dpi, width=device-width, initial-scale=1, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0">

 

target-densitydpi=device-dpi(在csdn中线有人在2013年就说这个不支持webkit了,腾讯的博客有在2012年还探讨,在使用appcan的时候制作appweb的时候会出现乐视华为三星宽屏手机在UC浏览器的兼容问题,去掉这个可以解决)
使用

width:控制viewport的大小,一般情况下指定为device-width(单位为缩放为100%的CSS像素),也可以指定一个固定的值例如600.

height:和width相应,指定高度。

initial-scal:初始缩放比例,页面第一次load的时候的缩放比例。

maximum-scale:允许用户缩放到的最大比例。

minimum-scale:允许用户缩放到的最小比例。

user-scalable:用户是否可以手动缩放。
参考资料
http://isux.tencent.com/mobile-development-essential-knowledge.html
http://bbs.csdn.net/topics/390403828

其中解决的过程中使用了rem,然并卵,又换成了em
使用css3单位rem,有人这样解释rem,root-em,就是根部的em,想必em大家都懂的,那么rem就是将根节点html的font-size的值作为整个页面的基准尺寸,默认html的font-size是16px,即1rem=16px,如果某div宽度为32px你可以设为2rem。当我们把html的font-size设为20px时,1rem=20px,那么32px=1.6rem了。到这里我们也就了解了rem的用法了,那么怎么用rem来实现不同尺寸屏幕的自适应呢?在页面载入开始时首先判断window的宽度(是window的宽度($(window).width()),不是屏幕分辩率的宽度(screen.width),两者的差别请自行查阅),假设宽度为W,一个div在宽度为640px的设计稿的下的宽度为dW1,这样如果html的font-size为100px,那么这个div的宽度用rem表示是多少呢?计算:div宽度dW2=dW1/100,px与rem之间很好换算,除以100就可以,这是假定屏幕宽度为640的,而不同宽度的屏幕怎么处理,为了能保证换算容易那就要为html设置一个合适的font-size,计算:100 / 640 = fontSize / W, fontSize = W / 640 * 100 = W / 6.4;

rem px em pt 需要了解

特色文章

随机数Math.random()

特色文章

html5本地存储-localStorage

html5本地存储有两类。
localStorage -一般保存在客户端计算机,在移动端浏览器中,一般情况是永久保存
sessionStorage – 数据保存在当前会话中,或者当前窗口,当前窗口新建的窗口,相关联的标签

1、在使用之前先检查浏览器是否可以支持Web Storage。

if(window.localStorage){ 
} 
if(window.sessionStorage){
}

2、赋值和调取

var userData={
name:"www",
account:"san",
level:2,
disbled:true
}
//存储userData数据
localstorage.setItem("userData",JSON.stringify(userData));

//读取userData并赋值给新变量
var newUserData=JSON.parse(localStorage.getItem("userData"))

 

3、删除数据

//删除本地存储的key为那么的Item
localStorage.removeItem("name");

//删除localStorage所有key/value键值对,Item
localStorage.clear()

 

PS:JSON.stringify()把字符串转换成对象;JSON.parse()把对象转换成原来的数据格式。

手机App实例:

/**
* localStorage保存数据
* @param String key 保存数据的key值
* @param String value 保存的数据
*/
function setLocVal(key,value){
window.localStorage[key] = value;
}

/**
* 根据key取localStorage的值
* @param String key 保存的key值
*/
function getLocVal(key){
if(window.localStorage[key])
return window.localStorage[key];
else
return “”;
}

/**
* 清除缓存
* @param String key 保存数据的key,如果不传清空所有缓存数据
*/
function clearLocVal(key){
if(key)
window.localStorage.removeItem(key);
else
window.localStorage.clear();
}

a页面存储

function openDetails(i){
var Arr=[‘投保指南’,’投保流程’,’常见问题’];
setLocVal(‘mName’,JSON.stringify(Arr[i]));
setLocVal(‘mNo’,JSON.stringify(i)); //
openNewWin(‘wytb’, ‘wytb.html’);
}

b列表页面接收

var mN = JSON.parse(getLocVal(“mN”));
var mNn = JSON.parse(getLocVal(“mNo”));

function showGoods(){
$toast(‘数据加载中…’);
if(mNn==2){
$closeToast();
$.getJSON(mN, function(data){
if (status==0&&data&&data.data.length) {
$closeToast();
var arrData = data.data;
var tmpl = ‘<div class=\”ub ub-ac ub-pc ub-pj uinn umar-t c-wh\” ontouchstart=\”zy_touch(\’t-org\’)\” onmousedown=\”zy_touch(\’t-org\’);\” onclick=\”openDetails(\’${href}\’);\”>’
+'<div class=”ulev-app2″>${title}</div>’
+'<div class=”arrow ub-img umwh”>’
+'</div>’
+'</div>’
var s = zy_tmpl(tmpl, arrData, zy_tmpl_count(arrData));
$$(‘mytb’).innerHTML=s;
Imgclick();
}else {
$$(‘mytb’).innerHTML= ‘<div class=”ub ub-ac ub-pc uinn”>暂时没有数据</div>’;
}
});
}else{
$.getJSON(mN, function(data){
if (data&&data.length) {
$closeToast();
var arrData = data;
arrData=JSON.stringify(arrData);
arrData=arrData.replace(/height.*?\/>/gi,”\/>”);
arrData=JSON.parse(arrData);
var tmpl = ‘<div class=\”uba b-gra ub ub-ver c-wh uinn umar-t\”>’ +
‘<div class=\”ubb b-gra ub uinn3\”>’ +
‘<div class=\”t-org ulev-app2\”>${title}</div>’ +
‘</div>’ +
‘<div class=\”uinnh1 t-gra1 ulev-app2 c-wh\”>’ +
‘<span>${text}</span>’ +
‘</div>’ +
‘</div>’
var s = zy_tmpl(tmpl, arrData, zy_tmpl_count(arrData));
$$(‘mytb’).innerHTML=s;
Imgclick();
}else {
$$(‘mytb’).innerHTML= ‘<div class=”ub ub-ac ub-pc uinn”>暂时没有数据</div>’;
}
});
}
}

//打开详情页面
function openDetails(url){
setLocVal(‘mHref’,JSON.stringify(lPath+’?url=’+url));//存值
openNewWin(‘wytb_detail’,’wytb_detail.html’);
}

//手机相册调取
function Imgclick(){
var Img = document.getElementsByTagName(‘img’);
for (var i = 0; i < Img.length; i++) {
Img[i].onclick=function(){
uexImageBrowser.open([this.src]);
}
}
}

 

c页面-详情页面

function sortList(){
$$(‘Info’).innerHTML=””;
$toast(‘数据加载中…’);
$.getJSON(liPath, function(data){
$closeToast();
if (data!=0) {
data.content=data.content.replace(/FONT-SIZE: 12pt/gi,””);

//详情模板

var liPath = JSON.parse(getLocVal(“mHref”));
var tmpl = ‘<div class=”ubb b-gra ub uinn3″>’
+'<div class=”t-org ulev-app2″>’+data.title+'</div>’
+'</div>’
+'<div class=”uinnh1 t-gra1 ulev-app2 c-wh”>’
+'<span>’+data.content+'</span>’
+'</div>’;
$$(‘Info’).innerHTML=tmpl;
}
else {
$$(‘Info’).innerHTML= ‘<div class=”ub ub-ac ub-pc uinn”>暂时没有数据</div>’;
}
});
}

 

 

 

 

特色文章

IE浏览器文本模式变为杂项(quirks)页面变形

00000
今天正好解决了这个问题,在QQ群里面也碰到有人在问这个问题,故写此记录下。(这个问题让我怀疑在三年前我遇到过,但是没有记录)
问题描述:在ie10到ie7标准模式下没有问题,在ie7\ie8或IE9浏览器文本模式变为杂项页面变形或弹出层不居中;或文件上传至服务器后出现变形。
不清楚什么模式,可以F12看或者
alert( document.compatMode );
解决方法:

先瞧瞧页面是html或者jsp
1、代码规范问题
文件头

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

换成

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0//EN” “w3.org/TR/html4/strict.dtd”>
就不会出现Quirks Model了,问题也就解决了
并且

<!DOC.......

前面不要有任何文本。

2、设置为当前浏览器最高版本
3、把<%@ page language=”java” contentType=”text/html; charset=UTF-8″%> 成<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> 

pageEncoding是jsp文件本身的编码
contentType的charset是指服务器发送给客户端时的内容编码
JSP要经过两次的“编码”,第一阶段会用pageEncoding,第二阶段会用utf-8至utf-8,第三阶段就是由Tomcat出来的网页, 用的是contentType。
第一阶段是jsp编译成.java,它会根据pageEncoding的设定读取jsp,结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码(即.java),如果pageEncoding设定错了,或没有设定,出来的就是中文乱码。
第二阶段是由JAVAC的JAVA源码至java byteCode的编译,不论JSP编写时候用的是什么编码方案,经过这个阶段的结果全部是UTF-8的encoding的java源码。

ps:涉及知识

<!--常见写法如下:-->
<meta http-equiv="X-UA-Compatible" content="IE=7">  
<!--以上代码告诉IE浏览器,无论是否用DTD声明文档标准,IE8/9都会以IE7引擎来渲染页面。  -->
<meta http-equiv="X-UA-Compatible" content="IE=8">  
<!--以上代码告诉IE浏览器,IE8/9都会以IE8引擎来渲染页面。 --> 
<meta http-equiv="X-UA-Compatible" content="IE=edge">  
<!--以上代码告诉IE浏览器,IE8/9及以后的版本都会以最高版本IE来渲染面。-->  
<meta http-equiv="X-UA-Compatible" content="IE=7,IE=9">  
<meta http-equiv="X-UA-Compatible" content="IE=7,9">  
<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1">
<!--以上代码IE=edge告诉IE使用最新的引擎渲染网页,chrome=1则可以激活Chrome Frame-->

 

怪异原理有个网友总结的好啊网站地址:http://www.ibm.com/developerworks/cn/web/1310_shatao_quirks/

成长是一场舍得,肩负着醒悟的意义

成长是一场失去,肩负着枉然的意义。

16年回顾

0、因为中介不退押金,第一次走进了法院开庭。

1、解锁了6个城市 广州 青岛 大连 成都 西安 郑州,回漂北京

2、解锁了地点  广州南越王博物馆  四川博物馆  陕西历史博物馆  河南博物院  秦皇陵兵马俑 西安城墙骑行 圣心大教堂   五四广场 星海广场美丽的大海

3、美食 成都火锅 西安葫芦鸡和各种面 四川糯米滋   大连龙虾 青岛海参 郑州面条和大大的蒸饺  广州的汤早点and so on好吃到口水就要流下来

17年展望

0、充实自己

1、状态稳定读书考试充电

2、于是旅游

 

感谢16年遇到的人遇到事。有在青岛机场丢失的电脑和考卷,而后机场安勤人员王师傅帮我找到。还碰到涛哥的结婚和以前同事燕燕姐等等。和好朋友梅子的螃蟹。可是实训完后的住宿和其他遭遇只让我远离那个城市。出租车干到420块,被宰了。

大连的碰到星海广场华表拆除,跨海大桥

西安城墙上的骑行,想要飞起来,喜欢上西安这个城市

成都的火锅,好吃的让我无惧香辣,流着眼泪也要吃

广州的啊,那里的学生很友善,可惜没听到本地的歌曲咯

郑州的雾霾让我疑似自己在帝都还未出差

待续

性格有变好,食材也变丰富,说话也有提高

加油~

新的一年

祝长辈们老爸老妈家人们身体健康,事事顺心~ ~ ~

没那么难,谈CSS的设计模式(转)

以前写的时候会写这种模式,但是从来没有细究过,为何要这样写,只是觉得趁手而已。用bootstrap的时候也发现了这种规律。现在看到这个文章感觉很好,特此联系作者,转载到自己这里。

原文地址:http://ideazhao.com/2016/08/07/css_design_method/

什么是设计模式?

曾有人调侃,设计模式是工程师用于跟别人显摆的,显得高大上;也曾有人这么说,不是设计模式没用,是你还没有到能懂它,会用它的时候。

先来看一下比较官方的解释:”设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。”

今天我们来聊聊CSS的设计模式。

设计模式,这个词汇我们常见,几乎所有的编程语言都会有几套,但深入研究的人不多,原因如下:

1、似乎没有太大必要性去强调它,有问题了改一下或者按团队规范来就行;
2、不去使用一些既有的模式也无伤大雅;
3、不少人所接触的业务量级还没有达到需要规划和组织的程度,光写布局,写特效,照顾兼容,就够喝一壶的了,没有意识去思考一些方法论的问题。

当然,这三者都是我经历过的,相信你也是~

我们都会长大,都会慢慢的做更多、更大、更复杂的项目,这个时候,就需要自上而下,全流程的去思考一些问题,后台不说,只讲前端,比如:风格的制定、色调、模块、布局方式、交互方式、逻辑等等,如果再加上团队合作,若再没有一个规划的话,要不了多久,那些看起来没问题的代码,就会暴露出各种问题,模块命名、类的命名、文件的组织、共用模块的提取、代码的复用、可读性、扩展性、维护性。它们看起来只是一些简单的小动作,却需要你看得更远,避免将来出问题需要付出更大的代价,甚至被迫整个项目重构,可谓,功在当代,利在千秋~

既然要对CSS进行设计,那么肯定是它本身存在一些问题或者缺陷,其中,一个最明显的就是,它的任何一个规则,都是全局性的声明,会对引入它的页面当中所有相关元素起作用,不管那是不是你想要的。而独立及可组合的模块是一个可维护系统的关键所在。下面,我们就从多个层面来探讨一下,到底该怎样写CSS,才是更科学的。

从需求出发


我们刚开始学习写字的时候,是不会去考虑,写出来的某句话好不好,文章结构合适不合适,因为我们是意识不到的。写代码也一样,刚开始,我们只是去定义规则,能用对了属性,语法正确,把页面实现出来了,就好。慢慢地,就会发现,页面也是有结构的,我们按照页面的结构去组织代码,会不会更好?比如,分成头部、导航、侧边栏、banner区、主内容区、底部等。

然而这样貌似还是不够,因为还有一些东西,复用度是很高的,又不好把它归为任何一个固有模块,比如:面包屑、分页、弹窗等,它们不适合被放到某一个固有模块的代码中,就可以单独的分出一段专属的css和js,或许,这就是组件化的由来~


在分了之后,我们的代码看起来已经比之前好很多了,组织清晰,维护性大幅提高,但是,好像还是不够,我们会发现另外一些东西,很细小,但复用度也很高,它们同样不适合被放到模块中去,比如,边框、背景、图标、字体、边距、布局方式等等。如果我们在每个需要它们的地方,都定义一次,它们会被重复很多次,显然,这背离好的实践,会造成代码冗余和维护困难。所以,我们需要“拆”。拆过之后会怎样?我们想在哪里用可以直接加,需要改的时候统一改。


经过了“分”、“拆”,我们的代码结构已经十分清晰,各个内容模块,功能模块,UI模块都乖巧的等待召唤,那么还差什么?是的,还差有序的组织,分类清晰之后,还需要排列有序,从不同纬度去考量,我们总能精益求精。举个栗子,我们可能会看到像这样:

@import “mod_reset.css”;
@import “ico_sprite.css”;
@import “mod_btns.css”;
@import “header.css”;
@import “mod_tab.css”;
@import “footer.css”;

我们将不同的部分按照一定的顺序去摆放,能让我们的代码看起来更加有序,易于维护,同时,有利于进行继承或层叠覆盖。不要小看这一步,看似可有可无,实际要求比较高的统筹规划能力,可以减少冗余代码和快速定位问题位置等。

除此之外,我们依然可以有其他的方法来帮助我们进行区分代码范围,比如:

1、在文件头部建立一个简要的目录

2、使用区块注释

在注释中,应该尽量详细的写清楚该段代码的目的,状态切换,调整原因,交互逻辑等等,这样不仅利于自己的维护,更加利于别人接手维护你的代码。

从结论出发

除了需求当中一些通用部分,另外一些也是需要注意,但不会被正式定义的东西,它们来源于我们的实践经验,比如:

层级嵌套不要太深

稍微了解一些浏览器渲染原理的都知道,它在解析CSS规则的时候,是从右向左,一层层的去遍历寻找,如果层级太多,必然增加了渲染时间,影响渲染速度。另外,如果选择器层级过多,也就间接反应了,你的HTML结构可能写得不够简洁。

那么具体多少层合适?一般建议是不超过4层,但话又说回来,超过4层会怎样吗?不会有多明显的影响,除非你写到很恐怖的数量,或者项目极其庞杂,可能能看出来影响,其实从我们日常需求来看,4层以内足可以解决绝大多数问题,故而,是合理的。

避免使用元素选择器

出于两点考虑:

第一点,和上一段提到的相关,在HTML中,有很多常用的高频元素,比如,div、p、span、a、ul等,如果,你在多层选择器的最内层使用了元素选择器,那么,在开始寻找时,浏览器就会遍历HTML中的所有该元素,显然,这是没有必要的。

第二点,我们的需求和代码结构都是存在着潜在变化的,今天写好了一个页面,明天可能就要再加进去一个按钮,再加进去一句话,再加进去一个图标。我们写好的一个结构,也随时可能被复用到别的结构中去,所以,如果,你使用了元素选择器去定死某个东西,不论是新加进来的东西,还是被复用的东西加到别的结构里去,都极有可能产生样式的冲突,这个时候,你又不得不写多余的样式进行覆盖修正,或者重新定义类。

所以,出于以上考虑,在具体的代码模块中,尽量不要使用元素选择器,使用元素选择器的前提是,你完全的确定,不会导致出现问题。注意,我用的限定范围是“具体的代码模块”,那么用于定义通用规则的样式,是可以的,也是推荐使用的,比如,reset。也可以是别的地方,这就需要我们自行考量。

避免使用群组选择器

群组选择器会有什么问题?直接上图吧。

图中这种情况不多见,此处只是举个例子,这里写了三组选择器,用来定义不同地方的同一种样式,其明显的缺陷是,如果有第四个地方需要使用到,你不得不再往里加一组选择器,如果有10个不同的地方,你就写10个?这对于维护来说,是很痛苦的,聪明的我们,怎能被如此繁复又不必要的劳动所困扰,故而,墙裂不推荐此种做法,完全可以提取出来一个公用类,定义统一样式,然后,哪里需要放哪里,复用和维护都会更加方便。

当然,你可能会说,我在写第一个的时候,不会知道后面还有那么多,有没有必要提取是不知道的,是的,所以,需要你根据经验去判断,也需要在项目推进过程中,适时的对代码进行整理和重构。

文件引入的数量和顺序

对于刚接触网页的朋友来说,这两点也是容易忽视的,因为它们看起来没什么大影响,多几次请求,样式是否已经加载,都没那么容易把人逼疯,但是出于对用户体验的极致追求,我们还是希望文件请求次数尽量少,内容的显示有个优先顺序,文件加载有个先后顺序,这样,在实在难以缩减文件大小的时候,让用户先看到更重要的,正常展示的内容。

以上只是几点举例,更多实战结论,大家可以多读相关的博文或者书籍,都会有前辈们的经验之谈。

从矛盾出发

通用和语义

Naming convention is beneficial for immediately understanding which category a particular style belongs to and its role within the overall scope of the page. On large projects, it is more likely to have styles broken up across multiple files. In these cases, naming convention also makes it easier to find which file a style belongs to.

命名规则有助于立即理解一个特定样式属于哪一类,它在页面的整体范围内的作用。在大型项目中,它更可能有在多个文件中被打破的样式。在这种情况下,命名约定也可以更容易地找到一个样式属于哪个文件的文件。

很多时候,我们需要一个东西被定义为通用的,以便复用,比如:模块标题、按钮、提示文字、图标等,最开始的时候,我们习惯去看视觉稿的内容,是“新闻”,我们就定义“new”,是“关于”,我们就定义“about”,是红色的按钮,我们就定义“red-btn”等,这样会导致一个问题,如果有另外一个跟新闻列表差不多的样式和结构,但不是新闻,怎么办?继续使用“new”显然不合适,这就告诉我们,不能把目光局限于内容,需要内容和结构分离。

不能用“new”了,那用什么呢?abc?123?这样总不会冲突了吧,万事大吉~其实,这是走了另一个极端,这样虽然在很大程度上避免了和别的模块冲突,但其本身的可读性就被大大降低了,别人,甚至你自己过一段时间都会忘记它是什么,对于团队合作是很不利的。至于需要用什么样的命名方式,需要你根据项目的整体来进行规划,适合根据什么特点来区分与之不同的结构,又能让人比较容易的在名称和结构之间建立联系,比如所属类别、功能、页面等。

团队和个人

一个团队当中,大家的经历不同,编码水平和习惯也不同,这样就会造成,一个人一个写法,你用中划线,我用下划线;我用英文全拼,你用简写,等等。这些虽然没有什么对错之分,但对于团队成员之间的协作造成了不小的障碍,别人必须花时间去适应和读懂你是怎样组织和定义的,这就无形之中提高了成本。

所以,就有了“团队规范”存在的必要,规范除了一些写法上的规定,让我们的代码更加统一,清晰,可读性更强,辨识度更高。还可以提取一些最佳实践和复用模块等,对于团队里每个人来说,都是有好处的。

当然,对于人来说,最难的,莫过于调整既有的习惯,这就会有进入一个团队之后“转型”的阵痛,其实这种痛也是成长的痛,你会学习到更好的编码方式,更好的实践方法,会从项目或者团队的整体去考量一件事的价值和意义。

CSS和预处理器

前面我有文章详细的谈过CSS预处理器,我曾经对它也是排斥的,因为学习成本,因为觉得应用起来没有必要,可是一旦你决定去学习使用它,就会觉得不是那样,预处理器在向你介绍它自己的时候,就有特意强调过,它的语法是和CSS完全兼容的,也就是说,你在LESS或者SASS文件中,直接写CSS代码是没有问题的。除此之外,它能给我们提供很多便利,比如定义统一的变量;使用嵌套而不用一直重复着写一些选择器;可以提取公共的代码块然后很方便的复用等等。

故而,当我们已经把CSS组织和书写得很好了之后,预处理器,就是再次为我们插上一双翅膀,能更灵活和高效的编码。

从现有模式出发

再来简单看看一些广为流传的模式。(ps:先后顺序与排名、好坏无关)

一、OOCSS——Object Oriented CSS
接触过计算机的应该都知道,OOP——Object Oriented Programming,如果你是第一次接触OOCSS,你会很困惑,难道是“面向对象的CSS”吗?它不是一本真正的编程语言啊,如何面向对象?

OOCSS,最早被提及,是在2009年,它的两大原则是:

separating structure from skin and container from content.

直译过来就是,结构和皮肤分离,容器和内容分离。

即不要把结构和皮肤以及内容进行强耦合,而是相互独立,所要达到的目标是更易复用和组合,可以选择使用,选择引用等。

详细了解链接:https://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/

二、SMACSS——Scalable and Modular Architecture for CSS

从实践上说,OOCSS给出了一种值得借鉴的思想,但在代码的组织方面,它并未给出具体的实施方法,从这一点上来说,SMACSS更进一步。

它的核心是:

1、Base(基础)
基础的样式,就是一些需要最先定义好,针对于某一类元素的通用固定样式。

2、Layout(布局)
布局样式,是跟页面整体结构相关,譬如,列表,主内容,侧边栏的位置、宽高、布局方式等。

3、Module(模块)
模块样式,就是我们在对页面进行拆的过程中,所抽取分类的模块,这类的样式分别写到一起。

4、State(状态)
页面中的某些元素会需要响应不同的状态,比如,可用、不可用、已用、过期、警告等等。将这类样式可以组织到一起。

5、Theme(主题)
主题是指版面整个的颜色、风格之类,一般网站不会有频繁的较大的改动,给我们印象比较深的是QQ空间,其他应用的不是很多,所以,这个一般不会用到,但有这样一个意识是好的,需要用到的时候,就知道该怎样规划。

有了以上5点分类策略,我们的代码组织起来,思路就会很清晰,会安排的很有序,另外的好处是,可以解决命名难和混乱,之所以有这个问题,主因便是我们不知道以怎样的标准去定义元素的所属和特点,有了分类之后,我们不会很随意和混乱的去命名,有了依据,就能更轻松,也不易冲突。

详细了解链接:https://smacss.com/

三、Meta CSS

原子类,也可以称之为“无语义”类,像这样:

它的特点是什么?样式和结构、内容无关,预先定义好这么一组规则,在需要的地方加上即可,我相信每个人第一次看到这种写法的时候,都会想:还能这样写啊?!是的,总有一些人,一些新的思想和方法会涌现出来,它就是其中之一,当然,并不是在称赞其本身有多么好,而是说这种现象和过程是好的,它本身经常被人吐槽,比如:“这样写和直接内联有区别吗?”、“如果要调整样式,就要去改HTML,维护更加麻烦,也有违样式和结构分离的初衷”等等,其实我个人也是不赞成上面这种写法的,如果你要把这些抽离出来,那么还有什么抽不出来的呢?而且这些属性,在项目之间,页面之间,模块之间,并没有太大的通用性,把这些抽出来,只不过是稍微懒省劲儿些,但为了照顾到更多情况,你必须写入冗余代码,是得不偿失的。

虽然它有缺点,我个人赞成另外的一些东西分出来,比如:浮动(float)、文本布局(text-align)、Flexbox布局等,这些是没有那么多可能性的值,而且使用频繁,复用方便,改动较少,除此之外,你还可以提取另外一些公共的小颗粒类,比如按钮的种类,文字颜色的种类等,这些和CSS本身无关,和项目相关,这就是借鉴其思想,而不是直接拿来用

四、BEM

严格说来,BEM不是一套有骨有肉的模式,也不仅仅局限你在CSS的层面去规划,它是一种怎样去组织、编写代码的思想,而且,看似简单的它,对前端界的影响却是巨大的。

它的核心如下:

Block(块)、Element(元素)、Modifier(修饰符)

它帮助我们定义页面中每一部分的级别属性,从某种意义上说,也是一种“拆”。命名规则如下:

它的出现,曾给不少人带来启发,但是也有另一部分人仍然抱着挑剔的态度,譬如:

1、风格不统一,显得代码不够整洁美观
2、可能会导致类名过长

还是前面说的,你可以不去直接用它,但要清楚它的优点:能够使得我们仅通过类名就知道哪些代码是属于一个模块内,以及在模块中所起的作用。然后借鉴之。

当然,BEM集聚了很多人的心血,也得到了很多的赞誉,其中就包括OOCSS的作者。所以,它肯定不是这么简单。它还会告诉你,怎样配合着js来写,你的文件怎样组织更好,项目该怎么构建等。详细可以到官网去查阅。地址:https://en.bem.info/

从实际出发,决定结果的人是你

到底怎样使用设计模式?

虽然已经有成熟的设计模式,但在实际当中,你可能觉得哪个跟自己的项目都不能完全吻合,或者你要去为了使用它们而调整,成本很高。其实,我们不需要去迎合模式,要让模式为我所用,你需要去了解它们背后的原理,要知道它们用什么方式解决了什么问题,然后借鉴之,用它的方式解决我们的问题,就好,这样就不需要作难要不要用,也不需要纠结选哪个,不是简单的说哪个好,哪个不好,总有我们能够用得上它的地方。海纳百川,集百家众长。

我个人一直以来所坚持的另一个观点就是,前端开发的三驾马车——html、css、js,不要,也不能孤立的去谈那样好或者这样好,我们极少会有只用一次的代码或者模块,也不会只写一种语言,三驾马车都是在一起协作的,都是会有复用、扩展和团队合作多方面的因素在里面,故而,不能抱着这样的想法:我现在就在做这个,它就是唯一的,就是固定的,没问题。其实很多问题都是潜在的,要带着发展眼光去看待。项目的文件之间,项目之间,团队成员之间,不论你的分工是哪块,都要考虑到前后的影响和可能给合作带来的不便。

怎样才是最佳实践?有“实践”,才有“最佳”,脱离实际情况谈最佳,就是空中楼阁。那么,最好的模式,不是哪个经典的模式,而是在项目进行中,不断的磨合调整而出的。故而,不需要再惧怕看起来不明觉厉的设计模式,也不需要因为自己还不懂设计模式而郁闷,它就是人们总结出来的实战方法,你也可以有自己的模式~

psb

2016已过287天咯

前半年的节日过得飘忽不定,躲在出差旅途中避过

白露已去,中秋已过,国庆已过,重阳已过。

你在等田园盛开的橡树,额头的汗滴烧着太阳火。

过去的云霞一直在心里,直到候鸟归来的相遇

沉溪不语,静静的回忆。

今天任性不想备课,但是保不定半夜披衣起床coding

现在备课备的有点疯魔,就像再好的小说也会有卡壳瓶颈的时候,有时再疯狂的热爱也会有偶尔的不耐。
想到南越王博物馆看到,曲流石渠里面故意点缀的石头,让水流有起伏浪花,人生也是如此,有起伏,有点缀的难题,才会有意激情四射闪闪发亮。


img_8412

img_8441

img_8413

 

进度条

 

进度条

0%

啊哟,成都的火锅啊

出差成都,于8月26日记

昨天晚上去宽窄巷子转了转,感觉跟南锣鼓巷神似。只不过人没有那么拥挤,小物件很精细。还有个拴马石。那里边有个琉璃馆非常好来,晶莹剔透好漂亮,据说琉璃的来源还跟范蠡和西施的爱情故事有渊源。啧啧嘻嘻

然后跟付老师一块去吃了火锅,我的天呐。以前我不敢吃辣,现在竟然看到红辣辣的火锅,吃的意犹未尽,走步溜达回去酒店。太撑了

psb (1)psb (2)psb (3)psb

好吧,到了现在……上了厕所,整个人都不好了,我感觉自己在喷火,不可描述的部分在喷火!!!!!!

天哪……

 

 

热爱

许巍是始终带着微笑看着远方,让我感觉无论发生了什么都有希望;汪峰是落泪时也会永远高仰着头颅,让我感觉着无尽的力量;朴树是平淡的看着天空,白云飘舞,让我感觉到自己的眼中世界;郑钧是从荆棘丛里出来依然满脸笑容,热爱生活,正如他们唱的一首首歌,有着顽强的生命力!

mark

田园将芜胡不归

魏晋南北朝,如果可以选择回到古代的一个朝代,那我会很乐意的回到魏晋南北朝的时代。文人如宝石熠熠生辉,无论是帝王将相的曹操曹植萧统还是归隐园林的陶渊明谢灵运,写美色的潘岳同时代的西晋诗坛用构思十年写出《三都赋》的左思导致一时洛阳纸贵,被称西晋诗坛第一人的,真是好奇这么多的惊才艳艳的人们遇到一起,该是怎么相处怎么恩怨,又怎么能互相不挫其锋芒,崭露头角的呢?

历史的长河在流动中,微波荡漾,闪亮的一点都是他们。真是好奇啊,少年才气。这选择真是令自己开心,看这些,真是情不自禁拍案叫好,有时愤而道道,有时开怀大笑,有时泪水涟涟。捻过一页,两目灼灼。

田园将芜胡不归,换行则已

clientX、 screenX和pageX

document.onclick = function(evt){

var e = evt || window.event;
// 浏览器可视区域左上角的坐标 可视区域坐标 client clientX
box1.innerHTML=e.clientX+","+e.clientY;

// 电脑的屏幕坐标,screen 屏幕坐标
box2.innerHTML = e.screenX+","+e.screenY;

// 根坐标,有些版本不兼容可用clientY+scrollTop (IE8)
box3.innerHTML = e.pageX+","+e.pageY;
}