Co treba specialni atribut pro vsechny html znacky ktere canvas ma videt, treba.:
<div canvas="visible-all-childs">
... vsechno tady canvas uvidi...
</div>
Implementace zni slozite (aby se odfiltrovaly SVG a pod.), pokud se neudela jednoduchym dvojitym renderovanim, t.j. do offscreen transparentniho buffra (v podstate do canvas) by se vyrenderoval jenom ten <div> a podstrcil canvasu jako zdroj pixelu. Tohle by podle mne slo implementovat relativne jednoduse, vcetne dynamicke zmeny DOM.
V principu je to souboj o to, co je canvas. Jestli je to doplnkovy nastroj k tomu co web browser jiz umi, nebo jestli je to oddeleny modul. To prve by bylo mnohem uzitecnejsi. Je to univerzalnejsi (t.j. ma to vetsi moznosti), min narocne na vyvoj a na adopci do stavajicich aplikaci. Proste jednou za cas kdyz se vam to hodi, tak tam nejaky ten canvas prihodite a nechate ho udelat tu extra praci navic co HTML nezvladne.
To, ze aktualne je to oddeleny modul, se projevuje treba jiz na navrhu funkci pro kresleni textu, ted kazdy browser krome toho ze tento problem jiz musel vyresit pro obycejne zobrazeni textu v HTML bude muset mit dalsi znacny kus (nekterym lidem mozna "wrapper" nad low level funkcemi neprijde az tak hrozny, ale podle mne kdyz je jen vysledkem spatneho navrhu, tak je to spatny hodne) kodu ktery udela to same pro canvas. Vyrobci browseru pro mobilni zarizeni budou urcite stestim bez sebe, kolik zbytecne zabrane RAM kodem timhle pristupem vznika. (flash je typicky priklad v podstate nezavisle aplikace uvnitr jine aplikace ktere vzajemne delaji spoustu stejnych veci, ale kazda naprosto vlastnim kodem a stylem ... canvas IMHO miri stejnym smerem, jenom bude tento kod navic integrovan ve zdrojaku k tomu puvodnimu)
Takze ve finale je vysledkem mnohem omezenejsi nastroj a snizeni kvality zdrojoveho kodu browseru (co ma dopad na vykon, bezpecnost a rychlost vyvoje).
IMO canvas jako oddeleny modul je zbytecny balast navic, tech par veci co umozni podle mne nestoji za to kolik prinese problemu a dalsi bobtnani browseru samotnych. Tech par demo ukazek mne nepresvedcili, ze by to stalo za ty dusledky, co jsem videl by slo nahradit flash nebo java appletem. Jesti nekomu vadi ze oboji vyzaduje externi plugin, tak v tomhle pripade je to podle mne jen slovickareni, teoreticky canvas je pak na stejne urovni jako kdyby se Adobe domluvil s Mozillou, pridal zdrojaky flash playeru do jejich repozitare a spravovali to spolecne jako jeden projekt.
(nasledujici odstavec je myslen obecne bez ohledu na existenci canvas, ale je snad zrejme co z toho pro canvas vyplyva)
Browserova platforma pro hry je sice v principu velmi neefektivni vymysl, ale prakticky se jiz ted pouziva (vid. treba Quake live, snaha o 3D engine u Opery a Googlu, ruzne java/flash hry a i ciste HTML/CSS hricky), bud jsou hry na urovni toho co aktualni platforma umoznuje, nebo se to obchazi ruznymi pluginy typu shockwave nebo primo activeX komponentou. Takze tenhle vyvoj uz zastavit nepujde. Jednotne, jednoduche a vykonne [a zdarma, idealne otevrene] API nativne implementovane v browserech by pomohlo v tom, ze bude jednodussi udelat browser pro nove platformy s podporou temer vseho co by bylo na webu k nalezeni. Ruzne pluginy zpusobuji ze treba platforma bez flash playeru ma aktualne velky problem a spousta "internetu" pak "nefunguje".
Jestli to chapu tady z reakci spravne, tak SVG umi manipulovat s tim co se vykresluje v HTML jinym zpusobem? (ja SVG nikdy nestudoval, bral jsem to jako vektorovy graficky format) Neni to uplne stejna dira jako canvas?
Pozor, ted se ptam jako laik ktery o dane problematice nic konkretniho nevi, takze se omlouvam jestli je to uplne spatne, ale ma naivni predstava je, ze k cemu ma pristup originalni DOM, k tomu ma pristup i js z daneho DOMu, ne? T.j. kdyz neco zobrazuje nejaky tajny obrazek, tak by to IMHO melo jit v jscriptu dane stranky nacist jako soubor byte po bytu a odeslat si to na vlastni server pres nejaky ajax dotaz. Takze bezpecnost takoveho obrazku je tak velka, jak tezke je vlozit takovy zakerny jscript do dane stranky. Prijde mi to stejne jako problem s tim ze canvas vidi veci z daneho DOMu taky, ten taky by vysledny obrazek odeslal jenom tam, kam ho jscript zamiri, ne?