« Guess the Feature
Rewriting the skin file parser...
facepalm or headdesk smiley »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Rewriting the skin file parser...
« Reply #60, on June 10th, 2012, 12:49 PM »
Okay, thanks... Then I guess it's due to this: your selector is split into two different selectors ("something:(firstpart" and "secondpart)"), and then sorted to gain a few bytes at gzipping time, but this also moves "secondpart)" further up the chain instead of directly following it. Hence the broken part.

So, there are two ways of avoiding this...

1/ Just reverting my sort() call and calling it quits on the optimization.

2/ Protection quotes, double quotes, brackets and parenthesis before doing the parsing. That is, anything between these items would be base64-encoded or something (right before building the pseudo-XML CSS tree), and then decoded again once the actual CSS file is generated.

I have a neat preference for solution 2 because it's "cleaner" in my opinion, and would also be likely to fix other potential issues I haven't found yet.
However, I'm not 100% sure it's going to work flawlessly. I can't think of anything right now, but there may be occasions where Wedge will want to access stuff between protected bytes at tree parsing time... What do you think?

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Rewriting the skin file parser...
« Reply #61, on June 11th, 2012, 12:47 AM »
Quote
1/ Just reverting my sort() call and calling it quits on the optimization
Is that all it is? A dinky little optimization? What all does it do?
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Rewriting the skin file parser...
« Reply #62, on June 11th, 2012, 09:35 AM »
Yes. It's only a gzip optimization. Nothing more. Plus when you have multiple versions of a gzipped CSS file, it's way easier to compare them when the selectors are stored. Otherwise Wedge tends to mix them up...
Re: Rewriting the skin file parser...
« Reply #63, on June 13th, 2012, 09:57 PM »
Quote from live627 on June 9th, 2012, 01:35 AM
Offending line:

.menu:not(#main_menu2, #context_menus)

The comma confuses the parser, it seems.
Instead of removing the sorting, I implemented the protection code.
It will search for any (..., ...) "..., ..." and '..., ...' in the selectors.
I tested with this:

Code: [Select]
.something, .menu:not(#main_menu2, #context_menus)
.hello
color: #fff

It got properly parsed. Is that good enough? :)

Now to fix the other error I'm getting... (Well, not so much an error as, ahem, a repetition of some selectors...)
Re: Rewriting the skin file parser...
« Reply #64, on June 14th, 2012, 12:21 AM »
I'm in the process of rewriting the css selector parser... Well, it had some obvious flaws to me (notably, it was, uh, building the final selector directly as a comma-separated string instead of just manipulating an array of selectors?!). Still has. But at least now Wedge will properly delete any duplicates. After gzipping, the current main CSS file is now 70 bytes smaller without any other change than removing dupes (most of the savings) and reordering selectors properly. :)

Hey Pete! Gotta go, will read your post tomorrow ;)

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Rewriting the skin file parser...
« Reply #67, on June 20th, 2012, 01:19 PM »
Quote from Arantor on May 29th, 2012, 05:36 PM
Putting aside the position of the replace keyword, just consider the remainder of the terms - index.replace.some,thing.css should replace index.some,thing.css but not index.thing,some.css.

While I can see the logic of arguing either way, I'd strongly be in favour of keeping it simple.
I need a briefing on this. I still don't know what's best -- deleting replace-type skins or not.
Re: Rewriting the skin file parser...
« Reply #68, on February 18th, 2013, 10:21 PM »
Bumping this...... If anyone feels inspired by the moment or something ;)
Posted: February 17th, 2013, 08:01 PM

Or, rewording... Does it feel more natural to use a skin.xml override to make a skin forget its parents, or to use a filename keyword..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
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
« Guess the Feature
facepalm or headdesk smiley »