-
Notifications
You must be signed in to change notification settings - Fork 49
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][fill-stroke] clarify userSpaceOnUse / objectBoundingBox applied to non-SVG elements #249
Comments
An initial test case, with filters, for people to start exploring: https://codepen.io/AmeliaBR/pen/qpGQyQ Summary of the test:
Summary of results:SVG elements:
CSS boxes:
Screenshots of results |
@AmeliaBR Could you add this to the Agenda of the CSS WG? Do you think it should be discussed during the current F2F or can this be done in a regular telconf? |
Hi @dirkschulze, I'm not at the Face to Face, but it would be good to get a wider discussion, since this affects so many specs. If it could be scheduled for late afternoon Berlin time, I could call in and give a background/overview of the issue. But it might help if you're ready with some demos / whiteboard examples of all the different cases & options. |
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> Topic: Clarify how userSpaceOnUse and objectBoundingBox apply to non-SVG elements<astearns> github: https://github.com//issues/249 <TabAtkins> AmeliaBR: Mega issue that affects everything in SVG graphical effects that we support applying to CSS boxes <TabAtkins> AmeliaBR: svg effects (gradients, patterns, clips) have a switch for how they're scaled and positioned <TabAtkins> AmeliaBR: So when you apply it to a rect, it can either be scaled to that rect, or to the svg as a whole so a gradient spreads smoothly across multiple rects, etc. <TabAtkins> AmeliaBR: When we added the specs for applying masks/clip-paths/filters to CSS boxes, it was never defined how they map to CSS coordinate spaces <TabAtkins> AmeliaBR: Actual impls are inconsistent <TabAtkins> AmeliaBR: I periodically get bug reports about how this is supposed to work <astearns> TabAtkins: roc had a proposal <astearns> TabAtkins: both anchor position according to CSS coordinate space, (and some other stuff) <astearns> TabAtkins: you at least get consistent sizing <TabAtkins> AmeliaBR: Yes, that's tehe simplest approach that still has sensible results <TabAtkins> AmeliaBR: So boxes are always the size of the css box <dbaron> s/consistent sizing/consistent sizing, but don't have the ability to have multiple boxes with views into the same gradient/ <TabAtkins> AmeliaBR: And OBB, which assumes the effect is scaled 0->1 gets that, and USOU gets normal px measurements <dbaron> (I think that's right?) <dbaron> (Tab says it is) <TabAtkins> AmeliaBR: Other possiblity is that you map USOU to the ICB (or nearest CB). Firefox does one of these, don't remember which CB. <TabAtkins> AmeliaBR: This doesn't match roc's proposal. <TabAtkins> AmeliaBR: So ncan we get more eyeballs on this? It prevents us from getting a reasonable spec on several of our fxtf specs. <fantasai> ScribeNick: fantasai |
There is actually a Firefox bug here which means that this is not entirely true: If the element has overflow, e.g. due to box-shadow, then Firefox enlarges the |
filter
,mask
,clip-path
, and the proposed extension offill
andstroke
all support SVG graphical effects applied to CSS layout boxes.The problem: none of these specs clearly define how the SVG effect-scaling attributes (
objectBoundingBox
versususerSpaceOnUse
forfilterUnits
,primitiveUnits
,maskUnits
,maskContentUnits
,clipPathUnits
,gradientUnits
,patternUnits
, andpatternContentUnits
) map to the CSS box model.I think we've got fairly consistent implementations when it comes to
objectBoundingBox
effects (but I haven't tested carefully), by mapping it to border-box. This is despite the fact that definitions in masking and filters just link to the SVG spec's definition of bounding box units. And fill & stroke has text trying to get border-box to match stroke-box.I know we don't have consistency for
userSpaceOnUse
effects. Definitions in the spec link to CSS Transforms' definition of the user coordinate system, which has now been updated to be defined as thetransform-box
width and height and position, with 1 unit = 1 CSS px. (I haven't tested whether any browsers that implementtransform-box
for SVG elements also change howuserSpaceOnUse
effects work in SVG. But my guess is no.)Of course, to make it even more confusing, only Firefox matches the spec definition of
userSpaceOnUse
for SVG elements. Everyone is else is broken in a very unhelpful way.(PS, Sorry for not bringing this up before. It's only as we've been working through FXTF issues that I realized there wasn't already an open issue for something I knew as one of the biggest issues with these specs!)
The text was updated successfully, but these errors were encountered: