Results tagged “css”

A Blue Box

By Michael Mulvey on December 1, 2013 11:12 AM

CSS-Tricks:

A little meme went around CodePen the other night. A Blue Box. I'm not sure how it started, but lots of people started posting code of different ways to draw a blue box. It's weird, it's funny, but it's also rather amazing there is as many ways as there are for doing something so simple.

This is a great example of how to train you to think different.

To think outside the [blue] box, if you will.

If lateral thinking is your bag, I recommend reading Edward de Bono.

Webkit to the Rescue

By Bryan Larrick on March 25, 2013 11:18 AM

I was a late-comer to Mountain Lion, for no reasons worth going into here. But the transition the last couple months has been rocky here and there. I'm not much of a fan of the half-baked in-between state Mountain Lion occupies between iOS and earlier OSX iterations like Snow Leopard. I've spent a lot of time tweaking things here and there to get them either back to the way I like them, or to activate features I think Apple missed. One of these is involves the web inspector for Safari 6.

I'm a web developer, and it's crucial for my job that browsers have a way to inspect a web page, showing me the DOM tree, all elements and attributes, inheritance, etc. One of the most important things for me, since I focus on front-end UI, is how CSS is being called. Back in Safari 5, this was easy in the web inspector. When inspecting elements on a page, any styles applied to an html tag would show in a details window, along with styles inherited from parent elements. Also present would be the file name and line number where the style lived. It was easy to find the exact style that was affecting an element.

For whatever reason, in Safari 6, the web inspector was changed. It still shows which styles are being computed, but it doesn't show where they came from. You have to click back through the DOM tree until you find the element with the associated style. This adds a lot of time to testing a webpage, especially if you're diving into someone else's work. See below:

safari6inspector_bl.jpg

In the above image, I selected a div that gets just about all of its styles from parent elements, but while I can tell which styles are being computed, I can't tell where they are. For example, I know what font-family is being applied to the div, but where is it coming from? This has been a source of frustration for me ever since I updated to Mountain Lion and have tested pages in Safari. Thankfully, WebKit has come to the rescue.

The WebKit Open Source Project is still using a web inspector with CSS details similar to that found in Safari 5. See below:

webkitinspector_bl.jpg

This is an image of the web inspector in the latest build of WebKit. I have the exact same div selected as in the previous screenshot, only in this one, I can see which styles are being applied from parent elements, and where they live in their corresponding CSS files. This is going to make testing styles in Safari a lot easier for me.

-Webkit Winning

By Bryan Larrick on February 13, 2012 11:11 AM

Scott Gilbertson, over at webmonkey, has an interesting piece on developers preferring the -webkit prefix in their CSS, and how this could be bad for the web.

...at the CSS Working Group meeting, Microsoft, Mozilla and Opera announced that each are planning to add support for some -webkit prefixed CSS properties. In other words, because web developers are using only the -webkit prefix, other browsers must either add support for -webkit or risk being seen as less capable browsers even when they aren't.

via webmonkey

TCC - Operational Instructions

By Michael Mulvey on December 5, 2006 2:51 PM

Coming soon to TCC - Operational Instructions: step-by-step tutorials on Flash Actionscripting, XML, HTML & CSS.

Stay tuned.

Clearing floats, margins and other Windows IE delights

By Michael Mulvey on October 9, 2006 10:54 AM

I probably should have known about this bug a long time ago, but apparently Windows IE (I've only tested v6) likes to double your margins on floating DIVs. What's the solution? A tiny-ass, stupid line of code:

 display: inline;

Other CSS tips:
How To Clear Floats Without Structural Markup - now this one I have known about for a while and its very handy.

What I like to do when I'm testing out my CSS is to turn on borders all all DIVs in my document. Many times it takes the guessing out of why your page is behaving like it is:

div {
 border: 1px #333 solid;
}

and if by some chance you're old school and having table issues, you can do the same:

table td {
 border: 1px #333 solid;
}
1

Daily Exhaust is hosted by DreamHost, powered by Movable Type with Minted statistics.