Wedge
Public area => Bug reports => The Pub => Archived fixes => Topic started by: Arantor on April 5th, 2013, 05:10 PM
-
From a PM. I have clearly hidden who sent it and the content because none of that is relevant. The first code snippet has issues with the horizontal scrollbar, the second forces the entire post to have a scrollbar.
Also note the poster width is different too. Chrome 26, btw.
/methinks flexbox is buggy :(
-
@Nao: Isn't it a bit too buggy to be spending so much time on?
-
Problem is -- I disabled flexbox yesterday, and don't think I've restored it since..? So how would the bug show up?
-
Maybe you only thought you disabled it? :P
-
I dunno, I'm just saying that here, on this site, today, I was getting the above.
-
I'm not seeing any of this, Pete... :-/
Can you analyze the DOM with dev tools..? Thanks.
(.postarea is what's supposed to have the flex display.)
:edit: Quick Edit fixed... :)
-
What, exactly, am I supposed to be looking for?
.postarea has display:table-cell.
-
Then it's not a flexbox problem...
Although maybe it's a problem due to the reversal, ah ah..!
:edit: Quick Edit fixed! :)
-
Pete, do you still have this problem..?
-
Yup. I just went back to the same PM that I posted a screenshot of, and still have the same issue.
-
If it's specific to PMs maybe can be fixed :)
-
Two suggestions, to be done with Chrome and dev tools...
- Change .post_wrapper's type from table-row to table
- If it doesn't fix your problem; add a property to .post_wrapper:
table-layout: fixed
I doubt the second one would work, but you'd be surprised the number of things it fixed in my table rewrites, over the years... :lol:
Also, I'm trying to re-consider the flexbox model. I regained some hope after I saw that the latest update to Avant Browser, while still retaining the same Chromium rev number (if I'm not mistaken; at least it's the same major version, i.e. 25), fixes the bug where margins are ignored in posts. Which tends to prove that it was a WebKit bug, not mine... :whistle: Still, bug is still there in Maxthon (Chromium 22), but not Sleipnir (Chromium 25). Which never had it, AFAIK.
So I've simply upped the minimum Chrome version to 26, that way I can be sure that Chromium-based software only implements flex when it's "solid" enough.
I'm still bothered by the fact that Opera is so buggy with flexbox, and yet they don't seem to notice... :-/
Maybe I'll try to submit the bug to them. If it's not too much of a waste of time, considering they're ditching Presto...
PS: just for fun/testing... Flex is disabled on wedge.org right now, but if you add "?flex" to the URL, it'll be re-enabled. (Until you visit a link without that in the URL, of course... °_°)
-
Bump for above...?
Also, Chrome is really starting to get on my nerves...
I double-checked the :hover/:focus bug that broke Wedge in Chrome 26, a few months ago... If you'll remember, just setting a border on hover for a textarea or text input would quite simply prevent entering text in them. So I disabled it... Today (an hour ago), I decided to re-enable it, because apparently it's been fixed. Good, good...
Only, on the very same day, i.e. a few minutes ago, I found another silly bug in Chrome 28...
Are you ready?
Set position: relative on an object.
Set position: absolute on a child, and top: 0px.
Animate (through jQuery) to top: 100% on that child.
Element goes right below parent, as expected.
All right..?
Now, set said element's top: 100% to be animated to top: 0px. Which will do the exact reverse... Okay?
Well, it doesn't. It resets its starting position to 100% of the total window height... Fun!
I tested in earlier versions, and the bug isn't there.
Thankfully, I found a workaround, which costs 5 bytes, but whatever... Just set the target to '0%', rather than just 0.
Ah, well... That's the fun of using cutting-edge jQuery along with cutting-edge Chrome...!
I don't know if it's a Chrome or jQuery 2.0 beta 3 bug, so I'll let it slide for now.
:edit: Actually, it's a free fix. I forgot to remove my debug code before comparing... ;)
-
given that flexbox was disabled for opera, i am seeing this issue but it seems to only happen when a pm has a code block in it [not tested with a quote]
i had not looked at sent messages to see the issue.
not that it matters but a sample of code that causes the issue
foreach ($context['recent_items'] as $item)
echo '
<li class="aeva_item">
<a href="', $galurl, 'sa=item;in=', $item['id'], '">
<div class="topic_starter_info ui-li-desc">
', ucwords($txt['by']), ' ', $item['poster_name'], ' ', $txt['on'], ' ', date('d M, Y H:i', $item['time_added']), '
</div>
<img src="', $item['thumb_url'], '" alt="" style="border-radius: 0; -moz-border-radius: 0; -webkit-border-radius: 0; text-align: center;"/>
<h3>', $item['title'], '</h3>
<p>', $item['desc'], '<br /></p>
',$item['is_new'] ? '<p><img alt="" src="' . $settings['default_images_url'] . '/' . $context['user']['language'] . '/new.gif" border="0" /></p>
</a></li>';
[edit] when posting that code in a post the same issue is not seen
-
PMs may not be using the exact same HTML as topic posts, that may be a reason...
Also, I've just re-enabled Flexbox on Opera for you to see, just use the trick I mentioned above: add /?flex to your URL...
-
adding /?flex to the url did not even cause a page reload?
going to the url in a new tab and searching the source does not show any flex in the source but to reference images etc in this thread due to the prettyurls.
-
Fixed.
That's the thing when I have tons of files under work locally... Sometimes, I get mixed up when uploading the 'clean' revisions.
Hopefully this won't break another thing, ahah..!
-
Just wanted to say... I'm going to remove support for flex altogether. While it won't come as a surprise to you guys considering all the trouble I had with it, today I decided to search google for 'nested flexbox', which is what I'm doing in Wedge, and guess what..? The results tend to say that flexboxes are BUGGY when nested inside of each other. NO KIDDING...
Considering that browsers are "not ready" for that, then I see no reason to waste my time on it.
I quickly looked into the grid module as a replacement, as it offers full rowspan/colspan support and thus does exactly what I want, but it's only fully supported in IE10. I've read, here and there, that Chrome 27 "will" support it. However, Canary is currently at version 28, and there's still no such thing as proper support for "-webkit-grid-columns" or whatever... Also, Firefox has some -moz-grid properties, but they're for use in XUL only, so it doesn't apply to Wedge itself.
At this point, I'll just stick to the display:table layout, and after that, there are really only three solutions...
- Leave it be.
- Implement <table> tags, because I can. Not exactly responsive, though... But I can always replace the table tags with regular divs with macros for Wireless, or whatever. Wedge is powerful.
- Restore the quick JS function I wrote to harmonize cell sizes. This is the 'best' solution, but unfortunately, because it needs to load images and have 'definitive' sizes for cells before I start this, I can't run it at .ready() time, and thus have to rely on .load(), hence a very, VERY visible jump in cell size at page load time.
I don't know if it's worth doing a poll for this..? I suspect that I'm the only one who cares about cell size harmonization, or close to... (Then again, my tendency to work for days on a single minor feature no one cares about is also what gave birth to some excellent modules, such as Wess and, well, Wedge's skeleton and mini-skeleton systems...)