Wednesday, November 5, 2008
Roundup of colour management / calibration / cs3 profile etc etc info
This looks like a good primer from apple about colourspaces, profiles, calibration etc...
http://support.apple.com/kb/HT2026?viewlocale=en_US
Looks like good explainations of various colour issues in these pages
http://www.gballard.net/psd/saveforwebshift.html
dont embed ICC profiles in your save for web dialogue if you want to match graphics and coded hex colours seamlessly. see...
http://www.gballard.net/psd/save_for_web_embed_ICC_profile.html
that post basically has screenshots of how to have settings in save for web.
so finally this is solving why when you save for web, photos get dimmer and washed out, they actually only are on my monitor not everyones elses because my gamma is set to 1.8
but really still in 2 minds about whether to have embedded profiles when saving for web or not. i tick convert to sRGB in save for web drop down.
1/ ticking embed icc profiles makes a less washed out image when viewing in safari. for some images it actually looks too saturated, maybe because they are incorrect to begin with. note that in firefox the image wont be any different and neihier will it in vista (vista displays it sRGB regardless. so is it worth the xtra 4k.
i was just about to think yes definately, then i viewed the images on an imac and there wasnt as much difference. and actually the untagged (more washed out) image actually looked better i think because the pic is too saturated to begin with.
2/ usually you wouldnt tick embed profiles, for web type things, because in safari or colour managed browsers you will get a mismatch between a jpg and a hex coded colour background. (because the hex coded background cant possibly have an embeded profile.
3/ so i dont know what is the answer. should i embed the profile so that in mac on safari the images look more saturated and similiar to the original image or have consistency between firefox and safari and hex colours and go for the washed out version which actually looks better on some images. and saves 4k per image. and also, on my screen it looks washed out but it wont on every mac screen.
4/ but mainly the concern was that what if my screen is very similiar to other mac users, and all of them using safari are seeing non punchy desaturated colours on the web when they dont need to be. see calibrating the monitor is actually NOT normal, so if you calibrate your monitor you will see punchy colours but the users still wont so whats the point. id rather leave my monitor to be like theirs, as a reminder that this is what it is going to look like for them and remember then to make the choice of embedding profiles or not.
also this is the reason why save for web images (without embedded ICC profiles) look different in a Preview or a browser and photoshop. photoshop views them in whatever is the working colour space eg. SRGB whereas Preview's colourspace is 'monitor rgb' which is the washed out one. but if you view a tagged (icc embedded srgb profiled) image in preview, it will look the same as in photoshop.
im gravitating more now towards tagging (embedding icc profiles) in save for web images, just because it is more correct in general to have a tagged image than an untagged. The tagged image will preview correctly and consistently in the finder, preview, safari and photoshop (but look washed out in firefox or any non colour managed browser but theres nothing to do about that anyway, at least safari users are seeing something closer to correct).
And especially to embed the profile when 50% of site visitors for the type of site your working on will be creative types on a mac OSX, using safari probably. the ones that count for commercial sites (customers with money to buy the products) will have fast bandwith so no caring about extra 4k, AND if someone has supplied a SRGB image that they have been viewing in photoshop with srgb working space, then i go and untag it and they view it on safari, it will look different and washed out compared to what they gave me. this = not happy.
just workeed out why the untagged profiles look different on the imac and the laptop. laptops 'generic rgb profile' and 'colour LCD' profile is used in the finder and in preview. the imac uses 'imac' profile to view things ie its own 'generic rgb profile'
so best thing to do is in your photoshop edit > color settings, you have ticked all those boxes that say profile mismatches etc etcwhen you open and paste files and so on. its a good reminder. it also helps you know what your working with, and you can convert images destined for the web away from adobe rgb to srgb when you open. its really important to be aware of which colour space the things your using were designed in and so on and you can sort of guess what it looked like on their screen.
whatever work now.
Friday, September 26, 2008
Roundup of best ways to do common things in CSS
Changing a background image on hover causes the browser to load it when its rolled over, which results in a long pause and a blank space where your buttons meant to be.
The simplest way to avoid this is this Pixy method - putting your button state images in the one image and moving that back and forth on hover states. Dont know what they mean by a flicker in IE, its seems fine in IE7.
http://wellstyled.com/css-nopreload-rollovers.html
A more complex method is here
http://www.alistapart.com/articles/sprites/
Li class active in CSS menu - but menu and head is a php include - solution
• do this by giving the body an ID and CSS styles for each body ID=active or something. BUT my body tag is in an include called head.inc - so it cant be unique on every page.
you could give the ul containing the menu a unique id on every page and then your has the code below- note - I think it can't be and .inc file anymore, it must be changed to be called .php because its actually executing php inside the menu include now, not just including plain HTML. ALSO - watch out for the " " marks, i don't think they're meant to be the fancy curly ones but the plain ones - retype the code to be safe rather than copypasting.
VARIATION - You can also change the menu code slightly to make the active page not linkable at all - this will further make the current page stand out from the other menu options. Here is an example of the code you would use for the links:
ahh cant work out how to paste code without it becoming html - go to the linked page for now
Tuesday, September 23, 2008
Recent finds and fixes typography and jquery fades
OS X and type rendering of knockout text (white text on a black background)
Normal body text in this situation on a mac looks bold, because of the anti-aliasing engine going overboard on knockout text.
/*text-shadow: 0 0 0 #000;*//*makes light coloured text look thinner in safari see http://24ways.org/2006/knockout-type */
Except theres nothing like that for Firefox. So Im using a lighter font family which is installed by default in macs.
font-family: "Helvetica Neue Light", "HelveticaNeue-Light", "Helvetica Neue", Helvetica, Arial, sans-serif;
and hoping it dosnt look too think with people who have PCs and that font.
JQuery fades side effect on Firefox 2 on a mac for type anti-aliasing. Or why on my Jquery gallery pages does the text suddenly look rubbish until I mouse over it?
/*-moz-opacity: 0.9999; *//*For Ffox 2.0 mac - Jquery fades on a page turn off its text anti-aliasing on that page. This style turns it off permanently so the problem isn't obvious. Double bonus of making knockout text not as heavy on os x. BUT - its makes a peekaboo bug on mac FF2&3 happen to Quicktime / Flash content so it cant be used. */
This seemed like a good fix until I checked a page with embeded quicktime and it was making the video display a peek-a-boo type bug when your mouse went near it. Ive read this also happens with Flash content (or your SIFR!).
IE7 cleartype (anti-aliasing) being turned off by Jquery
Theres also a similiar and just a shit problem that happens on IE7 to cleartype, in that the cleartype (IEs versions of anti-aliasing for web text) gets switched off when its part of your fading gallery (on mine text on the page is ok, just text thats being faded up with the gallery images looks rubbish). Aparently a fix is:
Assign a background colour to the bit thats being faded / the containing element of the text (but this isnt a solution for me because that area needs to be transparent (have no background assigned).
this could also be a fix
http://groups.google.com/group/jquery-en/browse_thread/thread/221169cf3a03d32e/51326b4726541831?lnk=gst&q=text+anti-aliasing#51326b4726541831
> But for IE7 you need to remove the opacity filter after the
> animation completes:
> $('#myDiv').fadeIn(function() {
> if ($.browser.msie)
> this.style.removeAttribute('filter');
> });
IE 6 div with class applied weirdness / bug - only applies first class styles in css source order
quick noteabout IE6 and having a div that has a class applied to it as in the html below.
HTML is
CSS is
#adivoneverypage {its styles}
#adivoneverypage.aclassforacertainpage{
special styles for just one unique page- as a class -but inheriting 'base' styles from above that are common to allpages with this div. (Mainly just to reduce repetition in the CSS file)
}
#adivoneverypage.aclassforacertainpage2{
styles for a different unique page to above- as a class -but inheriting 'base' styles from #adivoneverypagethat are common to allpages with this div.
}
#adivoneverypage.aclassforacertainpage3{
special styles for a different unique again page to above- as a class -but inheriting 'base' styles from #adivoneverypagethat are common to allpages with this div.
}
so the problem being - that in IE6 -it only applies the special class styles which come first in the source order of the CSS, and none after that!!! its as if these special styles just arent there, IE6 STOPS reading the styling after the first one is applied. You can test by copy pasting the last special class style and putting that first (after the #adivoneverypage styles) in the CSS source order. Then its styles will be seen by IE6 - but not the ones below it.
My fix to try is NOT USING class selectors on DIVS to make specific changes, but having just a unique div on every page and repeat the same a few times in the css instead of once and having all the classes inherit it.
so the HTML is instead:
CSS is
#adivforacertainpage {its styles}
and for each page have unique div IDs. Which is a shame because sometimes these divs on each page are practically identical except for maybe a bit of different padding is necessary for a certain page, or something like that, but otherwise they are the same size, have the same margins, positioning etc etc, so its a shame to have to repeat the CSS over and over again.
Saturday, September 13, 2008
Vertical Centering a fixed width and height website using CSS
A good explanation of historical methods and tutorial:
http://www.search-this.com/2008/05/15/easy-vertical-centering-with-css/
FIXED HEIGHT CENTERING
Live example - a simple method using a negative margin floated div like a spacer to do it. it also centers the background image which is great.
http://www.pmob.co.uk/search-this/center2.htm
CENTERING WHEN NO FIXED HEIGHT
Another method thats a bit more complex that works for if the div you want to center has no fixed height. Its uses display:table and some IE fixes.
http://www.pmob.co.uk/pob/vertical-center4.htm
Remember background can be centered vertically too, like this:
background:#000 url(images/vertbkrnd.jpg) repeat-x center center fixed;
and apparently need also body height 100% like:
html,body{
height:100%;
margin:0;
padding:0;
}
and a note - it dosnt have to be exactly centered, it could be say 30% from the top to be more compositionally nice.
Wednesday, September 3, 2008
Inspiration sites
http://www.cssartillery.com/