[css] meer css met htc voor IE

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:

1 2 3 4 5

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

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


HTML:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

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:

1	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:

1 2 3 4 5 6 7 8 9

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

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...

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:

1 2 3 4 5 6 7 8 9 10 11

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?)

Clay wijzigde dit bericht 05-11-2003 11:25 (7%)

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

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

quote:

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:

1 2	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

Clay wijzigde dit bericht 05-11-2003 11:35 (7%)

quote:

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

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...

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

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

quote:

Martijn22 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.

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.

Martijn22 wijzigde dit bericht 05-11-2003 12:55 (14%)

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

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...

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.

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

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.

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

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:

1 2	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:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

<?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:

1 2 3 4 5

<?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

quote:

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

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)

mattttt wijzigde dit bericht 09-11-2003 17:52 (23%)

quote:

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.

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...

Woudloper wijzigde dit bericht 11-11-2003 23:31 (22%)

Ter overweging: Digital Web Magazine - Keep CSS Simple

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.

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...