remove link 'title' attributes that's just the 'href' (zh-cn, part 5)

1 files changed, 7 insertions, 7 deletions

diff --git a/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html b/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html
index fa8fc121d3..37d5126d13 100644
--- a/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html
+++ b/files/zh-cn/web/progressive_web_apps/responsive/responsive_design_building_blocks/index.html
@@ -26,7 +26,7 @@ translation_of: Web/Progressive_web_apps/Responsive/responsive_design_building_b
 <p>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.</p>
 
 <div class="note">
-<p><strong>Note:</strong> You can find the <a href="https://github.com/chrisdavidmills/snapshot" title="https://github.com/chrisdavidmills/snapshot">Snapshot app on Github</a>; check out the code and help improve it. You can also see <a href="https://chrisdavidmills.github.io/snapshot/">Snapshot running live</a>. Note that <code>getUserMedia()</code> 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.</p>
+<p><strong>Note:</strong> You can find the <a href="https://github.com/chrisdavidmills/snapshot">Snapshot app on Github</a>; check out the code and help improve it. You can also see <a href="https://chrisdavidmills.github.io/snapshot/">Snapshot running live</a>. Note that <code>getUserMedia()</code> 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.</p>
 </div>
 
 <p>Our desktop layout for Snapshot is three columns, containing the camera viewer, image capture view, and gallery, respectively.</p>
@@ -83,7 +83,7 @@ x-card:nth-child(3) {
   box-sizing: border-box;
 }</pre>
 
-<p>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 <code>width: 40%</code>, the box width will always be <code>40%</code> 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 <a href="http://www.paulirish.com/2012/box-sizing-border-box-ftw/" title="http://www.paulirish.com/2012/box-sizing-border-box-ftw/">* { Box-sizing: Border-box } FTW</a>, by Paul Irish.</p>
+<p>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 <code>width: 40%</code>, the box width will always be <code>40%</code> 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 <a href="http://www.paulirish.com/2012/box-sizing-border-box-ftw/">* { Box-sizing: Border-box } FTW</a>, by Paul Irish.</p>
 
 <h2 id="Flexible_replaced_elements">Flexible replaced elements</h2>
 
@@ -232,7 +232,7 @@ x-card:nth-child(3) {
 
 <p>Last, we have used <code>flex: 1;</code> 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.</p>
 
-<p><img alt="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." src="https://mdn.mozillademos.org/files/5939/mobile-layout.png" style="float: left; height: 417px; margin-right: 2rem; width: 304px;">But there are more tricks up our sleeves for this mobile app layout! As mentioned above, we used <a href="http://mozilla.github.io/brick/" title="http://mozilla.github.io/brick/">Mozilla Brick</a>, a collection of ready-rolled mobile UI components, in the making of the mobile app layout. In particular, we used the <a href="http://mozilla.github.io/brick/docs.html#deck">deck</a> component for the nice transition effect between cards when the buttons are pressed. For more on using Brick, read <a href="/en-US/docs/Web/Apps/app_layout/Mozilla_Brick_ready_made_UI_components" title="/en-US/docs/Web/Apps/app_layout/Mozilla_Brick_ready_made_UI_components">Mozilla Brick: ready made UI components</a>.</p>
+<p><img alt="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." src="https://mdn.mozillademos.org/files/5939/mobile-layout.png" style="float: left; height: 417px; margin-right: 2rem; width: 304px;">But there are more tricks up our sleeves for this mobile app layout! As mentioned above, we used <a href="http://mozilla.github.io/brick/">Mozilla Brick</a>, a collection of ready-rolled mobile UI components, in the making of the mobile app layout. In particular, we used the <a href="http://mozilla.github.io/brick/docs.html#deck">deck</a> component for the nice transition effect between cards when the buttons are pressed. For more on using Brick, read <a href="/en-US/docs/Web/Apps/app_layout/Mozilla_Brick_ready_made_UI_components" title="/en-US/docs/Web/Apps/app_layout/Mozilla_Brick_ready_made_UI_components">Mozilla Brick: ready made UI components</a>.</p>
 
 <p>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 <code>media</code> attribute:</p>
 
@@ -325,7 +325,7 @@ x-card:nth-child(3) {
 <p>This causes our browser to render our mobile app layout properly — <code>width=480</code> tells the browser <em>"render this markup at 480 pixels wide"</em>, hence the media queries kick in appropriately. There are many more options available in the viewport meta tag, which you can read about in <a href="/en-US/docs/Mozilla/Mobile/Viewport_meta_tag" title="/en-US/docs/Mozilla/Mobile/Viewport_meta_tag">Using the viewport meta tag to control layout on mobile browsers</a>.</p>
 
 <div class="note">
-<p><strong>Note:</strong> There is a spec called <a href="http://dev.w3.org/csswg/css-device-adapt/" title="http://dev.w3.org/csswg/css-device-adapt/">device adaptation</a>, which defines the same functionality but in CSS, using a <code>@viewport</code> at-rule. This is probably a more logical place to put such information, but the spec is not as well supported as the viewport meta tag, therefore you should stick with that for now.</p>
+<p><strong>Note:</strong> There is a spec called <a href="http://dev.w3.org/csswg/css-device-adapt/">device adaptation</a>, which defines the same functionality but in CSS, using a <code>@viewport</code> at-rule. This is probably a more logical place to put such information, but the spec is not as well supported as the viewport meta tag, therefore you should stick with that for now.</p>
 </div>
 
 <h2 class="cleared" id="Responsive_imagesvideo">Responsive images/video</h2>
@@ -364,7 +364,7 @@ x-card:nth-child(3) {
   }</span></code> </span><span class="pln">
 </span><span class="pun">}</span></code></pre>
 
-<p>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 <a href="http://www.brettjankord.com/2012/11/28/cross-browser-retina-high-resolution-media-queries/" title="http://www.brettjankord.com/2012/11/28/cross-browser-retinahigh-resolution-media-queries/">Cross Browser Retina/High Resolution Media Queries</a>.</p>
+<p>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 <a href="http://www.brettjankord.com/2012/11/28/cross-browser-retina-high-resolution-media-queries/">Cross Browser Retina/High Resolution Media Queries</a>.</p>
 
 <h3 id="&lt;video>">&lt;video&gt;</h3>
 
@@ -388,13 +388,13 @@ x-card:nth-child(3) {
 
 <h3 id="&lt;img>">&lt;img&gt;</h3>
 
-<p>HTML images are a more difficult proposition. There is no mechanism inherent in HTML images for serving different image files dependent on viewport size, and, due to a number of irksome browser behavior realities, solutions are more difficult to hack together than you would imagine. There are currently some standards proposals in the works that would provide this — the W3C <a href="http://www.w3.org/community/respimg/" title="http://www.w3.org/community/respimg/">responsive images community group</a> discussed this problem for ages and arrived at the <a href="http://www.w3.org/TR/html-picture-element/" title="http://www.w3.org/TR/html-picture-element/">&lt;picture&gt;</a> element, which provides a similar markup structure to {{HTMLElement("video")}}<a href="/en-US/docs/Web/HTML/Element/video" title="/en-US/docs/Web/HTML/Element/video">,</a> with {{HTMLElement("source")}} alternatives selectable via media query results. Another proposal, <a href="http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/" title="http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/">srcset</a>, was put forward by Apple and takes a slightly different approach, instead providing a new <code>srcset</code> attribute for {{HTMLElement("img")}} inside which image references are placed along with "hints" that the browser can use to work out which image is most suitable to display given its viewport size, resolution, etc. These are not intended to be mutually exclusive.</p>
+<p>HTML images are a more difficult proposition. There is no mechanism inherent in HTML images for serving different image files dependent on viewport size, and, due to a number of irksome browser behavior realities, solutions are more difficult to hack together than you would imagine. There are currently some standards proposals in the works that would provide this — the W3C <a href="http://www.w3.org/community/respimg/" title="http://www.w3.org/community/respimg/">responsive images community group</a> discussed this problem for ages and arrived at the <a href="http://www.w3.org/TR/html-picture-element/" title="http://www.w3.org/TR/html-picture-element/">&lt;picture&gt;</a> element, which provides a similar markup structure to {{HTMLElement("video")}}<a href="/en-US/docs/Web/HTML/Element/video" title="/en-US/docs/Web/HTML/Element/video">,</a> with {{HTMLElement("source")}} alternatives selectable via media query results. Another proposal, <a href="http://www.w3.org/html/wg/drafts/srcset/w3c-srcset/">srcset</a>, was put forward by Apple and takes a slightly different approach, instead providing a new <code>srcset</code> attribute for {{HTMLElement("img")}} inside which image references are placed along with "hints" that the browser can use to work out which image is most suitable to display given its viewport size, resolution, etc. These are not intended to be mutually exclusive.</p>
 
 <p>This all sounds good. But those solutions are definitely not ready for production yet — both are in a very early stage of standardization, and have no support across browsers. Currently we have to rely on various polyfills and other solutions, none of which are perfect for all situations, so you need to decide which one is right for your particular situation. Some available solutions are as follows:</p>
 
 <dl>
  <dt><a href="https://github.com/teleject/hisrc">HiSRC</a></dt>
- <dd>A <a href="http://jquery.com" title="http://jquery.com">jQuery</a> plugin that allows you to create small, medium, and large versions of an image, and then serves the appropriate one according to the browser's resolution and available network speed.</dd>
+ <dd>A <a href="http://jquery.com">jQuery</a> plugin that allows you to create small, medium, and large versions of an image, and then serves the appropriate one according to the browser's resolution and available network speed.</dd>
  <dt><a href="http://www.mobify.com/mobifyjs/v2/docs/capturing/">Mobify.js capturing</a></dt>
  <dd>A very clever technique from Mozilla that allows you to capture the source of the page before it's parsed. This way, you can swap out image <code>src</code> values with JavaScript depending on browser features, circumventing browser preloading issues. This is promising, but doesn't work very well across older browsers.</dd>
  <dt><a href="https://github.com/scottjehl/picturefill">Picturefill</a></dt>