Is BlueGriffon a true wysiwyg web editor

[James Holland]

I had thought that BlueGriffon was a wysiwyg web editor. I expect an
editor that claims to be wysiwyg to work
somewhat like Microsoft Word, Open Office or even Kompozer. I
discovered that it must be some kind of hybrid.
I like most of the way it works except when it come to sizing fonts. I
do a website that the content changes
daily, in almost real time, and the font sizing thing makes me finally
put BG aside except for choosing colors. Many thanks for all the
people who make open source software, If Bg had all of the font
formating that Kompozer does, it would fill my bill. Thanks Daniel
maybe next time.

[Daniel Glazman]

On 25/01/13 04:57, James Holland wrote:

> I had thought that BlueGriffon was a wysiwyg web editor. I expect an
> editor that claims to be wysiwyg to work
> somewhat like Microsoft Word, Open Office or even Kompozer. I

James, let me laugh a bit, ok? KompoZer???? KompoZer is a fork
of Nvu and I am also the author of Nvu! Trust me on that, BlueGriffon
is just as Wysiwyg as Nvu or KompoZer were (I say "were" because
both are completely obsolete, last updated ages ago).

That said, WYSIWYG only means What You See Is What You Get. It only
says the visual representation of the document in the editor is the
final one you'll get in the browser.

> discovered that it must be some kind of hybrid.

Sorry no, no hybridation here. BlueGriffon is reall Wysiwyg.

> I like most of the way it works except when it come to sizing fonts. I
> do a website that the content changes
> daily, in almost real time, and the font sizing thing makes me finally
> put BG aside except for choosing colors. Many thanks for all the
> people who make open source software, If Bg had all of the font
> formating that Kompozer does, it would fill my bill. Thanks Daniel
> maybe next time.

Well, since I implemented both, let me tell you KompoZer is totally
obsolete with respect to font management (style, size, etc.) and people
will probably laugh at your markup if you still use KompoZer. Again,
*I* am the author of the original code of Nvu *and* KompoZer, so I
happen to know a bit about it :-)


</Daniel>

[Greg Chapman]

Hi James,

On 25 Jan 13 03:57 James Holland <jas...@bellsouth.net> said:
> I had thought that BlueGriffon was a wysiwyg web editor.

It is!

> I expect an editor that claims to be wysiwyg to work somewhat like
> Microsoft Word, Open Office or even Kompozer.

It works very much like KompoZer except that it is designed to
implement current best practice coding.

> I like most of the way it works except when it come to sizing fonts.

Sounds like you're used to using KompoZer's toolbar button. Trouble
with that is that it introduces code that was already deprecated back
in the last century - that's over a decade ago now. It is time you
started producing a site that will work on the range of modern devices
that you visitors might be using to access your site.

Greg Chapman
http://www.gregtutor.plus.com
Helping new users of KompoZer and The GIMP
Still exploring BlueGriffon

[Marc Sabatella]

On Jan 24, 2013, at 8:57 PM, James Holland <jas...@bellsouth.net> wrote:

> I had thought that BlueGriffon was a wysiwyg web editor. I expect an
> editor that claims to be wysiwyg to work
> somewhat like Microsoft Word, Open Office or even Kompozer

As Daniel mentions, mentioning Kompozer here is ironic. But anyhow, you simply must understand that the difference between Word and Office one hand and BG on the other is that the former are tools that are intended to produce results on *physical paper* in which everything has a specific *physical size* that will nit ever change once you print the document, whereas BG is a tool for producing results that are to be displayed on *web pages* which might be viewed on any of a zillion different screen sizes, with any of a zillion different user resolution settings. So font sizing is just inherently different affair, and it is an enormous mistake to try designing for the web as if you were designing for a printed document.

Which is to say, almost anything you might be trying to do to access font sizes directly is the *wrong* thing to do when designing for the web, which is why web standards have developed to discourage people from even trying. Whatever it is you are trying to accomplish with direct font size control might look good on your screen but terrible on someone else's. There are reasons that web standards call for different approaches to be used.

So why switch to another tool that makes it easier to create a *terribly designed* web page? Instead, you should be focused on creating *properly designed* web pages, and tools that make this easier. And I suspect you'll find BG makes creating properly designed web pages easier than ay of the other tools you mentioned.

Marc

[Marc Sabatella]

On Jan 25, 2013, at 4:19 AM, Greg Chapman <greg...@yahoo.co.uk> wrote:

> Hi James,
>
> On 25 Jan 13 03:57 James Holland <jas...@bellsouth.net> said:
>> I had thought that BlueGriffon was a wysiwyg web editor.
>
> It is!

Actually, as I think about it, it occurs to me that the whole notion of WYSIWYG is flawed when it comes to the web. For tools designed to produce printed output, WYSIWYG makes sense, because no matter what kind of system the designer is using, we will all see the same printed result. That's true even if you output to PDF instead of physical paper, because PDF is still completely tied to specific sizes. So it really can be not just "what you see is what *you* get", but "what you see is what *everyone* gets" - just as we would hope.

But for web design, the best one could say is that a tool is "what you see is what *you* get, but everyone else may see something different, because they may have a different screen size or resolution or browser settings than you". In fact, *you* might get something different the next time *you* look at the same page, if you do so in a different browser or on a different device.

Bottom line, relying on what you see at any given moment as your way of designing a web page just plain does not work. You simply have to accept that what *you* see is not necessarily what anyone else will see. So you need to design for that, and that's why the whole notion of WYSIWYG is kind of flawed with regard to web design tools. What *you* see is just not all that relevant except as a quick saity check that you aren't doing something *completely* stupid.

Don't get me wrong - it's not that tools like BG are a bad idea. But expecting what they show you on screen to be an accurate representation of what any other human being on earth will see is not reasonable. You simply must have other standards in mind besides what *you* see.

I have to laugh sometimes when I read about "responsive design" - building a site that works well on different devices. Back in "bad old days" of original-recipe HTML (early 90's), this would have been taken for granted. *All* designs would have been reasonably responsive, because no one relied on fixed width layouts - they weren't even possible. Tim Berners-Lee had the sense to anticipate this, but I wonder how we let ourselves stray so far from that ideal?

Marc

[James C. Holland]

On 01/25/2013 10:32 AM, Marc Sabatella wrote:
> On Jan 24, 2013, at 8:57 PM, James Holland <jas...@bellsouth.net> wrote:

Marc
Thank you and others for responding to my concern.
I will be eighty years old on my next birthday. I was in a
conference (National Computer Conference) in Dallas, Texas,
in the late 1970's, with Steve Jobs and Woz. Bill Gates and Paul Allen
were there. (they were trying to sell Microsoft Basic) I had put
together a computer system, that I was selling to machine shops, using
the S100 buss that Dr. Ed Roberts developed for the Altair. There wasn't
much software available. I had written a simple word processor in
machine language, I didn't even have an assembler, but the word
processor worked as intended. None of us knew much about the proper way
to write (code) software. We operated on the principle, the proof of the
pudding is in the tasting, not in the formating of the receipt. We
produce a local online newspaper that is intended to cover three
counties in Middle Georgia (US). The total intent of the newspaper is to
convey information. The content person is very familiar with word
processors, but, as with most of our readers, knows nothing about HTML.
We test our stuff on 4 browsers, and mirror it on three different
hosting providers. We test it on laptops, notepads, Ipads and desktop
screens. People read our stuff and they are buying advertising. The code
may make programmers laugh, but for us it works.I use BlueGriffon in
some fashion every day and am trying to "do webs" its way, but I may not
get there before I die. All I have said may not be proper here, but
please forgive me. I do appreciate all those people who work hard at
providing us with open source software. All our computers use my special
make of Lubuntu 12.10, and the only software that I pay for is the
addon's from the BlueGriffon folks, and Windows 8 on one laptop.

James C. Holland

[Daniel Glazman]

On 25/01/13 17:44, James C. Holland wrote:

> All our computers use my special
> make of Lubuntu 12.10, and the only software that I pay for is the
> addon's from the BlueGriffon folks, and Windows 8 on one laptop.

Thank you James.

</Daniel>, BlueGriffon's author
--
Disruptive Innovations, CEO
W3C CSS Working Group, co-chairman
Invited Expert to IDPF

[Joeg]

Keeping content and style separate is the way to go. As a professional web designer, I have always worked to a brief that established who the target audience were and what they would be viewing the pages on. It is not necessary to design for every possible situation but you do have to satisfy the design brief and reach the target audience. Yes, with all the mobile devices around these days, it is becoming increasingly difficult to satisfy everyone unless you use the most basic, plain vanilla design. That would lead for a very dull web and a lot of missed opportunities. I check the pages I design in browsers from IE6 up and in Firefox, Chrome and Safari on Mac and PC and Ubuntu where available. Also on an iPad and iPhone. They don't have to look pixel-perfect identical. They just have to work acceptably. What you see in Firefox 18 is NOT what you get in IE6 but if a significant number of viewers are using IE6 (server stats are your best friends here) it just won't do if your pages fall apart - and they don't have to. A disproportionate amount of time is spent getting web sites to work in older versions of IE that are gradually dying out - but not fast enough!