Any better Kompozers out there?

[Ivan Shmakov]

[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

[Marko Rauhamaa]

Post by Ivan Shmakov
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.

Post by Ivan Shmakov
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]

Post by Marko Rauhamaa

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.

Post by Marko Rauhamaa
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.

Post by Marko Rauhamaa
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.

Post by Marko Rauhamaa
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/

Post by Marko Rauhamaa

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.

Post by Marko Rauhamaa
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]

Post by Ivan Shmakov

Post by Marko Rauhamaa
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]

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

Post by Marko Rauhamaa
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."

[ray carter]

Post by Marko Rauhamaa

Post by Ivan Shmakov

Post by Marko Rauhamaa
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

Post by Marko Rauhamaa

Post by Ivan Shmakov
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

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

[Thomas 'PointedEars' Lahn]

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.

Post by Ivan Shmakov

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