Closed Bug 660196 Opened 14 years ago Closed 10 years ago

Implement proposed CSS filter shorthands

Categories

(Core :: CSS Parsing and Computation, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 869828

People

(Reporter: sebo, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [parity-webkit][parity-blink])

User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 Build Identifier: As seen in several other requests people want a CSS property, that allows them to apply some effects to an HTML element. Unfortunately CSS3 still doesn't include a way to specify anything for this purpose. Though implementing some filters directly into the browser has several advantages: 1. Web designers get more possibilities for styling website contents 2. No need for external image processing software 3. Smaller file sizes (no need for images) 4. In combination with CSS3 transitions you could get very nice animation effects Reproducible: Always The new property should be called "-moz-filter". Multiple filters can be applied separating them with commas. In the following I made up some example filter types: contrast(<value>) => changes the contrast of the contents <value>: values range from -100% to 100% (or -1 to 1) lightness(<value>) => changes the lightness of the contents <value>: values range from -100% to 100% (or -1 to 1) saturation(<value>) => changes the saturation of the contents <value>: values range from -100% to 100% (or -1 to 1) hue(<value>) => changes the hue of the contents <value>: values range from -100% to 100% (or -1 to 1) grayscale => changes all colors of the contents to grayscale invert => inverts all colors of the contents tint(<color>) => tints the contents in the given color <color>: All kinds of color values red => filters the red color channel green => filters the green color channel blue => filters the blue color channel mosaic(<horizonatal pixels> [, <vertical pixels>]) => creates a mosaic effect <horizonatal pixels>: values for pixels start at 0 (all normal size units are allowed) <vertical pixels>: optional; values for pixels start at 0 (all normal size units are allowed) If just <horizontal pixels> is defined, the vertical pixels get the same amount blur(<strength>) => Blurs the contents <strength>: values range from 0 to 100 sharpen(<strength>) => Sharpens the contents <strength>: values range from 0 to 100 sepia => creates a sepia effect emboss(<strength>) => creates an emboss effect <strength>: values range from 0 to 10 noise(<strength>) => creates a noise effect <strength>: values range from 0 to 100 Examples: filter: blur(5); filter: sharpen(3), lightness(50%); filter: blue; filter: grayscale; filter: emboss(2); filter: invert, sepia; filter: mosaic(10px), green; filter: tint(rgb(255, 255, 0)); If needed, I can create mockups illustrating the different effects. The new property should be proposed as "filter" to the W3C for the CSS3 spec including at least the values "grayscale", "invert", "lightness", "saturation" and "hue".
We already support applying SVG filters to HTML via CSS, no?
And in particular the "filter" CSS property is already used for SVG filters.
As filed this bug is probably invalid, but I'll morph into a bug to implement the proposed CSS filter shorthand syntax: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#ShorthandEquivalents which I think is closer to what Sebastian wants.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: CSS filter effects property → Implement proposed CSS filter shorthands
Thanks guys for showing me, that there were obviously already some people thinking of this and that there's already an approach to this. Though two notes here: 1. You have to admit it's pretty inconvenient in comparison to my proposal, because you have to (ab)use SVG for this to work 2. Also the author of the article already mentioned -moz-filter as another possible solution to this I think Dave Hyatt's first comment comes near to what I have in mind. My idea was to offer a simple way to achieve some display effects in HTML. And as I already read in several feature requests here and in the comments to the article mentioned above I am not the only one, that would like to have that possibility just using CSS.
Whiteboard: [parity-webkit]
We must add this feature in order to support the most of CSS3 elements as possible, and this is an imporant one that Chrome already supports. Besides if Firefox also implements this property the developers will be able to use this property in their webs because almost the half of the users will support this property. Greetings.
Hey Alfonso, I just bring this up 'cause people often don't seem to realise... You know that Firefox supports filters using a URL to an SVG (even a fragment of a filter embedded in the doc) right? 'cause, it seemed maybe you didn't, since while the SVG syntax is more tedious for simple effects, it can be used for all those effects and a lot more. For example: http://m8y.org/tmp/testcase281.xhtml (click the button in the lower right corner) and http://demosthenes.info/blog/534/Crossbrowser-Image-Blur So, while I really hope they add the shorthands too, they absolutely have the "long-hand" stuff down (actually, I thiiink they'd had it since like Firefox 3?). Actually, I haven't had any luck w/ the long-hand stuff in chrome personally :) So, definitely a nice to have, but, you know, I can understand their lack of urgency... That being said. SVG syntax is kind of a pain to manipulate, esp from JS :-/ so, yeah, pleeease fix sooon anyway :D :D
Blocks: 869828
The URL for the W3C specification has changed meanwhile.[1] Unfortunately I don't seem to have the rights to change the URL associated with the report. Since SVG filters are already implemented for a long time, I am wondering what is holding the people from adding the related CSS shorthands. Sebastian [1] http://www.w3.org/TR/filter-effects/
Sebastian, the URL hasn't changed. The URL you cite is a random out-of-date snapshot of the spec, basically, that has officially been "published". The URL in the URL field is the current editor's draft, which tends to be the most up-to-date version of an in-progress spec. Note that the date on the URL you cite is May 23, 2013, while the date on the URL in this bug is Oct 11, 2013, so the "TR" version is 4.5 months out of date. The mnemonic I've seen people use here is "TR is for 'trash'".
Right, the URL didn't move. It's just that the WD represents the latest official version and not the ED. Anyway, the more important part of my comment was the second paragraph. Sebastian
Blocks: css3test
Whiteboard: [parity-webkit] → [parity-webkit][parity-blink]
No longer blocks: 869828
Depends on: 869828
Status: NEW → RESOLVED
Closed: 10 years ago
No longer depends on: 869828
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.