BlueGriffon.org - Thinking at loud - Comments

Adding presentation to HTML is hard - gemtsone supplier

gemtsone supplier — Fri, 09 Jul 2010 04:46:07 +0200

But to be able to paint a CSS canvass using your mouse as the paint brush

Adding presentation to HTML is hard - Sean

Sean — Sat, 26 Jun 2010 10:24:54 +0200

"I will probably also remove support for HTML presentational attributes... BlueGriffon will then rely 100% on CSS for presentation..."

I've been waiting a very long time for you to say that.

As the years went by I cringed ever time I saw you working with HTML tables. But when I read your headline "CSS 3 Multicolumn Layout", I cheered.

I would like to make a suggestion if it's not to late in the Bluegriffon game of how I would like to see the work-flow in a completely WYSIWYG HTML editor. My main focus would be the CSS box. When it comes to the users interaction with the program, the div would be the most important element The user would layout the div's in a fully drag and drop manner, design his page with the box/div in mind and work his way inward.

I made a quick video mock-up of this idea. Please check it out here: http://tinypic.com/r/egej5u/6

I remember a few years back I tried a WYSIWYG HTML editor that was pretty much the same as my mock-up, but it used absolute positioning for the divs, which is not the best idea. But other than that the program was pretty impressive. It gave you complete control in a drag & drop, mouse driven environment. In pure CSS for presentation.

Having the same control as the above mentioned program and moving away from absolute positioning would be a lot more difficult. Bluegriffon would have to determine if the div should be floated or not, inline, relative, the list goes on. But in my opinion, this is at the heart of a truly great WYSIWYG html editor. Not the ability to bring up a context menu on some element and apply some CSS to it. But to be able to paint a CSS canvass using your mouse as the paint brush

Adding presentation to HTML is hard - Charles Cooke

Charles Cooke — Fri, 25 Jun 2010 18:52:51 +0200

Well. I certainly agree that we no longer need HTML presentational attributes.

Adding presentation to HTML is hard - julian cellini

julian cellini — Fri, 25 Jun 2010 15:57:54 +0200

I'm thinking on an example:

You have many p with a class,
1) you select some text and apply some format. (BG create a span and create an ID for it)
2) You made the same text formatting inside another paragraph of the same class

at this point, BG can ask for the creation of a css class for those span, or continue with ID's

you can also ask if the user wants descendant selector (with the p class) or not

¿is that posible?

Adding presentation to HTML is hard - Daniel Glazman

Daniel Glazman — Fri, 25 Jun 2010 15:11:14 +0200

@Julian: it cannot rely on contextual selectors unless you're editing an element already styled by such an existing contextual selector. So BlueGriffon will edit existing rules based on context but will only create ID selectors, class selectors and inline styles (only if abolutely necessary).

Adding presentation to HTML is hard - julian cellini

julian cellini — Fri, 25 Jun 2010 14:58:39 +0200

How can you decide if you create an ID or utilice an existant parent node ID and use desendant selector in CSS?

Image dialog - kemie

kemie — Wed, 12 May 2010 21:46:11 +0200

class name, for sure!

Image dialog - Elixon

Elixon — Wed, 12 May 2010 13:56:39 +0200

"float" is must have.

Image dialog - Firewalkwizme

Firewalkwizme — Wed, 12 May 2010 11:03:12 +0200

What about a border too ?

Image dialog - Glue

Glue — Wed, 12 May 2010 09:55:11 +0200

Example of radial gradient from the previous comment:

http://tinyurl.com/336rsol

Image dialog - Glue

Glue — Wed, 12 May 2010 09:48:13 +0200

How about being able to insert it as a background image with CSS linear and radial gradients?

JSCSSP - LUVEN

LUVEN — Mon, 15 Mar 2010 09:12:05 +0100

wat is dean's code?

JSCSSP - Daniel Glazman

Daniel Glazman — Thu, 04 Mar 2010 09:32:34 +0100

@Sean Hogan: yes I know Dean's code ; his parser does not do enough for my needs, unfortunately.

JSCSSP - Sean Hogan

Sean Hogan — Thu, 04 Mar 2010 06:15:21 +0100

Sorry, stupid question. JSCSSP = Javascript CSS Parser

Dean Edward's IE7 project has a CSS parser. You might be interested in collaborating with him.
http://ie7-js.googlecode.com

CSS 'font-weight' and UI - Marc

Marc — Wed, 03 Mar 2010 13:39:26 +0100

I think a UI for CSS is silly. CSS is too complex and has too many options. If you try and implement every option advanced users who know what they are doing would find themself frustrated and normal users would find themself overwhelmed. Personally, I would like a text editor that does solid syntax highlighting, formatting options and non intrusive auto completion / suggestions.

As mejy has already mentioned "Coda" does cover both levels of users well... and as I hand code, I've never bothered with the UI.

JSCSSP - Sean Hogan

Sean Hogan — Wed, 03 Mar 2010 01:05:56 +0100

What language are you writing the parser in?

CSS 'font-weight' and UI - Vincent

Vincent — Tue, 02 Mar 2010 16:31:51 +0100

I suggest to forget about the unspecified value and just display the actual value of the bold property, inherited or not.

Internally, you could keep adding styles to the CSS whenever the user changes something.

Then you can have a "Reset style" to be able to delete all your modifications and return to parent style (like OpenOffice).

Or your software could try to be (too?) smart and delete the style entry when the user chooses what actually would have been the default inherited value. Note that this could lead to this strange behavior: I bold my paragraph, I unbold some character, I unbold my paragraph (the font-weight is actually removed from my characters since it is the same as my paragraph), I bold my paragraph again and boom, my characters are bold again, may not be expected behavior).

CSS 'font-weight' and UI - mejy

mejy — Mon, 01 Mar 2010 22:56:49 +0100

The OS X editors such as Coda and CSSEdit seem to have things right approach IMO - don't try to abstract away all the CSS into some sort of MS Word type interface, just provide a nice interface to the existing model that makes it easy to set possible properties to possible values and preview their effects. Why fight the existing system when it actually makes a lot of sense already?

IMO it would make sense to default to an empty list of properties, and then have an option to add any relevant property to that list.

For options like bold which have an obvious common set of values (true or false, when set) you could then have a checkbox, and a button (with a little settings gear or something on it) that pulls up a drop down menu with more options, setting the checkbox to an inconsistent state (half set) if an 'advanced' setting is chosen.

CSS 'font-weight' and UI - Daniel Glazman

Daniel Glazman — Mon, 01 Mar 2010 21:08:29 +0100

@Wladimir: hey, I like that ; will be a bit tricky to implement because of all the machinery behind but that's the best option so far ; thanks !

CSS 'font-weight' and UI - Té

Té — Mon, 01 Mar 2010 21:03:37 +0100

Shouldn't be too bad with proper labelling.
Just an example, with bad wording.

<label for="setbold">Boldness:</label>
<input id="setbold" type="checkbox">
<select> // disabled=!setbold
<option>inherit</option>
<option>initial</option>
<optgroup label="Textual">
<option>bold (700)</option>
<option>normal (400)</option>
<option>bolder</option>
<option>lighter</option>
</optgroup>
<optgroup label="Textual">
<option>100</option>
<option>200</option>
<option>300</option>
<option>400</option>
<option>500</option>
<option>600</option>
<option>700</option>
<option>800</option>
<option>900</option>
</optgroup>
</select>

Even better, do what Obi says and just have a text field and add auto-completion to it. Even better still would be to have the ability to cycle through values a la Firebug and also get a drop-down with all possible values as above when pressing the down button when the textfield is empty (i.e. unspecified) or something like that.