spec: update remaining "in parallel" steps to use tasks #37
Conversation
|
tidoust: i've updated query/create algorithm in-parallel steps, ptal :) |
spec.bs
Outdated
| 1. [=/Resolve=] |p| with |result|. | ||
| 1. Run the following step [=in parallel=]: | ||
| 1. <a lt="convert">Convert |constraint| into a suitable form</a> for creating a platform-dependent [=handwriting recognizer=]. | ||
| 1. If the user agent can't create or prepare a [=handwriting recognizer=] to perform recognitions, [=queue a Handwriting Recognition API task=] to [=/reject=] |p| with a new {{DOMException}} according to the failure cause, then abort the remaining steps: |
There was a problem hiding this comment.
Both steps "queue a Handwriting Recognition API task". Maybe worth re-writing as:
- [=Queue a Handwriting Recognition API task=] to:
- If the user agent can't create or prepare a [=handwriting recognizer=] to perform recognitions, [=/reject=] |p| with a new {{DOMException}} according to the failure cause:
- If |constraint|'s ...
- Otherwise:
- Let |result| be...
- If the user agent can't create or prepare a [=handwriting recognizer=] to perform recognitions, [=/reject=] |p| with a new {{DOMException}} according to the failure cause:
There was a problem hiding this comment.
Would this cause the sequence of event to be interpreted differently?
I think the "if checks" (e.g. check if user agent can instantiate a suitable recognizer) should happen outside of the enqueued tasks, because those checks has nothing to do with JavaScript / DOM.
There was a problem hiding this comment.
I don't think the change introduces any substantive difference, but I may have missed something ;)
The Infra Standard explains that "Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms are intended to be easy to follow, and not intended to be performant.)"
Where and how the user agent checks the if condition is not observable by the application as far as I can tell. In particular, it does not trigger any event that the application could see. Regardless of how the algorithm is written, it seems totally fine for an implementation to check that condition within the enqueued task or outside of the enqueued task.
There was a problem hiding this comment.
Ah. Thanks for the explanation. I've updated to use
Queue a task to:
- If, ...
- Otherwise, ...
Co-authored-by: François Daoust <fd@tidoust.net>
Preview | Diff