[css-snappoints] Adding issue for trying to consolidate duplicated text in resnapping requirements

Author: ChumpChief

css-snappoints/Overview.bs

@@ -291,6 +291,8 @@ Scroll Snapping Rules: the 'scroll-snap-type' property {#scroll-snap-type}
 
             If the content changes such that the scroll container would no longer be <a>snapped</a> (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change and that same snap position still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change.
 
+            Issue: The text for mandatory and proximity resnapping requirements has some overlap -- try to rewrite this more concisely and without repetition without altering functionality
+
             If specified on a non-<a>scroll container</a>,
             this value “traps” descendant boxes’ <a>snap positions</a>,
             preventing them from affecting any ancestor <a>scroll containers</a>.

css-snappoints/Overview.html

@@ -543,6 +543,7 @@ <h3 class="heading settled" data-level="5.1" id="scroll-snap-type"><span class="
     <dd>
       If specified on a <a data-link-type="dfn" href="#scroll-container" id="ref-for-scroll-container-19">scroll container</a>, the <a data-link-type="dfn" href="#scroll-container" id="ref-for-scroll-container-20">scroll container</a> may <a data-link-type="dfn" href="#snap" id="ref-for-snap-8">snap</a> to a snap position at the termination of a scroll, at the discretion of the UA given the parameters of the scroll. 
      <p>If the content changes such that the scroll container would no longer be <a data-link-type="dfn" href="#snap" id="ref-for-snap-9">snapped</a> (e.g. content is added, moved, deleted, resized) to the same snap position it was snapped to before the content change and that same snap position still exists (e.g. its associated element was not deleted) and is reachable, the scroll container must be re-snapped to that same snap position after the content change.</p>
+     <p class="issue" id="issue-3caf6830"><a class="self-link" href="#issue-3caf6830"></a> The text for mandatory and proximity resnapping requirements has some overlap -- try to rewrite this more concisely and without repetition without altering functionality</p>
      <p>If specified on a non-<a data-link-type="dfn" href="#scroll-container" id="ref-for-scroll-container-21">scroll container</a>,
             this value “traps” descendant boxes’ <a data-link-type="dfn" href="#scroll-snap-position" id="ref-for-scroll-snap-position-10">snap positions</a>,
             preventing them from affecting any ancestor <a data-link-type="dfn" href="#scroll-container" id="ref-for-scroll-container-22">scroll containers</a>.</p>
@@ -1462,6 +1463,7 @@ <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content
    <div class="issue"> <b>This spec is currently undergoing major changes in line with the resolutions in <a href="https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html">https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html</a>. During this process it is not safe to assume that the current form will be representative of what it will look like in the future. After the work in process is completed, it will closely resemble <a href="https://drafts.csswg.org/css-scroll-snap/">this proposal</a>.</b><a href="#issue-752e30a5"> ↵ </a></div>
    <div class="issue"> <a href="https://lists.w3.org/Archives/Public/www-style/2015Nov/0328.html">Open issue</a> on whether to enhance the scroll-snap-type property for specifying the axis or adding a second property.  We have <a href="https://lists.w3.org/Archives/Public/www-style/2015Dec/0048.html">resolved</a> that this functionality be added once the issue is resolved.<a href="#issue-7e0cf181"> ↵ </a></div>
    <div class="issue"> Currently considering renaming the values<a href="#issue-780b32d8"> ↵ </a></div>
+   <div class="issue"> The text for mandatory and proximity resnapping requirements has some overlap -- try to rewrite this more concisely and without repetition without altering functionality<a href="#issue-3caf6830"> ↵ </a></div>
    <div class="issue"> Should this be x/y axes, or inline/block?  Starting with x/y axes for consistency with padding/area, otherwise a writing mode change would result in a axis mismatch (since padding is physical by default).<a href="#issue-f7391e31"> ↵ </a></div>
    <div class="issue"> This feature is planned to be removed in the next publication
     in order to reduce the feature-set of Level 1.