Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[filter-effects][css-masking] Should x,y,width,height on mask/filter elements map to SVG geometry properties? #25
I am removing that from SVG 2 because:
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.
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.
The Working Group just discussed
The full IRC log of that discussion<AmeliaBR> Topic: Geometry attributes on <mask> and <filter>
<AmeliaBR> Github: https://github.com//issues/25
<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