Nicely done!!
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Nao
- Dadman with a boy
-
-
- Posts: 16,082
It's not working 100% for now, works fine when not using comma-separated lists but I did that on ie6+ie7 and they fail to load correctly... Will test later...
Oh god, I have so many leftover features to finish... Grmpf...
Oh god, I have so many leftover features to finish... Grmpf...
Seems to be working, now :)
Oh, the Wireless skin was broken because of a test file I'd uploaded to stress-test the inheritance mechanism and forgot to remove when I was done... Sorry about that.
Will no one report that kind of issue when it's been going on for at least a few hours? :P
Will no one report that kind of issue when it's been going on for at least a few hours? :P
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
I guess no-one used Wireless in that time?
Nao
- Dadman with a boy
-
-
- Posts: 16,082
I did... Although I thought it was another parser bug, which turned out to be working fine...
(Except that Wine is seriously broken right now. Hmm, when did that start...? I'll have to fix it again. Maybe I'll use the opportunity to rewrite the sidebar to behave like in Weaving, because I've really grown tired of that nice little animation -- it doesn't work on touch devices, for starters...)
I think I've fixed everything...
Changed a lot of things internally, really.
I have no idea whether it's for the better. It's certainly a bit slower, whether it be the per-page file check, or the actual parsing (I now do some extra sorting on selector lists), but I did notice a minor improvement in CSS file size reduction, plus there's the added flexibility of using multiple suffixes...
Now I shouldn't forget about implementing per-member suffixes, and maybe other things... What about per-board and per-category suffixes, for instance? (A different skin can be chosen for another board, but this would allow having custom CSS in a single board across *all* possible skins for it...)
One thing I don't know about, though, is the 'admin' suffix (i.e. custom CSS for admins). That's because there's also an 'admin' radix (base?), which is used in the admin area... (the classic admin.css file.)
I'd like to change that, but I don't know what to, and I don't know if I should rename the radix or the suffix.
(Except that Wine is seriously broken right now. Hmm, when did that start...? I'll have to fix it again. Maybe I'll use the opportunity to rewrite the sidebar to behave like in Weaving, because I've really grown tired of that nice little animation -- it doesn't work on touch devices, for starters...)
Posted: May 23rd, 2012, 08:34 PM
I think I've fixed everything...
Changed a lot of things internally, really.
I have no idea whether it's for the better. It's certainly a bit slower, whether it be the per-page file check, or the actual parsing (I now do some extra sorting on selector lists), but I did notice a minor improvement in CSS file size reduction, plus there's the added flexibility of using multiple suffixes...
Now I shouldn't forget about implementing per-member suffixes, and maybe other things... What about per-board and per-category suffixes, for instance? (A different skin can be chosen for another board, but this would allow having custom CSS in a single board across *all* possible skins for it...)
One thing I don't know about, though, is the 'admin' suffix (i.e. custom CSS for admins). That's because there's also an 'admin' radix (base?), which is used in the admin area... (the classic admin.css file.)
I'd like to change that, but I don't know what to, and I don't know if I should rename the radix or the suffix.
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Nao
- Dadman with a boy
-
-
- Posts: 16,082
I think it's a bit too long for my taste...
What about mana.css? :P
It's like 'manage', but it pleases my RPG-addicted mischievous mind :lol:
Oh, also... Today I added support for:
- *.b1.css -> custom css for board #1
- *.c1.css -> category #1
- *.m1.css -> member #1 (no more annoying you with my tests :P)
- *.replace.css -> a new idea of mine... It basically acts like a local replace-type skin, for one radix type.
e.g. Wine was broken because it included custom.css from its parent skin, which was geared towards modifying Weaving, not Wine. So I added an empty custom.replace.css file in the Wine folder and voilà -- all custom.*.css files from Weaving are subsequently ignored.
What I like about my skin system is that I actually use it. Thus, when I meet a new problem, I try to find an innovative solution to it.
Heck, I could even get away with removing skin types entirely, and relying on the 'replace' keyword everytime it's needed... What do you think? I can't think of a situation where a global replace type would be better.
What about mana.css? :P
It's like 'manage', but it pleases my RPG-addicted mischievous mind :lol:
Oh, also... Today I added support for:
- *.b1.css -> custom css for board #1
- *.c1.css -> category #1
- *.m1.css -> member #1 (no more annoying you with my tests :P)
- *.replace.css -> a new idea of mine... It basically acts like a local replace-type skin, for one radix type.
e.g. Wine was broken because it included custom.css from its parent skin, which was geared towards modifying Weaving, not Wine. So I added an empty custom.replace.css file in the Wine folder and voilà -- all custom.*.css files from Weaving are subsequently ignored.
What I like about my skin system is that I actually use it. Thus, when I meet a new problem, I try to find an innovative solution to it.
Heck, I could even get away with removing skin types entirely, and relying on the 'replace' keyword everytime it's needed... What do you think? I can't think of a situation where a global replace type would be better.
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
mana.css is absolutely fine, and I love the idea of board and category CSS - not quite so keen on m1.css, but I'm sure it'll have use.
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
Nao
- Dadman with a boy
-
-
- Posts: 16,082
mana.css is absolutely fine,
and I love the idea of board and category CSS - not quite so keen on m1.css, but I'm sure it'll have use.
I really like the idea of using the replace.css and I can see the benefits of it simplifying add vs replace skins. Would it be faster to drop add/replace skin types and rely on the keyword?
skin.xml has many options, but the skin type is the option regarding CSS files and their ordering. It feels more natural to have this put into the file names themselves.
However, people may get confused with where to put the replace suffix... And even I don't know to which extent they should be applied. For instance, should they put it into every available file? index.replace.css + index.replace,ie6.css -- currently, Wedge doesn't need that because it will delete any index.*.css file if a replace suffix is found on any index.*.css file. But what if they only provide an index.replace,ie6.css file into their skin folder? Now that's an issue... It'd logically mean, "keep the parent index.css and everything, but replace the index.ie6.css with mine". I guess if I had to implement this, I'd need to add even more extra code to Wedge so that it goes through the parent list and removes only those files with suffixes found in our list (in this case, ie6). Meh. OTOH it also gives more flexibility than replace-type skins. But it also introduces a potential complexity that could scare themers away.
All in all, for now I'll be keeping the replace type, but I'd like more opinions on this.
Bump?
Ah well, so no one cares about that... :(
I assume no one cares either about the philosophical matter of having the Thoughts table serve as recipient for our future 'user streams'? (i.e. FB wall, to put it bluntly. Before they went for their horrible timeline thingy...)
Posted: May 25th, 2012, 01:09 PM
Ah well, so no one cares about that... :(
I assume no one cares either about the philosophical matter of having the Thoughts table serve as recipient for our future 'user streams'? (i.e. FB wall, to put it bluntly. Before they went for their horrible timeline thingy...)
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Hey, I've been busy, out yesterday fighting viruses, out today to London and back for a 15 minute interview >_>
I'm not sure which would be more natural, that's half the problem. I suspect ditching the separate skin types would make more sense, though. As long as it's documented, it'll be OK.
I'm not sure which would be more natural, that's half the problem. I suspect ditching the separate skin types would make more sense, though. As long as it's documented, it'll be OK.
Nao
- Dadman with a boy
-
-
- Posts: 16,082
Let's say you have these files:
/index.css
/index.ie6.css
/index.ie6,ie7.css
/index.ie8.css
/Sub/index.css
/Sub/index.replace.ie6.css
The question is: what files *should* be included as logic implies here, and in our current SVN, what files will end up being included in the Sub skin...?
You have one hour.
Or, in other words: should we allow for the replace keyword to be used alongside any other suffix...?
/index.css
/index.ie6.css
/index.ie6,ie7.css
/index.ie8.css
/Sub/index.css
/Sub/index.replace.ie6.css
The question is: what files *should* be included as logic implies here, and in our current SVN, what files will end up being included in the Sub skin...?
You have one hour.
Or, in other words: should we allow for the replace keyword to be used alongside any other suffix...?
Arantor
-
-
- As powerful as possible, as complex as necessary.
- Posts: 14,278
Yes, yes we should. That implies to me that we should load these as standard:
index.css
Sub/index.css (to extend index.css)
If IE6 is present, also load
index.ie6,ie7.css
Sub/index.replace.ie6.css
The replace keyword replaces the equivalent suffix earlier up, so Sub/index.replace.ie6.css replaces index.ie6.css but leaves index.ie6,ie7.css alone, as it's a different suffix.
index.css
Sub/index.css (to extend index.css)
If IE6 is present, also load
index.ie6,ie7.css
Sub/index.replace.ie6.css
The replace keyword replaces the equivalent suffix earlier up, so Sub/index.replace.ie6.css replaces index.ie6.css but leaves index.ie6,ie7.css alone, as it's a different suffix.
Nao
- Dadman with a boy
-
-
- Posts: 16,082
So, if I put a index.ie7,replace,ie6.css file into the folder, that would assume I want the parent folder's index.ie6,ie7.css and index.ie7,ie6.css files to be removed...? But not, say, index.ie6.css or index.ie6,ie7,ie8.css?