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.

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

remove document.designMode #177

Open
yoichio opened this issue Jul 4, 2018 · 5 comments
Open

remove document.designMode #177

yoichio opened this issue Jul 4, 2018 · 5 comments

Comments

@yoichio
Copy link

yoichio commented Jul 4, 2018

This is just an idea from #176.

document.designMode = true is same as document.documentElement.contenteditable = true and it looks there is rarely any usecase today.
Since I don't have any metrics so far, how about removing this feature for simpleness?

@rniwa
Copy link
Contributor

rniwa commented Jul 4, 2018

If you didn't have any metrics, the right solution is not to delete the feature. If you're making a proposal to remove this feature, please present an evidence that removing this feature is Web compatible.

@yoichio
Copy link
Author

yoichio commented Jul 4, 2018

Oh, I found we've had it.
On Chrome, document.designeMode = on is used 0.075% in wild [1] and the other hand contenteditable = true is used 2.25% in wild [2].

[1] https://www.chromestatus.com/metrics/feature/timeline/popularity/1129
[2] https://www.chromestatus.com/metrics/feature/timeline/popularity/1130

@ctzsm
Copy link

ctzsm commented Jul 6, 2018

I am curious about the data. It only explained the first spike was due to switching to a more accurate system, but there is another spike around Mar 22, 2018 for both of them, I doubt that we suddenly get a higher usage for both features, so can we find out the reason behind?

On the other hand, there is a browser behavior mismatch with document.designMode = 'on' with shadow DOM cases.

For one example:

<div>
  foo
  <div id=host></div>
</div>
const host = document.getElementById('host');
const shadowRoot = host.attachShadow({mode:'open'});
shadowRoot.innerHTML = '<div>bar</div>'
document.designMode = 'on';

Content in shadow DOM (i.e. "bar" in this example) is editable in Firefox (note that shadow DOM support in Firefox is behind a flag dom.webcomponents.shadowdom.enabled) and Safari but not editable in Chrome. (Sorry I have no access to Edge, but from this, Edge has no shadow DOM support yet).

From shadow DOM spec

The value of the contenteditable attribute must not propagate from shadow host to its shadow trees.

It didn't mention shadow DOM should inherit document.designMode = 'on' or not.

If we are not deprecating document.designMode, we probably want to standardize this behavior. Not sure if I should open another issue in editing or shadow DOM. Just comment my 2 cents here first.

@johanneswilm
Copy link
Contributor

@ctzsm An interesting observation. However, if noone uses designMode (except some cases to get around bugs in specific browsers), maybe time is better invested in other things than bringing designMode to Edge and fixing specific designMode behavior. We have actual issues that make are problematic for end users and editors, so let's try to resolve those first.

Of course, if we determine that there is a reason to not only keep designMode for compatibility with old web pages but that there is also a reason to continue developing it, we should start standardizing it. But let's first make sure there is a usecase for it. So far noone has been able to find one.

@rniwa
Copy link
Contributor

rniwa commented Aug 1, 2018

Edge DOES support designMode. What it doesn't currently support is shadow DOM API. I don't think we're comfortable removing this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants