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]
