In my project i have a lot of css styles. Some of them are never used (not anymore). I check this manually with eclipse: i select text and then with "Search -> Text -> Project" i can find, if this style occurs only in the stylesheet or also in java files. Is there better way to check, which styles are currently used in my GWT project?
edit:
#Igor,Keith: thanks for the hint, but i'm not using the CssResource to insert my css file. Instead i use my index.html. And i want to remove the unused styles just for better overview. CssResource is not exactly, what i'm looking for.
If you use CssResource to inject your css file, GWT will handle pruning unused styles for you (just like it does in the case of unused code). It will also by default obfuscate it, so watch out for that. For a comprehensive explanation see the docs.
CssResource works best in combination with UiBinder. I'd recommend both - you even get cool features like compilation-time errors when you are missing a CSS style in your UiBinder xml files (or you misspelled it), among other cool/awesome things - again, check the docs for the full list.
GWT 2.0 added a feature called ClientBundle, which is a generic mechanism for bundling resource files such as images and CSS. If you bundle CSS files with ClientBundle (via the CssResource class), the GWT compiler can actually generate errors on unused CSS selectors.
The documentation is a bit rough, but here is the relevant part of the GWT docs:
http://code.google.com/webtoolkit/doc/latest/DevGuideClientBundle.html#Strict_scoping
In addition to detecting missing selectors, CssResource also supplements CSS itself, letting you use constants and conditionals within your CSS, even allowing you to specify different styles depending on which browser is being used. It also provides obfuscation and minification, among other things.
I'm still looking for a better solution. To solve the problem i've used the linux terminal instead eclipse for the search and that was faster.
Related
For an organization I work for, there is a common stylesheet that all web applications are supposed to use.
For example, they expect some elements to be in thead.table-sortable th.table-sortable-sorted-down a:after to add a sorting icon. Now, in an Angular application, I use a component library (primeng) that has a simple element that just has the class .pi-sort-up for the same thing.
How can I map / copy /use part of the organization css into my application's css, to just copy the interesting stuff without requiring the complicated nesting on component (which I have no real control on anyway)?
We could use css, sass, or even dynamically generate css rules in javascript. I'd prefer avoiding changing the DOM at runtime for all matching components, as it could be quite dynamic.
EDIT: A build-time solution (e.g. with sass) isn't the preferred way, but could be acceptable if nothing else.
If the company style sheet is readonly for you, there is not much you can do at all. You will have to load the whole document wherever you need some parts of it. A possible "workaround" to avoid that would be to write a backend program (in PHP or node.js) which opens the company style document and looks only for a specific CSS rule which it then copies and pastes to some other style document.
However, this approach would be very dynamic as well and you needed to execute the backend script with each request, for the original company style sheet could change always... If your company could agree, you should use a preprocessor like SASS or LESS and define a structure for the company style, dividing it into several documents that can be loaded on purpose.
I'm writing a Chrome extension that injects HTML into a displayed page. I want the injected HTML to have it's own style, protected from the CSS that may be present in the host page.
I've tried using conventional CSS, and still suffer from style corruption from the host page.
After watching the Polymer presentation from I/O 15, I was wondering if there are any new, Chrome-specific techniques that I can use to achieve this?
What you will want to look into is shadow-dom. This will enable you to create a widget/component (which would be your injected html). This would mean that the DOM tree for the widget/component is encapsulated and no external styles from the page will affect it. There is a good article on html5rocks covering this. You may also want to look into WebComponents. Bear in mind that this functionality is only available in the latest browser versions.
Two things that I currently use at my place of work are:
css-modules
react-css-modules
I use react at work, hence react-css-modules, but css-modules should work in your case. It's not Chrome specific, but we use them within the context of each component we build. Basically, like the docs state, a class of row would become something like table__row___2w27N. The breakdown of the built name is the filename of the CSS than the class name followed by a base64 hash of 5 char. I hope this helps.
One potential downside is Webpack would be required.
Here is an example of our component folder structure:
- component
- Component.jsx/js
- component.css/scss/sass
- component.test.js
As stated by Rob Dodson, style tags are now unavoidable with Web Components. I am trying to find a way to use LESS with this new tecnhology without having to paste the compiled CSS in my HTML document everytime I change something in the LESS file . Is there anyway to achieve that?
I am using Polymer.
Thanks!
Laurent
You can make the client compile the LESS to CSS , you should definitely take a look at this :
http://lesscss.org/#client-side-usage
It is advised to compile it yourself to css in a production environment though !
Doing this client-side hardly seems like the corrent solution, especially at scale. For instance, do you really want 1000 web components in your app all including LessCSS and compiling on the client side?
Just compile server-side and include the compiled version in your html import. Apps like DocPad, make this a lot easier. For instance:
src/documents/components/my-component/my-component.css.less is your source file, and is compiled to out/components/my-component/my-component.css, which is accessible at /compoennt/my-component/my-component.css.
We use this workflow to also make use of javascript pre-processors like coffeescript, as well as post-processors like css auto prefixer, and bundlers like Browserify. See: https://stackoverflow.com/a/23050527/130638 for more info.
Simply compile your less and embed the generated CSS file via good old link tag.
I don't think that rob wanted to say that using style tags is the only way to go. You can still link to external stylesheets as you always did.
Why don´t you compile on server side using php compiler? Have a look here - http://leafo.net/lessphp/ -
To let you know, i´m using this compiler on my projects, on the server side without any kind of problems!!!!!!! :) IMO, it´s better to have the compilation work on the server side. I´m not totally 100% sure, but i think IE8 don´t recognize text/less
The way I have done this before is have individual .less or .scss file for each component and have it compile into the individual .css file which is then called into the respective component file. and finally vulcanize everything into a single file.
Incase you want to use a single CSS file, then use //deep// combinator or ::shadow pseudo elements in the CSS.
If you able to create the custom elements without using ShadowDOM then you can simply have all your less merge into a single CSS.
Honestly speaking I was unable to create a wc without shadowDOM in polymer. There is a long conversation on github on enabling / disabling and hacking a way to create a wc without shadowDOM here https://github.com/Polymer/polymer/issues/222
One solution would be to have the preprocessor translate .less files into .css and then linking them inside Polymer components, like explained in the official documentation: https://www.polymer-project.org/1.0/docs/devguide/styling#external-stylesheets
Unfortunately this is deprecated. So the other way to go could be to have another step that wraps the preprocessor-generated css files with a dom-module: this way you can follow the Polymer way including the style module inside your components, or using the css file compiled from less if you do things outside Polymer components.
I'm using Gulp for my build process and I found this module very useful:
https://github.com/MaKleSoft/gulp-style-modules
It creates, for every .less file I have in my sources, an .html file with a dom-module wrapped around it, ready to be included in the components' styles.
I'm using GWTP and Maven, i have a .css file which specifies different styles for the widgets in my application, and my application has some sub modules also so my question is how can i make my css available for the whole application ?
how can i make my css file available for sub modules also?
To benefit from GWT's CssResource advantages (like you do when you say <ui:style src="abc.css"/>) you'll have to use a ClientBundle.
ClientBundles are basically Java classes that represent CSS and other resources. Without GWT, you'd put your CSS and images directly into your HTML code. With GWT, you want to do everything through Java... and that means using Java design patterns.
As you know, you can't just use a global variable in Java programs, and the same is true for css with GWT. You'll have to pass your CSS classes to your libraries as Java objects. You can use static references in many places, but I prefer to actually pass in CSS objects to maximize flexibility later, and I think that's an established best practice.
TL;DR:
Figure out ClientBundles and do as you'd normally do to pass Java variables between libraries.
Hey, I'm developing a GWT app and now facing the CSS part. I read a lot about this topic at the official site but still have a few questions and hope someone can give me a hint.
When I'm using CSSResource the css styles will be compiled into the code - right? So it's not possible to change it without recompile the app. But what I wanna do is to have the styles be editable from "outside".
So what is this CSSResource for, since you can't just change a color or an image without compiling the app again?
Whats the best way to use CSS since there are a few ways (.css file, CSSResource, styles in ui.xml) to do this?
My thoughts are now, that I'm using only the normal CSS file to handle all my "changeable" stuff and add this file to the head, since I can't see the advantage of this CSSResource thing. Hopefully someone can help me with that. Thanks.
It all depends on the way you work with CSSes - if you need to apply some small changes, first test them "live", in Firebug/similar tool. During the designing phase (when you don't have a finalized view of how you want to style your application yet), you might want to work with normal CSS files, but as soon as the general style clarifies, you should switch to ClientBundle/CssResource.
Why? Let me answer, by writing up some thought about the goals listed on CssResource's documentation page:
Primary
Compatibility with non-GWT-aware CSS parsers (i.e. any extensions should be valid CSS syntax)
This does not imply that the stylesheet would necessarily make sense if you just displayed it in a browser - meaning, we want to only use valid CSS syntax, not some syntactic sugar that's gibberish to other parsers - might not be that important from your point of view (although, as a result, you don't need to change the syntax of your existing styles)
Syntax validation - very important point, IMHO. You get stuff like checking for missing (possibly misspelled) CSS classes, syntax errors, etc. - something that had to be (usually, painfully) tracked down via some browser specific developer tool (Firebug). Here, you get those errors early, during compile time (or even faster, with the help of the Google Eclipse Plugin).
Minification - this is not your run-of-the-mill minification, you get also selector and property merging. See the next point too.
Leverage GWT compiler - if a CSS class is not used (the GWT Compiler can make such a distinction, since it has the overview of the whole application), it is pruned and not included in the compiled code. How many times have you found CSS classes that were left there after some design changes? This takes care of that (see also the CSS modularization point)
Different CSS for different browsers, automatically - since the CSS generated this way is included with your JS code, it can (and is) optimized for the target browser - no need to include lengthy IE hacks in every permutation!
Static evaluation of content - already mentioned it before
Secondary
Basic CSS Modularization
Via dependency-injection API style - you can inject CssResources as needed (for example, to facilitate custom themes in your application)
Widgets can inject their own CSS only when it's needed - this is one of my favorite points, although at first I didn't see its significance - you divide your (usually) huge, monolithic CSS file into small modules, one for each Widget that uses UiBinder (which in turn uses CssResource internally) plus probably one global CssResource for application-wide styles. This results in a much cleaner, easier to maintain CSS styles (at least, in my experience). This also means, that if your code doesn't use that particular Widget (maybe because you've used ocde splitting and it hasn't been loaded yet), you won't download those styles.
BiDi (Janus-style?) - bidirectional text support, haven't used it but the docs look promising :)
CSS image strips - automagical image sprites generation - what more can I say? ;)
"Improve CSS"
Constants - I've always missed this feature in the CSS specification - when you change your primary colour, you have to find & replace it in the whole file (possibly leading to some errors, where you want to use the old colour in some places) - this makes it more intuitive, IMHO, by introducing constants (via valid CSS syntax and without any runtime penalty)
Simple expressions - you should skim through the docs to see the possibilities there, really cool stuff
Tertiary
Runtime manipulation (StyleElement.setEnabled() handles many cases) - on stylesheet injection (during runtime), some values are evaluated - this allows for skinning, etc.
Compile-time class-name checking (Java/CSS) - already mentioned the (obvious) benefits of this
Obfuscation - this one is really cool too, the GWT Compiler can safely obfuscate all the styles in CssResources, because it has the overview of the whole application - thus, name clashes are impossible. This means that you can use long (but not too long ;)), meaningful class names, without worrying how that will impact the size of the application - it will all get obfuscated to nifty, short (even 1-2 character long), random strings. This also enables you to define a .warning style in two Widgets and the compiler will understand that these two styles are in different namespaces (different Widgets) and thus should be treated differently (that is, obfuscated to different names).
About style injection
The class StyleInjector allows injecting styles at runtime. Additionally, the CssResource allows (at least according to the docs, I haven't tried it yet) for runtime substitution. For example, when you inject a CssResource containing the following:
#eval userBackground com.module.UserPreferences.getUserBackground();
div {
background: userBackground;
}
The userBackground will get evaluated and injected (as opposed to constants, which are resolved at runtime).