Wedge

Public area => The Pub => Plugins => Topic started by: live627 on July 15th, 2012, 05:34 AM

Title: Wand
Post by: live627 on July 15th, 2012, 05:34 AM
This is another of my plugins for developers. This populates the database with dummy entries.


Based on SlammedDime's script. Which also generates lipsum text.

Details
Title: Re: Wand
Post by: Nao on July 15th, 2012, 07:28 AM
That progress bar reminds me of somethin'... :P
Title: Re: Wand
Post by: live627 on July 15th, 2012, 07:45 AM
What is it?
Title: Re: Wand
Post by: Arantor on July 15th, 2012, 03:20 PM
The style submitted to SMF by Nas ;)
Title: Re: Wand
Post by: live627 on July 15th, 2012, 11:27 PM
Oh, er, yes, it is. That's how I found that keyframes  won't work in WeCSS.

I also put in time remaining estimates, but they are horribly inaccurate/unreliable. They keep jumping from one number to the next.
Title: Re: Wand
Post by: Arantor on July 15th, 2012, 11:38 PM
Probably because all the @ constructs in CSS generally are fall into the same general traps as things like the HTML5 audio/video tags, designed by people who have little idea how people would actually want to use these things and base it on what they think people might like.

Keyframes is a great idea, but it's not even standard CSS yet, it's solely in @-moz-keyframes and @-webkit-keyframes constructs, which I didn't even think were legal.
Title: Re: Wand
Post by: live627 on July 15th, 2012, 11:55 PM
I thought the braces {} did it.
Title: Re: Wand
Post by: Arantor on July 16th, 2012, 12:16 AM
Nope. There's quite a bit to it really.

Firstly you have to declare the animation.

Code: [Select]
@keyframes myanim
{
  from: { top: 0px}
  to: { top: 100px }
}

(or @-moz-keyframes or @-webkit-keyframes for now)

Then tell the relevant item to use it:
Code: [Select]
#mydiv
{
  animation: myanim 5s infinite
}

I can't imagine anything that would specifically upset WeCSS in this, and honestly if it were reformatted to use normal WeCSS layout it should work just fine.
Title: Re: Wand
Post by: Nao on July 16th, 2012, 10:56 AM
Quote from live627 on July 15th, 2012, 07:45 AM
What is it?
That:
http://wedge.org/do/media/?sa=stats

@Pete> What style by Nas? The thing I'm talking about was cooked up by Dragooon for AeMe...
Posted: July 16th, 2012, 10:53 AM
Quote from live627 on July 15th, 2012, 11:27 PM
Oh, er, yes, it is.
It is... What?
Quote
That's how I found that keyframes  won't work in WeCSS.
And... did you bother to report that...? I don't remember hearing about that.

Did you try putting keyframes into a separate CSS file using the regular CSS syntax? Just to know if it's a parsing issue or something else...
Title: Re: Wand
Post by: Arantor on July 16th, 2012, 02:46 PM
Quote
@Pete> What style by Nas? The thing I'm talking about was cooked up by Dragooon for AeMe...
I can't seem to find it anywhere but basically Nas redesigned the progress bar on the installer, I don't know if it was pushed to the main repo, but it was submitted IIRC. But it basically looks like the progress bars in this plugin - not the same as the stats page.
Quote
And... did you bother to report that...? I don't remember hearing about that.
I think it was mentioned in passing once, but given the above it's possible that it's not being used properly.
Title: Re: Wand
Post by: Nao on July 16th, 2012, 05:00 PM
Okay, found it... I think.
https://github.com/SimpleMachines/SMF2.1/pull/59
I can't see it in action, so I have no idea what it looks like. But it reminds me of Dragooon's bars because they're skewed by 45°.

As for keyframes, I did a bit of testing and here's what I came up with:

Code: [Select]
.cat
-prefix-animation-duration: 3s
-prefix-animation-name: slidein

@-prefix-keyframes slidein
from
margin-left: 100%
width: 300%
to
margin-left: 0%
width: 100%

This works just fine...
What's your problematic code then?
Title: Re: Wand
Post by: Arantor on July 16th, 2012, 05:39 PM
Quote
I can't see it in action, so I have no idea what it looks like. But it reminds me of Dragooon's bars because they're skewed by 45°.
There are screenshots taken there, and that's exactly what I had in mind.
Title: Re: Wand
Post by: Nao on July 16th, 2012, 06:42 PM
Yep, but I just can't bother to download Nas's repo and install it just to watch that... :P
I'm sure it looks good, too. Hey, if it's SMF 2.1 then we can happily steal from it :lol: I'm sure he'd be glad, too.
Although for now I'd rather use a <progress> bar, I'm sure in the future I'll want to harmonize its looks.
Title: Re: Wand
Post by: Dragooon on July 16th, 2012, 09:34 PM
Quote from Nao on July 16th, 2012, 05:00 PM
Okay, found it... I think.
https://github.com/SimpleMachines/SMF2.1/pull/59
I can't see it in action, so I have no idea what it looks like. But it reminds me of Dragooon's bars because they're skewed by 45°
He probably stole it from the same place I did :P
Title: Re: Wand
Post by: Nao on July 25th, 2012, 07:20 PM
Quote from Arantor on July 16th, 2012, 12:16 AM
I can't imagine anything that would specifically upset WeCSS in this, and honestly if it were reformatted to use normal WeCSS layout it should work just fine.
I had a look at Nas' code... I think I found it. His keyframes use 0% and 100% instead of 'from' and 'to'.
Because of that, they fail to be compiled by Wedge because rules are expected to NOT start with a digit.
So I had a choice between (1) only accepting digits when inside a keyframe (which forces me to change the way I parse the file), or (2) accepting digits. I chose (2) because I'm fucking lazy. It works now.

Although the CSS is quite large for something so small, I like it overall.
Posted: July 16th, 2012, 10:05 PM

Was wondering... I haven't yet committed my changes to Class-CSS on this, because it feels 'wrong' to accept digits in my regex when normally they're not allowed at the beginning of a selector. (Except, as pointed out, in keyframe definitions.)
Should I just deal with it and add support...?
Title: Re: Wand
Post by: Arantor on July 25th, 2012, 08:57 PM
I'd personally prefer to run with the from/to syntax, that's nicer to read. What's the standard say? (I can't remember what the standard says)

I also think it would be better to not support it because there is a certain nicety around keeping things clean - and being less strict does tend to make it less clean.
Title: Re: Wand
Post by: Dr. Deejay on July 26th, 2012, 12:24 AM
I think it looks great, I like the interface :)
Title: Re: Wand
Post by: live627 on July 26th, 2012, 01:16 AM
Thanks - except, the design elements were already floating about in the wild. I wanted to use the new HTML5 <progress> tag, but it wouldn't animate.. So I'm using two div's instead...
Title: Re: Wand
Post by: Nao on July 28th, 2012, 11:21 AM
Quote from Arantor on July 25th, 2012, 08:57 PM
I'd personally prefer to run with the from/to syntax, that's nicer to read. What's the standard say? (I can't remember what the standard says)
I agree it's nicer to read, but from and to are just 'aliases' to 0% and 100%.
The reality is, you can define more keyframes, e.g. at 0%, 25%, 57.5%, 100%... So it's not like I can prevent themers from using numbers.
Quote
I also think it would be better to not support it because there is a certain nicety around keeping things clean - and being less strict does tend to make it less clean.
Strictness would say, "only allow selectors starting with numbers when inside a @-keyframes definition"...
But it'd either make it slower to parse, or just impossible. (I'm a bit rusty when it comes to dealing with selector parsing. WeCSS is a fine work of art but I'm always on the verge of forgetting about its internals... And I'm not even sure documenting it further would help, ah ah.)
Title: Re: Wand
Post by: Arantor on July 28th, 2012, 02:52 PM
Quote
The reality is, you can define more keyframes, e.g. at 0%, 25%, 57.5%, 100%... So it's not like I can prevent themers from using numbers.
Ah, in which case then you do have to.
Quote
But it'd either make it slower to parse, or just impossible.
Hmm, guess it does have to be then.