<Glazblog/>

I spent an hour testing the new Panorama (aka Tab Candy) in the last nightly of Firefox and I have a few thoughts to share about it:

• it's not ironed yet (no tooltips, apparently low accessibility, tabgroup close buttons sometimes unresponsive at least on my Mac and w/o :hover effect) but hey that's a beta so no worries here; I loved the fact you have "magnetic lines" on the panorama viewport to make sure your groups nicely align.
• this is not a criticism but I find pretty amazing that we're moving back to some kind of UI/UX Opera offered long ago on Windows with their MDI desktop browser. With real zoom being available in Gecko, the Panorama view could be live... I mean the current canvas screenshots could be real live zoomed-out browser and then we have almost MDI again.
• no journalist noticed but the Panorama view is not a XUL view. It's based on HTML. It's one of the first times a major, shipped-in-the-browser and differenciating new feature of Firefox is entirely based on HTML from a UI perspective and not on XUL. This is very nice. Very nice but it has a bad side effect related to extensibility, because the current extensibility system in Mozilla (hear overlays) does not apply here. Creating then an add-on adding specific stuff to the Panorama view itself seems to be harder than expected.
• at first glance, having the app suddenly turning into a big grey area w/o menubar or toolbars or decorations feels really weird. I really wondered if it was a bug. The next item proposes a way to fix that issue.
• I think the UX could be improved in particular now we have canvas, CSS transitions and super powerful effects. The transition normalview-to-Panorama could be smoother with a better dissolution of menubar/toolbars and expansion of tabs into tab thumbnails ; probably requires a lot of work but would make the whole think better understandable, in particular the fact you see only one Tab Group at a time. Similarly, the panorama-to-normal transition is not smooth enough; that's partly because zooming from 0.1 to 1 blurs things a lot but that's also because reflows are not fluid enough and only one viewport expands and not the chrome. The selected tab could also expand while the rest of the Panorama view dissolves. Anyway, I'm just thinking out loud here but the fluidity of the whole thing can be improved and that would really help the user understand what's going on.
• I do like the concept a lot. I have mixed feelings about it though because after an hour using it and having six Tab Groups set up, I ended up having too many times to go back to the Panorama View w/o really needing it. The Panorama View then becomes de facto a focal point of the application and I'm not sure this is desirable. This is a browser after all and Panorama is only, IMHO, a helper feature. It can sound like a minor comment but I don't think it is since Panorama drastically changes the gravity center of the whole app and this the kind of things average users are easily lost with. Here are a few ideas (again, thinking out loud here) to possibly fix that issue or at least decrease its importance (these ideas are not mutually exclusive):
  
  • add an option/UI allowing to directly cycle not only between the currently shown tabs but between tab groups (if it already exists, I did not find it, sorry)
  • offer the choice (hear a pref) between show-only-one-tab-group-in-normal-view and show-all-tabs-anyway-in-normal-view ; with the latter, Panorama is only a supplementary enhanced tab list not interfering with a browser behaviour users have been dealing with for years.

Today, Microsoft Internet Explorer is precisely 15 years old. Wooooohooo !!!!

Sans commentaire...

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.

De passage dans le LIDL à côté de chez moi, je suis tombé sur un scanner de négatifs de la marque SilverCrest (une LIDLerie) à 39.99€. Comme LIDL ne fait aucune difficulté pour rembourser sous une semaine si on n'est pas content d'un produit et et comme j'ai des milliers de négatifs en souffrance, je me suis laissé tenter.

Installation très simple, logiciel plutôt simple à utiliser même s'il n'est pas beau. Ne marche que sous Windaube et pas Mac OS X mais bon, à ce prix-là... Tout ce qu'il faut pour les néga et les diapos. Mais malgré toutes mes tentatives de réglages, le scan génère des lignes sombres horizontales franchement pénibles et rendant le scanner peu utilisable. J'ai donc demandé le remboursement du produit, que je ne recommande à personne malgré son prix fort attractif. Voila.

Je viens de dévorer en une journée "Absolument dé-bor-dée !" de Zoé Shepard et je dois dire que j'ai adoré. Tout d'abord j'ai beaucoup ri. J'ai fortement apprécié le rapport de whistleblower sans concession (si ce n'est les changements de noms). Le tableau qu'elle brosse est effarant, consternifiant dirait Tristant Nitot, pire que celui que Corinne Maier ou moi-même avons pu dresser de la R&D d'Electricité de France. Je recommande chaleureusement ce livre, ne serait-ce que pour aider un peu l'auteur qui risque une suspension de deux ans sans solde par le Conseil Régional d'Aquitaine (encore qu'il semble qu'une suspension de ce type aussi longue soit illégale).

Un détail important : Zoé Shepard et son livre seraient probablement passés inaperçus sans la connerie sans limite de son employeur. Comme dans le cas de "Bonjour Paresse" de Corinne Maier, c'est l'énorme publicité offerte par l'action légale contre l'auteur qui a assuré son succés. Encore bravo au responsable de la communication et au président du conseil régional d'Aquitaine pour une décision non seulement complètement con mais surtout contre-productive. Félicitations à l'éditeur de Zoé Shepard qui a du se dire qu'avec des andouilles de cet acabit, la plainte était garantie et donc la pub avec.

Je serai l'invité de Guillaume Erner demain matin à 9h00 dans son émission en direct sur France Inter. Sujet : Apple... Les podcasts sont en général disponibles après l'émission.

Utilise.ca m'a fait l'honneur de m'interviewer récemment. C'est en ligne depuis quelques minutes.

So where are we (that "we" meaning the CSS Working Group) on CSS 2.1? In short, we're making fast and excellent progress:

• we are currently resolving the last outstanding issues ; almost all our weekly conference calls are entirely dedicated to CSS 2.1
• the Test Suite is near completion ; the Working Group has decided, given the size of the Test Suite, that it's not realistic to review individually all tests before saying the Test Suite is completed. We will declare the Test Suite ready for implementation reports and will fix individual bugs when reported buggy by testers, browser vendors, the community, whoever. On a more personal note, I think it's the only reasonable way of dealing with a Test Suite that contains thousands and thousands of tests, some of them rather complex not only to write but also to understand when you read them. Otherwise, the review and validation process of all these tests alone will take ages...
• given the recent changes in the spec - we resolved a lot of issues some of them pretty complicated - we may have to go back to Last Call Working Draft and then back to CR again. That's not a problem and can be relatively fast.
• the current CR exit criteria - that we don't plan to change - are very clear (see conditions 4 and 5). The CR period could be a bit long though; we'll see.
• the Test Suite and the CR should be available at same time and that time should be, as planned by the WG, after the summer. That should leave us enough time to reach Proposed Recommendation before the end of the year, as expected.

To the people who could complain about the duration of this process and the time needed to make this spec appear as a REC, let me say that we have a lot, really a lot of work here. The WG focuses almost solely on CSS 2.1 at this time and that's not recent. 2.1 must be released as a Web Standard because that's one of the current cornerstones of the architecture of the World Wide Web. We cannot make the next steps, CSS 3 even module by module, happen without 2.1 before.

In summary, we're on track. As expected. No reason to worry.

Thanks.

Daniel Glazman, W3C CSS Working Group, Co-chair

Update: reposted on W3C blog.