[whatwg] Joined blocks

[Kristof Zelechovski]

The concept of joint blocks (which should rather be named disjoint canvas)
is relevant mainly to printouts.  As it has already been explained in the
booklet case, HTML is not the primary workhorse for preparing professional
printouts.  Window content is stretchable, unlike a print sheet, therefore
it is easier and more logical to present continuous content in a continuous
block, with an optional IFRAME to make it bounded and locally scrollable.
Note that printouts are usually split into such disjoint canvas called pages
and that HTML has no concept of pagination.
IMHO,
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Shannon
Sent: Friday, August 01, 2008 6:58 AM
To: WHAT working group
Subject: [whatwg] Joined blocks

Something I think is really missing from HTML is "linked text" (in the 
traditional desktop publishing sense), where two or more text boxes are 
joined so that content overflows the first into the second and 
subsequent boxes. This is a standard process for practically all 
multi-column magazines, books and news layouts. It is especially 
valuable for column layouts where the information is dynamic and 
variable in length and therefore cannot be manually balanced. This is 
not something that can be solved server-side since the actual flow is 
dependent on user style-sheets, viewport and font-size.

For the sake of disambiguation i'll call this "joined blocks", since 
linking has its own meaning in HTML and the content need not be text.

I honestly don't know if this is too difficult to implement, however it 
has been a standard feature of publishing software such as Pagemaker and 
Quark Xpress for over 10 years.

The markup would be something like:

<div id="col1"><img src="logo.png" 
style="float:right"><p>....</p><p>....</p><p>....</p></div>
<div join="col1" id="col2"></div>
<div join="col2" id="col3"></div>

When reflowing, block elements are moved as a whole. If the block won't 
fit then it follows the overflow behaviour of the column. Inline 
elements are split by line.

For backwards-compatibility it must be legal to split the markup over 
each group member (manual or best-guess balancing). However a HTML5 
compliant browser would reflow to other members as though the combined 
markup originated in box 1.

There are two ways to implement this proposal with respect to CSS.
1.) Rewrite the DOM with the new layout. Closing objects that were split 
and propagating attributes.
2.) Rewrite the CSS parser.

Method 1 is probably simpler but has serious issues with the id 
attribute - since it must be unique and therefore cannot propogate to 
both halves of a split object. It could also create undesirable 
behaviour with respect to :first-line, :before and other selectors that 
the author would expect to apply to the element only once. Method 2 
solves most of these issues but it would probably be a significant 
rewrite of current parsers.

I accept this proposal may be difficult to implement but its use case is 
significant with regards to articles and blogs, especially in an era of 
user-submitted content and wide screen layouts.


Shannon