Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[filter-effects][css-masking] Should x,y,width,height on mask/filter elements map to SVG geometry properties? #25

AmeliaBR opened this issue Aug 19, 2016 · 5 comments


Copy link

@AmeliaBR AmeliaBR commented Aug 19, 2016

I found a section of SVG 2 draft describing the x,y,width,height attributes on the mask element as presentation attributes for the corresponding SVG geometric properties.

I am removing that from SVG 2 because:

  • it should really be defined in CSS-Masking
  • the defaults for a mask are different from the normal defaults for the properties, so there would need to be extra user agent stylesheet rules to set them
  • whether or not these attributes should be CSS-controllable should be consistent between masks and filters (which use the same defaults and are somewhat conceptually similar)

That said, if there's a use case for defining mask (and filter) dimensions with CSS properties, all of these obstacles can be overcome.

For reference, similar attributes on SVG paint server elements are not presentation attributes, and do not map to the geometry properties.


This comment has been minimized.

Copy link

@dirkschulze dirkschulze commented Jun 8, 2017

In an SVG WG meeting we clarified that this will not be the case for any kind of resources. IIRC Some browsers like Firefox do not have those elements in the rendering tree and it is currently not possible to compute the value.

In addition, the inheritance model might be too confusing since the position of the resource in the document counts.

Until we clarified all criteria we deferred the promotion to presentation attributes.


This comment has been minimized.

Copy link

@dirkschulze dirkschulze commented Dec 15, 2017

@AmeliaBR Are you ok with closing this issue or should we reevaluate this in a WG meeting?


This comment has been minimized.

Copy link

@AmeliaBR AmeliaBR commented Dec 15, 2017

Close, or defer to a future spec(s).

I do think that, once support for SVG geometry in CSS becomes widespread, we'll find author confusion for the elements that only support attributes. But it shouldn't delay Filters/Masking Level 1.


This comment has been minimized.

Copy link

@dirkschulze dirkschulze commented Dec 23, 2017

@AmeliaBR Yes, that was discussed as well and I agree. I think we thought about incrementally supporting CSS properties in more places over time. Especially since implementers raised implementation complexity concerns.


This comment has been minimized.

Copy link

@css-meeting-bot css-meeting-bot commented Feb 26, 2018

The Working Group just discussed Geometry attributes on <mask> and <filter>.

The full IRC log of that discussion <AmeliaBR> Topic: Geometry attributes on <mask> and <filter>
<AmeliaBR> Github:
<AmeliaBR> Dirk: The mask, pattern and filter elements both take x,y,width,height attributes. These are regular attributes. But now we have geometry CSS properties for those attributes.
<AmeliaBR> ... So the question is, should these attributes now be presentation attributes attached to the CSS?
<AmeliaBR> ...My proposal is to defer this to a future spec. No change for now.
<AmeliaBR> Bogdan: Have you talked with the CSS WG, does this affect CSS masking?
<AmeliaBR> Dirk: It doesn't affect the application of the mask, it only affects the mask and filter elements.
<AmeliaBR> Amelia: My concern is authoring confusion. Once authors are used to the geometry properties, they would expect them to work on these elements. But I have no problem with deferring it for now.
<AmeliaBR> Bogdan: Generally speaking, making these properties could add a lot of complexity, because they we need to handle style matching for the elements before rendering.
<AmeliaBR> Dirk: As an implementer, I agree.
<AmeliaBR> ...But at this point, the main argument is that there are no implementations yet, so align the current spec with what is implemented & defer to a next level.
<AmeliaBR> Bogdan: Is it worth opening a separate label, for things that are deferred beyond SVG 2?
<AmeliaBR> Amelia: Do we need it? These are already in separate, levelled CSS specs. Oh, except for pattern.
<AmeliaBR> Dirk: But even for pattern, any future work should probably be done in a separate SVG module.
<BogdanBrinza> resolution: Do not block CSS Masking/Filters on this and continue the discussion in SVG WG GitHub issue targeting SVG past 2.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.