Win2000/XP - Baseline for variable height objects become psychotic

[jesset77]

When you try and flow bunches of things with different heights, especially if the shorter stuff precedes the taller, Shoes begins grinning and brandishing a spatula at you.

First, some background:

Everyone has done it. Paste an image into a M$ word document, and it acts like a huge letter. Fun, hunh? Then, in the Netscape 1.0 days before we had any image layout power you got the same effect there. Put an image tag in a flow of text and it acts like a great big glyph.

Well, at least the behavior was predictable. You'd avoid doing that specific thing. However, sometimes you still need to show many images of slightly varying size in a row. Ideally in a flow, it would be nice if they wrap on smaller displays.

Solving that problem in HTML was a headache. We got HTML's "valign" and CSS' "vertical-align" with values like top, bottom, middle, absbottom, absmiddle, baseline, splitlevelcondo, it was a mess.

There are many strategies for making this heavenly. Taking a fresh approach like Shoes, where we have no legacy obligations, we should pick the most ruby-like way and run with it.

In the meantime Shoes can get quite cubist when presented with this problem. Here is a test case using stacks to mix up the baseline.

Shoes.app do
	(1..4).each do |i|
		para "hi#{i}"
		stack :width => 50*i, :height => 50*i do
			background magenta
		end
	end
end

Open the app and make sure the window is wide enough that no wrapping is needed. The first trouble you'll see is that the early paragraphs do not share a baseline with the later paragraphs. Nor do they line up on top or bottom. It's almost like they are using "baseline" alignment, but the baseline keeps getting redefined when larger objects get presented.

Next, narrow the window until things begin to wrap. Things get pretty warped. When choosing the vertical position for the next line, it's almost a dice roll. One time, I got a stack to wrap to the next line and still render 0 pixels from the top.

You'll get a lot of stacks covering over the paras, so you won't see a lot of the para's. I wanted to use a transparent background, but I am currently hampered by ticket #98. If this does not hamper your platform, feel free to try background rgb(1.0, 0, 1.0, 0.5) and keep playing. Maybe add borders.

In case anyone thinks this is a bug in the inner stacks and not the outer flow, you could substitute images. Or, even text-only. Here is another fun testcase:

Shoes.app do
	para 'one'*3, :size => 8
	para 'two'*3, :size => 12
	para 'three'*3, :size => 16
	para 'four'*3, :size => 20
	para 'five'*3, :size => 24
	para 'six'*3, :size => 28
	para 'seven'*3, :size => 32
end

In conclusion: stack+flow=awexome. Chucking the horizontal scrollbar is very liberating. Let's fix bugs like these so The Machine™ can continue rolling, crushing inferior layout engines under it's mighty cleats.

[why]

Definitely. Flows need some work.

[jesset77]

Confirm behavior change on r485. When I mix text of all the same size with "fixed height slots" (is that what they are called here? :) and/or images, I do not experience overlap any more. Mixed text heights like the second testcase in this ticket now overlap worse. :]

I think the description of a flow I heard from the example used in Design Patterns was that you make a virtual box, like a horizontal stack.. then you fill it with items until no more fit. You can tell what fits by margins and widths. You don't determine the Y position of any of the objects until the virtual box is full.

The box should take on the height of the tallest element, then get modified by whatever leading or inter-line spacing rules you allow, and then you get to arrange objects vertically in the box according to whatever kind of vertical align rule you want. Baseline, bottom, top, maybe some kind of percentage; this is the part HTML overcomplicates that we should find a brilliant way to express.

Then once all that work is complete you are free to render the box if you choose, and begin filling the next box if you have any elements left. Naturally, any time the parent container changes it's width you need to reflow the .. flow.

If you find this information highly obvious please do inform me, as I'll take silence to mean you're speechless from the wisdom you've been granted, lol.

GL man!

- - Jesse

[why]

The text is getting better after [487]. Everything is "valigned" to the top for now. Soon enough, you'll be able to change that. But I need to think about this situation a bit more before going on.

Infinite handshakes for closing the other ticket and for your ideas and just for keeping an eye on things.

[jesset77]

Wicked cool! Shoes has put down the spatula and invested in the Bond market now. All of my test cases now confirm sane flow control ceding the fixed choice of vertical alignment. I cannot get anything to overlap, I cannot get anything to steal whitespace from an upstairs neighbor.

So, I think we are all on the same page as to what sorts of problems need to be solved in order to perfect this part of the layout engine. Make HTML look silly, all of that. But in the meantime, we've won the main battle(s) I was concerned about! Given valign=top I can satisfy any layout need that comes to my mind right now, so feel free to invest your attention elsewhere.

Maybe get some green beer! :)

[why]

This has been moved to ditz. The new ticket is #shoes-6.