New Style for phpBB 3.3 ?

[Louis7777]

Whining without proving something isn't going to get you anywhere. How is the weight of proof on me lol?

You have a nerve. You don't even know how selectors are read from right to left which is really basic knowledge and now you come back with attitude at me.

I won't repeat myself. You made a claim. The weight of proof is on you so prove it. Cheers.

[Rhino.Freak]

You made a claim too, and you can't prove it.
I still believe it's best to avoid IDs, because we can. Cheers indeed!

[Louis7777]

You made a claim too, and you can't prove it.

Exactly what was my claim? I wasn't the one that told anyone how to do his job.

You presented something as an absolute truth based on an article that someone wrote while lacking knowledge of your own, I asked you to elaborate on why you think Buddha exists and then you demand me to present you with a PhD thesis for my counter-arguments.

I'll agree to waste my time by providing you a couple of links:
http://csswizardry.com/2011/09/writing- ... selectors/
https://developer.mozilla.org/en-US/doc ... icient_CSS

I suggest that you read the chapter "Writing Efficient CSS Selectors" or "Simplifying CSS Selectors" from the book "Even Faster Websites" by Steve Souders, as mentioned at the article of the first link.
I pasted the second link only because it has many things in common with the chapter of the aforementioned book.

I'm sure that while trying to prove me wrong you will focus on "The difference in speed between an ID and a class is almost totally irrelevant.", however, for thousands of selectors and depending of course on how you wrote your selectors it can add up to milliseconds.

The comparison is between IDs and Classes. If you combine those with other selectors, then the difference in speed could become noticeable. Just a crazy example for the sake of an argument: #id * {} and .class * {}

Furthermore, you're asking me to prove something that is common sense even if you don't know that selectors are read from right to left.

The main reason I presented browser speed of matching elements was because you presented specificity as a bad thing.

And there's still the argument of a developer's speed of working with a style which you have overlooked.

I still believe it's best to avoid IDs, because we can.

Very professional statement.

[Rhino.Freak]

Now see that wasn't that tough was it? I politely asked I would love to get informed about the speed part of the selectors a few posts ago.
Okay you have indeed enlightened me that IDs aren't that bad.
But still, you didn't consider my argument of working style either. Using classes in a better and organized way can help us achieve the benefits you mention of IDs. Besides I don't think I said anything wrong either, as you're trying to portray.
Not using IDs isn't a sin.

[Louis7777]

But still, you didn't consider my argument of working style either. Using classes in a better and organized way can help us achieve the benefits you mention of IDs. Besides I don't think I said anything wrong either, as you're trying to portray.
Not using IDs isn't a sin.

Now that's a very different attitude than what your original one was:
"Whatever style you make and whenever you make, just never use any id in the markup. It's really useless and has no benefits over classes."

How isn't that wrong?

Please show a hint of the better and organized way.

I'll show you an example - taken from the previous article - of why I support IDs:

Code: Select all

<ul id="social">
    <li><a href="#" class="social-link twitter">Twitter</a></li>
    <li><a href="#" class="social-link facebook">Facebook</a></li>
    <li><a href="#" class="social-link dribble">Dribbble</a></li>
    <li><a href="#" class="social-link gplus">Google+</a></li>
</ul>

The difference in speed between matching all social links that live in a specific #social section and matching all social links that live in possibly multiple .social sections is irrelevant, although the former is still faster.

However, it makes no sense to use a .social class instead of a #social ID for a parent element which is most likely a unique section of the page. Of course it can additionally have a class if it shares styles (colors, fonts etc.) with other elements.

Better specificity provides for an easier job for the average developer and style author.

Consider the use case of selecting that ul element in Firebug, then locate the CSS and try out the changes, then go change it. If it was an ID, there's no problem. If it were a class, however, you may wonder whether other elements have been affected.

Plus, in the case of the ID I can easily add my own CSS to style child elements. What would I do if there was only a class in place?

[RMcGirr83]

Can you two knock it off please, if you want to banter about classes vs id's go do it in a separate topic or via PM. The purpose of this topic is not for you two to argue, right or wrong, about styling.

[Louis7777]

Can you two knock it off please, if you want to banter about classes vs id's go do it in a separate topic or via PM. The purpose of this topic is not for you two to argue, right or wrong, about styling.

Alright but... didn't you enjoy it... like at all??

[3Di]

To be honest? Too much a do.

[Lirodon]

Personally, I think we should internally support one of the compiled CSS formats (either SASS or LESS).

In other news, I was working on a topic list mockup. It's very much like what we have now but reimplemented using the new CSS framework/button styles (the New topic button is blue like the Search button on the header). I had also revised the forum list a bit to have the TOPICS and REPLIES labels directly under the numbers, redid some icons to better match the styleguide I'm following, and moved the header buttons to their own strip at the top (pushing the logo and text down a bit but keeping the container BG the same).

Unfortunately I am out of town at the moment so I don't have screenshots.

[Rhino.Freak]

Do you have a live testing board or you have set it up on localhost?
Well either ways it sounds good.

Off topic: I kinda enjoyed too and learned a bit too.