homepage cache markers improvement

[andrixnet]

The homepage new caches list and their corresponding markers on the map look odd. At closer inspection, these are actually created by several DIVs and styles.

Wouldn't a SVG or a PNG look better?

Second, when you hover mouse over in the new caches list, the corresponding pin gets enlarged. This is very good, except for the fact that the pin zooming action is anchored at the center, and instead of highlighting the rough location, it just zooms over it. The pins should be anchored bottom center and zoom based on this anchor.

---

• [ ] improved pin marker
• [ ] proper placement when enlarged

[deg-pl]

Yes. Current system is not good. We should have ONE SVG file with fill color defined in CSS. I think it is much better, CACHEABLE solution.

Additionaly - JS for slider animation should be stored in external file! Now is included in tpl and loaded every time user display main page. This is not cacheable and not optimal!

[kojoty]

I agree that pins are not the best - I'm not an artist - If you are able to prepare better pin let me know - I'll integrate it with the map. Svg + style could be OK.

@deg-pl, how many lines has JS for slider? 15? I agree we can move it to separate file but this is very light and insignificant in my opinion.

[andrixnet]

I'll try to come up with something using Inkscape this weekend

[deg-pl]

@andrixnet I think there are a lot of free SVG markers on the Internet.

[andrixnet]

That's right. I'll about one which can be easily styled with CSS

[kojoty]

BTW: my markers was my first try of preparing something like that by css tricks - and every marker needs 4 divs (two circles + two triangles) but now I see this is far sub-optimal. There are markers based on one div and css like this : http://cssdeck.com/labs/css3-map-pins - I think it is much more "cachable" and faster than any svg (forget about traditional png-s at all :) )

[andrixnet]

Very interesting. This issue was not about the actual implementation solution, but about improved visuals. Still, those CSS tricks are a bit above my skill :-P

[deg-pl]

Why use CSS to DRAW graphics? CSS should be used for styling. SVG is designed for vector graphics. SVG could be much smaller file than (this fragment of) CSS. Our CSS is changing frequently - external SVG - not. Proposed solution (CSS) is NOT faster or more cacheable than SVG. Using strange "tricks" we may not be compatibile with all browsers. Code is much less readable.

[kojoty]

@deg-pl, this is a little flame war and I will argue only for fun, OK?

I can agree that generally svg is better for vector graphic, but I don't agree that in this specific situation svg is the best solution. CSS3 is supported in most by all modern browsers (see https://www.w3schools.com/cssref/css3_browsersupport.asp). I think that the number of css lines/chars is less or the same as for the similar svg pin.

To draw very simple pin:

you need <span class="pin"></span>

+ 8 lines of css:

.pin {
    width: 8px;
    height: 8px;
    position: relative;
    background: transparent;
    display: inline-block;

    border-radius: 14px 14px 14px 0;
    border: 6px solid #f33;
    transform: rotate(-45deg);
}

where probably first 5 lines of css are the same (or similar) for svg image as well! Css is loaded from separate file so it is as good for caches as svg.

Arguments about code readability are in my opinion subjective, but I can agree this is "trick" and pure-css solution has many restrictions in possible shape changes but I'm absolutely sure that this is faster solution than any svg

SVG is currently supported by most browsers but there are also an "issues" and "differences".

[kojoty]

@deg-pl ...and the final argument: CSS solution has probably nice for you word "deg" inside - please do svg solution with "kojoty" in code :) - I can't believe you aren't a fan of this css way!

[deg-pl]

<?xml version="1.0" encoding="iso-8859-1"?>
<svg version="1.1" id="Capa_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
     viewBox="0 0 54.757 54.757" style="enable-background:new 0 0 54.757 54.757;" xml:space="preserve">
<g>
    <path id="kojoty_is_the_best_OC_programmer" d="M27.557,12c-3.859,0-7,3.141-7,7s3.141,7,7,7s7-3.141,7-7S31.416,12,27.557,12z M27.557,24c-2.757,0-5-2.243-5-5
        s2.243-5,5-5s5,2.243,5,5S30.314,24,27.557,24z"/>
    <path d="M40.94,5.617C37.318,1.995,32.502,0,27.38,0c-5.123,0-9.938,1.995-13.56,5.617c-6.703,6.702-7.536,19.312-1.804,26.952
        L27.38,54.757L42.721,32.6C48.476,24.929,47.643,12.319,40.94,5.617z M41.099,31.431L27.38,51.243L13.639,31.4
        C8.44,24.468,9.185,13.08,15.235,7.031C18.479,3.787,22.792,2,27.38,2s8.901,1.787,12.146,5.031
        C45.576,13.08,46.321,24.468,41.099,31.431z"/>
</g>
</svg>

[deg-pl]

(Sorry for polish but I think it is unimportant in this issue) ;)

Przykład który podałeś jest faktycznie banalny i zadziwia prostotą. Jednak np. ta druga pinezka w CSSDesk już taka oczywista nie jest - to jest kod bardzo trudny do analizy z zrozumienia przez osobę trzecią. SVG to SVG - podejrzysz gdzie chcesz, zrobisz z nim co chcesz. Skalowanie czy kolorowanie jest banalne i podlega pod wszystkie reguły CSSa. A przede wszystkim - kod jest czytelny i logiczny (przyznasz, że Twoje markery z divów nie były ani czytelne ani logiczne ;) ). Co do keszowalności - CSS jest plikiem dużym i jednym z najczęściej zmienianych w systemie. Za każdą zmianą przeglądarki muszą pobrać cały plik i cały sparsować. Wywalenie kodu do zewnętrznego SVG nawet jeśli zwiększy sumaryczną objętość, to ten pliczek będzie pobierany wyłącznie raz w miesiącu - cała reszta poleci z cache. Renderowany będzie tylko tam, gdzie to potrzebne.

Dlatego też pisałem od razu o JS, który wrzuciłeś w główną stronę. Zrobienie z tego pliku zewnętrznego niby niewiele oszczędzi. Ale ten kawałek kodu będzie ładowany przez powracających użytkowników (72%) raz na miesiąc, a nie przy każdym wyświetleniu strony głównej (52 000 razy / miesiąc!), więc nawet niewielkie różnice urastają do całkiem sporych.

Inną kwestią jest na przykład wyświetlanie feedów na głównej stronie. Obsługa tego przez jquery zwiększa o 2 konieczne przebiegi renderowania strony niezbędne do wyświetlenia feedów! Kiedyś po prostu PHP generował newsy. Teraz najpierw pobierany jest HTML generowany przez stronę główną, następnie pobierane jest jQuery, a dopiero następnie pobierany jest /StartPage/newsFeed (czy jak to się nazywa). Dopiero po tej całej procedurze możliwe jest renderowanie całości strony. Z drugiej strony - taki kod jest znacznie bardziej logiczny i łatwiejszy do analizy. (nie odbierz tego akapitu jako krytykę rozwiązania, tylko luźną dywagację ;) ).

[kojoty]

@deg-pl, wojnę css vs svg zostawiam na boku - sobie jeszcze kiedyś pogadamy :) jeśli masz fajną pinezkę svg to mogę zintegrować - wybierz taką, którą uważasz za ładną

co do samej strony głównej - bo o tym jeszcze nie mówiem: tak, ten feedRss to takie obejście problemu - bo widzisz - początkowo miało to działać tak samo jak pozostałe listy na stronie głównej czyli generujemy 1raz/kilka godzin i trzymamy w keszu APC... tylko już po fakcie sobie uświadomiłem (tj. zauważyłem w testach), że występuje problem w momencie gdy feedow nie ma w keszu APC - wtedy pobieranie ich o ile akurat np. blog nie odpowiada sprawnie trwa dluuugo a strona w tym czasie wisi. Postanowiłem, że wyeliminuję ten efekt ładując feedy asynchronicznie o ile nie ma feedów w keszu - zrobiłem asynchroniczne ładowanie, ale nie dorobiłem sprawdzenia czy feedy sa w keszu i jeśli są - pobranie z kesza bezpośrednio - i słusznie że o tym mówisz - trzeba to poprawić :)

[andrixnet]

Added another improvement detail about the homepage map pins.

[following5]

This is related to #1436: Unify location map markers