[css] meer css met htc voor IE

[Clay]

Omdat IE toch enigszins beperkt is mbt css ondersteuning en we er toch nog wel een tijdje aan vast zitten dacht ik; waarom bouwen we het er zelf niet in dan? Zo wil ik bijvoorbeeld gewoon min-height kunnen gebruiken, en als ik iets met left, top, right en bottom definieer wil ik dat het de juiste dimensies aanneemt. Ook in combinatie met padding, border en min- height en width.

Omdat het alleen in IE hoeft te werken heb ik een test htc gemaakt. Die link je als behavior aan de body, en die gaat dan recursief door het document lopen en al het werk voor je doen;

HTML:

<style type="text/css">
body {
    behavior:url("css.htc");
}   
</style>

In de htc zit een klein stukje jscript dat het hele document uitkamt:

HTML:

<attach event="ondocumentready" handler="initCSS" />
<script language="JScript">

function initCSS() {
    parseNode(this);    
}
    function parseNode(node) {
        if(!node || !node.currentStyle) return;

        // - hier - iets met node doen

        for(var i=0; i<node.childNodes.length; i++) {
            parseNode(node.childNodes[i]);
        }
    }

...

En dan beginnen de problemen In de testcase heb ik een CSSElement object gemaakt die met een validate() functie css properties uitleest en volgens de standaard probeert toe te passen. properties hebben eigen "fix" functies, en als ze inderdaad nodig zijn kunnen ze zichzelf aan een resize event koppelen, zodat er niet teveel meuk aan de resize event komt te hangen:

JavaScript:

ResizeListener = {
    actions:[],
    add:function(scope, func) {
        this.actions.push(function(){
            scope[func]();
        });
    },

    trigger:function() {
        for(var i=0; i<this.actions.length; i++) {
            this.actions[i]();
        }
    }
}

ResizeListener.trigger(); hangt met een attachEvent aan het window. Een CSSElement kan dan b.v. de fixMinHeight functie aan de resize hangen met:

JavaScript:

ResizeListener.add(this, 'fixMinHeight');

Tot zover werkt het. Het moet alleen wel goed gaan werken en de problemen komen bij het opvragen van waardes uit de currentStyle en node zelf. Een simpele parseInt gaat niet werken, want 2em is niet 2px, en ik wil b.v. wel 2em van 100% af kunnen trekken, een element met:

Cascading Stylesheet:

    position:absolute;
    left:100px;
    top:100px;
    right:100px;
    bottom:100px;

    border:1em solid silver;
    padding:1cm;
    background:#f0f0f0;

zal b.v aan alle kanten die 100px moeten hebben. de width wordt dan (met padding en border alletwee left en right) met het w3c boxmodel: 100% - 2cm - 2em. Mozilla/firebird doen dat uiteraard vanzelf, in IE moet het berekend worden...

Wat ik dus eigenlijk zoek is een mooie generieke manier om met niet teveel code te kunnen rekenen met totaal verschillende eenheden. Een manier is b.v. om een factor te gebruiken en het cssElement bij de init vol te stauwen met omgerekende pixelwaarden. Maar misschien zijn er veel betere (en niet statische) andere manieren. Als dit een keer werkt en niet te groot of zwaar wordt wil ik het namelijk ook gewoon standaard gaan gebruiken

[Woudloper]

Goed punt wat je hierboven meld en ook wel een nobel streven om middels een IE only feature de browsers (IE, Mozilla, Firebird, etc) gelijk proberen te stellen..

Ik heb er net even over na zitten denken, maar zo ik het zie kan je alleen gaan voor het voorbeeld wat jij geeft, dus het cssElement voorstouwen met pixelwaarden. Echter ben ik niet wiskundig aangelegd. Wel denk ik dat je vraag verwarrend is m.b.t. het subject van je topic aangezien deze naar mijn idee niet in lijn zijn met elkaar...

[Clay]

Het ophalen van de juiste pixelwaarden (makkelijkst mee te rekenen) is een deel van het geheel, de hele aanpak is ook maar uit mijn duim gekomen en misschien zijn er betere duimen. Alles staat wat mij betreft ter discussie
Ik zal ook ff kijken of ik vanavond een demo online kan zetten van wat ik dan heb.

Ik ben al weer ietsje verder, en heb dit er nu bijstaan;

JavaScript:

function getPixels(node, attr) {
    var value = node.currentStyle[attr], 
        iVal = parseInt(value);

    if(isNaN(iVal)) return 0;
    else if(value.indexOf('px') > 0) return iVal;
    else if(value.indexOf('pt') > 0) return iVal * (4/3);
    else if(value.indexOf('em') > 0) return iVal * getPixels(node, 'fontSize');
    // %,  iVal * getPixels(node.parentNode, attr); ?
    else return 0;
}

Alleen luistert dit nog redelijk nauw. em leid ik af uit de fontsize, en pt lijkt 1.33n keer px. Vooralsnog lijkt het ook nog goed te gaan zonder ergens een fontsize op te geven (1em == 16px?)

[ Voor 7% gewijzigd door Clay op 05-11-2003 11:25 ]

[Anoniem: 9542]

je wilt dus iets van 1cm = 28 px, ervan uitgaande dat je scherm 72 dpi is, het lijkt me sterk dat het mogelijk is de resolutie van je scherm op te vragen, dus dit zal je vast moeten stellen. Misschien eens kijken in andere browsers of ze hier een vaste waarde voor nemen en welke dat dan is (bv een boxje verschillende breedtes is cm geven en de offsetWidth uitlezen, maar dat hoef ik je niet te vertellen neem ik aan )

om 1 em om te rekenen in px zou je hetzelfde kunnen doen, probleem is dan wel dat 1 em groter wordt als je je fontsize aanpast (toch?) misschien kan je ergens een invisible span parkeren waarvan je de hoogte uitleest, da's even de enige (zeer ranzige) oplossing die ik kan bedenken

Heb eigenlijk geen idee of er ergens generieke variabelen rondzwerven om dit uit te lezen (currentStyle.lineHeight misschien?)

Verder een prachtig plan, zie ik zeker het nut van in

[Clay]

resolutie zit in screen.width en height maar cm moet ik nog naar kijken.

om 1 em om te rekenen in px zou je hetzelfde kunnen doen, probleem is dan wel dat 1 em groter wordt als je je fontsize aanpast (toch?) misschien kan je ergens een invisible span parkeren waarvan je de hoogte uitleest, da's even de enige (zeer ranzige) oplossing die ik kan bedenken

Met die functie van hierboven lijkt em al goed te gaan. Die kijkt (dus idd met font-size) ook recursief naar boven (dus theoretisch kan dat erroren of hangen ) maar b.v. dit:

Cascading Stylesheet:

font-size:20pt;
border:1em solid silver;

geeft met getPixels op borderLeftWidth nu 26.66n terug, en als ik wat ik op mn scherm zie met een screendump meet in photoshop zie ik 27 pixels

[ Voor 7% gewijzigd door Clay op 05-11-2003 11:35 ]

[Anoniem: 9542]

Clay schreef op 05 november 2003 @ 11:34:
resolutie zit in screen.width en height maar cm moet ik nog naar kijken.

met resolutie bedoel ik de dpi, jij hebt het over afmetingen. Ik gok dat dit ook een standaard getal is overigens, kwestie van proberen

[Anoniem: 32071]

Er is al zoiets dergelijks ooit eerder gemaakt, geloof ik.
http://www.doxdesk.com/software/js/minmax.html
Ik hoop niet dat ik nu de pret heb bedorven...

[Anoniem: 9542]

da's alleen voor de min-height etc, en werkt alleen in px, clays idee is veel uitgebreider

[crisp]

beetje offtopic: mijn ervaring is dat stack-based door je document structuur heenlopen vele malen efficienter is dan recursief

[Clay]

Anoniem: 32071 schreef op 05 november 2003 @ 12:05:
Er is al zoiets dergelijks ooit eerder gemaakt, geloof ik.
http://www.doxdesk.com/software/js/minmax.html
Ik hoop niet dat ik nu de pret heb bedorven...

Nee hoor pret is niet bedorven. Maar dit is dus de javascript oplossing, en die wil ik juist niet toepassen. Ook de intervals en timeouts die daarinzitten wil ik juist voorkomen.

[Anoniem: 32071]

Nou, gelukkig maar
Ik had een tijdje geleden een vraag mbt tot defaultView, dat ik daar alleen px-waardes terug kreeg, terwijl ik de cascaded waarde wou (dus em).
In IE is dat dus mogelijk met currentStyle.
Als ik het nu goed begrijp, kun je dus geen absolute waardes terugkrijgen (zoals in defaultview)? Ik dacht dat runtimeStyle daar voor was, maar dat is dus niet zo?

edit:
inderdaad via behaviors is een goede oplossing.
Inderdaad, nee dus. Aan runtimestyle heb je niks.

[ Voor 14% gewijzigd door Anoniem: 32071 op 05-11-2003 12:55 ]

[Anoniem: 9542]

obj.offsetLeft, right, width en height geven je px terug, verder weet ik het zo ook even niet

[Woudloper]

Heb je wellicht iets aan onderstaande berekening:

code:

1 Inch = 90 px
1 pt   = 1/72 Inch = 1.25px

Hierbij ben ik uitgegaan van het aantal DPI = 72.

Naar mijn idee was dit namelijk de manier waarop het ging...

[Clay]

Het gaat toch niet helemaal lekker een element met alleen min-width en max-width moet tussen die grenzen op width:auto; staan, en daarbuiten op een pixelwaarde om de min en max te simuleren. Maar de onresize is zo ijverig dat de max toch weer op auto uitkomt, en de min de browser ophangt met een interval werkt dezelfde code wel en dat wil ik nou net niet.

[Anoniem: 9542]

waarom wil je geen interval? een kort interval zou voldoende smooth moeten blijven werken lijkt me

[Clay]

Ja, maar dan heb je dus een constante interval en dus code lopen, tegenover netjes event based waar er alleen maar wat geupdate wordt bij b.v. een resize van een gebruiker, en anders nooit.

[Anoniem: 9542]

oh, ik zat anders te denken:
als je onresize je code uitvoert, dan een vlaggetje zet, een timer laat lopen die je vlaggetje weer uitzet en alleen je aanpassen uitvoeren als je vlaggetje er is, dan verminder je zeg maar de frequentie van je onresize event

[Clay]

idd. hij doet nu iets dergelijks, de onresize zet een delay, en zolang je blijft resizen wordt de delay gereset, en zo dus vooruit geschoven. dat simuleert dan een soort onResizeEnd.

Ben ook ff naar selectors gaan kijken, en een :hover moet wel te bouwen zijn voor alle elementen, maar + en > en verschillende : selectors gaan niet werken zonder extreem vieze hacks. Je kan in IE wel de styleSheets uitlezen, en de selectorText van een rule object opvragen, maar voor alles wat IE niet kent poept die dan UNKNOWN uit, erg irritant.

De :hover komt gelukkig wel overal terug, en die is via htc ook wel overal aan te koppelen. Alleen een hover zou bv. ook zo kunnen staan:

Cascading Stylesheet:

div#menu li.item:hover {
}

Je zou de selectorText kunnen uitlezen en met addRule een rule toevoegen voor elementen met een hover, die die een speciaal hover htc'tje includet oid. Of je zou een array met referenties moeten vinden naar alle li's in #menu met class "item". Je ziet soms ook dat mensen een getElementsByClass bouwen, dat principe leek me wat handiger dan rules adden, maar dan niet byClass, maar obv een css rule, dit is er uitgerold;

PHP:

<script type="text/javascript">

document.getElementsBySelect = function(rule) {
    function findNodes(tag, docs) {
        var nodes = [];
        for(var i=0; i<docs.length; i++) {
            var res = docs[i].getElementsByTagName(tag);
            for(var j=0; j<res.length; j++) nodes.push(res[j]);
        }   return nodes;
    }

    function filterNodes(select, docs) {
        var s = (/\#|\./).exec(select);
        if(!s) return findNodes(select, docs);
        var rule = select.split(s);
        var nodes = findNodes(rule[0], docs);
        var filtered = [], val = rule[1];
        var atr = ((/\#/).exec(select))? 'id':'className';
        if(atr) for(var i=0; i<nodes.length; i++) {
            if(nodes[i][atr] == val) filtered.push(nodes[i]);
        }   return filtered;
    }

    var nodeList = [document];
    var sets = rule.split(' ');
    for(var i=0; i<sets.length; i++) {
        nodeList = filterNodes(sets[i], nodeList);
    }   return nodeList;
}

...

en dan kan je bv in een document een array opvragen net als een css rule:

PHP:

...

   var elements = document.getElementsBySelect('div#main p.content');

</script>

Hiermee wil ik dus die :hovers gaan koppelen (nog ff kijken hoe). Het kan vast korter, is misschien nog buggy (gebrek aan checks) en je kan bv. niet werken met + en > selectors, maar de basis werkt iig

[SchizoDuckie]

Clay schreef op 09 november 2003 @ 17:08 een geniaal verhaal:

ik kan nie w88 tot dit allemaal feilloos werkt
Zeker weten dat als je dit dan publiceert er over de hele wereld een aantal 's vandaan gaan komen

[bakakaizoku]

wat moet ik me eigenlijk voorstellen bij HTC ?

een soort van units zoals bij C++ (.h) en pascal (.tpu) worden gebruikt ?
(heb wel gekeken op een site over dit, maar kwam er niet helemaal uit)

[ Voor 23% gewijzigd door bakakaizoku op 09-11-2003 17:52 ]

[Clay]

mattttt schreef op 09 november 2003 @ 17:51:
wat moet ik me eigenlijk voorstellen bij HTC ?

met htc (en hta) kan je behaviors met css aan elementen koppelen, en ze zo een andere functie geven. Er zijn een aantal standaard behaviors zoal "download" waarmee je clientside makkelijk files kan dlen, of "userdata", waarmee je een element kan omtoveren tot een soort "bak" waar je client side en over sessies heen data in kan gooien (beperkt).

Het handige is dat je in zo'n htc kan scripten, en dat dat script dan puur op het element slaat waar je de behavior aan gekoppeld hebt. Je zou dus een "button.htc" kunnen maken en die met css aan een <div> of <li> oid geven, en dan kan je in die htc de button code zetten, zodat je div of li een mouseover krijgt bv.

[Woudloper]

Clay, het lijkt er een beetje op dat je ook de UL LI menu's goed aan de praat te krijgen op zowel alle platformen In een vorig topic, gaf jij een voorbeeld van een onder Mozilla/Firebird en IE werkende UL LI menu.

Wellicht is het nog interessant om hier deze link aan toe te voegen. Dat is een reactie van een persoon op een goed artikel op A List Apart over het gebruik maken van dropdown menu's met UL LI. Deze persoon heeft middels een .htc oplosssing het lijst probleem wat IE heeft opgelost, ziet er erg netjes uit (layout e.d. daar gelaten, maar het gaat tenslotte om de techniek).

/Edit:
Even een late toevoeging Ik kwam op mijn browsende avond ook nog onderstaande link tegen:
http://www.howtocreate.co.uk/tutorials/testMenu.html

Deze link beschrijft hetzelfde als hierboven, maar dan met volledige uitleg. Wat echter nog jammer is aan beide voorbeelden, dat is dat ze beiden hardcoded in het .htc bestand de kleuren hebben staan en deze niet uitlezen vanuit het CSS bestand waar de :hover background-color e.d. staan gedefinieerd...

[ Voor 22% gewijzigd door Woudloper op 11-11-2003 23:31 ]

[creative8500]

Ter overweging: Digital Web Magazine - Keep CSS Simple

[Clay]

CSS hacks was ik al niet voor ook die /* \*/ macIE5 hack niet trouwens (kende ik ook niet). Ik vind het verder een goed artikel, ben het er ook mee eens

Wat ik hier aan het proberen ben is naar mijn mening ook niet een superhack bouwen, maar een "plugin" voor om IE dingen laten ondersteunen die het tot nu toe totaal niet ondersteunt, en dan uiteindelijk door het geven van 1 behavior aan de body een stuk meer van gewone hackloze css ter beschikking te hebben.

Het probleem daarbij is dat het eigenlijk perfect op de standaarden moet aansluiten, bugloos, generiek, licht en betrouwbaar moet zijn, en geen rare workarounds nodig heeft. Daarnaast moet bij IE7 maar blijken of er al dan niet checks inmoeten om dingen uit te schakelen die dan wel werken, al is daar al wel op vooruit te lopen qua coden.

[Woudloper]

Ja, was een goed artikel die van PPK en in principe ook toepasbaar op het gebruik van .htc. In het artikel staat namelijk dat je alleen hacks e.d. kan gebruiken wanneer je zeker weet dat het voor deze browser versie is en het niet opgelost gaat worden in een nieuwe versie, zo refereert hij aan het niet meer doorontwikkelen van Netscape 4 en MAC IE 5.

Als je dan kijkt naar IE6 kan je ongeveer dezelfde conclusie trekken aangezien Microsoft de ontwikkeling heeft gekoppeld aan zijn OS. De laatste geruchten zijn dat het nieuwe OS pas in 2005/6 gaat uitkomen, dus naar mijn idee mag/kan je best een .htc CSS achtige hack toepassen...

Verder eens met de laatste alinea zoals Clay deze hierboven beschrijft...

[BtM909]

Woudloper schreef op 10 november 2003 @ 10:22:
Als je dan kijkt naar IE6 kan je ongeveer dezelfde conclusie trekken aangezien Microsoft de ontwikkeling heeft gekoppeld aan zijn OS. De laatste geruchten zijn dat het nieuwe OS pas in 2005/6 gaat uitkomen, dus naar mijn idee mag/kan je best een .htc CSS achtige hack toepassen...

Ik vind alleen niet dat je deze .htc oplossing als een hack mag zien. En dat is ook wat PPK een beetje bedoeld. De oplossing van Clay lijkt me meer in de richting van ontbreken van functionaliteit toevoegen, totdat het niet meer nodig is.

[Clay]

Totdat het niet meer nodig is (als het ooit wat wordt ) kan flink lang duren. Met de komst van IE7 in b.v. '05 of '06 zal IE6 nog heel lang nodig hebben om te overleiden. Ik wil niemand bang maken maar IE5.0 moet op zich ook nog ondersteund worden (en anders 5.5 wel) en die zijn ook uit '98 ergens oid.

[Clay]

Update

Het eerste bruikbare htc'tjs is er. Het doet nog niet superveel, maar het wel een fundamentele feature, :hover op wat dan ook.

De .htc leest de stylesheets uit en pakt rules op die een :hover hebben. Die rule wordt gekopieerd naar een nieuwe stylesheet met in plaats van :hover een .class (in dit script gewoon "onHover". Met het attachEvent model van IE wordt deze classname dan mouseover en mouseout erop gezet en eraf gehaald.
Op zich kan je dan met de :hover dus in IE ook alles doen wat in moz kan (met uizondering van selectors die IE toch al niet snapte, en gebruik van asteriksen, *, IE bug imo)

code:

body div:hover p {
}

... plakt dus een event aan de div, en door de classname te verwisselen wordt de p inderdaad daarna geselecteerd en de style toegepast.

De "affected" elementen worden met de getElementsBySelect van de vorige pagina opgehaald, daarvoor wordt alles na en inclusief de :hover van de selectorText afgehakt, en dan komen de elementen terug die de hover moeten krijgen. De hele htc is precies 100 regels.

ik heb hier een documentje erover getypt, met wat uitleg en veel hovers ter illustratie.

[coubertin119]

Awwww, nijs shit .

Geweldige methode heb je eigenlijk gebruikt, ik zou het in elk geval niet bedacht kunnen hebben.

[CrashOne]

Hmmmm, dus als ik het goed begrijp werken de suckerfish dropdown menu's met deze htc ook zonder (extra) JS in IE?

Zou mooi zijn.

[creative8500]

CrashOne schreef op 23 december 2003 @ 22:04:
Hmmmm, dus als ik het goed begrijp werken de suckerfish dropdown menu's met deze htc ook zonder (extra) JS in IE?

Zou mooi zijn.

Probeer het, zou ik zeggen

Ik zal het morgen inpassen in de remake.

[ Voor 10% gewijzigd door creative8500 op 23-12-2003 22:55 ]

[CrashOne]

was er al mee bezig en kan je nu vertellen dat het werkt

Lekker Clay!

[Clay]

CrashOne schreef op 23 december 2003 @ 22:04:
Hmmmm, dus als ik het goed begrijp werken de suckerfish dropdown menu's met deze htc ook zonder (extra) JS in IE?

Zou mooi zijn.

ff geprobeerd, en die werkt inderdaad als je het script wat er in zit uit haalt, en de htc koppelt.

Wat alleen dus niet gaat werken zijn multilevel menus waar de hover op iets met dit berust:

code:

li:hover > ul {
}

Dat is om te voorkomen dat alle ul's in die li, hoe diep genest dan ook, openklappen, maar IE snapt die hele > selector niet dus dan gaat de hover ook niet werken. Maar daarvoor zou met een paar classes op zich ook wel wat te verzinnen moeten zijn.

[Anoniem: 97824]

Probleem is denk ik voor de meeste 'client-side' scripters dat het geheel ook moet werken in IE5.0 ;-)

[Woudloper]

Clay Als ik zo het .htc bestand bekijk moet ik zeggen dat ik me verbaasde over de eenvoudigheid (het heeft je natuurlijk wel het nodig uitzoekwerk gekost) hoe het script er uitziet. Eigenlijk had ik behoorlijk veel data (code dus) verwacht, maar dat valt op zich heel erg mee.

Heb je script ook (net zoals anderen) even ingepast in de 'Suckefish Dropdowns', zoals ik hierboven al beschreef, en dat werkt echt perfect.

Het artikel wat je erover hebt geschreven is erg duidelijk en ziet er zeker goed uit. Ik mis eigenlijk nog een puntje waarin je uitlegt hoe je met de beperkingen om moet gaan. Ofwel stel dat ik het script nu ga toepassen in een pagina waarmee ik wel werk met multilevel menus, die berusten (zoals jij zelf hierboven al beschrijft) op dit:

code:

li:hover > ul {
}

hoe zou ik dan het beste mijn .css moeten herschrijven zodat het gaat werken met het .htc script wat jij hebt gemaakt. Of komt hier in de toekomst nog een vervolg op?

Anne:
Probleem is denk ik voor de meeste 'client-side' scripters dat het geheel ook moet werken in IE5.0 ;-)

Hoe bedoel je IE5? IE5 wordt toch bijna niet meer gebruikt? De meeste mensen werken op een Windows platform met IE5.5 of hoger en IE5 voor de MAC wordt toch ook steeds minder gebruikt doordat Safari standaard met de nieuw MAC OS wordt meegeleverd?

[Clay]

Probleem is denk ik voor de meeste 'client-side' scripters dat het geheel ook moet werken in IE5.0 ;-)

Ja, inderdaad. Dat probleem heb ik dus ook

Hij geeft nu ook een keiharde error in 5.0 beetje slordig, maar dat komt door de Array.push() die erin zit Vreemd genoeg werkt het verder wel als je die aan de prototype toevoegt... Op msdn staat ook dat behaviors er vanaf 5.0 inzitten, maar < 5.5 noemen ze ineens "attached behaviors".

Ik mis eigenlijk nog een puntje waarin je uitlegt hoe je met de beperkingen om moet gaan. Ofwel stel dat ik het script nu ga toepassen in een pagina waarmee ik wel werk met multilevel menus, ...

Daar moet ik dus ook nog ff mee spelen maar imo wat in theorie zou moeten werken is als je de verschillende niveaus een class geeft die dat niveau aangeeft, en dan in de css:

code:

ul.level1 li:hover ul.level2, ul.level2 li:hover ul.level3, ... etc.  {
    /* zichbaar maken */
}

[ Voor 48% gewijzigd door Clay op 24-12-2003 09:22 ]

[Bosmonster]

Persoonlijk heb ik absoluut geen zin in dit soort ongein, alleen maar om wat CSS-support in te bouwen. Het is imho terug naar het tijdperk IE4/NS4 waarin je probeert alles cross-browser te krijgen met bergen javascript.

Ik loop bij het bouwen van sites zelden tegen CSS beperkingen aan. Misschien als ik perse alles in divs etc zou willen doen.. maar is dit dan niet jezelf eerst een probleem aanmeten door een bepaalde (misschien NU nog niet optimale) methode te kiezen. En vervolgens bergen javascript nodig te hebben om dat voor elkaar te krijgen.

[crisp]

tsja, dan leg je je er dus bij neer dat IE gewoon niet meer innoveerd. Ik denk dat het wel degelijk zin heeft om jezelf deze methoden aan te leren, en als je het op deze manier ook beschikbaar kan maken aan degenen die vastzitten aan zo'n IE-monster dan is dat leuk meegenomen. Voor professioneel gebruik is het misschien nog niet the way to go, maar ik zie toch wel degelijk waarde in dit soort libs

[Clay]

@Bosmonster
Dat zou ik dus niet zo zien. de :hover, in combinatie met andere selectors staat je toe met alleen maar css dingen te doen die anders nog grotere bergen javascript zouden kosten. De beperkingen van IE gaan je ook pas irriteren als je dingen met css gaat doen die IE vanzelf niet snapt, maar wel erg makkelijk/handig blijken te zijn; zoals breder gebruik van :hover

Om het met het V4 tijdperk te vergelijken vind ik ook overdreven Het is alles behalve een berg script en de code is imo effectief en efficient. Het valt wat mij betreft ook niet in de categorie hack of ongein omdat het gewoon een (van de mogelijk) methode(n) automatiseert die je anders met de hand zou scripten, namelijk classes wisselen. Het versimpelt juist je code, omdat je standaard css kan gebruiken zonder verder ergens rekening mee te hoeven houden.

Het is het beste te vergelijken met hoe mozilla de <marquee> tag ondersteunt; namelijk via de interne css files met een xul binding.

@crisp
Ik leg me er inderdaad bij neer dat IE voorlopig niet gaat innoveren. Ik wil niet 2 jaar hoeven wachten op een nieuwe IE versie om dan pas te kunnen doen wat nu al kan in alles behalve IE.
Ik wil nu technieken gebruiken die mijn leven als devver makkelijker maken, en simpelere html en juist specifiekere css hoort daar bij. IE loopt al hopeloos achter bij wat andere browsers bieden; degelijk css support, alternate stylesheets, noem het op en het ontbreekt bij IE. Als behaviors daarvoor de oplossing bieden is dat imo een schitterende techniek om in te zetten, en op den duur idd misschien ook professioneel (als IE7 te lang op zich laat wachten).

[edit]

ff getest, en:

code:

ul.level1 li:hover ul.level2, 
ul.level2 li:hover ul.level3  {
    /* zichbaar maken */
}

werkt inderdaad voor multilevel menu's

[ Voor 8% gewijzigd door Clay op 24-12-2003 10:37 ]

[creative8500]

Woudloper:

code:

li:hover > ul { display: block; }

hoe zou ik dan het beste mijn .css moeten herschrijven zodat het gaat werken met het .htc script wat jij hebt gemaakt. Of komt hier in de toekomst nog een vervolg op?

Wellicht met een constructie als deze?

code:

li:hover ul { display: block; }
li:hover ul ul,
li:hover ul ul ul,
li:hover ul ul ul ul, { display: none; }

[Clay]

hoe zou ik dan het beste mijn .css moeten herschrijven zodat het gaat werken met het .htc script wat jij hebt gemaakt. Of komt hier in de toekomst nog een vervolg op?

Vervolg komt er vrees ik niet op. de > selector werkt gewoon niet in IE, en bij het uitlezen van css rules uit het stylesheets object krijg je voor rules waar dat instaat (en voor andere niet-ondersteunde combinaties) "unknown" terug in plaats van gewoon die rule. Het valt dus gewoon niet te parsen.

Wat misschien wel zou kunnen is de werkelijke content van css files uitlezen, en met een berg regexp de boel gaan parsen tot bruikbare rules en class toewijzingen, maar dat is (hoewel ik het wel ga proberen ) zwaar onder voorbehoud, en klinkt wel als een hele ranzige oplossing

[Anoniem: 97824]

creative8500 schreef op 24 december 2003 @ 10:42:
[...]

Wellicht met een constructie als deze?

code:

li:hover ul { display: block; }
li:hover ul ul,
li:hover ul ul ul,
li:hover ul ul ul ul, { display: none; }

Anne denkt dat je met een descendent combinator zoiezo al alle onderliggende ul elementen te pakken hebt, waardoor de laatste twee selectors overbodig worden ;-)

En ik bedoelde idd IE5/Win. Het is jammer dat Nedstat geen onderscheid maakt tussen 5.0 en 5.5. startpagina.nl leek me wel betrouwbaar.

[Woudloper]

Anne:
En ik bedoelde idd IE5/Win. Het is jammer dat Nedstat geen onderscheid maakt tussen 5.0 en 5.5. startpagina.nl leek me wel betrouwbaar.

slightly offtopic, maar ik kijk over het algemeen bij Google's Zeitgeist. Op deze pagina geeft Google een overzicht van meest gebruikte searches, maar ook met welke browsers Google wordt bezocht. * Woudloper denkt dat deze pagina iets betrouwbaarder (gezien het aantal bezoekers) is dan de nedstat van startpagina....

[creative8500]

Anoniem: 97824 schreef op 24 december 2003 @ 12:08:
[...]
Anne denkt dat je met een descendent combinator zoiezo al alle onderliggende ul elementen te pakken hebt, waardoor de laatste twee selectors overbodig worden ;-)

Inderdaad Offtopic: waarom ben je niet on-line @ msn?

[ Voor 1% gewijzigd door creative8500 op 24-12-2003 12:24 . Reden: typo ]

[André]

Woudloper schreef op 24 december 2003 @ 12:11:
[...]

slightly offtopic, maar ik kijk over het algemeen bij Google's Zeitgeist. Op deze pagina geeft Google een overzicht van meest gebruikte searches, maar ook met welke browsers Google wordt bezocht. * Woudloper denkt dat deze pagina iets betrouwbaarder (gezien het aantal bezoekers) is dan de nedstat van startpagina....

Waar staat het stuk over de gebruikte browsers dan?

[coubertin119]

http://www.google.com/press/zeitgeist/nov03_browsers.gif

Goed zo André, je krijgt een pluim voor beste zoeker woudloper .

[ Voor 7% gewijzigd door coubertin119 op 24-12-2003 12:28 . Reden: das toepasselijker 8) ]

[André]

coubertin119 schreef op 24 december 2003 @ 12:27:
http://www.google.com/press/zeitgeist/nov03_browsers.gif

Goed zo André, je krijgt een pluim voor beste zoeker woudloper .

En hoe kom je bij dat plaatje dan? Hoe klik ik daar naar toe? In welke pagina staat dat dan? Enz..?

[disjfa]

http://www.w3schools.com/browsers/browsers_stats.asp

staat ook alles heel netjes

[coubertin119]

*klik* http://www.google.com/press/zeitgeist.html
*scroll* October/November 2003 Zeitgeist
*kijk* tweede rijtje met afbeeldinkjes .

[ Voor 3% gewijzigd door coubertin119 op 24-12-2003 12:35 . Reden: nu nog ordelijker :P ]

[André]

coubertin119 schreef op 24 december 2003 @ 12:35:
*klik* http://www.google.com/press/zeitgeist.html
*scroll* October/November 2003 Zeitgeist
*kijk* tweede rijtje met afbeeldinkjes .

Kan het zijn dat jij meer ziet dan mij omdat je bijvoorbeeld de Google Toolbar hebt geinstalleerd ofzo?

[BtM909]

André schreef op 24 december 2003 @ 12:37:
[...]

Kan het zijn dat jij meer ziet dan mij omdat je bijvoorbeeld de Google Toolbar hebt geinstalleerd ofzo?

Me with stupid... Want ook ik kom niet bij dit plaatje

[coubertin119]

Wuh? Ik heb niks Google Toolbar en ik surf met:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030925 Firebird/0.7

Dus geen idee wat jullie fout doen

[André]

coubertin119 schreef op 24 december 2003 @ 12:43:
Wuh? Ik heb niks Google Toolbar en ik surf met:
[...]


Dus geen idee wat jullie fout doen

He klaphark, wij doen niets fout

Ik zal eens een screenshot maken van de pagina zoals ik hem zie.

[Scurra]

André schreef op 24 december 2003 @ 12:37:
[...]

Kan het zijn dat jij meer ziet dan mij omdat je bijvoorbeeld de Google Toolbar hebt geinstalleerd ofzo?

Nee, het ligt blijkbaar aan de taal die je ingesteld hebt in je browser. Jij ziet de Nederlandse variant van de Google Zeitgeist, die minder uitgebreid is. Kijk maar, de Engelse variant is veel uitgebreider.

[coubertin119]

Je ziet maar, mensen met veel talenkennis kunnen ook meer algemene kennis opdoen .

Wel weird dat Google er voor kiest om zulke levensnoodzakelijke grafiekjes enkel voor Engelstaligen open te stellen...

[CrashOne]

Ik liep vannacht ook tegen het probleem aan dat IE5 deze htc niet ondersteund door gebruik van die push(). Dat maakt hem een stuk minder bruikbaar (aangezien >10% vd bezoekers van mijn site IE5 nog gebruikt), is dit makkelijk op te lossen?

[disjfa]

CrashOne schreef op 24 december 2003 @ 14:10:
is dit makkelijk op te lossen?

kijken welke browser de mensen gebruiken en als ze 5 hebben linken naar een pagina waar staat 6 downen

en dan wat sites erbij zetten natuurlijk.... oa firebird en opera

[ Voor 21% gewijzigd door disjfa op 24-12-2003 14:12 ]

[crisp]

CrashOne schreef op 24 december 2003 @ 14:10:
Ik liep vannacht ook tegen het probleem aan dat IE5 deze htc niet ondersteund door gebruik van die push(). Dat maakt hem een stuk minder bruikbaar (aangezien >10% vd bezoekers van mijn site IE5 nog gebruikt), is dit makkelijk op te lossen?

ja, dmv prototyping een eigen push-method toevoegen aan het Array-object
(dat gaf Clay zelf ook al eerder aan in deze draad)

[ Voor 6% gewijzigd door crisp op 24-12-2003 14:18 ]

[André]

crisp schreef op 24 december 2003 @ 14:17:
[...]

ja, dmv prototyping een eigen push-method toevoegen aan het Array-object
(dat gaf Clay zelf ook al eerder aan in deze draad)

Waarom kun je de array.push methode niet veranderen op deze manier:

JavaScript:

Bla = new Array();

//Bla.push("Blabla")
Bla[Bla.length] = "Blabla";

[creative8500]

André schreef op 24 december 2003 @ 14:47:
[...]

Waarom kun je de array.push methode niet veranderen op deze manier:

JavaScript:

Bla = new Array();

//Bla.push("Blabla")
Bla[Bla.length] = "Blabla";

Zo doe ik dat ook ja

[Clay]

'k heb nog een paar andere bugjes ontdekt die er nog ff uitmoeten De check of het om een A element gaat kan al eerder, en d'r zit nog een foutje in de getElementBySelect. verder werkt ie eigenlijk schitterend

[crisp]

push is makkelijk als je meerdere elementen op een array wilt schoppen, en geeft de nieuwe lengte van de array terug:

JavaScript:

if (typeof Array.prototype.push == 'undefined') Array.prototype.push = _Array_push;
function _Array_push() {
  var i = 0, l = arguments.length;
  while (i < l) this[this.length] = arguments[i++];
  return this.length;
}

var a = ['spef','melp','woei'];
var newlength = a.push('foo','bar');

[Woudloper]

Clay, je uitbreding van het document over: whatever:hover ziet er goed uit al zeg ik hetzelf! Erg verhelderend, het voorbeeld ziet er ook netjes uit (met een mooie office layout menu).

offtopic:
Ga je met dit script ook naar alistapart of naar de schrijver van het dropdowns artikel toe, of wacht je nog tot alle bugs eruit zijn zoals je hierboven melde.

[crisp]

Hier met win95 en IE5.5 krijg ik geen submenu's te zien in het voorbeeld

qua JS kan er ook nog wel eea geoptimaliseerd worden maar dat is meer omdat ik een purist ben geworden
- een if (!s) vind ik lelijk, zeker als je weet dat je geen false krijgt maar null als exec() geen matches meer geeft.
- hetzelfde geld voor properties afvragen - niet zo: if (object.property) maar zo: if (typeof object.property != 'undefined')
- dit kan je ook optimaliseren:

JavaScript:

for(var i=0; i<sheets.length -1; i++)

, namelijk zo:

JavaScript:

var i=sheets.length-1;while(i--){ }

maar goed, dat is allemaal mierenn**ken, de code ziet er prima uit, lekker compact ook - blijft de vraag waarom ik hier geen submenu's krijg; eens even kijken....

[ Voor 85% gewijzigd door crisp op 29-12-2003 12:07 ]

[DeFeCt]

In IE 6 op 2003 server knippert alles als een gek, niet echt smooth zeg maar...

[killercow]

snap jullie nie,

waarom in gods naam iets bouwen in een htc wat wellicht (oke ingewikkelder) ook wel te schrijven valt voor mozilla en anderen.

Ik weet dat het leuk is om dingen met htc's te doen, heb zelf een keer een table-sort functie gemaakt maar toch is het niet verstandig om het op die manier te doen omdat je een gedeelte van je bezoekers,
ik zelf heb nu bijvoorbeeld gezeur met die sort dat hij ie gewoon laat crashen, en dat ik hem nu dus niet kan verbouwen naar een andere mozilla compliant functie.ze willen graag overstappen maar ja ze willen ook die client side sort houden.

[coubertin119]

Euhm, wie weet omdat het al werkt in Mozilla en niet in IE6, zodat dààr de uitbreiding voor nodig is, dus wat je in je verhaaltje probeert over te laten komen snap ik niet echt. En de link tussen een table-sort en het laten werken van een onderdeel van CSS zie ik ook niet, deze .htc zorgt ervoor dat standaard dingen werken zoals ze moeten werken terwijl jouw tablesort een uitbreiding is.

[Clay]

mja 't zou ook te mooi zijn als het gewoon zou werken allemaal

Het geknipper in IE6 is een cache probleem/plaatjes bug. Als je je cache op auto of never zet werkt die (hier iig) goed zonder geknipper, en anders wordt de hele boel idd steeds gereload Overigens is dat dan dus een image bug geen script/css bug imo. Maar het blijft kut ja.

Dat het in 5.5 niet werkt snap ik ook ff niet, maar daar ga ik ook nog ff naar kijken. De behavior werkt op zich wel, in een andere demo die ik hier heb liggen doet IE5.5 het namelijk wel, dus het kan ook weer een css bug zijn.

edit:

hmz, ok 5.5 werkt wel als je ipv de visibility de display togglet tussen none en block op de hover. maar het boxmodel is vernaggeld

5.0 maakt er een complete zooi van maar het "werkt" wel ook dit is gewoon weer een (berg) css bug(s), en die net genoemde andere demo werkt daarin ook.

't blijft dus wel wat schipperen. De behavior enablet alleen maar :hover op andere elementen; het fixt geen bugs, en dat menu is dan dus misschien niet het beste voorbeeld om de behavior te demonstreren

[ Voor 10% gewijzigd door Clay op 29-12-2003 12:24 ]

[killercow]

coubertin119 schreef op 29 december 2003 @ 12:12:
Euhm, wie weet omdat het al werkt in Mozilla en niet in IE6, zodat dààr de uitbreiding voor nodig is, dus wat je in je verhaaltje probeert over te laten komen snap ik niet echt. En de link tussen een table-sort en het laten werken van een onderdeel van CSS zie ik ook niet, deze .htc zorgt ervoor dat standaard dingen werken zoals ze moeten werken terwijl jouw tablesort een uitbreiding is.

ik bedoel dat je als webdevelopper wel eens iets leuks denkt te maken met een htc die dan alleen in IE werken. IE only is al niet handig maar vaak krijg je alleen met dit soort dingen te maken als je web-aps bouwt voor bedrijfen en dan wordt het pas gevaarlijk om extra dingen met IE only oplossingen te bouwen want dan restrict je je klant.

[Clay]

Even voor de duidelijkheid; het is juist de bedoeling dat dit IE only is, omdat het een tekortkoming van IE is die alleen in IE opgelost hoeft te worden. De :hover werkt in echte browsers al zoals deze behavior hem probeert te doen werken in IE, het hoeft dus ook enkel in IE te werken.
Een behavior gebruiken is dan naar mijn mening ook juist omdat dat IE only is een goeie keuze. Andere browsers laden dat hele ding dan ook niet in; dat hoeft niet.

Ik ben het helemaal met je eens dat het suf is om IE only dingen te ontwikkelen die je later weer op je bord krijgt, maar je opmerking is hier dus denk ik misplaatst

[Woudloper]

Clay:
[...] en dat menu is dan dus misschien niet het beste voorbeeld om de behavior te demonstreren

Was het wellicht niet handiger om het Suckerfish Dropdown menu als voorbeeld mee te geven? Wellicht kan je hem er nog bij plaatsen, aangezien je het er in je uitleg toch ook over hebt...

Wat is overigens het minimale wat jij wilt ondersteunen? IE5 of IE5.5? Zijn er overigens naast het :hover CSS gebrek binnen IE nog meer gebieden welke je graag zou willen gaan ondersteunen met htc of is dit het belangrijkste...

[killercow]

Clay schreef op 29 december 2003 @ 13:44:
Even voor de duidelijkheid; het is juist de bedoeling dat dit IE only is, omdat het een tekortkoming van IE is die alleen in IE opgelost hoeft te worden. De :hover werkt in echte browsers al zoals deze behavior hem probeert te doen werken in IE, het hoeft dus ook enkel in IE te werken.
Een behavior gebruiken is dan naar mijn mening ook juist omdat dat IE only is een goeie keuze. Andere browsers laden dat hele ding dan ook niet in; dat hoeft niet.

Ik ben het helemaal met je eens dat het suf is om IE only dingen te ontwikkelen die je later weer op je bord krijgt, maar je opmerking is hier dus denk ik misplaatst

point taken,

dus ook voor de mensen die dit wel een cool script vinden, maak ook de normale/mozilla versie er even bij op je site dan kan je site nog wat jaartjes mee want van IE hoef je de komende jaren geen nieuwe versies meer te verwachten maar van de andere browsers wel.

edit:

Ik snap best wat jullie aan het doen zijn hier, maar ik denk dat de gemiddelde devver hier de ballen van snapt, en dus klakkeloos jullie scriptje erin dumpt en dan klaar denkt te zijn, dat mozilla het wel of niet ondersteund en hoe dan precies dat zullen ze niet weten en dus ook niet implementeren, ik kom helaas nog te vaak sites tegen die dmv simpel knip en plakwerk een cool menutje hebben wat bij mij bijvoorbeeld absoluut niet gaat werken.

Bovenstaande is meer een vraag naar de gebruikers van jullie(clay's) script om ook die :hover versie voor mozilla te implementeren.

[ Voor 23% gewijzigd door killercow op 29-12-2003 16:39 ]

[coubertin119]

Er is toch helemaal geen "normale"/Mozilla versie van nodig, aangezien Mozilla standaard :hover ondersteunt, dus ofwel zit jij hier slap te leuteren ofwel kan je je zo geweldig goed uitdrukken dat Clay en ik er niets van snappen.

[creative8500]

killercow schreef: point taken,

Blijkbaar niet dus, je snapt het niet.

1. Mozilla ondersteunt in CSS: element:hover { }
2. Internet Explorer ondersteunt in CSS: a:hover {}

We kunnen ervoor zorgen dat:

1. Mozilla ondersteunt in CSS: element:hover { }
2. Internet Explorer ondersteunt in CSS: element:hover { }

door middel van een stukje JavaScript.

Dat stukje JavaScript hoeft dus alleen voor IE te gelden.

[ Voor 16% gewijzigd door creative8500 op 29-12-2003 16:40 ]

[--MeAngry--]

creative8500 schreef op 29 december 2003 @ 16:38:
[...]

Blijkbaar niet dus, je snapt het niet.

1. Mozilla ondersteunt in CSS: element:hover { }
2. Internet Explorer ondersteunt in CSS: a:hover {}

We kunnen ervoor zorgen dat:

1. Mozilla ondersteunt in CSS: element:hover { }
2. Internet Explorer ondersteunt in CSS: element:hover { }

door middel van een stukje JavaScript.

Dat stukje JavaScript hoeft dus alleen voor IE te gelden.

Kweet niet of het toegestaan is enzo, maar ik heb het scriptje al in gebruik en het werkt prima Onder IE heb ik nu mooi het :hover element, en tjah, onder Mozilla werkte dat toch al, dus nice job folks!

[Anoniem: 24491]

killercow schreef op 29 december 2003 @ 16:16:
point taken,

I beg to differ.. Hulde Clay ik denk dat ik dit wel ga gebruiken voor een nieuwe opdracht, bedankt zo ver.

[Clay]

Woudloper
Wat is overigens het minimale wat jij wilt ondersteunen? IE5 of IE5.5? Zijn er overigens naast het :hover CSS gebrek binnen IE nog meer gebieden welke je graag zou willen gaan ondersteunen met htc of is dit het belangrijkste...

5.0 zou leuk zijn, maar 5.5 en 6.0 heeft verreweg de meeste gebruikers, dus als iets toevallig niet in 5.0 werkt (en geen errors geeft) is dat op zich geen ramp imo. Naast die :hover zou ik natuurlijk nog veel meer willen "enablen" met htc, maar er is maar zoveel wat ook werkelijk kan zonder in vieze hacks te vervallen, en ik zou zelf geen site willen laten draaien op hacks, dus een ander wil ik dat ook niet aanraden

Zonder de content van de stylesheets met b.v. regexp te gaan filteren is het niet mogelijk de niet ondersteunde selectors te vinden, omdat IE vanuit het ingebouwde stylesheets object gewoon "unknown" teruggeeft ipv de werkelijke selector. ik ben dus bang dat het zonder hacks niet veel verder dan dit komt. Qua properties is er misschien nog wel het een en ander te doen, bv. border-spacing op tables en nog wat statische dingen. Eigenlijk is het voor dingen die aan een resize event moeten gaan hangen ook al niet meer handig.

killercow
... maar ik denk dat de gemiddelde devver hier de ballen van snapt, en dus klakkeloos jullie scriptje erin dumpt en dan klaar denkt te zijn, dat mozilla het wel of niet ondersteund en hoe dan precies dat zullen ze niet weten en dus ook niet implementeren, [...] wat bij mij bijvoorbeeld absoluut niet gaat werken.

Bovenstaande is meer een vraag naar de gebruikers van jullie(clay's) script om ook die :hover versie voor mozilla te implementeren.

Op zich is het ook juist de bedoeling dat je dit ergens "klakkeloos inmikt", en vervolgens :hover gaat gebruiken icm. andere css. Ik gebruik zelf firebird, en stoor me aan het gebrek in IE aan fatsoenlijke :hover ondersteuning. Hovers op inputs, hovers op TR's, IE kan dat allemaal niet, maar hiermee dus wel.

En dit hoeft dus niet voor firebird of mozilla geimplementeerd te worden, omdat die alles wat deze behavior voor IE doet vanzelf al kunnen.

Het voegt aan IE niets toe wat mozilla of firebird niet al lang konden.

[creative8500]

Clay schreef op 29 december 2003 @ 17:22:
5.0 zou leuk zijn, maar 5.5 en 6.0 heeft verreweg de meeste gebruikers

Bij enkele van mijn sites verbaasde ik me hierover: er waren juist nauwelijks gebruikers van 5.5, en veel van 5.0: volgens mij wordt met Windows 98 5.0 meegeleverd, en die n00bs weten niet dat je zoiets kunt upgraden.

[Blaise]

@ mighty Clay: Komt er ook :focus ondersteuning in?

[André]

Blaise schreef op 29 december 2003 @ 17:46:
@ mighty Clay: Komt er ook :focus ondersteuning in?

<body onload="element.focus()">

Waarom zou dat in een stylesheet moeten, lijkt me wat overdreven.

[Clay]

:focus in css is actief als je als user een element gefocussed hebt b.v. inputs etc. Maar, ik heb ff gekeken, en dat komt dus ook als :unknown terug. gaat waarschijnlijk niet werken dus.

[Blaise]

André schreef op 29 december 2003 @ 17:52:
[...]

<body onload="element.focus()">

Waarom zou dat in een stylesheet moeten, lijkt me wat overdreven.

Ik zat meer te denken aan form elementen zoals

code:

input:focus{ background : yellow; }

[André]

Blaise schreef op 29 december 2003 @ 18:08:
[...]


Ik zat meer te denken aan form elementen zoals

code:

input:focus{ background : yellow; }

Nu begrijp ik je, dat zou inderdaad wel een leuke feature zijn.

[Anoniem: 97824]

Dat kan dus ook: http://annevankesteren.nl...internet-explorer#c000703

Weblogs zijn geweldig hiervoor!

[Puck]

Ik volg dit topic nu al een tijdje en ik moet zeggen, geweldig werk Clay

Anne, die oplossing van Ben Nolan, is die niet heel erg fout?

code:

body{
    background: url("
        javascript:
             ");
}

Of kan zijn code ook via .htc worden aangeroepen?

[Clay]

Ik had er nog nooit van gehoord dat dat ook kon misschien opent dat weer perspectieven voor andere fixen, net als de property:expression(script); css die IE blijkt te ondersteunen trouwens, die kende ik tot voor kort ook niet.

Wat betreft het script van Ben Nolan; dat is iid ook een mooie, maar er zitten wel een paar serieuze haken en ogen aan die het mijns inziens wat minder bruikbaar maken. Daar zou nog het een en ander aan geoptimaliseerd moeten worden.

[Anoniem: 32071]

Beetje off-topic, vergeef me :
http://www.elf.org/pnglets/
Daar wordt javascript gebruikt om plaatjes te maken.
Er is ook een soort c-achtig taaltje wat xbm-plaatjes kan maken.

Maar vinden jullie dat nog zinvol?
Ik vind het persoonlijk een beetje zinloos en zelfs gevaarlijk dat je kennelijk op allerlei plekken javascript kunt includen.

[Woudloper]

Anne, in het vervolg op de opmering van PuCK met betrekking tot de: url(javascript: [..] ") oplossing welke door Ben Nolan is gemaakt vroeg ik mij af of dit een IE specifieke bug/hack is, of werkt het ook bij meerdere browsers op deze manier. Ik kon zo snel over bovenstaande niets terugvinden in de specs van CSS op w3.org en ook niet op msdn.microsoft.com.

Trouwens het lijkt erop dat om de één of andere reden het script van Ben niet altijd werkt. Ik opende de pagina namelijk (vanuit het artikel op web-graphics) nogmaals en toen deed de gehele pagina van Ben het niet. Wellicht een caching probleem!?

edit:
Leuk, ik zag dat Anne de suggestie nu ook door heeft gezet naar Web-Graphics en wel in deze posting. Ook zag ik in deze post dat er ook op WASP een posting aanwezig was over het script, gemaakt door Clay.

De publiciteit lijkt alleen maar omhoog te gaan nu zelfs Eric Meyer over jouw script is gaan schrijven. Hij heeft daarbij ook nog wel wat wensen welke wellicht met behavior zouden kunnen worden afgevangen.

En nog een kleine toevoeging. Ik zag bij het laatste commetnaar van het Suckerfish Dropdown artikel bij A List Apart dat iemand pretenteerd dat hij een htc script gemaakt heeft welke :hover werkend heeft gekregen bij IE5+, zie hier Overigens linkt hij wel naar het script van Clay. Hij geeft alleen als nadeel dat het alleen werkt als de pagina gedownload is.

[ Voor 72% gewijzigd door Woudloper op 06-01-2004 11:18 . Reden: Nog een linkje bij de edit sectie toegevoegd ]

[HarmoniousVibe]

Dat :hover htc'tje werkt erg goed hier. Precies wat ik nodig had. Maar hoe krijg ik die right: xxpx; werkend? Ik de openingspost staat er wel iets over, maar ik weet niet precies wat ik met die code moet doen.

[Clay]

Dat zit hier niet in 'k heb daarvoor nog geen mooie oplossing kunnen vinden.

Wbt. dat url("javascript: ... "), het lijkt ook te werken in Mozilla (ruwweg mits het op 1 regel staat) en Opera. Mac heb ik niet geprobeerd. het werkt ook niet alleen met javascript:, maar b.v. ook met mailto:, en dat gaat natuurlijk helemaal nergens meer over

[ Voor 6% gewijzigd door Clay op 06-01-2004 09:26 ]

[Woudloper]

Nog even over dat url("javascript: ... "). Heb nog even wat gezocht bij Google en kwam door gewoon even als site: w3.org op te geven op de volgende posting bij list.w3.org en dat is eigenlijk het enige wat ik erover had kunnen vinden. De discussie aldaar gaat niet over het gebruik ervan, maar of Cascading Stylesheets veilig zijn, hieronder een stukje uit het betreffende bericht:

> Whether it is true or not, css is generally perceiveded to be "safe".

It's not.

body { background: url("javascript:alert(\'Hello\ again!\ (background)\')"); }

...is possible right now, and shows a dialog in at least two browsers.

Indeed it's even easier in IE:

p { width: expression(alert('Hello!\ \(width\)')); }

...and that pops up several dialogs on each paint, almost.

See: http://junkyard.damowmow.com/85

So no, CSS isn't safe.

Verder heb ik er niet echt informatie over kunnen vinden. Weet dus ook niet of het een feature is of een bug!?

[Ms_Hyde]

Woudloper> Het is waarschijnlijk een IE bug, in Mozilla gebeurd er namelijk niks. Net zoals het gebruiken van .htc files. Ik zie het meer als een beveiligings lek in het parsen van CSS in Internet Explorer waarmee een webdesigner wat kan bereiken met zijn layout maar net zo goed kan een kwaadwillende ook misbruik van maken.

Dus nu weten we weer een nieuw manier hoe we met CSS en Javascript een browser kunnen laten crashen.

[Anoniem: 32071]

@Woudloper
Hier staat er wel iets over in:
http://www.w3.org/TR/REC-CSS2/generate.html#content
http://www.w3.org/TR/REC-CSS2/media.html

Due to rapidly changing technologies, CSS2 does not specify a definitive list of media types that may be values for @media

Het lijkt er dus op dat dit een beetje open is gelaten.

Ik heb ook wel eens gehoord dat dit soort voorbeelden zou moeten kunnen:

code:

div {
background-image:url(iets.swf);
}
div.twee{
background-image:url(iets.svg);
}

En misschien zelfs wel:

code:

div.drie{
background-image:url(drie.html);
}

Zou dat niet geweldig zijn?
Zo kun je niet alleen css gebruiken om daar je javascript in te begraven, maar ook meteen je flash, svg en html.

Ik had misschien als voorbeeld beter de nieuwe css3 content property kunnen gebruiken. Ik heb toch het idee dat background-images alleen voor plaatjes is bedoeld (svg valt daar geloof ik nog wel onder).
Dus zoiets:
content: url(iets.swf) url(iets.gif) "iets";
Deze heeft ook meteen een terugval-mechanisme.

edit:
Grappig, ik zie net dat de discussie opnieuw is aangezwengeld

[ Voor 5% gewijzigd door Anoniem: 32071 op 06-01-2004 16:40 ]

[Anoniem: 32071]

Nou, ik ben er ook nog even mee bezig geweest

Je kunt mbv htc-files ook js-files includen. Dat maakt de boel flexibeler.

cssfix.htc

code:

<PUBLIC:COMPONENT>
<PUBLIC:ATTACH EVENT="ondocumentready" ONEVENT="doe()" />
<script>

function addscript(ur){

scScript=document.createElement('script'); 
scScript.src=ur;
scScript.type='text/javascript';
window.document.getElementsByTagName('head')[0].appendChild(scScript);
}
function doe(){
addscript('http://home.hccnet.nl/m.wargers/csshover/csshover.js');
addscript('http://www.doxdesk.com/file/software/js/minmax.js');
addscript('http://www.doxdesk.com/file/software/js/fixed.js');
addscript('http://www.doxdesk.com/file/software/js/event.js');
addscript('http://www.doxdesk.com/file/software/js/position.js');
}
</script>
</PUBLIC:COMPONENT>

En dan invoegen via css:

code:

body{
behavior:url(cssfix.htc);
}

Ik heb de code van Clay omgezet naar een regulair csshover.js scriptje (wat erg simpel is te doen), en ik heb de css-fixes van http://www.doxdesk.com er ook maar meteen ingezet.
Het lijkt het allemaal wel te doen:

Ook een bookmarklet versie van gemaakt:
http://home.hccnet.nl/m.wargers/csshover/bookmarklet.htm

Hier kun je alle files zien en wat voorbeeldjes:
http://home.hccnet.nl/m.wargers/csshover/

[Anoniem: 24491]

Dikke vette schop naar de bovenste regionen

Nu ook htc behaviours te koppelen aan Mozilla

http://dean.edwards.name/my/examples/moz-behaviors/
(via XBL)

[Anoniem: 32071]

Dat is inderdaad erg interessant. Ik heb het zelf ook eens getest met wat htc-files van mezelf en daar werkt het helaas niet. Dit kan ook aan mij liggen hoor. Ik wacht nog rustig af op de uitleg die hij gaat geven
Voor zover ik het weet moet je dit doen om je htc-behavior werkend te krijgen in Mozilla:
Als je zo'n selector hebt:

div{
behavior:url(behavior.htc);
}
Moet je dit toevoegen:
-moz-binding:url(moz-behaviors.xml#behavior.htc);

De hash-naam die aangeeft wat voor binding je in de bindings-file gebruikt moet hetzelfde zijn als die van de htc-file.

In je moz-behaviors.xml file moet je dan dit toevoegen:
<binding id="behavior.htc" extends="#behavior"/>
Dmv het uiterst coole extends attribuut wordt dan deze binding uitgebreid met de eigenschappen van de #behavior binding en die doet dan al het werk (htc-file uitlezen en code omzetten naar voor Mozilla begrijpelijke code)

[Anoniem: 24491]

martijn misschien heb je hier wat aan

http://dean.edwards.name/my/

[Anoniem: 32071]

Ja dank je, maar dat wist ik al.
Ik gebruik nogal ie-specifieke code in mijn htc's (nogal logisch als je weet dat die alleen hoeft te werken in IE), dus het verbaast me niet zo erg.
Het punt is dat ik ook geen error messages krijg; daarom krijg ik nog het idee dat ik iets fout doe.

De auteur is trouwens wel benieuwd naar dit soort testcases. Dus als je iets hebt, mail het hem.
Ik vind het nog steeds ontzettend gaaf!

[Anoniem: 32071]

Nou hij heeft mijn htc behaviors gecorrigeerd, en daarna werken mijn behaviors ook onder Mozilla.

Er zijn gewoon een paar dingen waar je op moet letten:

1) your behavior must validate as strict xml
2) for the time being use lower case tags and attributes
3) use CDATA tags inside the script tags (and comment them out)
4) avoid proprietary microsoft properties like document.all and
element.children
5) and more! i'd better compile a list

Nou goed, hij legt het allemaal nog wel uit op zijn website.

Mijn behaviors voldeden daar natuurlijk niet aan, want IE slikt alles wat op zijn pad tegenkomt en daar maak ik gretig gebruik van

[Anoniem: 24491]

het is wel cool dat het kan, ligt toch een beetje in het verlengde van dit topic. Ook cool dat die behaviours van jou nu werken.