I stumbled a couple of times into this Light DOM thing but wasn't able to understand the difference with Shadow DOM. If someone out there could provide a clear answer it would be much appreciated.
The Light DOM is simply the plain old DOM tree inside a HTML element.
The term is only used in the context of web components to distinguish it from the Shadow DOM.
I suppose the normal DOM was redefined as Light in contrast with Shadow.
The specs call it the shadowroot host's node tree, or light tree:
A shadow root is always attached to another node tree through its host. A shadow tree is therefore never alone. The node tree of a shadow root’s host is sometimes referred to as the light tree.
I call it the normal DOM :-)
The Shadow DOM is the added DOM that recovers, masks, or replaces the normal DOM, as explained in the article from Google.
The rendered DOM can be a combination of the Shadow DOM and the Light DOM (through <slot> elements)
Note: it's not possible to completely polyfill the Shadow DOM behaviour in JavaScript, so Shadow DOM polyfills actually deal with normal DOM trees only.
You can say, the node tree that hosts the shadow root is referred as the light tree which might be Light DOM or another Shadow DOM as well.
Check this note in the specification.
A shadow tree’s corresponding light tree can be a shadow tree itself.
Related
why ::marker pseudo-element not support all CSS properties like other pseudo-elements?
can anyone explain me in brief.
Found out today that ::marker pseudo-element not support all CSS properties like background, display, etc but "font-size", "color", and "content" properties are working like charm.
The CSS Lists specification explains:
NOTE: It is expected that future specifications will extend this list of properties and relax the restriction on which properties can take effect. However at the moment outside marker box layout is not fully defined, so to avoid future compatibility problems only these properties are allowed.
Because this selector selects marker of a list item. Like the buller for example. That means that it allows you only to customize the bullet, not the list itself. Thats why you cant apply properties like display, because you are effecting the marker itself. This can be helpful
I'm working on a web scraper, and am examining some dynamic content. In the Elements inspector, the time class is pulsing blue. I can't find any documentation on what this is. Obviously it is being periodically updated. Is there a way to find out how?
It means the element is dynamically changed. It seems that there's no document about this, but we can draw this conclusion based on experience.
You can also refer to this similar thread. Edge is based on chromium, so it's the same in Edge developer tools.
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.
Is there a pseudo selector for this item? I am talking about the milky blue rect that appears on elements being inspected. It is too obtrusive and I would like to change it to just an inset box-shadow with an animated hue-rotation.
I suspect it lives in the shadow dom somewhere, what techniques could be employed to sniff it out minesweeper style?
The context is from a chrome extension.
Is there any way to access the stylesheets that make up firebug to edit things like the indent distance for nested DOM nodes? Looking for a location of some .css files or something that I can override.
I frequently find myself working with deeply-nested nodes that are pressed up against the right side of firebug, while the whole left side is unusable whitespace.
In Stylish Firefox extension, you can use this code to remove the indentation in the dom panel.
I have to look further to see how to decrease the indentation on child nodes (it's a good userstyle project, btw) :
.memberLabelCell{
padding-left:0 !important;
}
Edit:
Here is a little userstyle which reduces the indentation of nodes in html and dom panels : http://userstyles.org/styles/42885
(you need stylish to use it)