« Viewing IP addresses and banning
Getting ready for an alpha release: WeCSS/Wess improvements
Current status of the beta? »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #30, on December 16th, 2012, 07:11 PM »
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[1], 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...
 1. Or (maybe) if it's NEGATIVE but with a negative statement such as (!ie7)...?

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

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #34, on December 16th, 2012, 08:59 PM »
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...)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #35, on December 16th, 2012, 09:05 PM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #36, on December 16th, 2012, 09:49 PM »
Quote from Arantor on December 16th, 2012, 09:05 PM
It's not even like you can search for Mobile Safari either, since pretty much every mobile browser seems to send that header.
If Chrome sends both a 'chrome' and 'safari' user agent, it's not a problem because, as I said, we're going to have to test for 'chrome' + 'ios' anyway...
Quote
Apple is going to continue to refuse alternate engines for the time being.
This wouldn't bother me too much if Safari Mobile's engine was actually great... :P
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.)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #37, on December 16th, 2012, 09:58 PM »
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.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #38, on December 16th, 2012, 10:58 PM »
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...? :^^;:

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #40, on December 16th, 2012, 11:34 PM »
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.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #42, on December 16th, 2012, 11:53 PM »
Quote from Arantor on December 16th, 2012, 11:41 PM
Seems to me it should generally create a new CSS suffix.
I'm talking about the non-cached files, not the cached versions... Alright?
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.
Quote from Arantor on December 16th, 2012, 11:41 PM
@is (rtl) is probably superfluous, since there should be .rtl.css files for the cases when it is RTL, no?
The rtl file is the best way to simply forget about rtl support...
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...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #43, on December 17th, 2012, 12:02 AM »
Quote
I'm talking about the non-cached files, not the cached versions... Alright?
Ahhhhhh, my bad. See, this stuff is hard for someone like me who isn't an interface guru ;)
Quote
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.)
I see now, and logically the second case should add the keyword.
Quote
The rtl file is the best way to simply forget about rtl support...
True, true. Perhaps it should go, yes.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Getting ready for an alpha release: WeCSS/Wess improvements
« Reply #44, on December 18th, 2012, 01:42 PM »
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..?
« Viewing IP addresses and banning
Current status of the beta? »