Tag: CSS

BattleTop

Jeroen

Exactly one month ago I wrote about Google Code hosting. At the time I wasn’t ready to divulge the project I was using to test it, but today’s different. Today, I have decided to put BattleTop in Beta!

BattleTop is a responsive single-page web application to assist in bookkeeping things like Characters, Initiative, Hit Points, Conditions, et cetera, during D20-based table top RPG sessions.

BattleTop Beta Logo
BattleTop Beta Logo

You can view it, clone it, and provide pull requests for it at Google Code. Mind you, it is still in beta, meaning there’s many rough edges and bugs to be found. I have been and will be dogfooding it during our own table top RPG sessions, so I’ll be sharing your frustrations about bugs and time permitting I will be fixing things.

The current list of features:

  • Track characters. Add and remove monsters, NPCs, PCs, and environment initiatives. You can also reset the list to the party, or to a blank, new list.
  • Track initiative. Keep initiative and initiative modifiers, sort the list by initiative, keep track of ready and delay actions.
  • Track conditions. Each character has its own list of conditions which you can add, remove or change, with a number of turns to it (so they wear off automatically).
  • Track hit points. Each character optionally has a number of hit points. You can deal damage or apply healing to change the hit point amount.
  • Save/Load. Using the LocalStorage API BattleTop will save your state every 5 seconds. If you navigate away or re-open the page on your next play session the old state will be there.

Note: because BattleTop extensively uses many modern features (html5 semantic markup, css3 features, modern JS such as LocalStorage), only modern browsers will be supported.

Here’s a general view of what it currently looks like:

 

BattleTop 0.9.0 Setup Mode
BattleTop 0.9.0 Setup Mode

 

BattleTop 0.9.0 Update Hit Points
BattleTop 0.9.0 Update Hit Points

The horrifying state of free Android initiative-keeping apps was what triggered me to create BattleTop. I’ve decided on a HTML5 app as opposed to a native app because (a) it would be easier for me to create something in a short amount of time, and (b) to keep it portable across devices and operating systems with little effort. Hopefully BattleTop will help or inspire others as well.

Sassy Styles

Jeroen

In my previous post I ranted about the way the design community seems to violate the DRY principle. Let’s revisit the code (and Repeat the code, I know, I know):

What’s going on here? Well, to get to our beloved Em measurements, we apparently need a calculation based on our body’s font-size (24px) and the h1 target font-size (16px). This “would make future adjustments much, much easier”.

It’s not that I dislike this really, but more that I despise (having to do) this. We’re saying “1.5em” here, only we’re doing it twice.

Last week I’ve tried one of the solutions to this: SASS. And let me say, this feels like it could be love at first sight! With SASS, the above snippet will quickly transform into the following:

Much better, no? We’ve now only stated once what the font-size should be: a certain fraction × 1em. I’m a little bit disappointed about needing the “* 1em” there, but hey: it’s a great reason to ask another Stack Overflow question.

Anyways, SASS doesn’t stop here. It will add more improvements, one of particular importance to the above snippet. Consider this:

What’s up with the additional lines of code? Isn’t that extra code bloat? Well no, those lines help us achieve two very important goals:

  1. Our calculation is now much more meaningful, and will now truly “make future adjustments much, much easier”.
  2. We can reuse those variables in our style sheets. In the somewhat contrived example above it doesn’t really shine, but you can surely imagine this is a great benefit to the entire style sheet.

For my current pet project I’ve tried SASS in a feature branch, but I’ve already closed that branch: it was merged into the main branch after only a few hours. With this I’m indeed implying there’s a very friendly learning curve for SASS.

And yes: I’m also implying that you should try it for yourself! There’s many more nice features I haven’t even mentioned yet. And if I didn’t convince you, perhaps the two-page tutorial will!

Measurements in Responsive Design

Jeroen

My wife called me out for looking at CSS through a pair of Programmer’s Glasses™. She hastily added this could well be a Good Thing, and I suppose I’ll just interpret it as a compliment. In fact, I must say I agree, feeling more like a “developer” than a “designer”.

Let’s first look at how we ended up at this name-calling. Here’s a code snippet from Ethan Marcotte‘s book Responsive Web Design from the A Book Apart series:

He then goes on to state that:

I usually put the math behind my measurements in a comment to the right-hand side of the line, which makes future adjustments much, much easier for me to make.

At first glance, this makes sense. However, in the long run, this feels really weird to me: it smells like code duplication. The actual result and the calculation in the comment both express the “what“, just in different form. It reminded me of Clean Code, where a whole chapter is dedicated to comments, and I’d think this would fall under the Bad Comments section (“Noisy Comment”, perhaps?).

Now I’m currently thinking I must be wrong: everyone who is something in responsive design is generating this type of sample code. Maybe it is because I should read this kind of code like:

Both forms describe what the font-size should be. Form 2 is probably “best” from a Clean Code point of view (as it’s most descriptive), but unfortunately only form 1 is valid (plain) CSS. As a compromise both forms are kept.

So, what are the options for improving things? There’s at least a few I can currently see:

  1. Combine “Form 1 and 2”. Accept that you’ll need discipline to keep the measurement and comment in synch. This is what the Responsive Design community leaders seem to practice.
  2. Just use “Form 1”. You’ll loose (or never have) the benefit of understanding your measurement.
  3. Use a CSS pre-processor. There are Sass and LESS, the most well-known ways to introduce (among others) calculations in stylesheets.
  4. CSS3 modules. The CSS3 Calculations module introduces calculations, and the Variables module may even take this one step further (as far as preventing code duplication is concerned).

To be honest, this list is currently my reverse order of preference. I’d love for option 4 (the CSS3 modules) to become a success. Until then, I’m bound to investigate the CSS pre-processors, because option 1 and 2 are both crappy, in my opinion.

Can haz layout

Jeroen

Contains IE Hack This weekend I decided to deep dive in a StackOverflow question on the combination of pseudo-elements and the IE8 (and lower) filters. Even though it seemed to me the question couldn’t be answered with 100% certainty, I still gave it a shot. A similar but better answer got accepted (damn you, “ScottS”!!), but that’s besides the point. The most important thing I learned from answering this question, is understanding the magic in IE (especially version 8 and below). So, for reference, here are the important links of articles that made me understand IE a bit better:

The kicker from all this research is that I now finally understand this remotely related line of CSS I’ve seen (and even used) a lot:

This is a CSS hack to get some versions of IE to behave nicely. So far, nothing new. However, after reading the above articles, I finally understand what it does: it  forces the hidden IE property hasLayout to true. And that’s useful for quite a few cases where you’d expect things to have layout, but when they don’t by default.

Hack or not, I’m glad I understand things a wee bit more now.

CSS syntax naming conventions

Jeroen 2 Comments

My next Stack Exchange Challenge post will most likely be about the Programmers SE. One part of the challenge is to actually ask a question I have on the topic. The question I came up with (to be honest, this has been bothering me for months now) took quite some time to write down carefully. So, as I don’t have my next SE Challenge post ready yet, I decided to cross-post my question here on my blog as well.

The Question: what are the practical considerations for the syntax in class and id values?

Note that I’m not asking about the semantics, i.e. the actual words that are being used, as for example described in this blogpost. There are a lot of resources on that side of naming conventions already, in fact obscuring my search for practical information on the various syntactical bits: casing, use of interpunction (specifically the - dash), specific characters to use or avoid, etc.

To sum up the reasons I’m asking this question:

  • The naming restrictions on id and class don’t naturally lead to any conventions
  • The abundance of resources on the semantic side of naming conventions obscure searches on the syntactic considerations
  • I couldn’t find any authorative source on this
  • There wasn’t any question on SE Programmers yet on this topic

Some of the conventions I’ve considered using:

CSS naming conventions
CSS naming conventions
  1. UpperCamelCase, mainly as a cross-over habit from server side coding
  2. lowerCamelCase, for consistency with JavaScript naming conventions
  3. css-style-classes, which is consistent with naming of css properties (but can be annoying when Ctrl+Shift+ArrowKey selection of text)
  4. with_under_scores, which I personally haven’t seen used much
  5. alllowercase, simple to remember but can be hard to read for longer names
  6. UPPERCASEFTW, as a great way to annoy your fellow programmers (perhaps combined with option 4 for readability)

And probably I’ve left out some important options or combinations as well. So: what considerations are there for naming conventions, and to which convention do they lead?

CSS first-letter drop caps

Jeroen 1 Comment

A little while ago this interesting Stack Overflow question caught my attention. The question is about drop caps: a typographical gimmick where the first letter of a paragraph is very big and prominent. In older texts this could be even more than “prominent”, for example this page from an old Dutch Bible:

Drop caps in an old Dutch Bible
Drop caps in an old Dutch Bible

Of course, the CSS pseudo-selector :first-letter seems perfect to achieve this effect on the web. The question on Stack Overflow used that as a starting point, and is about a particular situation where IE wouldn’t render correctly. While trying to find a solution to that particular problem I found out things were not so simple, and posted this answer. The answer basically came down to “no way to get it right in all browsers”. With rather “standard” CSS rules, various browsers gave varying results:

Rendering of drop caps in various browsers
Various browsers render drop caps differently

Not very satisfying at all! After thinking about this some more, I decided to try and at least get a “minimal” example of drop caps working in all current browsers. To keep things “minimal” my first try will:

  • Not bother with padding for now (just set them all at zero);
  • Not bother (yet) with browsers <IE9;
  • Stick to the basic 26 characters from the latin alphabet;
  • Stick with uppercase versions of those characters.

It took some time, but I did come up with decent results. You can show the example html file on my blog, or view it as a jsfiddle. The example contains a reset style and some coloring so you can see the results clearly. However, the nitty gritty is in this bit of CSS:

This actually gives acceptable and mostly consistent results. Here’s a screenshot of how this renders in up to date versions of my browsers (all on Windows 7):

Drop caps experiment in IE9
IE9
Drop caps experiment in Chrome
Google Chrome
Drop caps experiment in Opera
Opera
Drop caps experiment in Firefox
Firefox

Great! However, one browser is still not playing nice. No, not everyone’s “favorite” browser IE is acting weird, but Firefox is! Have a closer look at the left (:first-letter) rendering in Firefox: the height of the drop cap isn’t what we want it to be. However, some searching on Google leads to a related Stack Overflow question as well as this question, ultimately leading me to a bug from 2007 in Firefox. Guess it can’t be done easily then.

End of the road? Perhaps. But perhaps also a great opportunity to try and create a jQuery plugin that creates drop caps…

Re-discovering JavaScript

Jeroen

Around 1995 I started creating web pages. HTML was my friend, and analogous to the story of Adam and Eve, a companion called CSS was created. I considered HTML to be the robust male of the relationship, and CSS giving the beautiful female touch to my web pages.

Then Darkness came.

A brand new player invaded my perfect little web world and tried to make it into a love triangle. Enter JavaScript. At first this new technique looked awesome to me. I knew Turbo C++ 3.0  (with a nice DOS look and feel) as well as Visual Basic, and was eager to add some dynamic features to my web pages.

Oh how I underestimated the complexity. I knew no patterns, none of my code had ever been reviewed by others, and I tried to figure out everything with trial and error. Plus: I didn’t understand the DOM at all. So I ended up writing stuff like this:

The above snippet must have cost me a week to figure out. I was so frustrated I wanted to ban JavaScript from my pages as much as possible, which is exactly what I did when I learned to use Perl to add dynamic features to web sites.

More than a decade passed, but Darkness was still looming. I tried to stay in the Light with my happy couple HTML and CSS (only tolerating incidental guest appearances by JavaScript). I even turned to WinForms programming in .NET so I wouldn’t have to face the Darkness.

But then my ASP.NET days came, and it turned out: JavaScript was here to stay. However, my second encounter with JavaScript was mediated by jQuery, which had powers rivaling those of Dr. Phil himself. That library makes JavaScript feel like the love child of HTML and CSS, with a dynamic twist.

And so, JavaScript is getting a second chance. Any leftover JavaScript frustrations were explained in this presentation: I started to use JavaScript without ever learning it. So I picked up the corresponding book by Douglas Crockford, which shall be followed by The Definitive Guide. Hopefully this will allow me to Learn to Stop Worrying and Love the Bomb.

Foot note: at the time of writing, the piece of JavaScript code in this post is still running in production, in a Web Shop created in the 90’s, using Perl 5, HTML4, CSS2, and a hint of JavaScript…