Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update to a spec draft document #251

Closed
wants to merge 23 commits into from
Closed

Update to a spec draft document #251

Show file tree
Hide file tree
Changes from 14 commits
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
4657165
update scope of spec
BoCupp-Microsoft Mar 13, 2020
df921b8
mark spot for example
BoCupp-Microsoft Mar 13, 2020
709f8de
Change title of spec
BoCupp-Microsoft Mar 13, 2020
9c805ec
rename spec
BoCupp-Microsoft Mar 13, 2020
6650990
Record a bunch of issues and share WIP document
BoCupp-Microsoft May 4, 2020
31838e6
first change
May 5, 2020
287485f
more changes to the spec
May 5, 2020
5577038
partial change
May 7, 2020
b607b9c
Merge pull request #1 from BoCupp-Microsoft/grishaChange
May 7, 2020
936bb59
updating with examples and fixing some grammatical issues
BoCupp-Microsoft May 7, 2020
c752195
small changes
May 7, 2020
2b5014b
removing setting
May 7, 2020
aa88953
reverting what i though to be a correct grammar fix. Also, linked iss…
May 7, 2020
ba03b4e
Merge pull request #2 from BoCupp-Microsoft/minorFixes
May 7, 2020
20458af
first round of PR feedback
May 8, 2020
c2ffdb8
Merge pull request #3 from BoCupp-Microsoft/minorFixes
May 20, 2020
8ee7cf4
addressing some of the PR feedback
May 20, 2020
6c46ff8
Merge pull request #4 from BoCupp-Microsoft/minorFixes
May 20, 2020
ac5ba6a
undoing title change
May 20, 2020
23bd69c
Merge pull request #5 from BoCupp-Microsoft/minorFixes
May 20, 2020
c1ddf21
Update Active Documents/contentEditableDisabled.html
Aug 11, 2020
cbd89f8
Update Active Documents/contentEditableDisabled.html
Aug 11, 2020
a53b2b4
Update Active Documents/contentEditableDisabled.html
Aug 11, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
90 changes: 0 additions & 90 deletions Active Documents/contentEditableDisabled.html
View file
Open in desktop

This file was deleted.

192 changes: 192 additions & 0 deletions Active Documents/contenteditable-disabled.html
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,192 @@
<!DOCTYPE html>
saschanaz marked this conversation as resolved.
Show resolved Hide resolved
<html>

<head>
<meta charset='utf-8'>
<title>ContentEditable-Disabled</title>
<script class='remove'>
var respecConfig = {
specStatus: "ED",
editors: [
{
name: "Johannes Wilm",
mailto: "johannes@fiduswriter.org",
company: "Invited Expert"
},
{
name: "Bo Cupp",
mailto: "pcupp@microsoft.com",
company: "Microsoft"
},
{
name: "Grisha Lyukshin",
mailto: "glyuk@microsoft.com",
company: "Microsoft"
}
],
github: "https://github.com/w3c/editing",
shortName: "contenteditable-interface",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed the short name doesn't match. Should this be contenteditable-disabled too?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd think so.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forgot to push? 👀

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, let me check.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been pushing my changes through my coworker's fork and the changes are not flowing in, somehow, I am making an attempt to edit the file in the PR.

wg: "Web Applications Working Group",
wgURI: "https://www.w3.org/2019/webapps/",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/114929/status",
license: "w3c-software-doc"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We get the right license by default, but we need to enable "xref", for cross references.

Suggested change
license: "w3c-software-doc"
xref: "web-platform", // we will be citing html, infra, and friends.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similarly to the issues above, I've changed it on my end.

};
</script>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
Copy link
Member

@marcoscaceres marcoscaceres May 8, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: common profile is deprecated...

Suggested change
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<script src='https://www.w3.org/Tools/respec/respec-w3c' class='remove'></script>

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed another commit. It caused github to disable Commit Suggestion button. I'll make a change on my and push it here.

</head>

<body>
<section id='abstract'>
<h2>Abstract</h2>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ReSpec will add this for free... you are welcome 😜

Suggested change
<h2>Abstract</h2>

<p>
This specification defines an API that indicates to user agents which editing-related commands are applicable to contenteditable regions of a document. User agents SHOULD take this information into account when presenting any editing-related UI to ensure its applicability.
Copy link
Member

@marcoscaceres marcoscaceres May 8, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Avoid RFC2119 keywords in non-normative sections.

Suggested change
This specification defines an API that indicates to user agents which editing-related commands are applicable to contenteditable regions of a document. User agents SHOULD take this information into account when presenting any editing-related UI to ensure its applicability.
This specification defines an API that indicate which editing-related commands are applicable to `contenteditable` regions of a document. User agents can take this information into account when presenting any editing-related UI to ensure its applicability.

"its applicability" is unclear... what is "its" there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The 'its' is referring to editing-related UI in that sentence. The API provides hints as to what editing operations (and therefore what editing UI) are applicable in a given contenteditable element. We could change it to... "User agents can take this information into account when presenting any editing-related UI to ensure it is applicable to a given contenteditable region."

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed another commit. It caused github to disable Commit Suggestion button. I'll make a change on my and push it here.

</p>
<p>
This specification purposefully does not prescribe the means by which a user agent will indicate to the user that some commands are not applicable in a given contenteditable region.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence reads like a double negative.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe... "This specification purposefully does not prescribe the means by which a user agent will indicate to the user the applicability of any editing command. The user agent could, for example, omit editing UI, disable it, or choose some other appropriate UI treatment."

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am taking Bo's suggestion and will push the changes in the next iteration.

</p>
</section>
<section id='sotd'>
<p></p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p></p>
<p>This is a work in progress and subject to change without warning.</p>

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed another commit. It caused github to disable Commit Suggestion button. I'll make a change on my and push it here.

</section>
<section id='conformance'>
<p></p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p></p>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note, you should move <section id='conformance'> to the end of the document. It's just boring boilerplate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good.

</section>
<section id="introduction">
<h2>Introduction</h2>
<p>
In contenteditable regions of documents, some user agents provide contextual user interface (UI) elements to help accelerate common editing operations. The UI is meant to enhance the editing experience, but when authors create customized editors that aren’t compatible with user agent UI, it leads to confused users.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aren’t => aren't

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@johanneswilm don't forget you can use GitHub's funky new suggestion button:

Screenshot 2020-05-08 14 56 31

You can then suggest changes inline that can be merged straight in.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In contenteditable regions of documents, some user agents provide contextual user interface (UI) elements to help accelerate common editing operations. The UI is meant to enhance the editing experience, but when authors create customized editors that aren’t compatible with user agent UI, it leads to confused users.
In contenteditable regions of documents, some user agents provide contextual user interface (UI) elements to help accelerate common editing operations. The UI is meant to enhance the editing experience, but when authors create customized editors that aren't compatible with user agent UI, it leads to confused users.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed another commit. It caused github to disable Commit Suggestion button. I'll make a change on my and push it here.

</p>
<p>
WYSIWYG markdown editors provide a canonical example. While markdown editors typically support bold or italicized text, they often don't support font color or font family customization. System or browser UI elements like those shown for iOS or the Mac Touch Bar below don't have any indication as to which formatting commands are applicable to a particular contenteditable element and should be displayed, and which ones should be disabled or omitted.
</p>
<figure>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should have this in the spec either... this could change in the future, and it's not appropriate to call out specific implementations in specification. Maybe move all this to a Wiki page here on GitHub.

<img src="images/mac-touchbar.png" alt="Mac Touch Bar showing editing buttons">
<figcaption>
Mac Touch Bar showing editing buttons
</figcaption>
</figure>
<figure>
<img src="images/ios-editing-buttons.png" width="300" alt="iOS selection menu showing editing buttons">
<figcaption>
iOS selection menu showing editing buttons
</figcaption>
</figure>
<p>
To address the issue, a new contenteditable-disabled attribute can be applied as shown in the example below.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚨 Whoa!!!! Noob question: is this web compatible??? I though "-whatever" was reserved for custom elements? Won't this conflict or cause confusion?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, isn't this a losing proposition? A content author would need to forever keep updating this list of things to disable, while the UA is constantly trying to enable things.

Wouldn't an all or nothing approach be better?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcoscaceres You mean a way to turn all off and then turn individual ones on again? We have gone back and forth between blacklisting and whitelisting on this. Browser makers generally prefer blacklisting and content authors generally prefer whitelisting. Browser makers are on the long end of the stick, so we went with blacklisting but with the addition that one can query which items are available, so that with a few lines of JavaScript one should effectively be able to implement whitelisting anyway.

This querying mechanism seems to have been removed with this PR and there is a tuicket here about bringing it back: #252

</p>
<pre class="example">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<pre class="example">
<pre class="example html">

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made changes on my end and will push new changes soon.

&lt;div contenteditable="true" contenteditable-disabled="
formatbackcolor
formatdent
formatfont
formatjustify
formatscript
formatstrikethrough
formatunderline
inserthorizontalrule">
This is a contenteditable region of a document that supports:
&lt;ul>
&lt;li>bold text&lt;/li>
&lt;li>italic text&lt;/li>
&lt;li>links&lt;/li>
&lt;li>lists&lt;/li>
&lt;li>and possibly other formatting outside the scope of this specification.&lt;/li>
&lt;/ul>

This contenteditable region explicitly does not support:
&lt;ul>
&lt;li>background colors&lt;/li>
&lt;li>indentation&lt;/li>
&lt;li>font name, size or color customization&lt;/li>
&lt;li>justification&lt;/li>
&lt;li>superscript or subscript text&lt;/li>
&lt;li>strikethrough&lt;/li>
&lt;li>underlines&lt;/li>
&lt;li>horizontal rules&lt;/li>
&lt;/ul>
&lt;/div>
</pre>
</section>
<section id="contenteditable-disabled">
<h2>
<code>contenteditable-disabled</code> DOM Content Attribute.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

HTML content attributes should first be approved by the WHATWG folks, and should be really be defined in HTML (the behavior of this stuff can be defined by this spec, however). @annevk and/or @domenic might want to give this a nod of approval.

We should then make a plan for how to integrate the specs.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This attribute name violates https://w3ctag.github.io/design-principles/#casing-rules.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And yeah, an issue against HTML with a rough outline of the plan/design would be good.

Copy link
Author

@gked gked May 20, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcoscaceres and @annevk thank you for your feedback. Issue tracking WHATWG discussion initiation.
I will remove the hyphen. Although, contenteditabledisabled seems lengthy to me.

</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]].
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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]].
The <code><dfn data-dfn-type="element-attr">contenteditable-disabled</dfn></code> attribute indicates which user agent-supplied editing UI SHOULD be disabled. When specified, the attribute can contain an [=unordered set of unique space-separated tokens=] that are treated as [=ASCII case-insensitive=].

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: "unordered set of unique space-separated tokens" hans't been exported yet from HTML... still need to do that. In any case, please avoid liking directly to the HTML spec using <a href=>, always use [=whatever you want to link to=]... and if [=whatever you want to link to=] doesn't exist in the xref database, we need to raise an issue on the corresponding spec to get the term exported and added to the database.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, ReSpec now throws the error. I will create an issue once the first change is landed so I can reference updated draft in the issue. Issue tracking the work here.

</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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where possible, please alway avoid <a href> - worst case, use data-cite= instead.

Suggested change
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.
The allowed set of tokens are listed below. Each token matches the name of an <a data-cite="input-events-1#events-inputevents">Input Type</a>, 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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The specification is kinda sad that it gives zero assurances about anything 😿 It's SHOULD everywhere, which leads me to believe something is not right with the overall approach.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the background for this is that it has been mentioned by browser developers that some of the appearance is determined by the OS and that it's not always possible to fully remove certain menus and menu entries. So in those cases they will grey those out in instead or make them visually disabled in some other way.

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? 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?

Copy link
Member

@marcoscaceres marcoscaceres May 8, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 gets 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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could say that user agents MUST NOT display UI that indicates an editing command is applicable if that editing command's corresponding Input Type is present in the value of the contenteditabledisabled attribute?

</p>
<h3>
<code>contenteditable-disabled</code> Allowed Tokens.
</h3>
<p>
<ul>
<li><code>formatjustifycenter</code></li>
<li><code>formatjustifyfull</code></li>
<li><code>formatjustifyleft</code></li>
<li><code>formatjustifyright</code></li>
<li><code>formatbackcolor</code></li>
<li><code>formatbold</code></li>
<li><code>insertlink</code></li>
<li><code>formatfontname</code></li>
<li><code>formatfontsize</code></li>
<li><code>formatfontcolor</code></li>
<li><code>formatindent</code></li>
<li><code>inserthorizontalrule</code></li>
<li><code>insertorderedlist</code></li>
<li><code>insertunorderedlist</code></li>
<li><code>formatitalic</code></li>
<li><code>formatoutdent</code></li>
<li><code>formatremove</code></li>
<li><code>formatstrikethrough</code></li>
<li><code>formatsubscript</code></li>
<li><code>formatsuperscript</code></li>
<li><code>formatunderline</code></li>
</ul>
</p>
<p class="issue" title="missing fontSize and insertImage">
fontSize / insertImage is missing from beforeInput. Why? It seems that it should be listed to create a more complete set.
<a href="https://github.com/w3c/editing/issues/249">Issue 249</a>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe if you use data-number ReSpec will link the issue for you. I find these features by clicking the ReSpec button, then clicking about ReSpec, and then clicking the link that sounds most like what I want to do. In this case it took me here: https://github.com/w3c/respec/blob/develop/src/core/issues-notes.js

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, please see also:
https://github.com/w3c/respec/wiki/data--number

</p>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<p class="issue" title="missing fontSize and insertImage">
fontSize / insertImage is missing from beforeInput. Why? It seems that it should be listed to create a more complete set.
<a href="https://github.com/w3c/editing/issues/249">Issue 249</a>
</p>
<div class="issue" data-number="249">
</div>

<h3>
<code>contenteditable-disabled</code> Allowed Token Shortcuts.
</h3>
<p>
The following tokens are also supported by the <code>contenteditable-disabled</code> attribute and serve as shorthands for specifying a set of tokens from contenteditable-disabled Allowed Tokens:
</p>
<p>
<ul>
<li><code>formatjustify</code>: combines <code>formatjustifycenter</code>, <code>formatjustifyfull</code>, <code>formatjustifyleft</code>, and <code>formatjustifyright</code>.</li>
<li><code>formatfont</code>: combines <code>formatfontname</code>, <code>formatfontsize</code>, and <code>formatfontcolor</code></li>
<li><code>formatdent</code>: combines <code>formatindent</code> and <code>formatoutdent</code></li>
<li><code>insertlist</code>: combines <code>insertorderedlist</code> and <code>insertunorderedlist</code></li>
<li><code>formatscript</code>: combines <code>formatsubscript</code> and <code>formatsuperscript</code></li>
</ul>
</p>
<p class="note">
Note that this specification does not have a shortcut to disable all editing UI. Authors should consider using a <code>textarea</code> or <code>contenteditable="plaintext-only"</code> for this purpose.
</p>
</section>
<section id="element-contenteditable-mixin">
<h2>Extensions to the <dfn>ElementContentEditable</dfn> mixin</h2>
<pre class="idl">
[Exposed=Window]
interface ElementContentEditable {
[SameObject, PutForwards=value] readonly attribute DOMTokenList contentEditableDisabled;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This readonly might be incorrect if we have a PutForwards. Need to check the webidl spec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No actually that looks correct: https://heycam.github.io/webidl/#PutForwards

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The JPG version of ios-editing-buttons looks unused and can be deleted.

fixed.

};
</pre>
<p>
The <code>contentEditableDisabled</code> WebIDL property reflects the contenteditable-disabled DOM content attribute.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are some things in this spec that should be definitions and others that should be linking to those definitions. Need to determine how to make that happen in ReSpec. For example, contenteditable-disabled DOM content attribute should probably be linking back to the definition for that phrase.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I've created an issue to fix DOMTokenList linking, I can use it for all dfns related fixes.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work @gked and @BoCupp-Microsoft ! I noticed you removed supported. This was something we had added after discussing whether to blacklist or to whitelist to kind of allow whitelisting anyway while giving a preference for blacklisting.

The reason this is important to JS editors is that it took several of the JS editor companies several months to discover that the Mac touch bar had been launched. During this time, their users would use the buttons of this bar and nothing would happen in the users editors or even worse - the editors were breaking. The same can happen again with new devices launches with new versions of browsers and operating systems that not every development team is aware of immediately. For that reason there was a demand for a way to query all the supported options that then can be disabled subsequently.

Maybe we need to open a ticket about this?

Sounds good, I created an issue and tagged with Agenda+ to be discussed tomorrow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When xref option is enabled, DOMTokenList will link correctly :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The <code>contentEditableDisabled</code> WebIDL property reflects the contenteditable-disabled DOM content attribute.
The {{ElementContentEditable/contentEditableDisabled}} IDL attribute reflects the contenteditable-disabled DOM content attribute.

<p>
</section>
<section id="issue-summary">
</section>
</body>

</html>
Binary file added Active Documents/images/ios-editing-buttons.jpg
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Active Documents/images/ios-editing-buttons.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added Active Documents/images/mac-touchbar.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.