W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [CSS3-Float] Some remarks about the draft

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 11 Jul 2011 15:04:40 -0700
Message-ID: <CAAWBYDBpidYHMG_=ikndqRfo_Y+dDm0hB-Hi2JRHAKfE_bMwJA@mail.gmail.com>
To: Fremy Fremy <fremycompany_pub@yahoo.fr>
Cc: www-style@w3.org
On Fri, Jul 8, 2011 at 7:00 AM, Fremy Fremy <fremycompany_pub@yahoo.fr> wrote:
> By CSS3 Float, I’m referring here to the Microsoft/Adobe proposal hosted
> here: http://www.interoperabilitybridges.com/css3-floats. I’ve got some
> remarks when reading the draft (maybe they were already brought to you be
> someone else; I apologies in such case) :

That link 404s, but I assume it's the same as the draft at
<http://dev.w3.org/csswg/css3-exclusions/>.


> [1] The “wrap-shape: auto” doesn’t define how the border-radius property
> interacts with the wrap zone. I know the spec says it’s not complete at this
> time, but I think it’s worth noting that I would expect the outside content
> to take the border-radius into consideration.

The draft currently says "The default shape is the content box as
defined by the CSS box model."  B&B3 *almost* defines border-radius as
affecting the shape of the box in the way we want here.  A little bit
more clarification would be helpful, given the clear intent in the
examples.


> [2] I don’t see in the spec how conflicting “wrap-image” and “wrap-shape”
> should interact. In fact, I don’t like the fact there’s two way to define
> wrap shape. Is the wrap-image property really needed? I would easily imagine
> “<image>” being another value for the “wrap-shape” property. Is there a
> reason why the two properties are both defined? Maybe the SVG shapes type
> could be extended with an “image” function. If an image is an useful way to
> define a wrap zone, it could be an useful way to define any kind of shape.
> Any thought on that?

I strongly agree.  The separate list-style-type and list-style-image
properties, for example, are rather silly to work with.  If I were
reinventing them from scratch, I'd do them as a single property
instead.


> [3] If wrap-image is here to stay, what about a special keyword to use the
> same value as the background-image property? It seems like a pretty common
> use case.

Sounds reasonable to me, though I wouldn't cry it if was omitted.


> [4] How should the browser react if "wrap-image" is set to an SVG image that
> recursively use itself in a cycle? Should the property be ignored? How
> should the browser react if the image fails to load or is currently loading?
> Revert back to auto?

Do browsers even render such images?

Anyway, yes, the draft needs to define what happens when the image
can't be rendered or retrieved for whatever reason.  The simplest
answer is what you suggested.


> [5] The behavior of inner wrapping is not defined in case where the
> available content is smaller than the content itself (in particular in case
> of non-rectangular shapes). How will the “overflow” property apply?

A lot of clarification is needed here.  How is overflow:scroll handled
at all, given that CSS assumes all boxes are rectangular currently (or
at worst, elliptical, but impls don't handle scrollbars well there
currently).

~TJ
Received on Monday, 11 July 2011 22:05:27 GMT

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