Re: Any better Kompozers out there?

[Ivan Shmakov]

>>>>> T <T...@invalid.invalid> writes:

[Cross-posting to news:comp.infosystems.www.authoring.html, as
the question doesn't seem to be specific to GNU/Linux. On a
second thought, adding news:comp.emacs as well; but feel free to
drop that as appropriate.]

> I have been using Kompozer to edit html pages. It is a bit awkward
> and buggy. I am going to be doing a lot more editing in the future.
> Does anyone have a favorite html editor? A better Kompozer?

As already suggested, it doesn't actually make much sense to use
a "visual" ("WYSIWYG") editor to edit decidedly /non/-visual
medium, such as HTML. This is contrary to, say, W3C-standard SVG,
or ISO-standard PDF, which /are/ visual, and which it /does/ make
sense to author "visually" (such as with Inkscape, SVG-edit,
Scribus, or many other such tools.)

Think, for example, of how your HTML document would be rendered
by a speech synthesizer to a visually impaired person. Most,
if not all, of the "common" CSS properties will be of no value,
and if the document in question relies on div, span, and class=
-- rather than the full repertoire of HTML5 elements -- the best
that the speech synthesizer will be able to rely upon would
probably be good old heuristics.

My preference is to use Emacs nxml-mode to edit "XHTML," mainly
for its support for real-time validation, based on the RNG
schemata included in Emacs. It should be noted, however, that
Emacs includes XHTML 1.1 [1] RNG schema where one would expect
HTML5/XML instead. (That's Emacs bug#12280 [2] -- and I'd very
much appreciate thoughts on how to include /both/ and let the
user choose.)

It's still possible to configure Emacs to use HTML5 RNG acquired
separately.

I'd also like to note that it's possible, although with certain
restrictions (mainly related to "void" elements, <style />,
<script />, <noscript />, and CDATA handling) to author valid
HTML5/HTML documents that are /at the same time/ valid HTML5/XML
documents. As such, nxml-mode is still useful for HTML5/HTML.

[1] http://w3.org/TR/xhtml-modularization/
[2] http://debbugs.gnu.org/12280

--
FSF associate member #7257 http://softwarefreedomday.org/ 16th September 2017

[Marko Rauhamaa]

Ivan Shmakov <iv...@siamics.net>:

> As already suggested, it doesn't actually make much sense to use
> a "visual" ("WYSIWYG") editor to edit decidedly /non/-visual
> medium, such as HTML.

Or such as plain text. HTML is just one kind of markup language. But
apart from Usenet postings, there is barely any text that doesn't
require markup.

In fact, even Usenet postings employ markup. GNUS displays *emphasized*
words in boldface and turns :-) into a happy face image.

> This is contrary to, say, W3C-standard SVG,
> or ISO-standard PDF, which /are/ visual, and which it /does/ make
> sense to author "visually" (such as with Inkscape, SVG-edit,
> Scribus, or many other such tools.)

I wonder. You need the markup/metainfo to edit any of those formats
meaningfully.

Even Gimp prefers to store images in the XCF format to preserve some of
the needed metainformation.


Marko

[Ivan Shmakov]

>>>>> Marko Rauhamaa <ma...@pacujo.net> writes:
>>>>> Ivan Shmakov <iv...@siamics.net>:

>> As already suggested, it doesn't actually make much sense to use a
>> "visual" ("WYSIWYG") editor to edit decidedly /non/-visual medium,
>> such as HTML.

> Or such as plain text.

I'd rate "plain text" much higher on the "visuality" scale than
HTML. For instance, turning HTML <p />s into blocks of
TAB-indented wrapped lines is a well-defined procedure (or could
be one if one bothers); the reverse has to rely on heuristics.

> HTML is just one kind of markup language. But apart from Usenet
> postings, there is barely any text that doesn't require markup.

That's debatable.

> In fact, even Usenet postings employ markup. GNUS displays
> *emphasized* words in boldface

Which, incidentally, is the reason /I/ use slashes instead.
IMO, boldface is rarely an appropriate presentation for "inline"
emphasis, and should be reserved for the headings, etc.

> and turns :-) into a happy face image.

Never in my configurations; along the lines of [1].

(And while we're at it, also [2].)

[1] Informal typography
URI: http://mandership.com/135/
[2] Bold or italics?
URI: http://mandership.com/79/

>> This is contrary to, say, W3C-standard SVG, or ISO-standard PDF,
>> which /are/ visual, and which it /does/ make sense to author
>> "visually" (such as with Inkscape, SVG-edit, Scribus, or many other
>> such tools.)

> I wonder. You need the markup/metainfo to edit any of those formats
> meaningfully.

Indeed, Inkscape leaves a lot of its own metadata in SVG by
default (thanks to the XML "extensibility"), and Scribus uses an
entirely separate "authoring" format.

> Even Gimp prefers to store images in the XCF format to preserve some
> of the needed metainformation.

AIUI, Gimp uses XCF mainly for its losslessness and the support
for multiple layers. (And their respective metadata, right.)

[Marko Rauhamaa]

Ivan Shmakov <iv...@siamics.net>:

>>>>>> Marko Rauhamaa <ma...@pacujo.net> writes:
> > Even Gimp prefers to store images in the XCF format to preserve some
> > of the needed metainformation.
>
> AIUI, Gimp uses XCF mainly for its losslessness and the support
> for multiple layers. (And their respective metadata, right.)

Layers *are* metadata. IOW, you can't derive layers from the visual
output. So even Gimp prefers not to be fully WYSIWYG.


Marko

[Ivan Shmakov]

>>>>> Marko Rauhamaa <ma...@pacujo.net> writes:
>>>>> Ivan Shmakov <iv...@siamics.net>:
>>>>> Marko Rauhamaa <ma...@pacujo.net> writes:

[Dropping news:comp.emacs from Followup-To: as no longer
relevant.]

>>> Even Gimp prefers to store images in the XCF format to preserve
>>> some of the needed metainformation.

>> AIUI, Gimp uses XCF mainly for its losslessness and the support for
>> multiple layers. (And their respective metadata, right.)

> Layers *are* metadata. IOW, you can't derive layers from the visual
> output.

Isn't that just a matter of terminology?

To me, "layers" are just separate images which Gimp allows me to
save into a single file for convenience -- much like I can keep
a bunch of RGBAs in a .tar archive.

Metadata is how these individual images are composed together to
get the desired result.

And BTW, this metadata /can/ be manipulated "visually."

> So even Gimp prefers not to be fully WYSIWYG.

That's somewhat of a stretch. No WYSIWYG tool I can think of is
"strictly" WYSIWYG. FWIW, modern word processors provide support
for "stylesheets" and an option of displaying "control codes."

[Marko Rauhamaa]

Ivan Shmakov <iv...@siamics.net>:

>>>>>> Marko Rauhamaa <ma...@pacujo.net> writes:
>
> No WYSIWYG tool I can think of is "strictly" WYSIWYG. FWIW,
> modern word processors provide support for "stylesheets" and an
> option of displaying "control codes."

Incidentally, very few users of word processors know how to work with
styles. Most people just keep on pressing the space bar and enter until
it looks about right.


Marko

[Thomas 'PointedEars' Lahn]

Ivan Shmakov wrote:

>>>>>> T <T...@invalid.invalid> writes:

That is not a proper attribution line. The number of leading “>” characters
are to indicate the quotation level. Therefore, a *new* attribution line
ought to have *no* leading “>” characters *at all*. See above.

> > I have been using Kompozer to edit html pages. It is a bit awkward
> > and buggy. I am going to be doing a lot more editing in the future.
> > Does anyone have a favorite html editor? A better Kompozer?
>
> As already suggested, it doesn't actually make much sense to use
> a "visual" ("WYSIWYG") editor to edit decidedly /non/-visual
> medium, such as HTML.

Utter nonsense. HTML is _not_ a “decidedly /non/-visual medium”. It is not
even a medium.

Instead, HTML is a *markup language* that is medium-*agnostic*. Therefore,
when editing HTML using a visual editor, which of itself is *perfectly OK*,
one has to keep in mind that the used presentation is only one possible way.
Therefore, the term “WYSIWYG editor” for such a software is ill-advised.

However, difficulties may arise from the fact that parent and child elements
may not be easily discernible if their borders overlap. Therefore, any
sensible visual editor should provide both visual editing and source code
editing, or allow to switch between assisted editing, in which container
borders never overlap, and original display.

It is also easier to create tag soup and, in general, bloat code with a
badly designed (and badly used) visual editor than with a source code
editor, as evidenced by Web sites created with the likes of FrontPage and
Dreamweaver.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

[ray carter]

In practice, nothing is WYSIWYG it's really more like "What You Get Is No
Surprise".