Wedge

Public area => The Pub => Features => Topic started by: Arantor on April 11th, 2013, 07:20 PM

Title: CSS inheritance issue
Post by: Arantor on April 11th, 2013, 07:20 PM
So, I want to add a new icon to the buttons, we have a tick and a cross and stuff like that, and I want to add a (!) button (i.e. using the warning icon)

Now, I don't want this in the main index.css file for obvious reasons so I thought, you know what, I'll put it in index.member.css, and extend input.submit that way.

So index.member.css has:
Code: [Select]
input.warn extends input.submit
background: url($images/warning_ban.gif) no-repeat
background-color: #fff0e3
:hover
background-color: #fff5e8

Except, and this is the troublesome part, this part is declared, effectively, before my input.warn class:
Code: [Select]
// Declare position only here, so that inherited classes can also set it.
input.submit
background-position: 5px center

So background-position gets overridden by input.warn's own declaration.

I don't know how to deal with this in a good way since index.member.css stuff is loaded after index.css, but I don't really want to add this to index.css if I can help it. I think I'll just have to add background-position directly to input.warn :(
Title: Re: CSS inheritance issue
Post by: Nao on April 11th, 2013, 08:01 PM
i don't get it. I'll have to look into the code in context.

Did you try with a mixes instead..?
I tend to use them a lot these days. Sometimes they compress better ;)
Title: Re: CSS inheritance issue
Post by: Arantor on April 11th, 2013, 09:43 PM
The context is straight forward - input.submit declares some stuff, for its main declaration, further down - but *after* all the main input.whatever classes. And then input.member.css is declared after that.

I don't see a mixes would solve this - it's simply that unless input.submit's declaration for background-position is somehow after the content of index.member.css being included, it can't be done.
Title: Re: CSS inheritance issue
Post by: Nao on April 12th, 2013, 12:15 AM
Oh...
extra.css then..? It's what this one is there for... ;)

So, extra.member.css is good to ensure it's added after index files, and still restricted to members. Or just extra.css.
This is for a core feature..? Like, in the Wedge SVN? I suppose not, otherwise you'd have added it directly to index.member.css..?
Title: Re: CSS inheritance issue
Post by: Arantor on April 12th, 2013, 12:18 AM
Quote
This is for a core feature..? Like, in the Wedge SVN? I suppose not, otherwise you'd have added it directly to index.member.css..?
That's the point. I DID add it to index.member.css. But it doesn't work! It needs to use the first half of input.submit's definition (because it extends input.submit) but it needs to be declared before the end of input.submit's declaration (the bit I quoted) because the background declaration in input.warn overrides input.submit's declaration of background-position.
Title: Re: CSS inheritance issue
Post by: Nao on April 13th, 2013, 09:45 AM
Okay, I had a quick look, and I can't for the life of me remember why I did that background-position thing, especially since it doesn't match the description... :-/ I would logically have added a 'final' keyword to the input.submit re-declaration, and this would have have the effect of doing exactly what you wanted, i.e. no influence over your background-position. Except, the other buttons also need the same background-position...
Honestly, I can't remember either why I did all of this weird stuff in button declarations. I do remember fixing a lot of bugs across multiple browsers, and that there were many precedence problems. I think one of these bugs took me days to fix..

Still. I don't see why you're not declaring this way..?

Code: [Select]
input.warn extends input.submit
background: #fff0e3 url($images/warning_ban.gif) 5px center no-repeat
:hover
background-color: #fff5e8

Doesn't compress as well, I reckon, but still, no precedence problem..?
Or simply -- just add the background-position: 5px center line in there as well...

The idea is that 'background' is a shorthand, so if no position is declared, it'll be set to '0 0', so you need to reset it immediately after...
Maybe inheritors should instead declare background-image, not background. Maybe I should do that too, to 'set an example'...

There are plenty of ways to fix this. Ideally, we want the one that compresses better and is the easiest to modify for plugin authors...
Title: Re: CSS inheritance issue
Post by: Arantor on April 13th, 2013, 03:57 PM
Quote
Still. I don't see why you're not declaring this way..?
Because I started out by copying what the others did :P

And yes, when you put 5px center in there, there's no inheritance problem because it's explicitly redeclaring the bit that was being overridden...

This is what I was getting at, I'm well aware that in the background shorthand, it's 0 0 - except it was supposed to be inheriting from an existing one, I didn't want it to be overridden.
Title: Re: CSS inheritance issue
Post by: Nao on April 14th, 2013, 05:02 PM
I'm probably going to go for the background shorthand route when it comes to declaring input.submit (including position and background-color), and remove the background-position declaration that was a bit below... I'll need some testing though, because it all doesn't make sense, and I want to ensure I didn't do that because of a special issue.
Title: Re: CSS inheritance issue
Post by: Nao on April 14th, 2013, 08:19 PM
So... Right now, in order to have a working button, you just need to do this.

Code: [Select]
input.new mixes .button-padding
background: url($images/buttons/new.png) 5px center no-repeat
background-color: #e0eaf6

This new method saves about 60 bytes in the regular gzipped file. It actually moves the :hover stuff to the basic button styling, and uses a box-shadow trick to reproduce the hover effect. It's not exactly the same, but it's similar.
(Using 'extends' instead of 'mixes' is possible, but saves 11 bytes from what I could see in my implementation... Goes to show how important repetition is, for gzip ;))
Title: Re: CSS inheritance issue
Post by: Arantor on April 14th, 2013, 11:43 PM
What is the benefit compared to:
Code: [Select]
input.warn extends input.submit
background: url($images/warning_ban.gif) 5px center no-repeat
background-color: #fff0e3
:hover
background-color: #fff5e8

I still need to set all the colours, all the other stuff gets inherited.

If I'm honest, this is why I don't touch the style code unless I have to because it doesn't seem to matter what I do, it's at least three generations behind how you're doing it.

/meis tempted to remove the changes except those 'strictly' necessary, seems easier. Saves more bandwidth too.
Posted: April 14th, 2013, 10:18 PM

Removed extra button, saves even more bandwidth that way.
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 12:03 AM
Lol... ;)

Anyway... To answer your question, the main thing with my rewrite is that you no longer have to provide a :hover with a new color. All buttons are now properly 'lighted' when hovering them, with a specific box-shadow setting.

I'll try to commit these things tomorrow. Along with a host of other changes to CSS... Don't worry though, nothing potentially game-breaking for you.
Title: Re: CSS inheritance issue
Post by: Arantor on April 15th, 2013, 12:06 AM
It would be hard to break anything, the grand total of CSS changes is currently:

Code: [Select]
/* And for the infraction history. Guests cannot see it.
------------------------------------------------- */
$inf_active = #cfc
$inf_expired = #f8faf8
$inf_revoked = #ffc

.windowbg.inf_active
background-color: darker($inf_active, 3%)
.windowbg.inf_expired
background-color: darker($inf_expired, 3%)
.windowbg.inf_revoked
background-color: darker($inf_revoked, 3%)

.windowbg2.inf_active
background-color: $inf_active
.windowbg2.inf_expired
background-color: $inf_expired
.windowbg2.inf_revoked
background-color: $inf_revoked

(this way I get to alternate colours nicely)
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 12:12 AM
Add a 'final' keyword to all of these windowbg-related selectors, and please tell me how many bytes this saves in your gzipped CSS, if any ;)

That's because with your CSS, any classes that inherit from windowbg will also be applied to this. ^^
Title: Re: CSS inheritance issue
Post by: Arantor on April 15th, 2013, 12:14 AM
Even though it's in index.member.css and declared after everything else? ;)
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 07:54 AM
Yes. Do you want me to quickly re-explain what keywords do what..?
Title: Re: CSS inheritance issue
Post by: Arantor on April 15th, 2013, 04:38 PM
Not really any point, it'll probably go over my head like it has done for months.
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 05:17 PM
Manuals are for noobs..? :P
Title: Re: CSS inheritance issue
Post by: Arantor on April 15th, 2013, 05:23 PM
/meis firmly a noob.
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 05:49 PM
Sometimes, when I read through my codebase and scratch my head at it, I feel like a noob too... :lol:
Title: Re: CSS inheritance issue
Post by: Oracle on April 15th, 2013, 07:07 PM
Nice to see I'm not alone. :lol:
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 11:37 PM
Quote from Nao on April 15th, 2013, 12:12 AM
Add a 'final' keyword to all of these windowbg-related selectors, and please tell me how many bytes this saves in your gzipped CSS, if any ;)
So, apparently you forgot to do it... :whistle:
Your CSS adds over 140 bytes (ouch).
Adding the 'final' keywords saved a total of 54 bytes.
That is -- nearly half of it.
As I said: please use final keywords when you're playing with anything that's used as an extend anywhere else...

Also, you forgot to add commas after your new .warn_* classes. I'm surprised you didn't catch it at commit time..?
Fixed locally.
Title: Re: CSS inheritance issue
Post by: Nao on April 15th, 2013, 11:39 PM
Also, I'd like to know if these .inf_* entries will show up for admins only? If yes, you can enclose them in @if admin tests...
If it depends upon a permission, well... I have yet to add any ability to restrict a CSS block to a certain permission... :^^;: I guess I could do it, but that would make for longer filenames, eh... Unless, hmm.... Unless I stored permissions under their ID..?
Title: Re: CSS inheritance issue
Post by: Arantor on April 15th, 2013, 11:53 PM
Quote
Also, I'd like to know if these .inf_* entries will show up for admins only?
No, they will show up for anyone who can see warnings or issue warnings. Which will be members who can see their own warning history. So member without any extra tests is appropriate.
Quote
Also, you forgot to add commas after your new .warn_* classes. I'm surprised you didn't catch it at commit time..?
I managed to miss a *much* bigger thing in r2060 than that. I would have spotted it when I actually got to testing the places where the style will be applied, which right now isn't anywhere.

Next time I'll just wait until I'm completely done before committing, I guess, and I'll go through it again with a fine tooth comb to make sure it's perfect.
Quote
As I said: please use final keywords when you're playing with anything that's used as an extend anywhere else...
And as I said, most of this stuff went over my head. In any case I haven't decided if this is the final code yet or not, it might change and I really don't see any point in worrying about optimising until it's actually done. Pre-emptive optimisation can actually make it very hard to get anything done.

I also said before I'm having a real hard time trying to keep all this straight in my head. Not including a comma at this point in time is a... minor omission.
Title: Re: CSS inheritance issue
Post by: Arantor on April 16th, 2013, 11:13 PM
Oh, and just to point out, .button_class is broken. Some of the buttons do not have a proper padding-left, and before there's any debate about 'I'm not using SVN', this occurs here too with Chrome 27.
Title: Re: CSS inheritance issue
Post by: Nao on April 16th, 2013, 11:19 PM
Nope, doesn't happen...
Only happened here because I forgot to remove the extra.webkit.css file when uploading rev 2060. This is fixed now. But AFAIK, the file was removed from SVN, so you shouldn't be having the problem locally...?

Also, it's .button-padding, not .button_class, although I'm thinking of renaming it to .button-with-icon, so that it's more self-explained...
Title: Re: CSS inheritance issue
Post by: Arantor on April 16th, 2013, 11:28 PM
I don't work out of my own SVN folder. So when it was removed, it didn't magically get removed from the test installation. So, just like here then.

Having removed the extra.webkit.css file here, it does work as expected.
Title: Re: CSS inheritance issue
Post by: Nao on April 16th, 2013, 11:46 PM
Yup. :)