We have shadow dom elements of (user-agent) type. Need help on automating these elements.
Tried CSS selector for finding shadow dom elements but it didn't worked.
Related
Here is an example from some tutorial:
<p id="p">Example: <i>italic</i> and <b>bold</b></p>
<script>
let range = new Range();
range.setStart(p.firstChild, 2);
range.setEnd(p.querySelector('b').firstChild, 3);
alert(range); // ample: italic and bol
// use this range for selection (explained later)
window.getSelection().addRange(range);
</script>
How to do this with vue?
Should I use query selectors too?
I am interested how to do this selection manipulation within contenteditable. I can use "ref" for contenteditable container but inner content with bold, italic etc. tags is dynamic and mark this code with refs:
... <b><i>some text</i></b> ...
isn't appropriate.
If you're using the Selection API to manipulate the DOM (not just creating ranges, but adding/removing/modifing/reordering DOM nodes), then you should be doing those manipulations on DOM elements not managed by Vue. You must not modify parts of the DOM managed by Vue because Vue won't know about those changes and it will get confused when trying to patch the DOM during the next render cycle. Vue "owns" the rendered DOM of its components.
This doesn't mean you can't use the Selection API and Vue together, it just means you need to be careful not to tinker in the DOM willy-nilly.
Should I use query selectors too? Using p.querySelector('b').firstChild isn't vue way but I don't know what should I use insted
This rule only applies if you want to get a reference to a DOM node rendered by Vue. If the container were content editable, then its contents would not be managed by Vue and you would have no way of referencing its contents without using querySelector and other DOM functions. Try not to get caught up with "am I doing it the Vue-way?" when what you are trying to do is inherently not Vue related anyway.
I'm trying to wait till the preloader appears on the website for that I'm using ExpectedConditions.invisibilityOfElementLocated but initially when I was locating preloader through the class name "DarkBg", the explicit wait didn't wait for the preloader to get invisible but later when I located through Id then the explicit wait worked and waited till the loader disappeared.
I've attached the loader image along with its source code. I want to know why the explicit wait through classname locator didn't work?
While using ExpectedConditions invisibilityOfElementLocated() with the classname DarkBg, the element seems to be a <div> node which seems to be the parent of the actual overlay in the form of the <img> node. This <div> node includes only the style height and may be either bigger then the Viewport (or out of the Viewport) and can be the possible reason behind Selenium unable to interact with it:
Where as the <img> tag seems to be have all the required style attributes present to be within the Viewport and interactable in the form of width, height, top, etc.
Hence Selenium easily detects it.
How to write a CSS Selector selecting elements NOT having a certain attribute?
I have 2 <div> nodes as follows:
First:
<div class="weEq5" style="will-change; width;">
<button class="_35EW6">
Second:
<div class="weEq5">
<button class="_35EW6">
I need to select the <div> (with the similar class) and each of them which have a similar descending <button> but without the style attribute.
XPath seems working fine as:
//div[#class and not (#style)]/button
I am looking for an equivalent CssSelector.
Trials:
div[class :not(style)]>button (doesn't works).
I have been through the following discussion but they seem to be discarding the class attribute as :not([class]) as in:
Can I write a CSS selector selecting elements NOT having a certain class?
Is it possible to define in CSS NOT to apply style if element have certain class? [duplicate]
I was looking in similar lines ending with :not(attribute).
I think more accurate CSS Selector is:
div[class]:not([style])>button
because the button element is a child of div element.
Hope it helps you!
That's the code you're looking for:
div:not([style]) button{
background-color: red;
}
Now let's break it down.
We have have four selectors in this example:
div and button - these select html elements. We can replace it for example with a class selector like .weEq5.
:not() - indicates that we want everything that does not qualify as the selector inside the brackets.
[style] - an attribute selector which is very powerful. We can place inside the not any other css selector like html tag names (button or div), class names or ids.
The combination of div:not([style]) means that we want all divs that do not have a style attribute. After which we have a space and a button means that we want all the buttons that are inside the above selector.
Adding a > before the button div:not([style]) > button will only select button elements which are direct children of the selected div. It will exclude from selection buttons that are deeper inside the div.
Normally, you would write :not([style]) to match an element that does not have a style attribute, as described here which emphasizes the use of both () and [] brackets, in that order.
But if this isn't working in Selenium WebDriver, and worse still if :not(style) works exactly like how I would expect :not([style]) to, then that's a bug with its CSS selector parser, since :not(style) actually means "not a style element" which makes div:not(style) redundant as an element can only either be a div or a style but not both at the same time. Unless you absolutely require a selector, I strongly recommend using the XPath locator strategy instead of relying on quirks like this with Selenium WebDriver's CSS selector engine that force you to write selectors that are both incorrect and don't work anywhere else that accepts a selector.
I do not understand how the situation developed in the first place, where the structure of the page necessitates the CSS rules to be aware of whether "style=..." exists in the document itself. Or even why style=... is being used.
The style attribute is old-school now, pre-CSS I believe. It also takes precedence over anything in the CSS. That attribute does not accept CSS class names. It accepts only native html style properties like "width","height","font" - old-school stuff - ultimately those are what your CSS resolves to, no matter how fancy or obfuscated it is through frameworks: font, width, left, top, float.. and so on.
By use of the class attribute (instead of style) in the document you get infinite control from which to write smart selectors in your CSS.
You can put 3 classes in the class attribute of your div for example, if you want, and have your selectors apply styling to it if 2 of the classes are present but not if all 3 are there. Tonnes of flexibility, no need to override or use "style=..." in the document at all.
I explicitly set the line-height property of an <input> element in CSS. But when I check the element in firebug, the line-height value of this element is not what I set in CSS. And it seems that the line-height value has nothing to do with what I set in CSS. What is the possible reason for this?
According to the definition of line-height in the CSS 2.1 specification, it has a specific meaning for block container elements and a different meaning for non-replaced inline elements. I can’t find any statement on replaced inline elements there, and an input element can be regarded as a replaced element, somewhat debatably.
Anyway, odd as it may seem, browsers seem to ignore line-height on input elements. As a workaround, you might consider setting the height property, or setting vertical padding. But the results won’t be consistent across browsers. As a rule of thumb, we should expect the rendering of a text input box to the under the control of the browser, though in some cases some features can be tuned using CSS.
not sure if that was the point but i specified margin, padding and got rid of border, here you got exactly 14px: http://jsfiddle.net/mymlyn/Uq5Tt/2/
if you check the dev tools it is (and was before specyfying the above) exactly 14px:
http://dl.dropbox.com/u/26827941/ScreenShot060.png (chrome dev tools)
http://dl.dropbox.com/u/26827941/ScreenShot061.png (firebug in ff)
the reason in your case might be that your input field has a specified id or class,
<input id="someID"/>
and there is something like
input#someID {line-height: 20px;}
in your css somewhere else, andyou might be trying to change its value by setting
input {line-height: 14px;}
if that was not the case im out of ideas :)
The lineheight wont be rendered in firefox but i think it will be in IE. There's a small trick to do, which is to let lineheight style to be rendered as block elements instead of an inline elements.
For example:
This will not work
span {font-size:12px; line-height:14px}
But this will:
span {font-size:12px; line-height:14px; display:block;}
How can I avoid the dojo parser showing a hidden element after it's parsed?
<input type="checkbox" dojoType="dijit.form.CheckBox" style="display:none">
When the dojo parser is done, the dijit checkbox will be shown, but the input "inside" it, will still be hidden. I want the dojo parser to create the dijit checkbox, but keep it hidden.
I think that's a limitation of how Dijit works... it's the construction of the widget that's doing this, not the parser per se. The style element gets mapped to the INPUT element, so there is no way to do this short of instantiating the widget directly and hiding it before placing it in the DOM. Updating the style after the parser does its thing would probably result in some unwanted redraws.
I use dijit.layout.BorderContainer with style="height:100%;width:100%;visibility:hidden" and it's working fine for me.