Jump to content

Log Change from HTML to Markdown


NinjaCacher!

Recommended Posts

 

I doubt that. But have a look:

 

Thanks for the link/picture, but I do not need to take a look at that editor as I'm already aware of what

it yields (actually the question I posed arose from experiments of a friend of mine with the editor).

 

It is not fully clear however how the old logs will be handled and also not whether what we will see will be what the online editor provides us with.

Edited by cezanne
Link to comment

If ordered lists will be supported at all, syntax explanation says

'It’s important to note that the actual numbers you use to mark the list

have no effect on the HTML output Markdown produces.' Then one would expect that

 

1. und 2. A

3. und 4. B

5. C

 

and

 

1. und 2. A

8. und 4. B

3. C

 

will be displayed as

 

1. und 2. A

2. und 4. B

3. C

 

***

maybe unwanted side-effects, harmless but beautiless:

* text text * text text *

 

* text text * text text *

* text

 

#2000

Cache #2000

M*A*S*H

gives this:

24256543is.jpg

Link to comment

Rhetorical question: How to prevent usernames in old logs from being altered/garbled, let alone cache names?

 

Will yes_no_maybe and Alter_Fuchs be altered to yesnomaybe and Alter_Fuchs ?

 

Alter_Fuchs and yes_no_maybe to AlterFuchs and yesno_maybe ?

 

*Eisbär* and srina_c and Alter_Fuchs to Eisbär and srinac and Alter_Fuchs ?

Link to comment

Rhetorical question: How to prevent usernames in old logs from being altered/garbled, let alone cache names?

 

Will yes_no_maybe and Alter_Fuchs be altered to yesnomaybe and Alter_Fuchs ?

 

Alter_Fuchs and yes_no_maybe to AlterFuchs and yesno_maybe ?

 

*Eisbär* and srina_c and Alter_Fuchs to Eisbär and srinac and Alter_Fuchs ?

 

We don't really know what flavor of Markdown GS will be using but Github Flavored Markdown will ignore underscores between words. For example,

 

great_cache would be displayed as is, but _great_cache_ would be italicized as great_cache

Link to comment
We don't really know what flavor of Markdown GS will be using ...

While the announcement doesn't state it explicitly, they do link to this page which is in fact the library they will be using. However they will be modifying it slightly to block images, not require a blank line between paragraphs, and possibly other changes.

 

Good to know.

 

I've also come across a site that does bbcode to markdown conversions. For those that have used bbcode to style their logs it might be a useful tool for converting them to Markdown. I haven't looked at the MarkdownDeep site, but as it's open source I wonder how difficult it would be to create something in the site that will transform a log containing html or bbcode to MarkdownDeep syntax.

 

I've only used Markdown (the Github flavor) a few times and have played with a couple of other editors and found the blank line between paragraphs requirement to be annoying.

Edited by NYPaddleCacher
Link to comment

Sorry if I eventually missed that such a suggestion has already been made, as I just flew over the topic.

 

I try hard to write meaningful and good logs (at least if the geocache is worth it) and I used UBB-Code frequently to format them (like size=1 for less important parts, * for lists in challenges, bold for emphasizing, ...).

 

Now I dislike the point that many of my logs will get rendered with ugly markup code in the future, so I think I will convert them log by log (maybe with the help of GSAK, but mostly by hand) - accepting the stupid "log edited on" line.

 

As this would be lot of diligent work, a tool that reduces the work would be desirable. Maybe this could be something like a page with a simple table:

first column: all logs which have UBB, HTML or maybe Markdown (unintended markup) in it

second column: just a view how the log will look like after the conversion

third column: a button to accept automatic conversion and a button to open the editor in a new window to edit the log.

 

Alternatively there could be a wizard which shows log by log - OK, this should be interruptible then so that one could convert portion by portion.

 

I hope that Groundspeak will find a way in supporting the conversion because leaving the cachers alone would be a slap in the face for those who log more than just "TFTC".

Edited by Cachologen
Link to comment

As this would be lot of diligent work, a tool that reduces the work would be desirable.

 

There are various tools available online to do this, such as:

 

html->markdown

http://domchristie.github.io/to-markdown/

 

bbcode->markdown

http://jondum.github.io/BBCode-To-Markdown-Converter/

 

Might be nice for geocaching.com to host something this on a tools page.

Edited by ChileHead
Link to comment

There are various tools available online to do this, such as:

 

html->markdown

http://domchristie.github.io/to-markdown/

 

bbcode->markdown

http://jondum.github.io/BBCode-To-Markdown-Converter/

 

Might be nice for geocaching.com to host something this on a tools page.

 

That's helpful, but, as Cachologen mentioned, we also need a way to identify which logs need to be changed. I've written about 9600 logs. Probably fewer than 1000 of those will require editing, but I really don't want to look through all 9600 to determine which ones do.

Link to comment

#3235

That´s how I start a log, sometimes I add *** for a word from hint or simply to "cover" a dirty word, etc. Does it mean my logs will get formated in the future? Even though I do not want them to be?

 

(As an owner I read logs primarily in e-mail and therefore consider both UBB and HTML for a horrible way to express "delight" over the cache - tags everywhere, text nowhere. Hence this could be an improvement. Yet I hope there will be an option NOT to have the log formated. And old logs should be at least partly automatically transferred - url, colours, bold, and italics shall be easy...)

Link to comment

As this would be lot of diligent work, a tool that reduces the work would be desirable.

 

There are various tools available online to do this, such as:

 

html->markdown

http://domchristie.g...io/to-markdown/

 

bbcode->markdown

http://jondum.github...down-Converter/

 

Might be nice for geocaching.com to host something this on a tools page.

 

The bbcode->markdown converter is pretty hopeless.

Link to comment

Rhetorical question: How to prevent usernames in old logs from being altered/garbled, let alone cache names?

 

Will yes_no_maybe and Alter_Fuchs be altered to yesnomaybe and Alter_Fuchs ?

 

Alter_Fuchs and yes_no_maybe to AlterFuchs and yesno_maybe ?

 

*Eisbär* and srina_c and Alter_Fuchs to Eisbär and srinac and Alter_Fuchs ?

 

I've been updating my partner app using the MarkdownDeep api and it returns as follows:

6cae9e36-c84a-4a09-ad33-fefea228061e.png

 

Link to comment

Rhetorical question: How to prevent usernames in old logs from being altered/garbled, let alone cache names?

 

Will yes_no_maybe and Alter_Fuchs be altered to yesnomaybe and Alter_Fuchs ?

 

Alter_Fuchs and yes_no_maybe to AlterFuchs and yesno_maybe ?

 

*Eisbär* and srina_c and Alter_Fuchs to Eisbär and srinac and Alter_Fuchs ?

I've been updating my partner app using the MarkdownDeep api and it returns as follows:

6cae9e36-c84a-4a09-ad33-fefea228061e.png

...so, it would seem to be ill-advised to apply Markdown rendering to text that wasn't written to be rendered with Markdown?

 

It's looking more and more like they're going to have to render pre-Markdown logs differently from Markdown logs. Doing otherwise will give unexpected and undesirable results, as has been demonstrated in this discussion. Maybe set a boolean isMarkdown flag in the database for each log?

Link to comment

As this would be lot of diligent work, a tool that reduces the work would be desirable.

 

There are various tools available online to do this, such as:

 

html->markdown

http://domchristie.g...io/to-markdown/

 

bbcode->markdown

http://jondum.github...down-Converter/

 

Might be nice for geocaching.com to host something this on a tools page.

 

The bbcode->markdown converter is pretty hopeless.

 

I know. I saw that one as well and thought it could be useful for those that wanted to change logs containing bbcode into markdown.

Link to comment

Rhetorical question: How to prevent usernames in old logs from being altered/garbled, let alone cache names?

 

Will yes_no_maybe and Alter_Fuchs be altered to yesnomaybe and Alter_Fuchs ?

 

Alter_Fuchs and yes_no_maybe to AlterFuchs and yesno_maybe ?

 

*Eisbär* and srina_c and Alter_Fuchs to Eisbär and srinac and Alter_Fuchs ?

 

I've been updating my partner app using the MarkdownDeep api and it returns as follows:

6cae9e36-c84a-4a09-ad33-fefea228061e.png

 

 

There are variants, and they'd be sure to make use of, or adjust, one that as described earlier in the thread ignores _ in the middle of words (just as GS said they'd make sure line breaks are preserved). The code is highly customizeable so if you make use of one version out-of-the-box, then you may not get exactly the results you're looking for.

Link to comment

The code is highly customizeable so if you make use of one version out-of-the-box, then you may not get exactly the results you're looking for.

 

I guess it does not really matter which version they use. It will always be the case that some old logs get corrupted if they interpret all logs as Markdown.

Link to comment

The code is highly customizeable so if you make use of one version out-of-the-box, then you may not get exactly the results you're looking for.

 

I guess it does not really matter which version they use. It will always be the case that some old logs get corrupted if they interpret all logs as Markdown.

 

You keep on mentioning corrupting old logs. According to the original announcement:

 

"After the switch to Markdown, HTML or UBB code will be displayed in all logs, since we will not respect or render the HTML or UBB Code on output."

 

The way I read that is that GS won't change the actual contents of the logs, but it will render any HTML or UBB code as plain text once the change occurs. The logs won't be corrupted but if you want to change the log so that the formatting is retained after the switch you'll have to convert HTML/UBB to Markdown.

 

 

 

Link to comment

The way I read that is that GS won't change the actual contents of the logs, but it will render any HTML or UBB code as plain text once the change occurs. The logs won't be corrupted but if you want to change the log so that the formatting is retained after the switch you'll have to convert HTML/UBB to Markdown.

 

Actually, I did not fully understand what exactly they are planning to do and none of what has been written so far provided any real clarification.

 

How will a log be treated that contains something like

https://www.geocaching.com/seek/log.aspx?LUID=200567aa-2e69-476d-900d-ed8aa35e232b

(just selected an arbitrary link to a log)

Does this turn the log to an html log?

 

If someone would want to make the link still work after the change, would it mean to not being allowed to use usernames like yes_no_maybe in the log?

Link to comment

There are variants, and they'd be sure to make use of, or adjust, one that as described earlier in the thread ignores _ in the middle of words (just as GS said they'd make sure line breaks are preserved). The code is highly customizeable so if you make use of one version out-of-the-box, then you may not get exactly the results you're looking for.

Well, let's hope there's no user named _brad_, since it would be impossible to tell whether that's markdown or not.

 

BBcode and HTML use unlikely character sequences to express formatting to minimize the chances of plain text being mistaken for formatting. One of the downsides of Markdown is that it is specifically designed to make the unformatted text look like a reasonable plain-text message, so it practically begs to have plain text mistaken for unintentional formatting instructions.

 

The way I read that is that GS won't change the actual contents of the logs, but it will render any HTML or UBB code as plain text once the change occurs. The logs won't be corrupted but if you want to change the log so that the formatting is retained after the switch you'll have to convert HTML/UBB to Markdown.

I assume he meant that it would appear to be corrupted when it's displayed as if it were Markdown even those it's not. I don't think anyone's thinking the actual log data in the system would be changed. Indeed, not changing the log data itself is exactly why they've decided not to try any automatic conversion.

Link to comment

Right, and that's what I also took cezanne to be referring to by "corruption":

 

Making all future logs display as Markdown means any plaintext that is not intended to be Markdown will still be interpreted as such. HTML is pretty hard to be 'mistaken' as plaintext, so it wasn't really an issue. But Markdown is intended to be human-readable, which means non-Markdown human readable text could be mistaken by the parser as Markdown, just as the "_brad_" username example would become brad.

 

So... dunno how GS intends to deal with that, apart from adding a toggle on the log form to indicate that Markdown exists in the text and to render it as such (like flagging a listing description as containing HTML*). But that would have to be mirrored anywhere log text can be provided (apps, 3rd party forms, etc). riiight.

 

* Technically, plaintext listing descriptions aren't really treated as plaintext, and HTML descriptions aren't just pumped raw to the browser. If not flagged, the plaintext actually pipes through a different parser which converts it to HTML for the web display (for example, converting line breaks to use the HTML br or p tags) as opposed to when it is flagged as HTML running the text through the sanitizer to verify the content is safe then displaying the result as approved formatted HTML.

 

This same process would have to happen with log text to avoid 'corruption'. "plaintext" (unflagged) logs would get normally converted to html output for web display, and if flagged with Markdown, the log first gets parsed and converted to html then output for web display. If they do the latter for all logs, having no flag either way, then some logs may well appear 'corrupted'.

Edited by thebruce0
Link to comment

Well, let's hope there's no user named _brad_, since it would be impossible to tell whether that's markdown or not.

 

There are a lot of usernames like that. Just on the first page of _a, I see

  • _A&A_
  • _a&v_
  • _A_
  • _a_piano_
  • _a1x_
  • _aabbbbiiee_
  • _aannaa_
  • _AAOS_
  • _abbalicous16_
  • _abby_

 

Then there are usernames like

  • # animal lover (header level 1)
  • * Anna * (unordered list)
  • [a] (link text or reference)
  • __Abe__ (bold)
  • `AleX` (code)

Link to comment

The way I read that is that GS won't change the actual contents of the logs, but it will render any HTML or UBB code as plain text once the change occurs. The logs won't be corrupted but if you want to change the log so that the formatting is retained after the switch you'll have to convert HTML/UBB to Markdown.

 

Actually, I did not fully understand what exactly they are planning to do and none of what has been written so far provided any real clarification.

 

I think that anything anyone writes about what they are planning to do is just going to be speculative until we actually see the implementation. Looking at sites which describe MarkdownDeep might give a reasonable indication but it sounded to me like they're going to make some customizations for the GS implementation. I also suspect that GS didn't go into detail about what they're planning to do as it would be too technical for many users.

 

 

How will a log be treated that contains something like

https://www.geocachi...0d-ed8aa35e232b

(just selected an arbitrary link to a log)

Does this turn the log to an html log?

 

If someone would want to make the link still work after the change, would it mean to not being allowed to use usernames like yes_no_maybe in the log?

 

Since the link you posted is html it sounds like it would just render as text. That means that if you entered something like this into a log:

<a href="http://coord.info/GC30">http://coord.info/GC30</a>

it would render as text. The easiest way to that would be to convert the less-than and greater-than characters into html entities (< >)

 

In order to display that link to the caching listing for Mingo (as I displayed above) I had to wrap the whole thing in a bbcode code tag. Markdown has a similar method of "escaping" Markdown. If I want _Brad_ to appear as a username, putting back ticks around it ( `_Brad_` ) would tell Markdown to treat everything in between the back ticks as plain text. I haven't looked at the WYSIWYG editor for MarkdownDeep but it could be as easy as highlighting _Brad_ and clicking on a button labeled Code. I explained in an earlier post how one version of Markdown will treat a string with embedded underscores as plain text (e.g. yes_no_maybe) as long as there isn't an underscore at both ends. I don't know of the GS version will do that but typing in `yes_no_maybe` would have the same effect.

 

It will probably take some time to get used to Markdown, but the learning curve is probably *much* less than learning how to style text in a log with HTML or bbcode...especially, if GS provides a WYSIWYG editor.

Link to comment

I also suspect that GS didn't go into detail about what they're planning to do as it would be too technical for many users.

 

I doubt it would be too technical for any user if GS responded if e.g. a log authored before the change and which contains the text yes_no_maybe will display uncorrupted in the future.

 

Since the link you posted is html it sounds like it would just render as text. That means that if you entered something like this into a log:

<a href="http://coord.info/GC30">http://coord.info/GC30</a>

it would render as text.

 

No, I'm not talking of cases where it has been entered as html command in the way above (I do that on cache pages).

 

In logs I just copy the raw link and over all those years it then worked as hyperlink. I would like if that continued to work like that.

 

It will probably take some time to get used to Markdown, but the learning curve is probably *much* less than learning how to style text in a log with HTML or bbcode...especially, if GS provides a WYSIWYG editor.

 

I'm not intending to use Markdown. My wish is that all the old text logs (no use of bbb code and no use of explicit html) will still display properly, but I'm worried that this will not be the case.

All you write about different versions of Markdown is not really addressing my main concern. They would need a flag "is not markdown" for the old logs except those the authors of which decide to reformat them.

Edited by cezanne
Link to comment

Even new logs. If _brad_ were to include his name in a log, the system would have to know not to style the phrase. But _brad_ doesn't want to use markdown, and neither do any of his friend who were caching with him that day. How will the system know, without requiring every user to consistently escape plaintext, or without an explicit flag?

 

I have a strong feeling they may be adding that flag. If not, they should.

 

Or, perhaps, if they allow switching between the plaintext entry and the wysiwyg editor, that could be considered the flag. In the editor, if you enter _brad_, you would see the text entry become italicized leading to "brad" instead of seeing the first "_". Perhaps they could set it so that if you type two "_" then you'll get a single _ as you intend, not italicized. Or you could use a format button to type a username which would be stored as markdown-escaped.

 

WYSIWYG? Markdown log.

Plaintext log entry? No parsing.

That would seem to make sense, imo.

Link to comment

There are not yet mentioned any, that the authors of geocaching-voltage applications will have to be reprogrammed so that the imaging logs of this was garbled. Groundspeak probably unaware that in the field is necessary occasionally to see the log, and legible. And because they are responsible programmers, those will have to do much better to show how Markdown, and BB and HTML code.

 

Markdown is for users new learning elsewhere practically unusable.

Compared to the general validity and practical similarities BBcode / HTML is the Markdown "language" rather quirky. Just the new line "command" is really "brilliant".

 

Closely related to the acquisition of logs using Fieldnotes. Fieldnotes format is very simple, the entire log is on the same line, if you want to divide into multiple lines, there simply will place "BR" in brackets. This manage bulk even the simplest editor (Notepad), how to do it in Markdown is a complete mystery to me.

Edited by Arne1
Link to comment

If I'm reading this properly, Groundspeak are saying:

 

1. We have existing rules which everyone must follow if they want to add formatting or links to their logs.

 

2. We are changing the rules so that messages written according to the current rules will no longer be displayed correctly

 

3. We are not making any attempt to modify logs written according to the current rules because that is too hard.

 

4. We are not going to grandfather logs written according to the current rules and display them according to the current rules, even though that would be almost trivial.

 

5. We are not going to offer any tools to assist our paying customers, who faithfully followed the current rules, in finding out which of their logs will be affected

 

6. We are not going to provide any tools to help our paying customers modify their affected logs.

 

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

 

Of course, I could be completely misunderstanding the situation. Am I?

Link to comment

If I'm reading this properly, Groundspeak are saying:

 

1. We have existing rules which everyone must follow if they want to add formatting or links to their logs.

 

2. We are changing the rules so that messages written according to the current rules will no longer be displayed correctly

 

3. We are not making any attempt to modify logs written according to the current rules because that is too hard.

 

4. We are not going to grandfather logs written according to the current rules and display them according to the current rules, even though that would be almost trivial.

 

5. We are not going to offer any tools to assist our paying customers, who faithfully followed the current rules, in finding out which of their logs will be affected

 

6. We are not going to provide any tools to help our paying customers modify their affected logs.

 

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

 

Of course, I could be completely misunderstanding the situation. Am I?

 

I believe your wrong about #7.

Link to comment

4. We are not going to grandfather logs written according to the current rules and display them according to the current rules, even though that would be almost trivial.

No, I don't think it would be trivial to grandfather previous logs. It might not to be very hard to support the old formats in addition to Markdown, but it would be very complicated -- and I'd probably go so far as to say a waste of effort -- to support the old formats only in logs that already use them at this time.

 

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

Well, no, I don't see any reason for them to do this unless they genuinely thought it was best for the community. There's simply no advantage for them to change this just because they can.

Link to comment
No, I don't think it would be trivial to grandfather previous logs. It might not to be very hard to support the old formats in addition to Markdown, but it would be very complicated -- and I'd probably go so far as to say a waste of effort -- to support the old formats only in logs that already use them at this time.

I'm curious, why do you think it would be so difficult? My analysis (based on 40+ years in IT) is that maintaining support for displaying the old formats would be by far the easier part of the task. Note that I only say "displaying", not continuing to accept the old formats for new logs, which neither I nor (AFAIK) anyone else is arguing for.

 

The basic outline is:

  • 1) identify post-cutover logs with a flag.
  • 2) Keep the current display code (which is entirely server-side).
  • 3) Add the Markdown code. This is server-side for HTML destinations.
  • 4) When displaying a log, based on the destination, either run the old code or the new code.

The announcement wasn't clear from a technical point of view, but I believe that they are going to have to do #1 anyway. This is because of the possibility of royally screwing up logs with text that has a formatting interpretation in Markdown, as already discussed here. Also, this is pretty close to trivial, so there's hardly any reason not to do it.

 

As for #2, they aren't going to remove the old code entirely anyway, since they say they will still support smilies. (The announcement is unclear here also, saying "smileys will continue to be supported as they are today". Do they mean that smileys in old logs will still display as images? Do they mean that smileys will be supported in Markdown logs? Or both?)

 

As for #4, they will have to adjust based on the destination anyway. Presumably when displaying to an HTML-capable device (which is more than just web browsers, since HTML rendering is built into most systems at a basic level these days), they will convert the Markdown to HTML, so that ** will actually be bold instead of just displaying the **, so that links will actually be links instead of just displaying the text followed by the URL, etc.

 

I'm always open to other analyses. So where do you see the great difficulty in supporting the old formats when displaying old logs?

 

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

Well, no, I don't see any reason for them to do this unless they genuinely thought it was best for the community. There's simply no advantage for them to change this just because they can.

While Gill & Tony's comment was a bit aggressively negative and imputes intents to the Groundspeak developers which are poorly founded at best, the statement is basically true. Groundspeak does have a monopoly on geocaching. I've pointed out in the past that geocaching is a natural monopoly: it's to each geocacher's advantage to be where all the other geocachers are. Going off and forming a splinter group confers few advantages and many disadvantages to the individual member, and the failure of such attempts supports this position. Our only alternative to following their new rules is to protest, and we've seen the lack of response from GS to this thread. And this time (unlike some other times) GS did not even solicit input from the tiny percentage of geocachers who read the forums.

 

I don't think GS is getting rich at our expense. They've clearly put a great deal of the growth in membership fees into development, which includes things we don't see. (Securing a large, popular web site today requires solid expertise. I can't recall a time when GS went down due to an attack, and that's a good record.) The game is still fun for most of us, despite floods of new users who often play in different ways. But it's still a monopoly.

 

Edward

Link to comment
No, I don't think it would be trivial to grandfather previous logs. It might not to be very hard to support the old formats in addition to Markdown, but it would be very complicated -- and I'd probably go so far as to say a waste of effort -- to support the old formats only in logs that already use them at this time.

I'm curious, why do you think it would be so difficult? My analysis (based on 40+ years in IT) is that maintaining support for displaying the old formats would be by far the easier part of the task. Note that I only say "displaying", not continuing to accept the old formats for new logs, which neither I nor (AFAIK) anyone else is arguing for.

 

The basic outline is:

  • 1) identify post-cutover logs with a flag.
  • 2) Keep the current display code (which is entirely server-side).
  • 3) Add the Markdown code. This is server-side for HTML destinations.
  • 4) When displaying a log, based on the destination, either run the old code or the new code.

This is a good list showing why I say it's complicated.

 

The announcement wasn't clear from a technical point of view, but I believe that they are going to have to do #1 anyway. This is because of the possibility of royally screwing up logs with text that has a formatting interpretation in Markdown, as already discussed here. Also, this is pretty close to trivial, so there's hardly any reason not to do it.

Nope, sorry, I see no evidence at all in the announcement that makes me think they won't just apply markdown to old logs. Some logs will have quirks when unexpectedly being interpreted as markdown, but those quirks are nothing compared to the bbcode and html code in existing logs that will be undeniably unreadable when displayed raw. They clearly say they aren't worried about the latter, so I see no reason to think they'd be worried about the much simpler and less common problems of the former.

 

As for #2, they aren't going to remove the old code entirely anyway, since they say they will still support smilies. (The announcement is unclear here also, saying "smileys will continue to be supported as they are today". Do they mean that smileys in old logs will still display as images? Do they mean that smileys will be supported in Markdown logs? Or both?)

There's no way they'd keep all the bbcode and html support just to support smilies. They'd reimplement smilies before they'd do that.

 

(I don't remember exactly what they said about smilies. I think markdown has a different smilie mechanism. Are you sure they don't mean they're supporting that rather than recognizing the current smilie codes?)

 

As for #4, they will have to adjust based on the destination anyway. Presumably when displaying to an HTML-capable device (which is more than just web browsers, since HTML rendering is built into most systems at a basic level these days), they will convert the Markdown to HTML, so that ** will actually be bold instead of just displaying the **, so that links will actually be links instead of just displaying the text followed by the URL, etc.

I'm not really familiar with how any of this works, but my guess would be that the HTML/no HTML decision is made long before the formatting code comes into play.

 

I'm always open to other analyses. So where do you see the great difficulty in supporting the old formats when displaying old logs?

The stated goal is to eliminate a security risk, so it seems unlikely they would continue to support the security risk regardless of how theoretically limited that support is.

 

In addition, the suddenness of the cut over is indicative of a team that very much wants to support only a single method. If they had any interest at all in supporting them all at once, they would be supporting all of them now instead of supporting only bbcode and HTML, then, from all appearances, changing to markdown at the flip of a switch.

 

While Gill & Tony's comment was a bit aggressively negative and imputes intents to the Groundspeak developers which are poorly founded at best, the statement is basically true.

I don't deny they have a monopoly, but there's simply no rational explanation for them using the monopoly to push some agenda here other than improving the user experience. Sure, many of us don't think it's an improvement, that the doesn't lead to the conclusion that they have some sinister unrelated goal in mind. They simply believe that markdown will appeal to the masses, and on that score, I suspect they're right.

Link to comment

They simply believe that markdown will appeal to the masses, and on that score, I suspect they're right.

 

I do not think so and the numbers provided by GS also speak a clear language: The majority of the logs were simple text logs. I see no reason for harming text logs as a result of introducing Markdown. Nothing what you wrote provides an argument against a Markdown flag.

Link to comment

As database technology goes, my list is a nearly trivial design. The amount of code needed is tiny compared with even what they are adding to implement Markdown.

 

I agree that the announcement is unclear as to what they will do with old logs. The fact remains that adding a flag, and testing it, is trivial. Well, OK, nothing is totally trivial with a database that has over half a billion entries, but it's just a matter of making sure the process of adding the field doesn't disrupt operations, documenting the changes, testing, etc. All of this has to happen for the Markdown implementation anyway.

 

I'm no Markdown expert, but from both memory and from scanning the linked docs, I see no evidence that Markdown has smilies. So GS is going to have to add smilies to the Markdown code. But of course I'm not sure what they mean, since they didn't give enough detail.

 

The security risk is on input, not on display. Furthermore, it's on input of HTML -- I'm not aware of any security risks of BBcode. (In fact that's one of the points of BBcode -- it simply doesn't have the power to do damage.) No one is asking them to continue allowing input of HTML or even BBcode. So again, I'm aware of no security risk in continuing to display existing HTML and BBcode. If you have an example, please present it rather than just saying there's a security risk.

 

I don't think any of us here know the reason for making this so sudden. Getting rid of HTML input could be belated recognition of the security issues, and preferring to eliminate it rather than sanitize it as they do for cache descriptions (and I have no argument with this). I think the more likely trigger is more users with plain-text devices complaining about the formatting of BBcode logs. By definition, most of us in the forums are web users, and probably read logs in web browsers, so we aren't aware of how a lot of users with mobile devices see the logs. But this is only speculation -- again, no one here knows the reasons.

 

Will Markdown appeal to the masses? Well, it appeals to me. I've said so earlier in this thread, and I certainly plan to use it once it's implemented. The conflict is only over display of existing logs.

 

Edward

Link to comment

4. We are not going to grandfather logs written according to the current rules and display them according to the current rules, even though that would be almost trivial.

No, I don't think it would be trivial to grandfather previous logs. It might not to be very hard to support the old formats in addition to Markdown, but it would be very complicated -- and I'd probably go so far as to say a waste of effort -- to support the old formats only in logs that already use them at this time.

Actually, it is trivial. They already have the code to display "old format" logs. They are obviously developing code to display "New format" logs. All they need to do is identify whether the log they are about to display is in old format or new format and call the appropriate routine. They may not need any database change to do this. If they have a "Date Created" field and a "Date Last Updated" field then the code just has to say if it was created or last updated on or after the cut-off date display it new style. If it was both created and last updated before the cut-off date display it in old style.

 

If they can't do this with existing data fields, they just need to create a flag (using one of the spare dummy fields they probably have in the log record) and use that.

 

The irony is that this would actually make life easier for them. They would not have to worry about old logs which contain unintended Markdown tags.

7. We can do this because we are a monopoly and if our paying customers don't like it they really don't have any alternative other than following our new rules (which we may change at some random time in the future).

Well, no, I don't see any reason for them to do this unless they genuinely thought it was best for the community. There's simply no advantage for them to change this just because they can.

I'm not suggesting that they are making random changes, just because they can. My comment was aimed at the fact that they can make a change to the basic rules in such a way that it affects 20,000,000 logs (all of which were created according to the old rules) and not give any support to those whose logs are affected. Yes, the change is necessary - I've not seen anyone dispute that - but the way they are handling the change smacks of "If you don't like it, tough".

Link to comment

Nothing what you wrote provides an argument against a Markdown flag.

I'm sorry, you misunderstood me. I'm not arguing against a markdown flag, I'm just telling you why they aren't going to implement one.

 

I'm not aware of any security risks of BBcode.

So there's no reason for them not to support bbcode other than some unstated internal consideration such as their own code maintenance costs, yet they've already made it clear they aren't going to support bbcode. So it's frankly ridiculous to think they're going to lift a finger to add even more code, whether it's all as easy as you think or not, just so they can continue to support the old formatting code forever.

 

As it happens, I'm one of the very few people that actually does have HTML code in some of my logs, and I'm perfectly happy with them dropping HTML support like a hot potato. You have to recognize that something else is going on here for them to drop bbcode, too, despite the fact that that will annoy a lot more people. I think it's obvious that part of this is that they don't want to support bbcode in any shape or form, so designing an implementation strategy towards a fancy scheme of two strata of logs is a waste of time. If they wanted to support bbcode, they could just support bbcode: there's no advantage to adding a complicated distinction between old logs and new logs.

Link to comment

As database technology goes, my list is a nearly trivial design. The amount of code needed is tiny compared with even what they are adding to implement Markdown.

 

I agree that the announcement is unclear as to what they will do with old logs. The fact remains that adding a flag, and testing it, is trivial. Well, OK, nothing is totally trivial with a database that has over half a billion entries, but it's just a matter of making sure the process of adding the field doesn't disrupt operations, documenting the changes, testing, etc. All of this has to happen for the Markdown implementation anyway.

 

If the database record for each log contains a last edited field, any long created or last edited after the switch over might contain Markdown.

 

 

I'm no Markdown expert, but from both memory and from scanning the linked docs, I see no evidence that Markdown has smilies. So GS is going to have to add smilies to the Markdown code. But of course I'm not sure what they mean, since they didn't give enough detail.

 

 

Smilies are just images. In the forum post WYSIWYG editor we're using here there are a set of Emoticons we can select from that will add the appropriate HTML to our posts. The WYSIWYG editor for Markdown could work the same way. Because MarkdownDeep is open source extending it to support emoticons may not be that difficult. Some versions of markdown support emoticons (I just tried it withe the Github version). There is a site with a huge list of emoji codes that can be supported (http://www.emoji-cheat-sheet.com/). Typically it uses a tag with the a colon before and after the name of a emoticon. For example, :+1: with display a thumbs up icon. GS could also add some geocaching specific tags. For example, adding something like :[GC30]: could link to the cache page for Mingo or :[TB12345]: link to a trackable item with that number.

 

 

The security risk is on input, not on display. Furthermore, it's on input of HTML -- I'm not aware of any security risks of BBcode. (In fact that's one of the points of BBcode -- it simply doesn't have the power to do damage.) No one is asking them to continue allowing input of HTML or even BBcode. So again, I'm aware of no security risk in continuing to display existing HTML and BBcode. If you have an example, please present it rather than just saying there's a security risk.

 

There are plenty of security risks on display. Phishing attacks are all about getting users to click on something that appears to be benign but actually does something different. XSS is all about introducing code that is rendered in the browser. MarkdownDeep has built in XSS detection.

 

 

 

Link to comment
There are plenty of security risks on display. Phishing attacks are all about getting users to click on something that appears to be benign but actually does something different. XSS is all about introducing code that is rendered in the browser. MarkdownDeep has built in XSS detection.

True, phishing is the most likely security risk in BBcode. But the same risk exists in Markdown, so apparently that's not the security risk being addressed. (The only way to address this is to refuse to hide the URL. IMDb message boards do this, probably for this reason.)

 

As for XSS, the risk is still due to what a user input. Once you stop accepting HTML as input, then old non-risky HTML can't be exploited. I'd be interested in whether scripting is already blocked in HTML logs. Not taking the time to test it now ...

 

Edward

Link to comment

Hello everyone! There has been a lot of talk and there are many questions about the changeover to Markdown. I am one of the developers on this project and I will try to provide some insights into the decisions that were made as well as correct the misconceptions that are swirling around this topic.

 

First and foremost this change, as with every change we make, has no ulterior motive or malicious intent. There is an understanding that change is disruptive and usually ill-received by some, but we are not making changes simply for the sake of change. There is a method to the (perceived) madness and we believe that we are moving towards a game that is better for everyone.

 

Historically the geocache and trackable logs are nearly unfiltered HTML. We began working on this change because anytime that user generated HTML is involved you open your website and users to security vulnerabilities and closing those down is a top priority. This leads directly into why we are not supporting legacy HTML logs; if we allow older logs to continue rendering HTML then any logs that include security vulnerabilities would still be active which goes against the core reason for making this change in the first place. In order to properly secure the website so it cannot be used as a portal for malicious attack it was deemed necessary to remove the rendering of all user generated HTML in the logs.

 

HTML is a security issue, so why aren't we going to support BBCode going forward?

BBCode is also a security vulnerability because it ultimately generates HTML that can contain its own vulnerabilities. Our implementation of BBCode in geocache and trackable logs is old and brittle and would need to be completely replaced in order to account for this. With this in mind we decided to look at our HTML rendering engine from a holistic perspective. Markdown and BBCode are "competing" standards that provide a similar set of functionality. However, despite BBCode being around longer, Markdown has emerged as the favorite between the two standards and many people find that Markdown is an easier standard to understand (although I appreciate that this can be subjective). The decision was made not to support two competing standards in our code base and because BBCode is being broadly phased out elsewhere we made the decision to remove support for BBCode. Now, there have been comments that it would be trivial to allow the rendering of both standards by adding a flag or switching based on the log date. I would challenge anyone who claims that maintaining duplicate code paths in a legacy system is a trivial task with no impact on future development or peformance.

 

If we aren't going to support BBCode, why not convert the BBCode to Markdown?

When you add up geocache and trackable logs we are dealing with over 1 billion records, ranging from 1 character to thousands of characters in length. The type of conversion that is required is difficult to perform in an automated manner because we will need to touch every single log. No query can reliably filter down the number of logs so we need to pull them all back. When dealing with that many logs we cannot account for every permutation in the logs which means that either logs will be missed or worse (and more likely) logs will be incorrectly converted. As a general rule we err on the side of avoiding permanent data loss.

 

It has been pointed out that logs that were written before Markdown might be converted inadvertently. It is true that there may be cases where plain text gets rendered by Markdown incorrectly. We do not have the concept of plain text vs HTML logs so everything is rendered as if it might contain Markdown. We are working to account for this in advance and we believe that any remaining cases will be minimal in number and impact. Going forward the benefit of moving towards a simplified standard will increase the quality of logs by providing the tools to better express meaning and context. Another benefit is that unlike HTML and BBCode, Markdown is more human readable and works cross platform so that all users can share the same experience.

 

I'm sure I have left some questions unanswered and there are still people that are unconvinced about this change, but please know that the change is made with good intentions and we are continuing to work towards a smooth transition. Also, just know that we are reading the forums and taking notes of constructive opinions in the various threads on the topic.

Link to comment

HiddenGnome, thank you for joining the discussion.

 

I am a fan of adding a Markdown WYSIWYG editor to the log creation page at the website. It is after-all about beauty and self-expression, and that will make it feasible for those who do not code hmtl or bb to express themselves with a little more eloquence. Some would argue that beauty is not necessary, but I bet you and your colleagues are proud of the current beauty of the page and, of course, the fact that nothing is broken. Quite awesome, really.

 

So when I read "Existing logs will display any old HTML and UBB code as of February 2." (in the announcement), I understand that you will knowingly and deliberately configure your main product (the web page) so that it will look broken to anyone who is not a computer programmer? I guess that as a webpage programmer you might consider <Large>HTML tags</Large> to be pretty; or perhaps you are so accustomed to seeing the tags that you are blind to them. But you may be surprised at how many of Groundspeak’s clients don’t see it that way.

 

While only 3.5% of the logs are apparently affected, how many web pages? I analyzed my current home database around my home in California and I have only 2.2% logs (out of ~540,000 logs) affected (I am counting logs containing these two-character sequences: </ or [/ ), but 35% of the 20353 caches in this database are affected. I note that the beautiful logs section, in which you invested all that hard work to cleverly pull and show logs as the user scrolls down, will ultimately show a broken log for more than a third of the active caches. Don’t you think you and Moun10bike will get tired of the stream of folks coming to this forum webpage in perpetuity, each with yet another observation that some logs are broken at the website but not in the GPSr or other software?

Link to comment

Wisiwyg editor ? Nonsens for user who mahe logs via fieldnotes !

Assuming that you're not currently formatting HTML or UBB using your GPS or cellphone, the changeover to Markdown would not affect your plain text field note logs.

Closely related to the acquisition of logs using Fieldnotes. Fieldnotes format is very simple, the entire log is on the same line, if you want to divide into multiple lines, there simply will place "BR" in brackets (or <br> of course). This manage bulk even the simplest editor (Notepad), how to do it in Markdown is a complete mystery to me.

Edited by Arne1
Link to comment

Maybe HiddenGnome can answer the following questions.

 

Will inserting a pure link like www.geocaching.com be treated like now, and be shown as clickable (visit link)? Or will users really have to go back and write "[some text](" before and ")" after a link?

 

Will it be possible to use something comparable to <s> / ?

 

For users interested in keeping their logs 'clean' it would be good to know: Will there be a explanation before 2016-02-02 which plaintext-logs will be affected by being interpreted by Markdown, e.g. which syntax exactly?

 

# and ##: Will there be really an extra rule compared to Markdown and # and ## only interpreted as header if the line is also ending with a #, or all lines starting with # or ## etc.? Millions of logs would be affected.

 

Will the following things work as Markdown Syntax says?

 

Lines starting with numbers, followed by dots (german way to say first, second ...): Always interpreted as ordered list, so other numbers than 2. in the second paragraph/line and 3. in the third paragraph/line will be 'overwritten' on the website?

 

Lines starting with > (meant as more than): Interpreted as 'quote' and not showing the > anymore?

 

Lines starting with *** or ___ or * * *: interpreted like <hr>?

 

Lines starting with + or - or *: interpreted as unordered lists?

 

Lines starting with four or more blanks: Interpreted as 'Code'?

 

And the wide field of emphasis: Will * and _ work as described "Emphasis can be used in the middle of a word" which will alter all usernames containing more than one _ or *, which would also affect usernames like yes_no_maybe, or will only usernames like *Eisbär* and _law_ be affected? Or will usernames like Alter_Fuchs also be affected if an opening or closing _ coincidentally happens to stand nearby?

 

Which ways to 'escape' being interpreted as Markdown will be supported? Inserting \ before otherwise interpreted characters, enclosing in `? All this will make text look ugly everywhere else, especially usernames.

Link to comment

Maybe HiddenGnome can answer the following questions.

And the wide field of emphasis: Will * and _ work as described "Emphasis can be used in the middle of a word" which will alter all usernames containing more than one _ or *, which would also affect usernames like yes_no_maybe, or will only usernames like *Eisbär* and _law_ be affected? Or will usernames like Alter_Fuchs also be affected if an opening or closing _ coincidentally happens to stand nearby?

 

Which ways to 'escape' being interpreted as Markdown will be supported? Inserting \ before otherwise interpreted characters, enclosing in `? All this will make text look ugly everywhere else, especially usernames.

Good question.

 

My girlfriend has a nick Naty* and nearly every log I mention her nickname as we hunted together. Will be this nick displayed correctly, or it will be appropriate to rename a girlfriend? And if you rename it, so as not to be another problem?

Link to comment

If there are no additionals rules like 'only complete words surrounded by * or _' are displayed italics and don't show the _ or * it will depend on context:

 

24330016yp.jpg

 

For a website using Markdown it seems more convenient not allowing usernames containing characters that might have to be escaped to display correctly on the website. But nobody could think about Markdown coming along during the last 15 years ... :blink:

Edited by AnnaMoritz
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...