Nikt ze znajomych nie jest mi w stanie odpowiedzieć, a od paru lat problem mnie co jakiś czas zastanawia. Stąd zagadka:
Dlaczego wymuszone złamanie linii w HTML jest elementem, a nie encją?
Odpowiedzi można nadsyłać w komentarzach, redakcja zastrzega sobie prawo do nie zwracania nadesłanych materiałów.
Yyy… może nie ma znaku unicode, który określa złamanie linii? A encje to chyba tak raczej do znaczków unikodowych się przypisały niż do formatowania ;-)
tego akurat nie wiem.. ale wiem, że w XHTML 2.0 będzie taki element jak linia tekstu a ‘br’ odejdzie do lamusa.. też mi on nigdy nie pasował.
mcv: niezupełnie. Są np Przypuszczam, że to po prostu jeden z pierwszych elementów, które się pojawiły. A dalej poleciało na zasadzie “kompatybilności wstecznej” :)
kurde. miało być ‎ ‏
medyk:
To będzie automatyczny element, nie będziesz musiał każdej linii zamykać w tagi.
nbw:
Wszystkie trzy są znakami Unicode. Podobnie jak ­ i znak końca linii.
Może dlatego, że ‘konstruktorzy’ pierwszych HTMLi nie myśleli co robią, albo po prostu nie wiedzieli, że kiedyś to będzie coś więcej niż zupa tagów…
HTML był przecież na początku niezwykle prostym językiem i chyba takim miał pozostać według pierwotnych zamiarów. Ot, taki spadek.
Myślę, że najlepiej będzie zapytać Domela :]
Niestety nie posiadam wiedzy, ktora powolila by mi na sto procent stwierdzic dlaczego (bo 12 lat temu jeszcze sie tym nie interesowalem). Chodzi najprawdopodobniej o to, ze wtedy poprostu nikt na to nie wpadl. Zreszta zapewne kierowal sie tym, ze to co jest widoczne powinno byc reprezentowane przez znacznik/atrybut a nie przez encje. Zreszta szczerze watpie zeby w ISO 8879:1986 istniala taka encja (jesli ktos by to sprawdzil to chetnie sie dowiem) wiec jesli jej nie bylo to nie mozna bylo z niej skorzystac ;-) . Do tego dochodzi sprawa, ze to bylo robione przez IETF a nie przez W3C, a to oznacza, ze najpierw ma dzialac a pozniej spisujemy specyfikacje, co z wiadomych powodow zwieksza prawdopodobienstwo glupot. A dalej to bylo tak jak napisal nbw. Czyli w imie “kompatybilnosci przenosimy wszsytkie bledy”. Dopiero XHTML 2.0 odcina sie od wszystkich bledow nalecialych przez te 15 lat. Jesli taki projekt, zeby w XHTML 2.0 zniknely wszystie encje (lacznie ze znakowymi, bo przeciez teraz jest unikod a nie jakies tam 8859-1).
Na marginesie mala uwaga: nie ma co mieszac do tego encji typu & shy ; i unikodu bo przeciez wtedy jeszcze nikt nie wiedzial, ze takie cos jak unikod jest wogole mozliwe :-)
@Patrys: Co oznacza “automatyczny element”?
a co jest do wygrania? ;)
@Domel: automatyczny == automatycznie wstawiany? :)
Domel:
AFAIK, to linia nie ma być tyle elementem DOM sensu structe (tag otwierający i zamykający), co magicznym pseudoelementem, takim jak ::before i ::after.
xard4s:
W XHTML nie ma automatycznie wstawianych elementów, tylko HTML pozwalał na pomijanie pewnych części dokumentu, które były automatycznie generowane przez agenta (jak
<body/>,<head/>itp.).Może wzorowano się na jakimś innym wariancie SGML, w którym “złam linię” było a nie &encją;? ;-)
Ups, chciałem sobie fajnie napisać i się schrzaniło…
Może wzorowano się na jakimś innym wariancie SGML, w którym „złam linię” było <znacznikiem> a nie &encją;? ;-)
Marcoos:
To samo pytanie można odnieść do dowolnego narzecza SGML :)
Patrys:
Raczej to nie możliwe. Skąd te informacje?
Zaleta tagów jest to, że mogą one przyjmować argumenty. znacznik BR przyjmuje kilka takich :)
Karolaq, w sumie racja, czesto ja np uzywam przy tworzeniu layoutow w polaczeniu ze stylem, w ktorym znajduje sie “clear : both”, bardzo przydatna sprawa :) , chyba ze sie da zastapic :P
Domel:
Takie propozycje kiedyś padły w dyskusji pomiędzy W3C i HTML WG. Nie śledzę tego na bieżąco teraz, bo nie mam tyle czasu, więc moje dane mogą być mocno nieaktualne. W każdym razie była koncepcja, żeby wiersze były pseudoelementami generowanymi w locie.
Karolaq, ziom:
Od tego jest
<hr/>i<separator/>.Patrys:
To musiałbyć jakiś mały epizot bo nawet nie pamiętam takiego wątku ale napewno to jest nie aktualne. Najbliżej akceptacji jest atrybut layout (nie mylić z xml:space).
W różnych systemach operacyjnych są różne sposoby kodowania znaku nowej linii, br informuje ze ma byc w tym miejscu wstawiony znak nowej linni odpowiedni dla danego systemu, sa/moga byc/byly przegladarki, ograniczone mozliwosci platformy, ktore moga wyswietlac powiedzmy 127 znakow wiec olewaja encje i wyswietlaja je jak widza, a dostajac znacznik br zastepuja go, wlasciwym dla siebie, znakiem nowej linii.
MOldar:
Przeglądarka niczego nie może sobie z założenia olać. Musi rozkodować encję i dopiero wtedy uznać, czy potrafią ją wyświetlić, czy ma ją zastąpić informacją o brakującym znaku.
A opisana przez ciebie przeglądarka powinna zepsuć każdy poprawnie złożony tekst, zawierający niełamliwe spacje przed spójnikami.
Dokładnie tak, zresztą opisana przez Moldara sytuacja nie miała ani nie ma miejsca. Problem zasugerowany przez Patrysa faktycznie istnieje ale w XHTML 2.0 będzie rozwiązany, myśle idealnie. Długo był dyskutowany, było wiele podejść ale chyba wypracowaliśmy już końcowe rozwiązanie czyli layout=”relevant” i zwykłe znaki końca linii lub znacznik l (przy okazji podział semantyczny się pojawia).
Ale prawda jest taka, że tak naprawdę lepsza jest zupa tagów niż zupa encji, więc chyba jednak dobrze się stało :-) .
Patrys: Gdzie jest napisane że nie może olać?
Na poczatku w HTML nie bylo encji ‘nbsp’… pozatym jesli tekst dojdzie do brzegu ekranu i tak bedzie zlamany, a coś takiego jak znak nowej linii musi sie wyróżniac w kodzie chociazby dla parsera ktory przy pierwszym przejsciu ze wzgledu na wydajnosc ignorowalby encje …od tamtego czasu minelo kilkanascie lat.
Domel: Nigdy nie możesz być pewien co gdzie nie ma miejsca.
Patrys… dlaczego po prostu nie wyślesz majla, z tym pytaniem, do w3c?
MOldar:
1. Napisane jest w specyfikacji.
2. Nie, własnie o to chodzi, że w nbsp nie bedzie złąmany
3. Nie musi, parsery działają nie tylko na znacznikach muszą również, przykładem jest BOM w pareserze XML
4. Mogę być pewny, bo widziałem wszystkie powszechne przeglądarki jakie były do tej pory wyprodukowane. Bo przecież nie mówimy o wyjątkach typu pan kazio napisał przeglądarkę w 100 liniach kodu (ktora oczywiście nie jest zgodna ze specyfikacją)
5. Może dlatego, że to wymyślała IETF a nie W3C?
ad. 4 Zjadło mi kilka wyrazów więc wyjaśniam: “…muszą również być brane pod uwagę inne czynniki, np. znaki, przykładem jest BOM w parserze XML. Jeszcze dodam, przy okazji, że jakoś w white-space (CSS) / znacznik pre to działa, to samo będzie z layout=”relevant” i pokrewnie jest z xml:space w XML-u.
Ja bym tylko chciał zwrócić uwagę, że encje nie służą tylko do kodowania pojedynczych znaków. Encje mogą być czymkolwiek. Nawet elementami.
Eksperyment do przemyślenia (działa w Operze):
“>
]>
Wilk syty i owca cała
blah&br;blah&br;&br;cone
Ja bym tylko chciał zwrócić uwagę, że encje nie służą tylko do kodowania pojedynczych znaków. Encje mogą być czymkolwiek. Nawet elementami.
Eksperyment do przemyślenia (działa w Operze):
<?xml version=”1.0″?>
<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”
[<!ENTITY br "<br/>">]>
<html>
<head>
</head>
<body>
<p>blah&br;blah&br;&br;cone</p>
</body>
</html>
{o}: Zgadza się ale Patrys mówił (tylko) o encjach _znakowych_.