by

Horizontal background extending on fixed width sites

Often when building a fixed width website, there are blocks of content whose backgrounds should extend horizontally beyond the fixed width area. Footers are a good example of this, but there are other cases as well.

There are a few ways to go about achieving this: wrapper divs, a mess of absolute and relatively positioned elements… or there’s a nice little CSS hack using the :before pseudoclass.

#myblock    /* Main content block */
{
    width: 940px;
    margin: 0 auto;
    background: steelblue;
    height: 200px;
}

#myblock:before    /* The pseudoclass hack */
{
    position: absolute;
    width: 100%;
    left: 0;
    background: steelblue;
    height: 200px;
}

A few things to note:

  • The block must have a fixed height, otherwise the :before extensions won’t match the main content height.
  • The content block must not be position relative, otherwise the absolute positioning of the :before pseudoclass won’t work properly.
  • This works in IE8+, Firefox, Chrome, Safari… IE7 and lower have no support for the CSS :before pseudoclass.
  • This is best suited for solid colours. A tiling image should be okay too. A background image at a specific location in the content block will probably incur z-index problems.
    For most browsers, this can be fixed by setting the :before pseudoclass to have a z-index of -1, but this will not work in IE8. There doesn’t appear to be a solution for this problem.
by

Reflections

Firstly, we survived and we are awesome. There are few things better than seeing 5 groups send files back and forth over wireless modems on a protocol we designed and then being told that you are the first group in 20 years to accomplish that.

What was interesting for me (between periods of frantic bug hunting) was watching how people worked, how they tried to solve problems, and how they handled things going wrong. From watching that, I’ve realised some things.
I need to be less… controlling about things. I try to always be open to new ideas and new methods, but I always try to ensure that everything is done the way I would do it. This leads to other people feeling useless, and me reaching the point of burnout from trying to do everything. I will always have a need to know how the project as a whole works and how all the pieces fit together, I’m definitely not one for blackboxing. But I need to trust other people to do things, and trust that they can be help responsible for what they’ve done.
Almost as importantly, someone needs to hold me to similar standards. There should be debate about how to do something, and someone’s idea should not be used simply because it’s easy, or it sounds good. I should need to prove my reasons to people before I’m simply given the freedom to implement it.

Those of you who felt like you couldn’t contribute anything, or (worse) those of you who got stuck writing documentation at the last minute: Don’t let me do that to you again.

by

Gwibber, or “Planning for Plugins”

I have been consistently pleased with Gwibber as a Twitter client over the past year or so, and I’ve seen some very nice improvements over that time (support for new services like Buzz and Digg, support for displaying thumbnails of Twitpics, etc.). Yesterday I was working on a simple prototype for fetching status updates from a web service, and thought Gwibber would be a good place to integrate it.

While I was (mostly) successful, the experience left me with some questions about plans for extensibility by 3rd party modules for Gwibber. Every service is implemented in its own Python file in a directory, adding the class for a new service was easy. Making Gwibber load it was much more difficult.

Gwibber’s client file explicitly imports all of the service modules. This is a problem: if I want to add my own service, I need to edit core Gwibber files. Not to mention, those files are of course in /usr which means I need superuser permissions to do so, and any Gwibber updates will overwrite those changes. I’m certain that there are “plugin” module loaders out there for Python, and if there aren’t any that are suitable it’s easy to write your own (I’ve done so in the past for a different project).
The second part of that problem is that simply importing the module isn’t enough, I also had to edit a dictionary in the client file to add my service to the list of recognised services.

Success… in some ways. The problem now is actually adding the account. Gwibber’s UI stuff seems to be entirely separate from the core, and each service defines its own UI file. I had to create another py file to tell it which UI to use (I cheated and re-used an existing UI, otherwise I would have had to create that as well).

Gwibber is a good program that works well, I wouldn’t have chosen it as my test area if I didn’t like using it. The actual service modules follow a reasonable structure (although some are inconsistent, and there is no documented API). The problem is that everything is hardcoded into the client.
I’ve seen feature requests for other services in Gwibber, but at the moment it isn’t feasible to write support for those as some sort of plugin.

Maybe I’ve been hanging around Pidgin too long, but I think the concept of every service/protocol being a plugin that is loaded dynamically is a very good one; and something that would make Gwibber feel a lot more open to 3rd party development.

by

From My Hands

(Cross-posted from GoW Forums)

I… haven’t touched Blender in 2 months.
I haven’t done any meaningful work in Blender is far longer.
It’s sad for me to say that, because I have things that I want to do and ideas that I want to develop.

We’re losing people. I’ve seen more people lose interest over the past 6 months than I have in any other period of Uru. We’ve been given hopes and promises, and now we’re all waiting for something that might never come. Times change and people get busier, and I feel that need to seriously ask myself why I’m still here.

It’s not because I enjoy it: Uru is depressing these days, and I don’t want to build Ages that nobody will ever explore;
it’s not for the community: I’ve seen almost all the good people lose interest, leaving only the idiots on MOUL worshiping their Holy Blue Lords of Cyan;
it’s not for the potential: time killed whatever potential was left in Uru.
It’s not even for Plasma anymore, the more I see of it, the more I realise how much it could be improved and yet there’s no way to do that.

I thought things would be more open when MOULa started, but instead they’re more closed than before. Any incentive to work on stuff is crushed by Cyan’s continued silence, and the overwhelmingly vocal disapproval of many community members. We all have bad days where we ask “Why do I put up with this?”; but when you’re seriously asking yourself that question every time you think of Uru, maybe it’s time to move on. I don’t want to be part of this anymore.

Uru’s dead, more dead now than before MOULa started. I keep wanting things to change, but I can’t keep pretending that they ever will. Cyan can’t make Uru work. They’ve lost direction and fragmented so much that the only thing keeping them in business is rehashing existing games on new platforms. The “Golden era” ended with Prologue, and came to a crashing halt after Myst V. MOUL never managed to bring any of that back.

The future is uncertain. I can say for sure that prpl-uruki will probably never be finished, and libHSPlasma development has mostly stopped as all the developers lost interest. PyPRP2 is up in the air, very dependent on what happens with Blender and whether there’s still enough interest to keep developing it. Without maintenance and support for the current tools, Age builders will lose interest and drift away, and with them goes any lingering hope for Uru’s potential.

For now, we keep waiting… but maybe someday you have to accept that the story’s over.

by

Moodle 2.0 Theme Contest: Silvern

Announced at http://newschoollearning.com/theme/contest/, I decided that this was the perfect excuse to actually finish the theme that I’ve been developing for over a year.

That year has been interesting, since almost every single piece of code related to themes has changes multiple times, requiring a number of theme rewrites to keep it all up-to-date. I seem to repeatedly have this issue with writing lots of code for something that’s in active development, and then rewriting that code to keep up with the API changes. >.>

The theme uses one of the new custom renderer classes to output HTML5, and includes a number of admin-configurable settings such as colours, welcome text, and the site logo.
My entry is called Silvern.

Silvern Moodle Theme

Silvern Moodle Theme

Edit: I almost forgot to mention: All the code for this theme is available on my github account. Enjoy :)

by

Future of the Web 20100620

  • Starbursts using only CSS3+HTML are a cool idea, and produce a cool effect if used in moderation. Sadly some of the outrageous hover effects on the starbusts near the bottom of the post remind me of terrible GIF rollovers and Flash buttons that plagued the web for years. (Anyoneelse getting GeoCities flashbacks?)
  • This has been around for a bit, but I didn’t find it until I was looking up some CSS animation stuff. Star Wars AT-AT Walker using only CSS animations. There’s also a blog post that explains how it was done.
  • Safari 5 supports border-radius without the -webkit- prefix! Let’s hope for the same in Firefox 4.
  • As cool as it may be, I really hope we don’t start seeing webpages that are designed like http://www.useragentman.com/tests/cssSandpaper/cube3.html. CSS is awesome, but some things should not be used for certain purposes. (HTML is awesome, but <blink>/<marquee> should be used for any purposes ;) ).
by

Future of the Web 20100602

Today’s dose of supercool comes via Tom (thegreatN). Seriously, between him and Sören (chucker) I get all sorts of awesome things to read about and play with!

  • Smokescreen (http://smokescreen.us/)
    Go look at that. Yes, those are indeed Strongbad flash videos being rendered without flash. Using JavaScript and (as far as I can tell) inline SVG elements. Not only does it render without the need of a plugin (which leaks memory), but it also doesn’t require any extra effort from the content creators. It takes an existing .swf file and plays it back without a plugin. Very cool!

    Now, it’s definitely not flawless. The SVG rendering is subtly different than the Flash rendering, most noticeably with this demo. The flash text is easier to read, and it appears that there is a border around the SVG text. As well, in that demo you can see that the blurred “data waves” are rendered without blurring in SVG (although with filters it should be possible to replicate), and that the “Find out here” button has no hover events in SVG.
    That last point is an interesting one, since SVG elements can respond to JavaScript events just like any other HTML element. There is no reason that clickable links couldn’t be implemented using xlink a tags. On the other hand, the project seems to be relatively new so it’s highly impressive that they have as much progress as they do.

  • iPads are cool, and fun… but not necessarily useful enough for me to seriously consider getting one. I will definitely be looking at how to improve my websites for iPad users though.
  • Neither cool, nor fun, is Adobe’s latest announcement. Rather than just take a magazine article and format it into a nicely design HTML site, they export it as .png images. Including animations. This is practically intentionally taking steps backwards!
  • Fun little personal project: Nadnerb wrote a raytracer using JavaScript and canvas. Very blatant abuse of Javascript, something that I hope nobody ever tries to use on an actual website, and also very very cool. I wanted to see if I could make it run any faster, so I started with basic JavaScript optimisations and ended with rewriting the sphere-ray intersection code. My revised version should be noticeably faster though! (Despite that, I should warn against running it in Firefox because it will freeze the browser and prompt you to continue for a long while)
  • I think this might be even better than a raytracer though (certainly less laggy!): Normal mapping with JavaScript and the canvas tag. The web is so awesome that I can’t describe it sometimes! (via @zib_redlektab)
by

Future of the Web 20100521

by

“Future of the Web”

Given the amount of very cool things happening on a daily basis in the world of HTML5, CSS, SVG, and the web in general, it would be cool to have a place to share thoughts, ideas, and cool links. (Idea largely stolen from Sören‘s “Chuckellania”.) I always like to watch for cool developments, and since beginning work at Ayogo Games, Inc. as a co-op student, I’m seeing cool links on an almost daily basis.

  • Support for CSS’s @font-face construct is surprisingly widespread, support in some form or another by all major browsers. Of course, the font formats that are supported vary widly from platform to platform. IE supports only the strange EOT format, while everyone else supports TTF and OTF. Firefox prefers WOFF, which is also supported by Webkit and IE9.
    Google is now offering “web fonts” of the future, hosted CSS files that contain the @font-face definitions. They also have an entire webfonts API to control font loading.
    It is great to see fonts like Droid on there (which is an entirely free font, used by my blog and my Ubuntu theme). However, a quick look at their CSS seems to indicate that the fonts are in TTF format only, which might limit their use on IE.
  • I played around with the IE9 Preview 2, mostly in IETester so that I wasn’t restricted to example pages. I was highly surprised that the rendered output was on par with that of older Firefox builds, but with much smoother text. Seems that the switch to DirectWrite was worth it. Of the CSS features I had in my test, the only thing IE9 was noticeably missing was text-shadow, which is rather minor. Now we just hope for speedy adoption, which might be an issue given the lack of support for Windows XP.
  • On the subject of IE9′s standards compliance, it currently handles HTML5′s <svg> tag better than Webkit. Firefox 4 will support is with the HTML5 rendering engine, but Webkit browsers only support inline SVG content when the page is served at XHTML. The bugzilla issue doesn’t seem to have caught anyone’s attention yet.
  • HTML5 video is starting to take off, with IE9 announcing that they will support H.264 encoded video playback. As much as I would like to see a fully open codec used, with Apple, Microsoft, and Google (via YouTube) putting support behind H.264, I think the battle is over before it really began. It would be nice to see some sort of official agreement made that would allow an open-source H.264 codec to be shipped in all browsers without worrying about patent issues. Opera seems to be planning to use existing backends such as GStreamer for its video implementation, leaving Firefox as the only browser without a way to view H.264 content. On the flip side, IE9 could be the only browser without a way to view OGG Theora content. Safari uses QuickTime for video, so even it can play Theora files after installing a codec.
  • Ending on a complaint… It is 2010. IE9 is in a preview stage with very good support for HTML5. All other browsers have equal or better support. But I still have to hack around transparent PNG images because of IE6. It is 2010. It is time stop dealing with IE6′s flaws. I don’t mean simply showing messages warning users about upgrades, I mean an actual refusal to deal with those browser issues. When that happens, we can start the same treatment for IE7.