Help! HTML

IFrame spre pagini tip SharePoint Wiki, care să fie editate direct din browser (foarte simplu) și care măcar scot o pagină redimensionabilă?
 
Dupa inca o noapte pierduta aiurea sapand in HTML m-am convins ca e o minune ca merge.

Se da problema cea mai simpla a unui site de web: ai aproape intotdeauna un header comun, un meniu de navigatie, content si footer. Cum poti sa faci ca headerul si footerul, cel putin, sa fie o singura instanta si nu o copie in fiecare pagina, in HTML?
- server side: ASP "include virtual" si gata, s-a rezolvat. Dar merge doar server side si numai daca este activat. Daca serverul e mai chior, gen SharePoint, slabe sperante
- client side: e o ciorba.
1. Faci o pagina cu header, meniu si footer si cu contentul iframe. Cu toate neajunsurile posibile, gen acelasi link pentru toate paginile, paginarea aleatorie per browser, lipsa suport in HTML5. Ciobaneala, dar in general merge.
2. Javascript. Ex. Ars Technica foloseste metoda asta ca sa incarce headerul. Dar Javascript nu e tocmai HTML si nu functioneaza daca e dezactivat din browser.
3. <embed type="text/html" src="header.html"> Functioneaza partial, dar are probleme majore.
a) In primul rand ca ia continutul gata formatat, nu poate sa aplice CSS la continut; header.html trebuie sa fie gata formatat. Se rezolva, dar nu e elegant.
b) este chiar embedded, adica nu porneste din coltul ecranului, are offset de 1 pixel. Si uneori da pe-afara din ecran si creaza scrollbar care nu vrea sa se ascunda. Se rezolva cu multa rabdare in a seta dimensiuni, pargini, padding etc
c) este chiar embedded, adica un click in meniul de navigatie se va deschide in acea bucata de ecran de header, nu in tot documentul. Nu se poate rezolva decat probabil cu Javascript, dar atunci nu merita folosit <embed> ci direct Javascript
d) daca ai un <embed> la sfarsitul documentului, gen footer, nu se poate scapa de scrollbar.
e) Comportamentul IE9 e complet diferit de Opera si Chrome: fara structura completa HTML in fisierul inclus nici unul nu aplica CSS, iar cu structura completa Opera si Chrome merg impecabil, dar IE9 nu mai pune nici macar continutul neformatat.
4. <object name="foo" type="text/html" data="foo.inc"/>. Gasit pe net, nu am reusit sa il fac sa mearga altfel decat <embed>, are aceleasi probleme.

Au adaugat <header> si <footer> in HTML5, dar sunt inutile in a rezolva problema. Sunt doar chestii cosmetice minore folositoare daca ti-e lene sa scrii <div id="footer"> si scrii doar <footer>. Wtf?
 
Nu poți compune un document HTML din mai multe client-side fără scripting. Server-side se poate, cu scripting se poate, dar HTML n-a fost conceput să se auto-modifice. E un model, peste care adaugi un view (css) și un controller (js + server). Controller-ul se ocupă de modificări, nu e bine să le amesteci. Da, există embed, iframes, frames (obsolete), dar toate sunt managed ca fiind pagini independente; le poți lega doar cu scripting (nestandard și complex).
 
Asta stiu, dar nu explica si nu justifica de ce nu se poate. Nu e vorba de a modifica sau auto-modifica, ci de a compune (header + body+ footer), ceea ce e cu totul alta poveste.
 
1. XSS: "Only correct design of Web applications on the server side can fully prevent XSS."
Şi aşa mai departe. Dacă te uiţi, problemele sunt de fapt cauzate ori de web designeri tâmpiţi, ori de useri tâmpiţi. Da' mă rog... cum zici tu.
 
Știi cum e un intranet corporate - ți se pune sub nas un calculator ale cărui setări le poți schimba într-o măsură mai mică sau mai mare, dar deseori sunt resetate periodic cu niște valori stabilite de cineva, după o logică mai mult sau mai puțin coerentă. Iar ca developer, trebuie să faci să meargă o chestie într-un mod frugal, fără overengineering, ținând cont ȘI de aceste limitări impuse. Sigur, ar fi minunat să ai output multiplu generat server-side în funcție de browserul identificat, inclusiv Android, iPhone, BlackBerry etc. Dar nu-ți dă nimeni buget să faci așa ceva pentru câteva pagini de help.

Adi, limitarea e by design: e un document structurat care trebuie să conțină tot ce e nevoie să afișeze. Nu poți folosi un .asp server-side ca referință în toate link-urile, al cărui unic scop e să asambleze un header, un footer și între ele numele fișierului trimis ca parametru GET?
 
De ce ti-ar reseta periodic desktop-ul, ca developer? E unealta cu care lucrezi, fiecare si-o bibileste cum ii place si simte nevoia.
 
Nu am nici un fel de suport server-side. Si problema se aplica si in cazul in care vrei sa faci cateva fisiere help locale html, daca vrei sa modifici un header ajungi sa schimbi manual in fiecare fisier.

Nu e vorba de o problema punctuala, pe-a mea am rezolvat-o deja si am trecut mai departe, sunt doar niste constatari pe care le-am facut despre limitarile nu tocmai logice ale standardului. Am mai descoperit o gramada de probleme legate de formatarea paginilor (modul in care elementele se aseaza in pagina), diferente intre browsere etc., dar e relativ surprinzator pentru un standard care tine internetul pe picioare (ca si continut).
 
Să trăiască Microsoftu' care de la bun început a dat cu flit standardelor (în devenire la acel moment) și și-a definit propria interpretare a HTML și JavaScript, apoi și CSS. Acum a pierdut dominația pe web și, forțat de împrejurări, plays nice și se apropie ceva mai bine de standard, dar tot mai are câte o răbufnire stil „așa facem NOI” la poziționarea elementelor, aliniere și parametri proprii.

Pentru help local, nu e mai bine să faci un fișier help standalone, compilat într-un format „standard” dintr-un authoring tool? Formatul CHM e deprecated de o juma' de deceniu. Windows 7 are .h1k/.h1s/.h1t/.h1c care e de fapt MAML, Office 2007 deja a trecut pe Microsoft Help 2 și Visual Studio 2010 merge pe Microsoft Help System 1.x (MS Help 3) cu fișiere .mshc. Avantajele la un asemenea format ar fi că folosești un editor pentru content creation, are TOC și căutare.

O alternativă comercială de authoring+publishing ar fi Adobe RoboHelp, care îți publică conținutul în format HTML5 interactiv pentru desktop, web, mobile și print. Direct de la Adobe costă 999€ + TVA. Merită pentru cineva care face în mod regulat documentație multi-platformă, dar pentru utilizare ocazională e over-overkill.
 
De ce ti-ar reseta periodic desktop-ul, ca developer? E unealta cu care lucrezi, fiecare si-o bibileste cum ii place si simte nevoia.

Mie nu mi-l reseteaza ca lucram de pe desktopul meu de-acasa si oricum nu sunt developer, pe laptopul de la birou am doar Office si Lync, restul chestiilor gen SQL Management Studio si Toad nu fac parte din munca mea oficiala si orice resetare de configuratie nu ma afecteaza in nici un fel. Atata timp cat nu e laptopul meu si e doar pentru uz in interes de serviciu chiar am un motiv in plus sa nu imi pese, daca se strica ceva sau nu merge pun un tichet si nu incerc sa mai repar singur. Pana se repara folosesc computerul meu :smile:

Dar e foarte util sa mai reseteze din cand in cand setarile computerului la cele corporate. Daca incerci sa faci o aplicatie cu cateva mii de utilizatori e mai simplu si mai ieftin sa ai o singura configuratie de suportat decat zeci. Tocmai ca incompatibilitatile dintre browsere sunt un cosmar pentru suport si suportul costa bani, atunci standardizezi si simplifici. Oamenii isi mai schimba setarile, suna dupa suport, li se spune sa le puna la loc ca o sa mearga, chiar merge, problem solved.

dar pentru utilizare ocazională e over-overkill.
Exact. Si nu fac CHM, ci niste pagini html care sunt gazduite acum pe un server de SharePoint, asta inseamna zero suport server-side si vreau totusi portabilitate si usurinta in utilizare. Paginile au link-uri catre aplicatii si link-uri catre documente (PDF), HTML e modalitatea cea mai simpla sa le fac pentru ca oricine are un browser, iar paginile scrise de mine manual (ca hobby, nu ca job) sunt testate sa mearga in orice browser major - in afara de IOS le-am testat deja. Nu e un job, e doar un hobby intr-un weekend, dar nu ma impiedica sa vad ca situatia nu e tocmai roza.

Btw, detest uneltele gen SharePoint Designer sau chiar Word care genereaza continut HTML in care partea utila e sub un sfert. Una din pagini fusese modificata de un coleg, stii de cate ori am gasit <span lang="ES-CR"></span> in cod? Si vorbesc de tag fara nici un continut, nu doar ca specifica o limba inutila dar nu contine nimic in interior. Sau SAP Netweaver, genereaza pagini de 1.5 MB bucata pentru un ecran 2/3 gol, doar un header si un meniu de navigare.
 
Nu exista niciun standard pentru web. Exista specificatii si validatoare de sintaxa, dar nu exista niciun validator de rendering sau implementare rendering de referinta. Iar specificatiile nu-s perfecte. Asa ca toata lumea face mici interpretari pe ici si colo unde sunt lacune. Si cu fiecare noua versiune din fiecare browser se creaza un milion de pagini care respecta idiosincrasiile lui, si apoi toate celelalte in veci si pururea trebuie sa pastreze backwards compatibility pentru ca altfel piata iti va refuza produsul. E un cerc vicios perpetuu.

Google "Martian headsets" si cititi-l daca n-ati facut-o deja.

PS: Si nu se fac inserari de markup direct in documente existente pentru ca ar introduce complicatii enorme. Modul limitat in care a ales Microsoft sa implementeze asta e cam singurul mod de-a o face corect, si te-ai convins cat de util este. Inserarea de documente se face ori incapsulat si izolat in iframe, ori cu JavaScript care poate manipula modul de integrare in DOM la un mod explicit.
 
De curiozitate: cam care ar fi complicatiile? Sunt riscuri de securitate, dar cand descarci o pagina de pe un server nici nu mai conteaza daca agregarea continutului e server side sau client side, iei asa cum iti vine.

Iframe functioneaza, dar nu e solutia perfecta, are aplicabilitate limitata. Javascript e iarasi o solutie, dar mi se pare overkill pentru chestii de baza precum cele ridicate de mine. Orice complicatie face codul mai ineficient, mai greu de citit (hint: JavaScript) si mai greu de controlat (adica mai vulnerabil).
 
E o limitare de proiectare. Arhitectura protocolului HTTP şi modelul REST pornesc de la premisa că se primeşte o resursă per cerere, punct. Un document HTML este strâns integrat cu pagina randată şi cu browserul conform DOM. Are tot felul de proprietăţi (charset, meta etc.), un singur head şi body, o anumită logică de parsare şi randare.

Orice incluziune de alt document ar complica mult lucrurile. Cum îl integrezi în structura documentului părinte? Ce charset foloseşti dacă apar conflicte? Ce meta şi alte proprietăţi au prioritate? Cum procedezi dacă un document inclus dă timeout sau răspuns non-ok? Cum procedezi cu implicaţiile de securitate? şamd

Evident, dacă se voia se puteau aborda şi rezolva problemele astea. Dar nu s-a vrut din cauza contextului cronologic şi modului în care a evoluat tehnologia.

Imediat după inventarea HTTP şi HTML, prima cerinţă a fost să se insereze imagini, care fiind un tip diferit de resursă au fost integrate fără probleme. A apărut curând după aceea problema ta, de refolosire a HTML, dar a fost foarte natural să fie rezolvată server-side (Server Side Includes, CGI), pentru că browserele erau extrem de "dumb" iar pe server side exista deja un mecanism versatil care a putut fi extins. Frames au fost introduse iniţial pentru a simula widgets de tip panel şi pentru a permite vizionare side-by-side, nu neapărat pentru navigare (dar se pot folosi şi aşa). Iframes au apărut mai târziu. Când a apărut JavaScript a început să capete tot mai multe puteri de-a modifica dinamic pagina, care s-a combinat perfect cu introducerea DOM.

Şi uite aşa a trecut timpul şi-n momentul de faţă există un munte de tehnologie "standardizat" de facto. Nu mai are nimeni chef să abordeze problemele alea şi să introducă suport pentru incluziune de HTML în HTML pentru că toată lumea foloseşte soluţii server side şi JavaScript extrem de puternic pe client-side şi-ar fi redundant.

N-a zis nimeni că e cea mai fericită situaţie. Web-ul aşa cum e în ziua de azi n-a fost proiectat de la zero cu vreun plan măreţ în cap ci a crescut ca buruienile din 1000 de tehnologii diferite dintre care unele au supravieţuit şi unele nu, după cum le-a fost norocul şi cheful pieţei.
 
Hmmm, pe SharePoint cred că s-ar putea face un Wiki pentru adăugarea/editarea conținutului dorit fără bătăi de cap, și apoi se modifică view-ul cu Designer ca să se scoată toate bălăriile de sidebar, menubar, navigare, search etc. și să rămână doar header, page content și footer. Dar munca de a desluși Designer-ul și tot restul probabil depășește efortul de a încropi rapid niște HTML-uri.
 
Dacă vrei, poţi să mai procedezi cum făceam acum 20 de ani când nu aveam suport SSI sau CGI pe server: foloseşti un program care asamblează HTML-urile din bucăţi şi le încarci pe server gata combinate. Un punct de pornire.

Dar nu e nevoie neapărat de ceva atât de elaborat, e suficient să scrii prima pagină, apoi pui header/footer/body în fişiere separate şi cu un simplu script combini corpurile de pagină cu header şi footer.
 
Da, e o explicatie rezonabila.

Eu mi-am rezolvat de mult problema practica, ramasese doar curiozitatea. Si cred ca suntem in vremurile in care parintii isi invata copiii sa scrie HTML inainte de a-i invata sa pescuiasca (daca o mai fac, nu am idee).
 
N-aş merge chiar aşa de departe. Să-şi facă un website da, dar HTML e deja ceva specializat, mă îndoiesc că învaţă mulţi oameni asta.
 
Back
Top