Re: [w3c/manifest] Drop WebIDL enums (#899)

@mgiuca commented on this pull request.

Is Marcos on board with this? I know he has been meaning to move the spec away from WebIDL to a different schema language for some time, due to the noted issues with WebIDL.

I do think we should be moving to some kind of schema language that allows us to specify the structure of the file declaratively, and not back towards the algorithmic parsing that we used to have. This is essentially a partial revert of the work Ken and I did a couple of years ago (converting the spec into WebIDL), making it much more verbose and harder to read.

I like that you've provided a "processing an enumeration member" abstraction so that at least when we look at the algorithm for, say, processing "display", we can see that it's based on the `DisplayModeType` enumeration. But it's **much** easier to read when the WebIDL clearly specifies that the type of `display` is `DisplayModeType`, not `DOMString`. I would prefer to hold off on this and do an all-at-once transition to either a different schema language that parses the way we want, _or_ (as I've suggested doing in the past), define slightly different parsing rules for WebIDL but keep the same representation.

Ultimately, a specification needs to be readable and understandable without having to follow through threads of program code, so I'm opposed to doing any work that reduces readability, even if it technically improves the guidance on how to handle edge cases. I think there are other ways to be unambiguous about how to handle edge cases.

> * DOMString vs. USVString

Enum values and other "internal" (not user-facing) strings should be DOMString (since they will be ASCII-only anyway).

> * Is it okay to pass an enum/type definition as a set?
> * What’s the default value for `orientation`?

Good catch, there is none specified at the moment. My reading of the [SCREEN-ORIENTATION] spec says it should be `"any"`.

> @@ -1363,6 +1385,20 @@ <h3>
           if the <a>base direction</a> is <a>rtl</a>.
           </li>
         </ol>
+        <p>
+          The steps for <dfn>processing the `dir` member</dfn> is given by the
+          following algorithm. The algorithm takes a [=DOMString=] |value| as
+          an argument. This algorithm returns a `DOMString`.
+        </p>
+        <ol>
+          <li>Let |value| be [=processing an enumeration member=] given |value|
+          and [=TextDirectionType=].

`TextDirectionType` and `DisplayModeType` are referenced several times throughout the spec, and are no longer formally defined. Your new structure implies that these are now "sets of DOMStrings" (as opposed to WebIDL enum types), so I think they need to be formally declared as such.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/pull/899#pullrequestreview-428565690