Russell Leggett | 1 Aug 14:28 2008
Picon

Re: Joined blocks

For what it's worth, Shannon, I totally agree with you. Not only is this something I have been wanted for a long time, but I think it belongs in the html. It's one thing if you just want columns, which is being covered here: http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there are times when the joined blocks are more remote and distinctly not columns, requiring the extra markup to control where it must join to. However, while useful for complex layouts, this is definitely the much smaller use case. I think it would make a great addition, but I suppose people have to have priorities! ;)

-Russ

On Fri, Aug 1, 2008 at 1:35 AM, Shannon <shannon-YrEe+GtlLzsQrrorzV6ljw@public.gmane.org> wrote:
I agree this is _mostly_ a CSS issue except that there is semantic meaning to the join attribute beyond layout. The attribute could serve as a guide to search engines, web-scrapers or WYSIWYG applications that two areas of the page should be considered a single piece of content. I am also unsure as to how this might affect other aspects of browser, javascript or DOM behaviour. There may be other uses or side-effects I can't imagine. At any rate CSS cannot associate elements so the join attribute should be considered independent of the style considerations as a means of saying "this block follows that one". Nonetheless I will do as you suggest.

Shannon



Ian Hickson wrote:
On Fri, 1 Aug 2008, Shannon wrote:
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.
I agree that this would be a useful feature for the Web platform. However, I believe the CSS working group is a better venue for exploring such options. I recommend forwarding your proposal to www-style-Pl0VvzL1eo4@public.gmane.org.


Tab Atkins Jr. | 1 Aug 17:00 2008
Picon

Re: Joined blocks

On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <russell.leggett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
For what it's worth, Shannon, I totally agree with you. Not only is this something I have been wanted for a long time, but I think it belongs in the html. It's one thing if you just want columns, which is being covered here: http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there are times when the joined blocks are more remote and distinctly not columns, requiring the extra markup to control where it must join to. However, while useful for complex layouts, this is definitely the much smaller use case. I think it would make a great addition, but I suppose people have to have priorities! ;)

-Russ

This is definitely and distinctly a CSS issue, not a HTML one.  The fact that the contents of an element flow into another box elsewhere in the page has nothing to do with the underlying structure of the data - it's still a single cohesive element, and thus in html it would be marked up exactly as normal.  You just happen to be displaying it differently.

As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of dynamic columns, which will be the most common need for this sort of thing.  However, it's certainly reasonable that one would want more than that, to allow the contents of an element to flow to an arbitrary location elsewhere on the page.  I could have sworn there was a flow-to property proposed in one of the working drafts, but I couldn't find it, so it's possible it only existed in my fevered imagination (it's also possible I was misremembering the "named flows" feature in Generated Content for Paged Media [1]).  A limited form of this property exists in the Paged Media section of the Template Layout module [2], where you can specify a template that spans across severa l pages.  If the contents of a slot would overflow, it instead forces a page-break within the slot and flows onto the next page, filling the slot of the same name.

I've got some ideas in this regard, but we should move it to the CSS list, www-style-Pl0VvzL1eo4@public.gmane.org.

~TJ

[1] http://www.w3.org/TR/css3-gcpm/#named1
[2] http://www.w3.org/TR/css3-layout/#templates
Shannon | 2 Aug 08:39 2008
Picon

Re: Joined blocks

Tab Atkins Jr. wrote:

This is definitely and distinctly a CSS issue, not a HTML one.  The fact that the contents of an element flow into another box elsewhere in the page has nothing to do with the underlying structure of the data - it's still a single cohesive element, and thus in html it would be marked up exactly as normal.  You just happen to be displaying it differently.

The accuracy of your statement depends largely on whether the specification allows the content source to be defined across all joined blocks or only in the first. For example:

<div id="col1"><p>first para</p><p>second para</p></div>
... other unrelated markup ...
<div join="col1"><p>third para</p></div>

This markup would be common when the author is trying to support legacy or non-CSS browsers. The join attribute allows supporting agents to know that conceptually the third para follows on from the second. This might be useful for text or audio browsers to correctly concatenate related sections of text and for search engines trying to demarcate meaningful areas of the page. I strongly recommend that HTML5 define the join attribute and then allow the CSS group to define its behaviour in relation to visual styles. The 'class' attribute sets a precedent for this as it is defined in HTML despite generally having no implications beyond being a style hook. CSS cannot currently target elements except by their structural alignment to others and in many cases the blocks to be joined won't have a simple relationship. Targetting the id of joined elements with the 'join' attribute is still required regardless of how the CSS rules are implemented and this is the correct forum for new HTML attributes.


I've got some ideas in this regard, but we should move it to the CSS list, www-style-Pl0VvzL1eo4@public.gmane.org.

Already done. The topic is currently waiting on moderation.


Shannon
Ian Hickson | 2 Aug 09:01 2008
Picon

Re: Joined blocks

On Sat, 2 Aug 2008, Shannon wrote:
> 
> The accuracy of your statement depends largely on whether the 
> specification allows the content source to be defined across all joined 
> blocks or only in the first. For example:
> 
> <div id="col1"><p>first para</p><p>second para</p></div>
> ... other unrelated markup ...
> <div join="col1"><p>third para</p></div>
> 
> This markup would be common when the author is trying to support legacy 
> or non-CSS browsers.

I agree that such markup would be common today, but I think that we should 
design the language with the intent to move past this style.

I would much, much rather see documents that <section> elements for each 
section, and then have the CSS split the section block into multiple 
boxes, than have the markup itself have each final resulting box split 
into different <div>s.

In the meantime, having blocks split into separate <div>s is the only way 
forward, but I think we can work around the accessibility problems of this 
by including links to the next part at the end of each block. I don't 
think we should add new features to handle this in HTML, I'd rather add 
them to CSS.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Russell Leggett | 3 Aug 02:06 2008
Picon

Re: Joined blocks

I would be happy to have this as a purely css solution, but if multiple container elements are required for the content to flow to, would you not want that relationship in the html? We specify anchors, links, and relationships in html, why not this? How the flow between blocks should certainly be controlled by css - when to break between blocks etc., but there a semantic and structural aspect as well.

-Russ

On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <jackalmage-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <russell.leggett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
For what it's worth, Shannon, I totally agree with you. Not only is this something I have been wanted for a long time, but I think it belongs in the html. It's one thing if you just want columns, which is being covered here: http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there are times when the joined blocks are more remote and distinctly not columns, requiring the extra markup to control where it must join to. However, while useful for complex layouts, this is definitely the much smaller use case. I think it would make a great addition, but I suppose people have to have priorities! ;)

-Russ

This is definitely and distinctly a CSS issue, not a HTML one.  The fact that the contents of an element flow into another box elsewhere in the page has nothing to do with the underlying structure of the data - it's still a single cohesive element, and thus in html it would be marked up exactly as normal.  You just happen to be displaying it differently.

As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of dynamic columns, which will be the most common need for this sort of thing.  However, it's certainly reasonable that one would want more than that, to allow the contents of an element to flow to an arbitrary location elsewhere on the page.  I could have sworn there was a flow-to property proposed in one of the working drafts, but I couldn't find it, so it's possible it only existed in my fevered imagination (it's also possible I was misremembering the "named flows" feature in Generated Content for Paged Media [1]).  A limited form of this property exists in the Paged Media section of the Template Layout module [2], where you can specify a template that spans across severa l pages.  If the contents of a slot would overflow, it instead forces a page-break within the slot and flows onto the next page, filling the slot of the same name.

I've got some ideas in this regard, but we should move it to the CSS list, www-style-Pl0VvzL1eo4@public.gmane.org.

~TJ

[1] http://www.w3.org/TR/css3-gcpm/#named1
[2] http://www.w3.org/TR/css3-layout/#templates

Russell Leggett | 3 Aug 02:10 2008
Picon

Re: Joined blocks

Ignore my last statement. It was a draft I wrote before reading Ian's response. If he has something in mind to get the same thing accomplished without adding extra tags, all the better.

On Sat, Aug 2, 2008 at 8:06 PM, Russell Leggett <russell.leggett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
I would be happy to have this as a purely css solution, but if multiple container elements are required for the content to flow to, would you not want that relationship in the html? We specify anchors, links, and relationships in html, why not this? How the flow between blocks should certainly be controlled by css - when to break between blocks etc., but there a semantic and structural aspect as well.

-Russ


On Fri, Aug 1, 2008 at 11:00 AM, Tab Atkins Jr. <jackalmage-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett <russell.leggett-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
For what it's worth, Shannon, I totally agree with you. Not only is this something I have been wanted for a long time, but I think it belongs in the html. It's one thing if you just want columns, which is being covered here: http://www.w3.org/TR/css3-multicol/. The CSS covers that nicely, but there are times when the joined blocks are more remote and distinctly not columns, requiring the extra markup to control where it must join to. However, while useful for complex layouts, this is definitely the much smaller use case. I think it would make a great addition, but I suppose people have to have priorities! ;)

-Russ

This is definitely and distinctly a CSS issue, not a HTML one.  The fact that the contents of an element flow into another box elsewhere in the page has nothing to do with the underlying structure of the data - it's still a single cohesive element, and thus in html it would be marked up exactly as normal.  You just happen to be displaying it differently.

As noted, CSS3 Multi-Column Layout directly addresses the wide use-case of dynamic columns, which will be the most common need for this sort of thing.  However, it's certainly reasonable that one would want more than that, to allow the contents of an element to flow to an arbitrary location elsewhere on the page.  I could have sworn there was a flow-to property proposed in one of the working drafts, but I couldn't find it, so it's possible it only existed in my fevered imagination (it's also possible I was misremembering the "named flows" feature in Generated Content for Paged Media [1]).  A limited form of this property exists in the Paged Media section of the Template Layout module [2], where you can specify a template that spans across severa l pages.  If the contents of a slot would overflow, it instead forces a page-break within the slot and flows onto the next page, filling the slot of the same name.

I've got some ideas in this regard, but we should move it to the CSS list, www-style-Pl0VvzL1eo4@public.gmane.org.

~TJ

[1] http://www.w3.org/TR/css3-gcpm/#named1
[2] http://www.w3.org/TR/css3-layout/#templates



Gmane