Re: [whatwg/dom] Add FormControlRange interface (PR #1404)

@dandclark commented on this pull request.

This is looking good! Next big steps will be defining the right integration points from the HTML spec, and working towards consensus on the API shape.

> +<a for=FormControlRange>start offset</a> equals <a>this</a>'s
+<a for=FormControlRange>end offset</a>; otherwise false.
+
+<p>An {{Element}} <var>el</var> <dfn>supports form control range</dfn> if it is an
+{{HTMLInputElement}}, or an {{HTMLTextAreaElement}} whose type
+<a href="https://html.spec.whatwg.org/multipage/input.html#do-not-apply">supports the selection
+APIs</a>: "<code>text</code>", "<code>search</code>", "<code>tel</code>", "<code>url</code>", or
+"<code>password</code>".
+
+<p>The <dfn constructor for=FormControlRange lt="FormControlRange()">
+<code>new FormControlRange()</code></dfn> constructor steps are to set <a>this</a>'s
+<a for=FormControlRange>control</a> to null and its <a for=FormControlRange>start offset</a> and
+<a for=FormControlRange>end offset</a> to 0.
+
+<p>For a <a lt="supports form control range">supported</a> host element <var>el</var>, its
+<i>value string</i> is the same string exposed by its IDL attribute

Let's also make `value string` a `<dfn>` that the other instances link to.

> +
+<p>The endContainer getter steps are to return <a>this</a>'s
+<a for=FormControlRange>control</a>.
+
+<p>The startOffset getter steps are to return <a>this</a>'s
+<a for=FormControlRange>start offset</a>.
+
+<p>The endOffset getter steps are to return <a>this</a>'s
+<a for=FormControlRange>end offset</a>.
+
+<p>The collapsed getter steps are to return true if <a>this</a>'s
+<a for=FormControlRange>start offset</a> equals <a>this</a>'s
+<a for=FormControlRange>end offset</a>; otherwise false.
+
+<p>An {{Element}} <var>el</var> <dfn>supports form control range</dfn> if it is an
+{{HTMLInputElement}}, or an {{HTMLTextAreaElement}} whose type

```suggestion
{{HTMLTextAreaElement}}, or an {{HTMLInputElement}} whose type
```

> +<p>The endContainer getter steps are to return <a>this</a>'s
+<a for=FormControlRange>control</a>.
+
+<p>The startOffset getter steps are to return <a>this</a>'s
+<a for=FormControlRange>start offset</a>.
+
+<p>The endOffset getter steps are to return <a>this</a>'s
+<a for=FormControlRange>end offset</a>.
+
+<p>The collapsed getter steps are to return true if <a>this</a>'s
+<a for=FormControlRange>start offset</a> equals <a>this</a>'s
+<a for=FormControlRange>end offset</a>; otherwise false.
+
+<p>An {{Element}} <var>el</var> <dfn>supports form control range</dfn> if it is an
+{{HTMLInputElement}}, or an {{HTMLTextAreaElement}} whose type
+<a href="https://html.spec.whatwg.org/multipage/input.html#do-not-apply">supports the selection

It might be better to use the terminology of the HTML spec about this, and say something like "An element `el` supports form control range if it is an HTMLTextAreaElement, or an HTMLInputElement with a type to which the selection APIs apply..."

Actually, it might be better still to just say this:

"An element `el` supports form control range if it is an HTMLTextAreaElement, or an HTMLInputElement whose type is one of text, search, tel, url, or password", and then in a note mention that these types were chosen based on the fact that they're the ones to which the related selection APIs apply.



> @@ -9892,6 +9892,167 @@ and {{Range/getBoundingClientRect()}} methods are defined in other specification
 [[CSSOM-VIEW]]
 
 
+<h3 id=interface-formcontrolrange>Interface {{FormControlRange}}</h3>
+
+<pre class=idl>
+[Exposed=Window]
+interface FormControlRange : AbstractRange {
+  constructor();
+
+  undefined setFormControlRange((HTMLInputElement or HTMLTextAreaElement) element,
+      unsigned long startOffset,
+      unsigned long endOffset
+  );
+  <!-- TODO: Bikeshed method name. Alternatives suggested include setInFormControl,

This could perhaps also be tracked as an Open Question in the explainer.

> + "{{NotSupportedError!!exception}}" {{DOMException}}.
+
+ <li><p>Let <var>len</var> be the length of <var>element</var>'s <i>value string</i>.
+
+ <li><p>If <var>startOffset</var> &gt; <var>len</var> or <var>endOffset</var> &gt; <var>len</var>,
+ then <a>throw</a> an "{{IndexSizeError!!exception}}" {{DOMException}}.
+
+ <li><p>If <var>startOffset</var> &gt; <var>endOffset</var>, then set <var>endOffset</var> to
+ <var>startOffset</var>.
+
+ <li><p>Set <a>this</a>'s <a for=FormControlRange>control</a> to <var>element</var>,
+ <a>this</a>'s <a for=FormControlRange>start offset</a> to <var>startOffset</var>, and
+ <a>this</a>'s <a for=FormControlRange>end offset</a> to <var>endOffset</var>.
+</ol>
+
+<p>If an {{HTMLInputElement}}'s <code>type</code> changes to a type that does not

(this, too, will likely need to be something that we'll need to put in the HTML spec)

> +     control value changes (similar to Range update handling in DOM). -->
+
+<p>The <dfn export for=FormControlRange id=dom-formcontrolrange-stringifier>stringification
+behavior</dfn> must run these steps:
+
+<ol>
+ <li><p>If <a>this</a>'s <a for=FormControlRange>control</a> is null, then return the empty
+ string.
+
+ <li><p>Let <var>value</var> be <a>this</a>'s <a for=FormControlRange>control</a>'s <i>value
+ string</i>.
+
+ <li><p>Let <var>start</var> be <a>this</a>'s <a for=FormControlRange>start offset</a>, and let
+ <var>end</var> be <a>this</a>'s <a for=FormControlRange>end offset</a>.
+
+ <li><p>If <var>start</var> ≥ <var>end</var>, then return the empty string.

Not sure we need this step. I don't think we can ever have `start` > `end`, and the case where `start` == `end` returns the empty string should be implied by the following step returning the substring from `start` to `end`.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/1404#pullrequestreview-3286758245
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/pull/1404/review/3286758245@github.com>