Flexible box model. It's easy, until it gets hard.


  • Fence accomplished!
  • Hello
  • Posts: 361
Thank you,


  • 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,668
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.


  • Dadman with a boy
  • Posts: 16,077
Re: Flexible box model. It's easy, until it gets hard.
« Reply #33, on February 28th, 2013, 11:53 AM »
iOS: okay, iPad only I suppose..? Can't bother to test on my decommissioned iPod. Let's just say, because Android marketshares are getting bigger, and frankly because I like Android way better these days (although I don't *reject* iOS, I simply find its UI to be too outdated and its system to be too closed), I don't see myself going on iOS testing sessions a lot in the future. Which is a shame, because at least, Safari Mobile has an obscure setting to enable the JavaScript console... Something that I have yet to see in an Android browser... :^^;: But no real dev tools for now.

Firefox: my tests are always done on Aurora, which currently is v21, and it works fine there because they enabled flexbox by default in v20.
However, I tested in Pale Moon 15 and indeed, it breaks there. I've looked at the HTML and CSS, and I don't see anything strange. It looks like the same good old CSS/HTML I wrote and that was the default in Wedge until yesterday...
Can you test an earlier SVN version on your Firefox..? I'm guessing rev 1955 would be just fine. If it works, save HTML page + the gzipped CSS file, then go back to HEAD and save HTML + CSS, and see if a diff between the two can generate anything interesting...?

Well, I know, I'm not supposed to teach you how to debug, but I have to say, I'm not in a position to debug thoroughly right now... :^^;:
Re: Flexible box model. It's easy, until it gets hard.
« Reply #35, on February 28th, 2013, 02:07 PM »
Okay, so it's not fixed, but at least I know why...

The reason is the internals of my @if implementation... It's a bit complicated, but it was pretty much mandatory for me because I wanted to be able to use variables in mixins, and it didn't work otherwise. The specifics are that @if calls are parsed twice. The first pass is for browser tests (@if chrome[20-], opera...), while the second (which occurs later in the CSS compilation process), is for variable tests (@if $bg_color == #fff). I didn't take into account the possibility of using a variable to store indirect helpers.

So, what I did is 'simply' add a test in the variable parser, to ensure that it held at least one "$" in the string. If it doesn't, return false. And this magically fixes everything... Then again, it doesn't actually fixes much, because at THAT point, I remembered there's no $ in the string anyway. They're all transformed, i.e. the second @if pass actually tests for "@if #fff == #fff" of "@if #000 != #fff"...
This means that I could fix this all by searching for one of the comparison operators, i.e. "==", "!=", "<" and ">", which (thankfully?), aren't supported in browser tests (it supports "!", "&"/"&&", bracket grouping and "," which is an equivalent for "or").
But it also means that if someone looks at my CSS, finds "@if !($supports_flex)" and decides that it's in their right to use @if !($my_random_variable), they'll start bugging me because it doesn't work, and they won't understand why they should be doing "@if $my_random_variable == 0" or something...

I'm afraid my "system" is a bit too smart for its own good.
Perhaps I should be using another variable declaration scheme to clearly differentiate between browser variables and generic variables.
That, or I should simply give up on storing a browser list in $supports_flex, and instead add a constant (like 'member' and 'guest') to the browser test suite, that tests for flexbox support. i.e., "@if supports_flex"...

Something like a list of browser features that can't be detected through CSS and can be useful to regular themers.
can_flex = chrome[20-], ...
can_table = !ie[-7]
Things like that...

What do you think, guys...? And if you think it's the best compromise, can we settle on a constant structure (can_, supports_, browser_, browser_can...? Lowercase? Uppercase?), and a list of features that we should allow testing against..?
I'm a little lost, myself.

Re: Flexible box model. It's easy, until it gets hard.
« Reply #36, on February 28th, 2013, 05:50 PM »Last edited on February 28th, 2013, 05:57 PM by Maxx
Just and FYI... I found surfing flex stuff

Also in this article:

A Word on Firefox The flexbox model was, at least originally, based on a syntax that Mozilla used in its products. That syntax, called XUL, is a mark-up language designed for user interfaces.
The irony here is that Firefox is still catching up, and its rendering of some flexbox properties can be buggy. Below are some issues to watch out for, which future releases of Firefox will fix. Credit here must go to the uber-smart Peter Gasston and Oli Studholme, giants on whose shoulders I stand.
  • Flexbox ignores overflow: hidden and expands the flexbox child when the content is larger than the child’s width.
  • The setting display: box is treated as display: inline-box if there is no width.
  • The outline on flexbox children is padded as if by a transparent border of the same width.
  • The setting box-align: justify does not work in Firefox.
  • If you set box-flex to 0, Firefox forces the element to act like it’s using the quirks-mode box model.

 box flex.png - 247.17 kB, 744x723, viewed 178 times.


  • Dadman with a boy
  • Posts: 16,077
Re: Flexible box model. It's easy, until it gets hard.
« Reply #37, on February 28th, 2013, 07:57 PM »
Yup, it's a well-known article...
Fact is, even though the old Firefox bug mentioned is similar to mine, it really was only in the old flexbox specification, and they simply dropped the bug (didn't fix it) because they've rewritten the entire thing for the new flexbox specification anyway, the one I'm using in Wedge...

Re: Flexible box model. It's easy, until it gets hard.
« Reply #38, on February 28th, 2013, 08:58 PM »
LOL I knew I could not possibly get one passed you, But For me this is very interesting site and I will spend time there reading.

I love stuff like this, But unlike you my bean can only take in so much at a time!



  • Dadman with a boy
  • Posts: 16,077

Re: Flexible box model. It's easy, until it gets hard.
« Reply #40, on February 28th, 2013, 09:42 PM »
You have a long way to go>>> So I'll be waiting on the dark side of the moon for Ya! Just as soon as I learn how to Fly!
But for now I'll stay Comfortably Numb. How ever I'm still not aring the inside out... P Floyd... I must be old But I'm happy!

Off topic again!



  • Dadman with a boy
  • Posts: 16,077


  • Dadman with a boy
  • Posts: 16,077
Re: Flexible box model. It's easy, until it gets hard.
« Reply #43, on June 13th, 2013, 06:12 PM »
So, last April I disabled this feature, because I'd discovered that no matter how much I worked on fixing it across browsers, nested flexboxes have an undefined behavior.

Today, for some reason, I decided I wanted to see if I could do without the parent flexbox, and only use the child. So, I experimented on it, and added a dummy div in postarea, and made it absolutely positioned, but then I remembered the table cell itself could be relatively positioned, because of a Firefox bug or something, so I tweaked everything, and managed to get the child div to take the entire height of the cell, *without even resorting to absolute positioning*!

This is probably a Chrome bug or something, but from my tests (and I assure you, it was a totally random shot, not some hack I read from another website), setting the table's height to 100% (which doesn't have any impact) allows me to set it on its cells as well. Odd, eh..? And then I can also set height: 100% on the child div. It works, and allows me to turn the div into a flexbox, but unfortunately, the height: 100% trick didn't work on other browsers, and thus can't be used there, AFAIK.

Then I thought about it some more, and decided I didn't give a damn... I'm on Chrome, I can decide to 'improve' its layout if it supports it; other browsers will just behave as usual. I also removed the dummy div, and tried doing display: flex on the postarea, and it friggin' worked. I can't believe it, eh..?!! Anyway, considering that it's Chrome-only now, I'll spot bugs soon enough, so, I suppose, it's time to restore flexbox into Wedge, and enjoy the moment.

'course, as usual, if someone finds a truly cross-browser way to do it, feel free to point it out...!

This will be in my next commit, I think... Along with other things, hmm... Can't tell, it's top secret.[1]
 1. No, not really... I'm re-doing the Ajax box, but I'm not 100% happy with it; actually, I'm tempted to remove it entirely, and replace it with a page-wide 'progress' cursor during the call... I did a test, and it worked.


  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Flexible box model. It's easy, until it gets hard.
« Reply #44, on August 8th, 2013, 11:51 PM »
I should just add, I'm using Chrome 29 and I got sent a block of XML in a PM. Trouble is, not only was the indentation screwed up, half the line breaks were also missing. It made a real mess out of the file I was sent :(
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