您的位置:奥门新浦京网址 > Wed前段 > 在Email中防御性地使用HTML5和CSS3的指南,是时候再

在Email中防御性地使用HTML5和CSS3的指南,是时候再

发布时间:2019-10-14 18:31编辑:Wed前段浏览(127)

    视频播放–踩坑小计

    2018/06/09 · JavaScript · 视频

    原文出处: chenjsh36   

     

    随着流量时代的到来和硬件技术的提升,越来越多的网站希望能在PC端或移动端播放自己的视频,而 <video>的兼容性的逐渐完善,使得开发者更愿意使用它来实现视频播放场景。

    本篇文章主要罗列__视频播放的通用场景及各场景下踩过的坑__,希望能__帮助开发者在遇到需求开发时能更快地选择合适的技术方案同时减少采坑的次数__。

    在Email中防御性地使用HTML5和CSS3的指南

    2015/04/20 · CSS, HTML5 · 1 评论 · Email

    本文由 伯乐在线 - fzr 翻译,黄利民 校稿。未经许可,禁止转载!
    英文出处:litmus.com。欢迎加入翻译组。

    “在Email中不能使用HTML5或CSS3”。

    由于它们“有限”的支持,这已成为邮件设计行业的一个普遍共识。然而,我们现在可以说它是一个完全荒唐的说法。

    尽管支持还不是十分通用的,但许多主流电邮客户端已经可以支持HTML5和CSS3了。实际上,电邮总体市场的50%都支持HTML5和CSS。前五大电邮客户端中也有3家开始支持它们了。对于特定顾客,可支持的内容可能会更多。

    但是,那些还不能支持这些高级功能的客户端会怎么样呢?你的邮件在这样的订阅者的邮箱中该如何展示?当这些涉及到邮箱,就归结为一个:为订阅者提供非凡的体验。然而,这也不意味着你的邮件必须在每一家客户端中都显示的一样——只需要让你的所有订阅者都能易得易取。

    我喜欢的两位邮件设计师——Jonathan Kim 和 Brian Graves——就十分强调使用不同的方法实现:防御性邮件设计和渐进式增强。

    防御性邮箱设计

    大概两年前, Jonathan Kim在我们的 Mobile Master 作品展上提出了“Pushing the Limits of Email”的概念。在谈话中,Jonathan发明了一个新词来说明当前的电邮设计状态,即防御性邮件设计。

    他解释说,由于一些邮箱客户端对CSS的支持有限,使得邮件设计者们陷入了陈旧的设计状态。他倡导邮件设计者们优先为那些支持网络渲染引擎的客户端设计,进而推动邮件设计行业发展。

    渐进式增强

    以此类推,在2014年的邮箱设计大会上,DEG的UI设计师, Brian Graves,,提出了“赢得在每个屏幕上设计的战斗”。他的谈话的重点在于渐进式增强,关于在支持的环境上提供高级功能。他也强调了优雅降级的重要性。优雅降级意味着,即使订阅者的邮箱客户端不能支持某项特定功能,你也要能为他们提供愉悦的用户体验。

    对获得Brian的完整展示感兴趣?幻灯片和录像现在都有提供了。

    自动楼梯就是实际生活中一个渐进式增强和优雅降级的完美例子。已故喜剧演员Mitch Hedberg开玩笑说,“自动扶梯永远不会出故障:因为它可以只是一个楼梯。你应该永远也不会看到‘自动扶梯暂时故障’的标牌,只是‘自动扶梯暂时为楼梯’,不利于方便。”不论环境如何,自动扶梯都能保持自己的功能。

    为HTML5和CSS3实现渐进式增强

    使用渐进式增强是解决邮件设计的最有效方式。我们都知道的是,在邮箱中使用传统的HTML5和CSS3会在不同客户端之间引起许多渲染问题。向后的兼容性非常不一致——一些HTML和CSS有稳固的向后兼容性而其他的却并没有。对此,不同的客户端采用了不同选择。使用标准的HTML5和CSS3需要更多的测试,而且会影响开发速度。所以,到底什么才是在邮箱中实现渐进式增强的最好方法?

    在电邮中使用HTML5和CSS3不必太困难。它不要求在古怪的邮箱客户端上浪费大量时间排除故障(说的就是Outlook邮箱)。它所需要做的就是用一个合适的框架来快速执行HTML5和CSS3而不用烦恼和担心产生渲染问题。而且,非常幸运的是,我们有那样的框架。

    下面就是邮件设计者们和开发者们提供的一行重要的代码:

    XHTML

    @media screen and (-webkit-min-device-pixel-ratio:0) { /* Insert styles here */ }

    1
    2
    3
    @media screen and (-webkit-min-device-pixel-ratio:0) {
      /* Insert styles here */
    }

    这个媒体查询只针对支持WebKit的邮箱客户端——对HTML5和CSS3有难以置信的支持度。这个媒体查询允许你使用现代技术例如HTML5视频、CSS3动画、web字体以及更多。

    这个方法也将现代邮件客户端和旧式客户端的邮箱开发分为两部分。你可以在使用Safari或Chrome浏览器为支持WebKit的客户端测试开发现代技术的同时,使用Firefox为旧式浏览器提供诸如外观之类的基本体验。

    这样解决电邮开发问题可以将更多的质量控制过程转移到浏览器方面而不是电邮客户端。这给予邮件设计者以更多的权力,控制力,和自信去开发一个能在所有邮箱客户端之间优雅渲染的电邮。

    下载这些Litmus测试结果,显示了就媒体查询对WebKit的支持。值得注意的是,Gmail——既是一个web邮箱客户端,也是一个移动App——并不支持媒体查询,所以这些测试对那些屏幕截图无效。

    你也可以针对Gecko(Firefox)渲染这个媒体查询:

    XHTML

    @-moz-document url-prefix() { /* Insert styles here */ }

    1
    2
    3
    @-moz-document url-prefix() {
      /* Insert styles here */
    }

    很少有客户端使用Gecko(Firefox)作为渲染引擎,这也是为什么最好就支持WebKit的邮箱提供你的增强版。但是,使用媒体查询为WebKit渲染引擎添加同样的功能就简单的多了,对Thunderbird之类的客户端而言。

    除了这个方法,还有其他在电邮中实现HTML5和CSS3的方法吗?有。但我们相信这个方法是开发的最迅速的方法——也是最安全的。它缩小了为特殊邮箱客户端开发外观之类需要的工作量,而且集中于基于浏览器的测试。

    总结:渐进式增强的建议

    了解你的受众

    订阅者在哪里打开你的邮件?他们会使用对HTML和CSS支持的很好的如iPhone和AppleMail之类的客户端吗?你可以使用Litmus’ Email Analytics测试工具检测出订阅者中最流行的邮箱App。

    基于所获得的信息,你可以决定是否渐进式增强会对你的工作有帮助。例如,如果你的受众中绝大部分使用WebKit,能够很好的支持高级功能,那么可能尝试创新性的技术,比如HTML5 视频,会是一个不错的想法!

    建立一个基本体验

    用对HTML和CSS支持有限的邮箱App——如Outlook和Gmail,在你为其他客户端优化邮件之前,为订阅者建立一个基本体验。渐进式增强不应该让其他用户产生次优体验。

    尽可能优化

    一旦你已经建立一个基本体验,就开始为其他用户优化体验。你可以使用CSS3,视频,交互,可缩放向量图形(SVG),以及web字体。记住,即使是对HTML和CSS支持的比较好的Email客户端也有它们各自的特殊之处,仍然需要测试哪些才是可行的。

    实战:邮件中的渐进增强例子

    我们先看看一些在邮件中使用渐进式增强的开创性例子。为了展示对这些邮件的优化,你必须使用一个如Chrome或Safari一样以WebKit为动力的浏览器。

    2014邮件设计大会以HTML5视频为背景的邮件

    为了播报2014邮件设计大会,我们决定认真地以HTML5视频为背景实现渐进式增强。尽管这种专项技术只能在Apple邮箱和Outlook 2011(Mac版)上工作,但这两种客户端达到接收特定邮件的用户40%左右。

    View the full email here

    对于不支持视频的电邮客户端,HTML5视频仅仅只是退化为一张静态背景图片。我们的结果却是令人惊奇的——而且回报也是惊人的!

    B&Q 交互式旋转圆盘邮件

    这一年中最酷的邮件之一是B&Q的交互式旋转圆盘邮件。对于WebKit客户端,该邮件包含了一个旋转热点,供用户点击查看不同的部分。

    View the full email here

    整个邮件中最令人印象深刻的部分,可能是它为非WebKit邮箱使用的备用方案——一个美丽的旋转木马网格布局,没有隐藏也没有复制任何内容!

    图片 1

    你可以在 Firefox 或 Internet Explorer 浏览器中打开该邮件查看备用设计。

    Litmus Builder(邮件开发工具)交互之旅邮件

    为了引入我们的新邮件代码编辑器,Litmus Builder,在这封邮件中展示了大量的可点击交互。同样,该技术也只能在Apple邮箱和Outlook 2011(Mac版)中工作,而这两个却占了我们的顾客的绝大部分。(注:邮件需要屏幕至少800像素宽才能浏览。)

    该展览仅仅只是退化为一个静态背景图片,而且会调用接口跳转到登录页面。这邮件取得了巨大的成功,其产品在最开始的几天里增加了成千上万的用户。

    View the full email here

    想尝试一下 Litmus Builder?注册后 ,你就可以开始使用HTML5和CSS3测试你的邮件!

    一个创新邮件设计框架

    CSS

    @media screen and (-webkit-min-device-pixel-ratio:0) { /* Insert styles here */ }

    1
    2
    3
    @media screen and (-webkit-min-device-pixel-ratio:0) {
      /* Insert styles here */
    }

    这个媒介查询为邮件设计师提供了一个简单的创新框架。我们可以为拥有现代邮箱客户端的那一大部分订阅者提供更好的体验。

    最好的防卫就是进攻。现在该是进攻的时候了。在邮件设计中使用这个媒介查询开始创新,推动邮件前进。

    为了订阅者去尝试。为了我们的行业,为了 对邮件的热爱。

    已经迫不及待想看看我们会共同建立出什么了。

    如果你用的是这种方法——或者开发你自己的更高级的版本——在你的邮件中,或者如果你对这种方法有任何的疑问,请在下面的评论中贴出,或者用更好的方式,去Litmus社区!

    发现你的受众 + 测试你的设计

    对于能够开始使用高级技能像HTML5和CSS3来推动邮件发展,是不是感到很激动?确保识别出订阅者们最喜爱的邮箱APP,然后测试你新设计的邮件。

    通过邮件分析,你可以了解订阅者经常在哪里打开邮件,这样你就可以集中精力在渐进式增强(以及优雅降级!)上了。

    测试设计也是开发过程中非常关键的一步。在30个以上邮箱客户端和APP之间的兼容性测试,可以确保订阅者们不论用什么邮箱打开邮件都能正常获得你的邮件。

     

    赞 收藏 1 评论

    是时候再提web标准

    2016/07/06 · 基础技术 · WEB

    原文出处: 灵感(@灵感_idea )   

    场景一:自动播放

    autoPlay 布尔属性;指定后,视频会马上自动开始播放,不会停下来等着数据载入结束。

    视频自动播放可以在页面打开且资源加载足够的情况下让视频自动播放,减少一次用户点击的交互,同时可以应用在动效背景、H5仿视频通话的功能。不过由于各种原因,自动播放无论在PC端还是移动端都有不同程度的限制。

    关于作者:fzr

    图片 2

    微博:@fzr-fzr) 个人主页 · 我的文章 · 26

    图片 3

    **背景**

    **web标准是个老生常谈的话题。引入国内的时间,粗略算下来,有十年左右了。但是由于国内前端优秀人才的缺失和相关教育跟进的缓慢,造成了很多人都没有对它引起足够的重视并运用到自己的实际项目当中,同时又花了较多精力在眼花缭乱的新技术方案和工具中,这就造成了技术断层,影响不是一个两个人,而是一大部分,如果再缺少相关的正确引导,就会保留很多不正确的编码习惯,对于个人成长和所做的项目都是不利的。**

    为什么是时候再提呢?可以先来看看下面一张具有一定代表性的图,截自我的企鹅群(152128548)

    图片 4

    1、标签仍在被滥用
    2、重视觉,轻语义和结构
    3、热衷于跟进热门新技术,不重视基础
    4、当我在跟大家说重视基础的时候,要么有人说原生js,要么有人说css原理和技巧,没人说html

    由于以上的几点,加上各种场合和会议似乎很少提及这些方面的东西,新手在被老手“牵”着走,老手的精力又不在这些比较基础的东西上。这篇文呢,就是跟大家一起回到起点,去看看怎样做才算是符合了web标准的编码。

    移动端

    问题来源

    IOS

    早期必须要有用户手势(user gesture)video标签才可以播放; 从版本10开始修改了video的规则,苹果放宽了inline和autoplay,策略如下(仅适用于Safari浏览器):

    • <video> elements will be allowed to autoplay without a user gesture if their source media contains no audio tracks.(无音频源的 video 元素 允许自动播放)
    • <video muted> elements will also be allowed to autoplay without a user gesture.(禁音的 video 元素允许自动播放)
    • If a <video> element gains an audio track or becomes un-muted without a user gesture, playback will pause.(如果 video 元素在没有用户手势下有了音频源或者变成非禁音,会暂停播放)
    • <video autoplay> elements will only begin playing when visible on-screen such as when they are scrolled into the viewport, made visible through CSS, and inserted into the DOM.(video 元素屏幕可见才开始播放)
    • <video autoplay> elements will pause if they become non-visible, such as by being scrolled out of the viewport.(video元素不可见后停止播放)

    1、门槛低、简单

    一周就可以掌握html,常用标签不多,用不到的不用管

    比如:h1~6、p、span、div、img、a、input等,我们来随意的看一张截图

    图片 5

    上面是某宝PC端的登录页,可能是由于种种原因(不详),只用了少量的标签,所以,并不说它是不好的或者是错的,但它是其他很多人的写照。如果我说html标签有100多个,你会是什么反应?

    1、不知道,没想到有这么多
    2、知道,但认为很多都用不上

    你会是哪种?

    如何在合适的时候,合适的地方,使用正确的标签,这是web标准的基本要求。后面细说。

    CSS很简单,常用属性也就那么多

    宽、高、边框、背景、定位、浮动、边距,如果你掌握了这么多,那么就能够应对很多页面布局的情况了。如果你因此就认为css很简单,那么就等着它来“惩罚”你吧。

    不好的方面:各种兼容问题,各种奇葩布局要求,各种不可预知的bug

    好的方面:诸多奇妙的技巧和css3新属性,能够帮助我们做出充满美感又神奇的效果

    如果你依然觉得CSS太简单,那么请看一下这里https://drafts.csswg.org/indexes/,要坚强~

    安卓

    __早期__同样需要用户手势才可以播放; 安卓的 chrome 53 后放宽了自动播放策略,策略不同于IOS的Safari,需要同时对 video 设置 autoplay 和 muted(是否禁音),才允许自动播放; __安卓的 FireFox 和 UC 浏览器__支持任何情况下的自动播放; 安卓的其他浏览器暂时不清楚情况;

    2、只需要做“对”,不需要做好

    很多时候,即使写错了浏览器会包容它,当我们的代码是不规范的,甚至有时候是错的,但是浏览器仍然将它“正常”显示出来,这个时候,我们意识不到自己的错误。认为看起来没问题就没问题,这是很危险的。

    标签不用在意,交给CSS去处理就好,理论上,我们可以通过一定的CSS规则,任意的改变一个元素的表现,这就造成了对html标签的不重视,因为我们总能让它们看起来没有任何问题。

    PC端

    早期是__支持自动播放,但__近来 Safari、Chrome 陆续修改了自动播放的策略……

    3、热衷于“向前看”

    学习新技术,丰富自己的技能树——html5、canvas、svg、react、ES6等。

    解决“难题”——觉得一般的工作没什么挑战了,所以不屑于去深挖自己已经会了东西。

    做出炫酷的效果——纯CSS图标、动画,3D动画,canvas动画等。

    跟风式学习——大家都在谈,业界都在捧,看起来很好的东西,就开始躁动不安,跃跃欲试,其实有句话叫做:“基础不牢,地动山摇”,兴致冲冲的去学习新的东西的时候,往往会发现,没有足够的基础,是很难前行的。

    上面说的这些是错的么?当然都对,特别是在技术发展更新迭代速度快的互联网领域,想会得更多让自己更强,同时会的更多在实际应用中可选择的方案也更多,兴趣驱动去学习,这是好事,我自己也是这样的,但我们需要注意的是,学习不是一条直线,不能沿着一条线一直往前冲,除了长度,还有深度,需要我们不断的从各个方面去打磨和填充才能日臻完善。

    Safari 浏览器

    __Safari 10 后__带音频的视频和音频默认禁止自动播放,更多信息可以参考这篇文章;

    Chrome(旧版本) 下自动播放:

    图片 6

    Safari (10后)不自动播放:

    图片 7

    文档结构和意义为先

    我们都知道,实现一种效果可以有多种方式,那么哪种才是最优的?来看例子

    Chrome 浏览器

    禁音的视频依旧可以播放,�带声音的视频会根据__媒体参与指数__来决定能否自动播放,那什么是媒体参与指数?官方给了解释和相关的维度:

    MEI 是一个评估用户对于当前站点的媒体参与程度的指数,它取决于下面几个维度:

    • 用户在媒体上停留时间超过了 7秒以上
    • 音频必须是展示出来,并且没有静音
    • 与 video 之间有过交互
    • 媒体的尺寸不小于 200×140.

    看完后开发者的心里是这样的:

    图片 8

    图片 9

    列表

    什么特点呢?最明显的就是有很多项,项和项之间相互独立,竖着排列,像这样

    我是列表
    我是列表
    我是列表

    它可以被怎样写呢?

    1、

    XHTML

    我是列表<br> 我是列表<br> 我是列表<br>

    1
    2
    3
    我是列表<br>
    我是列表<br>
    我是列表<br>

    2、

    XHTML

    <li>我是列表</li> <li>我是列表</li> <li>我是列表</li>

    1
    2
    3
    <li>我是列表</li>
    <li>我是列表</li>
    <li>我是列表</li>

    3、

    XHTML

    <ul> <li>我是列表</li> <li>我是列表</li> <li>我是列表</li> </ul>

    1
    2
    3
    4
    5
    <ul>
        <li>我是列表</li>
        <li>我是列表</li>
        <li>我是列表</li>
    </ul>

    上面三种是比较直接想到的对的写法,当然也可以用ol,算同一种方法。它们所能实现的效果是类似的,往往我们会从表现的角度考虑说第一种不够灵活,无法控制样式,第二种方法浏览器也不会不搭理你,它会把li解析成块级元素,让它们单独排列,但它失去了告诉浏览器“我是个列表”的标志,也就是外层容器(ul/ol),最好的写法肯定是第三种,它不仅看上去是对的,还告诉浏览器这是个列表,还有列表所应有的特点,比如“缩进”和“着重号”,当然,最大的益处仍然是它是有意义的,也是为什么这里没有提div和p等元素的原因。

    检测能否自动播放?

    好在无论是 Safari 还是 Chrome,在限制了自动播放的同时,提供了检测视频是否能自动播放的机制,以便于开发者在发现无法自动播放时有备选方案:

    var promise = document.querySelector('video').play(); if (promise !== undefined) { promise.catch(error => { // Auto-play was prevented // Show a UI element to let the user manually start playback }).then(() => { // Auto-play started }); }

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    var promise = document.querySelector('video').play();
     
    if (promise !== undefined) {
        promise.catch(error => {
            // Auto-play was prevented
            // Show a UI element to let the user manually start playback
        }).then(() => {
            // Auto-play started
        });
    }

    标题

    作为标题,特点也简单,比页面上其他的文本更大、更粗。
    我们可以这样写:

    1、

    XHTML

    <span class="head">我是标题</span>

    1
    <span class="head">我是标题</span>

    2、

    XHTML

    <p><b>我是标题</b></p>

    1
    <p><b>我是标题</b></p>

    3、

    XHTML

    <h1>我是标题</h1>

    1
    <h1>我是标题</h1>

    不看代码的情况下,三者可以一模一样,但看了代码的话,大家应该都会第三种写法是最好的,第三种写法的好处有哪些?

    1、本身是块级元素
    2、是独特的,不像p或者span等元素会用到页面当中的很多地方
    3、更加重要的是,在不加任何css规则的情况下,标题元素仍然明显是个标题,页面的无样式视图将显示其预期的文档结构,正确的标题元素传递了“意义”而不只是表现指令
    4、屏幕阅读器、手机和其他浏览器也将知道如何处理标题元素
    5、搜索引擎友好,除了title和meta,标题是最可能存在关键字的地方,利用好它,会更加方便用户找到你的页面

    但是它有没有问题困扰着我们呢,答案是有,h1和h2这些标题的默认样式被认为过于粗大,这会让有些人倾向于使用更高级别的标题元素,其实这个大家都知道,不是大问题,可以用css来控制,前提是:先结构,后表现。至于选择使用h几,也不是没有讲究的,它们既然是分了级别,那自然是有一定意义所在,一般来说,h1是个重要的标识,页面当中有一个就好,然后,不要出现类似h2包裹h1的情况。

    本文由奥门新浦京网址发布于Wed前段,转载请注明出处:在Email中防御性地使用HTML5和CSS3的指南,是时候再

    关键词: