Merge pull request #206 from nchan0154/master

Continue to fill out supplementary sections for client side capabilities

Author: AmeliaBR

index.html

@@ -2970,8 +2970,19 @@ <h5>Uses beyond mapping</h5>
 
 <h5>Related web specifications</h5>
 <p>
-<!-- Any existing/proposed specs that address similar needs or otherwise interact.
-      Include links with proper ReSpec references. -->
+<a data-cite="SVG2#">SVG</a> contains a number of elements that are positioned on a coordinate system.
+The coordinates and dimensions of the element are defined in markup,
+as attributes on the element.
+</p>
+<p>
+The <a data-cite="HTML#the-canvas-element">HTML Canvas2D API</a> also offers the ability to draw points on a coordinate system,
+but images are drawn by passing coordinates into a JavaScript method,
+instead of an element such as in SVG.
+This method of drawing features is more similar to existing mapping libraries,
+which are also reliant on JavaScript.
+However, the Canvas API offers a very low level of abstraction in comparison to mapping libraries.
+Depending on the complexity of the marker,
+the code to draw it may be very verbose.
 </p>
 
 <h5>Conclusion</h5>
@@ -3043,8 +3054,20 @@ <h5>Uses beyond mapping</h5>
 
 <h5>Related web specifications</h5>
 <p>
-<!-- Any existing/proposed specs that address similar needs or otherwise interact.
-     Include links with proper ReSpec references. -->
+<a data-cite="SVG2#">SVG</a> contains both a <code>polyline</code> and a <code>polygon</code> element.
+A comma separated list of coordinates is assigned to the <code>points</code> attribute to generate the shape.
+</p>
+<p>
+The way that polylines and polygons are created in the <a data-cite="HTML#the-canvas-element">HTML Canvas2D API</a> is much more manual,
+requiring a sequence of calls to the <code>moveTo</code> and <code>lineTo</code> methods.
+Like other aspects of the Canvas API,
+this syntax can be quite verbose.
+</p>
+<p>
+TODO: Mention HTML <code>area</code> and CSS  <code>polygon()</code> function.
+</p>
+<p>
+TODO: describe how polyline/polygon are represented in the important geospatial specs.
 </p>
 
 <h5>Conclusion</h5>
@@ -3109,13 +3132,28 @@ <h5>Supported use cases</h5>
 
 <h5>Uses beyond mapping</h5>
 <p>
-<!-- What other web content could use this specific capability? Be brief but specific. -->
+This functionality can be used to provide hyperlink support for diagrams.
+Any case where an image map may have been appropriate can also benefit from this capability.
 </p>
 
 <h5>Related web specifications</h5>
 <p>
-<!-- Any existing/proposed specs that address similar needs or otherwise interact.
-      Include links with proper ReSpec references. -->
+<a data-cite="HTML#image-maps">HTML Image Maps</a> consist of a large graphic with various subregions,
+which serve as links.
+A subregion is defined by passing a shape, coordinates, a link target and alt text to an <code>area</code> element.
+A significant limitation of image maps is that the coordinates of the area elements
+are always defined in pixels and do not automatically scale to match changes in scale of the image
+(see <a href="https://github.com/whatwg/html/issues/389">issue discussion on the HTML spec</a>),
+and this limits its usage in modern web development.
+</p>
+<p>
+The <a data-cite="SVG2/linking.html#Links">SVG2 specification</a> supports <code>href</code> attributes on <code>a</code> elements within SVGs,
+previously, the SVG 1.1 specification required <code>href</code> attributes to be specified within the XLink namespace.
+</p>
+<p>
+Though it is not visible,
+<a data-cite="HTML#the-canvas-element">Canvas elements</a> can include keyboard focusable links as a part of a navigable sub DOM.
+In order to make links within the canvas work on click, JavaScript is still neccessary.
 </p>
 
 <h5>Conclusion</h5>
@@ -3176,6 +3214,26 @@ <h5>Existing implementations</h5>
 <dd><a>supported, with limitations</a>: attribution is automatically generated,
 but it is not keyboard accessible.</dd>
 </dl>
+
+<h5>Supported use cases</h5>
+<ul data-ucr-role="capability-uses"><!-- auto-generated from use case required capabilities --></ul>
+
+<h5>Uses beyond mapping</h5>
+<p>
+</p>
+
+<h5>Related web specifications</h5>
+<p>
+Website authors can use <a data-cite="Microdata">Microdata</a> and other related formats to provide attribution data in a standardized format.
+How and whether or not this content is displayed is up to the website author,
+but the goal is to provide a machine-readable format for important document content.
+</p>
+<p>
+The <a data-cite="HTML#the-cite-element">cite element</a> is for describing references to a cited creative work.
+The HTML <code>blockquote</code> and <code>q</code> elements have a <code>cite</code> attribute
+where you can pass a URL as the source of a quote,
+but browsers currently do not display this information to the end user.
+</p>
 </section>
 
 </section>
@@ -3229,11 +3287,6 @@ <h5>Existing implementations</h5>
 <h5>Supported use cases</h5>
 <ul data-ucr-role="capability-uses"><!-- auto-generated from use case required capabilities --></ul>
 
-<h5>Uses beyond mapping</h5>
-<p>
-…
-</p>
-
 <h5>Related web specifications</h5>
 <p>
 The <a data-cite="geolocation-API">Geolocation API</a>
@@ -3300,6 +3353,42 @@ <h5>Existing implementations</h5>
 <dt>bing-maps-embed</dt>
 <dd><a>partial support</a>: does not support markers for a single location, but it is possible to display a map centered around a particular street address with no marker</dd>
 </dl>
+
+
+<h5>Uses beyond mapping</h5>
+<p>
+There are many cases where a website may expect an address from a user.
+An input type specifically for addresses has a wide variety applications other than displaying a map,
+such as reducing user error when facilitating e-commerce and delivery services.
+</p>
+
+<h5>Related web specifications</h5>
+<p>
+TODO: mention attempts to standardize what an “address” is,
+in HTML autocomplete attribute
+and Payment Request API.
+</p>
+<h5>Conclusion</h5>
+<!-- Cost, benefits, and recommendation on whether this should be a requirement.
+Should include an `<a>` element with attribute `data-ucr-role="conclusion"`
+whose text content or `data-lt` value matches one of the conclusions (requirement, enhancement, impractical, undecided).
+See examples.
+-->
+<p>
+Based on the limited data, we are <a data-ucr-role="conclusion">undecided</a> about whether this should be a requirement.
+</p>
+<ul data-ucr-role="conclusion-notes">
+<li>
+<a data-ucr-role="tag" href="#i18n-difficult"></a>
+There are significant regional differences when it comes to how addresses are formatted.
+A good implementation of this would need to take these regional variations into account.
+</li>
+<li>
+<a data-ucr-role="tag" href="#privacy-personal-data"></a>
+It is unlikely that this capability could be supported in a fully client-side way,
+the inputted address may be revealed to the browser or website author.
+</li>
+</ul>
 </section>
 
 <section id="capability-tile-coordinate-systems" data-ucr-role="capability">