703217 - Implement image() from CSS Image Values and Replaced Content Module Level 4

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Aharon (Vladimir) Lanin]

The CSS Images Level 3 Working Draft defines image() notation (http://www.w3.org/TR/2011/WD-css3-images-20110908/#image-notation). Supporting it would allow not only image fallbacks, but also image flipping for RTL, on images annotated with the ltr keyword (as in, "this image is ltr; flip when it is being displayed in rtl"; there is also the rtl keyword for the inverse case). That would simplify mirroring some pages, especially ones with relatively simple graphics.

Comment 1

[Aharon (Vladimir) Lanin]

FYI, The ltr and rtl keywords have now been dropped from CSS3 images due to a design issue. The feature has been deferred to Level 4 (but may wind up with a different syntax than originally suggested). The design issue (see http://lists.w3.org/Archives/Public/www-style/2012Mar/0243 and replies in "Next in thread" chain) is that it is not clear that there is a use case for specifying different modes (non-flipping, ltr, rtl) for different images in the fallback chain. That the syntax allows this may indicate that it is suboptimal.

Nevertheless, it would still be useful if browsers prototype this feature in the current syntax (suitably prefixed as necessary).

Comment 2

[Aharon (Vladimir) Lanin]

This functionality is now back in Level 4 (http://dev.w3.org/csswg/css4-images/#bidi-images), with a slight modification.

Comment 3

[Florian Bender]

Media Fragments for Images: Spatial Dimensions support is required before image() can be implemented (per spec). 

Please change this bug's description to remove the second part so it just says e. g. "Implement image() (CSS Image Lvl 3)".

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Shouldn't this depend on bug 801844, rather than the other way around?

Comment 5

[Florian Bender]

AFAICS Bug 801844 is a meta bug, so blocking it is the correct relationship.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think the idea is that we'll do bug 801844 before we fix this bug. And I don't think bug 801844 is a meta bug, actually.

Comment 7

[Florian Bender]

(Seth Fowler [:seth] from Bug 801844 comment #1)
> Let's treat this as a tracking bug since there are a lot of subprojects
> here. I'll create additional bugs for the specific features as needed.

Looks to me like a meta bug (ok, tracking bug, whatever ;-) ). Implementing image() is part of the refactoring. 

BTW: html5bidi should be removed from "blocking" as this is longer covered by CSS3 but CSS4 (this bug is about CSS3).

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We don't usually implement new features as part of a refactoring.

Comment 9

[Seth Fowler [:seth] [:s2h]]

We agree that bug 801844 does not have the best title. =) The intention was that we add support for the CSS3 image-related features mentioned in that bug's description, while making the changes necessary to do so in such a way that it will be easier to support the CSS4 features also mentioned in the bug when the time comes. I don't think that "refactoring" was the right term to use for this. Sorry if this has caused some confusion.

Comment 11

[Estelle Weyl]

MDN image() page: https://developer.mozilla.org/en-US/docs/Web/CSS/_image

JSFiddle for image media fragments: http://jsfiddle.net/Wf2Vj/5/

image with spatial fragment currently supported only in FF (since FF4), but via the -moz-image-rect(url(), t, r, b, l) syntax (see http://jsfiddle.net/Wf2Vj/7/)

Comment 12

[jsnkuhn]

Have run into a couple of cases lately where the Image Fragments from the image() function would be useful to have: being able to use sprites for repeating backgrounds and border images.

Comment 13

[jsnkuhn]

CSSWG is moving on to the ideas phase for css-images-5 which looks like it will include an @image rule for manipulating images before adding to CSS. This looks to add things that folks have been asking for years like transforms, filters, opacity, etc to CSS images. It will likely use the image() notation from css-images-4.

So even more reason now to have a stable version of css-images-4 image() to build on when the time comes for @image

https://github.com/w3c/csswg-drafts/issues/6807

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:emilio, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 15

[jsnkuhn]

css-images-4 will soon be getting a long overdue update (it's been 5 years yikes). Seems like a good time to revisit this.