- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 27 Jun 2013 21:59:02 -0700
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Nikos Andronikos <nikos.andronikos@cisra.canon.com.au>, "www-svg@w3.org" <www-svg@w3.org>
- Message-ID: <CAGN7qDDWO7njaZYh_oAb96ZXRfsRe-W9BcnwtpPFk_qETpkA4A@mail.gmail.com>
On Thu, Jun 27, 2013 at 9:39 PM, Dirk Schulze <dschulze@adobe.com> wrote: > When a transform setting creates a 3D > Context, the transform would still need to cause isolation. > I thought a bit more about this. Yes, if a transform is a 3d transform and it's 'transform-style' is 'flat', it should cause isolation. What is happening with filters today? (I know opacity is acting weird here) > > On Jun 27, 2013, at 9:24 PM, "Nikos Andronikos" < > nikos.andronikos@cisra.canon.com.au> wrote: > > > On 28/06/2013 1:59 PM, Rik Cabanier wrote: > >> All, > >> > >> currently transforms are listed as a property that causes isolation [1]. > >> After talking this over with developers on blink and WebKit, I would > like to drop that requirement and have them NOT cause isolation. Instead, > an element with a transform should still allow access to its backdrop. > >> > >> With the current code in WK and blink, we would have to go out of our > way to implement the currently specified behavior. Not only will it slow > down rendering, it will also increase memory since we'd have to create an > extra intermediate buffer. > > > > Heh, that's good news. Transforms causing isolation in SVG would have > sucked. > > > >> In addition, since SVG uses transforms all the time, blending would > become almost impossible to use. > >> > >> Can I make that change to the spec? > > > > I support this change. > > > > Cheers, > > Nikos > > The information contained in this email message and any attachments may > be confidential and may also be the subject to legal professional > privilege. If you are not the intended recipient, any use, interference > with, disclosure or copying of this material is unauthorised and > prohibited. If you have received this email in error, please immediately > advise the sender by return email and delete the information from your > system. > >
Received on Friday, 28 June 2013 04:59:29 UTC