Защо съществува ‹a›, а не изпращане на формуляр от тип метод get?

Просто съм любопитен защо HTML има anchor таг, използван за предварително формиране на GET заявки специално без възможност за промяна на типа HTTP заявка, или в противен случай защо не използваме конвенцията за подаване на формуляр, тъй като може да имаме възможността за get-променливи така или иначе.

По-интересно е как anchor таговете се свързват с #id секции на същата страница.

Има ли добра причина или това е просто догматичен остатък?

Редактиране: Не питам какво правят, поставям под съмнение конвенцията на anchor таговете и подаването на формуляри.

Защо това не е елемент на HTTP заявка, който покрива тези бази и по подразбиране е GET, така че да работи с връзка? Защо беше взето решение за тази конвенция. Казвам, че ми звучи безумно и искам да знам дали има някакво оправдание от момента, в който е взето решението.


http html history
person Incognito    schedule 09.11.2010    source източник

Отговори (3)


arrow_upward
1
arrow_downward

Котвата свързва два документа или части от документи, т.е. текущия и референтния. Но формулярът не го прави. Формата е за изпращане на запитвания. Това е.

person Gumbo    schedule 09.11.2010
comment
Тогава защо позволяваме GET променливи в HTTP заявки? - person Incognito; 10.11.2010

arrow_upward
1
arrow_downward

Маркерът <a> се използва за навигиране от една страница към друга, което изисква само GET заявки. И тъй като URL адресите поддържат възможността за изпращане на променливи (напр. ?a=b), няма абсолютно никаква нужда от по-сложен таг.

Очевидно тагът <a> е вграден елемент, докато тагът <form> е блоков елемент. Така че можете да заключите, че маркерите за котва трябва да бъдат прости, докато елементите на формуляра може да са малко по-сложни.

person Harmen    schedule 09.11.2010
comment
Вярно, но кодът за връщане и съдържанието не зависят от това какъв метод на заявка е използван. Например, можете лесно да получите един ресурс, който да върне два резултата с различни методи на заявка. Тагът A всъщност не е вграден, тъй като трябва да дефинирате inner-html, което така или иначе може да превърне нещото в блок, независимо от факта, че браузърът не свързва никакви входни елементи с него. Бих могъл също толкова лесно да създам хиперлинг, който прави <form method="get" action="example.com"><input type="hidden" name="arg" value="1"><input type="submit">Go there</submit></form> - person Incognito; 10.11.2010
comment
равно на `‹a href=example.com?arg=1›щракнете тук‹/a›, но конвенцията изглежда наистина странна - person Incognito; 10.11.2010

arrow_upward
1
arrow_downward

По-лесно е да използвате get, защото можете да извършите цялото действие с един низ и без допълнителни тагове. Той е кратък и прост и е идеален за повечето приложения за предаване на параметри и навигация.

POST е за формуляри и прикачени файлове. GET е ограничен по размер, POST не е.

По-интересно е как anchor таговете се свързват с #id секции на същата страница.

Има ли добра причина или това е просто догматичен остатък?

Не, хешираните URL адреси все още са полезни и са добър резервен вариант без JavaScript за навигация в страницата. Хешираните URL адреси вече се пренасят на следващото ниво, за да се поддържа състояние и маркиране на страници, базирани на AJAX.

person Diodeus - James MacFarlane    schedule 09.11.2010