- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Thu, 17 Apr 2014 16:47:56 -0700
- To: Matt Rakow <marakow@microsoft.com>
- Cc: "www-style@w3.org" <www-style@w3.org>
> On Apr 16, 2014, at 11:53 AM, Matt Rakow <marakow@microsoft.com> wrote: > > Hi all, > > We've been reviewing the border-image properties and would like to add a few minor clarifications to help disambiguate certain portions of the spec. I think all of this is in line with the current intent of the spec, so this is intended just to eliminate possibilities for misinterpretation and shouldn't represent any functional changes. > > 6.1: "Specifies an image to use instead of the border styles" -- this sounds like it implies the border image overrides border styles, rather than simply changing the rendering. "Specifies an image to render instead of the border style" clarifies, I think. In what way is it not an override? > 6.1: "as an additional background layer for the element" -- I think this is making reference to the "fill" behavior, but then I think this starts to imply interaction with background-related features that may not be intentional? One simple example of many -- should background-blend-mode apply to the border image? To just the "fill" portion? Or not at all (I think this is the intention). If this interpretation is correct, then I think this phrase should be removed such that the definition doesn't imply interaction with backgrounds. As I recall, this is in reference to the layer sitting just above the background layers. I agree that it should not imply full status as a background layer for blend-mode, etc. It could be worded better. > 6.1 "the element's borders are invisible" -- invisible seems ambiguous (Can they still be hit-tested against? Are they reflected in DOM APIs?) -- I think this should be phrased as "the element's borders are replaced by the border image" Hmm. It's been a while, but I think the answer to both questions is yes, and there is no hit testing of the border image. So the regular border is still there, but invisible. > 6.2 "Negative values are not allowed and values bigger than the size of the image are interpreted as '100%'." -- Is this stating that negative values are thrown out as invalid, and boundary-clamping is done only on the upper bound? I believe so. > Or that boundary-clamping occurs on both ends? Also, I'm assuming that the computed value is the clamped value and not the specified value in this case. > > 6.2 "auto-sized background" -- This term isn't really defined, but I think this is referring to "a background whose background-size property is 'auto'" -- If so, That's the intent, yes. I don't have any strong opinions on your suggested remedies, below. They seem reasonable enough to me. > it would probably be good to make that term a link to section 3.9 or else define it inline. > > 6.3 "'auto' If the image does not have the required intrinsic dimension then the corresponding border-width is used instead." -- Should be "corresponding computed border-width", similar to the definition for <number> > > 6.4 "multiple of the corresponding border-width" -- Should also be "corresponding computed border-width" > > 6.4 -- the formatting of value description is inconsistent with section 6.3. Could this be reformatted as a <dl> in the same fashion as section 6.3? > > Thanks! > -Matt >
Received on Thursday, 17 April 2014 23:48:29 UTC