英语原文：
节选自
Ben Frain. Responsive Web Design with HTML5 and CSS3[M]. Packt Publishing，2015.
Get designs in the browser as soon as possible
The more responsive design work I have done,the more important I have found it to get designs up and running in a browser environment as soon as possible.If you are a designer as well as a developer,that simplifies matters.As soon as you have enough of a feel,visually,for what you need,you can get it prototyped in a browser and develop the idea further in a browser environment.This approach car be embraced more fully by letting go of high-fidelity full-page mock-ups altogether. Instead,consider things like Style Tiles-positioned between a moodboard and full mockup.The introduction to Style Tiles (http://styletil.es/)describes them as.
“Style Tiles are a design deliverable consisting of fonts,colors and interface elements that communicate the essence of a visual brand for the web.”
I#39;ve found graphical deliverables of this nature can be useful for presenting and communicating look and feel between stakeholders without resorting to the endless rounds of composites.
Let the design dictate the breakpoints
I#39;d like to reiterate a point made in previous chapters.Let the design define where breakpoints should be set.With a design in the browser,it makes this process far easier.You should always start amending the design from the smallest screen sizes upwards,so as the viewport size increases,you can see how far your design works before you need to introduce a breakpoint.
You`ll also find that coding the design will be easier this way.Write the CSS for the smallest viewport first and then add any changes to different elements within media queries afterwards.
View and use the design on real devices
If you can,start to build up a #39;device lab of older devices (phones/tablets) to view your work on.Having a number of varied devices is hugely beneficial.Not only does it let you feel how a design actually works across different devices,it also exposes layout/rendering peculiarities earlier in the process.After all,no one enjoys believing they have finished on a project to be told it doesn#39;t work properly in a certain environment.Test early,test often!It need not cost the earth.For example, you can pick up older phone and tablet models on eBay,or buy them from friends/relatives as they upgrade.
Embracing progressive enhancement
In previous chapters,we have considered briefly the notion of progressive enhancement.It#39;s an approach to development that I have found so useful in practice I think it bears repeating.The fundamental idea with progressive enhancement is that you begin all your front-end code(HTML,CSS,JavaScript)with the lowest common denominator in mind.Then,you progressively enhance the code for more capable devices and browsers.That may seem simplistic and it is,but if you are used to working the other way around;designing the optimum experience and then figuring out a way of making that thing work on lesser devices/browsers,you#39;ll find progressive enhancement an easier approach.
lmagine a low powered,poorly featured device.No JavaScript,no Flexbox support,no CSS3/CSS4 support.In that instance what can you do to provide a usable experience?
Most importantly,you should write meaningful HTML5 markup that accurately describes the content.This is an easier task if you#39;re building text and content-based websites.In that instance,concentrate on using elements such as main,header, footer,article,section,and aside correctly.Not only will it help you discerm different sections of your code,it will also provide greater accessibility for your users at no extra cost.
If you#39;re building something like a web-based application or visual UI components (carousels,tabs,accordions,and the like)you#39;ll need to think about how to distil the visual pattern down into accessible markup.
The reason good markup is so crucial is that it provides a base level experience for all users.The more you can achieve with HTML,the less you have to do in CSS and JavaScript to support older browsers.And nobody,and I really mean nobody,likes writing the code to support older browsers.
It#39;s by no means a simple feat to start thinking in this manner.It is however,an approach that is likely to serve you well in your quest to do as little as possible to support ailing browsers.
Now,about those browsers.
Defining a browser support matrix
Knowing the browsers and devices a web project needs to support up front can be crucial to developing a successful responsive web design.We#39;ve already considered why progressive enhancement is so useful in this respect;if done correctly,it means that the vast majority of your site will be functional on even the oldest browsers.
However,there may also be times when you need to start your experience with higher set of prerequisites.Perhaps you are working on a project where JavaScript is essential,not an uncommon scenario.In that instance,you can still progressively enhance.Instead,you are merely enhancing from a different start point.
Whatever your starting point,the key thing is establishing what it is.Then,and only then,can you define and agree upon what visual and functional experiences the different browsers and devices that you intend to support will get.
Functional parity,not aesthetic parity
It#39;s both unrealistic and undesirable to try and get any website looking and working the same in every browser.Besides quirks specific to certain browsers,there are essential functional considerations.For example,we have to consider things like touch targets for buttons and links on touch screens that aren#39;t relevant on mouse-based devices.
Therefore,some part of your role as a responsive web developer is educating whoever you are answerable to (boss,client,shareholders)that #39;supporting older browsers#39; does
全文共18485字，剩余内容已隐藏，支付完成后下载完整资料
中文翻译：
尽可能快的完成在浏览器中的设计
在我完成越来越多的响应式设计的同时，我越来越清晰的感觉到使其能尽快在浏览器中运行与设计的重要性。如果你是一名设计师以以及开发者，这样事情就好办多了。只要你有足够的感觉，在视觉上，你需要什么，你就可以在一个浏览器描绘得到它的原型，在浏览器环境中进一步发展的你的想法。完全放开高保真的全页面模拟，可以更全面地接受这种方法。相反，考虑样式框架定位在moodboard和模型之间，样式框架介绍（HTTP：/ / styletil.ES /）描述了他们。
“样式框架”是一种设计交付物，由字体、颜色和界面元素组成，它们为网络传达视觉品牌的精髓。
在此之中我发现了，使用样式框架有利于展示和交流，而不必求助于无穷无尽的合成与混合当中。
让设计决定断点
我想重申前文的观点，让设计定义断点应该受到重视。在浏览器的设计中，它会使这个过程变得更加容易。你应该从设计最小的屏幕尺寸上开始进行修改，这样的话随着视口大小的增加，你便能在需要加入断点之前了解到了你的设计工作能走到哪一步。
您也会发现，这样设计代码更容易。首先为最小的视口编写CSS，然后在审查元素中中添加各种各样的更改到不同的元素中。
在真实设备上查看和使用设计
如果条件所允许，你需要去特意建立一个“设备实验室”也就是说使用旧设备（手机/平板电脑）来查看您的工作。具有许多不同规格的设备是非常有利于前端设计的。它不仅让你感觉到在实际设备上你的设计是如何呈现的，这也能在较前期的工作过程中过程暴露出布局和渲染的特点与不足。毕竟，没有人会享受他们的设计项目在特定环境中不能生效的苦涩感，因此在试验初期的时候，便需要经常的测试。例如，你可以在易趣网上购置老型号的的手机和平板电脑作为试验模型，或者在亲朋好友升级设备时从他们的手里购买。
拥有迭代开发思想
在前面的章节中，我们已经提出过了迭代开发的概念。它的发展与使用在我的概念之中是相当的实用的也经得起反复推敲。迭代开发的基本思想是，你首先应该以你心目中最小最弱的设备部分开始进行你的设计（HTML、CSS、JavaScript）。然后，你便可以逐渐修改代码去适应的更为强大的设备和浏览器。这看起来很简单，但如果你习惯于用另一种方式工作，为了能感受到设计的最佳的体验，尝试首先从较小较弱的设备/浏览器上开展设计工作，你会发现迭代开发是一种更简单的方法。
想象一下，在一个低功率、低效能的装置上，没有JavaScript，也没有flexbox支持，更没有CSS3 / CSS4支持。在这种情况下你能做些什么来提供一个可用的经验吗？
最重要的是，你应该写有意义的HTML5标记来准确描述的代码内容。这是一个容易完成的任务如果你是基于网站来建立文件与内容的。在这种情况下，专注于使用诸如正文、页眉、页脚、文章、章节和旁白等元素，不仅可以帮助您辨别代码的不同部分，还可以为用户提供更大的可访问性，而且不需要额外的成本。
如果你建立的东西是例如一个基于Web的应用程序或视觉的UI组件（旋转木马，标签，手风琴，等等），你便需要思考做到提供有用的标记来便于观察。
好的标记之所以如此重要，是因为它为所有用户提供了基本的体验。
这并不是一个简单的壮举，以这种方式开始思考，但是，这种方法能够为你尽可能地减少浏览器不支持的状况，也便于维护。
接下来我们便说一下关于浏览器的事。
定义浏览器支持矩阵
了解Web项目需要支持的浏览器和设备对于开发一个成功的响应式Web设计至关重要，我们已经提到过了为什么迭代开发在这方面如此有用；如果做得正确，这意味着即使在最老的浏览器中，绝大多数网页站点都能正常运行。
然而，也可能有些时候你需要更高的先决条件来开始使用体验，也许您正在开发一个JavaScript作为部件是必不可少的项目，却遇到一个不寻常的场景。在这种情况下，你仍然可以应用迭代开发，相对的，你只是从不同的起点开始迭代。
不管你的出发点是什么，关键是确定它是什么，然后只有这样，你才能定义和允许你打算支持的各种浏览器和设备拥有相应的视觉和功能体验。
功能对等，而非审美对等
试图令在任何浏览器中找到任何一个网站，都能在同一个浏览器上工作是不现实的，也是不可取的。除了特定浏览器的额外规定之外，还有一些重要的功能考虑。例如，我们必须考虑到触摸按钮以及一些触摸屏上才能使用得连接与鼠标设备是不可能兼容的。
因此，你作为一个敏感又专业的Web开发人员，不管你的身份如何，必须向需要教育的部分（老板、客户、股东）提出，支持“旧的浏览器”并不意味着看起来都一样，在“旧的浏览器”这部分我倾向于运行，也就是支持矩阵中所有的浏览器都将会得到一样的功能的体验，而不是视觉校验。这意味着，如果你有一个交易台，所有的用户都能通过检验和购买商品，但可能更高级与华丽的视觉体验将会提供给使用更现代的浏览器的用户，但核心的功能都是可以实现的。
选择浏览器支持
通常，当我们谈到需要支持与兼容哪种浏览器时，我们也就是在在谈论我们需要回头看多远，这里是几个可能的考虑，视乎与情况考虑。
如果它是一个现有的网站，看看游客统计（谷歌分析或类似）。有了一些数据，你可能会做一些粗略的计算与推测。例如：如果支持浏览器X的成本低于支持浏览器X所产生的值，那么就支持浏览器X！
同时，再考虑到统计使用人数小于10%的用户的浏览器时，必须进一步的去进行趋势评估。在过去的3、6和12个月的时间里有何改变？如果现在是6%，并且在过去的12个月里这个值已经减半，那么你便有了一个更有说服力的理由来考虑将这一种浏览器排除在更新之外。
如果它是一个新的项目且统计数据暂时不可用，我通常会选择一个“前两rsquo;策略来进行评估，就是目前的版本加上每个浏览器的前两个版本。例如，如果Internet Explorer 12是当前版本，看看那版加IE10和IE11提供增强功能（以前的二）。这种选择在热门浏览器上更容易实现，这会使浏览器在一个快速的周期内不断地进行更新（例如Firefox和Chrome）。
分层的用户体验
在这一点上，我们假设股东已经明白。现在加入你有一套明确的浏览器，你想添加增强的体验。我们现在就可以开始进行分层的体验的实践。我喜欢让事情变得简单，所以在可能的情况下我选择定义一个简单的普通版和一个功能强大的强化版。
普通版的网站是功能可行的最小化版本和强化版则是功能最全、最美观的版本。你可能需要更细致的进行分层，更多不同的强度，例如，浏览器体验分叉；例如，对flexbox或translatead支持。不管如何，明确规定，确保你定义的层次内应该展现什么，然后你便可以去那些层次进行编码。
将CSS断点链接到JavaScript
通常，基于Web的任何种类的交互都会涉及到JavaScript，当你开发一个响应式的项目时，你很可能会想在不同的视口大小上做不同的事情，那这样所涉及的不仅仅是CSS，还包括JavaScript。
让我们假设我们想调用一个JavaScript函数来让我们达到一定的CSS改变（记住断点是用来定义一个响应式设计应该改变点的术语）。让我们假设47.5rem断点（与l6px根字号等同于760px）我们只想在这样的规格之下运行功能。最明显的解决方法就是测量屏幕宽度和调用函数如果值匹配的AME值来决定你的CSS断点。
JavaScript总是将宽度的值作为像素而不是REM值返回，所以这是第一个复杂的问题，但是，即使我们将CSS中的断点设置为像素值，当我们改变窗口大小时，仍然会有两个地方需要去更新和改变这些值。
避免使用CSS框架
免费框架的存在，其意在帮助用户快速建立原型和进行响应式网站建设。两个最常见的例子是Bootstrap（http://getbootatrap.com/）和Foundation(http:// foundation.zurb.com/)。这些都是一些伟大的项目，尤其是在学习如何建立响应式网站的过程中，但我认为应该避免向项目中使用他们。
我已经和很多开发人员谈过，他们用这些框架中的其中一个来启动他们自己的项目，然后修改它们以满足他们的需求。这种方法对于快速原型开发来说非常有利（例如，向客户解释举例），但我觉得对于你要投入使用的项目来说这是错误的做法。
首先，从技术的角度来看，很可能从一个框架开始会导致你的项目拥有比实际需要更多的代码。其次，从美学的角度来看，由于这些框架的流行，你的项目很可能会和其他无数的项目非常相似。
最后，如果你只在你的项目中复制和粘贴代码，并把它调整到你的需要，你就不太可能完全理解在“在底层”下发生的事情。只有定义和解决你的问题，你才能掌握你放置在项目中的代码。
当链接成为按钮时
我不会说谎，对于这个难题，我通常会选择后者。然后，我尝试通过选择下一个最佳元素并在可能的情况下更改ARIA的角色来弥补我将使用错误元素的事实。在这种情况下，虽然我们的菜单按钮当然不是链接（毕竟，它不会把用户带到任何地方），但它是我将使用的一个标签。我认为它是下一个最好的东西 - 比任何其他元素更像一个按钮。通过使用链接，我们可以达到理想的审美观感。
当然，对于这个过于简单的例子，我们可以将显示从flex改为block，然后使用填充，直到达到我们所需的审美效果。或者，我们可以保留按钮元素并嵌套另一个语义上无意义的元素（span）并将其设置为Flex容器。使用哪种形式完全取决于你的喜好。
最重要的是，我们应该尽可能合理地标记文档。极端一点的，有开发人员只使用div和span进行标记，以确保浏览器不存在不需要的样式。降低了元素标识的开销，但反过来也就没有了“自由”的可访问性。另一个极端是标记纯粹主义者，他们只会在他们认为是正确的元素的内容中标记内容，而不管这些最终会形成什么样的视觉效果。在两者之中取其平衡，我觉得这是最明智和最有成效的做法。
通过视角隐藏，显示和加载内容
关于响应式网页设计的常见格言之一是：如果在较小的视角屏幕上没有东西，则不应该在较大的视角中出现。
这意味着用户应该能够在每个视角尺寸上完成所有相同的目标（购买产品，阅读文章，完成界面任务）。这是常识，毕竟作为用户自己，我们在使用一个网站却不能完成相应的功能时都会感到挫折感，仅仅是因为我们正在使用一个较小的屏幕。
这也意味着，由于屏幕空间较为丰富，我们不应该为了填补空间而添加额外的东西（例如小部件，广告或链接）。如果用户可以在小屏幕尺寸的情况下没有这些额外的东西，他们会在更大的视图中管理得很好。以更大的视口尺寸显示额外的内容还意味着内容在较小的视口处存在并且仅仅隐藏（在CSS中通常使用display：none达到效果）或者它被加载到特定的视口大小（在JavaScript的帮助下）。内容被加载但不可见，或者可以看到，但可能是多余的。
从广义上说，我认为上述格言是合理的建议。如果没有其他任何内容，它会使设计人员和开发人员更全面地考虑他们想要在在屏幕上显示的内容。但是，与网页设计一样，总会有例外。
尽可能地，我抵制加载新的标记为不同的视角，但偶尔也是必要的。我曾经完成了复杂的用户界面，这些界面在更宽大的视角上确实需要不同的标记和设计。
在这种情况下，JavaScript被用来替换另一个标记区域。这不是最好的做法，但它是最实用的。如果由于某种原因JavaScript失败了，用户至少可以获得最小的视角屏幕布局。他们可以完成所有应该有的功能，屏幕的布局对于功能的实现来说是次要的。
当你编写越来越复杂的响应式网页设计的时候，这些都是你可能面临的选择，你需要根据自己的判断来确定在任何可能出现的情况下最好的选择是什么。但是，如果您将标记的可见性切换为display:none来实现您的目标，那么这不是一个太大的问题。
让CSS做（视觉）繁重的工作
事实上，JavaScript为网页提供了一定程度的互动性，而单靠CSS无法实现这一点。然而，在可能的情况下，当涉及到视觉效果时，我们仍然应该用CSS来完成所有繁重的工作。实际上，这意味不仅仅是单独使用JavaScript（我在看你JQuery显示和隐藏方法）来实现动画效果菜单进出。相反，使用JavaScript在标记的相关部分执行简单的类更改，然后让该类更改触发菜单在CSS中显示/动画。
为了获得最佳性能，当在HTML中切换类时，请确保将类尽可能地添加到要实现的项目中。例如，如果您希望弹出框显示在另一个元素上，请将该类添加到最接近的共享父元素。这将确保在获得最佳性能的同时，只有页面的特定部分变得“脏”，并且浏览器不应该重新加载页面的大部分区域。
性能
考虑到响应式Web设计的性能与美观一样重要。但是，性能会带来一些不确定的目标。例如，浏览器更新和改进了处理资源的方式，发现了可取代现有“最佳实践和技术”的新技术最终获得足够的浏览器支持，使其可以广泛应用，列表如下。
然而，有一些基本的实现细节非常稳固（当然，直到HTTP2是常见的地方，其中更多的是短期的）。这些是：
1.最小化需求资源数量（例如，如果能练成一整个就不要连续加载15个Javascript文件）。
2.尽量减少页面大小（如果条件允许就将一部分的图片压缩一部分）。
3.推迟非必要的资源使用（如果你可以在页面已经呈现出来的情况下推迟加载CSS和JavaScript，它可以大大缩短页面加载时间）。
4.确保页面尽快可用（通常就是完成上述的步骤）。
有许多优秀的工具可用于衡量和优化性能。我个人最喜欢的是http://webpagetest.org/。最简单的方法是，选择一个URL并点击START TEST。它会向您显示完
全文共6058字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12580]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
