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.
Related
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 :)
My page has a display issue on pageload with Safari (display inline-block element has a width of 0, after one JS inline style its fine). I can fix the issue with this extra style for my span element:
display: inline-block; //standard for all browsers
display: -webkit-inline-box; //safari fix
I have to use at first the standard and after that my fix. On the current browser versions it looks good for FF, IE 9-11, Chrome and Safari (Desktop Mac).
My question is now: Is the order fine or can i get with some browsers a problem?
(Maybe browsers think: "Oh I have to make the inline element (span) to display:inline-block". And with the next line "Oh I dont know that property (-webket-inline-flex), so I use the standard display: inline".)
Hopefully you know what I mean? :)
The order is fine, however you will find that any browser which supports -webkit-inline-box will use this over inline-block. This may cause issues as the way the browser-prefixed version is implemented may not reflect how the non-browser-prefixed version is implemented.
For instance, Google Chrome supports -webkit-inline-box and will use this instead of inline-block. Off the top of my head webkit-inline-box is based on the old out-dated version of the Flexbox specification.
Perhaps a better solution would be to work out why Safari is giving your inline-block element a width of 0. This isn't behaviour I've witnessed myself, but Safari usually falls outside of the production browsers I test in.
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
I've read through other questions but to no avail - I really can't work this out.
The site is (Been redesigned, so isn't relevant anymore. It used HTML5 elements, but they weren't declared as block, and IE doesn't assume that they should be.)
The gradient on the footer looks great in non IE browsers, but fails to show in IE 7,8 and the IE9 dev preview.
Any ideas?
You could try adding this to your footer CSS (in addition to your existing footer styles).
footer
{
display:block;
}
This fixed it for me under FF3.6, and I'm assuming will fix it in IE as well - The default display style for <footer> is inline which doesn't play nice with backgrounds regardless of browser. Applying block to it will treat it more like a div.
You'll also want to be careful with your use of HTML 5. Not sure of how well supported it is in all browsers. You might want to consider <div id="footer"><!-- contents of footer --></div> and applying styles to it by id in CSS instead..
I had a similar problem, but finally find the solution.
Change your format image to png.
And works fine in IE8.
This works:
#footer_text {
background: url(/media/img/gradient.php?w=4&h=160&sc=4c4c4c&ec=000000) repeat-x scroll top left;
}
I'd be careful about applying any styling to html5 elements like footer right now. They're not well supported by all browsers.
You can use them for semantic reasons, though.
If I look at the footer using IE 8's developer toolbar, I get this as the background-image definition:
url(/media/img/gradient.php?w=4&h=160&sc=4c4c4c&ec=000000); TEXT-ALIGN: center
Notice the part to the right. I'm not sure where it comes from - it's not in the style sheet. Maybe the sheet is somehow garbled. If I remove the text-align part, the footer image shows fine. The same is happening to your body definition.
try opening the file in Photoshop or similar, and doing a clean save for web as a PNG.
I'm working with some CSS (from a Joomla template) like this:
div#logo {
-moz-background-clip: border;
-moz-background-inline-policy: continuous;
-moz-background-origin: padding;
background: transparent url(../images/head.png) no-repeat scroll 0 0;
...
}
I've looked up some of those -moz- properties and they seem to be assigned their default values, and if I turn them off in Firebug nothing happens visibly.
Would there be a reason to add them to a CSS file? Are they for an old version of Firefox perhaps?
I think what's happened is someone's set a background shortcut rule and then looked at the ‘computed style’ resulting from that shortcut rule in the DOM inspector. They've noticed that setting the style also sets Mozilla's background-clip, -origin and -inline-policy properties, and tried to reproduce these rules without understanding what they're for (namely a detail of Mozilla's CSS implementation, and potentially CSS3 in future).
Certainly changing -moz-background-inline-policy would only have any effect on elements that were display: inline (which div isn't by default), and changing the clip/origin properties around the border would only make any difference if the element actually had a border.
Get rid of them.
Chances are good that these properties don't need to be there. I'd suspect that they're included to ensure consistent rendering across different versions of Firefox. I guess the answer is, if you're seeing no difference from disabling them in the versions of Firefox you're interested in supporting, take them out.
background-clip isn't supported on current Firefox builds AFAIK, so the author has probably put them in preempting a problem (though that would be odd as they are all set to the default anyway, and they haven't included the opera or webkit prefixes...)
background-inline-policy is default as continuous in all Firefoxes, and background-origin is default as padding in them all too.
I'd say pointless code for this one.
If I turn them off in Firebug nothing happens visibly.
I'm not sure on those particular attributes, but have you checked that the browser isn't using a cached style sheet?