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...
Related
Edge browser recently released support for autofill and I wanna apply the same custom style I have for Chrome in Edge, but apparently the tag :-webkit-autofill doesn't work. Can someone help me on what to do in this case? I've spend half a day searching for the correct tag, but I couldn't find anything.
I found the solution and what Edge does is that it includes a class called edge-autofilled in the input.
I'm developing a website that should run in ancient browsers (IE 7/8/9, Safari 5.1.7). Our target customer is the old people.
I'm no expert in javascript and I searched for solution. My title question is very straight-forward.
I used input radio and others that has custom design using before and after.
If it's checked. I just toggle in after and before display property in css.
The problem is when the user is using ancient browser, the input radio will never appear. My idea is toggle display in input radio if the browser doesn't support pseudo-elements.
For CSS feature detection there really is no need to reinvent the wheel, tools like Modernizr do this perfectly and have a very small footprint, since you can select only the feature detects that you need.
Seeing as you want to support IE <8, I would strongly advise you to use it, since you're probably going to run into a lot of situations where CSS/JS features are unavailable.
Detect if they have a sufficient browser: http://caniuse.com/#feat=css-gencontent
Basically, IE8 (maybe 9 depending on what you need) and older don't work, everything else does.
You may find the library Modernizr useful in this instance. It allows you to test for browser features.
Optionally if you want to shim it so you know that the browser will support it you can use Selectivizr
Problem
I have an Eclipse RAP application, and as soon as I change some dropdown box value, random texts became changed in my application. They become bigger. You may need to know, that in Eclipse RAP all styles are inlined and calculated server side.
Steps to Reproduce
I open a tab inside RAP with a page with dropdown lists
Change the dropdown till random texts inside the browser become bigger (usually happens by first trial)
Investigation so far
I checked the JSON ajax request-replies, nothing is related to font change. Actually nothing is related to the tab widget in which I am currently and which has its font changed.
I attached a function to the div representing the tab inside debugger
using onpropertychanged event. I log the names of events. When I change the dropdown list and the tab text becomes bigger, there is nothing style.font* in the console. Other things like background color change display the events.
the last thing is hillerious. As soon as I click on inspect, and I "touch" the client area of my application with the mouse, all fonts become OK. So inspecting the problem is impossible:
Question
Did you see something similar ever?
Do you know about known issues
for IE, which could cause this?
Is there any workaround?
Update
So the problem is originated from my using custom fonts with #font-face. I realized the followings:
- Using web-font kit generated by FontSquirrel does not make any difference. IE loads then EOT (i checked with developer tools), but still the fonts are changing randomly.
- I tried a randomly downloaded TTF, same problem occours.
- if I remove the fallbacks from the css font definitions, there is no "font-change" phenomen described above
- if there is no fallback, IE uses the custom font always, but it seems to have calculation problems when it comes to the width of a text div. For example from my two word menu items only one word is shown (obviously the second word is word wrapped).
Solution
I guess the solution for me is to use native fonts. I don't want to spend my life with hacking around bugs of IE.
My suggestion is to look at this bug report.
From your image I can see that your doctype is
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
which triggers quirks (refer here) mode rendering in browsers. So my suggestion is to try to change it.
pages rendered in quirks mode might not be able to take advantage of
features the browser supports when using standards mode.
in IE the CSS rules applied when the :hover pseudo selector are not
applied when using quirks mode (colour should change and pointer
should turn into a hand).
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
I have a client who hates the tooltips shown in browsers by the alt and title attributes of images. They requested they be removed. Obviously this is an issue for both SEO and Accessibility.
While the accessibility thing is not a huge deal to me, the SEO factor is. My initial thoughts are to remove the alt and title attributes of the images with a quick JS script. Anyone see any issues with that?
The alt and title attributes are two different things.
The alt attribute is used for accessibility reasons and is required by the standards set by the W3C. In the United States, it's also part of the Section 508 laws and regulations. The alt attribute behaves poorly in older versions of Internet Explorer by showing it's contents via a tooltip. I know for a fact Internet Explorer 9 no longer has this behavior.
The title attribute is used to force the browser in to showing a tooltip with it's contents.
My advice to you is use the alt attribute exclusively instead of the title attribute. Advise your client to update their browser to a more standards compliant browser if a tooltip irks them that much.
Modern screen readers read the generated DOM. This means if you remove tags via JavaScript, you are not only invalidating your code after the fact, you are possibily hurting those who will visiting the site using assistive technology.
I highly recommend you don't do it.
More information
Target was sued and settled because of the alt attribute: http://www.sitepoint.com/target-settles-accessibility-lawsuit-for-6-million/
Because of this landmark case, it's safe to say that Section 508 DOES NOT only apply to federal and government websites.
If accessibility is not an issue, I see no issues using JavaScript to remove the content. Assuming you're OK with using jQuery, this is the easiest way in my opinion:
$(document).ready(function()
{
$('[title]').removeAttr('title');
});
You could also remove the title content in the onmouseover event and then add it back on the onmouseout event for the sake of SEO.
In vanilla JavaScript, you could use:
var images = document.getElementsByTagName('img');
for (i=0; i<images.length; i++){
images[i].removeAttribute('title');
images[i].removeAttribute('alt');
}
JS Fiddle demo.
Reference:
removeAttribute() at the Mozilla Developer Center.
You should consider if you want to remove these features only under certain circumstances. I experience a lot of similar ideas in daily business, because some people do not like to understand what certain things a good for, and maybe handle them by themselves ...
... which brings me to the idea to eventually add a Greasemonkey script, which provides the desired functionality instead of worsening the website by means of accessibility, etc. At least it should be an additionally configurable option, maybe by setting a cookie or stuff like that.
Maybe you can convince the client it is a better than getting rid of something, to allow to make everyone the choice for their own, and activate the default settings for best SEO and accessibility.