I wish to extract the entire CSS affecting a div that is highlighted. With complex designs the CSS is made up of many classes which add in some CSS. Looking for a technique that can strip out and perhaps concatenate all these together, like Inspect Element but cleaner.
For example, on this Adobe Experience Page(http://www.adobe.com/uk/products/experience-design.html). I wish to select the article div "A new experience in user experience." and then pull out all the CSS affecting everything inside it attached to a class.
There is an ExtractCSS tool that does something similar, but looking for something a bit more intuitive. That ignores all the strikethroughs too.
The simplest way is:
Select your element in the developer tools
Run window.getComputedStyle($0).cssText on the Js console
where $0 represents the currently selected DOM element.
In alternative, if you want to target a specific element with a given class, then do
window.getComputedStyle( document.getElementsByClassName('hero2-align-2 hero2-basis-0')[0] ).cssText
Querying elements by class name might return more than 1 element, the [0] is there to guarantee only one is processed.
Or by id
window.getComputedStyle( document.getElementById('yourID') ).cssText
Related
After carefully reading all related articles and posts on many sites, there is still one remaining question: Can i have a single, exchangeable CSS for a web app built with web components widhtout having to deal with all the weird stuff suggested by W3C?
I know about ::part( something ) and exportparts="something" to access nested components, but that does not go down the tree, so I have to add a part attribute to almost every element, which totally bloats my HTML.
Having an #import rule in each component is also not a great option, because it would be one more HTTP request per stylesheet. Also, once loaded in a template, the importet css can not be exchanged easily.
W3C really makes our lives harder by removing /deep/ and ::shadow. I know, performance concerns, blah, blah, but at least that worked like a charm.
Possible solutions I find impractical:
How to style slotted parts from the parent downwards
::slotted CSS selector for nested children in shadowDOM slot
How to access elements inner two shadow dom
Example HTML where all nested elements would be styleable with global CSS:
<body>
<o-app>
#shadowDOM
<o-header exportparts="username:o-textinput__username,action-ok:o-action__action-ok,o-action__label" part="o-header">
#shadowDOM
<o-texinput part="username">
<o-action exportparts="label:o-action__label" part="action-ok">
#shadowDOM
<div part="label">
Then I can finally style the label div by selecting it with:
::part( o-action__label ) {}
Now tell me that having to specify every single part of all descendant elements in the parent elements is not a total mess!
Playaround on Codepen: https://codepen.io/5180/pen/jOyQNYq?editors=1111
Now in 2021 I would rather use light DOM only instead of forcing the shadow DOM to behave like its counterpart, because there is currently no easy method of piercing through the artificial boundary. It was in the spec – ::shadow and /deep/ – but got removed, so deal with it. ::theme() is not ready yet, The ::part() selector is useless for deep styling as I pointed out in my example.
Just use the light DOM (innerHTML) of your custom element to avoid deep styling/theming issues.
Instead defining:
<div id="my-custom-element-101"></div>
I wrote:
<my-custom-element-101></my-custom-element-101>
But didn't go further to extend HTMLElement and define it. This way I get some enhanced readability and don't need to do any further coding.
Is there any potential downside to this practice?
There's no absolute downside for that, as soon as you use valid custom element notation (i.e. a name with an hyphen "-").
In this case it's just an unknown custom element.
Of course if someone else decide to define a custom element with the same name you could get into some troubles but if you own the entire code of the page it can't happen.
Also note that, in your example, your tag <my-custom-element-101> is seen as an inline element, not a block.
I want to build an external GUI that operates on a generic HTML piece that comes with associated CSS. In order to enable some functionalities of the GUI, I would need to create some "meta" HTML elements to contain parts of content and associate them with data.
Example:
<div id="root">
<foo:meta data-source="document:1111" data-xref="...">
sometext
<p class="quote">...</p>
</foo:meta>
<p class="other">...</p>
</div>
This HTML is auto-generated starting from already existing HTML that has associated CSS:
<div id="root">
sometext
<p class="quote">...</p>
<p class="other">...</p>
</div>
#root>p {
color:green;
}
#root>p+p {
color:red;
}
The problem is, when adding the <foo:meta> element, this breaks CSS child and sibling selectors. I am looking for a way for the CSS selectors to keep working when encapsulating content in this way. We have tried foo\:meta{display:contents} style, but, although it works in terms of hiding the meta element from the box renderer, it doesn't hide it from the selector matcher. We do not produce the HTML/CSS to be processed, so writing them in a certain way before processing is not an option. They come as they are, generic HTML documents with associated CSS.
Is there a way to achieve what we are looking for using HTML/CSS?
To restate, we are looking for a way to dynamically encapsulate parts of content in non-visual elements without breaking child and sibling CSS selectors. The elements should only be available to DOM traversal such as document.getElementsByTagName('foo:meta')
If I understood your problem correctly.I would suggest using the space between the grandparent and the child instead of a '>'. Also your selector is an id and not a class.
The selector you have put in selects the next level child that is the children. But adding the space in between enables you to select grandchildren too!
so you have do is this
#root .quote {
color:green;
}
Let me know if this helped.
A working css is here
So, after much fiddling and research, we came to the conclusion that this can't be done, even with ShadowDom, as even that would require massive CSS rewrites that might not preserve semantics.
However, for anyone stumbling upon this question, we came to the same end by employing the following (I'll be short, pointers only):
using two comments to mark where the tag would start/end, instead of an XML tag (eg. <!--<foo:bar data-source="1111">-->...content...<!--</foo:bar>-->)
these pointers work more or less like the markup equivalent of a DOM Range and they can work together with it.
this approach has the interesting advantage (as opposed to a single node) that it can start and end in different nodes, so it can span subtrees.
But this also breaks the XML structure when you try to recompose it. Also it's quite easy by manipulation to end up with the range end moving before the range start, multiple ranges overlapping etc.
In order to recompose it (to send to a next XML processor or noSQL XML database for cross-referencing), we need to make sure we avoid the XML-breaking manipulations described above; then, one only needs to convert encapsulated tags to regular tags by using string manipulation on the document (X)HTML (innerHtml, outerHtml, XMLSerializer) to get a clean XML which can be mined and cross-referenced for content.
We used the TreeWalker API for document scanning of comments, you might need it, although scanning the document for comments this way can be slow (works for us though). If you are bolder you can try using xPath, ie. document.evaluate('//comment()',document), seems to work but we don't trust all browsers comply.
<div class="thumbnail-popular" style="background: url('http://images.gogoanime.tv/images/upload/Go!.Princess.Precure.full.1812487.jpg');"></div>
I am trying to get the url component of this div class but I seem to be unable to fetch that specific data in the div class.
I have looked into making use of attributes but my attempts have been unsuccessful so far.
Usage of this CSS selector is through Kimonolabs.
div.thumbnail-popular should get you the element you're looking for — unless there is more than one such element, in which case you will need to narrow down your selector.
For example you will need to find out if this particular element belongs to a specific parent, or is the first, second, ... nth child, or any other information about the surrounding elements in the page that you're working with.
The background URL is in a style attribute on this element, so you will need to extract that attribute as described here. However you will still need to parse the declarations inside the style value in order to get the URL; I am not sure if it is possible to do this through kimono as I am not familiar with it (I'm not sure what its advanced mode really does, and it's difficult to tell from the lone screenshot that is provided in that help article).
My coworker is telling me I shouldn't use id's for paragraph tags...
I think it's the way to go if you know you're only using that kind of paragraph once on the page.
He also says that all elements on a page should only use class and not id, unless you are defining a header, container, or footer.
I am fresh out of college and I learned to use id for things that will only show once on a page, while using class for things that will show multiple times on a page.
Which way is proper?
I'd say it's fine as long as you know that the paragraph will only be used once on the page.
An example might be a piece of company info that you want to appear on multiple pages but be styled in a particular way. Giving that an id singles it out as unique and allows you to style it as such.
The class attribute should be used for styling a number of controls in a similar way (i.e. all those that belong to that class). For example, report totals might always need to be large and bold, so the encompassing tags would be given a reportTotals class. There might be more than one report and more than one total per page, but they should all look the same.
Yes, it's OK. Every DOM member can have an ID. There is nothing fundamentally wrong with a <p> tag using an ID.
Now, for applying CSS may be the case that is better for you using a class attribute instead of an id in <p> case because you might want to apply that style to several paragraphs. But it's just a matter of convenience.
From a semantic point of view, I would say that if the ids help split up the document structurally then using ids makes a lot of sense. For instance, you may have:
<p id="beginParagraph" ...> </p> and <p id="endParagraph" ...> </p>
that help easily identify and locate your beginning and ending paragraphs. Keep in mind that you should not have duplicate ids however, and the example above could easily get out of hand if you have many paragraphs and wanted to add an id for each.
Check out this article on Classes on Ids for other reasons why one might be better over another:
http://css-discuss.incutio.com/wiki/Classes_Vs_Ids
Use an id to refer to a specific element. Use class to refer to all elements of a specific type.
I think [you should use id on a paragraph tag] if you know you're only using that kind of paragraph once on the page.
You shouldn't use id just because you only happen have one of them on your page. You should use id when you want to be sure to only affect that one specific element, both now and in the future when other people add more paragraphs. If you have a specific "kind" of paragraph there is nothing wrong with using a class to represent this, even if that class currently only has one member.
I find the use of ids for HTML elements, specifically paragraph tags, is very useful when running automation tests using tools such as Selenium or in my current project that uses AngularJS, when running end-to-end tests using Protractor. It is much easier to make expectations by element ids than using class selectors.
Yes, it is perfectly okay to use the id element for the paragraph element. Just make sure you specify which paragraph if you are using more than one.