W3C home > Mailing lists > Public > www-style@w3.org > January 2012

RE: [css3-regions] Avoid Markup Clutter

From: Alex Mogilevsky <alexmog@microsoft.com>
Date: Fri, 6 Jan 2012 06:46:51 +0000
To: Vincent Hardy <vhardy@adobe.com>, Alan Stearns <stearns@adobe.com>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D51C9E849DDD0D4EA38C2E539856928412DCF6BF@TK5EX14MBXC214.redmond.corp.microsoft.com>
I very much agree with Vincent's explanation. 

Definitely let's define ways to generate regions. Once we get to an agreement on that, I predict that it will be clear if it needs to be in one spec with regions or not. Meanwhile it is well scoped and solid spec that defines what regions do once they exist. Let's let it be that and have a productive discussion on generating regions/columns/pages.


-----Original Message-----
From: Vincent Hardy [mailto:vhardy@adobe.com] 
Sent: Thursday, January 05, 2012 5:31 PM
To: Alan Stearns; Tab Atkins Jr.
Cc: fantasai; www-style@w3.org
Subject: Re: [css3-regions] Avoid Markup Clutter


We had a lot of discussions about regions v.s., pseudo-elements in April/May/June and we even had examples in the spec. showing how regions would integrate with various specifications, including a discussion about the grid layout spec. and cell selectors.

The issue boiled down to recognizing that there are separate issues:

a. The issue of specifying something as a region.
b. The issue of creating CSS boxes that are block containers.

As Alan reminded us, the second issue is not limited to regions and I think Alan's proposal to gather requirements/use cases is a good way to address this generic issue. I disagree with the view this should be addressed in the regions specification because it is more generic than regions.

The issue of making something a region is the only part the specification addresses. The regions specification *does not* require the use of markup.
It is agnostic. For example, Alan has done examples where regions are created on ::before and ::after pseudo-elements. Not necessarily what we'd like people to do either, but my point is that regions *do not* require elements and they do not inherently cause markup clutter. Regions only require a selector for the box it will turn into a region.

So I am very much in line with what Tab said on this:

>>Officially, I'm fine with leaving Regions alone for now, with the 
>>understanding that we'll solve the problem in the near future with 
>>some mechanism for generating arbitrary pseudo-elements.

For the specification example, I think it is ok to propose simple examples, and note that the expected best practice is to use generated pseudo-elements when that becomes available.

Regarding the issue of regions generation that was also raised in this thread (by Tab), I propose we continue that discussion on the thread that Hakon started.


From:  Alan Stearns <stearns@adobe.com>
Date:  Tue, 20 Dec 2011 16:45:31 -0800
To:  "Tab Atkins Jr." <jackalmage@gmail.com>
Cc:  fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org"
Subject:  Re: [css3-regions] Avoid Markup Clutter

>On 12/20/11 1:59 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>> On Tue, Dec 20, 2011 at 1:45 PM, Alan Stearns <stearns@adobe.com> wrote:
>>> There are plenty of examples in other specifications that use divs 
>>>for the  purpose of styling a collection of child elements. The only 
>>>wrinkle in  regions is that those child elements come from a 
>>>different branch of the  element tree. Is a div whose sole purpose is 
>>>to draw a border around a set  of child elements clutter? Or a div 
>>>that's only there to turn on  display:grid? Some 'wrapper' divs are 
>>>quite useful and uncontroversial. I  think region divs should be 
>>>considered as wrapper elements, even if they  appear to be empty in 
>>>the markup.
>> Yes, those divs are clutter, if they're not being used for anything 
>> else.  In some cases they're sufficiently worthwhile that we ignore 
>> the clutter (like requiring a wrapper to hook a new layout mode off 
>> of), but others are just things that we bear for now, because there's 
>> no other way around them yet, like drawing a border around a group of 
>> elements.
>>[other concerns about regions]
>> Officially, I'm fine with leaving Regions alone for now, with the 
>> understanding that we'll solve the problem in the near future with 
>> some mechanism for generating arbitrary pseudo-elements.
>> ~TJ
>Is there a place for collecting requirements for generating arbitrary 
>pseudo-elements? If not, I'll make an ideas page on the wiki.
>The use cases discussed so far are:
>1. Creating regions
>2. Creating borders
>3. Turning on layout modes
>I'd also add:
>4. Adding backgrounds
>5. Adding exclusion shapes
>It seems to me that there would need to be a way of determining how 
>these pseudo-elements are inserted into the box tree - where they land 
>in the tree, and what their children are.
>I know there was a lot of discussion on the list about anonymous boxes 
>when the regions specification had text for it in an early draft. I'll 
>comb through that as well.
Received on Friday, 6 January 2012 07:20:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:54 UTC