It's been a while since we had a quiz so her are two little quizzes to help make the week whiz by.

The first quiz (brought to you by Rayzur) is cure a real life problem in webkit browsers when using display:inline-block and you will need to find a solution to the white space problem that inline-block causes.

The second quiz is "just for fun" so please no comments about not styling form controls as I don't expect you to use this technique for real but as an exercise in solving problems. The task is to style an input of the "type='file'" which (if you google it) has never been fully achieved without using javascript at some stage.

[B]==============================================First Quiz.

[/B][B]Fix The Webkit Inline-Block + Word-Spacing Bug[/B]

There are many times when we need to have "Centered Widthless Blocks" in a simple UL. That is easily accomplished by setting text-align:center on the UL and then setting display:inline-block; on the LI. Since the list items are still actually following the rules of inline elements we get white-space nodes when the HTML is formatted in the normal manner.

There are many tricks to hiding the white-space nodes but they all fall short in the Webkit browser engine. It was a hot topic of discussion in this recent thread.

The font-size:0; trick: only allows us to reset the children font-sizes in pixel values and it still leaves about a 1px gap in Chrome and Safari (both using the Webkit engine). That just doesn't give enough flexibility nor does it resolve the problem completely.

The word-spacing:-1em; trick: works well for all other modern browsers since they do not collapse the over-sized negative values. That is really our best option until/ if white-space-collapse: is accepted into the CSS3 specs. The problem is that Webkit completely ignores the word-spacing property when it is used on inline-blocks.

Other tricks: include using extra wrapping divs or altering the HTML tags by chaining them together. Those methods do work but they have their downsides too. They are discussed in detail within the thread link above.

I have also set up a test-case which explains the buggy behavior with Webkit. It can be found in Post #33 of that discussion thread.

Your goal is to take the code below as a starting point and find a pure CSS solution to the "Webkit Inline-Block + Word-Spacing Bug". Yes, there is a solution to it and it is very simple. It should not require more than two new rules in the css to bring it to a fully X-Browser solution.

Rules: (There are always rules)

Do not alter the HTML format for the quiz. That means no tag-chaining to remove white-space nodes.

Do not remove or edit the css rules that are commented with: /* DO NOT ALTER RULE */ ... (e.g. .nav li {

You are free to edit or add whatever you choose below these comments: /* EDIT and ADD rules below as you choose! */

No CSS hacks or Webkit @media screen targeting.

No Javascript

Remember we are solving the inline-block problem so there will be no prizes for removing the inline-block and using some other method such as floating etc.

If anything is not clear or if I have made a mistake somewhere then just shout.

Remember this is to solve a real life problem and will result in a fully workable solution but there will be no prizes other than the satisfaction of completing the task.Don't post your answers in this thread but PM with the details instead so that all can have a go.[B]==========================================Quiz 2.

Style a File input button without using javascript

Disclaimer: [/B]I know I always tell you not to mess around with styling form elements because they vary so much between browsers and you will usually end up breaking their function in some way but just for the purposes of this quiz forget about that for a minute (Indeed if anyone feels the need to voice the same opinion then please don't as I will just remove any posts that aren't taking part in the actual quiz.)

The task is to style an input file field so that it matches the attachment called file-input.png. This is styled using only background colours and borders and no images. The attachment file-input2.png shows another example that has been styled with a background image to show that it is possible to use images also.

In each attachment you can see the normal state, the hover state, and the state when the filename has been selected.

In the first atttachment I have also shown the normal state of the button when not styled just for reference.

The browser support required is IE7+, Firefox 3+ and Opera10+. As you can see from attachment 1 Safari/Chrome don't play ball very nicely so we won't worry about them. However, If you can find a solution that I didn't then all the better.

This needs to be a fully working example that allows you to select the file and displays it in the input box as shown in the attachments. No scripting is allowed - just use html/css although for IE you may need to use some common hacks.

Use whatever css and html you need and here is some basic html you can change to your hearts content.

If anything is unclear or I have made an error in my logic then just shout. The winner won't necessarily be the first correct one I receive (but the first entry always gets a big mention and may indeed be the preferred solution).

Remember this is just for funand there are no prizes.Don't post your answers in this thread but PM with the details instead so that all can have a go.

i hereby declare openly that Paul O'B is a dictator and as such i choose to be a dissident and not obey his rule! i will not comply to any forced labour he may impose on me! down with the dictator! stop tormenting webkit browsers! freedom for the webkit browsers!

It's really not ironic when you think about it. IE6/7 are not modern browsers and they do not have native support for inline-block. The tripswitch is the only way to get them to display the blocks inline, and even then they do not render the nodes.

Webkit is a modern browser and this has been a frustrating bug for quite some time. They need to get it fixed because the inline-blocks should in fact be following the same initial rules as display:inline. I have mentioned that in the thread.

The point of that rule was to encourage you to find the solution which in fact does not require a hack at all.

Yes that is ironic and I suppose for the quiz we should have said forget about IE for the time being as we all know how to make then work but at the same time we didn't want you to break it for IE either which is why the code was left in place.

We are really only interested in you solving the webkit bug using valid usable code and didn't want to send you on a wild goose chase through miles of advanced css3 and webkit vendor extensions looking for a solution.

This one is particularly annoying for me as not being able to change markup OR THE CSS? What the ****?!? My solution in this case is always don't use inline-block; either float them or use display:table-cell...

Since as a rule I would never put inline-block on a LI since IE knows it not... usually when I need this there are ANCHORS inside the LI and I'd probably never use inline-block on anything other than a menu.

I suppose adding a new display rule after the 'feel free to edit' would be cheating?

Already walking away from the first one as "oh, **** this"

Let's see the second one... and no. Given how completely screwed up Sucko and Web**** are on styling form elements (which is to say they won't do it at all) much less that FF will not accept width or height the same as other browsers I don't see how that's even possible even with CSS3... Which is what I'm assuming is being alluded to.

We are really only interested in you solving the webkit bug using valid usable code and didn't want to send you on a wild goose chase through miles of advanced css3 and webkit vendor extensions looking for a solution.

Oh, and it's broken in the last version of nyetscape in gecko mode as well as iceweasel here because it omits the OTHER more recent gecko property - display:-moz-inline-block; inline-box is for pre gecko 1.5, between 1.5 and 1.8 you need inline-block, and declaring both (-moz-inine-block first) fixes bugs in various versions of gecko based browsers that are SUPPOSED to support -moz-inline-block but still screw it up.

It's really not ironic when you think about it. IE6/7 are not modern browsers and they do not have native support for inline-block. The tripswitch is the only way to get them to display the blocks inline, and even then they do not render the nodes.

You can change the CSS , just not the ones that say: /*DO NOT ALTER RULE*/

At which point why the restriction on changing or removing them, as isn't overriding them the same thing?

I mean in my version, that code would be overridden by my sending the two values that would kind-of make it work... to the point that code might as well not even be in the source.

Though the obvious solution of letter-spacing (which I'm willing to bet people are trying to use and SHOULD be mentioned in the original post!) should NOT be the correct answer either, since you cannot predict the character width of a space cross-system.

In fact anything that uses letter-spacing or negative margin tricks is pretty much NOT a correct answer! Or am I intentionally ignoring the 'corrent' answer? (In which case enjoy your centering being broken in FF -- though you already have that with the word-spacing!)

At which point why the restriction on changing or removing them, as isn't overriding them the same thing?

I made some edits to my last post ^

I mean in my version, that code would be overridden by my sending the two values that would kind-of make it work... to the point that code might as well not even be in the source.

We are working with inline-block on the LI

Though the obvious solution of letter-spacing (which I'm willing to bet people are trying to use and SHOULD be mentioned in the original post!) should NOT be the correct answer either, since you cannot predict the character width of a space cross-system.

In fact anything that uses letter-spacing or negative margin tricks is pretty much NOT a correct answer!

At least in K-Meleon (FF2 engine), the last-listed -moz statement overrules the first one. So I've stopped using both block and box together, because then I always have "box" which sometimes doesn't do what I'm after.

As Ray said we are looking for a cure for the webit bug with inline-block. Changing or over-riding the inline-block to something else may make the display work but doesn't actually address the bug at all.

If I said I wanted you to fix the IE double margin float bug and you simply changed the float to non floated so that the margin worked properly then that would not address the original issue although it may superficially make it look the same.

However, I will say that if you do have good alternative or different methods of producing the above then we would still like to see them even if they don't precisely fit into the quiz aspect.

Regarding the file input challenge:

Let's see the second one... and no. Given how completely screwed up Sucko and Web**** are on styling form elements (which is to say they won't do it at all) much less that FF will not accept width or height the same as other browsers I don't see how that's even possible even with CSS3... Which is what I'm assuming is being alluded to.

Remember the second quiz is just for fun but is quite a challenge. I have already said not to worry about Safari and I have shown a picture of how my version works in safari. The screenshots I attached are actual working versions from Opera and Firefox.

One of the key properties required is CSS3 but is a common property that all browsers except IE have implemented for years (that's a big clue) and indeed some well known sites list it as a css2 property even though it's not.