Hi. Just an idea for a convenience hack: How about an <update> tag?

When updating a node, one would only add the new text between <update> tags and the PM-Script-o-Matic would render the content as demonstrated below. Even the time of an update could be entered automatically - if that is considered useful. The examples below display the timestamp as a tool-tip, but it shouldn't be too difficult to make a timestamp more prominent, i.e. by means of the same mechanism that is used to show/hide Monk levels (.attribution-title).
Additionally, I also changed the demo-styles for <ins> (markup for inserted text) and <del> (markup for deleted text) that can be used independently from the <update> tag but also belong to the change marks category.

Pros:

Cons:

I.e., entering this ... 

<update>
  Some new paragraphs.
</update>

<update>Some new inline text.</update>
... will be expanded into this: 
<div class="update-block" title="Mar 01, 2009 at 16:20 CET">
    <div class="update-tag">Update</div>
    <div class="update-body">
      Some new paragraphs.
    </div>
</div>

<span class="update-inline" title="Mar 01, 2009 at 16:20 CET">
    <span class="update-tag">Update:</span> 
    Some new inline text.
</span>
So much for the HTML translation. Fortunately, the PM themes cannot be overruled easily, but unfortunately this means that you need to append the lines below to your personal CSS configuration if you like to see the rendered output. The style definitions should not conflict with existing or future themes (although they might cause eye damage). The styles below provide some examples suitable for PM themes with a light background (preferably Perl-Blue). A real style would have four or five lines only (.update-[block|inline|tag|body|stamp]). I hope not to have broken too many CSS/HTML/Latin rules ;-)

Thanks.

Update
Clarification/Summary: The <update> tag was intended to visualise a significant change of a node if the author decides so. At the same time, the reader shall have an opportunity to render this update according to his/her needs. It was not intended to replace or wrap any <ins> / <del> tags in <update> blocks. Longer explanation...

Examples

(*) Important: In order to see (or tweak) these demo-layout variants, you must find the «On-Site CSS Markup» - section in your personal Display Settings and temporarily append the following lines: 
/* UPDATE (document -> update-block -> update-tag -> update-body)*/
/* Sample CSS suitable for PM themes with light background,
   e.g. "Perl-Blue Theme" (my default) or "Red Theme". 
  "Dark" themes need further tweaking. 
*/

/* Update-Variant 1: sparse markup */
.del1          { color: #888;         text-decoration: line-through; }
.ins1          { color: #006;         text-decoration: none; }
.update-block1 { margin: 0.5em 0.5em; text-align: left; }
.update-inline1{ margin: 0.5em 0.5em; text-align: left; }
.update-tag1   { text-indent: 0.2em;  font-weight: bold; } 
.update-body1  { margin: 0em 0em 0em 2em; }

/* Update-Variant 2: moderate / invisible deletions */
.del2          { display: none; }
.ins2          { color: #006;         text-decoration: none; }
.update-block2 { margin: 0.5em 0.5em; text-align: left; }
.update-inline2{ margin: 0.5em 0.5em; text-align: left;
                 font-style: italic;}
.update-tag2   { text-indent: 0.2em;  font-weight: bold; } 
.update-body2  { margin:0em 0em 0em 2em; }
 
/* Update-Variant 3: plz hurt my eyes (nice with: Perl Blue Theme) */
.del3          { color: #888;         text-decoration: line-through; }
.ins3          { color: #00a;         text-decoration: none; }
.update-block3 { margin: 0.5em 0em 0.5em; text-align: left; 
                 background: #eeeeff;     border: 1px solid #069; }
.update-inline3{ margin: 0.5em 0em 0.5em; text-align: left; 
                 background: #eeeeff;     border: 1px solid #069; }
.update-tag3   { text-indent: 0.2em;      font-weight: bold; 
                 background: #069;        color:#fff; 
                 font-variant: small-caps; } 
.update-body3  { margin: 0em 0em 0em 2em; }
/* in case the 'title' attribute is removed from '<div>' tags: */
.update-stamp3 { font-size: smaller; font-variant: normal; }
/* ------------------------------------------------------------- */

[download]

Variant 0: No CSS changes

... Aenean commodo ligula eget dolor. Update: Perlum rulec! Nullam quis ante.
Update
Aenean massa. Cum sociis rubium perlum penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Nullam dictum felis eu pede mollis pretium. Cras dapibus.
Integer rhoncus tincidunt. ...

Variant 1 - Moderate Markup (*)

... Aenean commodo ligula eget dolor. Update: Perlum rulec! Nullam quis ante.
Update
Aenean massa. Cum sociis rubium perlum penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Nullam dictum felis eu pede mollis pretium. Cras dapibus.
Integer rhoncus tincidunt. ...

Variant 2 - Moderate Markup / invisible deletions (*)

... Aenean commodo ligula eget dolor. Update: Perlum rulec! Nullam quis ante.
Update
Aenean massa. Cum sociis rubium perlum penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Nullam dictum felis eu pede mollis pretium. Cras dapibus.
Integer rhoncus tincidunt. ...

Variant 3 - Heavy Markup (*)

... Aenean commodo ligula eget dolor. Update: Perlum rulec! Nullam quis ante.
Update
Aenean massa. Cum sociis rubium perlum penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Nullam dictum felis eu pede mollis pretium. Cras dapibus.
Integer rhoncus tincidunt. ...

Variant 4 - Heavy Markup with 'title' Workaround (*)

... Aenean commodo ligula eget dolor. Update: Perlum rulec! Nullam quis ante.
Update (Mar 01, 2009 at 16:20 CET)
Aenean massa. Cum sociis rubium perlum penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim. Nullam dictum felis eu pede mollis pretium. Cras dapibus.
Integer rhoncus tincidunt. ...

Tested under Linux with Opera 9.63, Firefox 3.0.6, and Konqueror 4.1.3 - but it should work with all modern browser/OS combinations.

Replies are listed 'Best First'.
Re: Suggestion for a new tag: <update>
by CountZero (Bishop) on Mar 01, 2009 at 19:44 UTC
    I regularly use the <ins> ... </ins> and <del> ... </del> tags to show updates and that suits me fine. An <update> tag would be duplicating the same functionality. Adding a timestamp does not add anything useful for me, but YMMV.

    Update: Added <del> tags. Thanks JavaFan!

    CountZero

    A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James

[reply]
[d/l]
[select]
Re: Suggestion for a new tag: <update>
by Perlbotics (Archbishop) on Mar 02, 2009 at 19:53 UTC

    Hi. Thanks to all above for your feedback. I guess, I have to clarify the motivation a little bit...

    The main intention was to make significant updates visible by authors and customisable by readers.
    It was not my intention

    • to replace the <del>-tag (deleted text) or <ins>-tag (inserted text) by <update> - they are good as they are now (although, I used <u> / <em> and <strike> in the past not knowing it better)
    • to wrap sections that contain change marks into an <update>-block - it would be too noisy, especially when inlined (<span>)
    • to emulate a change mark system as known by some Word processors
    Admittedly, using <del> and <ins> inside the examples for <update> markup might have lead to that conclusion. Here, the intention was to demonstrate that there is no interference when using them intermixed.

    My main observation was, that there are typically two kind of updates. First, editorial changes (grammar, spelling, formatting) and second, content changes (corrections of errors, background information added, etc.). It seems to be common understanding that an updated node is marked (usually at the end of the contribution) with the Update: keyword and some additional text. After this visual marker, some authors describe editorial changes, but most authors add significant information to the node, both activities reveal that the authors care about what they have written (quality). So it might be worth for a reader to re-visit such a node.

    Thus, updating a node is also a kind of asynchronous communication between the author and the reader. I thought, it would be useful that an author can <update> a node and thus say I consider this update a significant content-change. The reader at the other end of the communication channel might say I don't care. Don't bother me. (no special markup of <update>'d sections / site-default). But another reader might say Please make <update>'s prominent, so I can immediately see them while skimming through the nodes. (e.g. by specifying a private CSS style for such content). Using markup to identify such a section can serve authors as well as readers while making the new content accessible for tools.
    Multiple updates could be enumerated manually by using <ol> / <li> inside the <update> block... so there will be usually only a single instance of <update> present .oO(...consecutive update blocks might be merged and enumerated automatically...).

    Example: A possible use of a tool might be to add a marker (again: the reader can decide - as with Monk levels - if (s)he wants to see them) to the entries of Recently Active Threads. The (first N characters) of <update> could be inlined or made visible by tool-tips. A page with significantly changed (SoPW only?) nodes could be created - like we already have for Recently Updated Home Nodes.
    The PM engine knows that there was an update because the <update> tag was found but maybe the same thing can be achieved by adding a checkbutton significant update close to the Update! button?
    Maybe a tag could be added to indicate an insignificant editorial change (though appreciated) like so <update type="edit"> or with an alias <edit> hiding the change from being detected by the tools - but that might be more complicated than intended first? ...arrgh - creativity overflow...

    As said in the OP, it's just a suggestion. If it is considered useless, that's fine with me - but it was hard to tell in advance.

    Thanks again for you feedback.

[reply]
[d/l]
[select]

      While your proposal would give authors a way to mark major updates, I don't think they would solve the communication problem, for two reasons:

      • The user may not want to use special tags: some people have enough trouble just mastering paragraph and code tags. The net result is that many significant updates, especially by beginners, will not get marked.
      • I don't generally go back and read threads until a new node is posted on the thread, so I may never be on the thread to see the specially highlighted update.

      What would help me would be a node equivalent to what we have now for major and minor updates to user pages:

      • an easy way for the author to self-nominate their change as a 'significant change', for example, by having an update and major update buttons (instead of the one button that now exists).
      • an option to see major updates flagged on either (or both) "Newest nodes" or "Recent Threads".

      Best, beth

[reply]
        I don't generally go back and read threads until a new node is posted on the thread

        Neither do I. That's why I never bother to put the word 'update' in my node, or make my node harder to read by inserting strike throughs. If I update my node it's either to fix spelling, grammar or markup mistakes, or to add or clarify a missing or unclear issue - but the latter I only do immediately after posting.

        In all other cases, I just followup to myself. It's easier for me, and people following the thread see an update was made. And the original is still there.

[reply]
Re: Suggestion for a new tag: <update>
by JavaFan (Canon) on Mar 01, 2009 at 22:59 UTC
    Two questions:
    • How does one markup deletions of text?
    • Why require anyone to actually type <update>? If this is the greatest thing since sliced bread (which I do not think, I'm quite happy with the way things are), surely someone will be able to come up with a little program written in a language suitable for text manipulation that works out the differences between two pieces of text, and marks them?
[reply]
Re: Suggestion for a new tag: <update>
by salazar (Scribe) on Mar 02, 2009 at 14:44 UTC
    id amo, sed non cogito requirere
    (i like it, but i don't think that i need it)

    I just don't know if it's useful enough to merit all of the work involved, when there are plenty of other options. I mean, it's not hard to do something like:

    Update, 9:30 AM EST:
    blah blah blah
[reply]

Back to Perl Monks Discussion