xueqianban
xueqianban copied to clipboard
f2e-journey
班会第 21 期
班会主题: 那些年我们手机上用过的 App
- 技术
-
- 垂直对齐
- 伸展一个元素到窗口高度
- 基于文件格式使用不同的样式
- 创建跨浏览器的图像灰度
- 背景渐变动画
- CSS：表格列宽自适用
- 只在一边或两边显示盒子阴影
- 包裹长文本
- 制造模糊文本
- 用CSS动画实现省略号动画
- 样式重置
- 清除浮动
- 跨浏览器的透明
- CSS引用模板
- 个性圆角
- 通用媒体查询
- 现代字体栈
- 自定义文本选择
- 为logo隐藏H1
- 图片边框偏光
- 锚链接伪类
- 奇特的CSS引用
- CSS3：全屏背景
- 内容垂直居中
- 强制出现垂直滚动条
- CSS3渐变模板
- @font-face模板
- 缝合CSS3元素
- CSS3 斑马线
- 有趣的&
- 大字段落
- 内部CSS3 盒阴影
- 外部CSS3 盒阴影
- 三角形列表项目符号
- 固定宽度的居中布局
- CSS3 列文本
- CSS固定页脚
- 跨浏览器设置最小高度
- CSS3 鲜艳的输入
- 强制换行
- 在可点击的项目上强制手型
- 网页顶部盒阴影
- CSS3对话气泡
- H1-H5默认样式
- 纯CSS背景噪音
- 持久的列表排序
- CSS悬浮提示文本
- 深灰色的圆形按钮
- 在可打印的网页中显示URLs
- 禁用移动Webkit的选择高亮
- CSS3 圆点图案
- CSS3 方格图案
- Github的fork色带
- CSS font属性缩写
- 论文页面的卷曲效果
- 鲜艳的锚链接
- 带CSS3特色的横幅显示
-
- 介绍 create-react-app 工具
- React Tutorial 学习笔记
-
复制文件到另外一个目录时保持原有文件的目录结构
-
上传文件到阿里云 OSS 的 gulp 插件
-
- 全量发布
- 增量发布
-
// 注意: 如果要同时打开两个以上的弹窗, type 参数必须是 1 或者 2 // 因为 type 默认值是 0, 会造成无法同时创建两个以上的弹窗 layer.open({ type: 1, title: 'title', area: ['390px', '330px'], content: 'content', btn: '再弹一个', yes: function(){ // 这里再使用 layer.open 或者其他内置方法都可以 layer.confirm('a'); } }); -
相信写css的人都会遇到下面的问题：
- 糟糕，怎么命名这个class，好像不太贴切，要是冲突了怎么办，要不要设计成通用一点...
- 而改别人css代码的时候则会一直有个疑问：这个class到底是只在这个地方用了，还是其他地方都用了？
于是就有了下面的做法：
- 最后终于被逼出了个class，简洁也好，中英混搭也罢，看着一头雾水也没关系，反正最后页面显示出来的。
- 这个class应该是只有这个地方用到，我可以放心写。上线之后。如果没问题，则暗自自我欣赏，看吧问题就这么简单，分分钟搞定呀；如果冲突了，则无限感慨，哎，改的时候我就隐隐不安啊，妈蛋，深坑，这是谁写的，谁写的！！！
- 不好，这个class说不定其他地方也用到了，我得加个限制范围，加个父元素？要不重新再命名个class吧，比较保险。最后如果没问题则表示还好比较机智，怎么说哥也是混过的，还是有几斤几两的；如果有问题则表示防不慎防啊，这也太太太坑了吧。
也许你花了十分钟设计定义的一个class样式，人家分分钟就给你干掉了，这得多恼火；也许这个页面好好的，跑到另一个页面就跟原先的样式有了冲突。
所以class命名的难就难在既要重复利用，又要避免样式的冲突。如果要重复利用，那么当然是越简单越好，越抽象可用的地方越大，太具体了就完蛋了。而如果要避免样式冲突。BEM的方式最简单，class都唯一了，那还冲突个毛线；其次就是通过父元素限定作用域，可以搞几个层级，而不是单独一个class定义样式；还有就是追加class，来实现差异化；最后不同的页面不同的文件，你用你的我用我的。
class命名的发展历程
- 混沌阶段，没有规则就是最好的规则(大概每个人都是从这个阶段一路走过来的, @liangmiao930617 同学对吧)
- 原子类阶段，聚集神龙现身手
- 模块阶段，以职能划分，添加前缀
- BEM阶段，规则有序
其实每个命名的发展经历都有其特定的历史意义，也当然有其价值。所以吸取之长，弃之短缺就很好了。
常见class关键词
- 布局类：header, footer, container, main, content, aside, page, section
- 包裹类：wrap, inner
- 区块类：region, block, box
- 结构类：hd, bd, ft, top, bottom, left, right, middle, col, row, grid, span
- 列表类：list, item, field
- 主次类：primary, secondary, sub, minor
- 大小类：s, m, l, xl, large, small
- 状态类：active, current, checked, hover, fail, success, warn, error, on, off
- 导航类：nav, prev, next, breadcrumb, forward, back, indicator, paging, first, last
- 交互类：tips, alert, modal, pop, panel, tabs, accordion, slide, scroll, overlay,
- 星级类：rate, star
- 分割类：group, seperate, divider
- 等分类：full, half, third, quarter
- 表格类：table, tr, td, cell, row
- 图片类：img, thumbnail, original, album, gallery
- 语言类：cn, en
- 论坛类：forum, bbs, topic, post
- 方向类：up, down, left, right
- 其他语义类：btn, close, ok, cancel, switch; link, title, info, intro, more, icon; form, label, search, contact, phone, date, email, user; view, loading...
-
css3中，新增了一种样式规则，@font-face，这个规则可以用来引入自定义的字体，到客户端 上面的自已个h1中使用的，正是我们存在服务端的字体。由于各个浏览器的兼容性问题，
- IE浏览器：EOT
- Mozilla浏览器：OTF，TTF
- Safari浏览器：OTF，TTF，SVG
- 歌剧：OTF，TTF，SVG
- Chrome浏览器：TTF，SVG
@font-face { font-family: 'icons'; src: url(../font/curiconfont.eot#iefix) format('embedded-opentype'), url(../font/curiconfont.woff) format('woff'), url(../font/curiconfont.ttf) format('truetype'), url(../font/curiconfont.svg?#iconfont) format('svg'); font-weight: normal; font-style: normal; }既然font-face可以指定字体文件，那么字体长成什么样，不就是开发者说的算了么. 文字不就是图像么。人类最早发明文字的时候就是按照图像来发明的。所以，我们可以把一些字符，描述成图像。在我们的网页上，当成图像来使用。这就是iconfont了。把一些零散的icon做成字体。我们调用文字的时候，渲染出来的就是icon图像了。
iconfont的利与弊
-
iconfont图像放大后，不会失真
相信读者们没有见过文字在网页上放大的时候会失真的状况吧，因为字体是矢量的，字体的描绘只记录绘制的路径。而图片不是，我们如果把一张小图放大若干倍之后，会发现图像变得模糊了。因为图像是基于像素点的描述，放大后，之前图像的一个像素，被放大为多个像素。自然是会失真的
-
iconfont节省流量
在图片清晰度要求越高的情况下，我们的图片本身就会越大。这样非常耗费资源，而且，图像需要的色彩值信息，也会存储。这样也极大的浪费了空间。iconfont颜色由css决定，尺寸要求变大的话，则适应性的变大。传输的大小不会变大。
-
iconfont在颜色变幻方面很简单
-
iconfont不能支持一个图像里面混入多重颜色
作为文字，是不会出现左边是红色右边是绿色的状况的。一个文字，是一个整体，统一的颜色。这个颜色就取决于css的color了。所以使用iconfont做图标的话，最好使用纯色的图标。
-
iconfont的使用没有使用图片那么直接，简单
-
在刚有web的时候，前端与后端的交互，非常直白，浏览器端发出URL，后端返回一张拼好了的HTML串。浏览器对其进行渲染。html中可能会混有一些php(或者php中混有一些html)。在服务端将数据与模板进行拼装，生成要返回浏览器端的html串。
这与我们现在做一个普通网页没什么区别。只不过现在，我们更常使用模板技术来解决前后端耦合的问题。
前端使用模板引擎，在html中写一些标签，与数据与逻辑基本无关。后端在渲染的时候，解析这些标签，生成HTML串，如smarty。其实前端与后端的交互在服务端就已经有一次了。
// ajax获取字符串直接渲染方式 // // 如果这种模板的拼装会发生多次。是一个非常频繁的行为，且模板基本一致，只是数据变动的话，最好是一开始采用客户端拼装的方法。 // 因为，同样的模板没有必要被传到客户端好几次。这样，我们可以剩下传输同样模板的流量，请求更快 // 不过，这种做法也有问题，就是用户同步刷新的时候，需要等页面渲染完，再发一个请求，去请求第一屏的数据，才能开始渲染。 // 这个过程相当于发了两次请求，等待的时候还是有所感知的 document.querySelector('.blankPlace').innerHTML = xhr.responseText;// ajax获取数据，前端进行拼装的方式 // // 同步的时候，就将一段渲染好的HTML，直接输出到页面，而在异步的时候，请求的也是这段HTML，直接将请求回的HTML往页面上一塞就完成了。 // 这样就可以达到同步页面的时候，直接输出 var res = JSON.parse(xhr.responseText); document.querySelector('.blankPlace').innerHTML = '' +'<h2>'+ '我是模板'+ '</h2>'+ '<div>'+ res.data+ '</div>';如果前端的js里写一份模板，后端的html(jsp/asp/smarty)中也写一份模板呢？这样，同步的时候，直接用后端HTML(jsp/asp/smarty)中的模板。异步拉取数据的时候，每次使用js中的模板进行拼装 。同步也能保证首屏的速度，异步也能保证传输量的限制与速度。可是这样，也会面临问题，那就是，你的模板需要维护两份。如果那天产品和你说，我要改一下页面的结构。你不得不改动HTML的时候。js中与jsp/asp/smarty中的模板都需要同样的更改两次
smartyMonkey 用js解析smarty语法的模板，达到服务端smarty与客户端共享同一套模板的目的
前端解析模板的引擎的语法，与后端j解析模板引擎语法一致。这样就达到了一份HTML前后端一起使用的效果。一改俱改，一板两用
直接刷HTML的成本太高, 好在react给了我们一种新的思路，它用最少的开销帮我们处理模板的更新，却又不用我们维护更新时繁琐的步骤。有兴趣的读者可以了解一下react的diff算法及其应用。
-
-
什么是功能统计
比如，你想看一个功能有多少用户进行了点击，来证明用户是否喜欢这个功能，亦或是你想看看用户究竟会在你的页面停留多长时间，从而判断用户的黏性。那么，在用户点击那个功能的时候，前端发送一条日志到服务端，这样积累下去，我们就能获得，每天有多少用户在点击某一个功能了。在功能发生迭代后，我们也能根据统计，来判断用户是否喜欢新的变化。
-
如何统计
只要在想统计的行为发生时，发送一条请求到达服务端即可。这样我们的服务端就有了相应的记录。我们就能开心的利用记录数量来判断点击数量了。
一般来讲我们不必为了发送请求，就在各处点击的地方加个ajax，其实有种发送请求的方式比ajax更加的简单。而且还避免了跨域问题。其实直接给一个图片、script标签赋值地址，就完成了一次GET请求。
-
服务端如何接收并使用数据
服务器的server都会有access日志
-
-
- 网站都有哪些指标？
- 首屏时间(包括首屏的DOM元素的渲染，展现在用户第一屏幕的所有图片都完成。)
- 白屏时间(就是页面处于空白的时间。页面空白，用户就会焦躁，并且变得不耐心。影响白屏时间的多数是：DNS解析耗时+服务端耗时+网络传输耗时。)
- 用户可操作时间(我们的网页用户可以使用的时间。一般来讲 domready时间，便是我们的用户可操作时间了)
- 总下载时间(使用window.onload即可)
如何统计自己网站的这些指标
更建议采集用户日志，即，在自己网站的代码中，增加统计，并把统计结果发送到服务器。在服务器采集这些日志，并产生一个监控的网站。其实大可不必使用一些付费的服务，我们自己就可以轻轻松松的做一个简答的速度监控服务。
- 网站都有哪些指标？
-
- 产品
-
对于没有搜索到结果的页面给与用户友好提示
例如提示: 没有找到符合搜索条件的内容
如果不给用户提示的话, 用户点击了搜索按钮之后会觉得系统没有反应, 类似的提示文案可以参考 QQ 中的查找功能
-
真实电影《双十一：零点之战》讲述阿里巴巴神秘技术战队的故事，是阿里巴巴首次对外公布七年双11技术备战历程的纪录大片。
-
