Re: [css3-regions] Feedback on regions document

Hi David,

On May 12, 2011, at 10:49 AM, David Hyatt wrote:

On May 11, 2011, at 8:33 PM, Vincent Hardy wrote:

Hi David,

On May 11, 2011, at 1:07 PM, David Hyatt wrote:

On May 11, 2011, at 12:45 PM, Vincent Hardy wrote:

I understand that region styling is an implementation challenge.

I admit that this is mostly an implementation concern and not a philosophical objection to the feature itself.  first-line is already a bit of a nightmare, and it's way simpler than this.  Having both block and line objects changing style during layout as a result of pagination is going to be really complex as well.  In terms of incremental line layout for example (imagine typing somewhere in region #1 of 50 and having to figure out if the styles of lines and blocks are changing as you push objects to subsequent regions).

There are also situations that are ambiguous.  What happens with an object like <div style="height:10em"> for example if it splits across two regions?  Which font are you going to use to determine the size of the div if the two regions give the div a different font in each?

Yes, and if I try to generalize what you are pointing out, the question is: what is the computed value for an element that spans over multiple regions? (since in your example, we need a computed font-size value to compute the height property).

That's why I think you're better off styling pseudo-elements like lines.  You completely avoid this issue if you do it that way.

I think this is a similar (same) issue as pointed out in Issue 11 because in boils down to having selectors that match a 'portion' of an element and therefore, different 'portions' of an element have different computed style. Unlike ::first-line, we cannot really model this with a child pseudo element because splits can straddle elements.


Unless you just change how the feature works and only support line styling. :)


Assuming we limit the set of applicable properties to the same set as first-line

This is the standing proposal in the draft, so I think we are on the same page here. As I mentioned in my previous response, the current draft limits the properties to those applicable to first-line and raise an issue asking if that is enough.

and if we limit the feature to line styling, then the only thing you give up is the ability to have distinct background colors and background images per-region for a block level element.   I'd argue that could even mostly be handled if we allow the regions to render their own backgrounds behind the content that flows into the region.

Yes, I agree.

You'd still be able to control fonts, colors, etc. on all of the lines inside a block element.  All of the examples you use in the current draft would work just fine (with the exception of the one that changes display/border/padding, but those aren't applicable first-line properties).

Yes. So would you be ok with the proposed syntax and my request in the previous email that we still be able to select on elements inside a region?


I dislike the current syntax because it looks like you're styling the element itself.  That will lead to authoring confusion if the element doesn't support the same properties that it would outside of a @region-style block.  I just don't think we should allow styling of the element itself, but instead should use a pseudo-element that represents the lines *inside* the element.

h1::lines-in-region(<region_sel>)
{
  font-size: larger;
  color:red;
}

p::lines-in-region(<region_sel>)
{
   color: darkblue
}

Once you limit the set of applicable properties to only those that apply to first-line, all you lose with the line styling approach is the ability to specify distinct backgrounds on block elements inside a particular region, but I think that loss is acceptable given that you can specify backgrounds on the regions themselves.

All the rules for computed styles involving pseudo-elements are well-understood, and how styles work on lines (including inheritance of pseudo-element line styles like ::first-line) are well understood.

I see. What about the following then:

@region-style <region_sel> {
p::lines-in-region {
        ...
        }

        h1::lines-in-region {
         ....
        }
}




Ah, ok. So you want a more 'guided' solution than what the current draft proposes. I do not have strong feelings about this, except that if we go that route, we should also have a way to do absolute positioning on blocks created through CSS because I think there are use cases that would be hard to achieve with multi-col and grid layout.

I'm just going to concede on the DOM issue.  We already live in a world where presentational divs are commonplace, so it probably doesn't have to be up to this spec to say you can't use the DOM.

ok. I also saw your other email on that.


My hope was that by the time CSS Regions are available, we would have multi-col and grid layout widely implemented too and that it would be the default people would turn to. We could also guide/recommend that in the spec.

Yeah that is my hope as well.

Thanks,
Vincent