- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 29 Jul 2001 18:17:56 -0700 (Pacific Daylight Time)
- To: fantasai <fantasai@escape.com>
- cc: <www-style@w3.org>
On Sun, 29 Jul 2001, fantasai wrote:
> Ian Hickson wrote:
>> I assert that the spec actually says that [...] background colours
>> should be painted up to the border edge.
> Yes, that behavior can be deduced from the Errata, but not the
> original spec.
(Technically speaking, the errata is a normative part of the spec.)
>> According to the CSS2 spec, section 14.2.1, background-position
>> specifies the position of a background image relative to the
>> padding edge of a box, and tiling should cover only the content and
>> padding areas of a box:
>
> I don't dispute this.
Ok, good. :-)
So the only issue at hand is where the background colour should be
painted: to the border edge, or to the padding edge.
>> And, according to section 8.5.3, borders are drawn on top of a
>> box's background:
>>
>> # All borders are drawn on top of the box's
>> background.
>>
>> This logically means the background color should be underneath the
>> border, but not the background image.
>
> The logic of this behavior escapes me.
Ignoring the logic of the behaviour for a second, and concentrating
merely on what the spec says, the two statements above support my
conclusion that background colours should go underneath the border,
while background images should not, right?
> /Logically/ backgrounds should have consistent confines.
I disagree. While I'm not sure logic can be applied to this situation,
there certainly are examples in the real world where the behaviour I
assert is described by the spec exists and is accepted as good
("logical", if you like). One of these would be a painting:
+------------------------------------
:\ frame =============================
: \ \ +-------------------------------
: \ \ \ : :
: \ \ \ : :
: \ \ \ : :
: ` ` ` : :
: : :
\:/ \:/ :
+------------------------------------ :
\ canvas \:/
\ + - - - - - - - - - - - - - - -
\ YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
\ \YY painting (image) YYYYYYYYYY
\ YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
` `''''''''''''''''''''''''''''''
...where the background-image (painting) is on top of the
background-color (canvas), while the border (frame) goes on the
remaining part the background-color (canvas).
For an aesthetic point of view, painting the borders on top of the
background colour (as opposed to on top of transparency) seems ugly to
me. It also seems illogical if you view the borders as being drawn on
top of the box, just like the frame in the example above, instead of
around the box.
>>> I think it would be easier to correct the one passing mention of
>>> background in the border area in 8.5.3 than the five (or six)
>>> instances of just content & padding.
>>
>> The instances are already corrected -- see the errata. The only
>> outstanding errata item is that the spec should more explicitly
>> state that the background images are clipped to the padding edge.
>
> It's stated in several places already. The CSS2 spec is very
> explicit about this.
In that case, the spec is clear. (I still think it should be made even
clearer, possibly with an example.)
>> This testcase demonstrates why it is IMHO nicer for the background
>> images not to overlap the border:
>
> And I agree with you.
So we are violently agreeing here?
> Here, I'll support the statement in my previous post:
>
> Analysis of spec -
>
> The CSS2 spec, in four other places, refers to the behavior
> specified in 14.2, where 'background' is defined. Only in Section
> 8.5.3 does it extend 'background' to the border area.
>
> 14.2 - In defining "background", the spec writes that it
> gets painted in the content and padding areas.
> Borders styles are mentioned in a separate sentence
> dealing with border properties.
Corrected by the errata.
> 14.2 def 'background-image' - The spec writes that tiling
> only covers content and padding areas.
> 14.2 def 'background-attachment' - The spec writes that a
> a background image is only visible within the
> padding and content areas.
Agreed.
> 8.1 - The spec states that the backgrounds of the padding
> and content areas are specified by the background
> properties, but that the background of the border
> area is specified by the border properties. (This
> can make sense because content that overflows the
> border is rendered on top of it, not underneath it.)
And the errata corrects this to read "The background style of the
content, padding, and border areas of a box is specified by the
'background' property of the generating element".
> 17.5.1 - The image depicting a table with background-
> colored, double-bordered cells does not show any of
> the background between the two stripes of border.
Um, yes it does.
> Browser testing results and comments:
>
> Microsoft has background problems in any case: They render 0% 0% as
> upper left corner of the border edge, and I see nothing in either
> spec to support that interpretation.
>
> MSIE extends both background color and background images to the
> border edge.
>
> *BUT* they render according to 14.2 for table elements, (for which
> backgrounds are used much more extensively by authors than for block
> elements.)
>
> So MSIE needs to change it's background rendering regardless of
> whether the spec changes or not.
Note that that applies to WinIE. MacIE does the opposite.
> Opera is also not consistent in its interpretation. If there is just
> a background color, it behaves according to Section 8.5.3. However,
> if there is a background image, it follows 14.2. They should choose
> either one or the other.
Actually, even when there is a background-image, they draw the
background behind the border. They just have a repaint bug which means
you have to cause an invalidate rect to overlap their border for them
to get it to paint correctly.
> Mozilla behaves similar to Opera
Ironically, Mozilla actually exhibits an almost identical painting bug
(except that the border is painted correctly initially and only
repaints cause it lose the colour behind the border).
> However, unlike Opera, it paints that image over a background color
> extending to the border edge. This, too, is inconsistent.
Inconsistent only if you consider them the same "layer". However,
background images are drawn on top of the background colour (they have
to be, because they might themselves be partially transparent).
If you view this as a multiple level stack, as I do, maybe it will
seem more consistent (or at least, maybe consistency will no longer
seem to be relevant):
[] [] [] [] [] [] inlines
| O | | O | border
=================== background-image
----------------------------- background-color
> Amaya, the W3C browser, behaves according to section 14.2, based on
> testing 'double' (since the copy I have [v5.1] does not support
> 'dashed' or 'dotted').
I would strongly recommend not using Amaya when trying to draw
conclusions as to how to implement something. It is a testbed browser,
not a reference implementation.
> ...even though CSS1 explicitly paints borders on top of the
> background, with the current state of browser implementations and
> CSS2 wording, I think it would be easier to correct the one passing
> mention of background in the border area in 8.5.3 than the five (or
> six) instances of just content & padding.
Given that the existing errata items can be taken as normative parts
of the specification, why do you believe the spec should be changed,
and exactly how do you think it should be changed?
--
Ian Hickson )\ _. - ._.) fL
Invited Expert, CSS Working Group /. `- ' ( `--'
The views expressed in this message are strictly `- , ) -> ) \
personal and not those of Netscape or Mozilla. ________ (.' \) (.' -' ______
Received on Sunday, 29 July 2001 21:17:19 UTC