Shannon | 1 Aug 06:57 2008
Picon

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 
(Continue reading)

Ian Hickson | 1 Aug 07:22 2008
Picon

Re: 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 www-style@...

--

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

Shannon | 1 Aug 07:35 2008
Picon

Re: 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 www-style-Pl0VvzL1eo4@public.gmane.org.

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
Harlan Iverson | 1 Aug 22:39 2008
Picon

maintaining WebSocket connections between page loads

Hello,

I am an implementor of BOSH and interested in WebSockets as future option for browser based XMPP connections. I think a useful feature of BOSH is the ability to send a pause request to the server, which effectively increases the amount of time that can elapse before it considers a client timed out; a client then resumes by making a normal request with the same session ID and the request ID incremented as usual. This is useful/needed because BOSH is a sequenced protocol. Importantly, it enables a use case of maintaining a 'persistent' connection between page loads.

Is there any equivalent mechanism in WebSockets to produce a 'persistent' connection between page loads? Combined with sessionStorage this would be very useful for an application such as Facebook Chat.

My thought is something like this:

window.addEventListener( "load", function() {
  if( sessionStorage.resumeToken != undefined ) {
    // this part is sketchy...
    try {
      con = new WebSocket( sessionStorage.resumeToken );
    } catch(e) {
      // too much time elapsed, invalid token
     
con = new WebSocket( "ws://..." );
    }
  } else {
    con = new WebSocket( "ws://..." );
  }
}, false );


window.addEventListener( "unload", function() {
 
// timeout could be defined by UA, and connection closes after that time
  sessionStorage.resumeToken = con.pause();
}, false );

Personally I'm not a fan of the WebSocket constructor initiating the connection immediately, but I'm sure there are reasons for it being like that. My preference would be to have connect and resume methods to complement disconnect and pause, respectively.

I haven't thought through security implications of this sort of mechanism, but at the very least it seems safe if tokens can only be used within the same origin.

Best,

Harlan
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.   `._.-(,_..'--(,_..'`-.;.'

Greg Houston | 2 Aug 10:23 2008
Picon

Separating Interface and Content

Ten years ago we separated style from content. Pretty soon I think we
may need to start thinking more about separating the interface from
the content as well. We are still treating the web as a web of
documents when it is gradually becoming something more akin to a web
of applications. As an application developer the ratio of user
interface markup (divs within divs within divs) to content markup
(text and images and such) in each of my pages is gradually increasing
on the side of the interface. Just as removing style from HTML vastly
cleaned it up and gave an incredible boost to what we could do with
style, I imagine the same thing would be true if we separated the
interface from the content. The HTML would be cleaner and web
interface technology might be able to fully develop like CSS is doing.

Right now we tend to think of having a plain document that we then
warp into the shape of a user interface with CSS and a little
Javascript magic. But on the backend, for web applications at least,
that is not really what we are doing. We are making an interface and
then injecting content into its various parts and with AJAX updating
that content in those various parts individually. Seeing such a web
"page" as a single document rather than as an application with many
documents open within it is starting to make less and less sense.

I am aware of XUL, but am not very familiar with it, and I imagine not
a lot of developers are yet. My open question is, given the direction
the web seems to be going in, in developing HTML5 are we giving much
thought to eventually separating the interface from the content? Like
right now we are adding such elements as meter, progress, menu,
context menu and so forth to the specification when it seems they
might be better suited to a separate file. Five years from now are we
going to be giving people a hard time for sticking context menus right
into their HTML file the same way we now hassle people for using
tables to structure their document? "That guy is still putting
progress bars in his HTML markup." The progress element hasn't been
implemented yet, but I can already foresee it's demise.

Right now we load a document and then apply CSS to it. It might make
more sense to load the UI file first, then the UI's CSS, then the
document(s) and their CSS. Again, I am not familiar with how XUL
works. It may do something similar or do something a lot smarter.

Another way to think about this is the differences between your screen
CSS and print CSS. What do you hide in your print CSS? With each new
project it seems like I am setting increasingly longer lists of
elements to display: none in the print.css. It is all interface stuff
that does not specifically relate to what the viewer wants to print.
Generally almost all of my menus are hidden from print. Once context
menus are implemented they will certainly go on that list. So if I
feel that I need to hide something from being printed, should that
something be in the content file in the first place or would it be
better suited in an interface file? Should there be a way to print
only specific sections of an HTML file rather than the whole thing? If
so, how would you go about defining the different sections in the
markup? Maybe someone wants to print the help text in this div
container but is not interested in printing all the other widgets on
the page.

The CSS for my content (paragraphs, blockquotes, ...) is generally
rather small and has not really increased much in size over the years,
but the CSS for all the interface divs and unordered lists twisted
into crazy menuing systems grows month by month, from project to
project. I think this is a good indicator of the direction things are
going in.

- Greg Houston

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