At the sprite level, what is supposed to happen is that if you ask for
scrollevents, the sprite div is set to _always_ have scrollbars, and
made big enough to hide the scrollbars under the corresponding clip
div. You have to do this, or the browser will not report scroll events.
The code you are looking at seems to be involved with whether the LZX
scrollbars are visible or not. It seems to me that what you are
seeing is an artifact -- the LZX scrollbars, when visible, are
probably just hiding the native scrollbar.
If you have a small test case, I can try to look at it. But, maybe
the best thing is to try to measure the pixel width of an IE native
scrollbar. I really think that may be the whole problem, that the
quirk for that dimension is wrong. Look at the quirk for
scrollbar_width.
On 2009-06-11, at 17:14EDT, Henry Minsky wrote:
OK, here's where I'm having some trouble. The issue with the native IE
scrollbars showing up only happens when the scrollbar in
scrolledittext is
initially set to non-visible.
I'm looking at scrolledittext, and there is this init method
<method name="init">
super.init();
this.ensurevscrollbar();
setvscrollwidthfromvisibility(this['_vs'] ?
this._vs.visible :
false);
this.myDel = new lz.Delegate(this,
"setvscrollwidthfromvisibility", this['_vs'], "onvisible");
</method>
Does this setvscrollwidthfromvisibility have something to do with
whether
the
sprite's div is set to mask the native scrollbars?
On Wed, Jun 10, 2009 at 6:11 PM, P T Withington
<[email protected]>wrote:
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.
--
Henry Minsky
Software Architect
[email protected]
