[css-highlight-api] link to github issues.

Author: frivoal

css-highlight-api-1/Overview.bs

@@ -238,7 +238,7 @@ The [=Highlights Map=]</h3>
 		5. Return |result|.
 	</div>
 
-	Issue: Should we throw some kind of exception
+	Issue(4590): Should we throw some kind of exception
 	if the same [=highlight range group=] is [=registered=] twice (or more)
 	under different names?
 	If not, isn't it an isssue that the several [=custom highlights=]
@@ -307,7 +307,7 @@ Default Styling of a Custom Highlight</h3>
 		This would be overriden if by any use of ''::highlight(inline-highlight)'' in a stylesheet.
 	</div>
 
-	Issue: Do we really need this?
+	Issue(4588): Do we really need this?
 	Would it not make more sense to have a generic mechanism to set the style attribute
 	on any pseudo element?
 	In that case I'd also expect it
@@ -417,14 +417,14 @@ Priority of Overlapping Highlights</h4>
 	When two ore more [=highlight range groups=] have the same numerical priority,
 	the one most recently [=registered=] into the [=highlights map=] has the higher effective [=priority=].
 
-	Issue: should negative numbers mean stacking
+	Issue(4593): should negative numbers mean stacking
 	below the built-in [=highlight pseudo-elements=]?
 
-	Issue: Should priority be an (unsigned) integer instead?
+	Issue(4592): Should priority be an (unsigned) integer instead?
 	That would make comparisons more reliable,
 	but would likely lead to numbering reminiscent of BASIC line numbers.
 
-	Issue: Should we drop priority by numbers entirely,
+	Issue(4591): Should we drop priority by numbers entirely,
 	and replace it with some other ordering mechanism?
 	Experience with BASIC line number or z-index
 	does not give much confidence that ordering by number is a good idea.
@@ -433,7 +433,7 @@ Priority of Overlapping Highlights</h4>
 	other named highlights,
 	and let the UA figure it out?
 
-	Issue: Should the built-in [=highlight pseudo-elements=]
+	Issue(4594): Should the built-in [=highlight pseudo-elements=]
 	be exposed as well,
 	so that they too can be reordered,
 	and so that they can be interleaved with custom ones freely?
@@ -508,7 +508,7 @@ Repaints</h3>
 	or to changes to the {{HighlightRangeGroup/priority}} or {{HighlightRangeGroup/style}}
 	of a [=highlight range group=].
 
-	Issue: How should we specify the timing (and synchronicity) of this reevaluation?
+	Issue(4596): How should we specify the timing (and synchronicity) of this reevaluation?
 
 <h3 id=range-invalidation>
 Range Updating and Invalidation</h3>
@@ -555,7 +555,7 @@ Range Updating and Invalidation</h3>
 	are greater than the corresponding node’s <a spec=dom>length</a>,
 	The User Agent must behave as if it was equal to that <a spec=dom>length</a>.
 
-	Issue: As far as I am aware,
+	Issue(4597): As far as I am aware,
 	prior uses of {{StaticRange}}s were for [=ranges=] created by the User Agent
 	and passed to the author.
 	Here, it's the other way around,
@@ -565,7 +565,7 @@ Range Updating and Invalidation</h3>
 	Is it Fast enough that it's worth distinguishing static and live ranges?
 	Would some alternative handling be better?
 
-	Issue: The interaction of {{StaticRange}}s in a [=highlight range group=]
+	Issue(4598): The interaction of {{StaticRange}}s in a [=highlight range group=]
 	and [[css-contain-2]]
 	seems problematic:
 	on a fully contained element,