<Glazblog/>

I guess the title says it all It's available here.

/* enjoy */

BlueGriffon 1.1 was released a few minutes ago. We also released our new CSS Pro Editor add-on, probably one of the best CSS editor on the market with support for Media Queries, Shadows, 2D Transforms, Transitions, Multi-column Layout, Flex box, Web fonts and even a visual CSS 3 Selector builder.

Et bien voilà, je viens de tagger BlueGriffon 1.0. Incroyable mais c'est la révision svn 666 ! Bon, j'ai un sentiment de plénitude et d'épuisement qui me rappelle Nvu 1.0, il y a six ans déjà. En gros, j'aurai presque passé deux ans à plein temps sur BlueGriffon, pour un nouvel éditeur Wysiwyg propre, moderne, extensible réécrit from scratch et disposant son propre parser/serializer CSS. Donc woooof... Je prépare la Press Release, le site de vente des add-ons, et rassurez-vous je n'oublie pas les t-shirts pour les dix premiers chanceux de la Platinum Offer !

Il est l'heure de commencer enfin mon week-end (dimanche 20h), de m'ouvrir une bière, me poser dans le sofa et me dire que j'ai réussi à arriver avec BlueGriffon où je voulais. Enfin. Bonne soirée à tous

So you are a software implementor for the Web or an entrepreneur and you don't know who Nick Longo is? You should... In the Hall of Fame of the Web, his name has a place of choice. Not only is Nick the founder of one of the first Internet Cafés on the planet, but he's also the co-author of one of the very first HTML editors, CoffeeCup. You just have no idea how many CoffeeCups or add-ons to CoffeeCup he sold... I do. And I still can't believe the figures even if I know they are correct.

Today, I saw this appear in my twitter timeline:

Thank you so much Nick!

Bloquez la date !!! Systematic organise une belle conf sur JavaScript le 20 janvier prochain après-midi et le programme (qui n'est pas encore disponible) sera alléchant ! J'y serai pour parler du développement de BlueGriffon. Modalités d'inscription et programme à venir.

Mise à jour : les inscriptions sont désormais ouvertes via le lien ci-dessus.

Rappel, BlueGriffon Meetup à Paris demain soir lundi 6 décembre, venez nombreux !

WebFonts only took off in 2009 but they are an old technology. WebFonts are cool. WebFonts allow better and nicer web sites. WebFonts are cool but free fonts are hard to find.

So I just added to BlueGriffon a UI to add fonts from the Google Font Directory to a document w/o having to deal with a single line of code, markup or CSS. See the result here. The resulting add-on (XPI) is free to download.

Comme proposé il y a quelque temps déjà sur Twitter, il y aura un meetup sur BlueGriffon le lundi 6 décembre de 17h à 19h dans une salle généreusement prêtée pour l'occasion par l'IRILL, 23, avenue d'Italie, 75013 Paris. Plusieurs choses :

• la capacité de la salle est de 30 places ; premiers inscrits, premiers servis ; merci de ne vous inscrire que si vous êtes sûrs de venir ; inscription par mail à daniel AATT glazman DDOOTT org ; les inscrits seront listés au fur et à mesure ci-dessous
• pour venir à l'IRILL : tout est là.
• la langue sera le français
• si vous avez des questions spécifiques que vous souhaitez voir discutées, envoyez-les par mail à l'adresse donnée dans le premier item ci-dessus

Encore tous mes chaleureux remerciements à Sylvestre Ledru et Roberto Di Cosmo pour la salle !

(si on a le temps, on pourra aussi parler CSS 3, W3C et tout ça)

1. Jeremie Patonnier

On m'a suggéré de faire un meetup sur BlueGriffon à Paris début décembre. Cela serait si possible un vendredi soir, disons de 18 à 20H. Si vous êtes intéressé ET pensez venir si cela se fait, merci de laisser un commentaire pour le dire, j'ai besoin d'estimer combien de personnes seraient présentes.

You probably never asked yourself about it, but how complicated is the deletion of the selection in a markup-based Wysiwyg editor? In one single word: complicated.... I will try below to make you understand what a Wysiwyg markup-based editor does when you hit the delete key.

Let's take a simple example :

<h1>aa[aa</h1>
<ul>
 <li>bbbb
   <ul>
     <li>cc]cc</li>
     <li>dddd</li>
   </ul>
 </li>
 <li>eeee</li>
</ul>

The selection is everything between the square brackets (included). Now the user hits the delete key. The natural algo for that is the following one (I'm not saying it's the only one; see DOMRange.extractContents to see another one):

1. find all the "visible" nodes in the various ranges (here we have only one range) of the selection. A "visible" node is a text node or an empty element.
2. split the start and end nodes of each range of the selection if necessary, for instance if these nodes are text nodes and the selection splits the nodes in two nodes of non-zero length.
3. for each visible node in each range of the selection, remove the node and remove recursively all the parents if they are "removable". A "removable" parent is an empty element or, depending on its tag name, an element containing only text nodes made of whitespaces (/s in regexps); some elements are explicitely not "removable", body for instance.

This method is enough for the test case above and here's the expected result:

<h1>aa</h1>
<ul>
 <li>
   <ul>
     <li>cc</li>
     <li>dddd</li>
   </ul>
 </li>
 <li>eeee</li>
</ul>

But now imagine we have some markup that requires merging after the deletion of the selection. Here's one:

<ul>
 <li>aaaa</li>
 <li>bb[bb</li>
</ul>
<ul>
 <li>cc]cc</li>
 <li>dddd</li>
</ul>

What the user really expects here when the selection is deleted is the merging of the two ULs into one single list. We need then to improve a bit our algo above...

1. find all the "visible" nodes in the various ranges (here we have only one range) of the selection. A "visible" node is a text node or an empty element.
2. split the start and end nodes of each range of the selection if necessary, for instance if these nodes are text nodes and the selection splits the nodes in two nodes of non-zero length.
3. traverse all ranges in our selection and preserve a list of all nodes traversed with the traversal direction (start, up, down, next)

For our examples of two adjacent lists, the list of traversed nodes is:

But that's not all... There can be non-significant text nodes in the DOM between elements, like a carriage return between the two ULs. So to make sure we correctly merge during our deletion, the third step of our algo should be this one:

4. for each node being an element and having a direction "next" in the list of traversed nodes above, find the previous "visible" sibling, discarding text nodes containing only white spaces if the element is a block. If the previous visible sibling is also an element and of same type than the reference node, and if these elements are "mergeable", then append all the children of the reference node to the previous visible node's children and delete the reference node. Two "mergeable" elements are for instance two paragraphs, or two h1 elements, or two dl elements; two inline text elements like span or strong are also mergable if

The rest of the algo is similar to what we did for the h1/ul example above:

5. for each visible node in each range of the selection, remove the node and remove recursively all the parents if they are "removable". A "removable" parent is an empty element or, depending on its tag name, an element containing only text nodes made of whitespaces (/s in regexps); some elements are explicitelynot "removable", body for instance.

<ul>
 <li>aaaa</li>
 <li>bb</li>
 <li>cc</li>
 <li>dddd</li>
</ul>

Next time, we'll dive into some high-level functions like indentations or list creation.