Re: [whatwg] Joined blocks
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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=col1img src=logo.png style=float:rightp/pp/pp/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
Re: [whatwg] Joined blocks
Shannon: Something I think is really missing from HTML is linked text Linked or continued (numbered, ordered) lists have been dicussed here a while ago, and were rejected if I remember correctly. They made a stronger use case than generic continued texts in my opinion, although both could be done the same way, i.e. with IDs and some sort of |continue| attribute.
Re: [whatwg] 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=col1pfirst para/ppsecond para/p/div ... other unrelated markup ... div join=col1pthird 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, [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]. Already done. The topic is currently waiting on moderation. Shannon
Re: [whatwg] 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=col1pfirst para/ppsecond para/p/div ... other unrelated markup ... div join=col1pthird 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 divs. In the meantime, having blocks split into separate divs 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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 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. [EMAIL PROTECTED]wrote: On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett [EMAIL PROTECTED] 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 several 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, [EMAIL PROTECTED] ~TJ [1] http://www.w3.org/TR/css3-gcpm/#named1 [2] http://www.w3.org/TR/css3-layout/#templates
Re: [whatwg] 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 [EMAIL PROTECTED]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. [EMAIL PROTECTED]wrote: On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett [EMAIL PROTECTED] 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 several 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, [EMAIL PROTECTED] ~TJ [1] http://www.w3.org/TR/css3-gcpm/#named1 [2] http://www.w3.org/TR/css3-layout/#templates
Re: [whatwg] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Re: [whatwg] Joined blocks
On Fri, Aug 1, 2008 at 7:28 AM, Russell Leggett [EMAIL PROTECTED]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 several 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, [EMAIL PROTECTED] ~TJ [1] http://www.w3.org/TR/css3-gcpm/#named1 [2] http://www.w3.org/TR/css3-layout/#templates
[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=col1img src=logo.png style=float:rightp/pp/pp/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
Re: [whatwg] Joined blocks
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 [EMAIL PROTECTED] -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Joined blocks
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 [EMAIL PROTECTED]
