Jump to content

Release Notes (Website: Markdown) - February 2, 2016


Recommended Posts

Read previous Release Notes

 

Release Notes - February 2, 2016

 

Beginning today, you may notice some changes to geocache and trackable logs on Geocaching.com. In our continued effort to increase site security and promote cross-platform compatibility, we are removing support for HTML and UBB code in logs in favor of Markdown. These codes are used to add emphasis to text such as bold or italic type, or to add links to websites. In addition to improving site security, moving to Markdown means that new logs will now consistently look good across all devices.

 

To learn more about using Markdown and what this change means for your past logs, visit the Geocaching Help Center.

Link to comment
In addition to improving site security, moving to Markdown means that new logs will now consistently look good across all devices.
And many old logs will look... not good across all devices.

 

I took a look at some of my old logs. Please stop interpreting old logs (that were written as plain text, or as BBCode, or even as HTML) as markdown. Display the raw BBCode or HTML if you must, but please leave it at that. Interpreting non-markdown logs as if they were markdown logs creates a bigger mess than just displaying the raw BBCode or HTML.

Link to comment

I like the new format. A little less white space just above each horizontal rule would perhaps be a little more pleasant, but I like it. I do like the horizontal rule better than the alternating background colors.

 

As for broken html and bb rendering, it is not too prevalent; but it is definitely present on many caches; it is ugly; seems unprofessional; but I understand that that's how you want your product to look from now on.

Link to comment

Apart from the fact that I do not like the new look of the logs as some of the others who have replied to this thread, I can hardly say that logs like this one look nice

https://www.geocaching.com/seek/log.aspx?LUID=3abfd593-18f0-418a-86bb-db22bbec202d

 

All links are broken and this way to link to trackables concerns a huge number of logs.

Colourful logs in the old system also do not look nice now at all.

Edited by Rock Chalk
Removed unnecessary snark
Link to comment

Hi there,

after the current site update I am missing a quite comfortable function on the trackable page.

 

I have a list of Trackables to discover from a recent Event. I want to Change the date on the log page. So I enter the date of the Event into the date field and post a discover log. After this, I enter the next Trackable Number into the field below to log the next trackable.

Before the update, the changed date appeared in the date field of the log until I changed it by myself, giving the possibility to log all TB's with the Event date as discoverd.

After the update, date is switched back to the current date so I have to Change it manually every time.

This is quite annoying if you want to discover a lot of TB's.

 

Can this be changed, please.

Link to comment

The horizontal line is OK by me, but there's too much spacing.

Markdown itself is fine, but not addressing the existing html/bbcode in old logs is a real slap in the face for those who in the past have gone the extra mile to make their logs interesting and attracive, but then that's been pointed out many times in the forums in the past month and GS just don't seem to care :mad:

Link to comment

Markdown itself is fine, but not addressing the existing html/bbcode in old logs is a real slap in the face for those who in the past have gone the extra mile to make their logs interesting and attracive, but then that's been pointed out many times in the forums in the past month and GS just don't seem to care :mad:

 

What's particularly disappointing is that not even url links are displayed correctly in many cases and that's just a matter of a badly written routine to process the logs. If a bit of testing this could have been detected and fixed before the change. The same is true for the problems with some keyboard layouts (e.g. there is definitely one with the Polish keyboard and most probably one with many other Slavic languages too) - this has been mentioned before as well. GS could have contacted cachers from the countries with many caches and cachers to ask them to help with testing. Apparently this did not happen.

Link to comment

The problem with the ALT key = typically American, in America is ALT-key not necessary for writing characters.

 

The third time asking questions (no answer yet) - as in the offline logs using fieldnotes insert a line break? Thanks and log in another language, I used to be separated by blank lines.

Link to comment

Folks,

 

Multiple posts in this thread have been removed because they were rude, disrespectful, not constructive, or all of the above. All were written by people who have been in these forums for years.

 

It is possible to write critical posts that are not simply attacks. That's proven by the critical posts that remain in this thread.

 

For those of you whose posts have been removed, I strongly suggest you take a look at the Forum Guidelines before you post again in this or any other thread. It's become tiresome to moderate the comments of people who know better.

Link to comment

Please change your URL-regex to exclude ], so links don't get that messed up in old logs.

That would help. This particular breakage took me by surprise. The other stuff, like rendering bbcode italics as raw bbcode, I don't mind at all: I think bbcode is completely readable in the raw, which is why the arguments about markdown being so much more readable in the raw don't impress me. I could put up with the raw link code, too, except interpreting it as markdown puts a broken link right there making it hard to even grab the text of the original link. I'm thinking a little code could spot this case and come up with the correct link without any false positives mishandling any reasonable non-BBcode links.

Link to comment

I'll add my voice to those preferring the old alternately shaded format. I'd also like to see the unnecessary white space preceding the horizontal rule eliminated.

 

I do rather like the Markdown preview underneath the new message composition frame though. And the ability to resize it vertically.

Link to comment

Folks,

 

Multiple posts in this thread have been removed because they were rude, disrespectful, not constructive, or all of the above. All were written by people who have been in these forums for years.

 

It is possible to write critical posts that are not simply attacks. That's proven by the critical posts that remain in this thread.

 

For those of you whose posts have been removed, I strongly suggest you take a look at the Forum Guidelines before you post again in this or any other thread. It's become tiresome to moderate the comments of people who know better.

 

So, does that give you a good idea that this change is very unpopular? It should.

Not that GS listens, but these changes are very hard on the eyes. Bright white with black lines. Very tough. As opposed to gentle colors. But it is on-going with GS. Soon everything will be bright white. Very sad.

Link to comment

Please add back the drop down menu on the log page that shows what the codes are for the face emoticons. I can't remember them all! Thanks.

Click on the "How to Format" link in the logging pane. At the bottom of those instructions you will find the familiar old smiley guide!

Link to comment

but these changes are very hard on the eyes. Bright white with black lines. Very tough. As opposed to gentle colors. But it is on-going with GS. Soon everything will be bright white. Very sad.

 

Following some of the other "cosmetic" changes there have been various complaints that the "gentle colours" make it more difficult for people with visual impairments to read the text, and clamouring for things to be put back to plain black on white text. Now complaints that plain black on white is too harsh.

 

The old saying "d@mned if you do, d@mned if you dont" seems to fit here.

Link to comment

Ad Markdown: I cannot start a line with a date, e.g. 3. února (= 3rd February) - it changes into 1. února (1st February). According to this, you think most geocachers format their logs and most of them use auto-numbering of paragraphs. Otherwise, I cannot understand why you keep this function. According to me it should be optional whether I want to have my log formatted or no.

 

Ad log design: I do not like it. Too much white (= unused) space, logs blend together (reading tens of them) without distinguish colours, the "strange green" (you probably do not like the word 'ugly') hurts my eyes (above its visual unattractiveness) because it is too sharp together with those white spaces.

 

Simply I think that at least PMs should have option to choose their pattern of website (as you see, maybe two patterns could be enough = light x sharp) as well as to choose whether they want their logs to be formatted or not.

Link to comment

Ad Markdown: I cannot start a line with a date, e.g. 3. února (= 3rd February) - it changes into 1. února (1st February).

 

It has been mentioned in another thread already some weeks ago that this will become an issue with Markdown but apparently nothing has been done to address it. The problem might be that in the English language it is uncommon to use numbers like that (not only related to dates) while in many other languages it is common.

Link to comment
Ad Markdown: I cannot start a line with a date, e.g. 3. února (= 3rd February) - it changes into 1. února (1st February).
It has been mentioned in another thread already some weeks ago that this will become an issue with Markdown but apparently nothing has been done to address it. The problem might be that in the English language it is uncommon to use numbers like that (not only related to dates) while in many other languages it is common.
Related to this, footnotes* in old logs are converted to unordered (bulletted lists). I've occasionally used footnotes in my logs to provide details about something, without interrupting the flow of the text. That's one of the ways the new markdown presentation of old non-markdown logs‡ is breaking things.

 

* A footnote is generally indicated by an asterisk†, but markdown interprets the asterisk as a bullet and converts it into an unordered list.

 

† The second footnote on a page is generally indicated by some other symbol, such as a dagger. Although sometimes a double asterisk is used, but that would probably be interpreted as a nested list.

 

‡ Which is related to, but not the same, as the way the new markdown presentation of new plain text logs is breaking things.

Link to comment

Ad Markdown: I cannot start a line with a date, e.g. 3. února (= 3rd February) - it changes into 1. února (1st February). According to this, you think most geocachers format their logs and most of them use auto-numbering of paragraphs. Otherwise, I cannot understand why you keep this

You should be able to escape the . (numbered list) with a backslash. So, for your example, try: 3\. února

Link to comment

* A footnote is generally indicated by an asterisk†, but markdown interprets the asterisk as a bullet and converts it into an unordered list.

You should be able to escape the * with a backslash as so: \*

 

Do you really think that any cacher is willing to dig through hundreds or even thousands of logs to fix such issues? One can take care of such issues in new logs but it's too tiresome to take care of them in old logs.

 

An option to avoid interpreting logs as markdown which have not been written as markdown logs is what is needed.

Edited by cezanne
Link to comment

* A footnote is generally indicated by an asterisk†, but markdown interprets the asterisk as a bullet and converts it into an unordered list.

You should be able to escape the * with a backslash as so: \*

 

Do you really think that any cacher is willing to dig through hundreds or even thousands of logs to fix such issues? One can take care of such issues in new logs but it's too tiresome to take care of them in old logs.

 

An option to avoid interpreting logs as markdown which have not been written as markdown logs is what is needed.

You're such a downer; why do you always find something to complain about.

Link to comment

You should be able to escape the * with a backslash as so: \*

Gee, knowing that you need to do that to avoid a formatting you don't want and probably don't even know about seems as complicated as knowing how to call for italics using bbcode when you want them. And the main argument for markdown was that it would make raw text more readable, but now you're telling me I can get around this problem by making the raw text of the footnote unintelligible.

Link to comment

Altering dates and ordinal numbers especially in old logs when they are written in some languages like '4. Februar 2004' or '18. Tag' if starting a line to 'ordered lists' showing then as '1. Februar 2004' or '1. Tag' seems no insignificant issue to me. No problem for the english speaking world, but for others. And cachers who start their logs with a date or use ordinals did this for sure not only once and would have to look at every combination of digits and dot/full stop in every old log.

 

And then what? Escaping with \ looks ugly everywhere else and can't be the meaning of 'Markdown looks good even when not rendered'. In German you could convert the date to DD.MM.YYYY 04.02.2004 where no blank between day and month is necessary. And write 'Achtzehnter Tag' (eighteenth day) instead of '18. Tag'. But why?

 

Edit: Was there any research/testing how many old logs are broken because the language they are written in uses a dot after numbers, followed by a blank to indicate ordinal numbers and now are interpreted as ordered lists? And was there any research/testing how many logs had ordered lists in them? If the ratio was 10 : 1 or (as perceived) 10.000 : 1, why give preference to ordered lists and no practical solution for them who write in languages marking ordinal numbers with a dot? Displaying 4. or 29. or 889. as 1. is simply wrong when not asked for.

 

Interpreting - or * or + starting a line especially in old logs (something obviously not commom in english speaking countries, otherwise it would have been addressed) as 'unordered list' showing bullets instead of + or - or may lead to alter the meaning of the log, as these characters are not being displayed.

 

Edit: Starting a line with + or - corresponding to pro or con as in arguments pro and con something is not uncommon here. Omitting the + and - (pro and con) in front of the argument removes the point of the statement.

 

That seems no insignificant issue to me. As does omitting a starting > in old logs and showing the rest as quote.

 

Edit: Why not restrict triggering 'unordered list' with * only as shown in editor and leave alone + and - ?

 

Showing [not a link](really) as <a href="really" rel="nofollow">not a link</a> may be a minor issue, but to me generating a broken link like this seems useless in many respects.

 

And messing with usernames especially in old logs is no minor issue to me. _cacher_ or *cacher* loose their _ or */** and show italics/bold.

 

There might be no help for *cacher* except some escaping, but wouldn't it be enough Markdown to use only * for italics and ** for bold as shown in the editor and leave alone all _ ? Like not supporting 'nomal' Markdown and taking # as H1 only when the line ends with # ?

 

Now also cacher* and *cacher in old logs are affected, when listed in the order *cacher and cacher* or if for some other reason a starting or ending * is present. Here it would help to allow formatting only if exactly one word is surrounded by * or **, like GS already removed the ability to mark only parts of a word for formatting as italics/bold compared to 'normal' Markdown.

Edited by AnnaMoritz
Link to comment

Hi there,

after the current site update I am missing a quite comfortable function on the trackable page.

 

I have a list of Trackables to discover from a recent Event. I want to Change the date on the log page. So I enter the date of the Event into the date field and post a discover log. After this, I enter the next Trackable Number into the field below to log the next trackable.

Before the update, the changed date appeared in the date field of the log until I changed it by myself, giving the possibility to log all TB's with the Event date as discoverd.

After the update, date is switched back to the current date so I have to Change it manually every time.

This is quite annoying if you want to discover a lot of TB's.

 

Can this be changed, please.

 

There is nothing in the release notes about this, but I noticed it too.

 

I picked up 3 trackables yesterday and logged them today and had to put the date back every time. This is not the same behaviour as before!

Link to comment

Altering dates and ordinal numbers especially in old logs when they are written in some languages like '4. Februar 2004' or '18. Tag' if starting a line to 'ordered lists' showing then as '1. Februar 2004' or '1. Tag' seems no insignificant issue to me.

^This

 

I never used HTML or BBCode in my logs and was prepared that occasionally used links might need an edit.

But just browsing my last logs showed that in quite some cases my old logs will be garbled due to the above.

 

Can anybody give an usecase why automatically "numbering" is even considered a helpfull formating?

I somehow understand bold, italic, bulleting, textsize but numbering can easily be done by the author.

IMO it should be omitted especially when applied retrospective to 560 million logs.

 

I'm not against markup but I think it's a bad idea to apply it *by default* to all input text. Don't you think the overwhelming number of authors don't want and don't expect any formating? Given the examples in this and other threads many will be surprised or might even not noticing that their text will be garbled.

Link to comment

[...] what is not supposed to be since italic markdown should start and end with the asterisk *.

 

That's wrong. Underscores are valid Markdown triggers.

 

Hans

 

But not according to the "Markdown Guide" provided by Groundspeak:

 

markdown.jpg

Link to comment
we are removing support for HTML and UBB code in logs in favor of Markdown

The BBCode tool list is still visible and usable above the markdown tool list. Is this intentional?

 

Edit: Solved. It was a Greasmonkey script (GC Little Helper).

Edited by Hynz
Link to comment

[...] But not according to the "Markdown Guide" provided by Groundspeak:

 

Their guide is way behind reallity.

Underscores are valid Groundspeak triggers. Try it out*. ;-)

 

Hans

 

* Du glaubst doch sonst auch nicht blind alles, oder?

Link to comment

If the argument for not converting old logs is that only 3% used formatting, why spend so much time on making a new way to format for those 3%? Why not skip formatting all together?

 

Rendering old logs, for the 97% that doesn't use formatting, as formatted, doesn't make sense at all.

Link to comment

Please change your URL-regex to exclude ], so links don't get that messed up in old logs.

 

Thank you for doing something about this :) But right now, no link is made at all.

 

Can you please make it work so that in

[url=http://www.thomfre.net/en/out-caching/us-trip-2015-summary/]Read more about our trip here[/url]

, http://www.thomfre.net/en/out-caching/us-trip-2015-summary/ is treated as a link? :)

 

Edit: typo

Edited by thomfre
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...