- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 29 Feb 2012 16:34:51 -0800
- 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 UTC