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

[CSS3-Float] Some remarks about the draft

From: Fremy Fremy <fremycompany_pub@yahoo.fr>
Date: Fri, 8 Jul 2011 15:00:16 +0100 (BST)
Message-ID: <1310133616.59389.YahooMailRC@web28001.mail.ukl.yahoo.com>
To: www-style@w3.org
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) :

[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.

[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?

[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.

[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?

[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?

Received on Friday, 8 July 2011 14:00:45 UTC

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