That progress bar reminds me of somethin'... :P
![]() | ...« I say wedge wedge (in the butt) » « Everyone knows rock attained perfection in 1974. It's a scientific fact. » (Homer Simpson) |
What is it?
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.
I also put in time remaining estimates, but they are horribly inaccurate/unreliable. They keep jumping from one number to the next.
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.
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.
I thought the braces {} did it.
Nope. There's quite a bit to it really.
Firstly you have to declare the animation.
Code: [Select]
(or @-moz-keyframes or @-webkit-keyframes for now)
Then tell the relevant item to use it:
Code: [Select]
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.
Firstly you have to declare the animation.
@keyframes myanim
{
from: { top: 0px}
to: { top: 100px }
}(or @-moz-keyframes or @-webkit-keyframes for now)
Then tell the relevant item to use it:
#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.
What is it?
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
Oh, er, yes, it is.
That's how I found that keyframes won't work in WeCSS.
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...
![]() | ...« I say wedge wedge (in the butt) » « Everyone knows rock attained perfection in 1974. It's a scientific fact. » (Homer Simpson) |
@Pete> What style by Nas? The thing I'm talking about was cooked up by Dragooon for AeMe...
And... did you bother to report that...? I don't remember hearing about that.
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]
This works just fine...
What's your problematic code then?
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:
.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?
![]() | ...« I say wedge wedge (in the butt) » « Everyone knows rock attained perfection in 1974. It's a scientific fact. » (Homer Simpson) |
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°.
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.
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.
![]() | ...« I say wedge wedge (in the butt) » « Everyone knows rock attained perfection in 1974. It's a scientific fact. » (Homer Simpson) |
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°
![]() | The way it's meant to be |
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.
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...?
![]() | ...« I say wedge wedge (in the butt) » « Everyone knows rock attained perfection in 1974. It's a scientific fact. » (Homer Simpson) |
[Plugin] Awards »






