Błąd parsera

powinno być
if (y<a) or (x>b) or (x<c) or (y>d) then result := true else

w uszach
if (y<a>b) or (x<c) or (y>d) then result := true else

bez uszu
if (y<a) or (x>b) or (x<c) or (y>d) then result := true else

Kurcze, tutaj parser doszukuje sie znacznika <a> :/ Moze wiec wylaczyc ten znacznik na forum?

To wtedy psuć się będzie if (y<url>b) - to by trzeba było raczej naprawić, by olewał tag, który nie ma zamknięcia

Ten parser jest dosyc rygorystyczny. Tu jest kod filtra HTML: http://redmine.boduch.net/projects/coyote/repository/entry/trunk/lib/filter/html.class.php
Ale przechodzi rygorystyczne testy XSS.

Czy przeglądarka w ogóle spróbuje sparsować element z niedozwolonymi według filtra atrybutami, gdy będzie zawierać błędy (coś innego niż atrybuty)? Jeśli tak, to można tylko wywalać niedozwolone atrybuty, a resztę appendować: http://pastebin.com/HMNp8VFu (wiem, nie umiem php)

Dla wejścia: a<b || b>c
daje: a<b || b>c

Dla wejścia: a<b niedozwolony="1" dozwolony="2" || b>c
daje: a<b dozwolony="2" || b>c

Poza tym, po co filtr w uszach, skoro tam html i tak nie działa(?) ?

Tak. Przegladarka bedzie parsowac znaczniki HTML, ktore zawierala nieprawidlowe, niezgodne ze specyfikacja atrybuty.
Przykladowo:

<a foo="bar">bar bar</a>

rezultat:

bar bar

@Adam Boduch, dlaczego nie zastanowisz się nad jakimś generatorem parserów z gramatyk bezkontekstowych? Gdzie wyrażenia regularne będą jedynie częścią leksera, a nie próbowały tworzyć całą gramatykę? Obecnie wygląda to tak, że każdy przypadek, każdy wyjątek, którego nie da się sparsować prostym wyrażeniem trzeba hackować, każda niejednoznaczność powoduje kolejne obejścia.
Gdybyś użył np. takiego ANTLR, miałbyś o wiele większą możliwość np. reagowania na błędy parsowania i takie przypadki jak powyższy mógłbyś bez (większego) problemu rozwiązać.

W przypadku niepozamykanych tagów wyrażenie regularne w ogóle go nie ruszy (bo spodziewa się tagu zamykającego; nie ma? to na razie), a w przypadku parsera wygenerowanego przez w/w dostaniesz ładną informację: "parsuję właśnie linię tą, kolumnę tamtą, według takiej reguły, spodziewano się tego, tego albo tego, ale dostaliśmy to, co zrobić?".

Ale zagladales w kod, ze uwazasz, ze tworza cala gramatyke na regexpach, czy tylko tak domniemujesz? ;)

Czegokolwiek byś tam nie miał to tworzysz jakąś gramatykę. Problem w tym, że w obecnej postaci kodu ciężko ci ją poprawnie wyrazić i tyle.

edit: widzę, że zedytowałeś swojego posta już po mojej odpowiedzi ;].
Oczywiście, że nie tworzysz całego parsera na samych wyrażeniach regularnych, problem w tym właśnie, że obchodzenie niedoskonałości gramatyki opartej na wyrażeniach regularnych trzeba obchodzić masą specjalnych przypadków, hacków, kilkoma przebiegami, wielokrotnym filtrowaniem.
To prowadzi do tego bałaganu właśnie, który próbujesz ogarnąć od początku Coyote Forever i wciąż jest masa niedoskonałości, z czego połowy z nich nie da się w sensowny sposób usunąć.

nie chcę nikogo popędzać ale jest to dość denerwujące a zgłaszałem prawie 2tyg temu

w code
__**test**__
tekst
test
w uszach
__**test**__

w code
**__test__**
tekst
test
w uszach
**__test__**