Niektóre screenshoty mają białe tło, co zlewa się z treścią posta - czasem można nie odróżnić tekstu od obrazka.
Gdyby obrazki miały czarną ramkę, to by drastycznie poprawiło czytelność.
Widzę kilka opcji do rozważenia:
@Riddle: W Mikroblogach trzeba się nagimnastykować, żeby obrazek wsadzić w treść wpisu - po zapisaniu wpisu, kliknąć obrazek i skopiować link. A jak piszemy artykuł, to chcemy duże obrazki.
Więc edytor Mikroblogów przydałoby się ulepszyć, a nawet ujednolicić z edytorem na forum.
Żeby w mikroblogu, tak samo jak na forum, po kliknięciu w załącznik z listy, został on umieszczony w treści wpisu.
Pomniejszanie obrazków miałoby zastosowanie w niektórych przypadkach, ale raczej nie robiłbym z tego reguły.
Dałoby się do markdowna dorobić, żeby obrazek pomniejszony zaczynał się np. dwoma wykrzyknikami?
!
Masz na myśli to, żeby wklejanie obrazka do mikroblogu od razu umieszczało obrazek w treści? To jest akurat prosta zmiana. Możemy dodać.
mogłyby mieć w sumie ramkę, cień i zaokrąglone rogi:
LukeJL napisał(a):
mogłyby mieć w sumie ramkę, cień i zaokrąglone rogi:
Dokładnie tak bym to widział.
Tylko ja dodałbym też żeby się powiększał na kliknięcie.
@Riddle @pradoslaw
Nie mogę założyć nowego wątku żeby zrobić zgłoszenia bo chcę właśnie zgłosić że nie da się zakładać nowych wątków... ani pisać na mikroblogu i komentować.
The POST method is not supported for route /. Supported methods: GET, HEAD.
Request URL:
https://4programmers.net/Forum/Coyote/Submit/
Request Method:
POST
Status Code:
405 Method Not Allowed
W dodatku przestał działać link https://forum.4programmers.net
Przekierowuje na https://4programmers.net/Forum/ z ukośnikiem na końcu który najwidoczniej przeszkadza i nie ładuje styli a linki są błędne (/Forum/Forum) i powodują błąd 404.
To się stało parę godzin temu, ze 4 godziny temu wszystko działało
Próbowałem na kilku przeglądarkach i z czystym cache
@obscurity Powinno działać.
Ja jestem przeciwny ramce, bo to będzie psuło wstawianie zewnętrznych emotek 
[pomijam, że nadal nie został naprawiony błąd i obrazki mają styl blokowy zamiast domyślnego inline] czy przezroczystych obrazków, jeśli ktoś tak zechce. Ale to tylko mój głos.
Marooned napisał(a):
Ja jestem przeciwny ramce, bo to będzie psuło wstawianie zewnętrznych emotek
Fakt.
Tylko że takie coś chyba lepiej byłoby poprawić niestandardowymi emotikonkami. Coś co dawno już discord i slack zrobił, żeby zrobić niestandardowę emotkę :gg_wierd_eyes: czy coś takiego, które pokazywałoby wybraną emotkę inline. Myśleliśmy już o tym dawno z @Ketchupix.
Poprawisz niestandardowe emotki, nie poprawisz przezroczystych obrazków itd itd.
Tzn wprowadzając ramki dlatego że "źle wygląda ze screenshotami z białym tłem" nagle będzie trzeba poprawiać X przypadków w których ramki psują layout.
Lepiej nic nie zmieniać i zostawić as is szczególnie że np w ciemnej skórce screenshoty z białym tłem nie robią problemów, prawda?
Imho dodanie ramki do wszystkich obrazków dlatego że istnieje jakiś mały procent przypadków gdzie może to zwiększyć czytelność jest nadmiarowe.
@opiszon: dobrze mówisz, zaraz ktoś po tej poprawce będzie pisał, że coś innego się wyłożyło/źle wygląda i tak w nieskończoność, jest jeszcze ten dark mode to tam też będzie trzeba to dostosować. Nawet nie wiem na czym te ramki miały by polegać i jak wyglądać bo nikt szkicu nie zrobił to tylko umacnia to, że każdy inaczej zinterpretuje o co chodzi i na końcu znowu źle będzie.
W dark mode żaden problem. Ramka ma tylko dodać kontrast, więc w dark mode będzie jasna, a w bright mode będzie ciemna.
Nie musi to być linia ciągła (solid). Może być dashed, albo dotted.
Marooned napisał(a):
Ja jestem przeciwny ramce, bo to będzie psuło wstawianie zewnętrznych emotek
Obrazki inline musiałyby mieć stały rozmiar i jeśli forum miałoby je obsługiwać oraz nie psuć postów z blokowymi obrazkami, to należałoby dla obrazków inline wprowadzić inną składnię/jakiś modyfikator.
Chodzi o to że dla problemu ze screenshotami z białym tłem nie ma konieczności dodawania ramki w dark mode.
I w drugą stronę. Dla screenshotow zrobionych w dark mode nie ma potrzeby dodawania ramki w light mode.
Jeżeli bardzo potrzebujecie tej opcji to dodajcie sobie jakiś alternatywny tag typu "obrazek z outline" ale nie psujcie istniejącego rozwiązania.
opiszon napisał(a):
Jeżeli bardzo potrzebujecie tej opcji to dodajcie sobie jakiś alternatywny tag typu "obrazek z outline" ale nie psujcie istniejącego rozwiązania.
Czemu to miałoby być "psucie"?
Spine napisał(a):
Obrazki inline musiałyby mieć stały rozmiar i jeśli forum miałoby je obsługiwać oraz nie psuć postów z blokowymi obrazkami, to należałoby dla obrazków inline wprowadzić inną składnię/jakiś modyfikator.
Ale obrazki były inline na tym forum przez 20 lat i nikomu to nie przeszkadzało. Nie trzeba nowej składni, wystarczy nacisnąć enter.
Ja proponuję dać jakiś subtelny drop-shadow pod obrazki, nie zepsuje to zewnętrznych emotek, będą po prostu miały mały cień
@obscurity: Są ludzie, którzy od lat w Wordzie ręcznie numerują strony, a większe odstępy robią spacjami i enterami...
Nie przeszkadza im, że są do tego bardziej odpowiednie ficzery.
Tak samo w Markdown, czy LaTeXu automatyczne układanie treści pomaga, a nie szkodzi... Ale człowiek, który od lat robi odstępy spacjami i enterami będzie pokrzywdzony.
Spine napisał(a):
@obscurity: Są ludzie, którzy od lat w Wordzie ręcznie numerują strony, a większe odstępy robią spacjami i enterami...
Nie przeszkadza im, że są do tego bardziej odpowiednie ficzery.
jednak jestem prawie pewny że nowe linie w markdownie robi się nowymi liniami i to najodpowiedniejszy ficzer i nie potrzeba "specjalnego modyfikatora".
Moim zdaniem najlepiej by było gdybyśmy się trzymali standardów markdown jakie są na githubie / stackoverflow i do których większość ludzi jest przyzwyczajona. Tam możesz sobie normalnie wstawić obrazek inline, nie ma żadnego obramowania jeśli go nie chcesz i ogólnie wszystko trzyma się kupy. To nie jest "automatyczne układanie treści" jeśli nie da się tych treści ułożyć inaczej. Enter mógłby być wstawiany automatycznie przy pisaniu a nie przy renderowaniu, już kiedyś o tym pisałem w innym wątku.
Są osoby które odstępy w postach robią spacjami i enterami, są też osoby które sugerują że przerywana ramka do każdego obrazka jest estetycznie w porządku
Jestem otwarty na pomysł z inline obrazkami. Teraz pytanie: jaki jest use-case pod to?
Bo mój argument, czemu obrazy powinny być elementem blokowym jest prosty - są większe niż tekst. Więc nie pasuje żeby były pomiędzy linijkami w tekście, najlepiej byłoby gdyby były poniżej lub powyżej tekstu - tak jak np. tabelki. To jest argument za tym żeby były blokowe.
Jaki jest argument za tym żeby były inline? PS: Żeby nie było - nie mówię że nie takiego, tylko pytam @obscurity i innych czy jakiś jest, bo ja go nie widzę?
Jedyny argument jaki znalazłem w tym poście żeby obrazy były inline, to wklejanie obrazów JPG/GIF, które wyglądają jak stare emotki. Dobry argument, merytoryczny. Ale ja odpowiedziałem na niego kontr-argumentem, że to można rozwiązać tak że dodamy niestandardowe emotki, specjalnie pod 4programmers.net, które zawierają te stare emotki z GG. Wtedy emotki będą inline, a wrzucane screeny i inne obrazy będą block.
Czy jest jeszcze jakiś inny argument?
Riddle napisał(a):
- Ale w innym wątku, kiedy proponowałem składnie markdown zgodną z commonmark, i użyłem tego argumentu że podobnie jest na githubie, to pewien administrator (którego nie wymienię z nicka) powiedział, "nie obchodzi mnie jak jest na githubie, ma być zrobione tak żeby tu było dobrze".
No i co wtedy? Tak źle i tak nie dobrze.
No pamiętam mniej więcej taki wątek i zgadzałem się z tym administratorem którego imienia nie wymieniamy bo chodziło o jakąś funkcję która była specyficzna dla tego forum i chodziło o zachowanie starego zachowania, ale w innym poście o tym samym zresztą Obrazek jako element blokowy napisał że zgodnie z githubem jest spoko
Riddle napisał(a):
Jestem otwarty na pomysł z inline obrazkami. Teraz pytanie: jaki jest use-case pod to?
Bo mój argument, czemu obrazy powinny być elementem blokowym jest prosty - są większe niż tekst. Więc nie pasuje żeby były pomiędzy linijkami w tekście, najlepiej byłoby gdyby były poniżej lub powyżej tekstu - tak jak np. tabelki. To jest argument za tym żeby były blokowe.
Jeden obrazek jest większy inny nie. Use case prosty, na przykład można stworzyć ładnie wyglądające instrukcje krok po kroku, przykładowo:
Wpisz treść pod 
a potem sprawdź w zakładce 
jak wygląda i naciśnij 
żeby zapisać post.
Teraz to wygląda jak psu wyjęte z pyska i nic się z tym nie da zrobić.
Drugi use case - można zrobić porównanie obok siebie (na przykład fragmentów forum w light mode i dark mode) bez angażowania edytora graficznego.
Trzeci use case - można używać tych wspomnianych wyżej własnych emotek z zewnętrznego źródła.
obscurity napisał(a):
Jeden obrazek jest większy inny nie. Use case prosty, na przykład można stworzyć ładnie wyglądające instrukcje krok po kroku, przykładowo:
[...]
Teraz to wygląda jak psu wyjęte z pyska. No i można używać tych wspomnianych wyżej własny emotek z zewnętrznego źródła.
Okej, nawet sensowny use-case.
Gdyby obrazy były inline, to wyglądałyby tak:
Tylko że szczerze mówiąc, nie wiem czy tworzenie takich instrukcji jest zasadne. Widziałeś gdzieś w dobrej instrukcji lub dokumentacji takie zastosowanie obrazów? 
Osobiście, jeśli wklejamy takie małe obrazy do instrukcji, to zarówno jak są inline i block to wyglądają źle; z czego inline ma tą zaletę że jest to trochę mniejsze w pionie, ale nadal brzydkie. Gdyby paragraf miał więcej linii, wyglądałoby to jeszcze grzej.
Jeśli ja chciałbym napisać instrukcję dla kogoś, to napisałbym to raczej tak:
Dodałbym większe obrazy, które mają też więcej kontekstu.
Umieszczanie takich małych obrazków, i pisanie takich zdawkowych instrukcji, żeby zmieścić kilka obrazków w jednym zdaniu wydaje się że ma minimalizować Twoją pracę jako piszącego, kosztem czytelności dla czytelników.
@obscurity Jest może jeszcze jakiś inny use-case dla takich obrazów inline? Nie mówię od razu "nie", może znajdzie się jakiś sensowny przypadek o którym nie pomyślałem. Jeśli by tak było, to można by dodać specjalny atrybut, np. data-markdown-inline, który sprawiałby że obraz jest inline; jeśli znajdzie się use-case pod niego.
Ja widziałem takie przyciski w dokumentacji. Nie mam teraz pod ręką, ale mam swój przykład z ikoną
Ogólnie inline jest bardziej uniwersalne, bo bardzo łatwo zmienić w blokowe, a w drugą stronę nie da się.
I jestem przeciw ramkom.
-daniel- napisał(a):
Ja widziałem i używałem takie przyciski w dokumentacji. Nie mam teraz pod ręką, ale mam z ikoną
No rozumiem, ale moim zdaniem to wygląda brzydko, jak jedna linia w paragrafie ma inny line-height, przez to że dodano obrazek. Żeby to miało sens, to obrazek musiałby być nie większy niż wysokość linii.
Poza tym, sam obrazek ikonki nie pokazuje gdzie jest. Dobra instrukcja powinna wkleić szerszy kontekst, cały pasek narzędzi (albo jego część) żeby łatwo odnaleźć rzeczoną ikonę w nim, np. tak:
Nie będę się upierał, można dodać <img data-markdown-inline/>, żeby obrazek się stał inline, ale bardzo wątpię czy ktokolwiek będzie tego używał.
Riddle napisał(a):
No rozumiem, ale moim zdaniem to wygląda brzydko, jak jedna linia w paragrafie ma inny
line-height, przez to że dodano obrazek. Żeby to miało sens, to obrazek musiałby być nie większy niż wysokość linii.
A może by tak pozwolić autorowi posta zdecydować jak wygląda jego post? Jeśli nowa linia będzie wstawiana automatycznie przez edytor to ktoś umyślnie musiałby ją zlikwidować, więc znaczy że chce żeby tak to wyglądało.
Riddle napisał(a):
Poza tym, sam obrazek ikonki nie pokazuje gdzie jest. Dobra instrukcja powinna wkleić szerszy kontekst, cały pasek narzędzi (albo jego część) żeby łatwo odnaleźć rzeczoną ikonę w nim, np. tak:
No w profesjonalnej instrukcji możliwe, ale jak piszesz luźny artykuł lub post i już w nim jest screenshot całego ekranu to bez sensu duplikować te fragmenty ekranu wielokrotnie. Gdybyś chciał omówić każdą ikonkę z osobna to za każdym razem dasz obrazek całego toolbara i będziesz podświetlał inną ikonę? Ja jestem stare pokolenie wychowane na artykułach z "PC Format", "Chip" czy "Komputer Świat" i tam artykuły były pisane w taki sposób że małe elementy interfejsu były inline. Sam nawet nie zamierzam tworzyć takich treści.
Ramka też przeszkadza w prezentacji bo ktoś może na przykład "artystycznie" dawać screeny z nieregularnymi kształtami
i ramka mu to zepsuje. Wolałbym żeby dać możliwość wpisania "border" w stylu, albo danie "filter: drop-shadow" które dostosuje się do przezroczystej treści. Teraz style dopuszczają chyba tylko font-size i color.
Riddle napisał(a):
@obscurity Jest może jeszcze jakiś inny use-case dla takich obrazów inline?
Dałem trzy. Aż tak mi nie zależy żebym wymyślał use-case'y do końca wieczoru ;)
PS Jak widać sztywno ustawione line-height nie działa dobrze z customowym font-size
W temacie ramek, pewnie należałoby przeglądnąć istniejące wątki i dobrze przemyśleć co się z nimi stanie po dodaniu ramek. N.p. Arabskie znaki w Lazarus...
 |  |
Riddle napisał(a):
No rozumiem, ale moim zdaniem to wygląda brzydko, jak jedna linia w paragrafie ma inny
line-height, przez to że dodano obrazek. Żeby to miało sens, to obrazek musiałby być nie większy niż wysokość linii.
Nigdzie nie ma wymogu, że wiersze muszą mieć taki sam odstęp. Jeśli zawartość tego wymaga, to się go zwiększa, także w książkach
Moim zdaniem to jest brzydko ;)
obscurity napisał(a):
No w profesjonalnej instrukcji możliwe, ale jak piszesz luźny artykuł lub post i już w nim jest screenshot całego ekranu to bez sensu duplikować te fragmenty ekranu wielokrotnie. Gdybyś chciał omówić każdą ikonkę z osobna to za każdym razem dasz obrazek całego toolbara i będziesz podświetlał inną ikonę? Ja jestem stare pokolenie wychowane na artykułach z "PC Format", "Chip" czy "Komputer Świat" i tam artykuły były pisane w taki sposób że małe elementy interfejsu były inline. Sam nawet nie zamierzam tworzyć takich treści.
Okej, jeśli chcesz napisać coś na szybko, i nie koniecznie włożyć wysiłek w dobrze zbudowaną instrukcję, możemy dać specjalny atrybut <img data-markdown-inline> który pokaże obrazek inline, coś co proponowałem już kilka postów wyżej. Będzie to okej?
obscurity napisał(a):
Ramka też przeszkadza w prezentacji bo ktoś może na przykład "artystycznie" dawać screeny z nieregularnymi kształtami
Znajdź jeden post na forum gdzie ktos tak zrobił.
Nie próbujemy znaleźc rozwiązania które zadziała dla każdego możliwego przypadku, tylko coś co działa na forum. A na forum na razie 99% przypadków, to jest wrzucanie screenów (często kodu lub stron i programów), które wyglądają niefajnie, i to właśnie staramy się poprawić.
Mówię np. o przypadku kiedy ktoś wrzuca screen z telefonu, który jest dosyć wysoki, i często powiększa post tak że post jest wyższy niż cała strona. Myślę że w takiej sytuacji dobrze byłoby go skrócić, i pokazać całośc np. na kliknięcie w obrazek.
Riddle napisał(a):
@obscurity Jest może jeszcze jakiś inny use-case dla takich obrazów inline?
Dałem trzy. Aż tak mi nie zależy żebym wymyślał use-case'y do końca wieczoru ;)
Ja naliczyłem jeden, czyli obrazki inline jako pomóc w instrukcji.