CSS Problem z pozycjonowaniem tekstu

Mam cytat, ktory wisi sobie pod rozległym tekstem.
Wszystko było dobrze do czasu kiedy pewna osoba zażyczyła sobie obowiązkowego i ściśle zdefiniowanego układu.

Jakiś tam tekst na stronie ....

<p style="font-size: 14px; text-align: left;">  
      Ptak ptakowi nie jednaki<br />
      Człek człekowi nie dorówna<br />
      Dusza duszy zajrzy w oczy<br />
      Nie polezie orzeł w gówna<br />
      <span style="font-size: 10px;">St. Wyspiański - "Wesele"</span>
</p>

Jak zrobić żeby niezależnie od czcionki i jej wielkości zdanie o autorze zawsze kończyło się równo z ostatnią literą 'a' wyłącznie z jego ostatnim zdaniu "Nie polezie orzeł w gówna"..

Próbowałem i kombinowałem z osobnymi DIV'ami w jednym test-align left w drugim right i oraz proba zlaczenia tego na rozne sposoby. Ale zawsze bylo cos nie tak. Ma ktoś może pomysł...?

w css to chyba nic z tego nie wyjdzie. ale jeżeli możesz umieścić każdy wiersz z tego cytatu w osobnym elemencie blokowym, to możesz wspomóc się javascriptem - mierzysz szerokość ostatniego wiersza z cytatu, mierzysz szerokość podpisu, i wyrównujesz dodając jakiś tam margin-left.

Tego się obawiałem...
O JavaScripcie to pomyślałem na samym początku, ale chciałem znaleŹć prostsze wyjście i jak na razie opracowałem coś takiego...

    <div class="paddingTop">
    <table class="noBorderTable" border="0" cellspacing="0" cellpadding="0">
      <tr><td style="text-align: left;">
      Ptak ptakowi nie jednaki<br />
			Człek człekowi nie dorówna<br />
			Dusza duszy zajrzy w oczy
      </td></tr>
      <tr><td>
      <table class="noBorderTable" border="0" cellspacing="0" cellpadding="0">
      <tr><td style="text-align: left;">
      Nie polezie orzeł w gówna
      </td></tr>
      <tr><td style="text-align: right;">
      <div class="infAuthor">St. Wyspiański - "Wesele"</div>
      </td></tr>
      </table>
      </td></tr>
    </table>
    </div>

kod CSS:

.infAuthor {
  font-style: italic; 
  font-size: 8px;
  text-align: right;
  padding: 0px;
  margin: 0px;
}

.noBorderTable {
border: 0px dotted black;
border-spacing: 0px;
padding: 0px;
margin: 0px;
}

.paddingTop {
padding-top: 15px;
padding-left: 150px;
}

Sprawdza się też od IE 6, co prawda po specjalnych modyfikacjach dla IE ;) ... Co za pomylona przeglądarka

porąbane jak jasna cholera, no ale niegłupie. wczoraj pewnie nie byłem w stanie nic lepszego.. /ach, ja to rano pisałem/

łapaj to - chyba mniej porąbany kod, a działa (wydaje mi) się tak samo ;)
http://jsbin.com/ifivem/edit#html,live

IE6 to możesz olać - już przez chwilę poniżej 1% ludzi w Polsce go używało, IE7 także - teraz jest 3% (wg ranking.pl) - nie chcą biedaki zaktualizować - to niech mają zabugowane strony

Tak na chama to da się to zrobić w raczej prosty i jasny sposób:

http://jsbin.com/imecak/edit#html,live

Zerknijcie na CSS-y. Istotne są tylko trzy deklaracje, te z własnościami font-COŚTAM to tylko dekoracja.

Problem jest z markupem, czyli z HTML-em. To coś powyżej skleciłem w chwilę, ale przez ten czas nie objawiło mi się, jak ostylować poprawny markup. Musiałem uciec się do niepoprawnego i bezsensownego. Wy też to zrobiliście w swoich rozwiązaniach, a moje jest -- zdaje się -- nieco prostsze, więc je zamieszczam.

Poprawny, semantyczny HTML do tego cytatu wyglądałby mniej-więcej tak:

  <figure class="quote">
    <blockquote>
      <p>
      Ptak ptakowi nie jednaki<br />
      Człek człekowi nie dorówna<br />
      Dusza duszy zajrzy w oczy<br />
      Nie polezie orzeł w gówna<br />
      </p>
    </blockquote>
    <figcaption>
      St. Wyspiański - "<cite>Wesele</cite>"
    </figcaption>
  </figure>

Niestety nie udało mi się zmusić powyższego markupu do pożądanego zachowania za pomocą CSS. Jeśli jeszcze nad tym posiedzę i coś wymyślę, to na pewno dam znać.

(sorki za dubel, nie mogę się zalogować z tego terminala)

Przehackowałem się tak, żeby uzyskać właściwy markup. To już jednak jest hack:

http://jsbin.com/aworip/4/edit

No ale markup przeważnie jest ważniejszy niż kod arkuszy stylów.

W porównaniu do szkicu w poprzednim poście, do HTML-a musiałem dorzucić jedynie kilka spanów -- po jednym na każdą linię. Z punktu widzenia semantyki są "nadmiarowe", ale zupełnie dla niej przezroczyste, tj. niczego nie psują. Usunąłem też ostatnie
-- ale nie dlatego, że musiałem, tylko dlatego, że uznałem je za zbędne (wstawienie go ponownie nic nie zmieni). Całość otoczyłem też kontenerem div.quote-container i użyłem go jako prostego clearfixu -- na to są też inne, bardziej skomplikowane metody, które jednak nie wymagają dodatkowego elementu.

W stylach użyłem pseudoklasy :last-child by wybrać ostatniego spana. Przez samo to, style nie zadziałają w IE starszym niż IE8. Można jednak to bardzo łatwo obejść, dając ostatniemu spanowi klasę span i używając jej zamiast pseudoklasy.

Problem ze stylowaniem polegał na tym, że chcieliśmy wizualnie spiąć ostatni wiersz i podpis z informacją o źródle. Wystarczyło wrzucić obie rzeczy do jednego elementu-kontenera, co zrobiłem w działającym przykładzie w pierwszym poście (kontener .last-line-and-source). Ten kontener jednak sprawiał, że w markupie ostatnia linia cytatu i informacje o źródle były ściśle powiązane. Byłem zmuszony, by były zawsze razem. Nie mogłem więc użyć blockquote, bo on powinien zawierać tylko cytat, bez informacji o autorze. Nie mogłem też użyć figcaption (które musi być bezpośrednio w figure), bo ono może zawierać tylko informacje dodatkowe, a nie ostatnią linię.

Teraz, udało mi się to rozdzielić. Każdą linijkę umieściłem w spanie i starałem się sprawić, by tylko ostatni span wpływał na szerokość całego elementu figure. Użyłem ujemnego text-indent by wywalić tekst ze wszystkich spanów (oprócz ostatniego) w kosmos w lewo, a następnie dodatniego position: relative żeby wizualnie wróciły na swoje miejsce, jednak już bez zajmowania poziomej przestrzeni. Ostatni span nie ma tych sztuczek, tj. ma zresetowaną pozycję i text-indent do zerowych wartości. Dlatego on wpływa na szerokość figure (które opina ściśle swoją zawartość i nie rozchodzi się na całą szerokość, bo ma float: left).

Potem wystarczyło tylko dać text-align: right na podpisie -- i już był przyczepiony do prawego brzegu figure, który to prawy brzeg kończy się równo z ostatnią linią, bo wszystkie inne linie wywaliliśmy z równania.

Słuchajcie REWELACYJNA ROBOTA !

Ja i pewnie cała masa użytkowników też jest wam lub będzie wdzięczna :)
Pierwszy przykład jest czytelny i działa nawet na IE6. NIE DZIAŁA W IE 6 !, moje rozwiązanie jednak jest bardziej kompatybilne;
Choć strasznie nie eleganckie.

Drugi prawdziwie "hakerski", super wyjaśniony...
Fajnie wiedzieć że w razie czego można użyć innego rozwiązania !

załączam rozwiązanie które zastosowałem na swojej stronie przepisując je od Dzek69.
załączam rozwiązanie od Dzek69, bo jeśli komuś nie zależy tak jak mi na kompatybilności z IE 6 to te dwa będą na pewno odpowiednie.
Co prawda drugiego nie testowałem.
Aby inni użytkownicy tego forum mogli w razie czego mieć pełny podgląd na sprawę...

p.s.
fajny serwis ten jsbin oraz

Ulubione motto:     
      <div class="someSpeak">
      <p>
      Ptak ptakowi nie jednaki<br />
      Człek człekowi nie dorówna<br />
      Dusza duszy zajrzy w oczy
      </p>
        <div class="alignToLast">
         <span class="last">Nie polezie orzeł w gówna</span>
         <span class="alignAuthor">St. Wyspiański - "Wesele"</span>
        </div>
      </div>

a kod CSS to:

.someSpeak {
padding-top: 15px;
padding-left: 150px;
line-height: 16px;
}

.someSpeak .alignToLast {
display: inline-block;
}

.someSpeak .alignToLast span {
display: block;
}

.someSpeak .alignToLast span.alignAuthor {
text-align: right;
font-size: 8px;
font-style: italic;
}

.someSpeak .alignToLast span.last, .someSpeak p{
text-align: left;
font-size: 12px;
margin: 0px;
}

Znalazłem rozwiązanie naszego problemu w internecie... jednak mogę zastosować rozwiązanie od "dzak69"

ale należy zmodyfikować ten skrypt w następujący sposób, dodając 1 linijkę kodu i modyfikując drugą...

     <div class="someSpeak">
      <p>
      Ptak ptakowi nie jednaki<br />
			Człek człekowi nie dorówna<br />
			Dusza duszy zajrzy w oczy
      </p>
       <div style="display: inline;"> <!-- konieczny poprzedzający element blokowy z display: inline; --> 
        <span class="alignToLast"> <!-- musi być element span -->
         <span class="last">Nie polezie orzeł w gówna</span>
         <span class="alignAuthor">St. Wyspiański - "Wesele"</span>
        </span>
       </div> 
      </div>

http://kurs.browsehappy.pl/Bugi/InlineBlock

@dzek69:
Tak, tam powinno być "IE starszym niż IE8" -- dobrze, że zauważyłeś. W ogóle w kolejnym zdaniu też się "popisałem", pisząc zupełnie bez sensu, żeby spanowi dać klasę span ;-). Chodziło mi o klasę last. Się zdziebko spieszyłem -- tak naprawdę i tak dłużej pisałem posta niż to rozwiązanie.

"Ale generalnie - jakby tak myślał nad super haxiorskim cssem do każdych 5 elementów to w życiu by żadna strona nie powstała :P"
Chyba że byłyby fundusze, a jakość markupu miałaby pierwszorzędne znaczenie.

Ja, widząc coś takiego, pewnie bym się szarpnął na jakieś kombinowanie. Ale ja nie jestem przeciętnym frontendowcem i nie pracuję w przeciętnym frontendowym teamie. Akurat niedawno mieliśmy w zespole mini-dyskusję na temat cytatów. Taki suchar markupowy jak pozostałe rozwiązania (zarówno to Twoje, jak i to moje są analogiczne) na pewno nie przeszedłby u nas bez echa (i odpowiedniego flejmu ;) ) na code review.

Super haxorowanie nie zdarza się jednak często. W każdych 5 elementach byłoby... niepraktyczne. Bardziej niż o fundusze przy tworzeniu bałbym się nawet o masakrę przy utrzymaniu różnych takich hacków. Bo właśnie gdy nie tylko tworzysz strony, ale również je utrzymujesz, jakość kodu ma znaczenie. Tutaj jakość HTML-a jest niestety odwrotnie proporcjonalna do stopnia skomplikowania CSS-a.

Ostatni projekt, jaki (współ)tworzę, ma parę ładnych tysięcy CSS-a. Nie pisałem całości, choć większość, ale nie przypominam sobie ani jednego przypadku użycia hacków tego kalibru. Gdyby więc zdarzyło mi się jedno takie miejsce, mógłbym sobie zaszaleć i pozwolić na bardziej skomplikowane style. I nie byłoby to "każde 5 elementów", tylko "5 elementów na witrynie, która liczy ich setki".

Co do samego CSS-a, to nazwałem go "hackiem", ale tak naprawdę korzystamy ze standardowego, udokumentowanego rozwiązania, do którego dotarłem po paru minutach logicznego rozumowania, a nie kodując przypadkowo. Nie jest więc aż tak źle, tyle że nie jest to też całkiem prosty kod. A nieoczywistego kodu powinniśmy unikać.

@nixon:
BTW: sugeruję nie używać nazwy "skrypt" gdy mówimy o czystym HTML-u (kod znaczników) i CSS-ie (kod arkuszy stylów). Gdy mówimy w kontekście front-endowym, "skrypt" raczej jest zarezerwowany dla JavaScriptu ;)

@bswierczynski - chyba dalej Ci się śpieszy, bo napisałeś, że tam powinno być "IE starszym niż IE8" - a przecież właśnie tak jest :P ... starszym niż IE9 ;)

Chyba że byłyby fundusze, a jakość markupu miałaby pierwszorzędne znaczenie.

Ale po co?
Strona w Googlach nie skoczy na pierwsze miejsce dlatego, że zamiast DIV użyjesz BLOCKQUOTE, bo mimo, że pewne rzeczy są ważne, to jednak największe znaczenie ma tekst. Nawet kumpel-grafik - zrobił na freelancerce stronę z usługami minikoparką - choć było dużo lepszych stron, na ładnym w miarę kodzie - to "pocięta" przez niego statyczna strona na tabelkach, w tabelkach, w tabelkach od 2 lat wisi na pierwszym miejscu po wpisaniu hasła "usługi minikoparką [miasto jakieś, którego nie pamiętam]" :)

dzek69 napisał(a)

@bswierczynski - chyba dalej Ci się śpieszy, bo napisałeś, że tam powinno być "IE starszym niż IE8" - a przecież właśnie tak jest :P ... starszym niż IE9 ;)

LOL! #fail

Tak: "starszym niż IE9". [sprawdza, czy udało mu się tym razem napisać 4 słowa bez błędu]

dzek69 napisał(a)

Ale po co?
Strona w Googlach nie skoczy na pierwsze miejsce

Co po co?

W jakich Googlach, panie?

Jeśli każdy wykonuje swoją robotę idealnie, to strona w Google jest na szczycie listy jeśli jest dobra i przydatna.

Sam markup nie sprawi, że taka się stanie.

Natomiast może (powinien) poprawić wyniki dla fraz, o których strona traktuje -- i ewentualnie obniżyć dla fraz, które na stronie mają marginalne znaczenie/są słabiej opisane. I to jest dobre.

Google korzysta z różnych estymat przy uwzględnianiu rankingu. Markup to jedna z nich, integralna z treścią (inna, bardzo ważna: linki przychodzące). Nie działa to idealnie, niestety. Czasami na SERP-ach wciąż widzimy pełno crapu. To już nie moja robota, tylko ich. Ja jestem front-endowcem. Moim zadaniem jest m.in. opisanie semantyki dokumentu. Tabelki (w tym przypadku) tego kompletnie nie robią. Div z błędnie zastosowanym paragrafem też nie (paragraf w markupie kończy się w 3/4 paragrafu rzeczywistego = markup robi więcej szkody niż pożytku).

Znaczenie ma semantyka. Ustandaryzowana.

Reszta w rękach twórców innych narzędzi.

W rękach programistów z Mountain View, ale też typków kodujących przeglądarki, w tym te mobilne, czytniki ekranu, wszelkiej maści crawlery/parsery etc. Ja mogę powiedzieć im, co jest czym w dokumencie. Aż tyle i tylko tyle.

Mógłbym się też tym nie przejmować i dać im zupę pozbawionych znaczenia tagów. Z taką semantyką to oni za wiele już nie zrobią, bo nie mają jak.

Podobnie, copywriter też mógłby się nie przejmować swoją robotą i stworzyć dla strony słaby tekst, z dużą ilością pozbawionych znaczenia słów (szczególnym problemem jest to w nagłówkach, wstępach, początkach akapitów).

Grafik mógłby dać stronie byle jaki układ, bez uporządkowania elementów (również pod względem ważności).

Google by się to nie spodobało, choć witryna i tak mogłaby być wysoko w SERP-ach dla określonych fraz, np. ze względu na liczbę i wagę linków przychodzących lub ze względu na słabość konkurencji. Uczciwie zdobyte linki przychodzące mogą świadczyć o tym, że za stroną kryje się po prostu dobra usługa, co zawsze jest kluczowe dla biznesu.

Słabe wykonanie w żadnym razie jednak nie poprawia sytuacji na stronie, a na pewno obniża jej użyteczność, osłabia UX.

Ja tam nie myślę o SERP-ach tworząc kod strony. Chcę po prostu najlepiej opisać semantykę dokumentu i tyle. To w niczym nie przeszkadza. Nawet jeśli chodzi o koszt witryny bywa z tym różnie. Dobry specjalista jest znacznie droższy jednostkowo, ale ma mniej błędów w kodzie, a strona z dobrym kodem wcale nie musi powstać dłużej od takiej ze słabym kodem. Dotyczy to dużych witryn. Można sklecić na pałę coś małego, ale jeśli nie masz dyscypliny i pewnych umiejętności, to dorzucanie nawet stylów do witryny, która ma już ładnych kilka tysięcy linii CSS-a to prawdziwa udręka i bugi regresyjne. Należy pamiętać, że całkowity koszt witryny to koszt budowy pierwszych 80% kodu, drugich 20% i koszt utrzymania. Wtedy jakość odpłaca. (A poziom skomplikowania przeszkadza.) Bardzo często zdarzają się projekty robione olewczo, które na początku zdają się iść dobrze, a pod koniec zwalniają -- tempo zwalnia asymptotycznie niemal do zera ;) Koderzy mówią, że dali ciała w ostatnich 20%, które szły wolno. Często jednak dali ciała w pierwszych 80% ze względu na uchybienia jakościowe, i pozostałe 20% męczarni (trwających drugie tyle co pierwsze 80%) było tylko tego skutkiem.

Swoją drogą, agencje interaktywne często olewają kwestie utrzymaniowe. Nie dają czasu na zastanowienie się nad markupem, na przegląd kodu, refaktoryzację. Wszystko ma być "na wczoraj", a jak na produkcji pojawia się jakiś błąd, to dopóki klient tego nie zauważy, to jest OK. Podejście staranne potrafi nie być cenione w agencjach, bo i koderzy są tak strasznie poganiani, że ciężko im przysiąść nad jakimś trudniejszym kawałkiem kodu i zrobić go porządnie.

Się zrobiła niemal dyskusja filozoficzna ;).

Hm, to żeby nie było - ja nie uważam, że strony powinno się pisać robiąc zupę z <table> <tr> i <td>, o nie nie. Lubię html5 i te semantyczne znaczniki - ale jednak nie rozkminiałbym tego tak długo jak ty - tj blockquote ok (nawet o nim nie myślałem), ale moje spany bym zostawił i z ich pomocą bym wyrównał. no i niepotrzebnie ten <p> zamykałem, racja ;)

także - semantyka ok, ale bez paranoi ;]

ale ty lubisz długo pisać.. czasem też lubię, choć najczęściej potem robię ctrl+a, backspace, no bo kto to będzie czytał :D

dzek69 napisał(a)

jednak nie rozkminiałbym tego tak długo jak ty

Długo...? W mojej głowie to się dzieje dość szybko. Więcej czasu zajmuje opisanie tego, wytłumaczenie, a nawet sprawdzenie w niestandardowym środowisku (nie mam "przy sobie" mojego środowiska programistycznego i dlatego korzystałem z JSBina).

Podczas rozkminki często zagląda się do specyfikacji. Akurat odnośnie figure kumpel z teamu do mnie w zeszłym tygodniu poszedł i pogadaliśmy o tym kilka minut, analizując specyfikację HTML5 dla elementów figure, blockquote i figcaption. I już to wiemy na przyszłość, więc np. przy tym topicu od razu wiedziałem jak powinien wyglądać kod. To się opłaca.

HTML5 jest wciąż bardzo młodu i brakuje konwencji i przypadków użycia. Każdy wie, że do zakodowania menu nawigacyjnego w HTML-u 4 trzeba było użyć listy. W HTML-u 5 semantyka jest znacznie bogatsza, bardziej kontrowersyjna. KTOŚ musi te praktyczne przypadki użycia wyznaczać. Niestety, na stronie specyfikacji też jest ich niezbyt wiele. Ci "KTOSIE" (zwykle: topowi koderzy / koderzy udzielający się w community / koderzy-bloggerzy) powinni wypracowywać przypadki użycia na podstawie uważnego przeczytania specyfikacji -- tego, co w niej już jest. Zresztą, tak powinien robić każdy odpowiedzialny koder, nawet jeśli nie chce szerzyć wiedzy na szerszą skalę (ja np. bloga nie prowadzę, a w community się na dużą skalę nie udzialam i mi to nie przeszkadza).

dzek69 napisał(a)

moje spany bym zostawił i z ich pomocą bym wyrównał.

Ja te nie wzmzđliem jak się tu obejść bez jakiegoś odrożnienia ostatniej linii od reszty (tj. bez np. spana). Nie wiem czy da się to zrobć, może jakoś z CSS3 (text-align-last itp.), ale wsparcie tego mizerne.

dzek69 napisał(a)

tj blockquote ok (nawet o nim nie myślałem)

Nie myślałeś o blockquote przy ewidentnym cytacie?

Hmm, tak czy siak, użycie blockquote przy tej strukturze z ostatnią linią związaną z podpisem byłoby błędne. blockquote nie powinien zawierać informacji o autorze, tylko samą treść cytatu. Jakbyś użył blockquote'a i tego klasycznego rozwiązania divem na końcu, to div (tj. ostatnia linia+podpis) musiałby być albo wewnątrz blockquote -- i wtedy byłoby źle, bo podpis byłby wewnątrz cytatu, a nie powinien -- albo na zewnątrz. I wtedy ostatnia linia cytatu byłaby poza blockquote, co również jest niesemantyczne.

Stąd ten "hack".