Sunday, October 22, 2006

argghhh, I asked you to Save, Not publish

I realy don't have much time on my hands,
but stuff that I feel I should blog about come to my mind quite often.

so I decided that whenever I get such an idea I will just create a new blog entry,
with the main point of the issue at hand but keep it as a draft until I find some time to make it publish-worthy.

While doing so I discovered that when I edit the new blog entry and press ctrl+S
It just goes on and publishes the entry.

I consider this to be a bad choise of keys, ctrl+S is Save!
When working on a draft and pressing ctrl+S it should SAVE the draft and not publish it.

and yet, I know it says below the editor that ctrl+S is publish and ctrl+D is draft
but hey - the second my mind thinks "Save" my fingers press ctrl+S.

And one last note in case someone wants to do something about this,
remember - ctrl-P is Print... Not Publish.

Anyway, who knows maybe in a few years everyne will know that ctrl+S is publiSh and ctrl+D is Draft.

Thursday, October 12, 2006

about html editing, newlines, new paragraphs and the behavior of the enter key

The following was actually one of the issues that made me want to open a blog.

while working on the HTML editor of gigya.com I encountered the following issue:

The default behavior for both IE and FF is that when editing a document and the user hits "Enter" it starts a new paragraph (like in MS Word). Some (but probably very few) people might know that they have to hold down the "Shift" key while pressing "Enter" to get a new line.

Is this a reasonable behavior or not - well, its a matter of opinion, anyway I was asked to make it so that hitting "Enter" would generate a new line and not a new paragraph.

Take a few seconds and think how would you go about doing this ...

After doing some research it was my boss that found the solution - place a DIV as a wrapper on the edited area, when the cursor is inside the div, for some unknown reason it was decided that hitting Enter will behave differently - luckily for me differently meant just what I needed....

Hopefully this will save someone some R&D time.

Javascript debugger hilites wrong line

You will probably see a lot of JavaScript related posts in this blog,
well, this is because I do lots of JavaScript.

This time I was trying to add FireFox Support to a web app I am working on.
Usually I work with IE and with VS2005 for debugging.

This time I had to do some debugging inside FF,so I tried both venkman and firebug and had the same problem.

I placed a debugger; statement inside a function I wanted to debug (obviously - why else),
and when the debugger came to life it would hilite the line that is two lines above the one containing the debugger; statement.

well for a while I said - well, I will just have to live with it, but after a while I discovered this was easier said then done.

Thinking why this could happen I decided that it must have something to do with the document being changed dynamically and hence the lack of synchronization between the reported lines numbers and the actual displayed code.

so I played with a few simple examples, suppose you have a page that has the following markup:

<script>
s='<div>hello\nworld\n</div>';
document.write(s);
</script>
<script>
function go(){
debugger;
alert('a');
alert('b');
}
</script>
Hello


We would expect it to break at the debugger statement, but see for your self:
Photobucket - Video and Image Hosting
(And no, I did not make it step ahead).

Playing with it for a while I suddenly relized that my original problem was exactly the opposite of this one, as in this case the line that is being hilited is below the actual line being debuged.

so I went to my page, added:
<script type="text/javascript">
document.write('\n\n');
</script>

And voila, debugging became a reasonable task again.

Still the mystery remains - what could cause the debugger to hilite the wrong line but ABOVE the correct line.

Any ideas anyone ?

 
Clicky Web Analytics