Posted on by lhl

I submitted that bug that CSS2 Selector bug that I mentioned yesterday to Bugzilla. While creating a test page, I discovered it only occurs in quirks mode only occurs in quirks mode and with the :hover pseudoclass apparently (see additional testing w/ :focus added). But it’s still wrong, and not mentioned as something that should be handled differently according to the quirks list. Also, I submitted another bug related to the edit controls that I noticed while I was working on that, namely that the undo/redo buffers get cleared after a Javascript value change. Personally, I think this is a really big and annoying bug. A Javascript value change should be no different than any other typed change, and should definitely not be clearing the undo/redo bufers (for all the previous typed changes). IE works like you would expect it to. You can undo and changes, regardless if it were typed, or changed via JS. I’m hoping this is a simple bug to fix, like a ‘oh, we just won’t clear the buffer on a value change’ thing, but it might be slightly more complext than that to fix…

While playing around with the undo/redo (which honestly, I hadn’t really paid that much attention to. If it works properly you shouldn’t have to notice it) I noticed that in some respects Mozilla is more advanced. With Mozilla, each text input has it’s own independent undo buffer, which it’s advantages, I suppose. IE shares the buffers. That does mean you can actually undo stuff in the order you typed, but it does jump you around. I guess it’s a wash on which way is more usable. Also, IE does a character by character undo, which while taking longer, does give you some more control. Mozilla’s undo removes entire blocks, each block being a contiguous change (marked off by deletions or changes in focus). Again, I’d probalby have to give some more thought about which implementation is ‘better’.

Posted on by lhl

While styling the toolbar for the text input, I found some strange behavior in Mozilla’s CSS selector code. The SelectORacle parses this properly: #bar > *:hover, but Mozilla doesn’t handle it. Strangely enough, if you specify the element, say, like #bar > strong:hover, it’ll work.

Posted on by lhl

I’ve been really busy at work, so I originally missed seeing that a getSelection patch (bug 88049) had finally been checked into the latest nightlies. I’ve been waiting for this for over 2 years now, ever since I tried to implement the Blogger text-edit controls in an early milestone build of Mozilla (haha, I tried using window.getSelection(), silly me, why would I ever think that would return a selection?).

Now, here was where I was going to announce my triumphant victory. After all, it’s relatively simple to code, assuming the feature is working. And to that end, I’ve spent a few hours over the past few days whipping it up. But that little matter about the feature actually working? Well, it doesn’t really. With the current nightly builds, the ranging features die horribly when hard line-breaks are involved. Apparently, in those cases, the text nodes are represented in separate text nodes internally (this is not accessible to us mere mortal webmonkey’s, however. the DOM Inspector shows the entire text as one single textarea – I even tried to work around it by working on counts from the textLength, but it’s a no-go, the problem is intractable on this end). Also, even when it does work, there doesn’t seem to be any way to undo once you’ve done the insert. That’s awfully annoying. The entire selection / input / editing functionality in Mozilla seems to be pretty rickety, especially when compared to how well IE’s text editing. (Should I even mention ContentEditable? Well, at least there’s Xopus for that – no hope for an XBL fix for selections, that’s still broken.)

Umm, hmm, I’m ranting again. Anyway, as the bug is being actively patched, maybe in a few days this will actually work properly. Until then, it still will, but only if there are no hard line breaks:

I made versions for metafilter and blogger as well. Along the way, I found a fix for blogger’s wonky textare display. It renders properly when the following style code is added:

form { height:100%; padding:0; margin:0; }

I submitted that tidbit to Shellen the other night, but haven’t seen the change go up yet.

Ending massive post by clearing out some random links: