Closed Bug 13473 Opened 25 years ago Closed 24 years ago

root element's background should cover the canvas

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: ian, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: css1, regression, Whiteboard: (py8ieh:xmlify some testcases))

Attachments

(3 files)

test case showing incorrect enlargement of root element
731 bytes, text/html
Details
CSS file for the XML testcase
192 bytes, text/css
Details
XML test case
577 bytes, text/xml
Details 
According to section 14.2 of CSS2, the background of the HTML element (and the
root element of any XML documents) should spread into the canvas:
#   The background of the box generated by the root element covers the
#   entire canvas.
                                 - http://www.w3.org/TR/REC-CSS2/colors.html#q2

We currently don't do this.

Test cases:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/13.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/14.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/15.html
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/16.html

David: I cc'ed you because you recently mentioned this in www-style and so I
figured you might be interested.
See also bug 7039.
Status: NEW → ASSIGNED
We used to do this just fine. I know, because I wrote the code to make it do
that. Maybe it regressed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
The issue here is margins on the HTML element.

We do size the HTML element to be the size of the canvas. And we render its
background everywhere the box is.

However, the HTML element's margins are not part of its box and so we don't
render the background there, and so the canvas's default background shows
through.

In section 14.2, the CSS2 spec says: "background" refers to the background of
the content and the padding areas. ... Margins are always transparent so the
background of the parent box always shines through.

I think we're doing exactly what the spec intends.
Status: RESOLVED → VERIFIED
Based on troy's comments, marking as verified invalid.
Based on troy's comments, marking as verified invalid.
I think I agree with Ian on this.  Perhaps the margins on the root element
should be forced to 0, though.  There was some discussion on whether the root
element has margins a while back.
I don't see why. Ian's basis for the bug is based on "background", and that's
very clearly defined in 14.2

There was a discussion of whether margins applied to the root document element.
As I remember Hakon's opinion was that for HTML documents they should not apply,
but for XML documents they should.

That seems silly to me, and that's why we don't do it.

Note that since the canvas has a pseudo element style that applies to it the
content creator has complete control over the appearance of the canvas and can
do this:

:canvas {background-color: yellow;}
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
#   The background of the box generated by the root element covers the
#   entire canvas.
                                  - http://www.w3.org/TR/REC-CSS2/colors.html#q2

The BACKGROUND of the root element, which in HTML happens to be <html>, COVERS
THE ENTIRE CANVAS. We are not doing this now! You just need to propagate the
background of the root element up to the canvas' background.

Troy, if you want to mark this WONTFIX, then please tell me which part of the
above quote you disagree with...
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WONTFIX
No, we're not going to propagate the root element's background to the canvas
element.

As far as why, I very clearly stated that in my original response to the bug:
"In section 14.2, the CSS2 spec says: "background" refers to the background of
the content and the padding areas. ... Margins are always transparent so the
background of the parent box always shines through."
Severity: normal → minor
Ok for the WONTFIX, but I have to point out that the 'margins' quote is not
relevant here. The canvas itself has zero margins. Of course, the margins of
the root element show the canvas' background, but the canvas' background, per
the quote I give above, should be the same as the root element's background.

Hence, in the margins of the HTML element, you should see the background of the
canvas, which should be the same as the background of the HTML element.

Not reopening. This is a minor issue.
That's where we disagree. I think the margins part is relevant.

We do size the HTML element (margin + border + padding + content) to cover the
entire canvas. And then we have the canvas shrow through the [transparent] HTML
element's margin area

However, as you state it's a relatively minor issue, and someone can work around
it by either:
- not specifying a margin on the HTML element
- specifying a background on the :canvas pseudo element

The reason I'm reluctant to state propagating the HTML element's background up
to the canvas, is that we already have to do this for the BODY's background.
To make that work required quite a bit of code, and it doesn't currently work
right when the BODY's background changed dynamically

That's a bug assigned to Peter, but it's a whole class of problems I don't want
to duplicate if we start propagating the HTML element's background up to the
canvas
Status: RESOLVED → VERIFIED
Ah, I see. I understand the part I quote to mean that in the case of the HTML
element, the root element background should propagate into the canvas background
-- not using the same 'reverse inheriting' mechanism of BODY->HTML, but simply
drawing the background past the borders.

As you say, this would probably bring in a whole load of problems.
Verifying WONTFIX.
Note that Opera 4 alpha attempts to do this correctly.
Current behavior also disagrees with the following statement from CSS2 9.1.2:

# The width of the initial containing block may be specified with the 'width'
# property for the root element. If this property has the value 'auto', the user
# agent supplies the initial width (e.g., the user agent uses the current width
# of the viewport).

See the above testcase.  The green border should fit a little outside the blue
one, but the entire canvas should be red.
David: Why should "The green border ... fit a little outside the blue one"?
The spec says behaviour is UA-defined, so we can do what we like in that
particular respect.

The red should indeed be everywhere, though, including the HTML margins, and
the HTML box is too tall.
Keywords: css1
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Since bug 15405 was reopened (by Troy no less), reopening this one.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Troy no longer with us, trying buster...
Assignee: troy → buster
Status: REOPENED → NEW
Summary: {css1} root element's background should cover the canvas → root element's background should cover the canvas
I don't fully understand the issue here.  Ian, David:  is this just a duplicate 
of 35681?
buster: No, it isn't exactly a DUP (although as David says, this _could_ get 
fixed when 35681 is fixed).

The issue here is that the background of the :root element (HTML in an HTML 
document) should be painted on the canvas frame not the root frame, but offset
so that it looks like it is painted on the root frame.

See http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/13.html

At the moment, we are doing the wrong thing on several counts. First off, the
BODY background is being propagated to the HTML background, even though HTML's
background is not transparent. And then, the HTML background is being 
propagated to the canvas, but not leaving it aligned with the HTML frame.

That's actually several problems. I'll reopen the bug on BODY->HTML propagation.
Keywords: regression
Depends on: 2285
I doubt this one is going to get fixed.  David, Ian: there are comments in here 
that this is a "minor" issue.  As such, it's going to fall off the back of 
the 6.0 train, unless I hear good arguments why it's a vital compliance issue.

This bug has been marked "future" because we have determined that it is not 
critical for netscape6.0. 
If you feel this is an error, or if it blocks your work in some way -- please 
attach your concern to the bug for reconsideration.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Noooo! :-) This *used* to be a minor issue but it has now become quite a major
issue, since the HTML and BODY elements' backgrounds and sizes changed recently.

Browse through all the test cases at
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/
...to see how much of a major issue this now is. Most of the tests now fail,
some in quite major ways that are non-compliant and break forwards compatability
with working CSS2 browsers.
Severity: minor → major
Target Milestone: Future → ---
Thanks, Ian.  That's the kind of feedback I need when I mark these bugs FUTURE.  
I'll investigate further.
What issues in this bug will be fixed if bug 35681 is fixed?  Do they depend on 
how it is fixed?  Should it be marked as a dependency?
Ian:  Should there be a dependency relationship between this bug and bug 15405? 
 Which way?
They are certainly linked, but I don't know if either needs to be fixed before
the other one can be.

What we need is a third field, for related bugs... (I've said this before.)
I've got a fix for this one too - related to bug 2285
Assignee: buster → attinasi
Status: ASSIGNED → NEW
I think the fix attached to bug 2285 (if that's the fix you mentioned) only
fixes the problem for HTML.  It still leaves the XML problem open (where this is
perhaps a more serious issue), so the bug should probably stay open.
I believe this is fixed now for HTML (see patch in bug 2285), however David 
Baron says the XML cases still require attention.

Does anybody have a testcase for XML? I'd like to investigate what is going on 
there too. I have looked at the two XML testcases on Ian's site 
http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/19-alt.xml 
and http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/background/19.xml

The 19-alt.xml test looks like the text says it should (except that it is 
growing to the width of the viewport?), however 19.xml looks very different.
Status: NEW → ASSIGNED
Never mind.  XML is fine.  I'm not sure where the XML root->canvas propogation
is being done, but anyway...  (I would think it would be easier to use that same
code for the HTML HTML->canvas propogation, and leave the BodyFixupRule to do
only the BODY->HTML, but maybe not.)
Marc: Test 19 is another issue altogether, filed separately, and which is not 
going to be fixed for 6.0: Bug 15462. Test 18 (and 17) also shows another 
problem, also covered separately: bug 15405.

I need to make some XML equivalents of the other test cases, in particular 13
to 16. I'll add it to my list of things to do, but if anyone else wants to do
it instead....
Keywords: qawanted
Whiteboard: (py8ieh:xmlify some testcases)
David, in ConstructDocElementFrame (in CSSFrameConstructor) there is a call to 
PropagateBackgroundToParent. That code, written by Troy, propagates the 
background of the DocElement to it's parent... Could this be where the XML case 
is handled? If it is, then we are going to fail on dymanic updates of that 
background (which is why I moved that logic to the BodyFixupRule in the first 
place). This background propagation issue is looking more and more messy the 
longer I look at it. At the very least we should consolidate the code that 
manages this, and as David suggested, the BodyFixupRule is probably not the best 
place (although I do agree that the specific rules for HTML should be enforced 
there).
Fixed by fix to bug 2285 (nsHTMLBodyElement.cpp) and checked against the 
testcases given in the initial comment.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
As per meeting with ChrisD today, taking QA.

Will verify once I've checked the XML case.
QA Contact: petersen → py8ieh=bugzilla
I'll atach a XML test case I made, not sure if it's ok, hope it helps with the
verification.


    
    

    
  

      
      
      
      

        Attached file
          
        XML test case
        — 
      

    


  

    
    

    
  
verified working on build 2000100208 (trunk not commercial) on windows 98.
Tests cases backgrounds go all the way to the edge of the document (no margin).
Status: RESOLVED → VERIFIED

    
  
Keywords: qawanted

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: