-
So... I slept on it, and it's even worse now :)
I think WeCSS is getting a bit 'old' by my standards, and I should remove some of the dust. And maybe rename it to 'Wess', which I've been considering for a while...
- First of all, because I support 'base:' and added the 'extends' keyword to make it more objecty, I think it's only fair that I add a 'mixes' keyword that would do the exact same thing as 'mixin:'.
- Additionally, maybe mixins should be defined the same way as bases, that is, as regular selectors... (Or, at least, to enable virtuals to be used as mixins). To get the regular mixin behavior, we'd just need to define them as virtuals. The good thing is that it would mean .inline-block can be used both as a base and a mixin. Can you hear "solves the media query problem" already? Yes I'm sure you can...
- I went to check out LESS and SASS (my main 'competition' if I may say), and LESS has done a lot of progress in a year (I should have kept up with their new stuff really...). They now both support mixin parameters, and it's indeed something that could happen to be useful in WeCSS as well. I'm just trying to figure out the proper way of writing it if I'm going to use selectors for mixin declarations... Something like:
.my_mixin virtual params $col = #fff, $param2...
color: $col
box-shadow: ifnull($param2, none)
- As seen just above, there's already an undocumented feature in WeCSS which I like a lot:
background-color: ifnull($custom_color, #fff)
Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?
- Same for conditionals...
.class
color: #fff
@if ie6, ie7, firefox[-3.7]
background: url(border)
@else
border-radius: 5px
font-size: 1em
Should these keywords use @? Should whatever follows if be between brackets? if(ie) or if (ie), like in JavaScript or PHP... But maybe skin authors aren't too versed into these languages, I don't know.
Should we use @endif, too, or would indenting be enough to say "it's the end of the argument list"...? (I haven't tested for now whether or not it can allow for nested selectors in such a situation...)
Should we allow for single-line if statements?
.class
@if (ie[-8]) background-color: #fff @else background-color: rgba(255,255,255,.8)
.class
background-color: @if (ie[-8]) #fff @else rgba(255,255,255,.8)
(In which case, an @endif would mean end of statement, while a missing @endif would mean the statement ends at the end of the line.... But again, maybe it's too complicated?)
Or maybe, similarly to ifnull/@ifnull...
.class
background-color: @if (ie[-8], #fff, rgba(255,255,255,.8))
Just a few ideas like that. May add some in the future... Would like opinions from everyone interested in CSS in general, thank you :)
-
I know it's a lot of questions (that's what life is about :P), but you don't have to answer them all ;)
Just gimme your feelings about whatever made you feel something!
Hopefully getting some opinions before I actually start work on implementing these :^^;:
Posted: September 8th, 2012, 05:56 PM
A bit
Of a
Desperate
Bump.
Sadness ensues.
-
I know it's a lot of questions (that's what life is about :P), but you don't have to answer them all ;)
Just gimme your feelings about whatever made you feel something!
Hopefully getting some opinions before I actually start work on implementing these :^^;:
Posted: September 8th, 2012, 05:56 PM
A bit
Of a
Desperate
Bump.
Sadness ensues.
-
Can you hear "solves the media query problem" already? Yes I'm sure you can...
Meaning, "if $custom_color is set, then set background-color to it, otherwise set it to #fff".
Okay, so should this remain like this? Or would it feel more natural to use @ifnull instead of ifnull?
/meis somewhat sandbagged from today, having had to get outside on a bus on barely 3 hours sleep, then engage in psychological warfare, before coming home, leaving 20 minutes later to go visit a care home and arrange for my grandmother to be moved on Monday because of the country's social services system's inability to manage resources.
-
What about @remove and @replace? ;)
-
@ is for directives like @media - it seems very odd to me to overload that. It sort of threw me when I first encountered LESS on its own when experimenting with Bootstrap, to have everything prefixed with @ throughout the entire source.
Either it needs to be be consistently with @ or consistently without to let @ be left alone as it was for @media type stuff. Unless you have a different symbol in mind that can be consistently used everywhere?
-
I don't know. You tell me.
To me, it doesn't matter that much. @ is to help against mistaking commands for selectors. But @extends doesn't excite me so I decided tht any modifiers would be prefix free. But conditionals? Are they not commands?
-
It's more a semantic thing to me personally. LESS uses @ everywhere to indicate mixins, functions and whatnot and that helps differentiate it from CSS. Having the @ will certainly avoid making mistakes between commands and selectors, but it also conflicts with the use of @ for media.
Conditionals are somewhere between commands and modifiers, semantically speaking. But consider something like lighten(value, 10%) - what's different when writing compared to if(ie[-8], #fff, rgba(255,255,255,.8)) ?
You're still expressing an expression in-line. The difference is that you have a three parameter expression rather than a two parameter expression. To me, they're the same thing. It's a bit trickier with the else part, but even then I still think it should do what normal functions do.
I don't really mind either way, just offering up my thoughts on a technical perspective. People coming to Wedge will deal with whatever's there, warts and all.
-
I don't really mind either way, just offering up my thoughts on a technical perspective. People coming to Wedge will deal with whatever's there, warts and all.
-
It's more a semantic thing to me personally. LESS uses @ everywhere to indicate mixins, functions and whatnot and that helps differentiate it from CSS. Having the @ will certainly avoid making mistakes between commands and selectors, but it also conflicts with the use of @ for media.
Basically, the thing that connects them all, AFAIK, is that they're at the beginning of a line, rather than lost inside a selector.
So, there's no reason to use @ on 'extends', 'virtual' or 'final', etc.
However, Wedge defines mixins with the simple 'mixin' keyword, instead of '@mixin', which is probably an oversight of mine.
When CSS adds functions that can be used inside a property, they aren't prefixed. 'calc', 'url', and so on.
Now, one might want to keep away from using @ function names when nothing says CSS4 won't implement @if in the future. If this happens, however, there's always time to rename it. In the meantime, I'd like to 'stick' to the CSS standards as much as possible.
Thus, if() should be @if() because it's a conditional command. Even if it can be used inside a property -- but it's really of no concern to us, because it can be used anywhere and is a preprocessor magic replacement, just like $variables are.Conditionals are somewhere between commands and modifiers, semantically speaking. But consider something like lighten(value, 10%) - what's different when writing compared to if(ie[-8], #fff, rgba(255,255,255,.8)) ?
I don't really mind either way, just offering up my thoughts on a technical perspective. People coming to Wedge will deal with whatever's there, warts and all.
Well... I'll try to work on that this week.
-
Either it needs to be be consistently with @ or consistently without to let @ be left alone as it was for @media type stuff. Unless you have a different symbol in mind that can be consistently used everywhere?
Heck, even @ is Alt Gr + 0 number for us, but at least it's easy to type with a single hand... :)
Posted: September 11th, 2012, 12:46 AM
Oh, and the name Wess... Is that alright for everyone? Or does it sound too much like Wuss?
-
Well, ~ is a two key job on most QWERTY keyboards, it's usually shift and something (it varies, on the MacBook layout, it's shift + backtick, others, it's shift plus backslash), but it's still a one-handed job if you're reasonably dexterous.
I don't really mind - aside from not getting involved most of the time with CSS, the fact remains is that my objections are basically whiny and semantic rather than either pragmatic or logical :P
You've been working with this stuff, go with what your gut tells you feels right.
Like me with this bastard quick moderation mess. I've been pretty much rewriting it totally because it just felt so wrong how it was.
-
What do you think looks best and/or readable...?
$bevel = ", url($images/theme/bevel.png) $button_gradient"
$bevel {ie6,ie7,ie8} = ""
$button_gradient = ", linear-gradient(90deg, rgba(212, 212, 212, .5), rgba(212, 212, 212, 0))"
$button_gradient {ie9} = ""
$max-width = "max-width"
$max-width {ie6} = "width"
$bevel = @if (ie6,ie7,ie8) "" @else ", url($images/theme/bevel.png) $button_gradient"
$button_gradient = @if (ie9) "" @else ", linear-gradient(90deg, rgba(212, 212, 212, .5), rgba(212, 212, 212, 0))"
$max-width = @if (ie6) "width" @else "max-width"
I'd say the first one.
So, I've got three possibilities...
- Just get a life and forget the first one,
- Keep support for {browser}, as I'll probably be keeping it in skin.xml as well (I need to think about it),
- Just get a life and forget the first one, really.
What do you think...?
Also:
- I've rewritten ifnull() to @ifnull(), as it's a conditional command. It should now accept spaces before the brackets as well.
- Rewrote {%function%} to use '@dynamic function' instead. (It's the same thing, except that you can actually call multiple parameters now and with a cleaner param syntax, they'll be sent as regular parameters instead of the array crap I was sending.)
- And finally, renamed mixin declarations to @mixin. (Have yet to add support for the 'mixes' keyword.)
I discovered (ah ah, completely forgot about it) that I'd already added support for optional variables in mixins, but I haven't tested them for a long time, so I don't know if it still works, I'll have to try... Problem is, I really, really don't make much use of mixins in Wedge...! Actually, it's only used twice (checkbox-styling and ie-inline-block). And none of them require a variable. I should probably do something about that...
-
I've been breaking my jaws on the regex for @if... Grmpf!!
It's pretty hard to figure out.
- @if can be inline
- @if can be a block, in which case the code to be executed is in a nested block below it...
- @else can be on the same line, or at the same (horizontal) level in a following line <-- this is where it's getting complicated! Especially if I decide to allow for an inline @if followed by an @else statement on the next line...
- no @endif means I have to do a precise calculation of what is inside both @if and @else blocks
- I don't even know if I should allow @if to test more than CSS suffixes... i.e. in a mixin, @if ($param == 0) would be a nice thing to do... But then, how do I differentiate between a browser name and something else? (I mean in regex... and don't tell me "just look for $"...)
Perhaps I should do the parsing with multiple strpos calls. But I'm not sure it's even going to be any easier... At least with regex I can easily keep track of the positioning.
So much fun...
-
It might work better if I used a different command for inline if's, but people might see it as 'odd'...
But if there's a different syntax, then @if could be done with the {browser} syntax easily, without brackets or whatever...
@if {ie[7-]}
rule: property
@if $variable
rule: property
.class
rule: @test ({ie6,ie7}, property1, property2)
rule: @ifthen ($variable == true, property1, property2)
Is that, err... Any good?? Or confusing? What name for the inline version? @ite (if then else)? Is that self-explained or too lame?
Posted: September 11th, 2012, 04:25 PM
Or something like @if agent(ie6,ie7) maybe..? agent() being a function that returns 'true' if the current browser is in the list?
Although it could also be tested for "agent(rtl)" for instance, in which case we'd need a more generic name...
Maybe global(variable) or something?
We could even test for global(index) for instance, to tell whether the current file is executed in the main context, for instance if we're adding some conditional code in common.css or custom.css... Wouldn't it be nice to be able to restrict custom/common code to just one file? :)
Oh... "if is(...)"...? Sounds like a winner to me. Or "if for(...)", but I don't like it as much (the only point is that it's also used in skin.xml...)
Posted: September 11th, 2012, 04:37 PM
(Anyone still reading this topic...? :^^;:)
-
(Anyone still reading this topic...? :^^;:)
There are probably two people in this topic who have any understanding of the consequences of this stuff, and one of those has only a vague understanding of it all.
There is only one way to figure this stuff out. Do it and change it if there's a problem down the line. You're discovering the problem I had, that there's so many twists and complexities to it that there's no best right answer, so go with what your gut tells you then adapt and improve if the situation requires it.
-
To be honest I just like to use regular CSS. This kind of makes me less than qualified to answer this.
-
I'll document Wess... One day! If I can find features that I totally forgot I'd written, it means it's time for me to do it ;)
(Still dunno whether to call it WeCSS or Wess, though :lol:)
-
WeStyle! I'd personally like if with syntax/structure similar to @media queries. Something like
@if (browser: IE[6-7]) and $userhaspizza {}
Not sure how feasible that is though, never really looked into We<Whatever name you end up having>
-
WeStyle? Hmm... Why not? Except that it sounds like marmoset(http://fr.wikipedia.org/wiki/Ouistiti) in French, ah ah...
My current grammar for @if was close to this, but I used '==' instead of ':'. Plus -- I'd really rather use a function for browser names... I think.
I'd suggest you look into common.css and the end of index.css and sections.css (mostly), these have most of the WeCSS peculiarities really.
Anyway, it's currently working locally, but not ready for a commit.
-
My regex of the month...
~@is\s*\(\s*+("(?:[^"@]|@(?!is\s*\())*"|\'(?:[^\'@]|@(?!is\s*\())*\'|(?:[^\'",@]|@(?!is\s*\())(?:[^,@]|@(?!is\s*\())*)\s*+,\s*+("(?:[^"@]|@(?!is\s*\())*"|\'(?:[^\'@]|@(?!is\s*\())*\'|(?:[^\'",@]|@(?!is\s*\())(?:[^,@]|@(?!is\s*\())*)\s*+(?:,\s*+("(?:[^"@]|@(?!is\s*\())*"|\'(?:[^\'@]|@(?!is\s*\())*\'|(?:[^\'")@]|@(?!is\s*\())(?:[^)@]|@(?!is\s*\())*)\s*+)?\)~i
Which should allow for infinite nesting of @is tests.
Fun!
Maybe I should use (?R) instead... But I'm afraid it might be too CPU intensive :P
(And yes, right now the syntax is @is (browser, then, else)... Simplest I could do for now.)
-
WeStyle? Hmm... Why not? Except that it sounds like marmoset(http://fr.wikipedia.org/wiki/Ouistiti) in French, ah ah...
-
Oui !
-
So... Regarding @if statements.
Right now, if you didn't follow, there are two things you can do with them:
- Test for a variable's value.
@if $my_variable <= 7
do_this
@else
do that
@endif
- Test for a browser. (It's also more flexible, can be done anywhere.)
@if ie[7-8], opera
do this
@endif
Meaning "If browser is Opera or IE7 or IE8". The syntax is the same as in CSS file suffixes, e.g. "index.ie[7-8],opera.css" in the case above.
So... As usual when I'm a bit lost when resuming work on Wedge, I'm working on 'easy' stuff that I'm very familiar with, currently being the Wedge logo (yes, I've got something else in the works...) and this particular area of Wess.
These are the three additions I made to user agent tests, and I need some suggestions to help with them.
1/ Negative statements, i.e. @if (!ie[7-]) means "If browser is not IE 7 or above". (Parenthesis can be ommitted, of course.)
2/ OS, i.e. @if (win[6.1-]) meaning "if user is running Windows 7 or later".
3/ Logical AND, i.e. @if (opera, chrome && !android), meaning "if browser is Opera, or it's Chrome but not running in Android".
Pretty nice uh...?
Okay, the OS thing is due to two things.
- I've always been bugged by the fact that Wess stores some browsers per OS, like the fact that Safari Mobile's version number is actually the iOS version number because iOS doesn't allow for a different browser engine than Safari Mobile and thus any browser is locked to the OS version.
- There are some cases where a browser will behave differently in two different OSes, usually due to bugs. I like having the ability to specify browser and OS versions.
Okay, so here are my problems...
0/ First of all, with number zero... I know, 'semantics'... As if it's not 'right' to do browser sniffing. But until we're in a perfect universe where all browsers are perfectly compatible and follow standards etc etc, it's going to be a non-issue to me. People who are against browser sniffing and who say that to others have absolutely no idea how much time they're going to take away from them. IE6 being an obvious example... Wess makes it easy to add quick hacks to IE without hurting other browsers. Screw semantics here, they're just a twisted invention.
1/ I don't know what OS versions I should store... Windows is a given, iOS too (see above), Android as well. But what about the rest...? Are there any OSes, mobile or not, that are famous for requiring tweaks to one or more browsers running in them...? Because if I'm only storing Windows, iOS and Android, at least I don't have to create separate CSS files for each obscure OS like Bada or SunOS or whatever.
2/ Linux: should I store this..? If yes, a generic 'linux' entry? And what about the version number? Maybe no OS version at all, given the mess that it is? And I don't think Linux kernel versions have any influence over the browsers...
3/ Is it any actually necessary to store the OS version in the filename every time...? I was thinking of something a bit complex but that could save some space on the hard drive... Let's say we have a @if (win/windows) test in a file. Wess analyzes this, determines whether we're running Windows, and if yes, it tells the cache manager that we have a special behavior for 'windows'. Thus, the cache manager adds a 'windows-6.1' (or whatever version) keyword to the current file. Otherwise, no special keyword. At cache load time, Wess tries to load the 'windows-6.1' version. If it doesn't exist, it tries to load a version without the 'windows-6.1' keyword. Main problems is, I can already smell a really complex implementation (even if I'm up to it, it might be a failure in terms of performance or comprehensiveness in the end...)
4/ Or we could just store the 'main' version numbers, such as Windows shouldn't bother with anything below XP (5), then store only Vista versions (6) for anything above it because I'm not sure 7 or 8 have any significant differences in how they render stuff. Well, I'm mostly thinking of Vista adding things like Segoe UI Light and C fonts by default, or having support (IIRC) for Direct2D rendering in IE9, thus making it a no-brainer to use the ClearType-enabled fonts by default in a skin when instead it's probably wiser to just ommit them from the font stack in XP.
See what I mean...?
I'm just trying to make things 'right' and avoid having more cache files than necessary...
Re: negative statements, it was an annoying implementation, but it seems to be working. It adds quite a lot of lines though... AND statements were easier to add. And funnier, because I'm doing recursive calls for the AND lists. As I said -- fun. Not sure it's going to be liked widely, though... ;)
-
Windows version should be irrelevant to the browser just as it is with Linux. The only rules around Windows are that certain versions don't support certain browsers, e.g. XP won't have IE9 or 10.
-
No, no... My example was the very reason I added OS numbers: Vista adds Segoe UI Light & co. Seven adds Calibri & co. For instance I'm a big fan of Calibri but it has a x-height that's not compatible with anything else (except for a few webfonts). So I can't use the usual stack system because I can't define different sizes for each font (the CSS standard is somewhat lacking in that respect.)
This is why I devised something like this...
@if win[6.1-]
font: 10pt Calibri, sans-serif
@else
font: 9pt Segoe UI Light, Arial, sans-serif
@endif
See what I mean..?
-
Ah, I forgot about that (and that you can't set sizes for fallback fonts)
-
Yeah, it's really always bothered me a bit...
Anyway... I'm pretty much stuck in the mess that I wrote for Wess before. It has variables for is_android and is_iphone (when really it should be is_ios only), and is_tablet -- what's the point in this...? is_tablet is only used PHP-wide in addition to is_iphone, and in JavaScript it can easily be replaced with is_touch and a screen dimension test. As for CSS, a media query is all it takes... (Plus is_touch tests.)
I'm looking at it, and I think I'll have to clean it further...
But I don't really see how I can justify storing this or that version number but not all of them. The only thing I can say is, look at Chrome... It has so many versions in my cache files, it's frightening.
Frak. I don't know where to go from there... -_-
Perhaps I should just forget about Windows version numbers for now. Only store version numbers for iOS because of the whole "browser engine is always Safari Mobile thanks to Apple" story that means new browser features are discovered with new iOS versions, rather than browser updates. Android, well... There are plenty of features added on each new version, but I guess it can be done by "@if (android && opera[7-], android && chrome[20-])", etc...
Maybe just store Windows version for Windows 7 and up -- and state it as "7" rather than "6.1", except of course if Microsoft decides to name Windows 9 differently, ah ah... You never know with them...
What do you think...?
-
And Firefox is trying to be like Chrome...
As a thought, couldn't we add a scheduled task to houseclean periodically? Perhaps once a week, clear the CSS cache?
-
It already deletes any files older than 2 months ;)
-
Okay, I'm a bit stumped here... re: what we discussed above, and what I committed today.
Basically, it seems that Wess never actually stores an OS string into the css filename, even if there's a file in the list with an OS suffix. I don't know why, because it used to work... Anyway... It needs some changing anyway, because currently the implementation is flawed. That is, if an @if or @is command takes place in a file, Wess doesn't care what the question is about, and doesn't send back any data regarding it. For instance, if you do a test on the user agent or OS, Subs-Cache (most specifically the actual css caching function) has absolutely no way of knowing that such a test took place Inside the file, allowing it to force-add browser/OS keywords to the filename... Similarly, if it doesn't need to actually rebuild the cache, there's no way to actually determine that an internal test took place, and thus an extra keyword is needed in the filename...
What I could do, though, is something like that...
- If the test is POSITIVE, set a special variable asking Subs-Cache to later add the browser or OS to the filename (depending on what we tested against.) Otherwise, don't set a variable.
- At regular page load time, first generate a user agent-free filename, then do a file_exists on that filename + a browser + OS, if it exists, load it. Otherwise test filename + browser, if it exists, load it. Otherwise test filename + OS, if it exists, load it. Otherwise test filename, if it exists, load it. Otherwise rebuild cache file.
It adds quite an extra few file_exists tests, I know... We could always cache the results for some time, or whatever...
Maybe it's all a bit... far-fetched...
Fishing for ideas here...
-
I got nothing :(
-
Farfetched or not?
-
I'm still not entirely convinced that OS is entirely necessary if you can figure out browser and resolution, but if you're sure it's needed, then it's not far-fetched.
-
It's actually needed more than ever -- iOS doesn't allow for engines other than Safari Mobile's, so just having 'Chrome' isn't helpful because if it's 'Chrome for iOS', it actually uses the Safari Mobile engine, not Chrome's own.
The reason why I clearly separated OS from UA is because I wanted it to be 'clean', and having a special case for iOS wasn't clean to begin with.
It pains me to say, but as annoying as the new code can be, it's the only way it's going to work, as long as Apple refuses alternative engines on its platform... (of course, Opera Mini is a different engine per se, but it's more akin to sending a URL and receiving an image in return...)
-
It's not even like you can search for Mobile Safari either, since pretty much every mobile browser seems to send that header.
Apple is going to continue to refuse alternate engines for the time being.
-
It's not even like you can search for Mobile Safari either, since pretty much every mobile browser seems to send that header.
Apple is going to continue to refuse alternate engines for the time being.
Which it isn't.
The only thing I like on it, compared to Android stuff, is that it tends to reflow text in a smarter way. For instance, noisen.com's forum topic lists at the top of the page are very readable in iOS, and extremely small and unreadable in Android, whether using stock, Chrome or Opera or even Firefox... (I like Firefox on Android. Except that it doesn't tend to keep all of your tabs open after you quit it... Smart.)
-
No... Everything, even the Opera variant on my Nokia PureView sends a UA with Mobile Safari in it, so it's not even like you can work on that. iOS Webkit isn't that bad, but I don't have any Android devices to compare against.
-
You can always install the Android SDK and then download the x86 image for Jelly Bean or whatever... Then use Intel's accelerator (it needs to be installed from within a Program Files folder, oddly enough, but makes emulation magnitudes faster....), and you're good to go, except you can't run the Play Store with that, so you're stuck with installing APK packages. Ahem, Opera doesn't install on it IIRC. But Chrome probably can...
Anyway...
I'm trying hard to figure out a better way to cache the test results.
It seems like it's beyond me for now...
And I'm afraid it'll start to turn me mad, ah ah.
Well, anyone willing to help...? :^^;:
-
Then leave it for now, let it bubble away in your subconscious and when a solution strikes, it'll strike and you'll figure it out :)
-
Oh, I've been thinking about this for a week actually... But since I hadn't committed anything, it was okay for be stumped. Now, I forced myself to commit precisely so I could try and trigger a stroke of genius... Which has yet to happen. :^^;:
I'd like to know, though, whether or not I should restrict browser/OS tests to @is/@if commands, rather than have them as a possible CSS suffix.
(And I should check whether a @is (rtl) test will actually work...)
Most of my css suffixes are usually quick hacks, but several skins/extra.ie*.css files are much bigger than just the usual stuff, so it'd definitely take me a couple of hours just to move these hacks into index.css itself... Then again, after that it becomes a (bit) easier to manage the files.
-
Seems to me it should generally create a new CSS suffix.
@is (rtl) is probably superfluous, since there should be .rtl.css files for the cases when it is RTL, no?
-
Seems to me it should generally create a new CSS suffix.
index.ie[-7].css
Or
index.css with @is (ie[-7], "something", "else) inside it.
Both are currently valid, but the second one won't automatically force a browser keyword to be added to the cached filename (which is bad.)
The first one, though, also has its limitations.@is (rtl) is probably superfluous, since there should be .rtl.css files for the cases when it is RTL, no?
As you may have seen, I'd actually set up a variable called $left (IIRC?) that's set to 'left' or 'right' depending on the current RTL context. It seems more natural to me. So maybe index.rtl.css should go as well...
-
I'm talking about the non-cached files, not the cached versions... Alright?
Both are currently valid, but the second one won't automatically force a browser keyword to be added to the cached filename (which is bad.)
The rtl file is the best way to simply forget about rtl support...
-
So... I've been wondering about this for the last couple of days.... Still no progress.
In the meantime I've decided I should look into moving $context['browser'] into its own object.
1/ I'm currently using 'weUA' or more likely 'weage' (user AGEnt), dunno if it's for the best beyond the puns (weDge/weAge + we're getting old). I'm known for my unfunny puns so it's probably best to use something else. Don't have to stay in the 'we' + '3 first letters' naming policy, although that would be nice.
2/ Going for a syntax like this: weage::is('ie8'). I could also do weage::$browser['is_ie8'] but it's a bit longer, and I'm not sure calling a function at this point is going to be THAT taxing on overall performance... I've learned my lesson about micro-optimizations really -- they ain't worth it unless you're on a petabyte forum, and even then, you have other worries than saving a few bytes or cycles...
3/ I'm thinking that ::is() could be a good opportunity to actually alias the function to hasBrowser()... i.e., you could do things like, weage::is('ie[8-]') or weage::is('ie || !windows')... Would be a bit slower, though... But I could always do a shortcut at the beginning of the function that would do something like that: if (isset($browser['is_' . $string])) or if (isset($user_info['is_' . $string])) return !empty($user_info['is_' . $string]); ... And voilà, you get pretty much the same functionality as before.
Any opinions on these three suggestions..?
-
+1 for object, best name is weUA. Function calls are quite a bit slower than accessing a variable in scope.
-
Quite a bit = so you'd rather I put weUA::$browser['is_opera'] than weUA::is('opera'), even if I do a quick static cache?
Example:
function is($str)
{
static $is_cache = array();
if (isset($is_cache[$str]))
return $is_cache[$str];
return $is_cache[$str] = self::hasBrowser($str);
}
weUA bothers me a bit... Maybe weua or even 'weu' or weuse would be best... weUA::is() feels strange when typing it. It's a bit... alien.
Other than that, I've finished porting the functions to an object, converted Wess, it's all working I'd say. Some conversion functions in the CSS parser are going to be slower because of the weUA calls, but as they're cached...
-
I didn't say that. Firstly, I seem to recall staticclass::$var as not being valid. You're accessing a property rather than a 'variable' per se, but static instances don't strictly have properties in that sense.
In terms of performance, accessing $context['var'] (assuming $context is already in scope) is faster than obj::function(), but the number of calls we're talking about in a typical page load is small enough that we can declutter $context with this.
-
And in loops, I'm trying to use the variable version anyway.
static::$var is definitely valid on my side... Works quite well.
Class name suggestions please... In all lowercase :)
weua, weu, weage, weuse, webro... (Challenge accepted!) (Oh that was a good episode yesterday....)
-
lulz at webro
My vote is on weua.
-
Starting to wonder if it wouldn't be, hmm, smart to have a generic 'we' (or 'you' :P) object where we'd store contextual information like browser data, RTL mode, $user_info -- we::$user['is_admin'] or we::im('admin'), maybe..?
Would save the need to globalize some stuff like $user_info obviously.
-
I was thinking wesys might be better than 'we' for that, but I'm flexible.
I was sure static::$var didn't work, because I'm sure I'd tried it at some point.
-
I was thinking wesys might be better than 'we' for that, but I'm flexible.
I was sure static::$var didn't work, because I'm sure I'd tried it at some point.
-
I dunno, I just seem to remember getting errors, but it was a long time ago I tried it.
Hard to think straight, lots going on here.
-
Maybe it doesn't work in strict mode...? I dunno.
Anyway, I've started work on moving $user_info over to the we object.
Basically, use we::$user['is_admin'] or we::is('admin'), depending on your tastes. :)
-
we::is('admin') is shorter to type ;)
-
the latter looks cleaner
-
Note for later: inside allowedTo(), make sure to statically store the response from we::is_admin(), because it will be faster than making the function round trip every time.
-
It's is('admin'), not is_admin(), but it's all right to add a helper function... ;)
BTW, I made a few performance tests... 100k calls for each.
(local) $browser['is_ie6'] => 0.02s
we::$browser['is_ie6'] => 0.036s
we::is('ie6') => 0.32s
Oops...
After some heavy micro-optimization on is(), I managed to get it down to 0.2s, it's still about 10 times slower than a local variable test, or 5 times slower than an object variable test, but we're talking about a function that will never, ever be called 100.000 times over the course of a page execution... Even calling it a thousand times will only add 2 milliseconds to the execution time.
Is that okay..?
-
Yeah, I'd say that was probably OK ;)
-
I'm still surprised at how slow function overhead can be in PHP... But that's something for PHP to fix, not us. Technically speaking, the same code would run just as fast in JavaScript as without a function call, so I guess that using an Accelerator could improve that side of things in PHP.
Well, I'm still in the process of building my commit list and checking all changes one by one... Very annoying job. At least the code looks cleaner now...
-
There are hundreds of occurrences of the $user_info array in the code.
I'm thinking that converting those $user_info['is_.....'] entries isn't gonna be a big deal.
However, should I move everything $user_info into we::$user...?
For instance, $user_info['query_see_board']... I'm not sure these kinds of variables translate well into an object, performance Wise.
OTOH, that one's never gonna be called more than a few times per page... Hmm.
I'm starting work on moving loadUserSettings() to self::init_user(), I'll see how it goes. Fingers crossed.......
-
There aren't that many is_ entries.
query_see_board and all its friends are actually only really used in loadUserSettings and possibly loadPermissions - once they're defined, they're registered to the wesql class and that's pretty much it.
-
Interesting...
$user_info =& we::$user;
Doing the 1M tests on $user_info['id'] is then faster than doing them on we::$user['id'], meaning that the array's location is not what kills performance, instead PHP is wasting time parsing "we" per se on every call... Really strange. I can only confirm that it doesn't call getInstance() or whatever crap... It's just wasting time on that.
Any solution...? I guess not?There aren't that many is_ entries.
query_see_board and all its friends are actually only really used in loadUserSettings and possibly loadPermissions - once they're defined, they're registered to the wesql class and that's pretty much it.
I'm torn between keeping $user_info for compatibility (and not having to bother with performance here and there), or getting rid of it for good.
-
Don't worry about compatibility. This is strictly about cleanliness vs performance, and cleanliness is better IMO so if you're feeling up for it, get rid of it for good.
Yes, calling a static function is not cheap but I don't believe it's significantly slower than calling a normal function.
-
Well, it's not a function here, it's a static variable, but we get to know exactly the overhead: about 70%... Not that it matters much, again. I'm just worried over nothing much....
-
I tend to think of everything as functions one way or another ;)
-
I made a site-wide search & replace for $user_info['is_...'] to be replaced with we:is('...'), and I've found a lot of issues... Most notably plenty of lines where $user_info['is...'] is being written rather than read... So I've been replacing them with we::$user['is...'] instead.
Makes me wonder if it's okay mixing we::$user['is..'] data with we::is() in our source code... I mean, people may start wondering why there are two ways of doing this...
Then again, SMF has $context['user'] which has always eluded me :lol:
-
Well, $context['user'] is basically a link to $user_info,
Most of the time that we::$user is set anywhere, that would usually imply the we object should be doing that itself rather than something outside setting it.
-
I guess $context['user'] was added as a convenience for functions that already global $context and forget/don't want to global $user_info... It'll soon be gone, now that the global thingy can go.
I still have something like 1000 occurrences of $user_info to remove... All of the remaining ones are 'simply' $user_info to we::$user replacements, so we're in the area where it takes about twice the time it used to. Should I assume it's going to be okay using these even inside a loop...? I really don't want to spend another 6-7 hours checking each one individually just in case a $user_info variable is used in a heavy loop with 1000+ executions... (Implying we really lose a few milliseconds compared to before.)
-
It's probably going to be OK - and we can always do profiling later on to figure out where the issues are if need be.
-
Yeah, I guess...
Hey I caught you posting your commit to another board and then merging it before I had time to do it eheh ;)
Also, while we're at it... Maybe we should also move $user_settings into we::$settings..? (Or something with another name, in case it's confusing.)
-
Hey I caught you posting your commit to another board and then merging it before I had time to do it eheh ;)
Also, while we're at it... Maybe we should also move $user_settings into we::$settings..? (Or something with another name, in case it's confusing.)
I'd probably find another name for it, but not sure what.
-
Well, I've thought before about removing that entirely, but it serves an interesting use that loadMemberData doesn't; it allows for putting any columns or values into the members table and retrieving it for the current user essentially for free. I would encourage it to be part of the we object somewhere, we::$settings maybe, but don't forget that we also need to contend with $options which is also user-centric.
I'd actually suggest putting them all into we, and then applying "$options =& we::$options" (or we::$opt) definitions just like I did for $user_info before removing it. Then we can keep it that way and not bother about convert everything if we don't feel like it.
I'm just saying that because I did the entire conversion for $user_info and it killed me. I didn't expect it to be so much work, I'm actually proof-reading my commit for the second time, and am only halfway through it (it's a 350KB diff patch)... I don't know why, but I'm pretty sure I made a mistake somewhere. Hence the double proof-reading...I'd probably find another name for it, but not sure what.
Also, regarding your latest commit...
- I didn't change loadUserSettings() because the name spoke for itself, but I did consider doing what you did, so if you like it better that way, it's just fine with me. :)
- Forgot about the static keyword in we::analyze, indeed. It did work without it, though... But maybe it was just an oversight and it actually didn't work but didn't tell me. Dunno.
- I'm not sure about the 'public' keyword additions though... If you'll have a look at the wetem object, all public functions are declared without 'public'. Also, in wess, most public functions don't have the public keyword either. There are a few with it, but that's probably a copy-paste gone wrong ahah. Anyway, if you don't specify 'private' or 'protected', it's 'public' by default, and I tend to prefer shorter code because PHP parses it faster. I'd rather we don't use that keyword, then. Do you have any argument in favor of using it..?
-
If you don't declare the scope, they're automatically public anyway. I just made it explicit rather than implicit. I'm not sure PHP does parse it faster - it's actually historical hangover from PHP 4 when OO didn't have scoping. Aside from that, it's simply good practice.
As far as $options = & we::$opt or whatever, that's fine, but the goal should be eventually to remove it. Global variables are not actually that clever.
-
But Aside from that, it's simply good practice.
That would easily add a hundred bytes to the source code size. Per file.
Let's take another example... If you're calling preg_match_all() and you want to use the default behavior, will you add the PREG_PATTERN_ORDER flag to it? No, you'll just skip the flag altogether... That's the same here. For convenience, you don't have to specify a certain keyword.As far as $options = & we::$opt or whatever, that's fine, but the goal should be eventually to remove it. Global variables are not actually that clever.
-
Does that mean you want me to specify 'public' on all my functions in wetem and wess..?
That would easily add a hundred bytes to the source code size. Per file.
That's the same here. For convenience, you don't have to specify a certain keyword.
When you have a class, it is simply good practice to put that stuff in, even if it is how PHP will 'interpret' it. Partly because PHP might randomly decide to make protected the default in the future, partly because other people reading the code will understand later (be that us or someone else)
-
Size matters. Hence my $user_info rewrite, among other things...
PHP won't make protected the default, if anything to keep it backward compatible with older scripts.
So, yeah... To me, it's the same thing. PHP regularly adds new optional parameters to their functions. You don't need to specify these parameters, they're only there if you want to change them. So, when it comes to objects, it's the same to me: the simpler, the better. If you need to change a function's scope, you can. Otherwise, you don't have to...
-
This is the thing... it's solely the way it is because of older scripts. There's been an argument ever since PHP 5 introduced it that it should have made scoping mandatory, and in fact prior to PHP 5.1, it would have actually tripped a E_STRICT warning.
I get the whole size thing, but quite honestly, there are other things that are as important as keeping it minimalistic, like keeping it readable. Besides, I still want to make phpDocumentor documentation and it will not like the lack of explicit scoping directives.
-
I can see that I won't be able to convince you and you'll have a very hard time convincing me... We'll have to agree to disagree, which I'm not a big fan of... :-/
Then again, I don't understand why you're not bothered by the tons of missing 'public' keywords in our existing methods.
-
Because I haven't gone through those the way I did with this one. Partly because I always use WeCSS was always subject to massive changes, and I figured I'd only worry about keeping the code actually consistent with itself once major and rapid code iteration was done. And the fact that I don't think I've ever made a single change to WeCSS at any time...
I'm not a fan of agreeing to disagree either, though I'm less a fan of inconsistent code.
-
The we object is actually not finished at all... And it shows ;) I'd already made a few more changes to it even before you committed your changes... Thankfully, no conflicts. But still, I was heading towards something else. I guess it always feels strange having someone tell you how to code when you're right in the middle of it... I have my pride, as you know :lol:
I too am obsessional (is that even an English word?) about consistency. And because I'm also obsessional about keeping code as tight as possible (as long as it doesn't impair readability), in this case it was bound to clash with your obsession about documented code ;)
-
I'm not trying to dictate how code goes, as such, just that I like code cleanliness, and to me code that clearly indicates its scope is more clean than relying on PHP's rather idiosyncratic approach. There's an excellent article about how messed up PHP is in that respect, so anything we can do to make it make sense is better.
/meis also aware that he has had more alcohol than he expected today and is definitely feeling it.
-
Well, for starters, I just removed all occurrences of PREG_PATTERN_ORDER in the code. Cleaner.
I'm still of the opinion that we should rely on PHP's default behavior, because there has never been a case, AFAIK, where they changed it without ensuring that legacy code would still work. That's even the reason why explode() accepts parameter in two orders, although they recommend the use of explode($string, $array) for consistency with implode(). But still, the argument that "PHP may change its default behavior" doesn't really stand, if you'll allow me.
Then it just comes to ensuring that users are not confused with the code. Which is also a moot reason for me: I've always pictured object methods as being public, not 'by default' but simply because I didn't even know there were methods to conceal methods... I know, I know, PHP 4 vs 5, blah blah. Anyway, 'private' and 'protected' are keywords that are only going to mean something to very serious developers, and even they will know that the default is 'public'.
So, basically... I'd really, really like to keep code as short as possible. KISS, basically.
Or maybe the lack of alcohol will make you oppose this even more, I don't know... :^^;:
-
AFAIK PHP is the only language which keeps the default visibility scope to public only for the sake of compatibility with PHP4 type objects. So it becomes more unreadable if you're juggling between various languages, plus it's just good practice to have the visibility mode defined, and I'm fairly sure PHP will parse the lack of visibility scope slower even if it's less code.
-
Part of the issue with it is that pretty much everything in our objects is public anyway, there's very little that's protected or private - if there were more objects with visibility clauses, it would be more natural to have explicit declarations of public.
-
Dragooon, can you give me examples of languages similar to PHP that use a private or protected visibility by default...?
Pete, do you mean you're actually agreeing that the public keyword tends to mess things up in Wedge? :P Or did you actually mean that we should review all objects and dedicate ourselves and our days and nights in preventing plugins from accessing most of their variables and methods? :niark:
-
How about C++? Java? Pretty much any C-like language with OO is (and requires) explicit-declaration of scope. It's purely laziness in the half-assed approach PHP had to implementing OO originally. The only other C-like language that doesn't have explicit declaration of OO scope is JavaScript and that's even more insane to debug.
And no, I'm not agreeing with that at all :P It's simply that because most things are public, it doesn't 'matter' that stuff isn't declared.
Private methods are not about 'preventing others from accessing their methods and properties', at least not as the end in itself. The point of declaring public/private/protected, is that you get to enforce certain behaviours as well as logical separation.
For example, in the zip class I've been working on, there is a bunch of private methods. They're private because there is absolutely no reason to call them from outside the class, they are specific to that class. The only variation would be if I were to make classes that depend on that class, where protected might be better.
The idea is that you get to contain behaviour inside a given class. A better example might be the wedit component and subclassing it to implement a different editor (not currently possible, but trivial enough to make possible since it's geared up for it). Some of the stuff in there would be public - the functions called from outside the component, e.g. creating, outputting the editor and buttons. Meanwhile, some stuff you wouldn't change or allow to be changed (preparsecode comes to mind), and some stuff you wouldn't want to expose into the subclasses because they don't apply (some of the tag fixing stuff comes to mind)
-
How about C++? Java? Pretty much any C-like language with OO is (and requires) explicit-declaration of scope. It's purely laziness in the half-assed approach PHP had to implementing OO originally. The only other C-like language that doesn't have explicit declaration of OO scope is JavaScript and that's even more insane to debug.
See, a web dev is more likely to use JS and PHP exclusively in their daily work. I don't see it as a problem that visibility is no concern to them...
Heck, even the system object has static variables but doesn't explicitly describe them as public... I'm surprised you didn't change them or something :PPrivate methods are not about 'preventing others from accessing their methods and properties', at least not as the end in itself. The point of declaring public/private/protected, is that you get to enforce certain behaviours as well as logical separation.
The idea is that you get to contain behaviour inside a given class. A better example might be the wedit component and subclassing it to implement a different editor (not currently possible, but trivial enough to make possible since it's geared up for it). Some of the stuff in there would be public - the functions called from outside the component, e.g. creating, outputting the editor and buttons. Meanwhile, some stuff you wouldn't change or allow to be changed (preparsecode comes to mind), and some stuff you wouldn't want to expose into the subclasses because they don't apply (some of the tag fixing stuff comes to mind)
I'm just... Well I'm just sayin', I like consistency in our code. I'm okay with our 'areas of interest' using two slightly different ways of coding (yours and mine), I'm less okay with the 'no man's land' being less tightly maintained, and even less okay with having my areas of interest adopt different rules (e.g. public vs no keyword) under my own rule ;)
It's not a matter of whether or not it's "my" code, it's just that when it's code I tend to modify a lot, there are things I like to do my way, and having public keywords just isn't something that I usually do.
-
And once again, I left wetem alone knowing full well it was going to change over time - and be subject to big changes. Once it's settled down, we can go through and clean it up should we decide it is necessary. Little point changing it if it's going to change again.
Remember, the code isn't just for you to read.
-
wetem is definitely finished -- I haven't changed it in a while, it's working and I'm certainly not going to change the object's structure at this point... ;)
The code isn't just for me to read, that's true, but what are the odds that someone is gonna read it, and then screw everything up because they're not aware that this or that method has a public visibility...? Can you give me one real life example of 'wetem' or 'we' ruining somebody's life with a missing keyword...?
I just feel that this issue isn't worth 2 pages of discussion... :whistle:
-
*shrug* I was just trying to push for a little bit of consistency, sorry for wasting everyone's time with this.
-
But that's the point... Isn't it? I'm trying to have consistent (i.e. harmonized all throughout) code.
Anyway, I don't know what you want exactly... When you say that you're not touching wetem because you're not sure it's ready, but you touch we immediately after my first couple of commits, I'm not sure whether you actually had something in mind or it's just something you thought of when reading my code and you tried to justify yourself after that by giving a (wrong) example....
Fact is, you don't have to justify yourself, you're human as I am, we have our little idiosyncracies, what matters is to accept them and/or have others accept them. (It feels like watching every other episode of Friends or HIMYM...)
This is where we're wasting our time. As I said earlier, we're unlikely to budge much on this particular issue, so we have to determine, not who's right, but who's the more annoyed by the other's preference. If it kills you not to see a 'public' keyword, I'll gladly change my habit. If it only slightly bothers you, then maybe you'll gladly accept my own preference.
There's really no need to fight over this.
-
That's the point, I DO feel like I have to justify myself.
I changed this one because I happened to be going through the file straight after commit and it was a few minutes work to figure out. wetem is a much bigger thing and I thought it was still being updated - I tend to mentally think of Class-CSS and wetem as being one entity even if they're actually not because it's all interrelated stuff that I didn't touch in code terms, pretty much at any point of their development.
It doesn't kill me not to see it - because I would have been jumping up and down by now over wetem - but we either need to do that for everything or nothing, and right now that's not where we are - and THAT's what's bugging me. The DB classes for example all have their scope declared explicitly, wedit has pretty much everything declared as public though I'm not sure it needs to be that way (nor am I sure it should be that way)
Ideally I'd prefer to see explicit declared scope because that's what's more correct in the grand scheme of things than a 'micro-optimisation' that probably does actually make it slower, not faster in the long run. (No-one's sure if removing 7 bytes per function declaration in a class will make it faster to parse and the difference is going to be so small it's almost impossible to actually benchmark.) However with the changes in PHP 5.4 to class definitions, it would not surprise me if it were actually faster to have that declared explicitly.
-
To be honest I think having scope defined for fields in a class (especially in PHP) where it can be pretty forgetful for someone coming from Java would be good for consistency and readability, but could also remind forgetful people (like me :whistle:) like me who forget PHP seems to do it backwards. -_- Plus, it isn't a big deal just to place scope is it?
Yay for defined scope!!!!
-
So I'm looking at r1810 and I see there's a move of the instance to the getInstance function.
This is now less efficient in PHP 5.4, and I'm not even sure why it's been done, especially as it *deprotects* the singleton status of the object. There is a *reason* the instance is declared as a protected variable. (In PHP 5.4, the JIT compiler is faster when the properties of a class are predeclared, it doesn't have to maintain a hashmap the same way.)
There is absolutely no reason for the instance variable to be exposed outside of the class.
Posted: December 24th, 2012, 06:49 PM
EDIT: I just noticed some of the PREG changes as mentioned. Now I might as well bookmark the preg_replace function in the manual for debugging purposes, because I'm never going to remember the ordering structure for *complex* cases that get processed into loops.
Posted: December 24th, 2012, 06:51 PM
Come to think of it, why don't we strip all the comments left in the source while we're at it? It'd be faster to parse, right?
(Yes, it is faster to parse. But I still remember the fact that I had to create a flow chart to document a 600 line piece of code a few years ago to figure out how any of it worked after I removed all the comments.)
Posted: December 24th, 2012, 06:53 PM
Oh, and dropping the latest SVN into my test site, even clearing the cache, it's still not working properly - the menu dropdowns have no background to them, there's no gradient in the background and other miscellaneous issues that generally result in the setup correctly handling different browsers.
-
I don't know what you're talking about, Pete... I removed the protected static and moved it to the getInstance function. As a static, again. It's protected since it's only accessible from that function. Anyway... Merry Christmas -_-
-
I'm running on a lot of frustration right now, I'll admit. It's possible I misinterpreted the code, however the way this is working, I don't think you'll find it's quite as protected as you think, and I suspect a profiler will suggest it is less efficient than you hoped.
-
Ive been reading all your stuff since you began this fork. Ive been using smf, and yabb before that... smf is boring me at the mo. its stagnant, install a few mods and it breaks. lol
I could say i'm a genius but am not, i smoke too much so i enjoy reading stuff i dont understand what earth is going on. lol i love breaking things and spending hours looking for the errors, only to find it was something really stupid like a misplaced ' lol
anyways, as soon as you guys release your Wedge i think i'll be dropping SMF.
your work so far is awesome, so keep it up and don't rush anything, things take as long as they take.
all the best... oh yeah.
Happy Christmas Everybody.
-
I'll be gone for the day, so no post != issues. See you tomorrow.