Re: [css3-background] Issues and Proposed Resolutions

L. David Baron wrote:
> On Tuesday 2008-05-13 23:28 -0700, fantasai wrote:
> 
>> Feature Requests to Reject
>> --------------------------
> 
>> Add 'transparent' keyword for centerless border images.
>>   http://www.w3.org/Style/CSS/Tracker/issues/28 ISSUE-28
>>
>>   Reject. The use case is saving the implementation some effort.
>>   However, Bert and I don't think anyone is going to bother using
>>   this keyword, and it complicates the syntax.
>>
>>   http://krijnhoetmer.nl/irc-logs/css/20080512#l-333
> 
> I have mixed feelings about this one; I think it might save authors
> some effort as well.

Ok. I'd like to hear from some authors what they think, then. I'll
leave the issue open for now.

>> Issues to Close With Changes
>> ----------------------------
> 
>> 'bounding-box' and 'continuous' should affect blocks differently in multi-col
>>   http://www.w3.org/Style/CSS/Tracker/issues/43 ISSUE-43
>>
>>   Resolve: Fix 'bounding-box' definition for block to match the
>>   definition for inlines.
>>
>>   http://krijnhoetmer.nl/irc-logs/css/20080512#l-162
> 
> ISSUE-43 doesn't actually seem to point to any of the correct
> messages for this issue.  Are you referring to to defining it so it
> works when the box is sliced vertically rather than horizontally?
> (i.e., a lot like ISSUE-47, except for block vs. inline rather than
> for different text directions?

Sorry, I meant
   http://www.w3.org/Style/CSS/Tracker/issues/42 ISSUE-42

I've clarified the text for 'background-break' in the editor's draft
as follows:
   http://dev.w3.org/csswg/css3-background/#the-background-break

>> Proposal for 'no-clip' value for 'background-clip'.
>>   http://www.w3.org/Style/CSS/Tracker/issues/16 ISSUE-16
>>
>>   Resolve: Add 'no-clip' value to 'background-clip', mark "at risk".
>>
>>   http://krijnhoetmer.nl/irc-logs/css/20080512#l-447
> 
> This really doesn't fit well with the model of what backgrounds are,
> and it's quite a bit of work to implement correctly (since it means
> that repaints required for dynamic changes can extend outside the
> element in complicated ways).
> 
> I also haven't seen a strong use case given.
> 
> I'd prefer not adding this.

Lots of modern designs like to break the visual box with graphics.
I think this feature would make that easier, so graphics wouldn't
have to be cut up and positioned precisely. My preference would be
to leave it in and get some feedback at least in the next working
draft if not in the CR.

>> Add "spread" value to 'box-shadow'.
>>   http://www.w3.org/Style/CSS/Tracker/issues/41 ISSUE-41
>>
>>   Resolve: Add "spread" as optional fourth length value after "blur".
>>
>>   http://krijnhoetmer.nl/irc-logs/css/20080512#l-503
> 
> Is the idea that a spread is like a blur, but not blurry?
> 
> Note that the text in the spec differs from the proposal in the
> issue in that the text in the spec implies that spread causes
> curvature at the edges, whereas the text in the issue implies that
> the corners remain square.
> 
> If the former was intended, you need to define what negative spreads
> do.

Treating it as a radius defines what negative spreads do quite simply.
But I'm guessing from Brad Kemper's comments that sharp corners are
preferred? I'll clarify the draft to suggest that.

>> Rename 'background-origin' to 'background-box'
>>   http://www.w3.org/Style/CSS/Tracker/issues/46 ISSUE-46
>>
>>   Resolve: Bert and I tentatively accept this suggestion, but are open
>>   to better names.
>>
>>   http://krijnhoetmer.nl/irc-logs/css/20080512#l-715
>>   http://krijnhoetmer.nl/irc-logs/css/20080513#l-3
> 
> I don't think this is a good name, since it then becomes unclear how
> the property is different from 'background-clip'.  Given that there
> are *two* boxes involved (currently called origin and clip), I don't
> think either should just be called "box".

Ok. Left unchanged for now.

~fantasai

Received on Monday, 11 August 2008 15:47:54 UTC