Re: [w3c/editing] Update to a spec draft document (#251)

@marcoscaceres commented on this pull request.



> +        </pre>
+    </section>
+    <section id="contenteditable-disabled">
+        <h2>
+            <code>contenteditable-disabled</code> DOM Content Attribute.
+        </h2>
+        <p>
+            The <dfn><code>contenteditable-disabled</code></dfn> attribute indicates which user agent-supplied editing UI SHOULD be disabled.  If specified, the attribute must have a value that is an <a href=https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#unordered-set-of-unique-space-separated-tokens>unordered
+            set of unique space-separated tokens</a> [[HTML]] which
+            are <a href=https://infra.spec.whatwg.org/#ascii-case-insensitive>ASCII case-insensitive</a> [[INFRA]].
+        </p>
+        <p>
+            The allowed set of tokens are listed below.  Each token matches the name of an <a href=https://www.w3.org/TR/input-events-1/#events-inputevents>Input Type</a> [[input-events-1]], or is a shortcut that is equivalent to specifying a set tokens.
+        </p>
+        <p>
+            When a token is specified, any user agent-supplied editing UI, that when invoked, would result in a beforeinput event having and inputType that matches one of the tokens in the attribute's value, or matches a token that is represented by a shortcut that is included in the attribute's value, SHOULD be disabled, omitted, or otherwise indicated by the user agent to be not applicable.  The exact mechanism for that indication is beyond the scope of this specification.

> So in those cases they will grey those out in instead or make them visually disabled in some other way.

Ok, that's interesting. You are saying the functionality get disabled... so, that could work: It's not so much the presentation/UI aspect that the spec needs to concern itself with, but with the functionality itself... then it can be "MUST" just around the functionality.  

> But using "SHOULD" everywhere also basically means that a browser can be fully compliant with the spec without actually having implemented anything at all, right?

Yeah. 

>  In that would it make more sense to write that it "MUST" disable menus in some way without specifying what that way is and those browsers that cannot comply with that then need to be listed as non-compliant?

So yeah, don't think about this as menus (because then it crosses into areas where browsers compete at the UI level)... just talk about functionality. 

-- 
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/editing/pull/251#discussion_r422005667