chrome supports the isContentEditable property (lists it in the "Inspect Element"), but reports false for INPUT, FORM - actually, everything.
too me, for example, seems that INPUT, non-readonly, should be true.
does anybody know what's going on?
isContentEditable doesn't have anything to do with forms and input boxes.
It was designed to be a way to flag inline editable html content.
You can see a working example here: http://www.navioo.com/javascript/dhtml/isContentEditable_Example_4513.html
You can read about it
here: http://www.w3.org/TR/2009/WD-html5-20090423/editing.html
or: http://blog.whatwg.org/the-road-to-html-5-contenteditable
An element's isContentEditable property, in browsers which support it, tells you whether the immediate child content of the element is editable. It applies specifically to regular non-interactive content (i.e. not form controls), which can be made editable using the contenteditable attribute:
<div contenteditable="true">This text is all <i>editable</i></div>
The isContentEditable property of both the <div> and the <i> elements above will report true. However, be aware that not every browser that supports contentEditable also supports isContentEditable: Firefox 3.x, for example, supports contentEditable but not isContentEditable.
contenteditable is standardized in HTML5 but has been around for over a decade. It was first introduced in IE 5.5 in 2000 and eventually made its way into other browsers several years later. Firefox has had it since version 3.0 (although it had the document-wide equivalent designMode since pre-1.0) and Safari since (I think) 2.0.
Here's a good summary of the history of contentEditable: http://blog.whatwg.org/the-road-to-html-5-contenteditable
Related
I use the blur filter in my react application, in google browser or in microsoft edge everything works fine, but when I decided to test it in mozilla firefox I found out that it doesn't work there, I checked mozilla.org and didn't find anything special, maybe you have ideas?
<div style={{backdropFilter: `blur(${someValue}px)`}}
...
</div>
The backdrop-filter property is not enabled by default in Firefox. It is supported in newer versions, but it is hidden behind a flag, see MDN article to see that flag.
However you can probably achieve the same effect, using the more supported filter css property. The difference is that filter applies the effect to the element itself, while backdrop-filter applies it to the area behind the element.
I m developing a cross-browser application in Script#.
I m using a contenteditable div, where user can add text. But i dont want the auto correct/ auto completion feature to change the user text.
Plz tell me how can i disable this feature.
It should work on all platforms. ( iOS, Android, Windows)
I have tried autocorrect="off";
autocomplete="off"
but nothing is working. plz help....
What you can do is to use the attribute spellcheck=false. This is (in HTML5 CR) the defined way to disable “checking of spelling and grammar of editable text”. The default value of this element is browser-dependent, and the value may depend on element. E.g., in Chrome, the default is spellcheck=true for an element that has been made editable using the contenteditable attribute.
However, this affects (at most) only what happens in the browser. Software external to the browser, such as a system’s keyboard reading routines, are probably immune to anything you say in HTML.
You are using the correct attributes, but I'm not positive if they are expected to work with contenteditable (they are definitely supported for and tags). Current iOS versions(at least v6.1 and up) will currently support those attributes, however there is a bug in Chrome for Android not respecting these HTML 5 attributes. It appears to just recently have been fixed and hopefully should be released in an update soon.
https://code.google.com/p/chromium/issues/detail?id=303883&q=autocorrect&colspec=ID%20Pri%20M%20Iteration%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified
Also feel free to Star the issue to help boost the ranking...
Our site makes use of FreeTextBox, a web-based, rich-text editor. In IE, but in not Firefox, if a user types in something like:
someone#blah
IE automatically creates a mailto hyperlink. I have tested this with other text editors out there and the story is the same with all of them.
Can I override this browser behavior somehow from within my application?
This has to do with the MSHTML editor, which (I'm guessing all) Windows browsers use to instantiate rich text editors. There's a setting called IDM_AUTOURLDETECT_MODE that lets you decide if the autolinking will take place, and the default is true (other browsers apparently set it to false on instantiation, hence no autolinking in Firefox.)
Unfortunately, until recently Microsoft didn't have a mapping from the command ID to a command identifier string, so the function wasn't accessible via Javascript prior to IE9.
I just tried it out in IE9 and can confirm that, for that version and presumably all future ones, you can override the feature by calling
document.execCommand("AutoUrlDetect", false, false);
Note that it's IE9+ only, so you're still stuck for previous versions, and that you'll want to wait until the DOM is loaded before you call it and have some error handling around it, etc, etc.
There's a good summary of the original issue here, and a discussion of the fix in the minor change list here.
I am testing the speed of different methods to dynamically add html elements to the DOM. I've build a tester here (code is working version, so pretty sloppy). The results are (very) different for different browsers with Chrome getting all the points for speed, and Opera a good second - but that's not the question here.
In Firefox I detected a problem with clearing a div (from it's childNodes). When some 50.000 div elements are added, it takes ages to clear, using just
[div].innerHTML = "";
What is going on here? Did firefox implement some intrinsic garbage collection method for this?
While I am not sure about the innerHTML = "" you left out one possibly fast appoach using DocumentFragments for inserting into the DOM: As John Resig shows.
As Ólafur Waage already mentioned, even though innerHTML is faster in a lot of situations since it's not part of any W3C standard, quirks are far more likely to be introduced then if they were. Not to say innerHTML is not a defacto standard within modern browsers.
This blog post seems to indicate that Firefox spends a lot of time cleaning up after itself when using innerHTML to remove elements.
In some browsers (most notably, Firefox), although innerHTML is generally much faster than DOM methods, it spends a disproportionate amount of time clearing out existing elements vs. creating new ones. Knowing this, we can combine the speed of destroying elements by removing their parent using the standard DOM methods with creating new elements using innerHTML.
innerHTML is not a part of the W3C DOM specification.
It should never be used to write parts of a table—W3C DOM methods should be used for that—though it can be used to write an entire table or the contents of a cell.
As there is no public specification for this property, implementations differ widely. For example, when text is entered into a text input, IE will change the value attribute of the input's innerHTML property but Gecko browsers do not.
For those wishing to adhere to standards, here is one set of JavaScript functions offering to serialize or parse XML so as to set element contents defined as string(s) via the DOM or getting element contents obtained from the DOM as a string.
Source - Mozilla Dev
Is it true that most WYSIWYG editors on a webpage is by using the designmode property? Is there any other method besides using this method?
(is designmode first available on IE and other browsers added it too later on?)
HTML5 defines a contentEditable attribute that can be applied to any element (including the body element), it's supported in IE (which i think invented the attribute), Safari >2.0, and Firefox 3.x where x is at least 5.
Use is simply
<div contenteditable>Yay, i'm editable!!!</div>
Yes, this is probably the only way to do this without embedding non-html editors made in Flash, Silverlight, Java, etc.
Yes, this attribute first appeared in IE, then it was added in Mozilla (about the end of 2003), then in Opera 9 and Safari 2.