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

Re: [css3-images] cycle detection and element()

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 6 Feb 2012 01:03:25 -0800
Message-ID: <CAAWBYDAHwPazjMeuJxqugMkZyc9vuF38MvABk4jwb_y=23dM2Q@mail.gmail.com>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-style@w3.org
On Sun, Feb 5, 2012 at 10:47 AM, L. David Baron <dbaron@dbaron.org> wrote:
> http://dev.w3.org/csswg/css3-images/#element-cycles
> (Overview.html revision 1.269) says the following:
>
>  # Populate the dependency graph initially by having every element
>  # depend on each of its children. Then, whenever a property on an
>  # element A uses the ‘element()’ function to refer to an element
>  # B, add an edge to the graph by having A depend on B. If a
>  # dependency cycle is detected, any ‘element()’ functions that
>  # produced a dependency in the cycle must represent a fully
>  # transparent image with no intrinsic dimensions.
>
> It's not entirely clear, but this sounds to me like it's defining an
> algorithm that happens in a certain order (given its use of words
> like "whenever ... add").  In other words, it sounds like this
> algorithm might be suggesting that with this markup:
>  <div id="a" style="background: element(#b)">hi</div>
>  <div id="b" style="background: element(#a), element(#c)"></div>
>  <div id="c" style="background: element(#a)"></div>
> a cycle would be detected after adding the backgrounds for a and b
> to the graph, voiding (i.e., making transparent and dimensionless)
> the element(#b) background on id="a" and the element(#a) background
> on id="b", and possibly (the spec isn't clear on this point) then
> removing the corresponding edges from the graph.  If those edges are
> then removed from the graph (which I believe they should not be),
> then the element(#a) background on id="c" is *not* voided, which I
> believe it should be because of the c -> a -> b -> c cycle.
>
> There's no reason for this algorithm to depend on the order of CSS
> style computation.  That's a dependency that could be very confusing
> for authors even if that order were defined, which it's not (and
> shouldn't be).
>
> Additionally, the "add" wording is confusing because when the
> computed value of the property no longer contains the element()
> function, the edge should definitely be removed from the graph,
> which might cause a previously-eliminated background to render.
> Doing otherwise would violate the principle that the sequence of
> dynamic changes that led to the current state shouldn't affect how
> that state is rendered.
>
>
> I believe this section needs to be rewritten to describe the state
> of the graph in terms of the present state of dependencies rather
> than describing it in terms of addition operations that happen at
> certain times.

I didn't intend to imply an incremental algorithm.  Here's an
attempted rewording:

"""
The dependency graph consists of edges such that:
* every element depends on its children
* for any element A with a property using the ''element()'' function
pointing to an element B, A depends on B

If the graph contains a cycle, any ''element()'' functions
participating in the cycle must represent a fully transparent image
with no intrinsic dimensions.
"""

Does this address your issue?

~TJ
Received on Monday, 6 February 2012 09:33:20 GMT

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