preview in browser
477 views
Skip to first unread message
Roedy Green
Jun 14, 2014, 4:48:08 AM6/14/14
to blueg...@googlegroups.com
Thanks Greg. That tip worked just fine.
I have added it to my list of tips, bugs and feature requests
at http://mindprod.com/jgloss/bluegriffon.html
I have added it to my list of tips, bugs and feature requests
at http://mindprod.com/jgloss/bluegriffon.html
-- Roedy Green, pronounced RHOdee click attached vCard (Rolodex icon) for contact details
Alex Paton
Jun 17, 2014, 10:12:38 AM6/17/14
to blueg...@googlegroups.com
Roedy
I just read your page there, and I probably would have agreed with you a year and a half ago. However, after a conversation on here with Greg, some while ago, I disagree wholeheartedly, but in a nice way; the program hasn't changed hugely in that time, but my perspective has. Once I got into the habit of using the ID & Class Dropdowns correctly, and got into the habit of using the tag navigation at the bottom, I barely need to delve into code any more. The only area where a new HTML user would need to know anything about tags would be in the setting up of DIVs and in the use of the tag navigation.
In my opinion, what BlueGriffon does best is WYSIWYG web editing for people who don't know, don't want to know or don't care what HTML code is. If the program is used from that viewpoint, stubbornly refusing to use source mode, and accepting the code that the program produces, it works remarkably well. Let's be honest, those of us who are used to hand coding a lot often stick to that way of doing things, regardless of whether it is right or not.
Since I had such a shift in thinking, the only areas where I go in to edit the code is in removing some of the inline styles, and transferring them to an external style sheet, plus of course any php/javascript.
There are a few things that are not true on your page, or out of date:-
I just read your page there, and I probably would have agreed with you a year and a half ago. However, after a conversation on here with Greg, some while ago, I disagree wholeheartedly, but in a nice way; the program hasn't changed hugely in that time, but my perspective has. Once I got into the habit of using the ID & Class Dropdowns correctly, and got into the habit of using the tag navigation at the bottom, I barely need to delve into code any more. The only area where a new HTML user would need to know anything about tags would be in the setting up of DIVs and in the use of the tag navigation.
In my opinion, what BlueGriffon does best is WYSIWYG web editing for people who don't know, don't want to know or don't care what HTML code is. If the program is used from that viewpoint, stubbornly refusing to use source mode, and accepting the code that the program produces, it works remarkably well. Let's be honest, those of us who are used to hand coding a lot often stick to that way of doing things, regardless of whether it is right or not.
Since I had such a shift in thinking, the only areas where I go in to edit the code is in removing some of the inline styles, and transferring them to an external style sheet, plus of course any php/javascript.
There are a few things that are not true on your page, or out of date:-
Tagging with span classes is awkward. It takes five steps. It could be reduced to a select plus one click for common, recently used or user-selected classes with configurable toolbar icons.
Tagging: Select the text-> Click on drop down next to < > then click on span
Classes: There is a drop down box for classes, which also lets you create new classes and apply them to the currently selected tag. There is no option for recently used though.
Classes: There is a drop down box for classes, which also lets you create new classes and apply them to the currently selected tag. There is no option for recently used though.
Often as not, in assigns the class to the enclosing paragraph rather than the selected span of text.
Errrm, no it isn't. You are not using the tag navigation at the bottom correctly. It applies the class to whichever tag is selected there.
Alex
Ctrl-Z usually does not work
It doesn't seem to work in Source view, but works OK (generally) in WYSIWYG.
When you bold, you would expect <b> or <strong> tags to appear. Instead long-winded inline styles appear like <span style="font-weight: bold;">
The Strong and Em tags appear to work fine, whereas Bold works as it should do, given that Bold is a deprecated tag, which has largely been replaced with strong and em.
The way you insert entities is rather tedious. Try copy-paste from elsewhere in the document, especially if you repeatedly paste the same entity.
I suspect that there aren't too many people who do that, but perhaps you should consider the Snippets addon.
After the conversation I referred to with Greg, I made a conscious effort to WYSIWYG my way through a website, and realised that I had been wasting an awful lot of time trying to hammer a square peg into a round hole previously.
After the conversation I referred to with Greg, I made a conscious effort to WYSIWYG my way through a website, and realised that I had been wasting an awful lot of time trying to hammer a square peg into a round hole previously.
Alex
Greg Chapman
Jun 17, 2014, 9:06:58 PM6/17/14
to blueg...@googlegroups.com
Hi Roedy,
I am not sure I deserve the credit that Alex gives me, but I'll return
his compliment by saying I agree with his comments on your critique of
BlueGriffon at:
http://mindprod.com/jgloss/bluegriffon.html
At first I found some of your comments a little strange, but then I
loaded your page in BlueGriffon and realised that you are not the kind
of coder that I would expect to turn to BlueGriffon and, and your
position is that of an "extreme" coder, rather than that of a more
conventional WYSIWYG user.
For example, this is the first time I have encountered a page in which
just two linked stylesheets include around 1,000 class definitions (I
gave up counting when I got to 100!), yet there's not a single ID. You
clearly know your HTML and CSS, but having such a huge "library"
classes in a single stylesheet can't be best practice coding
technique. All the redundant ones should be stripped out only a short
relevant stylesheet for the page being edited retained.
That alone would get rid of the need for one of your and feature
requests about "recently used classes".
On 17 Jun 14 15:12 Alex Paton <lotapro...@gmail.com> said:
> Once I got into the habit of using the ID & Class Dropdowns
> correctly, and got into the habit of using the tag navigation at the
> bottom, I barely need to delve into code any more.
BlueGriffon is not designed for coders who who have their own views on
how code should look. You need to turn to other tools if you want that
function, so Alex is right when he says you really shouldn't need to
visit code that often.
It also makes this tip of yours redundant:
> Keep having a look at source mode to make sure the markup generated
> is what you expect.
One reason for you constantly needing to examine the code appears to
be your use of <span>s. You say:
> It, often as not, ignores me when I click format ⇒ span.
Perhaps that's because you have not got any content selected, or what
is selected crosses tag boundaries so introducing a span there would
be illegal. Inaccurate selection could also be the reason for your
complaint about the enclosing paragraph getting the class.
Of course if you have reached a position where you have empty span
tags in your code then it becomes very easy to make a selection with
the mouse that causes this problem. The most appropriate techique for
making inline selections is with the keyboard. However, in most cases
I would expect one to want to select a tag and its contents. In that
case the Structure bar is where you should click to select.
> When I examine the source, I see all manner of stray <spans.
It is true that BlueGriffon can be reluctant to delete tags when you
delete all content inside them. Generally the solution is in the
structure bar. If you are going to delete all content in a tag then
select the tag on the structure bar, hit delete, and the tag and
content will be gone. (In the case of block tags these may be replaced
with a <br> :-( )
I must admit to curiosity about your prolific use of span. This is
supposed to be used for non-specific inline style changes, but in
almost every case on your page there are more appropriate tags to use,
such as <strong>, <em> <dfn>, <abbr> and several more.
> Ctrl-Z usually does not work
>
> It doesn't seem to work in Source view, but works OK (generally) in
> WYSIWYG.
Alex is right and that's fully understandable given the underlying
design principle of the program. It is WYSIWYG editor that is designed
to generate code that conforms to all appropriate standards. However,
mess with its output, i.e. edit source code, and it has to check its
compliance with standards before it returns to WYSIWYG mode, otherwise
your code could stop it working as designed and totally crash the
program.
You complain about the programs speed of response when checking edits
to the code in long documents, and that it will adjust your edits to
do things its way and that it sometimes loses your content. This is
the very reason why I say it's not designed for hand coders. And
that's not just my view. The program's author makes it clear as well!
> > When you bold, you would expect <b> or <strong> tags to appear.
> > Instead long-winded inline styles appear like <span
> > style="font-weight: bold;">
That sounds like another case of your unusual code and poor selection
technique. Whenever I select a word to be made bold, I double-click on
it to select it and hit CTRL-B and the code generated is a <strong>
tag. If I have a phrase to embolden after selecting the initial word I
use CTRL-SHIFT-CURSORRIGHT to extends the selction before the CTRL-B.
Always works for me!
There are some other comments which I find very strange:
> I still have not figured out how to surround some text in <h2>…</h2>
> in WYSIWYG mode. Whenever I try, it erases the text.
I can't imagine what you are doing. Most typically, I would have been
typing a paragraph before getting to the heading. After hitting the CR
key at the end of that paragraph to generate the next one (You haven't
removed the default setting "Return key in a paraggraph always creates
a new paragraph setting", have you?) then I go to the paragraph
formatting drop down and select the heading I want. On completing that
heading (with a CR) the default is to make the next block a paragraph.
It couldn't be simpler.
Alternatively, if I have forgotten to make that one line paragraph a
heading and later decide that it needs to be one, I just place my
cursor within the paragraph, click on the paragraph formatting drop
down and choose the heading tag I need.
I guess your problem may be another case of making a selection with
the mouse that spans tags inappropriately.
There are other things on your page I don't fully understand.
You say:
> If I insert text into a <dd>…</dd> block, Blue Griffon splits the
> block in two and inserts my text between the two pieces. This makes
> no sense at all because <dd> must always be paired with <dt>. It
> should just insert the text inside <dd>…</dd>.
First, it only generates a new <dd> block if you hit CR. (I dare say
that is affected by the CR makes a new paragraph setting, but I have
never checked)
Second, there is nothing wrong with multiple <dd> blocks following a
<dt>. Just run a page with this code through the W3C validator:
<body>
<dl>
<dt>Term</dt>
<dd>definition </dd>
<dd>more data</dd>
<dd>yet more data</dd>
</dl>
</body>
On the other hand it will complain if you have no <dd> blocks
following a <dt>.
You say:
> Let me configure a more legible and larger font in source mode, such
> as Pragmata Pro.
I posted about this a while ago...
=========================================================
On 26 Sep 12 01:03 vmars316 <vmar...@gmail.com> said:
> The 'Source code window text' is too small for me to read.
> How Can I make 'Source code Window text' LARGER ?
I'm not an expert and don't know what side effects there might be, but
I did this:
1. Followed this menu route:
Tools > Preferences > Advanced and clicked the "Configuration Editor"
Button
2. Click the warning "I'll be careful, I promise" button.
3. On the dialogue that appears, enter "font.size" (without quotes) in
the search field.
4. Scroll down the list to find the entry:
font.size.fixed.x-unicode
Double-clicked on this and changed the value to 16 in the dialogue
that pops up. Also did the same for:
font.size.fixed.x-western
NOTE: I just guessed at the options that seemed relevant! Once these
values are changed from the default they show in bold, so are easy to
find again.
5. Backed out of all open dialogues.
I found that the new setting did not take effect until I closed and
reloaded the file I was working on.
As I mentioned earlier, I have no idea what other effects changing
these settings have, but they did make the text Source View larger.
=========================================================
Since then I have found that on my system only the setting:
font.size.fixed.x-western
has the effect I wanted on my system and that the following setting
will change the font used:
font.name.monospace.x-western
(I now use Consolas and use the "Light" theme).
Greg Chapman
http://www.gregtutor.plus.com
Helping new users of KompoZer and The GIMP
Still exploring BlueGriffon
I am not sure I deserve the credit that Alex gives me, but I'll return
his compliment by saying I agree with his comments on your critique of
BlueGriffon at:
http://mindprod.com/jgloss/bluegriffon.html
At first I found some of your comments a little strange, but then I
loaded your page in BlueGriffon and realised that you are not the kind
of coder that I would expect to turn to BlueGriffon and, and your
position is that of an "extreme" coder, rather than that of a more
conventional WYSIWYG user.
For example, this is the first time I have encountered a page in which
just two linked stylesheets include around 1,000 class definitions (I
gave up counting when I got to 100!), yet there's not a single ID. You
clearly know your HTML and CSS, but having such a huge "library"
classes in a single stylesheet can't be best practice coding
technique. All the redundant ones should be stripped out only a short
relevant stylesheet for the page being edited retained.
That alone would get rid of the need for one of your and feature
requests about "recently used classes".
On 17 Jun 14 15:12 Alex Paton <lotapro...@gmail.com> said:
> Once I got into the habit of using the ID & Class Dropdowns
> correctly, and got into the habit of using the tag navigation at the
> bottom, I barely need to delve into code any more.
how code should look. You need to turn to other tools if you want that
function, so Alex is right when he says you really shouldn't need to
visit code that often.
It also makes this tip of yours redundant:
> Keep having a look at source mode to make sure the markup generated
> is what you expect.
One reason for you constantly needing to examine the code appears to
be your use of <span>s. You say:
> It, often as not, ignores me when I click format ⇒ span.
Perhaps that's because you have not got any content selected, or what
is selected crosses tag boundaries so introducing a span there would
be illegal. Inaccurate selection could also be the reason for your
complaint about the enclosing paragraph getting the class.
Of course if you have reached a position where you have empty span
tags in your code then it becomes very easy to make a selection with
the mouse that causes this problem. The most appropriate techique for
making inline selections is with the keyboard. However, in most cases
I would expect one to want to select a tag and its contents. In that
case the Structure bar is where you should click to select.
> When I examine the source, I see all manner of stray <spans.
It is true that BlueGriffon can be reluctant to delete tags when you
delete all content inside them. Generally the solution is in the
structure bar. If you are going to delete all content in a tag then
select the tag on the structure bar, hit delete, and the tag and
content will be gone. (In the case of block tags these may be replaced
with a <br> :-( )
I must admit to curiosity about your prolific use of span. This is
supposed to be used for non-specific inline style changes, but in
almost every case on your page there are more appropriate tags to use,
such as <strong>, <em> <dfn>, <abbr> and several more.
> Ctrl-Z usually does not work
>
> It doesn't seem to work in Source view, but works OK (generally) in
> WYSIWYG.
design principle of the program. It is WYSIWYG editor that is designed
to generate code that conforms to all appropriate standards. However,
mess with its output, i.e. edit source code, and it has to check its
compliance with standards before it returns to WYSIWYG mode, otherwise
your code could stop it working as designed and totally crash the
program.
You complain about the programs speed of response when checking edits
to the code in long documents, and that it will adjust your edits to
do things its way and that it sometimes loses your content. This is
the very reason why I say it's not designed for hand coders. And
that's not just my view. The program's author makes it clear as well!
> > When you bold, you would expect <b> or <strong> tags to appear.
> > Instead long-winded inline styles appear like <span
> > style="font-weight: bold;">
technique. Whenever I select a word to be made bold, I double-click on
it to select it and hit CTRL-B and the code generated is a <strong>
tag. If I have a phrase to embolden after selecting the initial word I
use CTRL-SHIFT-CURSORRIGHT to extends the selction before the CTRL-B.
Always works for me!
There are some other comments which I find very strange:
> I still have not figured out how to surround some text in <h2>…</h2>
> in WYSIWYG mode. Whenever I try, it erases the text.
I can't imagine what you are doing. Most typically, I would have been
typing a paragraph before getting to the heading. After hitting the CR
key at the end of that paragraph to generate the next one (You haven't
removed the default setting "Return key in a paraggraph always creates
a new paragraph setting", have you?) then I go to the paragraph
formatting drop down and select the heading I want. On completing that
heading (with a CR) the default is to make the next block a paragraph.
It couldn't be simpler.
Alternatively, if I have forgotten to make that one line paragraph a
heading and later decide that it needs to be one, I just place my
cursor within the paragraph, click on the paragraph formatting drop
down and choose the heading tag I need.
I guess your problem may be another case of making a selection with
the mouse that spans tags inappropriately.
There are other things on your page I don't fully understand.
You say:
> If I insert text into a <dd>…</dd> block, Blue Griffon splits the
> block in two and inserts my text between the two pieces. This makes
> no sense at all because <dd> must always be paired with <dt>. It
> should just insert the text inside <dd>…</dd>.
First, it only generates a new <dd> block if you hit CR. (I dare say
that is affected by the CR makes a new paragraph setting, but I have
never checked)
Second, there is nothing wrong with multiple <dd> blocks following a
<dt>. Just run a page with this code through the W3C validator:
<body>
<dl>
<dt>Term</dt>
<dd>definition </dd>
<dd>more data</dd>
<dd>yet more data</dd>
</dl>
</body>
On the other hand it will complain if you have no <dd> blocks
following a <dt>.
You say:
> Let me configure a more legible and larger font in source mode, such
> as Pragmata Pro.
I posted about this a while ago...
=========================================================
On 26 Sep 12 01:03 vmars316 <vmar...@gmail.com> said:
> The 'Source code window text' is too small for me to read.
> How Can I make 'Source code Window text' LARGER ?
I'm not an expert and don't know what side effects there might be, but
I did this:
1. Followed this menu route:
Tools > Preferences > Advanced and clicked the "Configuration Editor"
Button
2. Click the warning "I'll be careful, I promise" button.
3. On the dialogue that appears, enter "font.size" (without quotes) in
the search field.
4. Scroll down the list to find the entry:
font.size.fixed.x-unicode
Double-clicked on this and changed the value to 16 in the dialogue
that pops up. Also did the same for:
font.size.fixed.x-western
NOTE: I just guessed at the options that seemed relevant! Once these
values are changed from the default they show in bold, so are easy to
find again.
5. Backed out of all open dialogues.
I found that the new setting did not take effect until I closed and
reloaded the file I was working on.
As I mentioned earlier, I have no idea what other effects changing
these settings have, but they did make the text Source View larger.
=========================================================
Since then I have found that on my system only the setting:
font.size.fixed.x-western
has the effect I wanted on my system and that the following setting
will change the font used:
font.name.monospace.x-western
(I now use Consolas and use the "Light" theme).
Greg Chapman
http://www.gregtutor.plus.com
Helping new users of KompoZer and The GIMP
Still exploring BlueGriffon
Reply all
Reply to author
Forward
0 new messages