Jump to content


+Premium Members
  • Posts

  • Joined

  • Last visited

Everything posted by aB5dEglYeS5P

  1. Some good improvements. I find that when found caches are hidden I still get the mouseover tooltip. In crowded areas this makes it difficult to mouseover the desired unfound cache. (Are the fixed width survey results going to be published?)
  2. When the source validates - a valid doctype would be a start... I'll accept browser support as a good reason to cripple functionality. As far as I can tell the properties you mention are supported by IE7+ ... http://www.w3schools.com/css/pr_dim_min-width.asp I'm not really sure why it's necessary though - I've always found the right combination of percentages and floats seems to work. That misses the point though - you point out readability issues with text and I'll agree that for cache descriptions, logs... other things I want to read that's true but for maps, tables (of caches, pocket queries, other) and anything else that you look at rather than read it just means things are compressed, run onto multiple lines and are (you guessed it) less readable. Case in point (though this could actually be solved by different means): http://www.geocaching.com/my/geocaches.aspx includes such gems as GC20EYY which 'you found x' runs to 4 lines meanwhile the first (date) column is half full a is the last and there is a third column with all the way down? More appropriate to the fixed width conversation is my list of nearest unfound. All being in 'London, United Kingdom' most of the second line (by...) run over. A different point, someone earlier asked about linking to the guide... the anchor names aren't the friendliest: http://www.geocaching.com/guide/default.aspx#ctl00_ContentBody_hlSection1dToggle Though id and class naming seems to be universally unhelpful Anyway, enough rant... given the number of people that don't bother to read a thread before repeating a question I should probably cut you some more slack. And I am very happy to see PMO caches on the beta map (even if I can't say I particularly like the new icon set... maybe it'll improve with age)
  3. Site changes require change to: javascript:for%20(i=0;%20i<document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes.length;%20i++)%20{document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes[i].childNodes[0].src=document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes[i].childNodes[0].src.replace(/(http.+?tiles.virtualearth.net\/tiles\/r\d+?)\?.*/g,%20"$1?g=604&productSet=mmOS");};%20void(0); and for some reason I seem to be unable to edit the last post.
  4. the golden caches are PMO only - the PMO mystery looks even more odd was the beta map Google Satellite view zoom limited to 18 before... I thought the full ?21 was prev. available but I might be wrong
  5. making maps (old) wider: @-moz-document url-prefix("http://www.geocaching.com/map") { #Content .container {width:95% !important;} #ctl00_divContentMain {width:100% !important;} } may save someone a few minutes with stylish naturally it may break something completely (edit: not quite as trivial to do the same on cache pages...)
  6. The fixed width (mentioned in vid @ 2:24) is a large regression, especially for maps. Hope that it's coded to allow for easy user restyling...
  7. For anyone interested a bookmarklet to see OS maps on the new beta maps... javascript:for%20(i=0;%20i<document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes.length;%20i++)%20{document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes[i].childNodes[0].src=document.getElementById('map_canvas').childNodes[0].childNodes[0].childNodes[7].childNodes[0].childNodes[i].childNodes[0].src.replace(/(http.+?tiles.virtualearth.net\/tiles\/r\d+?)\?.*/g,%20"$1?g=604&productSet=mmOS");};%20void(0); (edit: seems you can't link to js so needs to be installed by creating a bookmark rather than drag/drop) To use - load up beta maps, select Bing Maps and then (and only then as this is written - if someone fancies improving the logic, please do) run the bookmarklet. (It's not fantastic as you need to rerun the bookmarklet if you scroll/zoom but was a quick way to do what I wanted...)
  8. Liking the Maps Beta (though it's not really useful for me until I can filter out founds) And very happy to see addition of other Map Providers - in the UK, Bing features OS mapping... would it be possible to add this or does it need to be done via greasemonkey or similar?
  9. ...and the wysiwyg editor wraps everything in paragraph tags by default which adds extra white space. I thought we'd covered that after the release some time ago...
  10. PQ - Preview in Google Maps gives: Your search did not return any results. (when it really should and did earlier today) (this isn't the first time an update has broken this)
  11. Preview in Google Maps of a PQ with 1000 caches seems to have been broken. Only displays 649... worked before / still has 1000 results (if viewed as a list) [edit] not consistent... one shows 649/1000, one 659/1000, another 842/997, another 683/966 and that one includes a letterbox cache in the US that I haven't found... Smaller PQs (250) seem to be complete on the map.
  12. Doesn't only affect PQs with >500 results. Tried to download a PQ with 5 results generated yesterday and downloaded successfully yesterday and that now also returns 500 - Internal server error.
  13. Is it intentional that Hide My Finds doesn't hide my finds that are disabled? I'd expect it to be OR not AND if you see what I mean... Also there seems to be some reclassing of divs to unique ids... shouldn't this be by id... it makes restyling more difficult (I'm liking the general idea though )
  14. Care to share? Using stylish rather than GM... @-moz-document url-prefix("http://www.geocaching.com/seek/") { .DecryptionKeyWidget {display:none !important;} }
  15. I don't really understand the usage of those <br>s either, it's not like you couldn't call it all <div>View this Log</div> and add the relevant margin-top and font-size styles for it. <br>s are not supposed to be used for creating empty spaces on pages. But since you already managed to hide the View this Log -text then I believe you are using some custom CSS file for the geocaching.com site like I am, so try adding the following to it to hide the <br>s: table.LogsTable tr > td > br:nth-last-child(-n+2) { display: none; } Thanks for suggesting this... hadn't thought of a great solution when I was playing before. Now using: span#ctl00_ContentBody_CacheLogs br+br {display:none !important;} span#ctl00_ContentBody_CacheLogs small {padding:0 0 0 5px !important;} Which works well for me.
  16. Then avoid viewing the source. I'm not talking about the resulting HTML code, I am talking about the resulting web page as viewed in your browser. My point being is that it looks more like a step backwards than forwards. Entirely understood... just meant that if you think it looks bad on the outside, under the hood is worse... (Don't get me wrong, that's far less important but is IMO indicative of some of the sloppy work here)
  17. Then avoid viewing the source. Random id/class use, weird css mixture, random fixed column widths, perverse font sizes and modifiers. It's as if noone has looked at the code they're producing or if they have they don't care!? The printable css is now worse than it used to be - both for google maps (I want the cache names on the right and I want the cache type icon) and cache descriptions (cache_details.aspx not cdpf.aspx) And I've seen mention of HTML Tidy... then why are there still basic url encoding issues (& -> &) All cache logs have <br><br><small>View this Log</small>... which would be much better at the right of the date/name line than doubling the log height for short logs - not that I've ever understood the use of the link anyway and am currently hiding it. (Though not the more stubborn breaks)
  18. in case it saves someone else a few mins... @namespace url(http://www.w3.org/1999/xhtml); @-moz-document url-prefix("http://www.geocaching.com/") { body {line-height:1em !important;} } @-moz-document url-prefix("http://www.geocaching.com/map") { #cacheListTable {font-size: 10px !important; } .LabeledMarker_markerLabel {font-size: 8px !important; padding:0px !important;} #uxPremiumFeatures {margin-top:5px !important;} #filterLegend>p {margin-top:5px !important;} .FilterContainer {margin:0 !important;} #uxSideBar>p {margin-top:5px !important;} #cacheListBounding {margin-top:5px !important;} } tidies up the right hand side of maps a bit (and reduces line spacing... a bit too liberally really)
  19. Only if they're done sloppily. The css rules on this site are hugely frustrating, for example the base font declaration is: font:13px/1.231 arial,helvetica,clean,sans-serif; and h2 increases the size using: font-size:153.9%; and I've already mentioned my aversion to: line-height:1.75em; being the default across the site... At least it's possible to restyle it.
  20. line-height:1.75em; in http://www.geocaching.com/css/yui27-reset-fonts-grids.css makes the cache description bubble on a google map ridiculous (in addition to what it does everywhere else...) (IMO my implies I have control / your imples I'm being told what to do)
  21. concur with whitespace remarks. show numbers on map... the numbers are now ridiculously large...
  • Create New...