I have two types of event labels. The HTML markup is:

    <time class="reg-day">Mo</time>
    <time class="reg-time">13:00-14:30 Uhr</time>
    <p class="reg-location">Regent Street</p>

    <time class="work-month">Feb</time>
    <time class="work-day">24</time>
    <p class="work-type">Chess Group</p>
  <p class="work-location">Moonshine Avenue</p>

And the CSS the question is about is:

article {
    background-color: red;
    width: 20em;

.reg-day {
   position: absolute;

.reg-location {
   line-height: 1;

.work-month {
   -webkit-transform: rotate(270deg);
   position: absolute;

.work-day {
   position: absolute;

.work-location {
   margin-left: 5em;
   line-height: 1;

I have two types of event labels and have created a CodePen here.

The first one has the day on the left, the time on the upper right, and the location on the lower right.

The second has the month upright on the left, the day and on the upper right the type of event, and the location on the lower right.

Basically I've managed to get the layout as I wanted. Is the way I got there ok or is there a more robust and elegant one?

Especially the part of the day of week (of the first event type) and the day of month (of the second event type) covering more or less 2 height units of the two pieces of information on the right.

Day of week/day of month:

font-size: 3em;


font-size: 1em
line-height: 1.5; 

would work. That the info lines are the exact half of the day of week / day of month. Also i am unsure if using position absolute is the correct weapon of choice in that case. At least it prevents an misalignment of the margin-left: 5em elements. But over all the number of "magic numbers" feels a bit too high.

  • \$\begingroup\$ how robust do you want this to be? what happens when an event line is more than one? these are events, so how semantic do you want it to be? i can help, but idk what you want \$\endgroup\$
    – albert
    Jul 16, 2014 at 19:25
  • \$\begingroup\$ Cool! About the event line; it won't be longer than one line. I've already taken care that the content isn't longer than the available width. Ideally the two event types should be as robust as possible layout wise. In my used solution there are a few magic numbers i got by trial and error and not a clean mathematical built up layout. And about the html semantics, i know i left out the time attributes intentionally, the html part was thrown in together quickly. But those are the only parts i would change. Would you recommend further modifications??? \$\endgroup\$
    – rkoller
    Jul 16, 2014 at 19:56
  • \$\begingroup\$ are they related? why are their two locations? \$\endgroup\$
    – albert
    Jul 16, 2014 at 23:50
  • \$\begingroup\$ The first are regular events which take place every week, regular yoga courses, so it was no need for dates just the day of the week. The second type of events are yoga workshops lasting one to x days. And in the event display the infos (day monthy) of the first day when the event starts are used. And the two event types take place at the same base of locations. There are 3 to 4 different places the courses or workshops might takes place. \$\endgroup\$
    – rkoller
    Jul 17, 2014 at 7:22

1 Answer 1


There's a difference between magic numbers and values derived from calculations. A lot of your numbers aren't really magic, you just don't know the formula to get those values. You can start by creating variables of the things you know are going to impact your values (eg. font-size, line-height, etc.). Then you start looking for a formula you think will create your magic number. When it works, change one of the values and see if it still works. The width for $month is almost bulletproof, but the rest need help:

$padding: .5em;

$day-size: 2.25em;
$day-line-height: 1.5em;

$month-size: 1em;
$month-line-height: 1em;

body {
  padding: 10em;

time {
  outline: 1px solid;
  display: block;
  width: 3.5em;
  padding-left: $day-line-height;
  text-align: center;
  position: relative;

  .month {
     $width: $day-size * ($day-line-height / 1em);
     font-size: $month-size;
     transform: rotate(270deg);
     position: absolute;
     top: ($day-line-height - $month-line-height) / 2 + 1;
     left: ($width / $day-line-height - $month-size) * -1 + $padding;
     width: $width;
     text-align: center;
     line-height: $month-line-height;
     outline: 1px solid blue;

  .day {
     font-size: $day-size;
     line-height: $day-line-height;
     outline: 1px solid red;


If you look at the markup in the pen, you'll notice that it is a little different than what you're doing:

<time datetime="2014-06-30"><span class="month">June</span> <span class="day">30</span></time>

<time datetime="2014-02-24"><span class="month">Feb</span> <span class="day">24</span></time>

<time datetime="2014-09-15"><span class="month">Sept</span> <span class="day">15</span></time>

<time datetime="2014-05-04"><span class="month">May</span> <span class="day">4</span></time>

The time element should not be treated like a span, it has special meaning. If you don't have a valid date/time format (eg. 2014-05-04), then you need to use the datetime attribute to contain that information.

If you have two distinct times (such as your starting and ending time), then you should have two time elements:

<time datetime="2014-07-17T13:00Z">13:00</time>-<time datetime="2014-07-17T14:30Z">14:30</time>

Reference: http://www.brucelawson.co.uk/2012/best-of-time/

I don't feel that the article element is the appropriate choice for this type of information. An article is supposed to be for content that can be removed from the surrounding content and still make sense. An ordinary div or a table would be a better choice:

    <caption>Event Information</caption>


        <td>The Library</td>

        <td>Chess Club Meeting</td>

If the th/caption elements are cramping your style, just hide them. Tables don't have to look like tables. It's a bit rough, but you get the idea:


  • \$\begingroup\$ Sorry for the late reply and thanks a lot for the input! \$\endgroup\$
    – rkoller
    Jul 23, 2014 at 22:26
  • \$\begingroup\$ regarding "magic numbers"… a real valuable hint. So far i've tended to approach each value visually; each observed and tweaked on its own. But i think i go on with your recommendation from now on. Will apply your suggestion and play around a bit. \$\endgroup\$
    – rkoller
    Jul 23, 2014 at 22:29
  • \$\begingroup\$ regarding "time element"… the point about the two distinct dates i haven't know yet. Thx! The only issue i see is about the first event type. There i don't have a real date time to use at all since it is describing regular weekly dates, so it wouldn't even make sense to break it down to a single date. There isn't even a real "start date". It's more or less a weekly endless loop. :/ \$\endgroup\$
    – rkoller
    Jul 23, 2014 at 22:35
  • \$\begingroup\$ regarding "table element"… You are right if the event elements are displayed "as is" the article isn't the exact match and the table element might be a serious option to consider. I think the article element would only make sense if you could provide more background informations for each event - hidden per default but accessible via e.g. a checkbox hack so that you are able to blend in all the necessary background info - so each event could considered as stand alone information. Which would legitimate the article element again in that case? \$\endgroup\$
    – rkoller
    Jul 23, 2014 at 22:43
  • 1
    \$\begingroup\$ I think the initial spec for the time element specified that you had to have the exact time, but the article I linked to suggests that you are allowed to use it if you only know the date. There is a details element that's worth considering (however, I thought I saw it on the list of elements that are in danger of being deprecated). \$\endgroup\$
    – cimmanon
    Jul 23, 2014 at 23:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.