This seems like a rendering engine quirk, as it had been tested and failed to reproduce on WebKit driven browsers (Chrome and Safari for Windows).
Description
When using a deep nested DOM structure, such as the GXT Grid, the default cursor seem to override any other style applied. How to override (or sidestep) this behavior?
Test Case
Steps To Reproduce
(Requires basic knowledge of your favored browser's developer tools)
Visit the GXT 2.2.x examples showcase.
Right-click a cell text value in the grid and click Inspect Element, or hit F12 to open the developer tools and than inspect that element manually. You should be inspecting an element notated as: div.x-grid3-cell-inner.x-grid3-col-name.
In the Styles view, look for a rule matching the following selector: .x-grid3-row, it should have a single declared property for cursor. Change its value from default to auto.
Expected Result
The cursor should be rendered according to the element's type, e.g. text cursor for text content elements.
Actual Result
On Gecko based browsers, the default cursor appears regardless of the element's type.
This is a known issue caused by ancestor elements with a declared tabindex attribute with a value equals or larger than 0, and is a reported bug in the Mozilla bug tracker.
It can be reproduced by running this simple test case on Gecko browsers (run on WebKit for a reference).
As a workaround, one can ensure all elements up the hierarchy are assigned with a tabindex value of -1, or remove those altogether, thus avoiding entering this block, turning cursor related CSS rules back to their normal behavior.
Related
It seems like when a gesture begins in textarea or input, touch-action is ignored. This is unexpected for me. Expected behavior: touch-action is taken into account and e.g. scrolling does not happen (see demo below).
Demo: https://jsfiddle.net/1x8pc5ed/1/ (Open the desktop browser developer tools and activate the touch simulation or just open it on your phone, then try to scroll the page starting the gesture from the textarea, input and other areas for comparison.)
I've tested it in Firefox and Chrome:
Chrome ignores touch-action only in textarea case.
Firefox ignores touch-action in input and textarea cases.
Can anyone explain this behavior? For me it looks like a bug.
About textarea case:
This is probably not a bug, but expected behavior.
According to https://w3c.github.io/pointerevents/#determining-supported-touch-behavior:
A touch behavior is supported if it conforms to the touch-action property of each element between the hit tested element and its nearest ancestor with the default touch behavior (including both the hit tested element and the element with the default touch behavior).
I.e. in this case the chain begins and ends on textarea because the textarea potentially has default touch behavior (potentially it can be scrollable).
Applying overflow: hidden or touch-action: none on textarea let to prevent scrolling.
Yesterday (and today 12/18/2017) i updated my chrome browser to "Version 63.0.3239.108 (Official Build) (64-bit)" and something i found accidentally was about cursor issue in this version. I was added cursor: auto to some elements in my CSS and it was as i expected (totally normal) but now, after the update, cursor on those elements will not behave like they should be or at least like it used to. (In before, for a elements cursor was pointer and for plain texts was text, ofc after applying cursor: auto to them).
Based on Mozila MDN, initial value for cursor is auto same as W3 mentioned in their docs, but my chrome dev has no auto value for cursor and also act totally different from this description:
auto: The browser will determine the cursor to display based on the context. E.g., equivalent to text when hovering text.
The question is are google dev changed the behavior of cursor: auto or deprecated/removed it from their engine, or this is sort of a bug? If they mentioned cursor: auto as deprecate property please link me to it because i couldn't find anything related to this problem in their "changelog" and forum.
This is a fiddle that represent the issue: jsfiddle
The auto value for cursor is determined by the context:
The browser will determine the cursor to display based on the context. E.g., equivalent to text when hovering text.
And the text value states that:
The text can be selected. Typically the shape of an I-beam.
Essentially, because you can select the text in a hyperlink, the browser determines the I-beam to be the most appropriate cursor. This is not specific to Chrome's latest version (I just tested this in 63.0.3239.84), nor is it specific even to Chrome, as other browsers also exhibit this behaviour.
Hope this helps! :)
Does Firefox have any support at all for the alignment-baseline property? When I inspect (using Firebug) SVG elements for which the alignment-baseline property has been explicitly set, Firebug does not list this property at all (IOW it treats is as noise). No matter what value I assign to this property, the appearance of the displayed text never changes, further suggesting that FF ignores this property altogether.
(One other sign that FF's support for this property may be busted is that the link given in the page cited above for the CSS documentation for this property is dead-as-a-doornail.)
Assuming that, as it appears, FF does not support the alignment-baseline property, what is the value of this property that would most closely replicate FF's default behavior?
EDIT: For example, view this jsFiddle with both Chrome and FF; each line of displayed text displayed a highlighted word that has been produced with code of the following form:
<tspan style="alignment-baseline:alphabetic">alphabetic</tspan>
Note that all the lines look the same in FF, but not so in Chrome.
There are a few possible candidate values for this property to replicate FF's default behavior (namely, auto, alphabetic, mathematic, and inherit); unfortunately, this experiment cannot decide the matter, and it's not clear to me which of the possible options would match FF's default behavior in the greatest fraction of cases.
It seems that alignment-baseline is ment to be used only for portions of <text>, that is for elements tspan, tref etc. For the main <text> element use the dominant-baseline attribute.
(This is what #Tanel Eero wrote above as a comment. I'm re-stating it here so the question can get an accepted answer).
The Mozilla Developer Network website states that the style can only be used on certain elements:
The following elements can use the alignment-baseline attribute
<tspan>
<tref>
<altglyph>
<textpath>
So that seems to be your main issue as I understand that you are trying to apply it to a SVG.
I have created some fairly elaborate DOM elements with an :after pseudo-element, and I'd like to be able to inspect and tweak them in either Chrome Inspector or Firebug or equivalent.
Despite this feature being mentioned in this WebKit/Safari blog post (dated 2010), I can't find this feature at all in either Chrome or Safari. Chrome does at least have checkboxes to inspect :hover, :visited and :active states, but :before and :after are nowhere to be seen.
Additionally, this blog post (dated 2009!) mentions this capability exists in the IE dev tools, but I'm currently using Mac OS, so this is no help to me. Additionally, IE is not a browser I'm primarily targeting.
Is there any way of inspecting these pseudo-elements?
EDIT: In addition to being wrong about Firebug being unable to inspect these elements, I've found Opera to be pretty good at Inspecting :before and :after elements out of the box.
In Chrome's Dev tools, the styles of a pseudo-element are visible in the panel:
Otherwise, you can also input the following line in the JavaScript console, and inspect the returned CSSStyleDeclaration object:
getComputedStyle(document.querySelector('html > body'), ':before');
window.getComputedStyle
document.querySelector
As of Chrome 31 pseudo elements show in the elements panel as child elements of their parent as shown in the following image:
You can select them as you would a normal element but if you remove the content style then the pseudo element will also be removed and the devtools focus will change to it's parent.
It appears that inherited CSS styles are not viewable and you can't edit CSS content from the elements panel.
Chrome won't show :before and :after pseudo elements in the DOM-tree, if they miss "content" attribute. It should be set, even if it is set to nothing.
This won't show up:
:after {
background-color: red;
}
This will show up in the inspector:
:after {
content: "";
background-color: red;
}
Hope it helps.
At least since Chrome 62 there's a setting in DevTools to 'Show user agent shadow DOM' which displays additional pseudo-elements like input placeholders, which wouldn't show up in the DOM tree otherwise.
More information: https://stackoverflow.com/a/26853319/3963594
After a lot of frustration, I figured out that firefox doesn't show the pseudo elements in the document tree at all, but if you select the exact element which has pseudo element(s) defined, then the styles for its pseudo element(s) are shown in the style rules section on the right side. This is true for both firebug and the built-in inspect ("Q"), and I am shocked that nobody bothered to explain this clearly before.
Clearly, chrome/chromium's handling of pseudo elements is vastly superior, as they can be selected (both in the document tree and directly on the page) and inspected just like regular elements, with layout, properties and everything else, independent of their "owner".
Browser versions I'm using currently: Chromium 40.0.2214.91, Firefox 31.3.0.
Firefox has had this feature for awhile now, just right click, "inspect element", and see the before and after elements in the right panel of the inspector.
Select Element--> select hover checked ---> you can see ::before and after elements
I have explicitly specified an element as "visibility: visible" yet it doesn't display in Chrome. Using Chrome's Developer Tools, I can see the inline style specified, but the "Computed Style" shows "visibility: hidden".
Well that explains why it's not displaying in Chrome, but I don't understand what's causing Chrome to compute the visibility to be hidden. (Appears to work correctly in all other browsers.)
I have also inspected all parent elements and all either do not mention visibility or specify it to be visible.
I executed the following JavaScript command directly, via the Developer Tools console, to no avail (computed visibility remained "hidden"):
document.getElementById("c_311").style.visibility="visible"
See screenshot here: http://oi52.tinypic.com/ezrdcy.jpg
I know this is late, but I had the same issue lately, with Chrome 23. It seems like the secret is to also set the display property, like so:
domElem.style.visibility = 'visible';
domElem.style.display = 'block';//this is needed mainly for Chrome
and, to hide:
domElem.style.visibility = 'hidden';
domElem.style.display = 'none';//this is needed mainly for Chrome
It seems like Chrome uses a computed setting for visibility. IE and FF will hide or show the element when 'visibility' is set, regardless of 'display' property.
Which version of Chrome are you using? It has some bugs on version 11. See this post.