font-display is a new CSS property that allows developers to control how fonts are rendered depending on if they load quickly enough. There's been a few articles on it:
Controlling Font Performance with font-display - Google Developers
font-display for the Masses
None of them mention icon fonts. The specification does have an example that mentions icon fonts for the block value, but to me it doesn't make sense to use that:
'block'
Gives the font face a short block period (3s is recommended in most cases) and an infinite swap period.
If I understand the specification correctly, this means if the icons haven't loaded after the "short block period", the fallback font will be used, resulting in random letters appearing in their place.
If I use the optional value, the random letters will never appear but neither will the icons if they haven't loaded in the "extremely small block period".
There doesn't appear to be a value for giving an infinite block period without swap (so it would show invisible text until and unless the font loads). Is there a reason behind this and is there a workaround?
font-display: block;
As you commented, block still has a swap period; so it's still rendered until it's loaded.
Quoting Chris Coyier:
Wanna hear something quite unfortunate? We already mentioned font-display: block;. Wouldn't you think it, uh, well, blocked the rendering of text until the custom font loads? It doesn't. It's still got a swap period. It would be the perfect thing for something like icon fonts where the icon (probably) has no meaning unless the custom font loads. Alas, there is no font-display solution for that.
Considering alternatives:
I've also been there. If you have the chance, you might need to switch to SVG for icons. It has a few advantages over font-icons: SVG is better at pretty much everything than icon fonts.
Even Zach Leatherman, web fonts expert, has opinions about it on his very famous Comprehensive Guide to Font Loading Strategies.
This guide is not intended for use with font icons, which have different loading priorities and use cases. Also, SVG is probably a better long term choice.
In trying to clean up some warnings about deprecation Gtk.Widget.modify_base,Gtk.Widget.modify_font , I found the suggested replacements, override_background_color (and the equivalents for font and colour) are also deprecated. I am now trying to work out how to provide these styles to the widgets.
The font, colour and background are for a custom TextView widget and the values for these are stored in some strings as part of some preferences, so that the user can customise colours for several different things.
For the font and text colour, it seems that the best way might be to create Gtk.TextTags with the appropriate styling, and change any instances of insert() on the text buffer to insert_with_tags(). There doesn't seem to be a "default style" concept for TextBuffers and TextTags.
However, text tags won't deal with the background for the whole text view.
The suggested approach appears to be GtkStyleProvider, but how should I go about feeding these user-specified colours into the provider?
Lots of examples load string constants like this:
string style = """
GtkButton {color:#ff00ea; font:Serif 12;}
GtkButton:hover {background-color:#3085a9;}
GtkLabel {background-color:#898989;}
GtkEntry {background-color:green; color:red;}
""";
CssProvider provider = new CssProvider();
provider.load_from_data(style,-1);
But in this case, I'll have to manually format and interpolate the strings into a big block of CSS each time the config changes and feed it back into the style, which seems pretty messy. I'm also not sure if these can be changed after loading, as there doesn't seem to be a changed signal.
I suppose the other way is to somehow inherit GtkStyleProvider and implement my own, but this seems overkill for setting a handful of colours, and there appears to be very little documentation for it.
Most GTK+ programs (even GNOME ones) seem to just do it the "old" way with modify_* and override_* and ignore the deprecations, and it's not clear to me if the few that do use CSS can change it after load.
Are these the only two options? And which one is "right"?
I am using SEO analyzer, and it tries to make me crazy.
It says that the page has inline css. I have external css, which lists reused styles, but I do not see value to put once-used "style" stuff into this sheet so I leave them in html. I particularly curious about width and height css properties, which I define for images. Why this SEO analyzer does not check for uniqueness of styles?
The value in using groups of styles that you only use once is that you may find later on that you may have to use it more than once. If you already have the appropriate set of rules, it's a simple matter of using the stylesheet selector. It also makes it easier to update later on since the styles are in a canonical place in the CSS rather than a random place in the html.
As for width/height on <img>, these should be done via the attributes rather than style, and the analyzer should not complain about that -- in fact it should encourage you to use those attributes.
There is probably a lot of subjectivity in the SEO analyzer, but one of the key points of SEO is minimizing download size. Removing style attributes does this. It does increase the size of the CSS file, though, but probably not by as much. I'm not sure what effect that has.
I'm using meyerweb css reset. It works fine, but it resets all default styles, which is in the body and template structure (<body>, sidebars, etc...) or in the main content (articles)
It's a big problem! because I've styled my text in the editor (TinyMCE), but on the main page, it loses all of the styles, such as strong, italic or (un)ordered lists.
How can I solve it? Can I tell the browser to reset all except elements which are in a table or div with a specific class or ID (such as #content)?
Thanks.
You ran across one of the downsides of using reset sheets, in that they reset everything.
You may want to consider using an alternative to full resets, such as normalize.css. The idea behind this is that instead of having all browsers start off at a clean slate, get all of them to the same baseline. From the website:
What does it do?
Preserves useful defaults, unlike many CSS resets.
Normalizes styles for a wide range of HTML elements.
Corrects bugs and common browser inconsistencies.
Improves usability with subtle improvements.
Explains what code does using detailed comments.
This may (or may not) work better for you than the Meyer reset.
The best way to go about this, in my opinion, would be to re-define the styles after the reset as opposed to removing them from the reset. While you shouldn't see any issues with the elements defined above, removing things like ul and li definitions can result in very inconsistent behavior across browsers. Redefining these elements post-reset will ensure uniformity across browsers.
Use http://CSSesta.tk
[It's influenced by YUI, Eric Meyer & Boilerplate but it doesn't interfear with any typical styling aspects]
It has 6 options commented out. (You only need to amend at least opt 3) you can leave change the others if necessary, the rest should be as expected (in general) unless you're making a website that turns into a car.(Things like forcing vertical scroll, line height, font-size are to your discretion)
The HTML5 elements in CSSesta are more up-to date "currently" than Eric Meyers & will probably become the most frequently maintained reset sheet, I know this because I will be updating it.
(Try it, & if you get any problems let me know I'll look at your default one and meet it in between)
I'm just wondering what others do in this respect:
Do you try to keep positional CSS (layout) separate from color/flavor CSS (color, background-color, background-images, font-size and family) ?
Use two stylesheets? Combine two stylesheets server-side? Abstraction layer for the CSS?
or you don't even try?
I know sometimes after working on the same web project for six months I can usually live with the positional CSS but end up wanting to change the colors/images.
I tend to keep all the CSS together, without separating "color styles" from "positional styles" or "layout styles". I find that when I often try to debug a specific "module" it's easier to have all the CSS rules applied to one selector, and not spread out over the style sheet.
However, I do suggest you read Creating Sexy Stylesheets over at thinkvitamin.com. One thing I do is list the rules in a certain order everytime, so I know within the declaration block where to find what I want.
More info at Jina Bolton's http://creatingsexystylesheets.com/
You'll find that in large-scale projects, layout and color/flavor CSS will (if you're smart about it) usually just happen to be separate. Firstly, if you're catching yourself setting color/font-size/font-family style rules over and over, you're wasting your time. Typically you should define your fonts in one place: the body tag. Any additional fonts should be defined in their respective tags... h1, h2, p, etc. In my opinion it's not good practice to give these tags positional directives; they should be placed inside a div that will be responsible for their layout. Same goes for color and font size. I think the only exception to the rule would typically be background stuff, which is especially true if you have lots of gradients and fancy things like that.
Really what it comes down to is planning; a well-planned project needs very few color/flavor style rules. So to answer your question, yes, I usually have a "Global.css" file that defines all of my fonts and colors for h1-h5, a, p, and any other tags that will contain text.
Edit:
Usually, since the projects I work in are fairly large-scale and have a number of different modules, we separate the styles with in a sort of hierarchy; this makes sense because of the way CSS works -- as long as you don't change the style-rules put into place at the "base" (or in our case, the global.css) somewhere down the line, the styles will stick. This helps because when we want to modify the font of our site, we simply change the font-family rule at the "body" tag, and it will propagate throughout the entire site.
So, our stylesheet layout works something like this:
Global.css (Fonts/Text/Primary font colors)
--> genericBase.css (basic page structures such as columns that are used throughout the site)
--> nav.css (left-hand nav and/or top nav bar)
--> formLayout.css (labels, inputs, fieldsets, any other form stuff)
-----> forums.css (individual modules' styles that may deviate a bit from the usual structures, or simply things specific to those pages)
-----> blogs.css
-----> messages.css (etc etc etc)
The arrows here are meant to imply the "order" of the files in the hierarchy. The longer the arrow, the further down in the style-sheet the rules these files contain would be, if we had put all of the styles into one file.
So you see, the whole idea is to start with very general styles and work your way down to the most specific. Remember that the order in which your CSS files load matters to the browser. You can use this to your advantage. The interesting thing is, by the time we get to our specific modules' css files, we have very few styles to write because most of the other important stuff has actually work itself out along the way.
So like I said, planning is vitally important. I've found that this methodology makes it easier to "debug" my styles, and I use almost no hacks at all, usually only for silly ie6 stuff.
Let me know if you need more information. I'm glad this is helpful to you.
I used to separate them but it was more difficult to maintain. The problem is that many "formatting" properties will have an effect on the layout and many "layout" properties may actually be design.
Some examples:
While "border" may be considered a "formatting" property, they do take some amount of space so you will need to adjust your layout when setting or removing borders.
"line-height" is tied to the font-size and may be considered a "formatting" property, but it has a huge influence on the size of your elements and how they vertically align each other.
Margins and paddings are sometimes needed for the layout and sometimes used just for formatting.
If you think hard about it, there are very few properties that actually are purely formatting or purely layout.
It's often easier to just keep everything in the same file and try to keep it clean by having your declarations orders, related properties grouped, etc.
I keep everything together in a single file and use the folders feature in CSSEdit to keep it organised. Web design company Viget have a blog post about this technique here.
I separated my layout and color styles recently, and I now have several css files, which i import as follows:
<link rel="stylesheet" type="text/css" href="style.css" media="screen" />
<link rel="stylesheet" type="text/css" href="style-default.css" title="Default Style" media="screen" />
<link rel="alternate stylesheet" type="text/css" href="style-bw.css" title="Black and White" media="screen" />
All layout is in style.css, then colors are in style-default.css.
This way I have a standard style, but users also have the option to change the colors. This not only offers options for the user, but it makes it easy to make color changes without touching the layout (I tend to change my colors much more often).
In Firefox my color options show up in the view menu under "Page Style."
I've fallen into the pattern of separating my CSS out into the following:
Layout (headers, footers, logos - general chrome)
Typography (fonts, sizes, re-usable inline font styles)
Widgets
The latter category is generally made up of CSS code I re-use between projects, and usually gets split down itself into:
Forms (left-aligned, right-aligned, styles for required fields, etc)
Grids (2-col, 4-col, etc etc etc - about 20 or so varieties)
Hacks (IE/other CSS hacks)
Other stuff (AJAX widgets, toolbars, comment boxes, etc - anything re-usable)
For colours, I just keep a cheat-sheet text file around. Keeping them in a separate stylesheet will probably only work if you are very, very disciplined.
I have started to use classes to handle colors specifically.
.element{margin, padding, layout stuff}
.ourcolor{#some color}
It lengthens the class attribute though:
< div class="element ourcolor" >
However, I can reuse the color:
< span class="ourcolor" >Some text
So far I prefer it as adjusting colors is much easier.
As Mark W pointed out, Creating Sexy Stylesheets is a fantastic read. One thing they do advocate is separating the styling concerns through a framework:
screen.css - A screen CSS file can either have all your styles you want to be used for on screen, and/or can import additional styles, such as the following:
reset.css - A reset CSS file can be used to “reset” all the default browser styling, which can help make it easier to achieve cross-browser compatibility.
typography.css - A typography CSS file can define your typefaces, sizes, leading, kerning, and possibly even color.
grid.css - A grid CSS file can have your layout structure (and act as the wireframe of your site, by defining the basic header, footer, and column set up).
print.css - A print CSS file would include your styles you want to be used when the page is printed.
If you follow this pattern, the colors would go in your typography.css, and layout would be in your grid.css.
I keep everything in one file and only provide different files for alternative styles (e.g. for printing).
Within that file I keep the overall layout (columns, headeer & footer) seperate from the actual contents (paragraphs, headings, lists...)
I am used to thinking object oriented, so I group the styles for different objects (menus, blog posts) together. From that perspective, colour and position both belong to the same object and therefore are kept together.
I am wishing for the ability to define colours once in a style sheet, assign them a declarative name (e.g. 'HeadingColour') and then use the name when assigning the colour to a selector...