W3C home > Mailing lists > Public > www-style@w3.org > April 2014

Re: [css3-background] Border-image clarifications

From: Brad Kemper <brad.kemper@gmail.com>
Date: Thu, 17 Apr 2014 16:47:56 -0700
Message-Id: <16F6624A-C5FF-459D-9B32-60C3593D5B54@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
To: Matt Rakow <marakow@microsoft.com>

> 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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC