W3C home > Mailing lists > Public > www-style@w3.org > February 2009

Re: [css3-gcpm] How to create running elements

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 12 Feb 2009 09:52:03 -0600
Message-ID: <dd0fbad0902120752p30a73a37m5bc966d1bb3a7c27@mail.gmail.com>
To: Giovanni Campagna <scampa.giovanni@gmail.com>
Cc: www-style@w3.org

On Thu, Feb 12, 2009 at 8:57 AM, Giovanni Campagna
<scampa.giovanni@gmail.com> wrote:
> Am I the only one who cares that position is referenced in many CSS modules,
> that would instantly break as soon as we add this new position value? Or
> should all elements in named flows treated as positioned elements?
> Or instead can position become a shorthand for position-model: static |
> relative | absolute | fixed and position-flow: [flow(<identifier>) |
> slot(<identifier>)]+ like what they had to do with display: => display-model
> + display-role in the Template Layout module and overflow: => overflow-x +
> overflow-y => overflow-style-x + overflow-style-y + overflow-policy-x +
> overflow-policy-y in the Box Model and Marquee modules
> (better to have two syntaxes for template layout slots and named flows,
> although they may seem similar)

Hmm, that is true.  Hakon, anyone else, would this sort of thing cause
a problem?  Would there be similar problems with a "float:to()"

I suspect that it's probably okay, though.

The idea of making position: into a shortcut property is interesting,
if it becomes necessary.

> Is it like flow(<ident>[, <specifier>]*), that is any number of specifiers,
> any order, any combination?

That's the intention, yes.  Sorry my prose wasn't clear.  I should
have written it out in the official syntax.

> I think it is as complex as the current model, but it finally unifies a lot
> of different thoughts and proposals. I like it!

That's about what I was aiming for.  I think this is a fairly complex
topic anyway; no decent solution will be 'simple'.  Overall, though, I
think the concepts can be simplified by a unification like this.
Luckily, I don't think we have to add any complexity to unify it - it
seems like the various ideas are different just because no one though
to unify them, not because there are intrinsic differences that are
best reflected by separate syntaxes.

Received on Thursday, 12 February 2009 15:52:42 UTC

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