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've read one place that aural stylesheets are no longer in use? Is there something that has replaced them? I'm sure something is being used to make things easier for those who are visually impaired?
If aural CSS is in use still, is there a way to specify what should be said in a specific place, similar to using "alt" for images? For instance, I'm using an iconfont for my logo. I'd like to be able to have the user hear the name of my company, but because it's just done with a span, there's no place in that particular span that indicates the words (I'm assuming here that the system reads the words displayed on the screen, and not all the code with it, so obviously this works better if there's actual text to read). Maybe include a content: 'whatever text you want' is added somehow?
The gist is that I'm working on a site about opera for a client, and the client would like for the content to be accessible to everyone. And obviously someone with visual impairment is going to be especially wanting to hear things.
1. Is there a replacement for aural?
Aural stylesheets have indeed been deprecated as of CSS3. Major browsers such as Firefox removed the implementation a while ago. There is still a speech media included, but I haven't seen any implementations so far (it just seems to be a proposal at this point).
Many people with visual impairments use screen readers and to a lesser degree refreshable braille displays to view the content, so you usually don't have to worry about a direct implementation of speech. Important points for that to work are:
People have to be able to navigate through your content using the
tab key
All relevant rich content such as images etc. need to have a text equivalent.
Your html should be semantic (have a look at the aria attributes)
2. How can you make icon fonts (and other non-legible items) accessible?
In this article on bulletproof accessible font icons they propose a pretty good solution:
Since the characters don't have any direct semantic meaning, you could include them in the :before pseudoclass of your span:
.logo:before {
font-family: YourIconFontFamily;
content: "★";
}
And then include the company name directly in the span:
<span class="logo">Your company<span>
According to W3 it's defined in CSS 2 - but is already been deprecated with CSS3. You also can have a look at the Speech module: http://www.w3.org/TR/css3-speech
You can use another span with the specific content only for the screen reader which would look something like:
<span aria-hidden="true">Here could be your company name</span>
Source: http://www.456bereastreet.com/archive/201205/hiding_visible_content_from_screen_readers_with_aria-hidden/
On my page I have few blocks (div) that have the same style regarding background and border (menu panel, info panel, footer panel, ...).
Now I would like to write that style only once and not repeat it for every panel. Yet I don't see any comfortable way of doing that.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML. I'm no longer able to transparently change things easily because that requires modification of the (X)HTML.
Not to mention that it introduces issues with order of the classes (and thus order in which CSS attributes will be overwritten if needed).
EDIT: (an extended explanation for kolin's answer)
By “revealing implementation” I meant that the (X)HTML (“the content”) is much more strongly connected to the CSS (“the presentation”) than I would like them to be. Maybe I’m pursuing an unreachable ideal (maybe even an unreal or a dummy one!) but I’m trying to keep “the content” separate from “the presentation”.
Thus having a class menu isn’t bad because it describes “contents” not “presentation”. While using instead (what I understood from the cited articles and few others on that site) classes like menu box bordered left_column is bad because it mixes presentation with contents. Once you start adding such classes you might very well add that CSS directly to style attribute. It sure would be much more work and an unmaintainable result but conceptually (when regarding contents-presentation separation) it wouldn’t make a difference.
Now I do realize that in real life for real pages (rich and nice) it is virtually impossible to keep contents entirely separate from presentation. But still you may (should?) at least try to.
Also just look at the “But” in the end of the article The single responsibility principle applied to CSS. In my opinion the island class he used is already presentational because it does not describe contents. It describes how to show it. And that is immediately obvious once you see how widely he used (or might have used) that class on elements having nothing in common as regarding contents.
END EDIT
Another approach was to use selectors grouping. So I would have something like:
#menu, #info, #footer {
background: /* ... */
border: /* ... */
}
This avoids the need to modify (X)HTML. But still causes order issues. And also makes it hard to group styles logically. Especially if they are distributed among many files.
I think that what I really would like to have is to be able to name a group of attributes and just import them somehow in selectors. Something like #include in C++ for example. Is there any way to achieve this? I doubt it but maybe...
If not then is there any other method?
Using classes to define styles is the correct way to do it.
One approach I investigated was to introduce a dedicated class (for example panelClass) that would capture the common panel styles. Then in (X)HTML I would just add that class to every element that is supposed to be a panel.
For me this is exactly the way I would do it.
But this doesn't feel right. After all I would be "revealing implementation" in the (X)HTML.
is there a security problem with revealing implementation?
A few selected posts from Harry Roberts :
http://csswizardry.com/2012/04/my-html-css-coding-style/
http://csswizardry.com/2012/04/the-single-responsibility-principle-applied-to-css/
http://csswizardry.com/2012/05/keep-your-css-selectors-short
I find his style of using CSS eye opening, and it may help you
update
Following on from your update, I agree with you that you should try and seperate structure from presentation, although there will be times where we can't quite manage it. Whether it is fully possible or not, i don't know.
I partially disagree about the island class, the padding property to me kind of hovers over the border of structural and presentational. structural because it alters the layout of whatever element it is applied to, presentational because the padding alters how it looks on the page.
in an ideal world you should never need a class attribute that encompasses menu box bordered left_column, because you would write a couple of classes that seperate out the structure and presentation.
thinking about your case I might create a panel class
.panel{
margin:10px 0;
padding: 10px;
display:block
}
and a panel-display class
.panel-display{
background-color:#1111e4
}
.panel-display > a{
color:#fff
}
in this way I could just play with the presentation without affecting the structure of the site.
(n.b. I'm not sure if this helps you in anyway!, it just seems logical to me)
So, I know that this isn't something that is normally a good idea for a website, but I have a special purpose/intent for such a use:
I have a multilingual dictionary that I'm working with online, where I need one of the languages to be in a specific font, from a file that I specify locally. However, I want this language to be rendered ONLY in this font, as if it is rendered using any other font, it will render incorrectly. That's all fine and dandy, and I can load the file in CSS and whatnot.
But I want to make it so that if it can't load that file, either for one reason or another, or something goes wrong, it can't go to another font. Basically, render this text using this font, and if you can't do that, don't just try and render it with Arial or whatever is the default -- show me blocks, show me a stark something.
I've spent a bit looking around, but am not sure what in CSS I would be using for this. Suggestions/help? Thanks :)
As an update to this question, since April 2013 there exists the Adobe Blank Font, which can be used for that purpose.
You may build a cross-browser css with FontQuirrel WebfontGenerator and the Adobe Blank font files.
If you just need the font in OpenType format you can use this single css file with the already embedded font
You can't do this. Text is text and text has to have a font that it is to be rendered in. If you really want, there's probably some weird JavaScript function that can detect the actual font being used for the text and if it doesn't match the one you want, then you can hide it or something. But in the end, your only option is to have the text displayed in some obscure font, or completely hide the text. If the text is visible, it has to be rendered using some font.
You could also theoretically create your own font where all the characters are just blank, but that seems highly illogical and such a waste of resources to make people download a font just so it can display meaningless emptiness.
There is no "don't render fonts" option. It's a font, it needs to be rendered, or else it's hidden visually in the DOM.
You could use Javascript to find out the font being applied to a certain block, and if it's not the font you want, just hide it. Or display a message.
Another solution is somehow specify the content to be empty. For example, I'm trying to override the +/- character that a Webix tree displays using Font Awesome:
#lhn-tree-container .webix_tree_open:before {
content: '';
}
This only works with the :before and :after pseudo-elements though.
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...