- From: Dirk Schulze <dschulze@adobe.com>
- Date: Wed, 24 Jul 2013 01:18:06 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Cameron McCormack <cam@mcc.id.au>, "public-fx@w3.org" <public-fx@w3.org>
On Jul 24, 2013, at 9:47 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Jul 23, 2013 at 10:56 PM, Dirk Schulze <dschulze@adobe.com> wrote: >> On Jul 24, 2013, at 7:20 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> On Tue, Jul 23, 2013 at 5:36 PM, Cameron McCormack <cam@mcc.id.au> wrote: >>>> I don't think it's useful to have the computed value for the 'filter' >>>> property to keep distinguishing whether a filter primitive function's >>>> argument was a number or a percentage. So can the 'Computed value' say >>>> something like: >>>> >>>> as specified, but with numbers that indicate percentage values >>>> computed to percentages >>>> >>>> or whatever is the appropriate way to word it. I'm not sure whether >>>> computing these values to the percentage or the number or more common, so >>>> whichever way makes more sense. >>>> >>>> I'm assuming that numbers can be used to mean the same thing as percentages >>>> (with 0..1 meaning the same as 0%..100%), but this needs to be said >>>> explicitly. >>> >>> Assuming that percentages are computed against something known ahead >>> of time (which I think they all are), yes, the computed value >>> shouldn't preserve the type. >> >> I disagree on this. It would be inconsistent with other usage of unit values in other properties. > > Which other properties? Note that in CSS in general, computed values > are as absolute as possible without layout information. When we can, > we compute away percentages - they only stick around if they can't be > resolved at computed-value time. > >> We should preserve the unit. Furthermore, Cam is talking about some filter functions. There are others that take length values and degrees. We certainly want to keep units here. > > I'm not sure what these sentences have to do with Cameron's > suggestions. If I'm reading him correctly, he's suggesting computing > away the percentage. His description was about primitives where the > percentage is relative to a number, but obviously if they were > relative to a length or an angle, the result would be a length (in px) > or an angle (in deg) (because those are the generally acknowledged > "absolute" units). Implementations seem to disagree with you: var e = document.getElementsByTagName('body')[0]; e.style.backgroundImage = "linear-gradient(0.25turn, blue, red )" window.getComputedStyle(e).getPropertyValue('background-image') Blink: "linear-gradient(0.25turn, blue, red)" FF: "linear-gradient(0.25turn, rgb(0, 0, 255), rgb(255, 0, 0))" IE: "linear-gradient(0.25turn, blue, red)" All implementations return 0.25turn instead of 90deg. And IIRC you even worked on one of the gradient implementations. Greetings, Dirk > >> If we do not have the percentage value on the filter functions mentioned by Cam, the computed property values would look inconsistent in itself. > > I don't understand, unless this paragraph is calling back to your > previous paragraph, where you thought that percentages would only be > resolved for some of the primitives. > > ~TJ
Received on Wednesday, 24 July 2013 09:39:31 UTC