Opera bug?

Hello all,

I recently did a demo header for someone and saw something weird in Opera. Only Opera, both 11 and an old copy of 9.6.

http://stommepoes.nl/opera.html

http://stommepoes.nl/operabug.png <–Opera (the mouse was a hand, just doesn’t while screenshotting
http://stommepoes.nl/operabugFirefox.png <–same page, on Firefox 3

The code (remember this was from a quick throw):


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <meta http-equiv="content-language" content="en" />
    <title>Opera</title>
    <meta name="description" content="wut?" />
    <style type="text/css">
* {
  margin: 0;
}

html, ul {
  padding: 0;
}

img {
  vertical-align: bottom;
  border: 0;
}

body {
  padding: 130px 0 0;
  font: 100% georgia, "urw bookman l", serif;
  background-color: #c0ffee;
}

#container {
  width: 1150px;
  margin: 0 auto;
  padding: 20px 0;
  background-color: #decaff;
}

#header {
  width: 100%; /*Haslayout*/
  margin-bottom: 1em;
  outline: 1px solid #000;
  background-color: #615096;
}
        #header:after {
          content: " ";
          display: block;
          clear: both;
          height: 0;
        }

        #sitename {
          float: left;
          width: 220px;
          height: 58px;
          margin-bottom: 8px;
          border: 1px solid #000;
        }
                #sitename a {
                  /* display: block; remove this line, critical*/
                  font-size: 46px;
                  border: 1px solid #f00;
                }

        #header a {
          color: #fff;
          font-weight: bold;
          text-decoration: none;
        }
                #header a:focus,
                #header a:hover,
                #header a:active {
                  color: #ffd55a;
                  text-decoration: underline;
                }
    </style>
  </head>
<body>
  <div id="container">
    <div id="header">
      <p id="sitename"><a href="home"><img src="logo.png" width="220" height="58" alt="Yoursell!" /></a></p>
    </div>
  </div>
</body>
</html>

On the left in the #header is a floated <p> holding an inline <a> holding an image. Whether the image is there or not, the <a> sticks up out of the <p> and the #header unless I make it some kind of block.

I have no idea why.

When I first made the original mockup, there were 4 headers, each with an outline, and that’s where I saw Opera being strange. No other browser did this. The floated anchor-holding-image on the right does not affect things (this still fails when the ul is removed, as I did above).

Any ideas?

Hi Stomme,

Just bord drinking coffee - stuck on iPhone so can’t test. What if you just remove the p and float the anchor instead and give it all the goodies? Fix it? I wouldn’t wrap it in a p anyways - there is no paragraph there right? But both screen shots seem to be in the same position. Could be just the outline that is off.

Hi Poes,

It looks like Operas problem is related to that 46px font-size on the <a> along with the default vertical-align:baseline

If you set it to vertical-align:bottom it renders the same in FF and Opera


                #sitename a {
                  /* display: block; remove this line, critical*/
                  font-size: 46px;
                  border: 1px solid #f00;
                  [COLOR=Blue]vertical-align:bottom;[/COLOR]
                }

The P is only there to avoid the whole “blocks and inlines as siblings” though I agree that it’s not a paragraph. I have been using P’s for logos though is why I chose that one. Maybe a div is better. (it’s not in my code but the actual header I redid has a ul also as a child).

What if you just… float the anchor…?

That sets it in block context (just like display: block or display: inline-block), which is the fix for Opera. My question though is why does Opera let the anchor out of both its container (the p) AND the surrounding container (#header) when it’s left inline? I can’t see what could be pushing it up.

Could be just the outline that is off.

Actually, in Opera (tho the screenshot doesn’t show it), the area above the #header box is clickable. So, if my mouse wasn’t set back during the taking of screenshots, that mouse would be a little hand.

In all other browsers you cannot click above the #header to reach the link inside the p.

Hi Ray, you ninja’d in there! Aha, thank you for solving the mystery. My new question is, then, would this be considered a bug? In that, no other browsers let the anchor bleed out no matter what font-size (or line height… I set no line-heights but I assume Opera is making one for me based on that font-size) is set on it?

My new question is, then, would this be considered a bug?
I’ve learned not to jump the gun and start labeling things as bugs too soon but some quick testing shows something else that is interesting.

If you add another sibling inline element beside the anchor the problem goes away without needing to set v-align.


#sitename {
  float: left;
  [COLOR=Blue]width: 440px;[/COLOR]/*220px*/
  height: 58px;
  margin-bottom: 8px;
  border: 1px solid #000;
}
#sitename a {
  /* display: block; remove this line, critical*/
  font-size: 46px;
  border: 1px solid #f00;
  background:lime;
}
[COLOR=Blue]#sitename span[/COLOR] {
  font-size: 46px;
  border: 1px solid #f00;
  background:red;
}

      <p id="sitename">
        <a href="home"><img src="logoo.png" width="220" height="58" alt="Yoursell!" /></a>
        [COLOR=Blue]<span>Test Text</span>[/COLOR]
      </p>

… I set no line-heights but I assume Opera is making one for me based on that font-size
I’ve seen Opera being buggy with line-heights before. One case in particular (I’d have to find that thread) it mysteriously adds 1px when all other browsers don’t.

EDIT:
Here’s that thread where there was no known solution for the Opera line-height bug

Oh sorry I was just focussed on fixing it. I understand you wanting to understand what was going on with opera. :slight_smile: What’s wrong with block and inline as siblings? Seen that mentioned a couple times but have never seen a prob with it?

bizarre opera is bizarre, lawlz.

Eric: Yeah, I found several ways to fix it (tho I’d missed adding another inline sibling, weeeeird!), just wondered why Opera was totally the only one doing this (if IE had also done it I would have been less curious as Opera and IE often do some things similarly… like positioning legends).

It’s technically legal. There are two reasons people are against it:

  1. IE’s duplicate content bug and some vertical spacing bugs appear if the inline renders inline and the block renders block (meaning, you don’t get any IE bugs if you set the inline to block context like display: block or floating it). For me, this is a minor issue simply because changing the context in CSS magically fixes it, every time. And I’ve not seen issue in anyone else… and I don’t believe IE8 and above have this issue.

  2. There is a feeling among many developers that something like this
    <div>
    some loose text, man
    <span>some inline text</span>
    some more loose text man
    <p>some text in a block</p>
    </div>

is sloppy structuring. What browsers will do is create anonymous inline boxes around the loose text, similar but apparently not exactly the way it creates a known (span) inline box around the span and a known block box around the p (who is filled with anonymous inline boxes, one for each word). And so if we don’t like
<div>
it’s the corporations man
<p>some block text</p>
</div>

then that’s not so different from
<div>
<span>Spans man, how do they work?</span>
<p>some block text</p>
</div>

which then somehow leads to the idea (and that’s all it really is if you’ve taken care of IE’s rendering bugs) that a group of siblings should really all be either inlines or blocks (not sure about inline-blocks, I think they’d be ok with the blocks) for structural reasons.

I’m always on the fence about this: for dropdown menus I’ve continued having inline and block siblings:
<ul>
<li>
<a href=“#”>inline sibling</a>
<ul><–block sibling

</ul>
</li>

</ul>

Though I’ve also gotten the IE vertical-spacing bug with that (fixed by setting the anchor to display: block which of course triggered a nice set of other bugs in IE6). But just once, and there was weird stuff going on in the code.

But lately I have been trying to find things to wrap around short anchors and images… usually these end up being p’s because I’m also on the fence of “what’s a paragraph in HTML?” where some people stick to literary/typographic paragraphs (at least one full sentence) and others stick to dictionary definitions (which include sentence fragments).

I do usually wrap something around logos, possibly because in the past I always had header tags there. Now that I don’t consider logos (site names) to be headers except on the main/first page of a web site, I wanted to switch to another block. And div felt less “right” than p since p still suggests to me “I’m wrapping specifically around some text” (I use Gilder-Levin so there’s always plain text in the logo… NOT like I had in the Opera bug example above, that was for someone else).

So long story short, I dunno what exactly is “wrong” with mixing the two; it’s technically completely legal and seems to be mostly people’s feelings on style.

Now that anchors can wrap blocks in HTML5, this is totally getting weird.

Not sure I follow exactly what the bug is, but I’d be delighted if you could make a smaller testcase and file a bug at https://bugs.opera.com/wizarddesktop/ :slight_smile:

Not sure I follow exactly what the bug is, but I’d be delighted if you could make a smaller testcase…
Hi Simon,

I have put together a reduced test case and I am willing to label this as a Confirmed Bug now.

I no longer file bug reports with Opera as we never know what becomes of them. Here’s one I filed over a year ago and it never was fixed anyway. In fact the new version of Opera breaks the CSS fix that worked at the time.

Your more than welcome to take my test case of the New Bug and file it yourself. You may have more influence on it actually getting fixed that way.

Opera: IMG vertical-align:bottom BUG

My conclusion of this bug is:

Opera is either ignoring vertical-align:bottom when it is applied to an IMAGE or it is failing to align anonymous sibling inline boxes to the bottom of the image.

This is only happening with vertical-align:bottom applied to an IMG.

I can verify this exists as far back as 9.27 but I don’t have anything older.

I would suspect the REAL culprit is setting that font-size without – say it with me people – setting a line-height. What have I said time and time again?

When you change your font-size, set the line-height at the same time; which is why I ALWAYS use the full declaration and redeclare the face too.

I’ll play with that when I’m at my workstation… of course you know what else I’m going to say, right SP? That’s not a paragraph, that’s a presentational image so it has no business in the markup, and what purpose does that #header div serve other than bloat? :smiley:

Digging deeper – you’re mixing a margin-bottom on the #siteName with a negative top margin on the menu… That’s also a likely culprit. Another issue is you are leaving the IMG tags in their default ‘special’ display state, when you would be better off setting them to block…

… again NOT that I’d have those images in the markup in the first place.

I’m also questioning the placement of .cart in the markup – I’m not sure I’d make that part of the main menu since usually you would also want to show extra info like how many items are in the cart and total price – which is probably why I’d not be using an IMG for that in the first place no matter how much the PSD jockey likes it… and place it in it’s own div or list.

Also, what’s with that min-width? Makes them not space evenly and looks like ass… shouldn’t that be padding’s job?

… and is that header:after supposed to be doing something useful? (doubtful!)

– edit –

Yup, it was the lack of line-heights, which is why it was even MORE screwed up on my large font/120dpi system.

Move the font-size out of #siteName a and into #sitename, and add line-height:58px, and that fixes it.

Though I’d probably be writing that something more like this:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html
	xmlns="http://www.w3.org/1999/xhtml"
	lang="en"
	xml:lang="en"
><head>

<meta
	http-equiv="Content-Type"
	content="text/html; charset=utf-8"
/>

<meta
	http-equiv="Content-Language"
	content="en"
/>

<link
	type="text/css"
	rel="stylesheet"
	href="screen.css"
	media="screen,projection,tv"
/>

<title>
	Opera Layout Test
</title>

</head><body>

<div id="pageWrapper">

	<h1>
		<a href="\\">
			YOURSELL!
			<span></span>
		</a>
	</h1>

	<div id="topCart">
		Your Cart:<span></span><br />
		<a href="#">
			3 items<br />
			$89.50
		</a>
	</div>

	<ul id="mainMenu">
		<li><a href="#">Home</a></li>
		<li><a href="#">Products</a></li>
		<li><a href="#">Help</a></li>
		<li><a href="#">Contact</a></li>
	</ul>

<!-- #pageWrapper --></div>

</body></html>


/* null margins and padding to give good cross-browser baseline */
html,body,address,blockquote,div,
form,fieldset,caption,
h1,h2,h3,h4,h5,h6,
hr,ul,li,ol,ul,
table,tr,td,th,p,img {
	margin:0;
	padding:0;
}

img,fieldset {
	border:none;
}

body {
  padding-top:130px;
  font:normal 100%/140% georgia,"urw bookman l",serif;
  background:#C0FFEE;
}

#pageWrapper {
  width:1150px;
  margin:0 auto;
  padding:20px 0;
  background:#DECAFF;
}

h1 {
	position:relative;
	height:1%; /* holly hack, trip haslayout */
	font:normal 32px/34px georgia,"urw bookman l",serif;
  background:#615096;
  border:solid #F00;
  border-width:1px 1px 0;
}

h1 a {
	display:block;
	padding:12px 8px;
	text-decoration:none;
	color:#FFF;
}

h1 span {
	position:absolute;
	top:0;
	left:0;
	width:220px;
	height:58px;
	background:url(images/h1Logo.png) 0 0 no-repeat;
}

#topCart {
	position:relative;
	float:right;
	display:inline;
	height:58px;
	margin:-58px 1px 0 0;
	text-align:center;
	font:normal 16px/20px georgia,"urw bookman l",serif;
}

#topCart a {
	position:relative; /* make sure it depth sorts over h1 */
	display:block;
	width:124px;
	padding-top:18px;
	color:#FFF;
}

#topCart span {
	position:absolute;
	top:0;
	left:0;
	width:124px;
	height:39px;
	background:url(images/yourCart.png) 0 0 no-repeat;
}

#mainMenu {
	list-style:none;
	overflow:hidden;
	height:1.9em;
	padding-left:112px;
  background:#615096;
  border:solid #F00;
  border-width:0 1px 1px;
}

#mainMenu li {
	display:inline;
}

#mainMenu a {
	float:left;
	padding:0.25em 8px;
	text-decoration:none;
	font-weight:bold;
	color:#FFF;
}

#mainMenu a:active,
#mainMenu a:focus,
#mainMenu a:hover {
	text-decoration:underline;
	color:#FFD55A;
}

Just a little different. If I was doing that, I might even consider changing “your cart” into a H2. :stuck_out_tongue:

In any case, NEVER trust the default or inherited line-height! You change the font-size, change the line-height, you’ll have a lot less headaches.

of course you know what else I’m going to say, right SP? That’s not a paragraph, that’s a presentational image so it has no business in the markup, and what purpose does that #header div serve other than bloat?

Yeah yeah… my explanation and Democratic waffling is above.
#header as an easy way to show the guy I was demo-ing how to avoid 100 sliced images by throwing the main bg image on a header wrapper (called #header). See link below, but if you do a rewrite for him, you’ll spend a lot of time redoing the images.

Digging deeper – you’re mixing a margin-bottom on the #siteName with a negative top margin on the menu… That’s also a likely culprit.

Nah, I removed that to see if it was. It wasn’t.

Another issue is you are leaving the IMG tags in their default ‘special’ display state, when you would be better off setting them to block…

Maybe.
Reason I don’t most of the time is, I don’t want them to be blocks with set dimensions if images don’t load. I want alt text to take as much room as it needs. Yeah, doesn’t work in many browsers but the one who sets them back to “special default inline” this is a bonus… it’s the one browser I can actually surf with images off and enlarged text in.

… again NOT that I’d have those images in the markup in the first place.

If I were really building this page myself and had access to the background image, I would have used plain text positioned with margins and then some goofy text-shadow to imitate what the current site has (text shadow isn’t necessary and IE users would likely be very happy to avoid seeing it anyway). You can see that in my version #3 on the thread that started it all. (they all fail text-enlarge)

I’m also questioning the placement of .cart in the markup – I’m not sure I’d make that part of the main menu since usually you would also want to show extra info like how many items are in the cart and total price – which is probably why I’d not be using an IMG for that in the first place no matter how much the PSD jockey likes it… and place it in it’s own div or list.

The guy had a sliced table page… I did not know if “Your Cart” was just one part of some larger menu that maybe appears if you’re logged in? Was “You Cart” always available for users (which at worse would just tell new users “0 item” I assume).
Since I couldn’t open the guy’s 77.7MB PSD (crashed the GIMP and gave Gnome hiccups) I thought I could make 4 different examples of how he could do a NON-sliced header… but I didn’t have the images and thought for now he’d be better off using images+alt text than jumping into Gilder-Levin or anything similar at this point.

Also, what’s with that min-width? Makes them not space evenly and looks like ass… shouldn’t that be padding’s job?

If you add padding to either the anchors or the images, then you get (unwanted) spacing between the anchors. The min-width was a kludge to keep words from doing
HomeProductsContactHelp
when images were off. Even though the anchors were blocks, they had no margins or spacing on them. The guy who made the images had the “spacing” built into the images. For his demo I wasn’t going to re-do his images.

… and is that header:after supposed to be doing something useful? (doubtful!)

I think it was to wrap floats without hiding overflow (since what Opera seemed to be doing looked like overflow).

Though I’d probably be writing that something more like this:

Wait. Before doing a redo of this stripped-down version of an attempt to fix someone’s sliced images, you should go here first.

What I ended up doing was taking a screen shot of how the linked page looked that day and trying to make an example of that. The images are less than optimal though (understatement lawlz), and I don’t know the true relationship between the menu items (does Your Cart belong to another menu, or is it always on it’s own? Does it only appear if you’re logged in or added something to cart??) and figured, since I don’t know, make it one menu item (since to me, on a shopping system, my cart is Yet Another Navigation Item).

Just a little different. If I was doing that, I might even consider changing “your cart” into a H2. :stuck_out_tongue:

Assuming it really is just one item by itself and never part of a larger list, you would really do that? A div?

I’ve been wavering on divs for “some random inline has to be alone by itself somewhere but should try not to be a sibling to a block” situations. I’ve been taking Gary Turner’s position as far as “paragraphs” for wrapping even sentence fragments like Name Of Web Site (logo), but it (a <p>) never feels right for one-off anchors and stuff.

Here is what the specs say about a replaced elements height setting the height of the line box.

10.8.1 Leading and half-leading

On an inline-level element, ‘line-height’ specifies the height that is used in the [COLOR=Red]calculation of the line box height[/COLOR] [B](except for inline [URL=“http://www.w3.org/TR/CSS2/conform.html#replaced-element”]replaced elements, where the height of the box is given by the [URL=“http://www.w3.org/TR/CSS2/visudet.html#propdef-height”]‘height’ property). [/B]

Now let’s set Mallory’s code aside for a moment and look at the way Opera is handling vertical-align:top/bottom; on a replaced element within the line box. That was really the root of the problem that started this thread.

Just a simple img found in the string of a line box -

<p>This is an IMG [COLOR=Blue]<img src="sample.jpg" width="180" height="60" alt="Test">[/COLOR] in a line box.</p>

When vertical-align:bottom is set on that img Opera is the only browser that does not give us the expected results.

Digging a little deeper into the specs, I’m now thinking that this really can’t be called a bug in Opera. Though I don’t consider Opera’s behavior very to be intuitive.

I think this is where the specs let Opera get away with this

10.8 Line height calculations: the ‘line-height’ and ‘vertical-align’ properties

As described in the section on inline formatting contexts, user agents flow inline-level boxes into a vertical stack of [URL=“http://www.w3.org/TR/CSS2/visuren.html#line-box”]line boxes. The height of a line box is determined as follows:

  1. The height of each inline-level box in the line box is calculated (see “Calculating heights and margins” and the [URL=“http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height”]‘line-height’ property).
  2. The inline-level boxes are aligned vertically according to their ‘vertical-align’ property.[B] In case they are aligned [COLOR=Red]‘top’ or ‘bottom’[/COLOR][/B][COLOR=Red], [/COLOR]they must be aligned so as to minimize the line box height. [B]If such boxes are tall enough, there are multiple solutions and [COLOR=Red]CSS 2.1 does not define[/COLOR] [COLOR=Red]the position of the line box’s baseline[/COLOR][/B](i.e., the position of the [URL=“http://www.w3.org/TR/CSS2/visudet.html#strut”]strut, see below).
  3. The line box height is the distance between the uppermost box top and the lowermost box bottom. (This includes the strut, as explained under [URL=“http://www.w3.org/TR/CSS2/visudet.html#propdef-line-height”]‘line-height’ below.)

Now when we look at the vertical-align values we see that top & bottom does not follow the same rules as all the other values.

W3C Vertical-Align

The following values only have meaning with respect to a parent inline element, or to the strut of a parent block container element.

  • baseline
  • middle
  • sub
  • super
  • text-top
  • text-bottom
  • <percentage>
  • <length>

Now when using top/bottom the rules are different

The following values align the element relative to the line box

  • top
  • bottom

Now if we look back up to #2 in the list we are reminded that "CSS 2.1 does not define the position of the line box’s baseline."

As I said, I think that is where Opera is allowed to do as it pleases but to me it does not make any sense.

The only way I see to get Opera to give us the expected results is to nest ALL inline boxes within a parent inline element and set vertical-align:bottom on that parent (that’s why setting v-a:bottom on the anchor in SP’s code worked as I did in post#3) as shown in this example -

Opera’s Line Box Formatting with v-a:top/bottom

Of course we could use vertical-align:baseline when running an IMG in a string of text and that would solve the problem. I was wanting to dig into what Opera was doing with top/bottom though, as pointed out above those values follow a different set of rules and that changes everything with Opera.

While this Opera vertical-align subject is still fresh on my mind I will also point out that there ARE three other confirmed vertical-align bugs

#22-24 in this list :
Bugs in Opera 11 for Windows

Looking back to when that “Content First Quiz” was running I remember running into these Opera vertical-align quirks. I had to use text-bottom to make it work in Opera. At the time I didn’t know what was going on with how Opera treats bottom.

CSS Quiz #36 - Rayzur

Now after looking through Gerald’s opera bug list I see why text-bottom worked in Opera.

vertical-align: text-bottom is incorrectly rendered in Opera 10.0

Opera renders text-bottom in the same manner that other browsers render bottom.
I didn’t know it at the time, but I was working off a bug in Opera.

Well, that’s a problem with the HTML specs in general – they allow so many things to the discretion of the browser maker that developers are lucky ANYTHING works cross browser; just look at how a simple element like INPUT is handled for proof of that.

Line-height is DEFINITELY another of these cases… the specification doesn’t even STATE a default you have to use, it just “suggests” 110 to 130%. The flow box for an inline element on a line is then some random amount between those two points – and opera treats inline-level elements as CDATA for figuring % or metricless line-heights. This is then forcing the element to grow in height which is why the alignment within that height is all wonky… and why I consider the problem to NOT be a bug in Opera, but a faulty technique for building a site element.

Which again, is simply avoided by stating the line-height properly or not using an IMG tag on a non-presentational image.

I’m going to post my approach to what the OP was trying to do in the original thread – and no SP, I probably WON’T have to slice up images a whole lot to accomplish the layout; since I’m going to work from a screencap of your #4, and use ONE IMAGE for the ENTIRE layout.

Had I seen the original first, I would have taken a bit different an approach on it.

If by that you mean the outdated retard Nyetscape style “text-zoom only” that is no longer even the default in FF, show me a page that doesn’t look like ass and/or broken using that idiocy?

If by that you mean the system metric enlarge, that’s what PX is for on fonts; hiding under images. (the only time I consider px for fonts a valid choice – image interaction)

Though only #4 even comes close to looking acceptable to me – though it falls way short of what the OP wanted.

If by that you mean the outdated retard Nyetscape style “text-zoom only” that is no longer even the default in FF, show me a page that doesn’t look like ass and/or broken using that idiocy?

I test all my pages with that idiocy: lots of us HATE ZOOM WITH A PASSION. See all the whinging on the Chrome help forums asking why they removed text-enlarge. Zoom sucks balls.

If by that you mean the system metric enlarge, that’s what PX is for on fonts; hiding under images. (the only time I consider px for fonts a valid choice – image interaction)

Meaning if I need that text bigger, I’m stuffed. His image text is freakin tiny.

Though only #4 even comes close to looking acceptable to me – though it falls way short of what the OP wanted.

It looks like his site, except the borders are gone… I dunno if he really wanted borders or not. #3 still shows all the image text underneath the image, because I didn’t feel like stripping that text. You can see on his page (where I copied his image) the YourSell text isn’t even truly aligned with the background (you can see someone did a sloppy paste job) and everything’s off wherever the borders came in.

#1 and #2 are only to show two steps: markup and background colour, then after adding a background to #header. Which would work better if it was a background without all the text in the image.

I’ve never understood that attitude about it – ZOOM is more useful and doesn’t break just about EVERY page you try to use it on.

I mean, which one is better?
Firefox, older version from years ago:
http://battletech.hopto.org/images/firefux/FF_Zoom.jpg

Or this?
http://battletech.hopto.org/images/firefux/Opera_Zoom.jpg

I tend to go with the latter as the more useful “zoom”. This is particularly true of all the garbage fixed width websites out there, where FF doesn’t even expand the container around the text…

As someone who NEEDS to zoom in on about 60% of the sites out there thanks to the px-tards, resizing just the text is effectively USELESS when you end up with an illegible five words per line and text busting out of containers.

Which is why that shouldn’t be declared in PX… or an absurdly undersized train wreck PX at that.

[ot]

I’ve never understood that attitude about it – ZOOM is more useful and doesn’t break just about EVERY page you try to use it on.

What I have now with text-enlarge is, I get larger text without needing to scroll horizontally to read each line, and I don’t get giant useless blurry images.

With zoom I always get a scrollbar (which is only ok if I can still read one column without scrolling) and retardation in images.

Usually, I’m enlarging text to… enlarge text. Not to make the whole page bigger. [/ot]

[ot]

Which is why that shouldn’t be declared in PX… or an absurdly undersized train wreck PX at that.

But didn’t you just say

If by that you mean the system metric enlarge, that’s what PX is for on fonts; hiding under images. (the only time I consider px for fonts a valid choice – image interaction)

?? I thought you meant if you’re hiding text under G-L images then they should be in px so they don’t peek out… which could be valid except if I need that text bigger I need it to peek out and then I use my handy 'tard-friendly toolbar to block all images (way easier than the 15 clicks through FF preferences). I don’t do that often, but I do it often enough. And since FF does ignore px (tho I agree with you I think IE’s idea is better) then I can enlarge that text whether they set the font to 9px or not.[/ot]