We have a medium size application with around 30 views. We have many CSS files laying around. Some are specialized (popup styles) but the rest contains style for different parts of the application, in addition of the style embedded in the *.ui.xml and it's start to get pretty messy.
Is there any guideline on how to structure the styling in a GWT application and in a web application in general ? How do you structure yours ?
There are two schools of thought on this. Some developers prefer to use CSS Resources.
My strong preference, after 7 years of experience with GWT and multiple projects, is to have a single external CSS file for all styles. I even do not include any GWT stylesheets (including DataGrid styles) - I copy their content into my CSS file. These are the reasons for this preference:
CSS is called a cascading style sheet for a reason - it is build around inheritance. A professional web designer builds an app design starting from the very top (html, body elements) and defines the rules for the entire application: font or fonts to be used, color palette, standard margins and paddings, standard grid (columns width), etc. These rules must propagate throughout the entire app. Once developers start defining their own styles at the view/widget level, it's nearly impossible to ensure any design consistency across the app.
Even more importantly, when the CSS rules are split between many different sources, it becomes very hard to predict their interactions. Why is this element not positioned correctly or has the wrong font size? Is it because I used the wrong selector in the widget CSS, or is this because some other rule from some other CSS resource overrides or conflicts with it? Now you find yourself jumping back and forth between different stylesheets trying to make it work.
Even if you do find a source of the problem and fix it in one of the stylesheets, now you have to check how this change affected other views and widgets. Making a change at the top of the DOM tree can impact every element at the bottom (again, it's cascading!). Often it's not easy to anticipate this impact in every browser possible.
These considerations become even more important when you try to make your app design responsive and make your app adjust nicely to different screen sizes. What happens to your view or widget-level CSS when you add a media query in your main CSS file?
Another important point is the speed of development. If you use a professionally designed CSS file, you almost do not need CSS at a view or widget level. When I add a new form, for example, I never need any CSS - I just throw a sequence of labels and input widgets and they all suddenly look right and they are positioned correctly, because the rules have been already set and they apply to all forms, input elements, labels, etc. in the app. I do not think what font size or color to use in a widget. I just use a <h2> header, for example, and it has one color in a light skin and a different color in a dark skin, and it changes its size and margins according to the screen size.
Finally, moving as much CSS away from the widgets makes it easier to reuse them in new projects. Using the same example, if a header does not have a font-family, font-size, color or margins specified in a widget, it will take these values from another app's CSS file (which may or may not be the same rules as the contributing project's file). So you can reuse the widget in a new project without touching its code, which again speeds up the development process and makes maintenance so much easier.
To summarize, a single CSS file makes it easier to enforce style consistency across the entire app and maintain code, and considerably speeds up the development.
Related
I am studying CSS best practices and methodologies like OOCSS and SMACSS to use in a medium scope project that uses Twitter Boostrap 3 and LESS. I'm starting to get a grasp of these methods but I have some trouble to find out how to handle responsive design and CSS modules relationship.
For example let say I have a button module with all different kind of buttons used in the project (color, shape, size). How could I make the button change depending of the device. The same button should be large in mobile and a normal in desktop.
Following OOCSS I should have 2 skin classes like btn--default and btn--large. But as the HTML is the same for each device I can't switch this class in the HTML. Also using a media query in the module's CSS that would change the size of the button depending of the device size doesn't seem a good idea as I would be coupling the module with this specific need (and what if I want a normal button in mobile later?).
As an other example, I have product section module that have different possible layouts (vertical / horizontal). What if I want to use the vertical layout in desktop and the horizontal in mobile. I'm facing exactly the same issue. I can easily create 2 different submodules (product--horiz, product-vert) but I can't change them.
I could use javascript to switch classes but it doesn't feel right and would break the design with JS disabled. You could tell me that maybe the design is not right if an element is changing so much from one device to another but it would be a real limitation to restrain this.
So what are your thoughts about this issue. Is there any generalised practice used to face it?
To use your example for buttons:
Mobile is also tablet and tablets come in a variety of viewport sizes that are just as large as desktop. Media queries are not detecting features, like touch, so making a media query is only for visual at that viewport size. It's best practice to use large buttons and large click areas for fat fingers for every device unless you do feature detection with js such as .touch .btn- {big styles}. I use a little script to put .no-touch and .touch on my html, but I don't bother making larger areas just for .touch. I make them for everything if at all possible.
Your base button style should be defined in the button module in your 'modules.scss'. Apply any styles here that will transcend across all buttons. Then handle the differences in your smacss 'states.scss' file (compiled last). You should have one 'button' section in your states file in which you handle media queries and unique classes that will alter the appearance of the button. Hope that helps, I can elaborate more if you need.
I am using Flex 4.9. I thought that with the newest SDK, they finally made Flex and CSS components tags to work. But they did not.
I tried to set horisontalAlign and verticalAlign of spark HGroup vie CSS style, so I could manage it smoothly and save some code typing. HGroups didnt respond to CSS style I applied, ok, I thought that at least I will set their width. It also did not work! Nor pixel width or percent value.
Does Flex CSS styling is really so limited or am I missing something?
horizontalAlign, verticalAlign, width and height are all properties of the HGroup class, not styles. Hence you cannot set these properties through stylesheets.
What you seem to be missing is that Flex is not HTML and that the same semantics do not apply. In Flex 4 we separate the content from the way it is presented mainly through a process called skinning: we declare components and their logic in one class (usually in ActionScript) and we define its visual representation in another (usually written in MXML).
With this separation already in place there is hardly any need for stylesheets. In fact, if you would put a CSS on top of that, you would kind of artificially try to separate the layout into two separate entities which doesn't make much sense. Not to mention it would make the code much harder to read.
There is a case where CSS comes in handy though, that is when you want to apply a certain visual style throughout your application. A Button could have five different skins, but through CSS you could set the font color of all five to a specific color without repeating that in each skin.
I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.
I'm working on my first responsive site and have read numerous articles but can't find an explicit answer to my question.
I have created and coded 3 designs at this point. The overall site is has a fluid main column and a fixed sidebar. The header and footer are fluid. After a cutoff point it will go from 2 column to one, with some additional changes to go to smart phone size. I want one style sheet. Having read several pros and cons, since this is my first responsive site I will be making the desktop design the "default" and want to use media queries to change styles for smaller sizes.
I have several styles that won't change from size to size, and a handful of styles that do change.
Do I go ahead and do my entire style sheet for the desktop, then add the media queries at the bottom? (Before the print styles or after?) Or do I mix the media queries in throughout the style sheet, wherever the "default" style is?
Thanks!
I've been battling this about my head for a while, as well. Some of my sites have one big handheld- or print-only section at the bottom, some have the relevant media queries right after the selectors they affect. As far as I've seen, neither way has any impact on rendering performance one way or the other (if there is one, I haven't perceived it).
My answer is to just use whichever you feel is easier to read. If this is part of a bigger project, consult any team members who also work on the CSS and ask them which they prefer.
Im working on some web software that has 2 style sheets one for style (style.css) and one for layout (layout.css). Im wondering what the poing in this is (apart from the obvious) I mean some style options will effect the layout and vice versa. So would it be better to roll all css into on page to make it easier? Maintining multiple stylesheets seems very tedious.
Anybody got an opinion on this and best practice?
Cheers
PQ
I could see this being useful in situations where you want to have multiple styles whilst keeping the same layout. For instance, if you wanted to change the colour scheme at the click of a button.
I don't think I'd use it in any other situation, as by doing so you would be duplicating classes to set different styles and increasing your workload for something that's not really beneficial.
I personally like to separate style and layout in different CSS-files as you can have the same layout with different style (and vice versa) this way. Think of having a multi-client system and each customer wants a different style while the layout stays unchanged. Have those two files merged into one will create unnecessary overhead.
i think the choice depends on personal preference and on the size of the project.
when i'm working on bigger projects with other developers, i prefer to keep the styles in a separate stylesheet primarily because you can 'give' one stylesheet to the other developer and work on another and not worry about someone overwriting your styles.
the disadvantage of this is that multiple styles might appear in different stylesheets. what we generally do is have separate stylesheets for the main layout and the various sections, so the styles for the dynamic part can be edited easily without scrolling through a 3000 line stylesheet.
I do this in a simple CMS system I wrote so that I can change the style and layout independently of one another. This means I can write a new stylesheet for layout and use it in conjunction with all existing 'styles' for (in theory) no extra effort. However, sometimes it takes a bit of work to make all combinations of style and layout work properly together.
Personally, I think its a nice thing to be able to do and would keep it as it is in your system.
I guess that the idea is that you could create a new color theme by only switching the style stylesheet. If you are careful about what you put in each style sheet, it's definitely possible to use it that way.
It might have an application in some rare cases, but generally it will just make it harder to work with the CSS. I have tried this for a site where we have multiple themes, but I ended up merging the stylesheets again after all.