And the Winner is Dawid Lizak
Dawid Lizak is from Łęczna – a small town in east Poland. He has been working in XHTML and CSS as a hobby since 2005. Dawid is currently expanding his knowledge of JavaScript, usability, accessibility, and new semantic web trends, which he hopes is evident in his CSS Off Jabroni entry. He has started a new personal web site just within the last few days, http://www.lizak.pl.
Dawid has chosen the $50 charitable donation as the reward for his winning entry. The funds will go to the Polsat Foundation, one of the largest charities in Poland, which helps ill children whose parents don’t have money for treatment.
Why Dawid Won
Dawid’s Jabroni entry had a great balance of good markup, organized CSS, and consistent browser rendering true to the original comp.
More about Dawid’s entry
Dawid avoided divitis by giving thought to each component and using more appropriate markup in key areas, such as the <ul> for the navigation, Upcoming Events, and Merchandise sections. The Jabroni-Mail form was marked up appropriately using <form>, <fieldset>, and <input> tags.
(Note: Other entries may have used different markup for those components, but the markup was just as relevant and meaningful to the content as Dawid’s. That’s ok!)
Dawid was one of many participants that chose to expand the banner to full-width of the browser instead of sticking to the 800-pixel width of the comp. Though we appreciate some of the entries wanting to create a pixel-perfect rendition of the Jabroni psd, no more no less, we were actually hoping there would be deviation from the design when it made sense to do so. Expanding the width, we feel, was one of those instances when it made sense.
I want to emphasize that Dawid did not win because he used access keys. My fear is that all future submissions will be laden with access keys just because the first winner’s entry had them. Please only do this when the site calls for it. I, for one, did not necessarily feel that a wrestling boot retailer web site gets much value from access keys, but they were implemented well. The net effect on the judging of Lazik’s entry was zero.
With all due respect to Dawid, we felt his markup was not without its flaws. We would’ve preferred to see Customer Support in title case and used CSS to transform it to uppercase instead of uppercasing it in the markup. Also, we feel it should’ve been a link. One of the judges thinks that “Enter a Fake Email Address” should’ve probably been in a <label> tag. One of the judges also would’ve preferred to see the Merchadise images as actual <img> tags rather than CSS background images, and would’ve preferred a more obvious hover state for those departments. Of course, we’re being very subjective and in real life our opinions about this matter are no better than yours, so we try to be open to interpretations.
About our decision
This was a tough call to make. There are other entries that had better markup. There are other entries that took more impressive creative liberties with the design. There are other entries that render and scale better across browsers. We were able to whittle the entries down to a handful that we felt had the best combination. If you asked us why we chose Dawid out of that handful, the answer is that we can’t remember, but we’re happy with the decision.
About other entries
Some of you…
- Used favicons (
Entry 13;
Entry 22;
Entry 22)
- Used Eric Meyer’s CSS Reset method
- Used images instead of text for headlines and the date box
- Used cool hover effects for the date box
- Used liquid layouts
- Kept the fixed width, but used a matching background color
- Made some bold decisions
- Made your own choices for fonts
- Used javascript to validate email
- Used mootools.js for no other reason than for the navigation’s presentation (we find this a bit troubling)
- used tables for layout — just kidding!
Take a look for yourself at all the differences, both with the design and with the markup, at our index of every entry.
Some thoughts about your submissions
We welcomed design tweaks, as long as it looked ok. For example, in entry 45, it was a perfectly ok design decision to have the black banner run straight into the purple background, but we would’ve liked to have seen the banner altered so that it had a gradient back to the purple color on the left.
Navigation
We saw plenty of variety here, not so much in the markup, but in the CSS. When this comp was designed, it was purposefully designed so that the navigation would be a bit tricky to pull off. The curved tops for the “on” state and segmentation between each tab were meant to be the challenge. Most of you handled the markup beautifully, using an unordered list with list items arranged inline, with the <a> or possibly a nested <span>/<em>/etc. to help with the right and left background images. We don’t mean to pick on our audience, but we need to show an example of what not to do. Consider the following markup from one entry:
See those “splitter” classes in there? Those were used to create the dividers between each list item. Some might ask, what’s wrong with that? How is that different from using an empty <div> elsewhere in the markup to achieve a presentational effect?
The problem is semantics. The navigation is a menu of list items, and each of those list items should represent another page to visit. But that isn’t true in the above markup. Some list items are a page to visit, and other list items in same list are just there to throw in a visual effect. The meaning behind a list item in this menu falls apart. If that’s not enough, consider what happens if CSS is disabled — the list is potentially confusing.
On top of that, the flexibility we could have had in modifying the presentation of this list is now crippled by having to deal with extra list items that have no meaning whatsoever to the content.
The judges looked at how every entry’s navigation kept its design integrity when the browser font size was adjusted in every browser, including IE6. This was a toughy for many, as sometimes the list items would disappear behind the angry wrestler image, and other times wouldn’t resize at all. Many of you created a nav that maintained readability no matter how much it scaled. Great job! We realize what a challenge that must’ve been. To see just how challenging that must’ve been, we came up with our own Jabroni navigation.
About the judging process
Sorry we’re late. As we said up front, we don’t have everything figured out. That applies to the judging process, too.
As a couple of you have mentioned in the comments, having to wait longer than a week for results leads to a bit of impatience. That’s understandable — it would be ideal to have the results within a short enough timeframe so that the competition is still fresh in our minds. We have to admit that we were excited about the contest, but gave little thought as to how to proceed after that deadline. We reviewed blocks of entries on a certain set of criteria, took notes, then realized we need to do it again with another set of criteria, and got a bit flustered, because it was getting more time-consuming than originally anticipated, and thought to organizing the notes wasn’t given until much later.
I think we have a better handle on how to do that going forward, but for this time around, you may see notes on our entry table that aren’t all that cohesive, meaningful, complete, nice, fair, or even there. We’ll try to do better next time.
To all that participated
To all that participated, thank you immensely. Subscribe to our feed (left column) for future contest announcements.
Why did he win? His didn’t use labels, none of the events were links, and the footer didn’t attach to the bottom of the window. I saw plenty of other entries that did these things, so i am asking, why did he win? Also, what do the colors mean on the entries chart?
Congratulations Dawid. Your markup is truly the best.
Thank you for great contest! I’m looking forward to win next time! ;-))) Congratulations for winner!
Gratulacje dla Dawida!
Most entries from Poland were the best!
I’m happy that somebody of my city (and country) won this competition.
By the way: Polsat Foundation is foundation for sick, little children, which parents cannot afford curing.
First of all: congrats Dawid! Indeed, the entry isn’t perfect, but just a nice balance between all.
I think I’ve screwed upmy menu. Not the markup, but the CSS. I could have done this better, but I hadn’t all the time. Next time, I hope I’ll solve this things better. By the way, the menu you both have built, isn’t centered. Together with the rest of the menu that gave me some problems (especially in IE6 and 7).
I hope everybody will have a look at your notes in the listening, they are very helpful.
Arjan, I can see that you send greetings to Dawid but still you cannot agree with the judgement. If you didn’t have enough time to create good entry you should not take part in the contest. But please do not explain that you had no time. It doesn’t matter for us.
The winner is Dawid.
Particularly as they are generally considered problematic, and in the WCAG Sumurai’s errata to WCAG 1.0 have been explicitly banned.
Otherwise, well done David.
Congrats Dawid!
A really good start to the contest! A shame mine didn’t validate properly (bloody form!)…oh well, will have to aim for full marks next time!
nice Vadit ;)
« We would’ve preferred to see Customer Support in title case and used CSS to transform it to uppercase instead of uppercasing it in the markup. Also, we feel it should’ve been a link. Also, we feel it should’ve been a link. One of the judges thinks that “Enter a Fake Email Address” »
In my work I take note of flexibility. Footer is very high, and I think that somebody want to put there full Customer Support informations. Next, link style in footer is defined. User have freedom, he can put them plain text, or links.
You’re right about label markup. Next time I try to write fully-semantic code :)
Zdanek, I do agree with the judgement. Come on, that’s not what I meant with my comment.
It is great to have a look at the different entries.
Looking forward for next contest.
Congratulations, David! I’ve learned a lot from this contest, thank you Tony and JD.
“One of the judges also would’ve preferred to see the Merchadise images as actual tags rather than CSS background images(…)” - no comments
@joe:
To see why Dawid won, go to the section in this post titled “Why Dawid Won” and “More about Dawid’s entry”.
On the index of all the entries, I have included a little more description about what the colors mean.
At least I saw that his layout was verry similar to mine. To me that means that my skills are good.
Also I sow verry little people that actualy made a hover effect for the menu as Dawid did, and as I did.
Congratulations Dawid.
I totally agree with result (btw: GRATULACJE DAWID :)).
David’s work was not flawless but it’s definitely the best.. I think it has most PSD faithful rendering among browsers (with one flaw: it breaks in small size window) and looks good with text resizing and with images off (just few works were comparable at that part).
In terms of semantics it is good.. but it has some controversial solutions (to me).. but unless w3c doesn’t give us ready receipt for that, it’s hard to dismiss someone’s work because we think a bit different..
Anyway things I wouldn’t do (just to share my thoughts not to dismiss :) :
- there are clearly presentational elements used clearly for presentation (<hr />’s, and <b>’s’ in menu) - (I understand that they’re to give better presentational look to “unstyled” content - but to me it is a bit like being one leg in html 2.0 and other in html 4.0 - I really think that in 2007 we should forget about presentation through markup).
Similar thing with element within form - to me it’s same misconception as using e.g. class=”red” (if people would have element they would use it instead ;).
- ‘Wrestling boots for web geeks’ were simple text not image - they were just using uncommon font - I would use one of image replacement techniques for that (I can’t wait @font-face! )
- <strong> element is used inappropriately in upcoming events list. <strong> is inline element meant to emphasize part of text within text.. like word within sentence.. or sentence within paragraph.. Here you’ve used it for what’s clearly a title/heading so should be used.. it’s block element.. and even that you’ve used later indicates that we’re dealing with block element here (you’ve replaced it with inline+br). Below you have what’s a paragraph of text and you’ve used element.
- presentational class names (leftSide, rightSide, top, bigNote) (what’s left or right when there are no styles? :)
- lack of label for email input
- Unnecessary use of fieldset (I believe that in this case also purely presentational - border with css off (?)) - I disagree with judges in that case - I understand that fieldset is to group thematically related form controls.. but there’s no need for grouping when we have one group ( element groups them clear enough I think).. - it’s similar to calling one element a list.
- Merchandise images definitely should be part of markup - they’re not part of decoration but content. Client shouldn’t mess with CSS just because he wants to change image for one item in a list or add another one.
- In CSS too many fixed widths. Just one is enough rest should be relative - it’s easier then with one edit to change body width to e.g. 1024px
Anyway I think that indeed you deserved first place :)
@judges - how should I understand note:
“upcoming events dates are not consistent. i’m not showing the day on a new line after the month.” by entry 31..
I didn’t use ’s there..I have problems understanding your point.
uups.. sorry I had no idea.. that markup changes to markup :)
I meant:
(..) (hr’s, and b’s’ in menu) (…)
(..)Similar thing with ’small’ element within form(…)
..etc..
@medyk:
The note about the upcoming events turned out to be a FF2 for mac issue only (not on windows). In FF2 for mac, the upcoming events calendars appeared like this: (link to screenshot) Note that the day for the top two items stayed on the same line as the month. We blame the inconsistencies of FF2 across platforms for the issue - obviously not everyone has a mac at their disposal for checking for these inconsistencies. Ideally, FF2 mac would’ve rendered it identical to FF2 windows.
Thanks for clarification.. I never tested FF under mac assuming it will be same as on windows.. and it’s actually second time I got caught on difference. Thanks for pointing that
You’re right, my work isn’t flawless. Thanks for remarks. I’ve much learned owning this contest and you.
Well, in short… ;)
- - for accent Accesskey, :first-letter doesn’t works.
- - for separation page in text browsers.
- about in upcoming events you may have right.
- presentional class names – you’re right, but it’s purposely, these elments have weight only in presentation layer, not structural, and they don’t including special content, look e.g. “date” class used in events list.
- label in form - i wrote about this.
- fieldset - you’re right
Once again thanks for comments.
in previous comment:
<b> - for accent Accesskey
<hr /> - for separation
little mistake, is late-night ;)
Re the fieldset, an inline element can not be the direct child of a form in xhtml 1.0 strict. The fieldset is the most semantically correct choice here, as it makes much more sense to use a fieldset to contain a couple of inputs than it does a p or div.
Fieldset was the correct choice, and all forms should use them.
Hey Congratulations David and CSSOFF!
I didn’t have the time to enter this contest (though I did try it). I look forward to July 1st!
Cheers!
Nice code, I’m glad that someone from Poland won! :-) (Gratulacje)
Anyway, IMO there are few things that could have been done better.
1. Layout breaks when width of the window is small enough.
2. I would use ‘if IE lte 7′ instead of ‘if IE’ - who knows what will happen in IE8 ?
3. ‘xml:lang=”pl” lang=”pl”‘?
4. Defining your font-sizes in px makes IE users unable to resize text.
I’m looking forward to the next contest, I had no time for this one. :)
[…] first competition results of the CSS OFF Competition is in, and it looks like we have a winner! Congratulations Dawid […]
Congratulations David, very nice, clean and structured CSS. Looking forward for the next round (July 1?).
Ad 2. who knows what will happen in IE8 when I use ‘if IE lte 7′? :) it is thing (these few characters) which anybody can fast change.
Ad 3. ‘xml:lang=”pl” lang=”pl”‘
it’s my template, that I using in my all works, I forget to change this ;)
@Dan ott
Fieldset is an optional element and it is for a reason.
Fieldset should be used for grouping thematically related controls.. this is exactly what w3c rec says - it doesn’t say that form should have one or more fieldset - I think it’s overuse to put fieldset in any form.
Form is really an interaction layer that we put on top of real structure. Form can consists of table of list or of whichever block elements. Fieldsets are there just for clear separation of form sections so then they’re more accessible - if we have just one section then ‘form’ element groups controls clear enough.
Generally fieldset element is a weak part of HTML recommendation as all it does is sectioning and why we can only section form controls (?) - it would be helpful if we would have some general ’section’ element so we could section not only form controls - and that’s the way it is in XHTML 2.0 there’s no more ‘fieldset’ element but we have more general ’section’ element.
Cool!, this was really great!!
[…] w serwisie CSS OFF. Gratulacje! Szczegółowe uzasadnienie i komentarze można znaleźć na stronie konkursu.Komentarz do mojej pracy: Room for […]
[…] come up with the best standards-based solution using images, css, and (x)html. I entered in the first contest, and had a great time (here’s my entry). It’s just pure fun. If you win, you can […]
[…] Also thinks we didn’t like are added, with some ideas how we would do it. Have a look at the previous results to see how extensive the entries are being […]
[…] w serwisie CSS OFF. Gratulacje! Szczegółowe uzasadnienie i komentarze można znaleźć na stronie konkursu.Komentarz do mojej pracy: Room for […]