Skip to main content ↑ ↓
Topic: Quickedit (Read 9909 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Quickedit

Reply #15 –

Quote from: Antechinus – Doesn't surprise me. I have a suspicion that it's due to display: table-cell; not behaving properly when the contents of a child element have nowrap.  May have to go back to using floats on the template.
Nah, yust set the outer DIV to (The parent from "postarea" and ul with class "poster") the CSS property:
Code: [Select]
display: flex;

and it's fixed :P
 I'll send a PR for that issue later this day..
Thorsten "TE" Eurich
------------------------

Re: Quickedit

Reply #16 –

Not supported in IE or Safari, so how can we use it? Have you checked those for overflow too (I haven't yet).
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Quickedit

Reply #17 –

Fixed that in Wedge yesterday for the blog homepage. ;)
This was also an important fix in SMF itself back in mid-2010. Something all table-based layout deva should be aware of. ^^

Re: Quickedit

Reply #18 –

Quote from: Nao – Fixed that in Wedge yesterday for the blog homepage. ;)
Congratulations.

QuoteThis was also an important fix in SMF itself back in mid-2010.
Welcome to 2013. You'll love it.

QuoteSomething all table-based layout deva should be aware of. ^^
I have no idea what a "table-based layout deva" is supposed to be, or what they should or should not be aware of. Personally, I'm a carbon-based life form. Delighted to make your acquiantance.

Anyway, regarding this little buglet, what happened is that I changed the CSS to use display: table-cell; on .poster and .postarea instead of a float on .poster and a margin on .postarea. At the time I didn't check for overflowing code blocks, because I didn't see any reason why the change should result in a child element several levels down forcing an overflow. However, apparently it does.

If necessary, it can be fixed by just reverting to using the old float and margin, which is basically what 2.0.x did, but without so much redundant markup.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Quickedit

Reply #19 –

Quote from: Antechinus –
Quote from: Nao – Fixed that in Wedge yesterday for the blog homepage. ;)
Congratulations.

QuoteThis was also an important fix in SMF itself back in mid-2010.
Welcome to 2013. You'll love it.

QuoteSomething all table-based layout deva should be aware of. ^^
I have no idea what a "table-based layout deva" is supposed to be, or what they should or should not be aware of. Personally, I'm a carbon-based life form. Delighted to make your acquiantance.

Anyway, regarding this little buglet, what happened is that I changed the CSS to use display: table-cell; on .poster and .postarea instead of a float on .poster and a margin on .postarea. At the time I didn't check for overflowing code blocks, because I didn't see any reason why the change should result in a child element several levels down forcing an overflow. However, apparently it does.

If necessary, it can be fixed by just reverting to using the old float and margin, which is basically what 2.0.x did, but without so much redundant markup.
I meant dev not deva. Stupid autocorrect.
And the answer was...... table-layout: fixed.

You're welcome ;)

Re: Quickedit

Reply #20 –

K, well that would be the important fix in SMF that doesn't appear anywhere in SMF's CSS then. :D

If you mean portal pages using it to deal with the side blocks, etc then I'd forgotten about that. I haven't used tables for that for years. You can do portals without table-based markup, as long as you aren't trying to support IE6 (and I'm not). Whenever I did a custom portal installation, I just re-wrote it to use divs.

I may still use a float anyway. The thing is that display: table hasn't been declared anywhere at the moment. That could be declared on the .windowbg2/ divs, but I didn't bother at the time because it was unnecessary bloat.

Problem is that when the layout is switched to the compact option (no poster area as such) I want to switch the display of .posterarea to block, because that's the best way of dealing with it. Mozilla doesn't behave properly when there is only one "table-cell".

As long as having table and fixed on the windowbg/2 divs doesn't screw anything else further down, with either layout option ,then that would be fine. If it turns out to be a chasing-your-tail scenario then just going back to a float may make more sense.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Quickedit

Reply #21 –

When reading this I am reminded of why I started Protendo(and its predessors) in the first place.. ::)

Re: Quickedit

Reply #22 –

It just came back to me. That wasn't SMF. That was a fix we discussed at the time for your portal Bloc, isn't it..?

Re: Quickedit

Reply #23 –

Is the original fixed?
Bugs creator.
Features destroyer.
Template killer.

Re: Quickedit

Reply #24 –

@IchBin was having the problem, I think its been fixed but he would be the one to say for sure.

Re: Quickedit

Reply #25 –

Looks like it's working to me.!
Success is not the result of spontaneous combustion, you must set yourself on fire!

Re: Quickedit

Reply #26 –

Good! :D
Bugs creator.
Features destroyer.
Template killer.

Re: Quickedit

Reply #27 –

Just to note here (old strawhead just remembered) this was the expired cookie / chrome issue from BB that we had fixed in BB itself.