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()"
syntax?

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.

~TJ
Received on Thursday, 12 February 2009 15:52:42 GMT

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