On 2009-06-10, at 17:53EDT, Henry Minsky wrote:
On 6/10/09, P T Withington <[email protected]> wrote:
I'm _really_ concerned about tweaking the padding without
understanding
why. In particular, you may end up clipping the text in other
browsers
where the clipping already works.
Things I would investigate:
1) Did IE change the size of its scrollbars? Is that why they are
sticking
out now? (Currently the scrollbar width is browser-specific,
because IE
_used_ to have smaller ones than the other browsers.
It didn't look like the IE scrollbars were partially clipped, it
looked
like they were not being
clipped at all. This is in contrast to the appearance in Firefox or
Safari,
where they
did not appear at all.
I was talking about "making its padding 2 pixels smaller". That seems
wrong because that padding is not browser-specific, but this is a
browser-specific bug.
Having the overflow:hidden makes sense, because the _click style is
supposed to match the non-_click.
There is another _click style in that same file that appears to also
be missing the overflow:hidden
2) Why do the scrollbars _not_ stick out the same way when you are not
moused over? There must be some additional difference between the
_click
and non-_click divs.
Yeah the mystery is that it seems like if the container click-div
didn't
have overflow=hidden set, that the native scrollbars
ought to be showing up in all browsers. So I guess the question is
not 'why
did they appear in IE?" but "why didn't they appear in Firefox/
Safari?"
I have to believe that is because the behavior of input text and click
div's is different in IE from the other browsers.
This code looks like a possibility:
if (this.quirks.fix_ie_clickable) {
this.__LZinputclickdiv = document.createElement('img');
this.__LZinputclickdiv.src = lz.embed.options.serverroot
+ LzSprite.prototype.blankimage;
} else {
this.__LZinputclickdiv = document.createElement('div');
}
Bingo! It is REALLY BAD to use HTML elements in the kernel, because
a) they do not have standard CSS attributes -- each browser can decide
to give these tags random CSS styles by default. But worse yet, in
this case, <img> is not block element, it is an inline element, which
means that it is treated as text with a baseline, descenders,
character spacing, etc.
If we _have_ to use this img hack for IE, we need to at least add
`display: block` to all the clickdiv styles (should be a no-op in all
other browsers, where the clickdiv is actually a div). This will make
the img element be laid out as a block element, which should make it
behave.
If that doesn't solve it, you'll have to dig deeper to see if there
are other random styles implied by the img tag in IE (e.g., if it has
default padding or something) and you'll have to override that. If
that is the case, you'll need to conditionalize those changes on the
quirk.
