BUG: "Short description" HTML causes frustrating whitespace

[+redcreek18]

You removed the "short description" field about a year ago, but forgot to add a check on whether the field is actually being used or not, which means that the HTML for the "short description" field remains visible even though the field is not being used. This causes a frustrating whitespace above the description (previously "long description"), both on the website and in the app. Please fix this.

 

HTML:

 

<div class="UserSuppliedContent">
  <span id="ctl00_ContentBody_ShortDescription">
  </span>
</div>
<br>

 

Release note from 2017:

 

Previously, there were two text fields to describe your cache. During the Cache Submission Process, those were the cache summary and long description. On the Edit Cache Listing page, they were the short description and long description. Going forward, there’s just one field. However, the short description field still exists for any caches that currently have a short description. If a cache owner removes an existing short description from their cache, the field will disappear.

Edited October 22, 2018 by redcreek18

[+IceColdUK]

Raised this back in February - no response ?

 

 

 

[+redcreek18]

That is crazy to hear, IceColdUK. This bug affects EVERY SINGLE USER who has created a new cache in 2018! Are there any staff-members who can comment on this?

[+The A-Team]

It's a fairly minor issue that most people would never notice (I hadn't until you mentioned it), so it's probably way down on the priority list.

[+redcreek18]

I happen to believe the opposite is true for a lot of people (perhaps not everyone), The A-Team. Many enjoy reading the description, and I believe most of them would notice a huge whitespace at the top of it. It's also frustrating for people who make caches, who would like everything to look perfect for the audience, like myself and IceColdUK. It's a frustrating bug, extremely easy to fix (being a full stack web developer myself), and someone should do something.

Edited October 22, 2018 by redcreek18

[+Viajero Perdido]

I'm surprised an empty DIV produces any whitespace at all.  Doesn't/shouldn't HTML collapse all whitespace into nothing?

 

(Spoken as an ex-HTML geek from the coal-burning era...)

 

Ah, it's probably some standard padding in the CSS around DIVs, even empty ones.  There, I did the hard work, now could you fix it please?  Thanks.

[+redcreek18]

This can probably refresh your HTML skills 30 minutes, Viajero Perdido: https://www.codecademy.com/learn/learn-html But let's try avoid getting sidetracked - we need a staff member to get involved asap. There's also a break tag outside the div.

[+Lynx Humble]

3 hours ago, redcreek18 said:

(...) we need a staff member to get involved asap (...)

 

Good luck with that like A-Team said Groundspeak have others priorities for the moment like the New maps that is still broken 1 month after its been released...

[+Bl4ckH4wkGER]

@redcreek18

Thank you for bringing this to our attention. I have documented the issue.

 

Overall, this creates roughly 18px of extra white space between the h3-header "Geocache Description:" and the cache description. In the app, this only shows in the text-view, not in the web-view.

I cannot say when this is going to be picked up priority wise. Thank you for your patience. 

[+The A-Team]

22 hours ago, redcreek18 said:

Many enjoy reading the description, and I believe most of them would notice a huge whitespace at the top of it.

 

4 hours ago, Bl4ckH4wkGER said:

Overall, this creates roughly 18px of extra white space...

 

redcreek18, you and I have very different definitions of "huge". As I said in my earlier post, most people would never notice this single extra line's worth of whitespace. If you're seeing this manifest itself with a much larger whitespace, then it would be helpful if you can describe your specific circumstances (e.g. GC code of example listing, phone platform, browser, etc.) so the developers can figure out why it would do that.

[+redcreek18]

On 10/23/2018 at 7:15 PM, Bl4ckH4wkGER said:

I have documented the issue.

 

Thank you!

 

On 10/23/2018 at 7:15 PM, Bl4ckH4wkGER said:

In the app, this only shows in the text-view, not in the web-view.

 

Important: For me, it's the complete opposite - the white space only shows in the web-view, not in the text view. I'm using the latest version 6.13.0 of the app on iPhone SE, iOS version 12.0.1. Please add this to the issue. Thank you.

 

On 10/23/2018 at 7:15 PM, Bl4ckH4wkGER said:

I cannot say when this is going to be picked up priority wise.

 

I've got all I needed, thank you :)

[+noncentric]

So this is why that was that extra whitespace at the beginning of the cache descriptions I worked on.  I wonder if this explains why the cursor kept starting at the second line when I first edited the cache description section of the cache page.  Hhmmm.

 

On 10/24/2018 at 4:04 PM, redcreek18 said:

On 10/23/2018 at 10:15 AM, Bl4ckH4wkGER said:

In the app, this only shows in the text-view, not in the web-view.

Important: For me, it's the complete opposite - the white space only shows in the web-view, not in the text view. I'm using the latest version 6.13.0 of the app on iPhone SE, iOS version 12.0.1. Please add this to the issue. Thank you.

 

Interestingly, it seems the white-space shows up differently between the two apps.  I'm seeing it in the 'text view' on Android (v 6.14.0) and the 'web view' in iOS (v 6.9.0).

[+kunarion]

Here I tried to demonstrate the space, by highlighting it in yellow (and with an arrow).  It's an invisible container for the "Short Description" when present, and otherwise takes up space.  In the right half of that screenshot, that cache page has a Short Description so there's less empty adjacent white space.  There is still a white space, but it can be set between paragraphs as if I intended it.

 

I haven't figured out how these things happen.  That is, why people need to point them out (met with apathy).  Why web aesthetics (and typography) aren't a priority on Geocaching.com.  Sooo many faint gray things on gray backgrounds (even interface arrows), and stays that way for years, even gets worse.  I'm guessing that it's an issue of programmers not particularly bothered with visibility, with TPTB delegating and not particularly bothered, either.  How embarrassing for them. 

 

It's not the end of the world.  It's only a thread.  Go ahead and fix whatever you like.  But it is a thing. 

 

Edited November 9, 2018 by kunarion

[+thebruce0]

I hear ya kunarion. I'm a web dev, and also a perfectionist, so these little things I notice in others' web development methods tend to get under my skin (whether a tiny little sliver or a plank). Over the years with gc.com, my skin has grown a little thicker learning to accept with the timescale of their devs addressing even the smallest little hot-fixable tweaks, and what seems to be the top priority of favouring mobile over desktop end users, plus other things youv'e mentioned.  I think we have a number of intelligent professional programmers in here who regularly point out minor improvements. But our schedules and priorities are a little different than GS's (love it or hate). *sigh*

[+noncentric]

Veering into OT territory:

 

10 hours ago, thebruce0 said:

... what seems to be the top priority of favouring mobile over desktop end users...

This is what makes me so curious about why things (tagging logs as helpful/great story, native solution checker, new maps that I haven't even looked at yet) are being developed when app-only users aren't even being exposed to them.  Testing things, like the great story/helpful tags, that only website users can see provides zero insight into whether app users would like to see the feature or not.  And having CO's use the native solution checker that isn't even visible (much less usable) on the app, instead of a 3rd party checker that can be seen and clicked on in the app, seems to be a detriment to app users.  Sometimes, it's not clear to me whether GS is trying to encourage or discourage interacting with the website.