f8 2008

Just got my ticket for f8 2008, I’ll be in San Francisco July 23rd, I’m sure I’ll have some interesting notes to share :) .

Download Day is Awesome


Today I ran into an interesting response to Paul‘s post on those who dislike the awesome bar (which I decided not to link to).  The post pulls the following quote from the end of Paul’s well thought-out and harmless article:

So just give it a shot and quit complaining. Yes, it is a complete paradigm shift. But it’s not called the Awesome Bar for nothing; it really is awesome once you give it a chance

And proceeded to call Paul an “asshat” and a “discredit to the Mozilla community”.  Really?  One sentence saying “give it a chance” and all of a sudden Paul’s an asshat?

Normally I would ignore this and chalk it up to people seeking out drama for the sake of snagging pageviews, but it made me realize that most media does this.  The Firefox 3 launch was absolutely amazing: we had 8 million people download our software in 24 hours, 12 million in 48.  It’s unreal!  Yet I’ve seen dozens of posts and articles talking about a minor outage and “howls of derision across the blogosphere”.  Are people that desperate for a negative angle to a story?  I’ve yet to hear one negative comment from people in person (granted, I see a lot of Mozilla employees, but I still see/talk to other non-Moz folk).  The execution had a few hiccups, but the overall project went amazingly well.

This is why I like sites like Hacker News.  The community discourages blowing things out of proportion.  For example, I recently commented on a post entitled Firefox 3 smart bar is just too smart, and it led to an intelligent discussion about the merits of the bar.  My post said basically the same thing as Paul’s, but there’s less hostility towards differing opinions, and it results in the ability to actually discuss things instead of pointless name-calling.

So the next time you’re writing a blog post focusing on a tiny negative aspect of a project, think about the big picture, and if it really matters, or is just a rant to spread negative views that only benefit your pageview count.


Border Conflict Resolution

Earlier today I was attempting to style a table header when I came across a peculiar part of the CSS 2.1 spec.  Here is what I was trying to create:

I has a table with a number of header elements and I wanted to style it such that each one would have 2px of gray border on the bottom and 2px of space in between each element.  Simple enough, right?

After poking around for a bit with allowing table row elements to have margins, I decided it would be much easier to just put a right border on each element, 2px thick and solid white.  Easy enough, right?  Wrong!  Here’s what I got:

It seems the bottom border would take precedence over the right border.  But why?  How could I override this?  Eventually I stumbled upon the appropriate page of the CSS 2.1 spec, which explained everything (almost): Border conflict resolution

In the collapsing border model, borders at every edge of every cell may be specified by border properties on a variety of elements that meet at that edge (cells, rows, row groups, columns, column groups, and the table itself), and these borders may vary in width, style, and color. The rule of thumb is that at each edge the most “eye catching” border style is chosen, except that any occurrence of the style ‘hidden’ unconditionally turns the border off.

The following rules determine which border style “wins” in case of a conflict:

  1. Borders with the ‘border-style’ of ‘hidden’ take precedence over all other conflicting borders. Any border with this value suppresses all borders at this location.
  2. Borders with a style of ‘none’ have the lowest priority. Only if the border properties of all the elements meeting at this edge are ‘none’ will the border be omitted (but note that ‘none’ is the default value for the border style.)
  3. If none of the styles are ‘hidden’ and at least one of them is not ‘none’, then narrow borders are discarded in favor of wider ones. If several have the same ‘border-width’ then styles are preferred in this order: ‘double’, ‘solid’, ‘dashed’, ‘dotted’, ‘ridge’, ‘outset’, ‘groove’, and the lowest: ‘inset’.
  4. If border styles differ only in color, then a style set on a cell wins over one on a row, which wins over a row group, column, column group and, lastly, table. When two elements of the same type conflict, then the one further to the left (if the table’s ‘direction’ is ‘ltr’; right, if it is ‘rtl’) and further to the top wins.

So there we have it…there is an order of precedence for border edges.  While it seems relatively arbitrary, it is at least specified, which I suppose is better than nothing.  This doesn’t exactly fix my problem though, now does it?  In the end I copped out and just made the width in between the cells 3px and as per item 3, the white border took over.

I hope CSS 3 has some kind of mechanism to specify this (The CSS3 table module has yet to have a draft release).  It seems like the ordering is relatively arbitrary and in rare situations where it does matter it’s worth being able to specify.

Firefox 3!!!

Yup, FF3 is here.  Go download it.  Seriously, it’s awesome.  How awesome is it?  It’s so awesome, it has a feature called the awesome bar.  It’s so awesome, there are hundreds of parties all over the world to celebrate it.  It’s so awesome, I use it :-P.

So yea, go downloads it.  Also, I promise not to make every post in the future about Firefox, but this week has been really big for Mozilla and the OSS community.

Update: We’re currently serving 14,000 downloads/minute.  That’s over 200 downloads per second.  Wow!

Update 2: The IE team sent us another cake, how sweet :)

They did this for Firefox 2 too, check out the remnants of that cake:

I’ve been told the last one was delicious, this one should be pretty good too.  Thanks IE Team!