For the keyword: Element Should Be Visible in Robot Framework, it is written that it gives a logical visibility not optical. What does that mean? I do not get the idea!
Thank you for your help!
It means that the keyword decides by inspecting the DOM, by checking certain HTML attributes that indicate or could indicate visibility.
The documentation of the keyword further says:
For example, an element that carries display:none is not logically visible, so using this keyword on that element would fail.
Related
I am seeing a single dash in the Chrome developer tools as seen in the image below.
What does this refer to? If it had a digit associated with it I would think it meant negative.
Nothing.
That's not a valid value for this (or any) CSS property, it looks like whatever generated that style either failed to provide a value or it's inserting invalid values on purpose (whatever that might be)...
Inspect the element and on the Styles tab (on Chrome) if the property value is invalid it'll show with a yellow explanation mark.
Whomever wrote that code just didn't know what they were doing. They declare padding-right 3 times in one style attribute, and all of them are invalid values (including the one that just says -2 with no units. If we go to chrome dev tools and we apply that same property/value to an element, we get this:
when you hover on the yellow triangle, it tells you that the - is an "Invalid property value".
Safari/Chrome Developer Tools indicate that a CSS rule is overridden by something else by striking it through, as shown in the image.
Sometimes I find myself in a situation where I can not figure out from the CSS files what causes this rule to be ignored. But surely Safari itself must know as it strikes it through.
Is there a way to know what overrides such a rule?
Look at the one which isn't striked out, higher up on the list.
Alternatively, view the computed styles. They will be the definitive applied styles.
When you inspect an element, you can show the 'box'. Just bottom of that, you have a 'filter' which should show you every properties being applied to your element.
If you click on a property, it will give you the file and the line number.
Developer Tools will list all rules for an element. Just read through all the CSS rules that apply, and check for a non-struck-through one with the same name.
Go to Elements >> Computed and you'll get the stylesheet that defines the rule you're looking for.
Go to the Computed tab of Chrome Developer tools. Find wanted property and expand details.
How do I add arbitrary selectors in CSS rules?
For instance, say I want to make every item of the .effect class turn red if the user hovers over#target. How would I implement this? Is there a robust approach to this? I know about things like nesting .effect inside #target or using the sibling selectors ~ and +, but all of these rely on a certain way of structuring the HTML.
Is this possible at all? It seems like something relatively straight forward. If it's not possible, is there any reason it isn't?
I do not want to use Javascript.
No, you can't.
Don't expect it for the forseeable future either. Let's take a look why!
From the point of view of someone who works on a CSS engine, selectors are actually evaluated backwards. This is certainly a rather interesting and less known aspect of CSS; Whilst the CSS selector specification does not directly define the implementation behaviour, all selectors are defined with this in mind. No hierarchial/ 'structural' selector has been created which can arbitrarily jump around the DOM as that would cause major performance issues in comparison to what we have today.
So, for example, let's take the following selector:
#target:hover .effect
This requires that an element with a class of effect is a child (at any depth) of an element with an ID of target because the selector engine starts by matching elements with a class of effect first, then proceeds to work backwards, stepping up the DOM looking for a parent element with an ID of target next.
Jumping to the parent node is extremely fast. Evaluating this in the forward direction would involve testing all children of any element with an ID of target which is considerably more performance intensive.
This characteristic of CSS evaluation is naturally important for performance; at the worst case, the above selector will only bubble up to the root of the DOM, testing only a handful of elements along the way. The direct child selector, a > b, only tests the direct parent and then stops, for example.
'Baking' the structure of a selector
For even further performance, the structure of a selector is 'baked' into the DOM. There certainly isn't consensus on this, i.e. every CSS engine does it differently, but roughly when the DOM structure of a selector matches (i.e. we have found an element with a class of effect and any parent with an id of target) the selector is recorded as having matched in the DOM, regardless of the hover state on #target. When the hover state on #target changes, it then simply bumps all the selectors that are baked at the element - this may then trigger the whole selector to activate or deactivate. This way we're not constantly testing masses of elements when the mouse moves around, for example.
In short, none of this works either if it could arbritarily jump around the DOM. Elements entering/ leaving the DOM could affect selectors in entirely separate parts of the DOM, so the style engine would potentially be checking the entire DOM to keep this index up to date.
Partially loaded DOM
Also consider that we can test for elements before something, but not after (when evaluated backwards):
h1 + h2
h1 - h2 /* ..? Doesn't exist! */
This is because when we test this particular selector starting against a 'h2' element, the DOM following it might not actually be loaded yet. As soon as an element enters the DOM, either because it's just been parsed from the incoming HTML or it has been added via scripting, we begin checking for which selectors it matches. That means we can't depend on anything being available after the element in the raw HTML, so again this would also be a block for any arbritary DOM hopping.
In Summary
It's currently not possible and it's unlikely to be added any time soon because it invalidates multiple performance characteristics of CSS implementations. That's not to say that it won't be added however; the W3C does appreciate that hardware is getting ever more powerful, so there is always a point at which author convenience will win over implementation performance considerations.
So, putting this a little further into context of the question, take a look at this fiddle created by #Marvin to see what's currently possible with selectors today.
First of all, I did use Google and SOF Advanced search but I didn't find this question.
Now to my question:
I know that initial sets the shadow to default i.e none.
Then what is the difference between these two keywords WHEN APPLIED TO BOX-SHADOW PROPERTY.
For some properties, none doesn't work so that time it is understood but it doesn't make sense in box-shadow and other such properties.
And I did read w3schools initial keyword page completely and I made this thread after reading that so please don't stick me that. :)
Please help me clear my doubt. :)
There is no difference according to CSS specifications and drafts. However, there is a practical difference, because not all browsers support the initial keyword. Such browsers ignore a declaration with the value initial. (If no other style sheet sets the property for an element, then the valus of the property is still its initial value.)
According to the CSS Values and Units Module Level 3 CR, initial “represents the specified value that is designated as the property's initial value”. For the box-shadow property, this value is none.
I have googled, but found no satisfactory answer.
Is there a way to execute a CSS selector live in the browser in the same way you can with JavaScript in the console?
I know I can modify the CSS in the Styles pain, but this doesn't seem to let me add psuedo selectors such as :first-of-type. It also doesn't appear to show all tags affected or the tag set returned by a selector.
Is there a way I can execute section.blah:first-of-type and see the returned or affected elements?
I'm using only Chrome right now but can use FF or whatever if it gives me this feature.
In the Elements tab, you can search with selector syntax.
If you search for
.myclass
you will find elements that have class="myclass"
I think that this is the closest that you can get to what you are asking
Go to the elements tab, and press ctrl+F (for find). in the example below, enter div.answer
to the right of the search string, you see "1 of 3" stating that 3 elements met your criteria. The current one is highlighted. and you can go up & down thru the items with the arrows.
If you use jQuery in your page then you can do:
$("section.blah:first-of-type");
Executing that in the browser console will show you a list of elements that jquery matched.
Better yet you can assign it to a variable and traverse it programatically.
Acctually you can do that just via editing the Styles pane.
You have to select a parent first(html in my case).
The result is:
In this way, chrome will show all affection instantly. Not just highlight the DOM tree.