I tried my website (http://fnndsc.github.io/fnndsc.babymri.org/) on the latest canary and many things are messed up.
More importantly, the style is not propagated down to sub-elements anymore. I read around but couldn't find the best pratice to handle that.
How can I tell my polymer element to use the style from it parents.
Is there a special flag to turn on?
Up to Chrome 34 it works fine but 35/36 appear to be broken.
Thanks
Chrome 35 unprefixes the new Shadow DOM implementation (blog post) and turns it on by default. Some of what you're seeing could also be differences between native Shadow DOM and the polyfill shimming.
Without having the codebase to look at, there could be any number of things. There have been many updates to Shadow DOM's styling features in the last few months.
Things to note from what I saw on your site
#host { :scope {display: block;} } -> :host {display: block; }
move stylesheets an element relies on into the <polymer-element>.
applyAuthorStyles is gone. If you were using it, the only way to take on styles from the outer page is to use ::shadow, /deep/, or include shared styles in the <polymer-element> the needs it.
If you're using <content> and distributed nodes, make sure you're using the ::content pseudo element
Here are some up to date resources for styling:
http://www.polymer-project.org/docs/polymer/styling.html
http://www.polymer-project.org/articles/styling-elements.html
Related
I am developing a website in Angular2. In the css for all of my components, I am making use of the :host selector. The css there is brief and more or less identical in every component:
:host
{
position:relative;
top:60px;
background-color:black;
width:100%;
}
Most of my components are dynamically populated with data retrieved from a database, so the host element should grow with the content dynamically placed inside of it. This works as intended in both Chrome and Firefox, but not in Safari. In Safari, the data is loaded properly, but :host doesn't grow, and as such, the black background color just cuts off at a certain point as you scroll down the page. I should mention that the version of Safari I'm using is 9, which is certainly outdated, so for all I know, this may not even be an issue in more recent versions, but this still has to work in older versions for backwards compatibility. Also, I've not yet tested in IE or Edge, so I'm not sure if this is an issue there or not.
So I'm just wondering why :host isn't growing with its content in (at least this older version of) Safari and if there's a way to fix it? And I know I can just use a wrapper class in each of my components, put the background color in there instead of :host, and that will work(I tried it), and that's what I'll do if I have to, but I just wanted to inquire here first to see if anyone knows why I'm having this issue and if there's a way to fix it without resorting to a wrapper div/class.
Angular host elements have inline display by default. Try changing the default display of the host element:
:host {
display: block; // or any other value.
}
Inline elements ignore any height or width values.
See this for more explanation.
I figured it out. I had an old, unnecessary display:flex in a :host style for a parent component that was screwing things up. Removing that fixed the problem.
Please note: I found this question as well as this one, but both of their answers involve writing and executing customized JS. My question here is about how to wield Chrome Dev Tools (or similar) to accomplish the same thing in real-time.
I have a quasi-legacy JVM app that serves (and creates as part of its build pipeline) all sorts of nasty and messy CSS files.
I'm wondering if Chrome Dev Tools (or any other modern OSS webdev tool for that matter) has a "reverse engineering" feature in it that allows you to click on an HTML element and get a list of all the CSS rules that apply to it. And, not only that, but which rules are overriding other rules.
This way, when I need to tweak my CSS, it's less of a wild goose chase to figure out which rules are coming from which CSS files and that are actually being applied to the live element at runtime.
Any ideas?
Yes, in Chrome DevTools (F12 in Windows / Option+Cmd+I in OSX) within the Elements panel you can click on an element and see the applied CSS rules on the right-hand side. The overridden styles or classes are crossed out, and you can see the file name in which the CSS rule comes from. See below:
element.style refers to inline styles. For example, if I modified the selected element to be <div class="container" style="background-color:#000">...</div>, background-color:#000 will show up in the that section.
#content refers to the div element with the associated id of 'content'. The checkboxes that are checked on the right indicate that they have been applied with no overriding. You can check and uncheck these to play around with the styles so that you can see what you should change in your source code.
The html, body, div, span etc. allows multiple selectors to use the same styles. All the selectors in that comma-separated list will have the styles, except some may be overridden by other CSS rules - in this case, margin and padding are overridden by the more specific #content selector.
The next block is for user agent styles. These are styles that are applied by the browser, and each browser may apply different ones. This can be a problem if you have more specific rules defined yourself. Many people use normalizers to make sure things remain consistent among browsers. Check out Normalize
The inherited section shows all the styles that are inherited from parent styles. In this example, the text-align: left style was applied from the .container class as that is the parent element and the #content element didn't override it explicitly.
Update
Added better quality screenshot (thanks to #SLaks)
Added keyboard shortcuts for access (thanks to #NKD)
Added simple explanations of the sections of the Styles panel on the right.
Modern browsers have an "inspector" option that allow you to select a piece of generated HTML and view the CSS applied to it. Each one varies slightly, but normally hitting F12 will get you going.
The following illustrates this issue with a trivial example I have prepared and pushed to a github repo.
I created a custom element "x-menu" (in /x-menu.html) with styling rules for the light DOM. In practice, my use case for doing so is to use CSS variables and mixins to define colors, font-stacks, etc. to be used in the document and custom elements.
I have a custom element defining document styling (in /demo/index.html) as described in the relevant part of the Polymer 1.0 dev guide, which defines some typography rules for my pages.
This works fine with native Shadow DOM in Chrome.
However, when using Shady DOM the document styling resolves to style definitions which have higher specificity than the styling in the x-menu element. This is now it appears in the Styles stack of Chrome's developer tools:
ul:not([style-scope]):not(.style-scope), p:not([style-scope]):not(.style-scope) {
font-size: 12px;
color: red;
}
.container.x-menu ul, .container.x-menu p {
font-size: 30px;
color: green;
}
I understand there are some limitations with Shady DOM and Shadow DOM polyfill (webcomponents.org simply says a known limitation is "CSS encapsulation is limited."),
There are two workarounds I can think of, neither of which is very practical:
Add a CSS class to every light DOM node (which you can see in the demo page)
This is not practical because a user of the custom element has to remember this and defeats the CSS encapsulation goal.
Apply a CSS mixin to the local style definition. When processed by Shady DOM, the CSS has higher specificity than "custom-style" at the document level.
This becomes more cumbersome and adds unnecessary overhead in developing, maintaining, and processing the CSS.
I am looking for any ideas for a suitable workaround for this issue. Worst-case, I would like to put the onus on the element developer rather than the user of the element.
Seems like a possible limitation of the style shim. Polyfilling CSS is hard! I'd recommend filing an issue on the Polymer repo with this demo.
We are working on redesigning our web-based application’s Front-end. We started with a PoC based on Extjs 6 and we are facing few compatibility issues.
These compatibility issues are related to IE8 and CSS, while it is mentioned on your website that Extjs6 is fully compliant with IE8.
CSS classes work perfectly with all Major Web Browsers (Firefox, IE11, Chrome...) but some do not on IE8.
This is an example of CSS not working properly under IE8:
Ext.create('Ext.button.Button',{
text:'Button Test',
cls: 'btnColor',
renderTo: Ext.getBody(),
});
.btnColor {
background-color: green;
border-color:green;
}
Works on IE11 :
But not on IE8 :
We would like to know if this is a known issue and is there a specific processing which allows us to handle this kind of needs.
Thank you in advance.
The element in your comment above is the wrong element - that's the inner element for the button; you want the class with an id something like button-1009 (it's going to be an anchor or div tag a few elements up in the hierarchy).
And as to why it's not working - there are going to be multiple CSS selectors that define the background colour. The default one, from ExtJS, is going to be x-btn-default-large. The full CSS class for the attribute is going to be something like x-btn buttonCls x-unselectable x-btn-default-large x-border-box.
Done like that, both the buttonCls and x-btn-default-large are equally valid choices - the browser must pick one to use. IE8 is picking the last one; other browsers are picking the first one. Neither is wrong - the ambiguity is in your code.
To fix it, make your CSS selector more specific. Try:
.x-btn.buttonCls {
background-color: green;
border-color:green;
}
This applies to buttons (which will be the only things that have the x-btn componentCls attribute) that have the buttonCls cls attribute.
The problem is JavaScript syntax.
IE8 and earlier are strict about trailing commas on arrays and objects.
Your line renderTo: Ext.getBody(), ends in a comma, but is the last item in the object. In IE8, this will fail to compile.
The solution is simply to remove that comma.
You can keep an eye open for theses kinds of things by running your code through a linting tool like JSHint or ESLint, which will flag this kind if thing up.
The answer of Sencha support team:
https://www.sencha.com/forum/showthread.php?305980-CSS-compatibility-issues-on-IE-8.&p=1118734#post1118734
This clarified a lot for me, it might help you :)
I'm working on a browser extension that adds it's UI to the pages DOM. On some pages I have the problem certain styles affect my UI. To counter this I keep my UI underneath a common root which resets most of the styles to the default value.
Sometimes I missed things which causes visual glitches in my UI. (i.e. the pages CSS file sets form { width: 80%; } so I need to add form { width: auto; } to my reset styles.
Is there a collection of styles that reset every CSS attribute to the value that is declared as default by the standard for every element?
I have come across the same problem. The usual CSS normalizers listed by the other answers does not answer the question because it is made to cancel the differences across the browser's default styles.
In the context of an extension, I needed to cancel every specific style that may exist on a random website.
I have come across this solution (I am not sure if it was possible at the time of the question, 7 years ago).
.your-container-class,
.your-container-class *,
.your-container-class *::before,
.your-container-class *::after {
all: initial;
}
So far it seems to achieve the goal by removing the differences across websites. The downside is that it resets even some default styles (ol, ul, li not behaving like lists for example).
Eric Meyer’s “Reset CSS” 2.0
(the original one)
HTML5 Doctor CSS Reset
(extends the Eric Meyer's one to improve HTML5 tags reset)
Yahoo! (YUI 3) Reset CSS
(based on Normalize.css)
Universal Selector ‘*’ Reset
Normalize.css 1.0 2.1.3
("…as used by Twitter Bootstrap, HTML5 Boilerplate, YUI 3, Pure, TweetDeck, Soundcloud, Medium, NASA, GOV.UK, Guardian, Rdio, Favstar, iA, and many others.")
There are others, but this were (and still are) the 2012’s most popular CSS Reset scripts.
I recommend using a quick Google search to find something like so: http://meyerweb.com/eric/tools/css/reset/
You can implement the reset in as-is and then if any problems arise down the road, simply add to it as needed.
Be aware that some pre-made CSS resets require a shout-out to using them.
Yes, absolutely.
There are two schools of thought to this. One is the zeroing style reset sheets, which basically remove all margin, padding and other such settings from the css. A good example of this is Eric Meyer's Reset CSS
The other approach is to set everything to roughly what you'd sensibly expect it to be, setting a reasonably looking margin to paragraphs and headings, indenting lists etc. A good example of this is Normalize.css
Some browsers also support the initial value, which sets the value of a property back to what it intially was. It's not widely supported enough to use in production, IMO.
Html5 boilerplate has an normalize.css which sets al lot of css styles to a default.
http://html5boilerplate.com/
As you are applying your styles to different pages with different unique styles, its hard to say if you will get success on removing all styles from all pages with some CSS reset.
But maybe these can help:
Normalize.css (used by many CSS frameworks)
CSS Reset by Meyer