W3C home > Mailing lists > Public > www-svg@w3.org > October 2012

Re: 'clip' property and the behavior on 'auto'

From: Dirk Schulze <dschulze@adobe.com>
Date: Thu, 11 Oct 2012 08:21:32 -0700
To: Robert Longson <longsonr@gmail.com>
CC: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <E08B1A6D-7EEB-46ED-B933-8D252144BFA7@adobe.com>

On Oct 11, 2012, at 7:15 AM, Robert Longson <longsonr@gmail.com> wrote:

> 
> > In CSS 2.1 it says
> >
> > 'auto' The element does not clip.
> SVG is precisely on how to use 'auto'. I don't think that "Firefox implements CSS 2.1" means that SVG can't override the definition. That is why I ask if we can remove this clarification for SVG elements.
> 
> What I really meant was that we parse rect arguments per CSS 2.1 rather than per CSS 2.0 which is not compliant with SVG 1.1 but, I hope will be compliant with SVG 2
Yes, it is in the current draft of SVG2 and in CSS Masking (which replaces the section in SVG) as well.

>  
> 
> >
> > If you want clipping you need an overflow value other than visible (This value indicates that content is not clipped per CSS 2.1) and you want the svg width/height to be larger than the clip region to see clipping occur.
> 'overflow' with 'visible' says:
> 
> "This value indicates that content is not clipped, i.e., it may be rendered outside the block box."
> 
> It could be interpret that this is a general statement. I would just interpret that it is not clipped by the 'overflow' property. After all Firefox allows clipping with 'clip-path', so this seems not to be the reason:
> 
> CSS 2.0 was more explicit in this regard. http://www.w3.org/TR/1998/REC-CSS2-19980512/visufx.html#clipping I don't know whether the sentence was removed because it was tautologous or wrong though. 
I see, this is different in CSS 2.1 indeed. CSS 2.1 has less restrictions. Do I understand that both is implemented this way in SVG and HTML for Firefox? I would need to test other browsers as well.

Greetings,
Dirk


> 
> Best regards
> 
> Robert.
> 
Received on Thursday, 11 October 2012 15:22:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:37 UTC