Wednesday, May 7th, 2008
Category: CSS
Eric Meyer has felt a lot of pain due to line-height, which means us mere mortals are totally up the creak.
He posted about how line-height is abnormal and goes into detail on his learning curve, and the pain he saw which lead him too:
Why bring all this up? Because I went and poked line-height: normal with a stick, and found it to be both squamous and rugose. As with all driven to such madness, I now seek, grinning wildly, to infect others.
Here’s the punchline: the effects of declaring line-height: normal not only vary from browser to browser, which I had expected—in fact, quantifying those differences was the whole point—but they also vary from one font face to another, and can also varying within a given face.
I did not expect that. At least, not consciously.
He created a tool that visualizes all of this for you, so you can see the magic at work:
Tuesday, May 6th, 2008
Category: Browsers, CSS
After building a slide deck with Ben, you learn the art of a perfectionist. He would love Chris Hester’s posting on button padding that shows you how your buttons look on various browsers and operating systems. Even been frustrated when you try to style things on the Mac?
Here are a few of his findings:
- IE 6 and 7 apply extra padding to buttons with < 2px, but IE 8 doesn’t
- IE 8 and Opera add borders to all standard buttons if you zoom large enough
- Padding on the standard buttons has no effect on Mac Firefox, and Safari on both Mac and Windows
Friday, May 2nd, 2008
Category: JavaScript, Browsers, CSS
John Resig "doesn't think there's a single JavaScript developer who isn't excited about the new Selectors API specification (and the upcoming implementations)."
He was asked to provide feedback on the API, and he sent them an email with just that.
He had three concerns:
DOMElement.querySelectorAll returning incorrect elements
This is the most critical issue. As it stands DOM Element-rooted queries are borderline useless to libraries - and users. Their default behavior is unexpected and confusing. Demonstrated with an example, using Dojo:
HTML:
-
-
-
<script src="http://o.aolcdn.com/dojo/1.1.0/dojo/dojo.xd.js"></script>
-
-
var foo = document.getElementById("foo");
-
// should return nothing
-
alert( dojo.query('div span', foo).length );
-
// will return the SPAN (booo!)
-
alert( foo.querySelectorAll('div span').length );
-
</script>
-
He then asked other library authors if they agreed:
Andrew Dupont (creator of Prototype's selector engine):
My issue with this is that it violates principle of least surprise and bears no resemblance to the APIs in the wild.
Alex Russell (creator of Dojo's selector engine):
This is a spec bug.
Combinator-rooted Queries
I read about some prior discussion concerning this (especially in relation to DOMElement.querySelectorAll-style queries). This is an important part of most libraries, as it stands. Maciej's proposed solution of using :root to allow for front-leading combinators is perfectly acceptable to me (where :root is made equivalent to the element, not the document element).
JAVASCRIPT:
-
-
// jQuery
-
$("#foo").find("> span");
-
-
// DOM
-
document.getElementById("foo").querySelectorAll(":root> span")
-
This is something that a library can easily detect and inject.
Error-handling
I'm perfectly fine with the proposed try/catch solution however there must be a way of easily determining what the invalid portion of the selector was. Currently the following occurs in Safari:
JAVASCRIPT:
-
-
try {
-
document.querySelectorAll("div:foo");
-
} catch(e) {
-
alert(e); // "Error: SYNTAX_ERR: DOM Exception 12"
-
}
-
If there were extra properties to point to what the inappropriate selector was, that'd be fundamentally important. Probably the best solution (for both implementors and JavaScript library authors) would be to simply provide a character index, working something like the following:
JAVASCRIPT:
-
-
var selector = "div:foo";
-
try {
-
document.querySelectorAll(selector);
-
} catch(e) {
-
alert(selector.slice(e.position)); // ":foo"
-
}
-
It is nice to see this all in the open, and especially watching the library authors get involved in the specs that effect us all.
Category: Fun, CSS
There is the David. There is the Mona Lisa. And then, the artist has to create the Homer.
Román Cortés did just that with his Homer in CSS and Ned Batchelder shows it via animation.
Thank god for fun fridays.
Friday, April 25th, 2008
Category: Browsers, CSS, Safari
How long have you wanted to name colors and such in your CSS instead of having to use search and replace (which breaks if you share the same colors ;) ?
We have a proposal thanks to Daniel Glazman and the ubiquitous David Hyatt.
Since the release of CSS Level 2 Recommendation ten years ago in may 1998, the Web authors' community has been requesting a way of defining variables in CSS. Variables allow to define stylesheet-wide values identified by a token and usable in all CSS declarations. If a value is often used in a stylesheet - a common example is the value of the color or background-color properties - it's then easy to update the whole stylesheet statically or dynamically modifying just one variable instead of modifying all style rules applying the property/value pair. We expect CSS Variables to receive a very positive feedback from both the Web authors' community and browser vendors.
With Dave on the author list, we can expect the following to work on WebKit sometime soon!
CSS:
-
-
@variables {
-
CorporateLogoBGColor: #fe8d12;
-
}
-
-
div.logoContainer {
-
background-color: var(CorporateLogoBGColor);
-
}
-
(via Dylan Schiemann)
Tuesday, April 15th, 2008
Category: Browsers, CSS, Safari
Dave Hyatt, the one person I would love to get to TAE to join the other browsers, posted about CSS gradients in WebKit:
CSS:
-
-
-webkit-gradient
(<type>, <point>
[, <radius>
]?, <point>
[, <radius>
]?
[, <stop>
]*
)
-
So what exactly is a gradient in CSS? It is an image, usable anywhere that image URLs were used before. That’s right… anywhere. :)
You can use gradients in the following places:
- background-image
- border-image
- list-style-image
- content property
The type of a gradient is either linear or radial.
A point is a pair of space-separated values. The syntax supports numbers, percentages or the keywords top, bottom, left and right for point values.
A radius is a number and may only be specified when the gradient type is radial.
A stop is a function, color-stop, that takes two arguments, the stop value (either a percentage or a number between 0 and 1.0), and a color (any valid CSS color). In addition the shorthand functions from and to are supported. These functions only require a color argument and are equivalent to color-stop(0, …) and color-stop(1.0, …) respectively.
This is great stuff. Think about the image repeating tricks you have had to do just to get some of this behaviour. This is much more elegant.
There are a bunch of examples:
And in conclusion, we have a lot more coming:
WebKit now supports a generic architecture for generated images, making it easy to add new generator effects to CSS in the future (lenticular halos, checkerboards, starbursts, etc.). The rules for sizing of these generated images will match whatever is decided for SVG content with no intrinsic size (the two are sharing the same rules right now).
We encourage you to try gradients out and file bugs if you see any unexpected or weird behavior. They will degrade safely in other browsers as long as you use multiple declarations (e.g., specify the image in one declaration and the gradient in a following declaration).
Thursday, April 10th, 2008
Category: JavaScript, CSS, jQuery
During his work in redesigning the Pathfinder web site, Brian Dillard came across the infamous IE6 transparent PNGs issue and used two methods to tackle the issues. He decided to do a nice write-up explaining how he worked around the fact that IE6, while it would render PNGs, would not retain their alpha-channel transparency and produce unexpected colors in place of the transparency.
IE6's lack of transparent PNG support is appalling, but Microsoft does offer a proprietary fix for the same problem: CSS behaviors, which are a non-standard extension to the CSS spec. By applying a special behavior to your PNG images, you can force IE6 to display them with their alpha transparency intact.
Coding this CSS behavior on an image-by-image basis would be tedious. Luckily, developer Angus Turnbull has released an open-source script that can be used to apply the behavior globally: IE PNG Fix. The current production release is v1.0 RC4, but a preview of v1.0 RC5 is also available.
While the IE PNG Fix script to dealt with the majority of the PNG transparency issue, there was still one problem that the script could not correct:
There is, however, one drawback to Turnbull's script: It can't account for PNG background images with a background-position other than top left. It will restore the alpha-channel transparency to such images, but it will reposition them to top left, potentially making your designs look even worse than they would have with an ugly gray halo where the transparency should be.
Brian turned to jQuery to help him resolve this by allowing him to re-insert the background images previously removed from IE6 as foreground images.
Full details, including code, of his solution can be found in his two part series linked below:
Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 1 of 2)
Hacking transparent PNG support into IE6 with IE PNG Fix, CSS and jQuery (part 2 of 2)
Wednesday, April 2nd, 2008
Category: IE, Browsers, CSS
Howard Rauscher tipped us off to this IE 8 ticket that talks about how opacity and IE 8 strict mode do not jive:
Description
IE8 Strict Mode correctly omits the filter: alpha(opacity=xx) in CSS
which allows the user to specify the opacity in pre-IE8 browsers but
does not implement the CSS3 opacity setting. While I understand that
opacity is part of the CSS3 spec which is not finalized, this leaves
developers with an odd regression in functionality where it is no
longer possible to change opacity on css elements (where as it was
with IE 5.5, IE 6.0, IE 7.0, Mozilla Firefox, Apple Safari, among
others).
Comments
So the fact that this has been labeled as by design suggests that IE8
will be the only browser produced in the last 10 or so years that will
not support opacity in its strictest mode. Thats rediculous. I
understand the wish to be standards compliant but how hard is it to
implement reading the css3 opacity tag (even if it still makes use of
the filter, at least it will exist as a future standards equivelant
tag).
At some point standards has to give way to usability. Mozilla, Opera,
Apple all realize that a few tags that maybe are not official CSS 2
spec still need to be available. If major functionality is missing
from the standards compliant version of IE8, who will use it, even if
it is standards compliant.
You'll have a whole host of websites that are standards compliant but
need a few features unavailable in standards compliant mode. So these
websites will be setup to use IE7 mode. And then when IE9 comes out
you'll have to deal with compatibility issues all over again.
Posted by Ames on 3/17/2008 at 3:59 PM
A pretty crazy regression no?
Tuesday, April 1st, 2008
Category: Examples, CSS, SVG
Torrey Rice took Safari 3.1 and the new CSS Animations feature, and mashed it up with SVG to create a fisheye demo.
All the functionality through CSS:
CSS:
-
-
.dock img {
-
width:50px;
-
padding:10px;
-
float:left;
-
position:relative;
-
display:block;
-
-webkit-transition:width 0.5s ease-out, top 0.2s ease-out;
-
}
-
-
.dock img:hover {
-
width:100px;
-
}
-
-
.dock img:active {
-
top:-40px;
-
}
-
-
.dock img:hover + img {
-
width:70px;
-
}
-
Jeff Schiller then asked to see the example using the standard SMIL, which has been turned on (all beit a subset) on WebKit nightly to pass Acid3.
-38461538461538000 rating from 26 votes
Monday, March 31st, 2008
Category: Browsers, CSS, jQuery, Debugging
Mario Heiderich of Ormigo has created a jQuery based code snippet/bookmarklet that is capable of detecting floating errors and adding a dotted orange border to elements which should be cleared - but aren't.
It saved me a huge bunch of time debugging complex layouts for all browsers - especially IE6. If jQuery isn't already loaded on the page it can easily be fetched with the several jQuerify approaches.
Snippet
JAVASCRIPT:
-
-
(function(){
-
function checkNext(element, floating) {
-
if(element.css('clear') != 'none') {
-
var clearing = true;
-
} else {
-
if(element.next().length !== 0) {
-
var clearing = false;
-
checkNext(element.next(), floating);
-
} else {
-
console.log(element);
-
element.css({border:'2px dotted orange;'})
-
}
-
}
-
}
-
$('body *').each(function(){
-
var element = $(this);
-
if(element.css('float') !== 'none' && element.next().length !== 0) {
-
checkNext(element.next(), element.css('float'));
-
}
-
eval('');
-
});
-
})();
-
Bookmarklet
JAVASCRIPT:
-
-
javascript:eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('(3(){3 5(a,b){4(a.2(\'p\')!=\'9\'){6 c=h}d{4(a.1().7!==0){6 c=o;5(a.1(),b)}d{n.m(a);a.2({l:\'j i k;\'})}}}$(\'g *\').f(3(){6 a=$(e);4(a.2(\'8\')!==\'9\'&&a.1().7!==0){5(a.1(),a.2(\'8\'))}q(\'\')})})();',27,27,'|next|css|function|if|checkNext|var|length|float|none||||else|this|each|body|true|dotted|2px|orange|border|log|console|false|clear|eval'.split('|'),0,{}))
-
Saturday, March 15th, 2008
Category: CSS, Testing
Via John Resig we just got to learn about a clever technique applied by the Filament group in Boston called Progressive Enhancement with CSS support.
The study rightfully claims that object detection to determine whether a user agent is capable of supporting a certain interface is not enough. You also need to make sure that the browser supports the right look and feel - in other words that the CSS you will apply can be rendered as intended.
I've done similar things in the past, reading out the offsetWidth of an element to determine if the browser is in standards or Quirksmode but Filamentgroup's test script goes a lot further than this. It tests for the following CSS support:
- Box model: make sure the width and padding of a div add up properly using offsetWidth
- Positioning: position a div and check its positioning using offsetTop and offsetLeft
- Float: float 2 divs next to each other and evaluate their offsetTop values for equality
- Clear: test to make sure a list item will clear beneath a preceding floated list item
- Overflow: wrap a tall div with a shorter div with overflow set to 'auto', and test its offsetHeight
- Line-height (including unitless): test for proper handling of line-height using offsetHeight, primarily to rule out Firefox 1.0
For example the right box model support is tested with this script:
JAVASCRIPT:
-
var newDiv = document.createElement('div');
-
document.body.appendChild(newDiv);
-
newDiv.style.visibility = 'hidden';
-
newDiv.style.width = '20px';
-
newDiv.style.padding = '10px';
-
var divWidth = newDiv.offsetWidth;
-
if(divWidth != 40) {document.body.removeChild(newDiv); return false;}
When the browser passes, the script adds an "enhanced" class to the body that you can use in your style sheet.
Neat idea and very defensive programming.
Wednesday, March 5th, 2008
