diff --git a/files/zh-cn/_redirects.txt b/files/zh-cn/_redirects.txt index 0427a76bb12ba5..9c07c786d0d84d 100644 --- a/files/zh-cn/_redirects.txt +++ b/files/zh-cn/_redirects.txt @@ -2663,6 +2663,7 @@ /zh-CN/docs/Web/Progressive_web_apps/Offline_Service_workers /zh-CN/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Offline_Service_workers /zh-CN/docs/Web/Progressive_web_apps/Re-engageable_Notifications_Push /zh-CN/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Re-engageable_Notifications_Push /zh-CN/docs/Web/Progressive_web_apps/Responsive/Media_types /zh-CN/docs/Web/CSS/CSS_media_queries/Using_media_queries +/zh-CN/docs/Web/Progressive_web_apps/Responsive/responsive_design_building_blocks /zh-CN/docs/Learn/CSS/CSS_layout/Responsive_Design /zh-CN/docs/Web/Progressive_web_apps/加载 /zh-CN/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Loading /zh-CN/docs/Web/Progressive_web_apps/添加到主屏幕 /zh-CN/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable /zh-CN/docs/Web/SVG/Attribute/文本锚点 /zh-CN/docs/Web/SVG/Attribute/text-anchor diff --git a/files/zh-cn/_wikihistory.json b/files/zh-cn/_wikihistory.json index 677cd5c0d64656..67e07b90457944 100644 --- a/files/zh-cn/_wikihistory.json +++ b/files/zh-cn/_wikihistory.json @@ -32180,10 +32180,6 @@ "modified": "2019-11-13T02:27:54.714Z", "contributors": ["JC-Ge"] }, - "Web/Progressive_web_apps/Responsive/responsive_design_building_blocks": { - "modified": "2020-11-17T04:04:41.165Z", - "contributors": ["DingGuangbo"] - }, "Web/Progressive_web_apps/Tutorials/js13kGames/App_structure": { "modified": "2020-05-31T18:38:01.454Z", "contributors": [ diff --git a/files/zh-cn/learn/accessibility/mobile/index.md b/files/zh-cn/learn/accessibility/mobile/index.md index a0210a5f14c73a..b3166c249e8fbc 100644 --- a/files/zh-cn/learn/accessibility/mobile/index.md +++ b/files/zh-cn/learn/accessibility/mobile/index.md @@ -10,7 +10,7 @@ slug: Learn/Accessibility/Mobile - +
前置条件：前提： 基本的计算机素养，对 Javascript,html,css 有基本的认识，对 无障碍 > TalkBack，打开开关即可打开 TalkBack。按照屏幕提示操作即可。 -**注意**: 旧版本的 TalkBack 的打开方式有[一点不同](https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback)。 - 当 TalkBack 打开时，你的 android 设备的基本操作将有一点点不同。举个例子： 1. 点击一个应用将会选择它，同时，你的设备将会告诉你这个 APP 是什么。 @@ -66,9 +64,9 @@ TalkBack 是运行在 Android 系统上的。 2. 导航到 无障碍 > TalkBack 3. 导航到滑动的开关，并激活它将其关闭。 -**注意**: 你可以通过向左上方滑动返回桌面，如果你有多个桌面，你可以通过两个手指在屏幕上左右滑动来切换桌面。 +> **备注：** 你可以通过向左上方滑动返回桌面，如果你有多个桌面，你可以通过两个手指在屏幕上左右滑动来切换桌面。 -**注意**: 关于“TalkBack”的收拾完整列表，查看[使用 TalkBack 手势](https://support.google.com/accessibility/android/answer/6151827)。 +关于“TalkBack”手势的完整列表，查看[使用 TalkBack 手势](https://support.google.com/accessibility/android/answer/6151827)。 #### 解锁手机 @@ -89,7 +87,7 @@ TalkBack 允许你使用全局和本地菜单，无论你已经导航到哪个 3. 向左右滑动可以选择不同的菜单。 4. 一旦你选择了你想要的选项，双击它可以直接选择。 -想要查看全局和本地上下文菜单的详细选项，请查看[使用全局和本地上下文菜单](https://support.google.com/accessibility/android/answer/6007066) +想要查看全局和本地上下文菜单的详细选项，请查看[使用全局和本地上下文菜单](https://support.google.com/accessibility/android/answer/6007066)。 #### 浏览网页 @@ -111,7 +109,7 @@ TalkBack 允许你使用全局和本地菜单，无论你已经导航到哪个 7. 双击选择它。现在你就可以通过左右滑动在标题和 ARIA 标识之间切换 8. 向右向上滑动之后，进去本地上下文菜单，选择“默认”，就可以返回默认模式 -**注意**: 查看[TalkBack 入门](https://support.google.com/accessibility/android/answer/6283677?hl=en&ref_topic=3529932)获取更完整的文档。 +> **备注：** 查看 [TalkBack 入门](https://support.google.com/accessibility/android/answer/6283677?ref_topic=3529932)获取更完整的文档。 ### iOS VoiceOver @@ -135,7 +133,7 @@ TalkBack 允许你使用全局和本地菜单，无论你已经导航到哪个 #### 使用转子 -当 VoiceOver 打开时，您可以使用一种名为“转子”的导航功能，该功能可让您快速从多种常用选项中进行选择。要使用它： +当 VoiceOver 打开时，你可以使用一种名为“转子”的导航功能，该功能可让你快速从多种常用选项中进行选择。要使用它： 1. 像转动拨号盘一样在屏幕上扭动两根手指。当你扭动更多的时候，每个选项都会被朗读。你可以来回循环选项。 2. 一旦你找到你想要的选项： @@ -170,17 +168,17 @@ TalkBack 允许你使用全局和本地菜单，无论你已经导航到哪个 7. 选择标题，现在你可以通过上下滑动在页面的不同标题中切换 -**注意**: 有关 iOS 上可用的 VoiceOver 手势以及有关辅助功能的其他提示的更完整资料可以查看[在你的设备上用 VoiceOver 测试辅助功能](https://developer.apple.com/library/content/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html#//apple_ref/doc/uid/TP40012619-CH3) +> **备注：** 有关 iOS 上可用的 VoiceOver 手势以及有关辅助功能的其他提示的更完整资料可以查看[在你的设备上用 VoiceOver 测试辅助功能](https://developer.apple.com/library/archive/technotes/TestingAccessibilityOfiOSApps/TestAccessibilityonYourDevicewithVoiceOver/TestAccessibilityonYourDevicewithVoiceOver.html)。 ## 控制机制 在我们的 CSS 和 JavaScript 无障碍文章中，我们研究了特定于某种控制机制的事件的概念（请参阅[鼠标特定的事件](/zh-CN/docs/Learn/Accessibility/CSS_and_JavaScript#mouse-specific_events)）。回顾一下，因为其他控制机制不能激活相关的功能，将会导致辅助功能的问题。 -举例来说，[点击事件](/zh-CN/docs/Web/API/GlobalEventHandlers/onclick)在无障碍方面是好的 - 通过点击处理器设置的元素，选中它并按下回车或返回，或者在触摸屏设备上点击它，可以调用关联的事件处理程序。试试我们的例子[simple-button-example.html](https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-button-example.html)([查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/simple-button-example.html)) 来看看我们是什么意思。 +举例来说，[点击](/zh-CN/docs/Web/API/Element/click_event)事件在无障碍方面是好的——通过点击处理器设置的元素，选中它并按下回车或返回，或者在触摸屏设备上点击它，可以调用关联的事件处理程序。试试我们的例子 [simple-button-example.html](https://github.com/mdn/learning-area/blob/main/accessibility/mobile/simple-button-example.html)（[查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/simple-button-example.html)）来看看我们是什么意思。 -另一方面，像[mousedown](/zh-CN/docs/Web/API/GlobalEventHandlers/onmousedown)和[mouseup](/zh-CN/docs/Web/API/GlobalEventHandlers/onmouseup)这些特定的鼠标事件会产生一些问题 - 他们的事件处理程序不能使用除了鼠标意外的设备操作。 +另一方面，像 [mousedown](/zh-CN/docs/Web/API/Element/mousedown_event) 和 [mouseup](/zh-CN/docs/Web/API/Element/mouseup_event) 这些特定的鼠标事件会产生一些问题——它们的事件处理器不能使用除了鼠标意外的设备操作。 -如果你尝试通过键盘或触摸来试试我们的[simple-box-drag.html](https://github.com/mdn/learning-area/blob/master/accessibility/mobile/simple-box-drag.html)([查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/simple-box-drag.html))，你将发现问题。它发生的原因是我们用了下面的代码： +如果你尝试通过键盘或触摸来试试我们的 [simple-box-drag.html](https://github.com/mdn/learning-area/blob/main/accessibility/mobile/simple-box-drag.html)（[查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/simple-box-drag.html)），你将发现问题。它发生的原因是我们用了下面的代码： ```js div.onmousedown = function() { @@ -205,21 +203,21 @@ div.ontouchstart = function(e) { panel.ontouchend = stopMove; ``` -我们提供了一个简单的例子来展示如何使用鼠标和触摸事件 - [multi-control-box-drag.html](https://github.com/mdn/learning-area/blob/master/accessibility/mobile/multi-control-box-drag.html) ([查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/multi-control-box-drag.html)) +我们提供了一个简单的例子来展示如何使用鼠标和触摸事件——[multi-control-box-drag.html](https://github.com/mdn/learning-area/blob/main/accessibility/mobile/multi-control-box-drag.html)（[查看在线例子](https://mdn.github.io/learning-area/accessibility/mobile/multi-control-box-drag.html)） -**注意**: 你可以看到一个功能完善的例子，展示如何在实现[游戏控制机制](/zh-CN/docs/Games/Techniques/Control_mechanisms)中实现不同的控制机制。 +> **备注：** 你可以看到一个功能完善的例子，展示如何在实现[游戏控制机制](/zh-CN/docs/Games/Techniques/Control_mechanisms)中实现不同的控制机制。 ## 响应式设计 -[响应式设计](/zh-CN/docs/Web/Progressive_web_apps/Responsive/responsive_design_building_blocks)是根据屏幕大小和分辨率等因素动态更改您的应用程序的布局和其他功能的做法，因此对于不同设备类型的用户来说，它们是可用和可访问的。 +[响应式设计](/zh-CN/docs/Learn/CSS/CSS_layout/Responsive_Design)是根据屏幕大小和分辨率等因素动态更改你的应用程序的布局和其他功能的做法，因此对于不同设备类型的用户来说，它们是可用和可访问的。 特别是，移动端设备需要解决的最常见的问题是： - 移动端设备布局的适用性。例如，在窄屏上多列布局不能很好的工作，需要增加文字大小以提高可读性。这些问题可以通过[媒体查询](/zh-CN/docs/Web/CSS/CSS_media_queries)、[viewport](/zh-CN/docs/Web/HTML/Viewport_meta_tag)、[弹性布局](/zh-CN/docs/Learn/CSS/CSS_layout/Flexbox)来解决。 -- 节省下载的图片大小。一般来说，小屏幕设备不需要与桌面设备一样大的图像，而且它们将更可能在慢速网络连接上。因此，适当地缩小屏幕设备以缩小图像是明智的。您可以使用[响应式图像技术](/zh-CN/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images)处理此问题。 -- 考虑高分辨率。许多移动设备具有高分辨率屏幕，因此需要更高分辨率的图像，使得显示器可以继续看起来清晰和锐利。再次，您可以使用响应式图像技术来适当地提供图像。此外，使用 SVG 矢量图像格式可以满足许多图像要求，这些格式在目前的浏览器中得到了很好的支持。SVG 有一个小文件大小，并将保持清晰的大小显示在（请参阅[向网络添加矢量图形](/zh-CN/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web)一些更多的细节）。 +- 节省下载的图片大小。一般来说，小屏幕设备不需要与桌面设备一样大的图像，而且它们将更可能在慢速网络连接上。因此，适当地缩小屏幕设备以缩小图像是明智的。你可以使用[响应式图像技术](/zh-CN/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images)处理此问题。 +- 考虑高分辨率。许多移动设备具有高分辨率屏幕，因此需要更高分辨率的图像，使得显示器可以继续看起来清晰和锐利。再次，你可以使用响应式图像技术来适当地提供图像。此外，使用 SVG 矢量图像格式可以满足许多图像要求，这些格式在目前的浏览器中得到了很好的支持。SVG 有一个小文件大小，并将保持清晰的大小显示在（请参阅[向网络添加矢量图形](/zh-CN/docs/Learn/HTML/Multimedia_and_embedding/Adding_vector_graphics_to_the_Web)一些更多的细节）。 -**注意**: 我们不会在这里对响应式设计进行完整的讨论，因为他们在 MDN 其他地方都有涉及（参考上面的链接）。 +> **备注：** 我们不会在这里对响应式设计进行完整的讨论，因为他们在 MDN 其他地方都有涉及（参考上面的链接）。 ### 具体的需要注意的点 @@ -227,7 +225,7 @@ panel.ontouchend = stopMove; #### 不能缩放 -我们可以利用[viewport](/zh-CN/docs/Web/HTML/Viewport_meta_tag)来禁止用户缩放，在你的[\](/zh-CN/docs/Web/HTML/Element/head)中加入下列代码即可： +我们可以利用 [viewport](/zh-CN/docs/Web/HTML/Viewport_meta_tag)来禁止用户缩放，在你的 {{htmlelement("head")}} 中加入下列代码即可： ```html @@ -241,28 +239,28 @@ panel.ontouchend = stopMove; 在实现这样的菜单时，需要确保显示控件的控件可以通过适当的控制机制（通常为移动触摸）进行访问，如上面的控制机制中所讨论的，并且页面的其余部分被移开 或在菜单被访问时以某种方式隐藏，以避免与导航混淆。 -让我们来看一个很好的“[汉堡包菜单”的例子](http://fritz-weisshart.de/meg_men/) +让我们来看一个很好的[“汉堡包菜单”的示例](https://fritz-weisshart.de/meg_men/)。 ## 用户输入 在移动设备上，输入数据往往比在台式计算机上的同等体验更令用户恼火。使用桌面或笔记本电脑键盘输入文本到表单输入比触摸屏虚拟键盘或微小的移动物理键盘更方便。 -出于这个原因，值得尽量减少所需的输入量。作为一个例子，与其让用户每次使用常规文本输入来填写他们的工作标题，而是可以提供一个\菜单，其中包含最常见的选项（这也有助于数据输入的一致性），并提供一个“其他”选项，显示一个文本字段来输入任何异常值。你可以在 [common-job-types.html](https://github.com/mdn/learning-area/blob/main/accessibility/mobile/common-job-types.html)中看到这个想法的一个简单的例子（查看[在线例子](https://mdn.github.io/learning-area/accessibility/mobile/common-job-types.html)）。 -也值得考虑在移动平台上使用 HTML5 格式输入类型（如日期），因为它们可以很好地处理它们 - 例如，Android 和 iOS 都会显示可用于设备体验的可用小部件。有关示例，请参阅[html5-form-examples.html](https://github.com/mdn/learning-area/blob/master/accessibility/mobile/html5-form-examples.html)（请查看[HTML5 表单示例](https://mdn.github.io/learning-area/accessibility/mobile/html5-form-examples.html)） - 尝试加载这些内容并在移动设备上对其进行操作。例如： +也值得考虑在移动平台上使用 HTML5 格式输入类型（如日期），因为它们可以很好地处理它们 - 例如，Android 和 iOS 都会显示可用于设备体验的可用小部件。有关示例，请参阅[html5-form-examples.html](https://github.com/mdn/learning-area/blob/main/accessibility/mobile/html5-form-examples.html)（请查看 [HTML5 表单示例](https://mdn.github.io/learning-area/accessibility/mobile/html5-form-examples.html)）——尝试加载这些内容并在移动设备上对其进行操作。例如： - 在输入数字、电话和邮件时，展示合适的虚拟键盘来输入数字。 - 在输入时间和日期时展示合适的选择器来选择时间和日期。 -如果你想为桌面端提供不同的解决方案，则可以使用功能检测为您的移动设备始终提供不同的标记。有关检测不同输入类型的原始信息，请参阅[输入类型](http://diveinto.html5doctor.com/detect.html#input-types)，还可以查看我们的[功能检测文章](/zh-CN/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection)获取更多信息。 +如果你想为桌面端提供不同的解决方案，则可以使用特性检测为你的移动设备始终提供不同的标记。有关检测不同输入类型的原始信息，请参阅[输入类型](https://diveinto.html5doctor.com/detect.html#input-types)，还可以查看我们的[特性检测文章](/zh-CN/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection)获取更多信息。 ## 总结 -在本文中，我们向您提供了有关常见移动设备无障碍问题的一些细节以及如何克服这些问题。我们还通过使用最常用的屏幕阅读器来帮助您进行无障碍测试。 +在本文中，我们向你提供了有关常见移动设备无障碍问题的一些细节以及如何克服这些问题。我们还通过使用最常用的屏幕阅读器来帮助你进行无障碍测试。 ## 参见 -- [移动 Web 开发指南](https://www.smashingmagazine.com/guidelines-for-mobile-web-development/) — “Smashing”杂志的文章列表，涵盖移动网页设计的不同技术。 -- [使您的网站在触摸设备上工作](http://www.creativebloq.com/javascript/make-your-site-work-touch-devices-51411644) — 有关使用触摸事件来获得在移动设备上进行交互的有用文章。 +- [移动 Web 开发指南](https://www.smashingmagazine.com/2012/07/guidelines-for-mobile-web-development/)——“Smashing”杂志的文章列表，涵盖移动网页设计的不同技术。 +- [使你的网站在触摸设备上工作](https://www.creativebloq.com/javascript/make-your-site-work-touch-devices-51411644)——有关使用触摸事件来获得在移动设备上进行交互的有用文章。 {{PreviousMenuNext("Learn/Accessibility/Multimedia","Learn/Accessibility/Accessibility_troubleshooting", "Learn/Accessibility")}} diff --git a/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.md b/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.md deleted file mode 100644 index e23f7ccfce9465..00000000000000 --- a/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.md +++ /dev/null @@ -1,437 +0,0 @@ ---- -title: 响应式设计的基础 -slug: Web/Progressive_web_apps/Responsive/responsive_design_building_blocks ---- - -在本文中，我们将讨论响应式设计的主要基本组成部分，并在必要时提供一些指向更多信息的链接。 - -For Web developers, it is now fairly common to be called upon to create a Web site or app that changes its user interface depending on the browser or device accessing the site to provide an optimized experience. One approach to this is to create different versions of your site/app for different platforms or browsers and serve them appropriately after detecting which browser or platform is looking at your site. But this is increasingly inefficient: browser sniffing is inherently error prone, and maintaining multiple copies of your code can turn out to be a nightmare. - -It is usually much better to create a single version of your code which doesn't care about what browser or platform is accessing the site, but instead uses feature tests to find out what code features the browser supports or what the values of certain browser features are, and then adjusts the code appropriately. This tends to be termed **responsive design** or **adaptive design**, two related but different approaches. For a discussion on the differences between the two, read [Responsive design versus adaptive design](/zh-CN/docs/Web/Apps/app_layout/Responsive_design_versus_adaptive_design). - -This is much more reliable, more maintainable, and more future proof. You don't get caught in the situation of having to bring out more new site versions as more new browsers and platforms come out, and adjust code as feature support in existing browsers changes. - -There are disadvantages to this approach as well. If the content, layout, and functionality need to change greatly for different devices, it may not be such a good approach. Also, taking an existing site and adding responsiveness to it, to make it mobile/tablet friendly, can be a lot more effort than just creating a separate mobile site or app, especially if it is a sprawling enterprise site. Read more about [responsive design advantages and disadvantages](/zh-CN/docs/Web_Development/Mobile/Responsive_design). - -> **备注：** You can also read our discussion on the basics of [responsive design](/zh-CN/docs/Web_Development/Mobile/Responsive_design), if you need some more background information and basics. - -## Fluid grids - -The best place to start is with fluid measurements for our application layout — essentially, this means using a combination of percentages and ems/rems to size your containers and text, not fixed widths such as pixels. This has a lot of advantages in that the layout will adapt to different viewport dimensions. Let's look at an example. - -We've written a simple-but-fun prototype for an application called Snapshot, which takes a video stream from your webcam (using {{domxref("navigator.getUserMedia", "getUserMedia()")}}) then allows you to capture stills from that video stream (using HTML5 {{HTMLElement("canvas")}}), and save them to a gallery. You can then view previously-captured images and delete them. Other articles will discuss the functionality in more detail, but here we're interested in the layout. - -> **备注：** You can find the [Snapshot app on Github](https://github.com/chrisdavidmills/snapshot); check out the code and help improve it. You can also see [Snapshot running live](https://chrisdavidmills.github.io/snapshot/). Note that `getUserMedia()` is an experimental technology, which currently only works in Google Chrome and Firefox desktop. More functionality and a clean up of the styling of Snapshot are planned for a future date. - -Our desktop layout for Snapshot is three columns, containing the camera viewer, image capture view, and gallery, respectively. - -![](desktop-layout.png) - -The markup is very simple: - -```html - - - … - - - … - - - … - - -``` - -> **备注：** These weird x- elements may be unfamiliar; they are part of [Brick](http://mozbrick.github.io/), Mozilla's UI element library for mobile web apps. We have used Brick to create the mobile layout for Snapshot, which you will read more about below. - -To get these sitting side-by-side we have used the following rules: - -```css -x-card { - width: 100%; -} - -x-card:nth-child(1), x-card:nth-child(2) { - width: 30%; - float: left; - padding: 2rem; -} - -x-card:nth-child(3) { - width: 40%; - float: left; - height: 100%; - overflow: auto; - padding: 2rem; -} -``` - -So we're giving the first two columns a {{cssxref("width")}} of `30%`, and the third a `width` of `40%`, floating the columns all left. This way they end up side-by-side, and their proportions remain the same as the browser window size varies. This is just a simple grid example, but you can apply this principle to more complex grid layouts as required. - -### border-box sizing - -The padding does not affect the overall width and height of the containers because we have set the {{cssxref("box-sizing")}} of all elements to `border-box`: - -```css -*, *:before, *:after { - -webkit-box-sizing: border-box; - -moz-box-sizing: border-box; - box-sizing: border-box; -} -``` - -This basically means that {{cssxref("width")}} and {{cssxref("height")}} will now set the dimensions of an element all the way up to and including the border, not just the content. So if you set `width: 40%`, the box width will always be `40%` of its parent, and any {{cssxref("padding")}} and {{cssxref("border")}} widths set on the box will be subtracted from the content width, not added to it. Very useful! Read more about this at [\* { Box-sizing: Border-box } FTW](http://www.paulirish.com/2012/box-sizing-border-box-ftw/), by Paul Irish. - -## Flexible replaced elements - -Things are working fairly well now, but there are still some issues just waiting to present themselves. For a start, let's have a look at what happens when we include the {{HTMLElement("video")}} and {{HTMLElement("img")}} elements inside our first two columns, naked and unstyled. - -![](broken-images.png) - -Because the size of replaced elements is dictated by the size of the media inserted into them, and the media is a fixed size, they explode out of their containing elements and make a mess of the layout. This is pretty horrible, but generally this kind of problem is easily fixed with some simple CSS: - -```css -img, video { - max-width: 100%; -} -``` - -This tells the replaced elements to remain constrained inside their container's widths, no matter what. However, if they aren't as wide as their containers, they will not stretch to fill them. In the snapshot example, we ended up with slightly different code: - -```css -x-card:nth-child(1) video, x-card:nth-child(2) img { - width: 100%; - … -} -``` - -This is because in our case, we do in fact want the video and image to stretch to always fill their containers no matter what — a subtle but important difference from {{cssxref("max-width")}} — and therefore always be the same size. The video always resizes dynamically, but the screen captures taken from it do not, so upon resizing the screen it was possible to end up with a messy layout with different sized elements when using `max-width: 100%`, such as: - -![](broken-max-width-layout.png) - -## Media queries - -Fluid grids are a great start, but you'll notice that at certain points (known as breakpoints) the layout starts to break down. At these points you'll want to change the layout to rectify the layout problem, and this can be done using media queries. - -> **备注：** Media queries are a CSS3 feature that allow you to selectively apply CSS depending on the results of media feature tests — for more on the basics, read [Media queries](/zh-CN/docs/Web/Guide/CSS/Media_queries). - -### Typical desktop layout - -In our example, we have a desktop layout, as we've already seen. This is created using the CSS rules included at the top of the stylesheet, before any media queries are encountered. - -![](desktop-layout.png) - -### Mid-width layout - -We also have a mid-width layout, which is aimed at working well on tablets and narrow laptop screens. This is created by all of the CSS inside the first media query: - -```css -@media all and (max-width: 1024px) { - x-card:nth-child(1), x-card:nth-child(2) { - width: 50%; - } - - x-card:nth-child(3) { - width: 100%; - clear: left; - } - - x-card:nth-child(3) img { - width: 20%; - } -} -``` - -So here we're altering the widths of the columns and removing the float of the third column (and adding clearing to guard against any float funny business). We've also altered the width of the images inside the third container (no longer a column — this is the gallery) so that now you get five per line (it was previously three per line). - -![](middle-layout.png) - -### Narrow screen/mobile layout - -We then have a narrow screen layout, designed to fit the bill for a mobile app/open Web app experience. This is created in multiple parts. First of all, as expected, there is a media query in our main CSS, which is quite weighty, so we'll go through it in parts: - -```css -@media all and (max-width: 480px) { - x-card:nth-child(1), x-card:nth-child(2), x-card:nth-child(3) { - width: 100%; - float: none; - padding: 0; - } - - button { - margin-top: 0; - border-radius: 0; - } - - x-card:nth-child(1) video, x-card:nth-child(2) img { - border-radius: 0px; - border: none; - padding: 0; - background-color: 0; - } -``` - -This first block resets a number of different things from the widescreen layouts that were't required for the mobile app. - -```css - x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) { - margin-top: 17.5vw; - } - - x-card:nth-child(1) button, x-card:nth-child(2) button { - position: absolute; - bottom: 0; - } - - x-card:nth-child(2) button:nth-of-type(2) { - bottom: 5.9rem; - } - - x-card:nth-child(1) button { - font-size: 7vw; - } - - x-card:nth-child(2) button { - font-size: 7vw; - } -``` - -The next rules do some sizing on the buttons inside the first two cards, and give all card contents a top margin so that their content won't be lost under the navigation buttons (see below). This was necessary because Mozilla Brick (also see below) forces its components to be 100% of the screen width and height. We have used `vw` (viewport width) units for these — `1vw` is equivalent to 1% of the viewport width. This makes the dimensions scale up and down nicely along with the viewport width. Last for this section, we absolutely positioned all buttons at the bottom of the cards they are in, so the layout looks OK at different viewport size variations. We then add a rule that positions the second button in any card a button's width higher up the card. When you click on an image in the gallery it brings up options to delete or cancel deletion of the card, and you don't want two buttons on top of one another. - -```css -x-card:nth-child(3) img { - width: 50%; -} -``` - -This rule simply changes the width of the gallery images so now there are two per line. - -```css - nav { - width: 100%; - position: absolute; - z-index: 1000; - - display: -webkit-flex; - display: -moz-flex; - display: -ms-flexbox; - display: flex; - } - - nav button { - font-size: 6.8vw; - - -webkit-flex: 1; - -moz-flex: 1; - -ms-flex: 1; - flex: 1; - - border-left: 1px solid rgba(100,100,100,0.4); - } - - nav button:first-child { - border-left: 0; - } -} -``` - -In this last set of rules, we change the display value of the {{HTMLElement("nav")}} to `flex` to make it show (it was set to `none` in the default CSS at the top of the stylesheet, as it wasn't needed for the other views.) We then use absolute positioning and {{cssxref("z-index")}} to make it take up no space in the document flow, and sit on top of the x-cards (this is why we gave the x-cards that top-margin earlier). - -Next up, the `font-size` of the buttons is set to `6.8vw`. Why? Because the top-margin of the x-cards was set to `17vw` earlier on. All buttons in the app have been set to have a `line-height` of 2.5, in the default CSS at the top of the stylesheet (check if you don't believe me.) And 6.8 x 2.5 = 17. - -Last, we have used `flex: 1;` to make the buttons always take up the same proportion of space on the line. Let's have a look at the mobile layout, in the below image. - -![single column layout for mobile app view, with three buttons to navigate between cards, an image viewer, and a Save Picture button at the button.](mobile-layout.png)But there are more tricks up our sleeves for this mobile app layout! As mentioned above, we used [Mozilla Brick](http://mozilla.github.io/brick/), a collection of ready-rolled mobile UI components, in the making of the mobile app layout. In particular, we used the [deck](http://mozilla.github.io/brick/docs.html#deck) component for the nice transition effect between cards when the buttons are pressed. For more on using Brick, read [Mozilla Brick: ready made UI components](/zh-CN/docs/Web/Apps/app_layout/Mozilla_Brick_ready_made_UI_components). - -What's more relevant to this article is that we didn't want the Brick CSS and JavaScript files being applied to the markup unless we were looking at the mobile app view. To achieve this, we applied the Brick CSS to the page using a separate {{HTMLElement("link")}} element with a `media` attribute: - -```html - -``` - -This says that the whole stylesheet will not be linked to the HTML unless the viewport width is 480px or less. Moving on to the JavaScript, {{HTMLElement("script")}} elements don't accept `media` attributes, so I had to do this a different way. Fortunately there is a JavaScript construct called {{domxref("window.matchMedia()")}}, which can conditionally run JavaScript constructs depending on whether a media query returns `true` or not. We opened up the `brick.js` file and wrapped the whole lot in the following: - -```js -if (window.matchMedia("(max-width: 480px)").matches) { - // The whole of brick.js goes here! -} -``` - -This causes nothing inside the `brick.js` file to be run unless the viewport width is 480px or less. Problem solved. - -### Really wide screens - -One thing you might notice is that when the viewport gets very wide (such as on a cinema display), the layout stops getting wider, and just centers in the space available. This is pretty simple to achieve. You could use a `min-width` media query to fix the {{HTMLElement("body")}} width at a certain point: - -```css -@media all and (min-width: 1400px) { - body { - width: 1400px; - margin: 0 auto; - } -} -``` - -But it's actually easier to just set the following rule instead, and get rid of the media query altogether: - -```css -body { - max-width: 1400px; - margin: 0 auto; -} -``` - -### Orientation fail - -We also came across some problems with orientation: the mobile-app layout of our example app is designed for portrait orientation, and looks terrible when viewed on a device in landscape orientation. To fix this, we added in a media query that only applies its contents to the markup when device is viewed in landscape orientation: - -```css -@media all and (max-width: 480px) and (orientation: landscape) { - nav { - width: auto; - - -webkit-flex-direction: column; - -moz-flex-direction: column; - -ms-flex-direction: column; - flex-direction: column; - } - - nav button { - font-size: 6.8vh; - } - - nav button { - border-left: 0; - } - - x-card:nth-child(1) video, x-card:nth-child(2) img, x-card:nth-child(3) { - margin-top: 0; - } - - x-card:nth-child(1) button, x-card:nth-child(2) button { - font-size: 2rem; - } -} -``` - -This does the following: - -- Adjusts the nav buttons, changing the direction the flexbox is laid out in, and altering the font size and borders so they sit vertically instead of horizontally. -- Removes the top margin from the x-card contents so you don't end up with an unsightly gap at the top of the screen in landscape mode. -- Changes the sizing of the control buttons (e.g. _Take Picture_, _Delete Photo_) so they don't look too big and sit properly on the screen. - -This results in the following layout: - -![](viewport-fail-fixed.png) - -> **备注：** Another solution with respect to orientation might be to just lock the orientation of your app, to portrait or landscape. If you are working on an installed app, you can easily do this with the [orientation manifest field](/zh-CN/Apps/Build/Manifest#orientation). If you want a solution that works across general web apps, you could use the [Screen orientation API](/zh-CN/docs/Web/API/CSS_Object_Model/Managing_screen_orientation#Locking_the_screen_orientation), and/or provide a message asking the user to rotate their screen if they are using the wrong orientation (for example, if `window.innerWidth` is larger than `window.innerHeight`, assume the -> game is landscape mode and show a "please rotate" message.) - -## Viewport - -One last problem to mention for our example app is concerned with mobile browsers and media queries. If we viewed my example in a mobile browser in its current state, we wouldn't see our nice mobile layout. Instead, we'd see the below image. - -![](viewport-fail.png)I'm sure you'll agree that this really isn't what we wanted — why is this happening? In short, mobile browsers lie. They don't render web pages at their true viewport width. Instead, they render pages at a higher assumed viewport width (something approaching a laptop screen), and then shrink the result down to fit inside the mobile screen. This is a sensible defensive mechanism — most old school sites that don't have media queries would look terrible when rendered at say, 320px or 480px wide. But this doesn't help us responsible web developers, who have written small screen layouts into our CSS using media queries and want mobile devices to display those! - -There is a way to override this mobile rendering behavior — viewport, which is inserted into our HTML pages in the form of a {{HTMLElement("meta")}} tag. In my example, let's add the following into our HTML {{HTMLElement("head")}}: - -```plain - -``` - -This causes our browser to render our mobile app layout properly — `width=480` tells the browser _"render this markup at 480 pixels wide"_, hence the media queries kick in appropriately. There are many more options available in the viewport meta tag, which you can read about in [Using the viewport meta tag to control layout on mobile browsers](/zh-CN/docs/Mozilla/Mobile/Viewport_meta_tag). - -## Responsive images/video - -Another problem that comes up more and more these days is making image/video weight (size in KB) responsive as well as the dimensions of the image on screen. Yes, you want the images to be contained inside the app UI whether you are using it on desktop or mobile, but you should also consider that mobile apps have much smaller viewport dimensions available than desktop apps, so you should try to give mobile devices a smaller image to download. Mobiles in general (more commonly in some parts of the world than others) are on lower bandwidth connections and have less memory available than desktop devices, so yes, those extra kilobytes really do count. - -Another challenge is dealing with high resolution screens — raster graphics designed for low resolutions are in danger of appearing tiny when displayed on a high resolution screen, so devices often apply a default zoom factor to rendered pages to avoid this. The trouble with this, then, is that raster images are zoomed in and as a result can start to look pixellated. - -### CSS background images - -For CSS background images this is a fairly easy problem to solve. If you use the [mobile first](/zh-CN/docs/Web/Apps/app_layout/Mobile_first) methodology, you will be creating your mobile layout inside your default CSS, before any media queries have been applied. The media queries then supply CSS that is only applied to the markup when the viewport is **above** a certain width. Let's look at a quick example: - -```css -header { - height: 300px; - width: 100%; - background: url(images/small-header.jpg) center; -} - -@media all and (min-width: 480px) { - header { - background: url(images/large-header.jpg) center; - } -} -``` - -This means that mobile browsers only download the mobile background image asset — not the desktop mobile assets — because they fail the media query tests and therefore ignore the media queries. You can also serve a larger graphic to a higher resolution device using a resolution media query, like so: - -```css -button { - background: url(images/low-res-header.jpg) 1rem center ; -} - -@media only screen and (-webkit-min-device-pixel-ratio: 2), - only screen and ( min-resolution: 192dpi), - only screen and ( min-resolution: 2dppx) { - button { - background: url(images/high-res-header.jpg) 1rem center ; - } -} -``` - -This looks rather complicated, but really it's not — we are providing a number of media query options, as at this time different browsers support different resolution media query types and even units. Brett Jankord has a good explanation at [Cross Browser Retina/High Resolution Media Queries](http://www.brettjankord.com/2012/11/28/cross-browser-retina-high-resolution-media-queries/). - -### \