element not positioning correctly in chrome

Forum Moderators: not2easy

Message Too Old, No Replies

element not positioning correctly in chrome

Skier88

12:26 am on Oct 26, 2011 (gmt 0)

I think this bug (as I assume it is) is strange enough to warrant the half hour I just spent hitting my head against the wall. Refer to this example:

<!doctype html>
<html lang='en'>
  <head>
    <meta charset='utf-8'>
    <title>position test</title>
    <style type='text/css'>
      #right {float:right;}
    </style>
  </head>
  <body>
    left text
    <div id='right'>right text</div>
  </body>
</html>

It displays the same in every browser I've tested: all the text is on the first line, and "right text" is on the right.

Now, delete the style element and insert a link to a stylesheet containing the exact text of that style element. In every browser but chrome this makes no difference, but in chrome the text on the right is now shifted down a line.

Is anybody else seeing this or is my computer broken in the most improbable way? Any thoughts on fixing it without changing #right to a span or equivalent?

lucy24

3:13 am on Oct 26, 2011 (gmt 0)

Immediate reaction before even trying it: anything coded as a float needs to go before the stuff it's floating next to. Otherwise it may be too late to float it. (Notably this happens in Camino even with internal styles.)

Yes, I do get the same weird phenomenon in Chrome. fwiw, this is not the first time I have seen Chrome behaving oddly w/r/t floats, again even with internal styles.

Note also that if I put the "left text" into a paragraph-- as you'd normally expect it to be-- the float starts on the next line in all browsers. This strongly implies that the aberrant behavior in Chrome is not a property of the float but of the preceding non-floated text.

Conversely, if I put the floating part before the non-floating part, it behaves as desired even in Chrome with external stylesheet.

Paul_o_b

10:26 am on Oct 26, 2011 (gmt 0)

Hi,

That's strange I'm not seeing that effect in either chrome 14 or 15 on PC or MAC.

I should note that IE7 and under will also show the words on two lines because they don't obey the specs for this element correctly.

To clarify the specs a floated element will float as far to the left or to the right as it can and will displace any "inline content on the same line" so that the float starts at the far left or far right. The important part to note is that only inline content on the same line as the float will be displaced to make room for the float. If the preceding element was a block element then the float will start on a new line as usual. IE7 and under however will always start a float on a new line so its best to always make sure that your floats come first in the html.

The structure you are using is not semantically correct (although it will validate) because you have anonymous text just hanging in mid air which needs to be in the appropriate block container (most likely a p element). The browsers will look at the stray text and construct an "anonymous block box" around the element just because you didn't. :)

I would guess that its the fact that the browser needs to do this extra work that is causing you problems in chrome and indeed ie6 and 7 will throw various bugs when they see inline elements running head onto block elements like that as they always need structure to work properly.

However having said all that I can't actually reproduce the issue so I wonder if its a version thing or I'm just lucky.

Skier88

5:15 pm on Oct 27, 2011 (gmt 0)

Thanks for the replies. First off, "left text" is currently inline - it makes no difference to this example if it's wrapped in an inline element. So, "left text" IS "inline content on the same line" as the floated element, so it should be displaced. Putting it in a <p> produces the behavior I would expect. I also understand that this can be fixed by putting the float first, but I would prefer to keep the left content higher on the page as on my actual website the "left text" is the <h1> which I feel should logically come first. Speaking of my actual page, it's now displaying fine thanks to changing #right to a span, but I'd still like to know if this is actually a bug or simply the browser's guesswork with invalid html.

I'm not sure what you mean by "needs to go before..." and "may be too late" - are you saying the current syntax is invalid, or just that some content doesn't clear a float?

Lucy, your observation that this seems to be an effect of "left text" seems reasonable, yet further testing has produced some inconsistencies. Take the example with the styling in an external stylesheet. If you wrap "left text" in an inline or inline-block element nothing changes. It is also unchanged if the "right text" div is styled to display inline. But if #right is changed to a span, which should be equivalent to applying "display:inline;" to the div, it works as it does in other browsers (stays on the same line). Furthermore, using this externally styled example, it displays correctly when navigating to the page using the back button, but not when loading the page fresh, reloading, or using the forward button (all in chrome of course).

Paul, did you try refreshing the page after you loaded it? That always got it to break for me. And I don't think it's a version thing as my chrome is up to date. However, I'm running XP and I think Lucy's on a Mac, so it could be an OS thing. Also, could you elaborate on what you said about semantic correctness? I try to comply to the standards, but I don't know of a spec that says not to do this. And what exactly is the rule? The body is a block element so your previous definition is not thorough - do you mean a text node's first block or floated ancestor should never contain block or floated elements?

Fotiman

5:30 pm on Oct 27, 2011 (gmt 0)

I don't see the behavior you describe, using Chrome 15 on Windows XP. For me, both display with the floated text on the same line as the inline text.

Fotiman

5:32 pm on Oct 27, 2011 (gmt 0)

I would suggest inspecting the element to see what styles and computed styles are being applied.

Skier88

5:34 pm on Oct 27, 2011 (gmt 0)

Thanks for the suggestion, but I already tried that and it's not an issue of styles being overridden. I actually spent my first 10 minutes of debugging sure this was the case...

So much for the OS theory. Now I have no idea what the criteria are, but we do know it's not just me.

Fotiman

6:35 pm on Oct 27, 2011 (gmt 0)

I wasn't suggesting necessarily that the styles were being overridden. I was wondering more about what the computed styles were. When I do this myself, I get the following computed styles:

display: block;
float: right;
height: 20px;
width: 52px;

I'm just curious if you see any values that are different one way or the other. If the results were the same for you either way, I wonder what that would mean?

I'd then start looking at the Properties to see if any of the offset values were different, just to see if there were any clues there.

Paul_o_b

10:08 pm on Oct 27, 2011 (gmt 0)

Also, could you elaborate on what you said about semantic correctness? I try to comply to the standards, but I don't know of a spec that says not to do this. And what exactly is the rule? The body is a block element so your previous definition is not thorough

Your code as it stands is invalid as an inline element cannot be a direct child of the body (run it through the validator and you will see). Even if you add a span around the left text it will still be invalid.

It is not invalid (as I mentioned above) to have inline elements running into block elements but it is not really semantically correct and will cause issues in IE7 and sometimes other browsers also.


<div>
 <span> This is some text</span>
 <p> But now I am in a block element</p>
</div>

The above is nonsense because a span identifies a section of inline content and not a whole section. The above should be two paragraphs.

The browser will see the inline span runs into the block element and will therefore construct an anonymous block box around the span to keep it all correct.

It's just a pet hate of mine and the fact that I've seen it cause so many errors in older browsers that its something I advise against doing. It's not invalid but in semantic terms it's just not nice.

Regarding the behaviour of floats then its as I summarised above and even if the left text is in an inline element the rule is still the same.

Changing the right div to a span "should" have made no difference because floats produce a block display and inline or block rules have no effect on them (apart from using display:inline to cure the old IE6 double margin bug. If changing the "right text" float to a span fixes it for you then it seems to support my block element running into an inline element "pet hate" that I started with :)

Notwithstanding any of that the behaviour you are getting in chrome is definitely a bug and I did manage to get chrome to display incorrectly but only the first time I loaded.

Skier88

10:41 pm on Oct 29, 2011 (gmt 0)

Fotiman, I checked out the computed styles and I'm getting the same as you for both versions. The offsets (left, top, width, height) are the same for both versions except for top, which increases when the element moves down (as expected). It's all as expected, so no clues there, as far as I can see.

Thanks for the clarification Paul. You seem to be using valid in two different ways, so I just want to say, I did run it through a validator, and it's valid. But I understand why it's bad practice now, thanks. I do have one follow-up question: is it still a bad idea if the wrapper for "left text" is an inline-block?

Paul_o_b

9:09 am on Oct 30, 2011 (gmt 0)

so I just want to say, I did run it through a validator, and it's valid.

It may show valid when using the html5 doctype option in the validator but that is an experimental and unreliable mechanism at the moment.

If you add any other strict doctype and validate it will show as invalid. (It may be that html5 is again bending the rules and the reason that so many old timers dislike it intensely. Indeed the allowance of anchors to be wrapped around block elements is causing no end of bugs.)

I do have one follow-up question: is it still a bad idea if the wrapper for "left text" is an inline-block?

As far as htmnl goes then it matters not a jot what CSS styles you apply to the element.:) The rules of html have no bearing on css and vice versa.

A document is marked up semantically using html. Then it is styled with CSS. There is no conflict although sometimes due to the limitations of CSS you have to massage the html a little to get the desired outcome but never by creating invalid or non-semantic html.

CSS doesn't care what an element looks like or what it does (in most cases) as it can simply style it to suit.

Back to your question then it makes no difference to the html rules what the "display" of the "left text".

There is always confusion between an element that is set to display a "block box" and an element that is a "block element". A block element can be set to display:inline but that doesn't make it an inline element. It still exists as a block element in html but its display is now inline.

They are different concepts - css can't change the rules of html it can only change how things look :)

As an aside I use inline-block a lot these days as it avoids the snagging problem of floats and allows you to center elements very easily also. (If IE6 and 7 support is required for inline-block then you need a little hack for them as they don't understand it when applied to block elements. However if you turn the block element to have an inline display and then apply haslayout with zoom:1.0 then they will work also.(Those rules must be fed to only ie6/7 though))

Fotiman

2:07 pm on Oct 31, 2011 (gmt 0)

The offsets (left, top, width, height) are the same for both versions except for top, which increases when the element moves down (as expected).

In that case, I would start inspecting every element leading up to the one with the increased offset to see if you can find which element is causing the offset to be different. Look at margins, padding, width, height, borders, offsets... anything that affects the box position.

Unfortunately, I can't reproduce it, so not a whole lot I can do to help other than to offer suggestions. :-/

Skier88

1:31 am on Nov 1, 2011 (gmt 0)

Ok, thanks for elaborating Paul. I've heard the litany of separate content and presentation, but between your answers and checking my html5 pages as xhtml I've come to realize I still had a basic misconception about html. I had been viewing it as a toolkit with a few requirements, but it is really a structured, albeit very flexible, document. I also realized my solution on my actual page is invalid xhtml, as you can't have a span around a form (already fixed it, just saying how much this helped).

When I asked about "left text" being inline-block, I was asking more about the property than css. For example, what if it was a text-type input element with no styling? But I think you answered this as well - it's not even the default styling that matters, but whether the tag is in a list of allowable top-level tags (and, as per the w3 validator, <input> is not).

Fotiman, thanks for your input, but as of today I can't test it either. The bug was gone when I turned on my computer this morning; I can't get it back, and I can't figure out what's different. It's not the first time I rebooted since posting either. I do not envy the chrome developer who has to chase this one down.

lucy24

3:06 am on Nov 1, 2011 (gmt 0)

The bug was gone when I turned on my computer this morning; I can't get it back, and I can't figure out what's different.

Isn't that infuriating? :) Of course you're glad the bug is gone-- but you'd be so much happier if you could see the corpse and be certain it hadn't simply gone on vacation or moved to a different part of your html.

Paul_o_b

6:12 pm on Nov 1, 2011 (gmt 0)

but you'd be so much happier if you could see the corpse

lol - that's a good way of putting it - although slightly morbid :) Yes the worst bugs are the occasional ones that run and hide until you are not looking anymore.

Skier88

9:29 pm on Nov 1, 2011 (gmt 0)

Haha, yes, I think I would have preferred a corpse. Although I'm lucky enough to have an excuse not to worry about it - if I see this bug I know there's a better solution that doesn't require I address this issue. I use the same trick to avoid learning flash :)