Poprawiałem formatowanie w artykule @Marooned Kurs pisania systemu operacyjnego, część 1 i natknąłem się na buga. Jeśli nagłówek jest otoczony linkiem (<a><h2>), to wtedy renderer artykułu dokleja </p> w dosyć losowym miejscu.
Bug zreprodukowany tutaj: https://4programmers.net/Madmike/Bug_z_linkami_dooko%C5%82a_nag%C5%82%C3%B3wk%C3%B3w
Nie jestem pewien, czy to bug. Szukam w internecie informacji na ten temat, ale ciężko to uchwytne. Zauważ, że umieszczasz element, który jest domyślnie block-level element (H2) w elemencie, który jest domyślnie inline element (A). To może powodować zamieszanie dla parsera HTML (nie wiem, jak wyglądają style CSS w tym przypadku).
Załączę źródło strony, z której zrobiłeś zrzut ekranu, tak jak wygląda w Firefoxie 90.0:
<p><a></a></p><h2><a>Test</a></h2><a></a><br>
test test</p>
<p>test test</p>
(O, jest nawet <, co do której miałem wątpliwości w innym wątku w Coyote ;)).
A po sformatowaniu przeze mnie dla lepszej przejrzystości:
<p>
<a></a>
</p>
<h2>
<a>Test</a>
</h2>
<a></a>
<br>
test test</p>
<p>test test</p>
Dwie rzeczy warte odnotowania, które widzę póki co:
A występuje trzykrotnie w kodzie wynikowym, podczas gdy w kodzie źródłowym został umieszczony jednokrotnie;</p>, który widać wyrenderowany, jest renderowany z ciągu znaków </p> (czyli z ciągu znaków /p otoczonego referencjami).PS Załączam kod źródłowy dla porównania:
<a><h2>Test</h2></a>
test test
test test
Silv napisał(a):
Nie jestem pewien, czy to bug. Szukam w internecie informacji na ten temat, ale ciężko to uchwytne. Zauważ, że umieszczasz element, który jest domyślnie block-level element (H2) w elemencie, który jest domyślnie inline element (A). To może powodować zamieszanie dla parsera HTML (nie wiem, jak wyglądają style CSS w tym przypadku).
Załączę źródło strony, z której zrobiłeś zrzut ekranu, tak jak wygląda w Firefoxie 90.0:
<p><a></a></p><h2><a>Test</a></h2><a></a><br> test test</p> <p>test test</p>(O, jest nawet
<:P).A po sformatowaniu przeze mnie dla lepszej przejrzystości:
<p> <a></a> </p> <h2> <a>Test</a> </h2> <a></a> <br> test test</p> <p>test test</p>Dwie rzeczy warte odnotowania, które widzę póki co:
- Element
Awystępuje trzykrotnie w kodzie wynikowym, podczas gdy w kodzie źródłowym został umieszczony jednokrotnie;- samotny znacznik
</p>w kodzie wynikowym jest otoczony referencjami<oraz>.
Nawet jeśli jest jakieś uzasadnienie, czemu parser miałby zamknąć </p>, to to nie jest żaden uzasadnienie czemu miałby wyświetlić "</p>". To jest bug.
Silv napisał(a):
Nie jestem pewien, czy to bug. Szukam w internecie informacji na ten temat, ale ciężko to uchwytne. Zauważ, że umieszczasz element, który jest domyślnie block-level element (H2) w elemencie, który jest domyślnie inline element (A). To może powodować zamieszanie dla parsera HTML (nie wiem, jak wyglądają style CSS w tym przypadku).
A czemu niby display elementu miałby wpływ na parsowanie HTML? Jeśli tak jest, to to na 100% jest bug. Są w specyfikacji HTML'a wpisy o tym że niektóre elementy nie mogą mieć innych w sobie, ale to nie ma związku z tym czy coś jest inline czy block.
A po drugie, mówiłeś że bug występuje z <a> bo jest inline. Dodałem do strony przykład z <p>, który jest block i to samo zachowanie.
TomRiddle napisał(a):
Silv napisał(a):
A po drugie, mówiłeś że bug występuje z
<a>bo jestinline. Dodałem do strony przykład z<p>, który jestblocki to samo zachowanie.
O, dobry pomysł. Ciekawe, kod wynikowy HTML jest inny: między innymi element P nie występuje potrójnie (jak element A), a pojedynczo. Tak to wygląda (po sformatowaniu przeze mnie dla przejrzystości):
<p>
<a></a>
</p>
<h2>
<a>Test</a>
</h2>
<a></a>
<br>
test test</p>
<p>test test</p>
<p></p>
<h2>Test</h2>
</p>
<p>test test</p>
<p>test test</p>
PS Załączam kod źrodłowy dla porównania:
<a><h2>Test</h2></a>
test test
test test
<p><h2>Test</h2></p>
test test
test test
Tak czy tak, to jest bug.
Więc jeśli ktoś wpisze <a><h2>Tytuł</h2></a>, to mamy dwa rozwiązania (i trzecie trochę dziwne):
A. mamy klikalny nagłówek - to jest coś na co się pozwala od HTML5 (moim zdaniem to się powinno stać)
B. zgodność z HTML4 - po prostu usuwamy <a>, nagłówek nie klikalny
C. (to by było dziwne trochę), ale wtedy mogłoby nie być linka ani nagłówka, tylko po prostu zobaczylibyśmy "<a><h2>Tytuł</h2></a>" (tak jak teraz jest w markdownie, jak się np nie uda sparsować <h2>``hey``</h2>, to widzimy backticki.
Załączam informacje, które do tej pory znalazłem odnośnie poprawności występowania elementu H2 w elemencie A:
https://stackoverflow.com/a/9760109
You can only place
<h2>elements within<a>elements if you're working with HTML5, which allows any other elements within<a>elements. Previous specifications (or current ones however you want to look at them) never allowed this.
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-a-element
The a element can be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g., buttons or other links).
Ponieważ kod wynikowy posiada preambułę <!DOCTYPE html>, uznaję, że powinno zachodzić tutaj parsowanie zgodne z HTML Living Standard.
TomRiddle napisał(a):
Poprawiałem formatowanie w artykule @Marooned Kurs pisania systemu operacyjnego, część 1
:O
Pierwsze słyszę, bym pisał jakiś artykuł, a już tym bardziej o pisaniu systemu operacyjnego. W historii rzeczywiście pokazuje mnie jako pierwszego autora. @Adam Boduch kojarzysz temat? Czy 14 lat temu jakiś szczwany hacker włamał mi się na konto by podbić moją reputację na dzielni i w moim imieniu napisał coś sensownego?
O rany, ale sieczka. Poprawiłem trochę formatowanie. Podejrzewam, że to biblioteka HTMLPurifier próbuje "naprawić" zepsuty kod HTML.
@Marooned napisałeś w historii że przywróciłeś omyłkowo usunięty artykuł. Nie jestem w stanie powiedzieć więcej co tam się stało.
Adam Boduch napisał(a):
O rany, ale sieczka. Poprawiłem trochę formatowanie. Podejrzewam, że to biblioteka HTMLPurifier próbuje "naprawić" zepsuty kod HTML.
No większość artów w kompendium taka jest, dlatego chodzę i poprawiam :D