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

Re: [css3-regions] Avoid Markup Clutter

From: Vincent Hardy <vhardy@adobe.com>
Date: Thu, 5 Jan 2012 17:30:54 -0800
To: 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: <CB2B8E9F.29EA6%vhardy@adobe.com>
Hello,

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.

Vincent



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"
<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.
>
>Thanks,
>
>Alan
>
>
>
>
>
Received on Friday, 6 January 2012 01:33:56 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT