• Any better Kompozers out there?

    From Ivan Shmakov@21:1/5 to All on Thu Sep 14 17:05:52 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marko Rauhamaa@21:1/5 to All on Thu Sep 14 21:20:31 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    Ivan Shmakov <ivan@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ivan Shmakov@21:1/5 to All on Thu Sep 14 20:12:45 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    Marko Rauhamaa <marko@pacujo.net> writes:
    Ivan Shmakov <ivan@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.)

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ivan Shmakov@21:1/5 to All on Thu Sep 14 20:40:42 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    Marko Rauhamaa <marko@pacujo.net> writes:
    Ivan Shmakov <ivan@siamics.net>:
    Marko Rauhamaa <marko@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."

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marko Rauhamaa@21:1/5 to All on Thu Sep 14 23:22:59 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    Ivan Shmakov <ivan@siamics.net>:

    Marko Rauhamaa <marko@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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas 'PointedEars' Lahn@21:1/5 to Ivan Shmakov on Fri Sep 15 03:28:20 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    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$8300dec7@news.demon.co.uk>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ray carter@21:1/5 to Marko Rauhamaa on Fri Sep 15 02:39:23 2017
    XPost: comp.infosystems.www.authoring.html, comp.os.linux.misc

    On Thu, 14 Sep 2017 23:22:59 +0300, Marko Rauhamaa wrote:

    Ivan Shmakov <ivan@siamics.net>:

    Marko Rauhamaa <marko@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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)