I'm wanting a pointer cursor over an element until that element has focus, and then turn to the typical text caret. Easy enough in Chrome, but IE11 and Edge don't seem to let me change the cursor if the element has the contenteditable attribute.
#thing{cursor:pointer;}
<div id="thing" contenteditable="true"style="width:200px;border:1px solid black;cursor:pointer;"> this is a some random foo bar dog jumps over a stick test</div>
The simple example shows the cursor only changing if contentedible is false. If true, it only does the text cursor. Rather annoying since MS is the one who supposedly created this attribute. Is this just a bug? Intended by design? Is there a workaround?
I came across this link but unfortunately I'm still not having any luck by changing the DTD.
How to change cursor style on element with 'contenteditable' attribute in IE?
I have reproduced the problem on my side, it could be the default behavior of the IE browser, I will feedback this issue.
As a workaround, I suggest you could try to use the <textarea> tag, by using this tag, in IE browser it could use the pointer cursor, code as below:
<textarea id="thing" contenteditable="true" style="width:200px; height:100px; border :1px solid black; cursor:pointer">
this is a some random foo bar jumps over a stick test
</textarea>
Related
Take a look at this (overly simplified) snippet:
HTML
<div class="container">
<button class="no-select">Button</button>
Container Text
</div>
CSS
.no-select {
user-select: none; /* For comprehension sake, pretend this works for every browsers */
}
When clicking, dragging or double-clicking the button on desktop, it works as expected: the text inside the button is not highlighted.
Long-pressing the button on mobile still doesn't select the text inside the button, but instead starts selecting the parent's text. More precisely, it selects the next "selectable" thing it can. In this case, it would be the container text (Container Text). I've only tested on iOS, someone could confirm for other devices?
You can also see this behavior on Material-UI's buttons. Long-press one of the buttons on iOS and you will see the bug.
How do you prevent this behavior from happening?
Nodes in an HTML document bubble most events to its parent (and subsequent parents) that are not captured by the child. This is what you are seeing.
If you want to avoid the parent's other text from being selected when the child is (long) pressed, try wrapping the other text in a separate element.
<div class="container">
<button class="no-select">Button</button>
<span class="container-text">Container Text</span>
</div>
Generally, it's good practice to not leave bare text next to other HTML elements as it can break semantic reasoning. However, in some instances it can be acceptable, such as anchor tags or inline text buttons.
I wanted to add a behavior for input with placeholder to a contenteditable field.
Not a problem and it is done with the following CSS
<div contentEditable="true" data-placeholder="Title"></div>
[contentEditable=true]:empty:not(:focus):before{
content:attr(data-placeholder);
color:grey;
}
which is for every element with an attribute contenteditable that is true and also does not have children and not focused insert a text that is equal to the text in data-placholder.
JsFiddle is available. On FF, Chrome and IE 11 it works nice, but in Safari (from 5 to 7) I see the following bug. When I click:
click on editable
write something
click away (it works properly)
then go back to contenteditable
remove all the text
click away
Than my contenteditable is empty. (In all other browser it has Title inside). Note that if you just click on editable and clickaway, it behaves correctly.
No idea why it behaves this way and also how to fix it.
This is a known issue where the element does not register as being empty. You can fix it with a simple jquery function call to empty the element:
$input.empty();
See this answer for a detailed explaination.
Here your working jsfiddle.
In IE 9 (I'm assuming other IEs as well): using window.showModalDialog causes IE to set focus to the first focusable element in a page. This code demonstrates the issue:
<a href='javascript:window.showModalDialog("http://stackoverflow.com/")'>This sets focus to the search box</a>
<br>
<a href='javascript:window.open("http://stackoverflow.com/")'>This doesn't</a>
Fiddle: http://jsfiddle.net/Vz4Yb/
This is pretty annoying because I have some pages that have an image inside an A tag as the first element, and it puts an ugly focus rectangle around the image when the page loads. No other browser seems to be doing this. Has anyone else noticed this before, and is there a way to tell IE to NOT do this?
I'm working on an HTML page where we would like the input fields and select dropboxes to have a border around it as it is tabbed through and in focus. I've defined an input class within my CSS like so:
input.highlight:focus {
border: #003366;
border-style: solid;
border-width: 2px;
}
The input field is defined within my HTML file like so:
<input class="highlight" name="attorneyName" id="attorneyName" type="text" value="John Jackson" size="50" maxlength="30">
The focus seems to work fine in Chrome, but in IE the focus remains on one of my buttons no matter what I do. The button seems to steal the focus attribute and the page never focuses on any input fields, so the fields are never shown with a border around them while they are being tabbed through. What might be the cause of this problem?
From another thread, someone was able to point out that the :focus attribute is only recognized in IE9. This explains why the jsFiddle version works properly. When running the HTML file from my local drive, however, IE9 runs in compatibility mode for IE8 and lower and the :focus attribute is never recognized.
Have you tried to set the tab index attribute to the page elements. This property is supported by all major browsers. Supporting Browsers are : IE, safari,firefox,chrome.
" The button seems to steal the focus attribute and the page never focuses on any input fields, so the fields are never shown with a border around them while they are being tabbed through."
If i understand your question clearly then you have an issue while tabbing from one element to another right?. If that is the case the tab-index with increasing index value(or any order) will let you to select next elements while tabbing based on the tab-index set up, and the DOCTYPE Tag specifies the rules for the markup language, so that the browsers render the content correctly. Of course the changes in the Doctype tends to changes in the page. Have a quick look on w3 schools about doctype, Hope it may spot some light.
Cheers,
Arun
In Firefox extra spacing is added around the text value (not just vertical space as would be the case from line-height, but horizontal as well).
Chrome, Opera (has a slightly different line-height issue), and even IE all render submit buttons without adding any extra space.
http://jsfiddle.net/jswartwood/aFCwj/
If you open firebug and hover over the <a> and <input> respectively, you can see that it is not padding, etc.
From the sound of the bug tracker it seems that Firefox puts a "block" inside these form elements?!?! If this is true, why? This makes visual button size very difficult to keep consistent.
After digging through the Firefox source code (layout/style/forms.css) I found ::-moz-focus-inner to be the shadow selector I needed.
I still disagree with mozilla's choice of forcing line-height, but that is another story; in the mean time I may be able to normalize all browsers by setting line-height: normal.
input::-moz-focus-inner {
padding: 0;
border: 0;
}
A working example: http://jsfiddle.net/jswartwood/aFCwj/14/
To answer your original question: I do not believe CSS can successfully style the input submit element perfectly consistent across all browsers.
Every browser renders these elements differently. Explorer's buttons are in keeping with Windows. Safari's buttons are in keeping with Mac styling. Firefox, Chrome, Opera, etc. are going to do their own thing.
When it's important enough for your design that the submit button look the same across all browsers, you would create a custom graphic and make that your button.
Simply replace your submit button code with the following...
<input type="image" src="myButtonImage.jpg" alt="" />
You can optionally use CSS Sprites or JavaScript to swap button images on hover, click, etc.
A button doesn't have to be a button. You can use any other element, like a in your example, or even better span. And bind it click event to submit your form.