BlueGriffon.org - Thinking at loud

Adding presentation to HTML is hard

BlueGriffon — Fri, 25 Jun 2010 14:12:00 +0200

Attributes ? Inline Styles ? Context ? ID ? Class ? A mix ? *sigh*

I'm not happy with the CSS Policy Manager I implemented. It currently lets users of BlueGriffon decide in all dialogs how an action should be performed: through HTML attributes, through inline styles, or through embedded styles attached to an ID or a class. That's far too complex for many users and the resulting dialogs are so painful that I hate them myself. I am then going to revamp it entirely and remove the corresponding bits from the dialogs. I will probably also remove support for HTML presentational attributes... BlueGriffon will then rely 100% on CSS for presentation... That was not possible a few years ago because of the browsers' landscape but I think it's now a more - if not perfectly - reasonable target. The whole Table Layout dialog is already 100% CSS-based.

In summary, the Preferences panel will offer the following choices:

Let BlueGriffon decide by itself how it adds styles and let it pick IDs and classes for me when needed (enter a prefix below)
Let BlueGriffon decide by itself how it adds styles but prompt me when a new ID or class is needed
Let me decide

It's clearly (much) harder to implement but I am sure the whole CSS/HTML machinery should be hidden as much as it can. The average user - and that includes myself - does not want to know about the technical details as soon as the result is clean, standards-compliant and what he/she expects from a rendering point of view. Advanced users will still have the possibility to edit their stylesheets directly through the CSS Manager.

All in all and in my opinion, this proposal is good for both beginners and advanced users. Comments?

T-shirt :-)

BlueGriffon — Tue, 22 Jun 2010 22:42:00 +0200

here...

Image dialog

BlueGriffon — Wed, 12 May 2010 09:21:00 +0200

The new Image insertion dialog in BlueGriffon will allow to set a CSS box shadow and a CSS roll-over. Other suggestions?

JSCSSP

BlueGriffon — Tue, 02 Mar 2010 14:14:00 +0100

Nvu had a strong limitation, because of Gecko. It could only edit CSS styles understandable by the embedded version of Gecko. This is something I don't want for BlueGriffon because I think it does not make sense to make a content editor for the Web that is restricted to Gecko-based browsers. I want users to be able to manipulate a UI that will create -moz-transform but also -webkit-transform. And I also want users to be able to edit stylesheets that include both properties while the -webkit-* are never present in Gecko's CSS OM (and that's normal). I don't need to cascade, I want to preserve all rules and all declarations even multiple declarations of the same property, I want to preserve comments as much as possible (ie between rules and between declarations), I want to preserve CSS parsing errors. The only extra thing I need is a resolver for shorthands.

So I just started my own CSS parser. It'll parse a string containing a stylesheet and will return CSSOM-like objects with the necessary extensions. It'll live inside the CSS Inspector sidebar of BlueGriffon but I will probably make it MPL.

CSS 'font-weight' and UI

BlueGriffon — Mon, 01 Mar 2010 16:35:00 +0100

CSS is so cool. So cool. But not in terms of UI for a CSS editor...

let's suppose you can have your text 'bold' or 'normal'; one checkbox or checkboxButton is enough, and you can have this button live with other buttons like italic, underline and others
let's suppose now you can have your text 'bold', 'normal or unspecified ; a few options here:
1. one checkbox to say the boldness is specified or not and a checkbox/checkboxButton for bold
2. two checkboxes/checkboxButtons for 'bold' and 'normal'; property is unspecified when both are unchecked
3. a menulist with three choices
let's suppose now, and that's the CSS real case that matters to me, boldness can take the values 'bold', 'normal', 'bolder', 'lighter', 'inherit', 'initial', 100, 200, 300, 400, 500, 600, 700, 800, 900 or can be unspecified... The two reasonable choices here are:
1. one checkbox to say the boldness is specified or not and a menulist
2. a menulist where 'unspecified' is one of the options

In other terms, offering the full power of the 'font-weight' CSS property to a CSS editor will necessarily suck in terms of UI (yeah, forcing a menulist when most users will only use the 'bold' choice just sucks)... I am even tempted to have two modes in the CSS editor, basic and advanced. Pffff....

Ideas, suggestions?

Speaking of tables

BlueGriffon — Fri, 03 Oct 2008 16:04:00 +0200

One of the nice features of text editors is table formatting. Think MS Word and its Table Autoformat dialog. It's very easy to implement that in BlueGriffon... Hehe