Please forgive my ignorance to all things front-end development - but I was wondering if I have a style that targets images, for example, and then after an arbitrary amount of time a user inserts an image into a content editor (i.e. the image is introduced to the page a long time after the page has been rendered) - will the css style apply to this image? Or is it 'too late'?
Yes, try loading some content with AJAX what should have styles applied. Those will be applied.
But: As #BoltClock pointed out, some older IE-versions don't like this, I suggest you take his comment into account.
Related
I've been playing around with Filament's Critical CSS (https://github.com/filamentgroup/grunt-criticalcss) and have a question about it's usage.
As I've been using the tool, it generates a "critical" sheet for every page I point it at so that I can inline those files into my HTML via a <style> tag in the <head>. This all makes sense.
However, once the user visits any of my sites pages, they'll have the main sheet fully cached. At this point does it make sense to stop inlining the CSS, as the user already has the CSS loaded, and instead link to it via a traditional tag?
If you're certain that the user has the stylesheet cached this would be a valid approach, assuming that parsing a cached stylesheet or inline styling of critical css will take the same amount of time.
You however can't be certain that it exists in the users cache. As the critical css also exists in the stylesheet this isn't a problem, but it will make rendering the page slower.
The only way to know when it might be useful is to parse your access logs, try to find how often the stylesheet is also requested when a specific page is requested by a specific user. Using that you can create a probabilistic model on when it's useful to inline critical css. This seems like too much work for a small gain. I'm guessing that using inline critical css is most useful for landing pages or pages that go viral.
Yes, Inline CSS usually now is only needed when you want it to take complete precedence over an external style-sheet you do not control of a .JS file that makes unwanted changes which overwrites your style-sheet as well. Doing this also helps with performance, band-width, etc., etc.
I am going to answer here as it is best to do so instead of in comments.
The problem that you're having is strange in the matter that you are wanting to cover all possible bases with two separate, but tied issues.
Firstly, your performance gains. Since you want to have higher performance doing inline styles is the technically correct answer. There are some minor gains because you are not doing a request. All requests that go out take time and depending on the time it takes for the server to communicate each request you will see a possible performance drop. This is why some requests that are much larger are considered excessive and Google generally informs you to sprite the image or some other form of connection.
The other part is you want ease of accessibility and want to be able to update quickly which is what would be provided by an actual CSS file. You would need to at some point call this CSS file so that it can be cached into the browser as you expect. You can do some cookie checks and depending if the user has been to the site or not they will have a specific call, but here is the major issue:
At some point you HAVE to actually load it. You will have to make the call. Whether it be on the first load or the last at some point for it to be cached it actually has to be retrieved. You will spend a ton of time checking each variable if they don't have it they will need to have the style sheet loaded. If you are already required to load it at some point then it comes down to never really needing to do inline styles. And if you have inline styles you never really need to load it.
You could potentially do a PHP include of the file and have it pull in that way. You would just include the file between a style declaration and it would populate the CSS that way. I wouldn't say that is the best way to do it, but it is possible. It can be done. I still stand by saying inline is not the right way to go. Technically yes it can help. Reality... no. I have not seen it be beneficial ever in my time. If someone wants to show me one that is fine, but I doubt I will use this practice unless it is last resort.
Keep in mind this final thought. Most cases inline styles are styles that are meant to be final styles; ones that end overwrite original external style sheets that we as developers can not edit ourselves (or do not want to change for other reasons).
Google is great and they provide great research, but research is meant to be considered and not always used exactly as they write. It is to provide insight. Not usually a guide into the way.
I've developed an instant messaging component using AngularJS that adds instant messaging functionality to any web page. The component is fairly complex it's style sheet runs to about 800 lines.
I'm having a problem when the component is deployed to third party websites. Sometimes the CSS from the host website affects the styles of the chat widget.
The screenshot is used when the component is added to a fresh Wordpress install. You can see that the button text is overridden by the Wordpress style to be upper case.
The problem is this component will be deployed to tens of thousands of websites so it wouldn't be practical to solve each small issue on a case by case basis. It would also be impossible to know if these changes would have a knock on affect to another website.
The approach I'm currently considering is to create a very comprehensive reset stylesheet - I'd override all possible styles on all elements. That would give me a fresh canvas to start with.
This seems like a pretty onerous task so I was wondering if anyone had devised a better solution?
Note:
An iFrame isn't possible because the chat has to overlay the original web page
Like Luca suggested, using a namespace is the correct answer.
While you could use !important or an iframe I dislike both of those answers and here's why.
Why you shouldn't use !important
Your goal is to create CSS that can't be overridden. Using !important
doesn't actually solve that problem. I could still override your
styling by using the same specificity that you have. It is however, a pain to do.
Mozilla specifically recommends that you don't do it.
As you've said yourself, this could be used on 100k+ websites. The likelihood that you're going to override someone else's styling is pretty high. Using !important is going to ruin their day. You've effectively taken the cascading out of CSS. As a rule, use the least amount of specificity that you can comfortably get away with. This makes everyone's life easier.
Why an iframe is not the answer
I'm not nearly as opposed to using an iframe as I am to using !important but there is some negatives that you need to be aware of.
iframes give control to you (the plugin maker) at the cost of the user. e.g. The user has no choice in being able to match your iframe's responsiveness with their site. It's entirely likely that some user is going to have a specific breakpoint that isn't going to play nice with your plugin.
Your styling is impossible to override. This point could be seen as a positive for you but I find that it's a negative to the user. Being able to style the colors of your plugin helps make the plugin a part of the site. It's a guarantee that your plugin's colors won't mesh well with some sites. Letting the user change the colors is a must for me.
Using Namespaces
The idea is pretty simple. Let's say that your app is called SuperIM2000. All you do is make sure that there's a container with the same class name and that you use it to target your styling. This has the added benefit of allowing you to use very simple class names e.g. button.
HTML
<div class="superIM2000">
<input class="button" />
</div>
CSS
.superIM2000 .button{
color:#000;
}
As you can see, the specificity is very low. However, the likelihood that you're going to override someone else's styling is extremely low. This has a benefit to the user as well. It's possible that the button class is already used in their site and it can take advantage of any inheritance that you haven't overridden.
namespace your classes to avoid any possible clashes
reset all styles (super tedious I agree)
if you really want to go hardcore, I would not recommend any of the below but they are available options:
use !important
use inline styling with the above
Why is the editable html moved into an iFrame? I analysed different editors (TinyMce, CKEditor, etc) and all move the editable content into a separate iFrame which they lay over the original text.
What is the technical reason for this. I experimented with the contenteditable="true", which is the base of all this editors too, and didn't find a reason yet to do this.
I'm CKEditor core developer. Not for a long time - just for last half of the year, but I've learnt a lot about why we use iframed editable :)
Styling - content of the iframed editor doesn't inherit styles of the page. This is extremely important, because we cannot reset styles (sic! CSS really sucks). What's more - in iframe we can freely add our own styles which is helpful too.
Only in iframed editable we can work on entire page with head, metas, body styles, title, etc. Some of our users need this.
Browsers have very buggy (and incomplete) impls of contenteditable. E.g. guess what will happen when you paste list into the editable which is a <h1> element on Firefox (you can check that in this editor - http://createjs.org/demo/hallo/)? It will leak out of editable area and become a non-editable element. We have to handle these cases manually in the editor and this is really hard work :).
I'm not sure about this but I believe that designMode wich allows to switch entire document into the editable area had been first and contenteditable came later. So the reason may be historical too - it's hard to switch from one approach to another.
Probably there're more reasons why we use an iframed editable. I'll update my answer when I'll learn them :)
From the tinymce froum
Hi Zappino!
It is the very nature of editors like TinyMCE to use an IFrame because
in a frame you can modify any part of an HTML document to suit your
needs without breaking anything in the main page's document.
Especially if you want to edit a complete HTML document including the
parts between and you won't be able to do so without an
IFrame.
Cross Domain Skripting will occur if you store TinyMCE's files on a
different (sub-)domain than the page from which you embed the editor.
Show us a test scenario of your installation with which you are having
trouble and someone might be able to help you out!
Greetings from Germany (back to Germany )
Felix Riesterer.
I have a more general design question relating to css and websites. I know that it is good computer science to normalize code as much as possible and avoid duplication. So it would stand to reason to me, at least in theory that one would do the same when organizing stylesheets for a website.
So when I started on my most recent website I started out with this same philosophy. It worked ok for my first few pages and while I was only testing in firefox...
However as my site grew and as I added pages, multiple layouts (and browsers) I found this philosophy broke down really quickly. Ultimately over time I have moved to the following approach:
I have a very limited top level css file for each master page layout in my site, it contains classes for well known styles across that layout as well as css for the master page.
I keep specific css styles for each page.
I keep specific css styles for embeddable page elements / controls
I ended up taking this route so that I could trust that changes on one page wouldn't accidentally break other pages in the site resulting in a lot of regression bugs.
What do other people do when approaching this? Is this a good / bad approach... I do see cons to this approach, some pages are very similar so making a significant change means changing more css code, I also feel that the pro's outweigh this on a daily basis.
What do other developers think about this philosophy? Good? Bad? Just curious really...
To me its one of those situations where I weighed the difference between my ideals (I try to keep very tight code), and the frustration of changing requirements on one page breaking 20 other pages because I changed a div width by a few pixels (upsetting a float on another page for instance).
Thanks for your input
Just like any other type of code, if you are duplicating your CSS code all over the place, you are asking for trouble. Maintenance is going to get harder and harder for you as time goes on.
The best way to not have issues with a change on one page affecting other pages detrimentally is to have a style guide that drives your UI layout and design. If your style guide defintes the HTML and CSS classes to use for a given design element, then they will all always be displayed the same across all pages. If a specific page's element needs to be changed, you change the HTML to use a different class and then build new CSS for that class (and add it to your style guide for reuse). The style guide also allows you to make sure that your HTML is uniform across all developers working on the site, which means even less of a chance of CSS changes causing problems as you do more development.
Another point you need to remember with CSS is that every one of those .css files you create and reference on a page is an HTTP request. If every page and control has its own CSS file, you are really hurting your users' experience on the site by bogging down the total request download time for every single page request. It also makes it less likely for their browser to cache the .css files because the cache has a limited amount of space, so if you keep filling it with more and more .css files, they are going to get dumped from the cache more quickly. Yes, you can combine .css files programmatically in a handler so your page only makes one request per page, but then you have additional server overhead and the caching issue still remains (unless you have a single request for all .css files on your site, which defeats the purpose of what you're trying to do here anyways).
I am making a Google Chrome extension to change the appearance of the (Webkit) scrollbars. I want them to "blend in" with the rest of the page. What I was thinking of doing is reading the page's background colour and assigning it to the background-color of ::-webkit-scrollbar-track-piece. Is this possible?
Also, is it possible to tell if the scrollbar I'm changing is one of the main ones (as opposed to an in-page one).
P.S: I'm really a beginner when it comes to web development.
With a content script you can read the CSS data, and then inject the proper styles on to the page.
As an example, the following will style just the "body" scrollbars:
body::-webkit-scrollbar {background-color:#000}
No, you can't do it in pure CSS, You'd need at least Javascript to accomplish this, but it's probably impossible in Chrome, and for good reason.
The last time I remember this being possible is in IE6. It's a risky idea in general to change user interface elements that are common to all applications on a platform, because the user has to relearn how to use your application.
Think of the best-designed sites on the internet. You probably don't spend much time wishing their scrollbars blended in better. It's just unnecessary, and the downside (confusing the user) far outweighs the upside (possibly making the scrollbars slightly prettier).