grab a new bookmarklet, click on the bookmarklet, then on the markkit label, see your marks. voila.

markkit has a mark log , but it’s never been a main feature. markkit is a highlighter, it highlights text in a web page. it’s up to you to store your highlighted pages using whatever app you like (del.icio.us, firefox bookmarks, …) .

but I quickly noticed when I started using markkit everyday, that the mark log was in fact very useful as a short term memory. In fact i used to go to the mark log very often to see my recent marks, since I was the only person using it.

Lately some people started using markkit, it became more difficult to find my marks. But I must admit that what decided me to work on the /home feature is this post from startuparabia : both Mohamed Marwen and Montassar asked for it.

howto

• delete your old bookmarklet
• grab a new bookmarklet
• go to any web page
• click the markkit bookmarklet
• highlight (note: actually you don’t have to. but if you don’t do you wont see any mark in your markkit home page)
• click the markkit label (at the top of the page)
• see your marks

what’s still missing

If you use more than one bookmarklet (if you have more than one browser, or use more than one computer) , you will actually have a different home pages for each bookmarklet. In coming weeks I will add a feature that lets you register and have all your marks in one home page.

For the moment there is a workaround : have the same bookmarklet on all your browsers. I leave this as an exercise to the reader.

To be honest, markkit always worked on safari. The only problem was interoperability between Safari and Firefox. Thus highlights made using Firefox were not visible to Safari users, and the other way around also.

I nailed it last week when I was unable to see highlights from @houeida which is a mac user using my Firefox2. Today I thought it was time to investigate a bit more to see if i can fix it quickly. And in fact, I tried and it worked. I never been so happy for having made the right choice of developing for the standards from the beginning of the project. I mean, I just got support for Safari almost for free.

But what was going on in first place? It happens that the generated DOM trees from Safari and Firefox are almost identical, since they both conform to w3c standards. The only difference is the position of the body node : it’s the first child node of document in Safari and the second in Firefox.

Now, I did not even had to bother know what was actually the first child node of document in Firefox. All I got to do is setting document.body as a root node for markkit in place of document. And everything worked. DOM magic.

A friend of mine asked if he can add a markkit button on his blog so that anybody visiting a page on his blog can highlight. I lied : “sure!” then I did it before he noticed.

From now on, you can add the cool markkit yellow button to your website. It’s easy just go here : http://markkit.net/in-your-site.html and copy the code.

sometimes you highlight text in different parts of the same paragraph, you come back later and you find only half of your marks. this is the BigBug.

After weeks of investigations, of trying different strategies, of reading specs and of testing… fixing the bug was a matter of ordering the marks. It took me 5min this morning. But why did it take so long. It has to do with the fact that the BigBug is a symptom of a BiggerBug, otherwise called “conceptual gotcha” : the DOM is dynamic. it can change at any time without notice and markkit will have to cope with this. Web pages are full of Javascript that CRUDs Nodes in the DOM. Ads are the most common example. What would markkit do if some javascript displaced the paragraph where you highlighted text before your marks were loaded? I don’t know (actually, i know, but i wont tell you).

What i did is just a bugfix. It was possible because the BigBug is a specific case related to the fact that markkit itself changes the DOM under his own feet (!). Someday i will have to implement a more general solution to the problem.

other improvements i also did this morning :

• fragment identifiers : when you click the bookmarklet, markkit used to remove the fragment identifier. now it leaves it.
• you own your session : if you click the markkit bookmarklet you create a new session. you highlight text, then you send the URL to your friend. he can see your marks of course. but he was also able to use your session to highlight text. which is annoying, since he’s not always aware that he is in the middle of a markkit session. From now on, he wont be able to highlight text in your session, he will have to start his own session using his own bookmarklet.

We’ve all heard of “security from ground up”, “security is not a feature, it’s a process”, “Embedded security”, “Security awareness”. All of this sounds like self-censorship applied to the software developer.

Today, i chanced upon James McGovern’s Firewall 2.0 which reminded me of a discussion i had recently with Marc Blanchet about how Security section became mandatory in every RFC. My argument could be formulated this way : “This move goes against a basic good design principle : separation of concerns“. Then i acknowledged that this fits into a more general movement in favor of security.

Generally speaking, security comes at the cost of freedom. There is no workaround. Whereas freedom is essential to development. Including software development. Security and Development are two antagonist values, and there should be two antagonist powers behind them. None should care about security and development at the same time. Otherwise he will certainly break both.

It’s 2008. We reached DOM level 3. DOM level 1 is 10 years old and IE8 still does not have a Node or Range interface implementation. it’s sad.

markkit relies heavily on DOM objects. so I’m disappointed. i must admit, i hoped, naively, IE8 will be really dom compatible. so that i don’t have to do the ugly work of adaptation to IE quirks.

now i’ll have to do it. but, i pushed it down on my task list.

P.S. don’t even try to do the X-UA-Compatible ugly trick. it does not work.

last times i had to cope with SQL for long days. the mysql standard CLI console proved to be very handy, especially with readline (learn the power of CTRL-r ). but it lacked one feature : infinite history. i had to save, my queries in an organized text file between sessions. which was silly. Bazdig never forgets a query.

so i decided to make a better SQL console. some time ago, i heard about codepress, it was a perfect fit for what i wanted to do. i built bazdig around it. it required 50 hours of work and here is it :

http://repo.or.cz/w/bazdig.git

you can download it, or, if you feel more helpful, get it from the repo.

this is the markkit blog. I’ll be posting news about markkit here. keep in touch.