Re: [css3-regions] issue: is first region initial containing block

On Feb 9, 2012, at 10:59 AM, David Hyatt wrote:

> On Feb 9, 2012, at 10:08 AM, Brad Kemper wrote:
> 
>> I prefer to think of it as giving authors the choice to decide for themselves whether or not their positioned objects should be positioned relative to the regions or relative to something containing the regions (such as the page or viewport). What you're essentially saying is that if somebody tries to paginate content by putting it into regions, that anything flowing into that region can never be positioned relative to some ancestor of the region. That seems like a huge restriction to me, and unnecessary. 
> 
> I don't see this as much of a restriction. If you wanted to position content relative to the page or viewport, you simply wouldn't put it in the flow thread.

That assumes that the person designing the page also has control over the source, which is very often not the case. The thing I want to position to the page might be buried inside a bunch of content that I want to flow into the regions, and I can't just change the HTML to pull it out.

> The only reason to put it in the flow thread and behave as you suggest is if you wanted to have unique per-fragment positioning schemes for a positioned object that is paginated across multiple regions.

I don't know what you mean by fragment. Per-region? I would be OK if all the regions of a flow had the same position as each other. It is the normal chain of ancestors that I want to choose from for the containing block, as usual.

> That would be extremely difficult to implement in WebKit, and I don't really understand what the use case would be for such a feature. It would complicate implementations considerably.
> 
> I don't understand why you would ever want to put positioned content into a flow thread only to have it break out of the regions its flowing through. That seems pointlessly confusing and doesn't make sense structurally from an HTML perspective. Why wouldn't you just put the positioned object closer structurally to the place you really want to position it? If that's the page or viewport, why would you ever lump the content in with the flow thread content?

There are probably many examples, but the one that springs to mind is when I have an abs pos child that is hidden until its parent is moused over. At that point, it should be able to appear anywhere. So, suppose there are a couple somewhat randomly positioned regions, with paragraphs of text flowed into them. Certain words or icons in the text contain hidden child elements containing help text or annotations. When you hover over the text, it is to appear in a reserved banner area across the top of the page, or perhaps in a page sidebar where horizontally it is always in the same page but vertically it is 'top:auto; bottom:auto;' so that it roughly lines up with the hovered item. The regions might be in a DIV that has auto margins on the side, while the BODY has a flexible width, and the sidebar or help banner area is hugging the edges of the body. This means the intended positions can be varying distances from the regions, and each region might also be different distances from the target areas.

I've used the 'hover to expose an abs-pos child' pattern many times to good effect, and this is a simple variation of it.

Another reason is that the region content might be coming from a different source than the template designer, and the content author might want to position something in the content that he controls, to be positioned relative to the page or some other container. If he knows the regions and its ancestors in the template (that he doesn't control) are all static positioned, why shouldn't he be able to take advantage of that to position some of the content outside the flow, relative to the page?

Similarly, but conversely, the template and CSS might be controlled by the designer, but it is basically an envelope template around some other content. I run it to this often, where I can put HTML above and below the main content, and I can use CSS to control all of it, but I cannot change the licensed content's HTML, which may vary from page to page. With regions, I could build a template around the content, and flow the content into it, but there may be some elements of that content that I would position somewhere else on the page than where the content authors originally imagined it to go. I often have to use creative CSS to do this sort of thing, to force someones table based layout into the sort of layout I want, and absolute positioning is a good tool to help with that. I would like to be able to use regions without giving up that power.

These last two situations can be boiled down to this:

1. The content author can control the "middle" content and include a style sheet, but can't touch the template around it (and regions might be the only place he CAN put it).
2. The template author can wrap a template around some content, and include a style sheet to control how it is presented, but can't alter the content directly (because it is shared with other licensees too).

In both these situations, the author cannot just take some content in the HTML and put it outside the designated area. I've been in both situations (just not with regions, of course).

>>> We have two other examples to use as a guide. Printing and columns. In the printing case, positioned objects do get paginated. In the columns case, they don't. I think of regions as being more like printing, though, in that the author explicitly shunted the positioned content into the flow thread, and in my opinion by doing so, we should use a model where this positioned content paginates by default.
>> 
>> With printed pages, there is no other possibility, because the page does not have any ancestors. The region does (maybe even regions inside of other regions). The limitations of printed pages should not limit the increased flexibility of regions.
>> 
>>> Otherwise we're effectively ignoring the request to put the content into the flow thread in the first place.
>> 
>> We're not ignoring it, we're providing an option for how the author wants the content to be positioned. Absolutely positioning elements takes them out of the flow, even without regions. Position:relative applied ancestors is a standard way for authors to decide what that abspos is relative to.
> 
> This assumes that the regions genuinely contain the child flow thread content. I think that's a dangerous assumption to make, since it greatly complicates the implementation of regions. Once you begin to think of the contents of regions as being actual children of the regions, then you get into this line of thinking where you can pull the flow thread contents higher up in the region's containing block hierarchy. That is a massive complication for implementations.

OK. I can think of the child flow as having its original container as its parent. That still gives me the power to use that container or its ancestor as a containing block. Or somehow designate the regions/flow-thread as the containing block via position:relative. But if the flow thread is ALWAYS the ICB, then I am still being robbed of expressive power.

>>> If you accept that the positioned content is respecting pagination, then using the first region's dimensions as an ICB (e.g., if someone says bottom:0) makes sense in that it matches printing. If you don't accept that the positioned object should paginate, then I can see your objection.
>> 
>> I accept that author would often want positioned objects to paginate, but not always, when the pages have ancestors that can sometimes be a better choice.
> 
> Then don't put them in the flow thread in the first place.

That's not always an option. And there may be other reasons to maintain parent-child relationships (the :hover case I mention above, for instance).

> Again, I don't understand why you'd put a positioned object into a flow thread if all you wanted to do was position it relative to a region or something that enclosed the region. Just put it there instead. And as I said above, if the goal is to allow the positioned object to split across regions while having unique positioning schemes in each, I think that's just crazy complicated and not something we should be pursuing.

I'm less interested in having different positioning per region. I mainly want to be able to choose if the regions are the containment block or if some other thing (like the page, or a main content container) is.

Received on Friday, 10 February 2012 05:48:58 UTC