disable div content error - css

I can disable the content of my div using this
<div style='-webkit-touch-callout: none;
-webkit-user-select: none;
-khtml-user-select: none;
-moz-user-select: none;
-ms-user-select: none;
user-select: none;
' onselectstart='return false;'>
I have two contents inside my div, the first one is the
<input>
and the other is
<textarea>
When I drag my mouse, both can't be selected. But when I right click + select all. I can select the content of my textbox, but not the input box.
NOTE: I am using an openWYSIWYG editor for my textarea, I've also tried putting transparent div at top but got same result.
the question is, how can I totally disable the selection?

There is no standard behavior on the CSS user-select-attribute. So in Safari the the "select all" option or just selecting surrounding elements will still select the content in-between – as you've experienced.
Here are some more information: "css-tricks.com: User-Select"
Note, that this CSS does not prevent users from viewing the source of the page and copy the content from there. As stated by Chris it's more for the purpose to not select content accidentally.

The proper way to disable a form element is to set it's disabled="disabled" flag with the help of JavaScript. This method works well.
You can not add this attribute for div elements, but you can emulate the behaviour of the disabled element by setting the color of selected text the same as the background of div using CSS code like
::selection {
background: #xxxxxx;
}
::-moz-selection {
background: #xxxxxx;
}
where #xxxxxx is the background-color of the div element.

Related

How to display colors correctly using ::selection pseudo element

I'm styling the selected text in my document using the ::selection pseudo class.
div::selection {
color: white;
background-color: red;
}
span {
color:white;
background-color: red;
}
<div>Selected styled.</div>
Selected regular.
<span>Not Selected.</span>
When I select the styled text, the red is very visibly not the same color as regular red. It has a blue-ish overlay. This seems to be some sort of interaction between the default selection styles of the browser and my own styles.
How can I completely remove the browsers styling while keeping my own?
I've tried using user-select: none; in the html style, but that completely overrides all selection.
EDIT: I've just run this is firefox and it's fine, so this appears to be a Chrome specific issue.
EDIT: Here is a screenshot of what I see when selecting:
I'm using Google Chrome Version 74.0.3729.131 on a Mac.

can't drag element that has css property unset: all

It seems I'm not able to drag an element that has unset: all css property.
.my-component {
all: initial;
* {
all: unset;
}
}
I use these rules inside a chrome extension, on elements that are being injected in the user browser page (to prevent local style affecting my component). Unfortunately, elements are not draggable anymore.
Those elements have the draggable property on in html.
I tried pointer-events: auto;, -webkit-user-drag: auto;, user-select: all; but I still can't manage to make elements draggable.
There must be some properties I have to set back to normal.
If someone had an idea, I would highly appreciate any help on this topic.
Edit : see this codepen - https://codepen.io/thomaslh/pen/OgQNMz
Looks like you need to add 2 CSS properties. user-select and -webkit-user-drag
.el {
all: unset;
-webkit-user-drag: element;
user-select: none;
}
<div class="el" draggable="true">
drag
</div>

How can I make the box for contenteditable text disappear?

I am using contenteditable on my web pages. This works fine but the browser puts an ugly border around the editable section when it is activated. Also, some of these borders are not erased when the focus is changed to another element on the page.
Safari creates a light blue border, Firefox uses a thin black line, so there is some browser interpretation at work here.
I have tried explicitly setting the border on the editable sections to none and making that CSS property important, but this does not change the browser's behavior.
My question:
Is there a way to influence the styling of the page element that overrules the border property when the user has clicked inside it to start editing?
Add this style (JsFiddle):
[contenteditable="true"]:active, [contenteditable="true"]:focus
{
border:none;
outline:none;
}
To let all contenteditable elements not use border and outline when focuesed.
EDIT: I found an excellent tutorial
Try adding outline:none in css for the form elements to remove the border highlight property outline:none in css for input elements.
For example:
input:focus{
outline:none;
}
textarea:focus{
outline:none;
}
select:focus{
outline:none;
}
For working code find the Jsfiddle link
[contenteditable="true"]:active,
[contenteditable="true"]:focus
{
border:none !important;
outline:none !important;
}

Clicking a child doesn't trigger the parent's :active state in IE

I have found an irritating bug in IE 8-10 that prevents a parent's active state being triggered. It appears that if a child of the parent element is the target of the click event the active state on the parent element is not triggered.
Here is a working example. If you click the text inside the <li> the element wont change colour. If you click inside an <li> anywhere other than on the <p> child the element will turn blue.
This is a problem as it pretty much renders the css :active pseudo state useless in IE if the element has any children.
Has anyone encountered this problem before, and even better found a way round it?
Here's an easy workaround: add a css rule to the paragraph.
Working example
CSS
ul { list-style: none; }
li { height: 50px; margin-bottom: 4px; background: red; }
li:active { background: blue; }
p:active { background: blue; height: 100%;}
I have fixed the issue by preventing pointer-events on the child element. This way the :active state is triggered directly on the parent and doesn't need to be propagated. The only downside of this solution is you cannot attach an event listener (not even a css `:hover selector) to the child anymore. So you have to move all your event listeners to the parent.
.child { pointer-events: none; }
Here is jsFiddle https://jsbin.com/govelabuca/1/edit?css,output
Just uncomment the last line in css and compare the result in IE and other modern browser
You could add another CSS selector for the <p> tag so your
li:active { background: blue; }
will become
li:active, li p:active { background: blue; }
I would suggest you would use javascript or jquery for that when you click a child element, perform the active state of of the parent.
I've stumbled upon this on IE11. I was writing a drag-n-drop styling logic using this approach suggested by Martin.
In my case I have a row with td cell elements and using :active for the parent tr does the job for other browsers. For IE, I've added a CSS rule to target the cells (tr.myRowClass > td:active) and modified the if condition in my custom JS logic executed during the mousemove event handler of the cells:
if (style.getPropertyValue('cursor') == 'auto' || document.querySelectorAll(":active").length > 0) {
The remaining task is to find the target element:
Determine which element the mouse pointer is on top of in Javascript

Why does the CSS3 pseudo ::selection not change the color for all parts?

Why does the CSS3 pseudo-element selection not change all parts of the highlight? As you can see in this screenshot I have selected part of the page, and parts of the selection are the default bright blue color:
This is the CSS that I'm using, it is at the top of my CSS file:
::selection { background: #3B3B3B; color: #fff; }
::-moz-selection { background: #3B3B3B; color: #fff; }
It seems like the highlight for inputs (text, checkboxes, etc.) and white space does not change. Does anyone know why this is, and is there a way to change it for every part of the page so the highlight color is consistent? I'm using Chrome.
The ::selection pseudo-element doesn't work properly in Chrome/Safari. <input> elements will be the standard highlight color. It's a very old and still outstanding bug:
https://bugs.webkit.org/show_bug.cgi?id=38943
The only workaround I've been able to come up with is using contenteditable elements instead of <input> elements.
Here's a demo I created: http://jsfiddle.net/ThinkingStiff/FcCgA/
And a post I wrote about it: https://stackoverflow.com/a/8529323/918414

Resources