Open Bug 275479 Opened 20 years ago Updated 2 years ago

Misalignment in 'ez publish' created website

Categories

(Core :: Layout: Floats, defect)

Product:
Core
Component:
Layout: Floats
Platform:
x86
All
Type:
defect

Tracking

()

People

(Reporter: sbrown3, Unassigned)

References

(
URL
)

Details

(Whiteboard: [reflow-refactor])

Attachments

(2 files, 1 obsolete file)

Testcase
406 bytes, text/html
Details
Testcase extracted from comment 13
473 bytes, text/html
Details 
I created a website using 'ez publish', a content management system I downloaded
from ez.no.  My site uses standard templates that came with the software.  At
the top of each page is a link to a login screen and a search input box,
separated by a vertical bar.  In Firefox (and Mozilla), the line with these
items wraps at the vertical bar.  The search box is pushed underneath the login
link.  These items should appear on the same line.  My site appears correctly in
Opera and Konqueror.

To see, go to http://69.113.88.148:85/gallery (hurry - this is not a static ip
address).
What version of Firefox are you using? See
http://www.mozilla.org/support/firefox/bugs

In accordance with the bug reporting instructions, I reproduced this problem in
nightly builds of Firefox and Mozilla application suite.  Since it occurs in
Mozilla, I'm changing this from a Firefox bug to a 'Mozilla Application Suite' bug.
Product: Firefox → Mozilla Application Suite
The Login and Seach items seem to be generaterated by this HTMLÆ

                <ul>
                    <li class="toolbar-item first"><a
href="/gallery/index.php/gallery/user/login">Login</a>&nbsp;</li>
                    <li class="toolbar-item last">
                        <div class="label">Search: </div>
                        <div class="search-line">
                            <form
action="/gallery/index.php/gallery/content/search" method="get">
                                <input class="searchinput" type="text" size="10"
name="SearchText" id="Search" value="" />
                                <input type="image" class="searchimage"
src="/gallery/design/standard/images/1x1.gif" />
                            </form>
                        </div>
                    </li>
                </ul>

Other things being equal, I would expect two list items to be on two
separate lines.

Do you know how the list items in the toolbar-design div are styled_ 
The list items are styled by:

li
{
    margin: 0 0 0.3em 0;
    padding: 0;
    line-height: 1.25em;
}

There are two lines immediately before the ones posted by Ben Fowler:

            <div id="toolbar-top">
            <div class="toolbar-design">

I'm guessing that the toolbar-top is styled by:

div#toolbar-top li.first, div#toolbar-bottom li.first
{
    display: inline;
}

Google turned up a site that says that "display: inline" doesn't work properly
on list items and definition lists" in Netscape 4.x.

http://www.w3schools.com/css/pr_class_display.asp

I have pasted your styles into an HTML file similar to yours, videlicet:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="no" lang="no">
<head>
    <title>Welcome to Steve Brown's Wallpaper Gallery - Steve Brown's Wallpaper
Gallery</title>
<style type="text/css"><!--
li {
    margin: 0 0 0.3em 0;
    padding: 0;
    line-height: 1.25em;
}

div#toolbartop li.first, div#toolbarbottom li.first {
    display: inline;
}
--></style>    
</head>
<body>
    <p>Para 1</p>
       <div id="toolbartop">
                 <ul>
                    <li class="first"><a
href="/gallery/index.php/gallery/user/login">Login</a></li>
                    <li class="last">Search:</li>
                </ul>            
        </div>
    <p>Para 2</p>
</body>
</html>

and both <li>s are displayed inline if they are both of class first.

Does the file (as I have it above) display as you expect? If not, how
do you expect it to display?

The CSS system in mozilla has been completely re-written at least
once since Netscape 4, and that browser has not been suitable
for serious work for, say, the past six years.
I cut-and-pasted the HTML from bfowler's comments.  When viewed in the browser,
the <li> items appear on two lines.  I expect them to appear on one line.  I
tried it in Firefox and Opera and it did not work as I expected in either
browser, so I'm not sure if this is the same as the original code I posted,
which DOES work in Opera (and the other browsers I mentioned).

If I change the class from "last" to "first" in the second <li> item, then it
appears as I expect.
(In reply to comment #6)
> I cut-and-pasted the HTML from bfowler's comments.  When viewed in the 
> browser, the <li> items appear on two lines.  I expect them to appear 
> on one line.  

That is very clear. Could I ask you to do some more work on this? I am not
quite sure what is meant to happen in the case of two adjacent items where
one is specified as inline (joined) and the other as separated. Fundamentally
if things are to be joined, then there has to be two of more of them capable
of being joined. I would think that when the layout agent processes the
first item, it is ready to inline the next, but on seeing that that one
is not inline, it inserts a break.

Could you review the specs for CSS and determine what is meant to happen,
because that is the expected behaviour. There are many tutorials on using
CSS to style lists, as this is the modern way to generate menus; and I have 
admit that I would (as an author) tend to inline all items in a list, if 
I needed to have any inlined. 

> I tried it in Firefox and Opera and it did not work as I expected in either
> browser, so I'm not sure if this is the same as the original code I posted,
> which DOES work in Opera (and the other browsers I mentioned).

There are two points there, the first is that if Opera and Firefox agree
(and both are known to be standards compliant) then perhaps both are right;
the second is that it is perfectly possibly that the HTML I have been 
looking at is not the same as the HTML in question, and I fear that
the solution to that is for someone to produce a short test case that
shows the problem you are seeing. I may be wrong, but to date, nobody
else is claiming to see it.

Thank you for taking the trouble to investigate whether there is
a defect in Firefox.

So can someone attach a file demonstrating this problem to this bug using
https://bugzilla.mozilla.org/attachment.cgi?bugid=275479&action=enter ?

Ben, please don't paste large chunks of HTML into bugs -- it makes them nearly
unreadable.
Sorry. 

I haven't tried to make a reduced testcase: To work from the original
page would mean retrieving style sheets using syntax such as:

    @import url("/gallery/design/base/stylesheets/classes.css");

which doesn't seem to happen automatically. (I suspect that the list
is being styled by CSS correctly, but not as expected by the author).

I don't know why the results differ in Konqueror. Do you want a testcase
in which a list, some of whose items are inline, is rendered differently
in Gecko and Konqueror?
I'd rather see a page showing this bug as reported, minimal or not.  I can
minimize it if needed, or look for people who have time to minimize it...
It is not often that I sent mail for the attention of someone at the
Massachusetts Institute of Technology.

My comment 3 meant that I had looked at the source and thought that there was
a likelihood that Gecko was rendering correctly what was requested. This was
intended to put the ball back in the reporter's court: Can anyone other than
he see the bug.

So far as I can tell nobody else has.

In comment 7 I understand that there is some doubt as to whether the code 
that I has extracted + the styles given to me was together a true copy of 
the code with the problem. I felt that either there was no defect in 
Firefox, or the ball was back with the reporter.

I am working on the basis, that you consider that there is a possibility
that there is defect in Gecko. I can't produce the reporter's page and
his render, but if you want, I can download his files (see comment 8 about
the @url syntax requiring manual downloading), and attempt to produce
a file that renders differently in Firefox/Opera or Firefox/Konqueror.

(That still doesn't mean that there is a problem with Firefox if one
can assume that Konqueror's support for CSS is incomplete).

I can certainly do this, otherwise we will have to wait for the reporter
to upload a page.
Oh.  I didn't realize that you weren't seeing the problem on the site the
reporter sees it on.

Yeah, I agree we need more data from reporter here....
Attached file CSS file involved in misalignment (obsolete) — 
View http://www.miabrown.com in firefox and opera to see the difference in the
top 'toolbar'.	In firefox, the search box is force onto a second line.  In
opera, the login link and the search box display neatly on a single line.
That looks like a bug, yes (though the page is making all sorts of assumptions
about font sizes that could screw this up).

A testcase would be nice.... ;)
URL: http://www.miabrown.com/
Keywords: qawanted
Attached file Testcase — 

        Attachment #171962 -
        Attachment is obsolete: true

    
    

    
  


  
I see the problem in comment 15 and I enclose a possibly different test
case with comments. There are four properties set; one is necessary to
request that the <li>s are displayed on one line, and the other 3 are
all needed for this not to happen as the reporter originally wanted.

I do not know whether the behaviour in this test case is a bug, but it
is not the expected one.

    
    

    
  
Maybe this has got something to do with bug 191699?

    
    

    
  
Looks like a shrink-wrap issue.
Assignee: firefox → nobody
Status: UNCONFIRMED → NEW
Component: General → Layout: Floats
Ever confirmed: true
Keywords: qawanted
Product: Mozilla Application Suite → Core
QA Contact: general → layout.floats
Whiteboard: [reflow-refactor]
Version: unspecified → Trunk

    
  
Severity: normal → S3

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: