<Glazblog/>

This is a verbatim from an IRC chat:

<glazou> are interested in contributing?
<glazou> s/are/are you
<xxxx> looool, nerd
<xxxx> 
<xxxx> unfortunately i didn't grow up with the terminal but i think i heard of s/

Je viens de mettre à jour mon add-on FreeRecord pour Firefox. La version 4.01 est donc disponible pour Firefox 4.01 (et c'est une coïncidence). Vous pouvez l'obtenir via Outils > Modules Complémentaires et en faisant un clic droit sur FreeRecord, ou en la téléchargeant directement depuis le site.

The trickiest problem of all for a DOM-based Wysiwyg editor... I already wrote multiple times about it, but once more is not worthless. Here are some of the requests I currently have on my BlueGriffon radar:

1. don't mess with my indents and CRs
2. please don't wrap long lines for asian languages since that introduces an unwated whitespace in the rendering
3. I want a checkbox in the source view allowing me to toggle on/off the line wrapping
4. don't touch my original source code but if I insert new paragraphs, I want a paragraph per line, not an endless line with all my new content

Eh. Only that... Let me give one answer per item above:

1. in just a few words, that's impossible in the general case. The simplest case a DOM-based editor will never handle is the following one

   <img src=foo.png"
        alt="my image" />

   where the user wants to preserve the indentation of the alt attribute in the source code... In the DOM, the carriage return and the indentation just cannot be preserved. There is no way the HTML serializer can output the same source code from the DOM. Yeah, well, it could nicely indent the second attribute. But then it will do it for all attributes. And some other users will complain about it, in particular if the two attributes fit into one single (not too long) line.

2. that one is doable modulo the fact people wanting this also always want request number 4 to avoid endless lines. So see item 4 below please.
3. that request implies a deep misunderstanding of what is the source view of a DOM-based editor... The source code is serialized from the DOM tree before showing the source view. If the source view shows line wrapping for instance at 72 chars, it's impossible to go back to the unwrapped view without reparsing the source and reserializing the DOM tree w/o the wrap option ; same thing if you have an unwrapped view, the list of operations needed to switch between unwrapped and wrapped is not trivial at all. In all cases, the result will very likely be not exactly in line with what the user expected.
4. sigh. So if you original source contains in one single line <p>a</p><p>b</p> you want to preserve that as it is, but if you create the same two paragraphs in the Wysiwyg view, you want the created paragraphs to generate one line each in the source view. There's only one way that could be done: give a special attribute or user data to the nodes created in the wysiwyg view. Why? Because there is no other way the serializer can make a difference between a node that was in the document at parse time and another node you created by hand... Then during serializing in Raw mode, output a CR before blocks' start tags for blocks that do carry that special attribute/user value. Of course, those special data should not be visible in the source view. So when you go back to wysiwyg view, they're lost. Hum, to say the least.

I said it multiple times in the past, a DOM-based Wysiwyg can try its best to keep your source code readable, indented, nice. But it cannot, it just cannot preserve an original source code whatever that source code. Serialization will always drop some whitespaces/CRs from the original source. It will always have to make compromises between the various - and opposite - wishes of the user. Wysiwyg is still hard.

When Mozilla trademarked Firefox, many people complained loudly. How dared Mozilla trademark a name related to open source and free software... I did not complain. I made comments, because the original trademark policy needed some light clarifications, but I did not complain at all. I found it perfectly wise and normal for Mozilla to protect the name of its flagship product to avoid clones of Firefox under the same name/logo. I never found the trademark harmful to the Open Source nature of Firefox and still think the free zealots who switched the name/logo to Iceweasel are stupid fanatics. Ubuntu's name and logo are protected too and they never shout at that.

So when I started working on my current new editor, I did the same and trademarked BlueGriffon immediately.

And since a pure copy of http://bluegriffon.org appeared some days ago under the URL http://bluegriffon.FR, it was a good idea. The site was such a copy of mine that the TM signs, the logo, the prose, the images, everything was copied. The download links were changed, the contact emails were changed and more important, ads were added... The cybersquatter behind that is apparently well known to copy/abuse very visible open source or free projects to drive ad-based income.

Here, thanks to the TM registration, a cease-and-desist letter was enough. The domain is now in the hands of my company even if the DNS changes are not widely spread yet. A legal action would have given the same result : TM infringement was clear, and AFNIC rules were clearly in our favor.

So thanks Mozilla, thanks a lot for the lesson. Sincerely.

On Mac OS X, three-fingers gestures (top-to-bottom or bottom-to-top) used to scroll to the bottom or top of the document. I am really used to it and find it much more important to my daily browsing life than the new settings, showing or hiding Panorama. I restored the previous settings with the following:

• set browser.gesture.swipe.down preference to cmd_scrollBottom
• set browser.gesture.swipe.up preference to cmd_scrollTop

Just saw Tantek Çelik appear on planet.mozilla.org. Just saw also the announcement on Planet Mozilla Blog and it made me react immediately because Tantek's introduction there is not enough.

Tantek is not just yet another contractor with a good standards background. Tantek is the man behind one of the most superb browsers of its time: Internet Explorer for Mac, with first-class CSS support. He is also a loooong-time influential member of the CSS Working Group (if I recall correctly, Tantek joined the CSS WG in 1998) and contributed directly to many of our specs. If two or three names have to be attached to Microformats, Tantek's is one of them. It's a side note but he's also an old and good friend of mine I have immense respect for. Tantek is a guru, a real one, and Planet Mozilla Blog's announcement did not reflect it.

Seeing Tantek become a mozillian is an old dream. I think I mentioned it during a dinner in his flat when he decided to leave Microsoft. But Tantek joined Technorati instead. So welcome Tantek !

Oh, and his last name starts with a Ç (&Ccedil;), don't write it C

I have no idea how to file that bug in BMO and I'm not even sure it's a BMO bug since it's more probably a Flash plugin bug so let me describe it here:

• the Firefox 3.6.8 home page recommended me recently to update my Flash plugin on my Mac OS X box (Snow Leopard)
• so I did...
• since that day, many web sites showing Flash-based videos freeze making the browser totally unusable with CPU usage > 95%. A good example is http://lci.tf1.fr/
• I originally thought a bad interaction between Flash and AdBlockPlus was guilty but I removed ABP and the problem is still here ; the Flash plugin is almost certainly guilty here

The new Flash plugin was probably pushed to users for security reasons. But for UX reasons, it's probably better to stop pushing it until this problem is gone...

Let's say the user wants to use a larger font size on the LAST paragraph in the following example:

<style>
  #section p { font-size: larger ! important}
  .warning   { color: red; border: thin solid red }
</style>
<div id="section">
  <p>This is NOT a warning</p>
  <p class="warning">This is a warning</p>
</div>

We're in a Wysiwyg environment, the user got the document from an unkown source, places the caret in the paragraph or selects the whole paragraph, click on some UI thingy meaning "I want a larger font" and he/she expects a larger font size for the paragraph, whatever has the editing tool to do for that... The user has no knowledge of the underlying technology - in our case CSS - and he/she's the perfect target for Wysiwyg editors. Let's suppose the editing tool manipulates stylesheets and hates HTML attributes and inline styles, and that's also our goal.

First thought and first problem, we cannot apply font-size: larger to the paragraph since it's already applied... But, wait, how do you know it's already applied? Just looking at the computed value of font-size, you can't since that will reply only an absolute value like 18px! So to determine if and how you can tweak a given property on a given element, you first need to browse all the CSS rules applying to your element. In Gecko, you can use the inIDOMUtils DOM Inspector interface and namely its getCSSStyleRules() method. Then for each rule applying to the element, you need to check if the property is applied to the element through that rule and if it is, compute the specificity of the selector and preserve the rule, the specificity of the rule and the priority (think !important) of the declaration in an array. When that's done for all rules, sort the array according to the CSS Cascade rules... Yep, that's right, you read it well, you need to recascade yourself the whole thing because the CSS Object Model has no getCascadedValue() method for the time being. Oh and of course, nothing either to compute the specificity of a given selector...

Once you have the cascaded the whole thing, you have the rule applying the current font-size to the element, its specificity and the priority of the declaration. Of course, there is a trivial case where no rule applies to the element for that property and your final data set is empty. 

Then the editing tool has no choice, it must create a rule with a specificity greater than or equal to the specificity of the rule we found and caring about the priority of the declaration...

• If the data set above is empty or if the rule's specificity is equal to or less than the specificity of a class selector, AND IF the user says through some UI dialog we can safely apply the change to all <p class="warning">, then we can create a .warning { font-size: ...px } or .warning { font-size: ...px !important } rule at the end of our stylesheet where ... is a font-size value greater than the computed value of font-size on the element. Hey, yeah, you have to compute that value yourself again We won't deal with the p.warning possibility because it's just impossible to show an average user a dialog asking for permission to change the styles applied to all paragraph of class warning and not other elements...
• Else if the rule's specificity is equal to or less than the specificity of an #ID selector, we can safely insert a #myNewId { font-size: ...px }  or #myNewId { font-size: ...px ! important } at the end of our stylesheet but please note the editing tool has to query the user for an ID or select a random - and unreadable - one by itself. Of course, the font-size computation issue detailed just above still applies here.
• Else if the rule's specificity is equal to or less than the specificity of an #ID selector and a type element selector, we can safely insert a p#myNewId { font-size: ...px } or p#myNewId { font-size: ...px ! important } at the end of our stylesheet. And the font-size computation and the ID UI query issues still apply here.
• Else we have the most complex case: we need to prompt the user for an ID or find a random one and derive a rule from the selector of the rule we found above adding an ID simple selector to the last chain of simple selectors in the selector. In other terms in our case here, create #section p#myNewId { font-size: larger ! important} from #section p { font-size: larger ! important}.

Woof. Of course, the CSS Object Model's minimalistic interfaces don't help a lot here and the editing tool's author will end up writing a lot of code that is already implemented in the rendering engine, but not exposed. Welcome to my world