Anchor list items are not contained within their parent block.

RESOLVED INVALID

Status

()

RESOLVED INVALID
16 years ago
16 years ago

People

(Reporter: dbasch, Assigned: jst)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: 1.3a

What I have discoverd that the problem is that if I give an A element within a 
LI element a border of 6px and a width of 100%, the border width is added to 
the width of the A block element. This causes the A element to overflow on the 
right hand side. The weird part is that only A block elements seem to do this 
(As I understand it 'display:list-item' transforms A from inline to block). If 
I dont give a width percentage the A block elements render correctly in Gecko . 

So, can anyone tell me why the border width is being added to the overall width 
of the A block element in Gecko? 



Reproducible: Always

Steps to Reproduce:
1.visit www.plexisweb.com/bug/index.htm
2.
3.



Expected Results:  
The anchor elements should be contained within the parent DIV. This renders 
correctly on IE.

Comment 1

16 years ago
I think I could :-). Because it seems to be a result of bug 57882. "List markers
render inside adjacent float edge".
(Reporter)

Comment 2

16 years ago
I believe that it is a different issue for several
reasons.

1) There are no list markers because of the following
CSS rule: "list-style: none outside;"

2) The amount of overflow on the right hand side of
the A element is directly proportionial to the
combined width of the left and right borders. If you
change the border widths to a larger amount the
overhand increases by the same amount.

3) This error only occurs when using A elements. Not P
or h1.

4) No floats are involved.

Thanks,
Derek Basch
> So, can anyone tell me why the border width is being added to the overall 
> width of the A block element in Gecko? 

Because that is what the CSS spec says to do -- "width" is the size of the
_content_, not including padding and borders.  Now that IE6 is out, every single
major browser on the market (IE6/Win, IE5/Mac, Gecko, khtml, Opera) renders that
way (or at least IE6 claims to render that way; it may do it for display:block
but not display:list-item).

The rendering I see is correct.



Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

16 years ago
> Because that is what the CSS spec says to do -- "width" is the size of the
> _content_, not including padding and borders.

Fine, this would explain why the border is added to the overall width of the A 
element. However, if that is the case then we have another bug to look at.

The P element is a block-level element just as an A element with "display: list-
item" is contained in a primary block box. Quote from spec: "This value causes 
an element (e.g., LI in HTML) to generate a principal block box and a list-item 
inline box."

So, logically P elements should also overflow on the right hand side. To verify 
this I ensured that the P element was in fact rendering as a block by adding 
what should be a redundant block rule. I also changed all instances of list-
item elements to block elements.  The same erroneous rendering (according to 
the box model you described) of the P element resulted (no right overflow). I 
have updated the test case located at the above URL.

> Now that IE6 is out, every single major browser on the market (IE6/Win,
> IE5/Mac, Gecko, khtml, Opera) renders that way (or at least IE6 claims to
> render that way; it may do it for display:block but not display:list-item).

IE incorrectly renders the border inside of the containing block for both block 
and list-item displays.

Thanks,
Derek Basch  
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
> So, logically P elements should also overflow on the right hand side.

Except you didn't set "width: 100%" on it, unlike the <a> elements.  Adding that
makes it act similarly to them.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

16 years ago
Created attachment 111519 [details]
Test Case: External Cascading Style Sheet
(Reporter)

Comment 7

16 years ago
Created attachment 111520 [details]
Test Case: XHTML Document
(Reporter)

Comment 8

16 years ago
Not to be disrespectful, but, wrong! 

> I have updated the test case located at the above URL.

Perhaps you were referring to a cached copy from the start of this bug report?

I have attached the style sheet and XHTML document test cases to this bug 
report so that there will be no confusion. Also here is an excerpt of the 
relevent sections from the stylesheet:

#menuList A {
	display: block;	
	background: Silver;
	width: 100%;	
	border-right: 12px solid #9932CC;
	border-left: 20px solid #9932CC;		
}

#menuList p {
	display: block;
	width: 100%
	padding: 0px 3px 0px 3px;
	font-size: 10pt;
	color: white;
	background: Silver;
	border-left: 12px solid #9932CC;	
	border-right: 12px solid #9932CC;
}

both elements have 'width: 100%' rules.

Thanks,
Derek Basch

 



 
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Attachment #111519 - Attachment mime type: text/plain → text/css
	width: 100%

no semicolon, so i gets munged with the next declaration and ignored.  I had not
looked at the source; merely at the styles that actually got applied; that is
why I had not seen it.  Sorry about that.

Sorry, but still invalid.  ;)  (and there is nothing disrespectful about telling
someone that he is wrong, imo).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.