Piekło zamarzło: Apple broni starego HTML
Google ciągnie sieć do przodu, Apple broni semantycznego HTML. Kiedy strony zaczyna składać AI, a projektant widzi tylko czat i podgląd, przewagę ma ten drugi.
Kiedy czytałem stanowisko WebKit w sprawie WebMCP, miałem przed oczami reklamę Apple z 1984 roku w reżyserii Ridleya Scotta. Biegaczka z młotem, szare szeregi, wielki ekran. Wtedy Apple był buntownikiem przeciw dominującemu graczowi. Czterdzieści dwa lata później role się odwróciły. Dominujący gracz przynosi nową warstwę i ciągnie sieć do przodu, a Apple broni starego, wspólnego standardu. Piekło zamarzło: Apple jest tym konserwatywnym.
Apple ma oczywiście swoje interesy. Kontroluje jedyny silnik przeglądarki na iPhonie i od lat słyszy, że hamuje rozwój sieci. Spowolnienie WebMCP spowalnia też agenta Google w Chrome. Ale argument ocenia się po treści, a nie po tym, kto go wypowiada. A w tej sprawie, moim zdaniem, Apple ma rację.
Jedno źródło prawdy
Semantyczny HTML przetrwał dekady. Przycisk, który jest przyciskiem, i pole z etykietą działają dla człowieka, dla czytnika ekranu i dla agenta. WebMCP to szybka próba poprawy sytuacji dla agentów. Może też próba zbudowania standardu i trzymania go w swoich rękach. Tyle że gdyby strony były semantyczne, WebMCP w większości przypadków nie byłby potrzebny. Człowiek, czytnik i agent czytaliby z jednego źródła, bez rozjazdu między dwiema warstwami.
Nie w każdym przypadku. Zostają wieloetapowe operacje i akcje, których skutków HTML dziś nie opisuje. Ale to jest ogon, a nie fundament. WebKit zresztą sam to przyznaje: najpierw semantyka dla ludzi, a osobne uzupełnienie dla agenta dopiero wtedy, gdy semantyka nie wystarcza. To ta sama zasada, którą opisałem w tekście „Ogon, który udaje fundament”.
Projektant z okienkiem czatu
Wczoraj Elegant Themes pokazało pierwsze spojrzenie na Divi MCP. Agent AI w Divi już jest, teraz builder będzie można prowadzić z czatu, z ChatGPT, Claude Code czy Cursora. Builder od zawsze ukrywał kod przed projektantem. Builder połączony z AI ukrywa już nawet siebie. Zostaje okienko rozmowy i podgląd efektu.
Projektant ocenia to, co widzi człowiek. Nikt w tej pętli nie patrzy na to, co widzi agent. Semantyka przestaje być rzemiosłem kogoś, kto pisze kod, i staje się ustawieniem domyślnym narzędzia. Jedna decyzja producenta buildera poprawia albo psuje setki tysięcy stron naraz.
Myślę, że to przesądza sprawę na korzyść semantyki. Skoro strony coraz częściej będzie składać AI, nikt nie będzie ręcznie sklejał źle opisanego kodu, a narzędzie może generować dobry HTML z założenia. Osobna warstwa dla agentów jest potrzebna tylko wtedy, gdy strona jest zła. WebMCP wygląda mi więc na protezę na czas przejściowy, a nie na fundament następnej dekady.
Co zostaje
Zostaje pomiar. Kiedy kod znika z oczu, jedynym sposobem, żeby wiedzieć, co widzi agent, jest to zmierzyć. Audyt Lighthouse dla agentów liczy do wyniku drzewo dostępności, a nie WebMCP. AI View w narzędziowni iFOX pokazuje, co agent wyciąga z kodu strony i gdzie się gubi. Projektant z okienkiem czatu nie zajrzy do kodu, ale może sprawdzić wynik. I w świecie, w którym strony pisze AI, to właśnie powinno stać się jego nawykiem.
Szczegóły stanowisk przeglądarek, daty i źródła zebrałem w tekście „WebMCP pięć miesięcy później”.