markkit works on Safari

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.

Add a highlighter to your site

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 : and copy the code.

the BigBug is fixed (hopefully)

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.

the separation of security and software

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.

Internet Explorer 8’s dom is still broken

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.

Bazdig, the SQL console/editor

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 :

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.