W3C home > Mailing lists > Public > www-style@w3.org > March 2012

CSS3 Images issues needing WG review

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 29 Feb 2012 16:34:51 -0800
Message-ID: <CAAWBYDAiKOnWbdQHUZ=1jzWvSORvvYURh6_OjSLy5d61vVWbqA@mail.gmail.com>
To: www-style list <www-style@w3.org>
The following email is a listing and explanation of each of the issues
at <http://dev.w3.org/csswg/css3-images/issues-lc-2012> that are
marked as needing WG review, so that WG members don't need to dig
through the emails themselves.

Issue 2 - Don't use propositions in linear-gradient()
=======
We just need a quick confirmation that, indeed, we're not changing the
linear-gradient() syntax again (in particular, removing the "to"
keyword).


Issue 3 - Use of 'bounding box' is undefined, should be 'border box'
=======
We need a quick review of the definition of "decorated bounding box"
in the spec to make sure it's sane.  For CSS, it's the border image
area (actually, the smallest rectangle containing the border image
areas of every fragment the box may be split into).  For SVG, it's the
"decorated bounding box", defined in SVG Tiny, which is the smallest
rectangle containing both the geometry and the stroke.


Issue 4 - 'element reference identifier' underdefined
=======
We need confirmation that switching back to using only id selectors,
and letting host languages define ways to make more elements match
that selector (in HTML, the CSSElementMap), is okay.


Issue 14 - image() shouldn't require implementations to support Media Fragments
========
Kenny suggested instead defining simply that the fallback algorithm
will skip any image using a fragment syntax the UA doesn't understand.

Fantasai and I decided to instead keep the requirement (moz already
implements moz-image-rect(), which is essentially the same
functionality, and we think MF is a great idea anyway), but also add
Kenny's idea to the spec so that *future* fragment syntaxes get the
same nice fallback potential.

Is it okay to keep that requirement in?


Issue 15 - Better define how image-orientation interacts with EXIF data
========
Due to legacy compat constraints, browsers are required to ignore EXIF
data by default.  I have a note to this effect in the spec, but should
it be a normative requirement?  Fantasai and I discussed, in level 4
when we add a 'from-image' value that respects EXIF, making that the
initial value and then putting '0deg' in the UA stylesheet for
browsers.


Issue 22 - There should be a non-example reference to CSSElementMap
========
Fantasai suggests that if CSSElementMap is just a CSS feature, it
should go into CSSOM.  If it's an HTML/DOM feature, it should affect
more than just this function, and perhaps be called "ElementMap".

We can either leave the spec as it is now (with an example and note
about HTML defining the CSSElementMap), or alter it somehow to
accommodate one of the above options.

I opened a bug today against the HTMLWG about this.  Note that, since
this whole thing is about a note and an example, with no normative
statements involved, this can be changed as an editorial edit at any
time after this has gone to CR.


Issue 24 - 'object-fit:cover/contain' contain seemingly-redundant text
========
I wrote up a simple explanation of the issue already at
<http://lists.w3.org/Archives/Public/www-style/2012Feb/1403.html>.  In
short, elements with an intrinsic aspect-ratio expose a unique way to
have unsatisfiable constraints, CSS 2.1 mandates a particular way of
resolving the conflict, but it's desirable sometimes to resolve it in
a different way.  object-fit:contain/cover were written to double as
switches for this behavior.

I think we should remove this functionality from object-fit.  It's
unintuitive for this property to contain such a behavior switch.  As
well, when ordinary elements gain the ability to have an intrinsic
aspect-ratio (such as through the aspect-ratio property), we'll want
the same behavior switch, and it's even *more* confusing to have
object-fit do it then.  This problem is valuable to solve, but we
should do it separately, such as in an additional property in whatever
spec ends up defining 'aspect-ratio'.

Yay/nay?


Issue 27 - Allow image() to accept element()
========
I generalized image() to fallback based on "invalid images", and then
defined element() to be an invalid image when it doesn't match
anything it can draw.  This allows an author to get some useful
behavior, such as using element() to point to an actual element's id
on page load, and then later using script to have it point to a
different script-chosen element, without having to tweak style values.
 (-moz-element() hits this use-case by consulting its fake-id-map
*first* before consulting the document so you can "override" an id
specified in the document, but I thought it would be better perf-wise,
assuming the map was a generic DOM feature, for it to be consulted
*afterwards*.)

Is this change okay?  Future <image> values that have a "failure mode"
can also hook into this to get good fallback behavior.


Issue 30 - Style resolution of elements not in a document
========
element() can references elements that aren't in a document through
use of host-language-specific features like the CSSElementMap.
element() can also reference SVG paint servers.  However, paint
servers rely on CSS being applied to them, and application of CSS when
an element is not part of a document is undefined right now.

The spec currently explicitly notes this as undefined, and gives a
recommendation for how to avoid the undefined behavior.  Is this
acceptable?


Issue 33 - aliasing of object-fit/position
========
The spec currently defines that image-fit/position are aliases of
object-fit/position, because these properties were implemented
unprefixed under that name by several printers.

Is this okay?  Fantasai notes that we could perhaps just define the
aliasing in the Print Profile, and not allow it in normal CSS.
Thoughts?

~TJ
Received on Thursday, 1 March 2012 00:35:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:51 GMT