[Webdesign]Wat zou jij toe willen voegen aan de standaarden?

[Michali]

Er lopen in dit forum meerdere mensen rond die wel meer dan eens een design hebben omgetoverd tot een website. Om dit voor elkaar te krijgen kun je gebruik maken van wat er in de standaarden is gespecificeerd (behalve wat nog niet is geimplementeerd natuurlijk). Vaak kun je hier goed mee uit de voeten, maar op sommige punten krijg ik (en waarschijnlijk ook andere) wel ideeën voor betering of toevoeging. Vandaar nu dit topic. Zelf heb ik al hier en daar ideeën gekregen (enkele die ik ook weer ben vergeten), hier in ieder geval wat ik nu kan bedenken:

parent selector (css):
Je hebt in css al de beschikking over een child selector, maar het lijkt me toch handig om ook een parent te kunnen selecteren. Stel dat je bijvoorbeeld een menu hebt, opgebouwd mbv. een unordered list met een achtergrond afbeelding en enkele list items met achtergrond afbeeldingen. Nu wil je graag dat als over een li element gehoverd wordt, dat dan zowel de achtergrond afbeelding van de list item als van de complete lijst veranderd. Nu is zo iets nog niet mogelijk, maar lijkt me toch handig als dit wel kan met een parent selector.

XPath stijl van nodes selecteren (css):
Beter nog zou het zijn om in XPath stijl elementen te kunnen selecteren. Dan heb je dus ook de beschikking over alle axissen van XPath en dat zou een aparte parent selector geheel overbodig maken. Mischien dat dit het wel een stuk complexer maakt, maar het geeft je wel veel mogelijkheden en flexibiliteit.

meerdere achtergrond afbeeldingen (css):
In css heb je nu de mogelijkheid om een element een achtergrond afbeelding te geven. Toch komt het bij mij meer dan eens voor dat ik op een bepaalde plaats meerdere afbeeldingen in de achtergrond wil combineren. Nu moet ik dan gaan zitten klooien met extra 'wrapper' elementen die geen enkele semantische betekenis hebben. Ik probeer ze dan wel zo'n naam te geven dat het niet te herleiden is tot de vormgeving, maar puur tot de structuur. Toch zou het fijn zijn als dit geheel overbodig zou zijn. In css 3 krijg je ook de mogelijkheid om de borders een achtergrond afbeelding te geven, maar dit zou imo toch best een mooie toevoeging zijn. Hoe dit geimplementeerd zou moeten worden weet ik niet. Je krijgt dan natuurlijk te maken met ordening van die afbeeldingen, mischien dat je iedere afbeelding een ID kunt geven en zo ook op andere plaatsen precies de eigenschappen van die afbeelding kunt overschrijven. (deze is dus al gespecificeerd in CSS3)

extra elementen toevoegen vanuit de stylesheet (css):
Het lijkt me ook erg fijn om extra afbeeldingen toe te kunnen voegen vanuit de stylesheet. Dit zou geimplementeerd kunnen worden dmv. een speciale property waarin je kunt aangeven dat het element alsnog toegevoegt moet worden als het niet gevonden is in het document (ergens achteraan, of op een te specificeren plaats, zoals na een ander element bv.). Dit zou ik graag willen, omdat er wel eens elementen in het document voorkomen die eigenlijk niets met de inhoud of structuur te maken hebben. Ze staan er alleen om gebruikt te worden voor layout of stijl doeleinden. Kijk bijvoorbeeld eens naar css Zen Garden. Onderin zie je daar ook wat extra divs staan.

Nu ben ik natuurlijk ook erg benieuwd wat jullie graag zouden willen toe voegen. Graag ook met een kleine onderbouwing. Als iemand kritiek heeft op mijn toevoegingen, dan graag. Ik wil graag weten waarom dan juist niet of wel zou kunnen.

[TwoR]

Voor zover ik weet is het niet mogelijk om vanuit CSS de Cellspacing en Cellpadding van je tabel te zetten. Ja het kan wel maar dan een grote omweg. Ergens hier op GoT staat die uitleg wel.
Maar wat ik fijn zou vinden is dat die gewoon een standaard wordt in CSS. Nu doe ik dit nog regelmatig gewoon in de HTML maar dat is niet echt netjes.

[ Voor 13% gewijzigd door TwoR op 17-08-2005 13:25 ]

[Barracuda_82]

Meerdere achtergrondafbeeldingen zou ik echt super vinden als ze dat ooit maken. Dan kun je mooi liquid divjes maken met afegronde hoekjes enzo.

[OkkE]

Ik stem inderdaad ook voor meerdere background-images per element. Verder kan ik zo even niets bedenken wat er niet al is..

Maar ik zou al heel gelukkig zijn als a) alle standaarden volledig geimplementeerd zouden zijn en b) er niet zo'n groot verschil tussen de brouwsers zou bestaan. Maar dat is weer off-topic, sorry.

[ Voor 12% gewijzigd door OkkE op 17-08-2005 13:35 ]

[Willem]

TwoR: padding / (margin) (~table td.piet)

[TwoR]

willem169 schreef op woensdag 17 augustus 2005 @ 13:34:
TwoR: padding / (margin) (~table td.piet)

op die manier hou ik op de een of andere reden altijd ruimte tussen TD's .

Zal er nog eens naar kijken

[Michali]

Barracuda_82 schreef op woensdag 17 augustus 2005 @ 13:32:
Meerdere achtergrondafbeeldingen zou ik echt super vinden als ze dat ooit maken. Dan kun je mooi liquid divjes maken met afegronde hoekjes enzo.

Dat is op zich al goed te doen met de css 3 specificatie, die zegt dat je alle border (inclusief de hoeken) een afbeelding kan geven.

Nu ik dit op zoek, zie ik ineens dat het al wel gespecificeerd is. Laat dat toevoegen dus maar weg, deze zit er al in . (nu nog de implementatie, maar het zit er iig wel aan te komen)

[OkkE]

TwoR schreef op woensdag 17 augustus 2005 @ 13:36:
[...]

op die manier hou ik op de een of andere reden altijd ruimte tussen TD's .

Zal er nog eens naar kijken

code:

table { border-collapse: collapse; }

Dit zou dat moeten oplossen.

[ Voor 3% gewijzigd door OkkE op 17-08-2005 13:37 ]

[Michali]

TwoR schreef op woensdag 17 augustus 2005 @ 13:36:
[...]

op die manier hou ik op de een of andere reden altijd ruimte tussen TD's .

Zal er nog eens naar kijken

Dan moet je de border-spacing van je table op 0 zetten.

[TwoR]

@ Michali en OkkE:
Ja thats it. Waarom wist ik dat niet. Naja verder ontopic maar weer want dit was dan niet iets wat nog toegevoegt moet worden.

[crisp]

Meerdere achtergronden is al voorgesteld als CSS3 feature Safari ondersteund het al

[Michali]

crisp schreef op woensdag 17 augustus 2005 @ 13:44:
Meerdere achtergronden is al voorgesteld als CSS3 feature Safari ondersteund het al

Ik zag het net ja toen ik de spec weer eens doornam. Ik was het eerder niet tegen gekomen, ik heb het de laatste tijd dan ook niet echt veel bekeken.

[HunterPro]

ik heb het eergister met een paar australiers en een duitser gehad over SVG (hier op de campus van de UT is een SVG conference). Daaruit kwamen we op een gegeven moment bij scripting etc. En toen vertelde een van hun me dat 20% van alle (!) javascript op het internet, bestaat uit een paar standaard macromedia functies. Dan heb ik het dus over van die onload, mouseover etc functies. 20%! Oftewel, je kan als je dat soort basic dingetjes omzet naar een standaard, hoe raar (en ranzig) het ook klinkt, zorgen voor 20% minder (onzinnige) code op het net. Dag ranzige stukjes code en omwegen, en hoi nette oplossingen voor zoiets.

[Verwijderd]

Betere controle over elementen in zowel de breedte als de hoogte.

Het W3 boxmodel is niet logisch, graag de oude situatie... een wrapper van 100% height met een padding top of padding bottom veroorzaakt zonder boxmodel wijzigingen een scrollbar. Je moet de meest idiote workarounds verzinnen om deze vaak voorkomende situatie te omzeilen.

Minder gemier over properties die specifiek afhankelijk zijn van andere properties (block/inline) verhaal icm alignment en centrering. Het gaat zijn doel totaal voorbij.

Niet direct een markup gerelateerde standard, maar verbeterde ondersteuning voor upload controls. evt. public static methods als getBytesTransfered(), getTransferSpeed() zodat er progress kan worden getoond.

In overall, betere ondersteuning voor standaard controls. We zitten nu al jaren tegen basis controls aan te kijken, terwijl het aantal web applicaties groeit.

Generieke drag n drop, zonder window beperkingen. Iframes zijn nodig om de load te verdelen in een grote web interface, maar beperkt de mogelijkheden van drag n drop.

Antialiased tekst, eventueel te bepalen met een antialias property voor css.

Meerdere background images is bepaald in CSS 3, evenals columns, en meerdere borders (innerborder, outerborder), en verwacht ik zo rond 2020 crossbrowser geimplementeerd.

Voor de rest is het vooral nog een kwestie van missende ondersteuning.

[ Voor 4% gewijzigd door Verwijderd op 17-08-2005 14:00 ]

[Standeman]

polygone divjes... in plaats van alleen maar rechthoekige blokken!!

[HunterPro]

Standeman schreef op woensdag 17 augustus 2005 @ 14:04:
polygone divjes... in plaats van alleen maar rechthoekige blokken!!

kijk eens naar SVG

[Michali]

Dat zou idd erg mooi zijn, als dat allemaal ondersteund zou worden Gordijnstok. Vooral die drag & drop en beter boxmodel zou erg fijn zijn.

[Scrummie]

Zit al in CSS3.. maar: Tekst door laten lopen in meerdere kolommen. Dus:

code:

    col1           col2              col3

Tekst Tekst      Tekst Tekst       Tekst Tekst
Tekst Tekst      Tekst Tekst       Tekst Tekst
Tekst Tekst      Tekst Tekst       Tekst Tekst
Tekst Tekst      Tekst Tekst       Tekst Tekst

Kolom 1 vol? Automatisch tekst doorschuiven naar Kolom 2..
Zoals dit in pakketen als InDesign en Quark al sinds het begin der tijden kan

Hier zit ik dus echt op te wachten, support voor zoiets.

[ Voor 20% gewijzigd door Scrummie op 17-08-2005 14:30 ]

[Annie]

Heb het al eens in een ander topic geplaatst: mogelijkheid tot groepering van selectors.

Voorbeeldje:

code:

.someclass h1, .someclass h2, .someclass h3 { color: red; }

wordt dan bijv iets als:

code:

.someclass { h1, h2, h3 { color: red; } }

[Verwijderd]

Wat ik handig zou vinden dat het voor internet explorer eens moglijk word om een hover attribuut aan een niet <a> element te kunnen koppelen. Zodat pure css dropdown menu's eens mogelijk worden (zoals in firefox al het geval is)

[crisp]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:32:
Wat ik handig zou vinden dat het voor internet explorer eens moglijk word om een hover attribuut aan een niet <a> element te kunnen koppelen. Zodat pure css dropdown menu's eens mogelijk worden (zoals in firefox al het geval is)

waarschijnlijk in IE7...

[Verwijderd]

Annie schreef op woensdag 17 augustus 2005 @ 14:30:
Heb het al eens in een ander topic geplaatst: mogelijkheid tot groepering van selectors.

Voorbeeldje:

code:

.someclass h1, .someclass h2, .someclass h3 { color: red; }

wordt dan bijv iets als:

code:

.someclass { h1, h2, h3 { color: red; } }

Dit zou inderdaad ideaal zijn, of een import statement op een selectie.

.leftcol @import "article.css"
.rightcol @import "article.css"

Of, maar dan gaat het verder, interfaces in css. Als je wilt dat je objecten voldoen aan bepaalde css eisen, kun je daar een css interface voor maken.

[ Voor 15% gewijzigd door Verwijderd op 17-08-2005 14:47 ]

[McVirusS]

Meer standaard form-elementen; met name een slider en een combobox. Standaard implementatie van rollovers (en andere states e.d.). Zijn zomaar paar dingen die in me opkomen.

[McVirusS]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:44:
Of, maar dan gaat het verder, interfaces in css. Als je wilt dat je objecten voldoen aan bepaalde css eisen, kun je daar een css interface voor maken.

Zou wel nice zijn maar dat heeft alleen zin tijdens het ontwikkelen natuurlijk. Intressante gedachtengang though .

[McVirusS]

Formvalidatie opnemen in de standaard zou ook wel wat zijn .

[-Lars-]

Een compleet nieuwe set tags om eenvoudig grafieken en diagrammen te kunnen toevoegen aan een webpagina. Er zijn vast plugins e.d., maar dat levert slechte ondersteuning op. Natuurlijk kun je nu grafieken plaatsen door het gewoon als afbeelding te plaatsen, maar dat zit me toch niet helemaal lekker. Wat moet er dan precies in een alt-attribuut staan of op een speciale pagina met een langere beschrijving?

De grafiekgegevens passen meestal nog het best in een tabel, het zou dus ook mooi zijn als je met CSS aan kunt geven dat een tabel als grafiek moet worden weergegeven. Eerlijk gezegd weet ik niet echt wat het best is: een HTML- of CSS-oplossing.

I'm dreaming again

[IschaGast]

Qua formelementen kan er nog wel wat verbeterd worden inderdaad.
Het zou mooi zijn als je alle formelementen zou kunnen stijlen op 1 of andere manier.

[Clay]

Michali schreef op woensdag 17 augustus 2005 @ 13:17:
parent selector (css):
Je hebt in css al de beschikking over een child selector, maar het lijkt me toch handig om ook een parent te kunnen selecteren. Stel dat je bijvoorbeeld een menu hebt, opgebouwd mbv. een unordered list met een achtergrond afbeelding en enkele list items met achtergrond afbeeldingen. Nu wil je graag dat als over een li element gehoverd wordt, dat dan zowel de achtergrond afbeelding van de list item als van de complete lijst veranderd. Nu is zo iets nog niet mogelijk, maar lijkt me toch handig als dit wel kan met een parent selector.

Ideeen hiervoor bestaan al een flinke tijd. het laatste wat ik hiervan gezien heb is :matches(), en dat zou er in een rule dan ongeveer zo uitzien:

Cascading Stylesheet:

ul:matches(>li:hover) {
}

De parser kan dan ook gewoon "vooruit" blijven lezen, en toch eigenlijk naar de parent kijken.

XPath stijl van nodes selecteren (css):
Beter nog zou het zijn om in XPath stijl elementen te kunnen selecteren. Dan heb je dus ook de beschikking over alle axissen van XPath en dat zou een aparte parent selector geheel overbodig maken. Mischien dat dit het wel een stuk complexer maakt, maar het geeft je wel veel mogelijkheden en flexibiliteit.

Hier verschillen de meningen ook over. Je kan misschien meer, maar het maakt het idd veel complexer en selectors worden er vele malen langer van. Een parent selector is (zie boven) in de xpath vorm eigenlijk niet nodig, en bovendien kent xpath niet zoiets als specificity, wat een (hoewel onbekend) fundamenteel aspect van cascading stylesheets is. Van mij mag xpath dus lekker bij xsl blijven.

Wat ik graag zou zien is dat css2.1 nou eindelijk eens overal lekker geimplementeerd is op zich mankeert er minder aan dan je zou denken, je kan er alleen maar zo weinig van gebruiken. En een media attribuut voor script tags lust ik ook wel.

[Verwijderd]

Verwijderd schreef op woensdag 17 augustus 2005 @ 14:32:
Wat ik handig zou vinden dat het voor internet explorer eens moglijk word om een hover attribuut aan een niet <a> element te kunnen koppelen. Zodat pure css dropdown menu's eens mogelijk worden (zoals in firefox al het geval is)

Naast het toevoegen van mogelijkheden aan de standaarden is het idd niet verkeerd om die standaarden toe te voegen aan de browsers...

De meerdere tekstkolommen zit ik ook al een tijdje op te wachten.

[KneoK]

-Larz- schreef op woensdag 17 augustus 2005 @ 16:00:
Een compleet nieuwe set tags om eenvoudig grafieken en diagrammen te kunnen toevoegen aan een webpagina. Er zijn vast plugins e.d., maar dat levert slechte ondersteuning op. Natuurlijk kun je nu grafieken plaatsen door het gewoon als afbeelding te plaatsen, maar dat zit me toch niet helemaal lekker. Wat moet er dan precies in een alt-attribuut staan of op een speciale pagina met een langere beschrijving?

De grafiekgegevens passen meestal nog het best in een tabel, het zou dus ook mooi zijn als je met CSS aan kunt geven dat een tabel als grafiek moet worden weergegeven. Eerlijk gezegd weet ik niet echt wat het best is: een HTML- of CSS-oplossing.

I'm dreaming again

Grafieken kun je heel makkelijk in allerlei programma's maken (maak er een mooi plaatje van in Paint ?). Je zou zelfs met wat divjes onder/naast elkaar al een leuk ogende grafiek kunnen maken.

[Yoozer]

BioWEB schreef op woensdag 17 augustus 2005 @ 16:44:Grafieken kun je heel makkelijk in allerlei programma's maken

En die moet je of vinden of er voor betalen. Moet beter kunnen.

(maak er een mooi plaatje van in Paint ?).

Mooi en Paint in dezelfde zin?

Paint is ran-zig. Geen grid waar je vaste breedtes kunt instellen, dus het is maar afwachten of alles breed genoeg is. Geen gradients, fatsoenlijke selecties. Geen update als je even je maten moet aanpassen. Paint is een in- en in-triest programma. Paint.Net is beter maar niet van MS zelf - overigens wil ik niks van MS, ik wil wat in de specs! .

Je zou zelfs met wat divjes onder/naast elkaar al een leuk ogende grafiek kunnen maken.

En zo wordt het meestal ook al gedaan. Maar een grafiek genereren op een set van gegevens is eigenlijk beter met serverside en VML (dat mag er ook heel snel in komen) of met serverside en een applicatie die afbeeldingen op verzoek kan genereren. Dit is echter nog niet eenvoudig genoeg. Iets als

code:

<label for="userOS">Operating systems</label>
<chart id="userOS" style="type:pie; width: 200px; height:200px;">
   <slice value="20%" alt="Linux" style="color:purple;" />
   <slice value="50%" alt="Windows" style="color:blue;" />
   <slice value="30%" alt="Linux" style="color:yellow;" />
</chart>

maakt alle grafieken tenminste fatsoenlijk in plaats van in Paint ineengedraaide ranzige screenshots van een gewarezede Excel of zo .

[ Voor 10% gewijzigd door Yoozer op 17-08-2005 16:58 ]

[Michali]

-Larz- schreef op woensdag 17 augustus 2005 @ 16:00:
Een compleet nieuwe set tags om eenvoudig grafieken en diagrammen te kunnen toevoegen aan een webpagina. Er zijn vast plugins e.d., maar dat levert slechte ondersteuning op. Natuurlijk kun je nu grafieken plaatsen door het gewoon als afbeelding te plaatsen, maar dat zit me toch niet helemaal lekker. Wat moet er dan precies in een alt-attribuut staan of op een speciale pagina met een langere beschrijving?

De grafiekgegevens passen meestal nog het best in een tabel, het zou dus ook mooi zijn als je met CSS aan kunt geven dat een tabel als grafiek moet worden weergegeven. Eerlijk gezegd weet ik niet echt wat het best is: een HTML- of CSS-oplossing.

I'm dreaming again

SVG is daar erg handig voor. Dit is bijvoorbeeld een screen van een statistieken app die ik gemaakt heb met SVG:


Er komt natuurlijk wel wat rekenwerk bij kijken, maar het is in SVG toch best goed te doen. Je hebt nu idd problemen met ondersteuning, maar het is al wel bekend dat het binnenkort gewoon beschikbaar wordt binnen de browsers.

[Dark Blue]

rotatie van objecten (css)
Ik geloof dat het in Mozilla al mogelijk was, zo heb ik ooit eens gelezen/gedroomd, maar ik zou zo graag gehele ondersteuning willen voor het roteren van een object, zoals een div, of een stukje tekst.

text outlines en of randen (css)
Gewoon, een randje om je tekst, of helemaal geen fill colour maar alleen het randje.
Het is heel vies op te lossen nu met een glow filter wat alleen in IE werkt en daar een harde rand van maken met extreem foute waarden, dus een echte text-border optie zou geweldig zijn

[Alex)]

crisp schreef op woensdag 17 augustus 2005 @ 14:33:

[...]

waarschijnlijk in IE7...

Zeker weten in IE7, het staat al op hun 'fixed' lijstje

offtopic:
Die 'Check images' functie is leuk, maar hij zou wel Nederlandstalig mogen (net getest)

[HunterPro]

-Larz- schreef op woensdag 17 augustus 2005 @ 16:00:
Een compleet nieuwe set tags om eenvoudig grafieken en diagrammen te kunnen toevoegen aan een webpagina. Er zijn vast plugins e.d., maar dat levert slechte ondersteuning op. Natuurlijk kun je nu grafieken plaatsen door het gewoon als afbeelding te plaatsen, maar dat zit me toch niet helemaal lekker. Wat moet er dan precies in een alt-attribuut staan of op een speciale pagina met een langere beschrijving?

De grafiekgegevens passen meestal nog het best in een tabel, het zou dus ook mooi zijn als je met CSS aan kunt geven dat een tabel als grafiek moet worden weergegeven. Eerlijk gezegd weet ik niet echt wat het best is: een HTML- of CSS-oplossing.

I'm dreaming again

SVG! (ja ik ben bekeerd )

[Verwijderd]

ik wil niet heel vervelend zijn, maar wat is het doel hiervan?

Eigenlijk alle genoemde dingen zijn allang eens aan bod gekomen in de mailinglijsten van whatwg en www-style. of zelfs al opgenomen in de specs (css3 en html 5) of met reden verworpen.

om maar te noemen:
formvalidatie: zie html5
kolommen: css3
elementen genereren met css: zie css3 (:before, :after, :alternate, pending() etc)
allerlei fancy css dingen (polygons, grafieken etc): vergeet svg niet
parent selector: zie clay's post
XPath: als je een plan hebt om dit backwards compatible te doen en ook nog de incremental rendering in de gaten houdt, laat maar weten
form control styling: broser issue, + er komen wat extra selectors als :read-write en :read-only etc, lees de spec
antialiasing: browser / userissue


edit:
als iemand hier een concreet voorstel heeft voor een bepaalde feature en deze is nog niet eerder aan bod geweest binnen de working groups, dan lijkt he me nuttig het hier over te hebben, goed door te spreken en vervolgens op de mailinglijst te kwakken, maar anders zie ik het nut van dit topic eigenlijk niet zo

[ Voor 70% gewijzigd door Verwijderd op 18-08-2005 11:01 ]

[Michali]

Verwijderd schreef op donderdag 18 augustus 2005 @ 10:07:
als iemand hier een concreet voorstel heeft voor een bepaalde feature en deze is nog niet eerder aan bod geweest binnen de working groups, dan lijkt he me nuttig het hier over te hebben, goed door te spreken en vervolgens op de mailinglijst te kwakken, maar anders zie ik het nut van dit topic eigenlijk niet zo

Het nut van dit topic is om je ideeën de vrij loop te laten gaan en om te kijken wat er uit komt. Erg fijn als veel van de gevraagde zaken al besproken of zelfs gespecificeerd zijn, maar ik vind het toch fijn om er dan ook achter te komen. Het lijkt me juist leuk als mensen ideeën krijgen over verbetering of toevoeging, dat die dat dan hier neer zetten en er over discussiërren.

Over :alternate en pending() kan ik niets vinden trouwens. Heb je mischien een linkje?

[Barracuda_82]

Variabelen in CSS
Ik zou graag zien dat je in CSS variabelen kan declareren. Zo ongeveer:

Cascading Stylesheet:

#kleur1 = #FF9900;

b {
   color: #kleur1;
}

Zo kun je makkelijk kleuren veranderen van meerdere elementen in een pagina.

Rounded corners
Afgeronde hoeken als standaard voor verschillende elementen als div, li, table, td, etc. Dat zie ik zo voor me:

Cascading Stylesheet:

div {
   corners: 10px;
}

10px staat dan voor de radius van de afgeronde hoek.

[coubertin119]

Variabelen in CSS kan dmv SSV-CSS, alleen heb je dan wel PHP-geparsete CSS-bestanden, maar dat kan de pret niet drukken.

En rounded corners kan ook al in Gecko, met -moz-border-radius, je kan in de CSS3 spec gaan zoeken op border-radius.

[Blue-eagle]

Fonts. Ik wil exotischer fonts kunnen gebruiken zonder vieze noodoplossingen of Flash te gebruiken. Ik wil gewoon tekst kunnen typen in ieder willekeurig (rechtenvrij?) font. Misschien is dat erg veiligheidsgevoelig omdat er een font bestand moet worden ingelezen over http maar ik denk dat met een slimme opzet de browser dit wel kan isoleren of iets dergelijks. In ieder geval, een standaard font oplossing.

Verder mogen ze van mij het hele css model wel opnieuw uitvinden, liever een iets geavanceerdere "syntax" en "nesting" dan wat we nu hebben...

code:

(//div[@id='wrap']) {
    display: block;
    float: left;
    etc...

    (div[@id='header']/h1) {
        color: #fff;
        background: #000;
    }

}

[Verwijderd]

Michali schreef op donderdag 18 augustus 2005 @ 13:01:
Over :alternate en pending() kan ik niets vinden trouwens. Heb je mischien een linkje?

http://www.w3.org/Style/CSS/current-work

specifiek:
http://www.w3.org/TR/2003/WD-css3-content-20030514/

Barracuda_82 schreef op donderdag 18 augustus 2005 @ 14:33:
Variabelen in CSS
Ik zou graag zien dat je in CSS variabelen kan declareren. Zo ongeveer:

Cascading Stylesheet:

#kleur1 = #FF9900;

b {
   color: #kleur1;
}

Zo kun je makkelijk kleuren veranderen van meerdere elementen in een pagina.

Rounded corners
Afgeronde hoeken als standaard voor verschillende elementen als div, li, table, td, etc. Dat zie ik zo voor me:

Cascading Stylesheet:

div {
   corners: 10px;
}

10px staat dan voor de radius van de afgeronde hoek.

variabelen: niet nodig, je kan toch voor alle elementen de kleur in 1 keer zetten, lwestie van slim gebruik maken van cascading:

ronde hoeken: zie css3

complete rewrite van de syntax: leuk, maar hoe hou je dat backwards compatible:

mensen: lees je eens wat meer in in de materie, nu is het een beetje een topic van "gaat dit komen?" - "ja/nee, zie ~" specs doorlezen kunnen jullie zelf ook

[Michali]

Verwijderd schreef op donderdag 18 augustus 2005 @ 15:06:
variabelen: niet nodig, je kan toch voor alle elementen de kleur in 1 keer zetten, lwestie van slim gebruik maken van cascading:

Je weet toch niet altijd van te voren welke elementen een bepaalde kleur nodig hebben? Je kan natuurlijk wel een aparte class maken en die aan al die elementen geven, maar dan vervuil je je html op een manier die niet echt netjes is.

Wat ik graag toegevoegd zou willen zien is om een complete class te kunnen erven. Iets in de zin van:

Cascading Stylesheet:

.eenSuperClass
{
  /* eigenschappen */
}

.eenSubClass extends eenSuperClass
{
  /* extra eigenschappen */
}

Nu zou dit zo moeten:

Cascading Stylesheet:

.eenSuperClass,
.eenSubClass
{
  /* eigenschappen */
}

.eenSubClass
{
  /* extra eigenschappen */
}

En dat is niet altijd mogelijk als eenSuperClass gedefineerd is in een algemeen css bestandje. Zeker als je een grote website hebt met zo veel css dat het in verschillende files opgedeeld moet worden (laatst had ik bv. een website met +- 40 css bestanden a 100 regels), dan is het lastig om een goede structuur te houden en om bepaalde stijlen niet te kopieeren. In dit geval zou het dan wel geheel gekopieerd moeten worden. Een andere optie is om een element 2 classes te geven, maar dan ben je in je HTML doc weer bezig met stijl zaken, en dat is imo niet echt de bedoeling.

[Pelle]

Formvalidatie vind ik wel een goeie, iets als inputmasks bijvoorbeeld zou zeer handig zijn. Natuurlijk kun je een hoop doen met javascript, maar dat is altijd nog een workaround voor iets wat je browser je gewoon kan verbieden, in plaats van dat je met een script de onkeyup enzo moet afvangen.

Verder een manier om in CSS fatsoenlijk kolommen te kunnen maken met div's, zodat je niet meer met tables of ranzige oplossingen met CSS hacks hoeft aan te komen zetten.

Tot slot vind ik dat een parent element een child element dat absoluut gepositioneerd is, volledig moet (kunnen) omvatten. Stel, ik maak een div met daarin 1 regel tekst, en in die div ook nog een child div, die ik absoluut positioneer op met een top en left van 500px. De parent div is dan zo hoog als de regel, maar ik wil dat die parent div zo hoog wordt als dat nodig is om ook de child-div te omsluiten.

[Verwijderd]

als je een uitgewerkt idee hebt en kan zorgen dat dit backwords compatible blijft, de cascade rules blijft volgen en nog steeds in 1-pass te parsen is, dan denk ik dat je nog wel een kansje maakt met je voorstel. Dit is serieus al bijzonder vaak langsgekomen op de mailing lijsten. En iedere keer wordt het verworpen om oa. bovenstaande redenen.

Zoek anders even daar als je er verder in geinteresseerd bent

@pelle:
forms: zie pattern attrubute in html 5 http://www.whatwg.org/spe...current-work/#the-pattern
kolommen: css3
laatste punt: geen idee

[ Voor 17% gewijzigd door Verwijderd op 18-08-2005 16:33 ]

[Annie]

Verwijderd schreef op donderdag 18 augustus 2005 @ 15:06:
mensen: lees je eens wat meer in in de materie, nu is het een beetje een topic van "gaat dit komen?" - "ja/nee, zie ~" specs doorlezen kunnen jullie zelf ook

Dus omdat het ergens op internet staat, maakt dat we er niet meer over mogen discussieren in een forum? Ik lees de w3 site niet dagelijk door; so sue me.

[Verwijderd]

ik vind het idd voor een groot deel uitgemolken en na te zoeken discussie om eerlijk te zijn. Dit is niet de enige plek waar dingen worden besproken, veel is gewoon na te zoeken. Ik vind het raar dat mensen allerlei dingen "bedenken" en er vervolgens over gaan discussieren hoe het geimplementeerd moet worden als het allang in de molen zit.

Beetje research doen doet niemand kwaad

http://lists.w3.org/Archives/Public/www-style/ - www.style mailing list
http://www.whatwg.org/mailing-list - what wg mailing list
http://www.whatwg.org/specs/ - "html 5" spec
http://www.w3.org/Style/CSS/current-work - css3 spec

speciaal voor form validation, repetition etc: http://www.whatwg.org/specs/web-forms/current-work/ de web forms 2.0 spec

een css faq: http://www.grauw.nl/articles/css-faq.php#cr-vs-r

[ Voor 45% gewijzigd door Verwijderd op 18-08-2005 16:40 ]

[Cavorka]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:25:
ik vind het idd voor een groot deel uitgemolken en na te zoeken discussie om eerlijk te zijn. Dit is niet de enige plek waar dingen worden besproken, veel is gewoon na te zoeken. Ik vind het raar dat mensen allerlei dingen "bedenken" en er vervolgens over gaan discussieren hoe het geimplementeerd moet worden als het allang in de molen zit.

Beetje research doen doet niemand kwaad

http://lists.w3.org/Archives/Public/www-style/ - www.style mailing list
http://www.whatwg.org/mailing-list - what wg mailing list
http://www.whatwg.org/specs/ - "html 5" spec
http://www.w3.org/Style/CSS/current-work - css3 spec

speciaal voor form validation, repetition etc: http://www.whatwg.org/specs/web-forms/current-work/ de web forms 2.0 spec

een css faq: http://www.grauw.nl/articles/css-faq.php#cr-vs-r

NOFI, maar wat loop je te zeuren over dit topic? Wat wil je precies bereiken met al je opmerkingen? Zoals gezegd: niet iedereen kent de w3c website uit zijn hoofd.

Anyways: wat ik wel wil zien is een goed werkende CSS shadow optie. Zonder lelijke hacks als dubbele divs of spans in een paragraph.

[ Voor 13% gewijzigd door Cavorka op 18-08-2005 17:30 ]

[alienfruit]

http://www.w3.org/TR/2005...-20050216/#the-box-shadow en
http://www.w3.org/TR/REC-CSS2/text.html#text-shadow-props

[ Voor 101% gewijzigd door alienfruit op 18-08-2005 17:47 ]

[Bluestorm]

Verwijderd schreef op donderdag 18 augustus 2005 @ 15:06:
variabelen: niet nodig, je kan toch voor alle elementen de kleur in 1 keer zetten, lwestie van slim gebruik maken van cascading:

Yep, maar wat nou als ik wil dat de border van element1 de zelfde kleur heeft als de achtergrond van element2 ?

Die door blue-eagle genoemde geneste syntax heb ik ook heel lang gedacht dat dat nodig was, maar sinds ik m'n css gewoon opmaak alsof 't genest zou zijn, is die behoefte een beetje weggevallen.

code:

.a{
    ....
}
    .a .b{
        ....
    }

Helaas wel wat overbodig schrijfwerk dan bij wat complexere structuren.

Iets wat mij wel fijn zou lijken is als je wat meer in relaties kunt uitdrukken. Ik zou dingen willen beschrijven als 'de zelfde hoogte als element X'. Want dat is toch eigenlijk de manier waarop je over layout etc denkt. Dus eigenlijk expressies op basis van eigenschappen van de dynamische elementen. Zou een hoop JS schelen.
Maar dat gaat dan weer een beetje buiten de huidige werking van CSS om.

Gordijnstok, Iframes vormen toch niet echt een beperking voor drag 'n drop? Maar het zou idd fijn zijn als daar gewoon iets generieks en standaards voor kwam. En dat je dan ook mooi drag acties uit andere windows en applicaties zou kunnen afvangen.


Ohja... een File control die multiple files ondersteund... Zodat je niet oneindig vaak door de 'browse' ....dialoog heen hoeft om files te uploaden.

[ Voor 12% gewijzigd door Bluestorm op 18-08-2005 18:07 ]

[Cavorka]

alienfruit schreef op donderdag 18 augustus 2005 @ 17:44:
http://www.w3.org/TR/2005...-20050216/#the-box-shadow en
http://www.w3.org/TR/REC-CSS2/text.html#text-shadow-props

Maar de een is dus nog totaal niet supported (volgens mij alleen supported in Safari 1.1) en de ander gaat er misschien aankomen in CSS3. Ik wil het NU!

[ Voor 6% gewijzigd door Cavorka op 18-08-2005 18:15 ]

[Michali]

Cavorka schreef op donderdag 18 augustus 2005 @ 18:14:
[...]

Maar de een is dus nog totaal niet supported (volgens mij alleen supported in Safari 1.1) en de ander gaat er misschien aankomen in CSS3. Ik wil het NU!

Ik wil het ook graag nu, jammer dat het allemaal zo traag gaat.

Dat web forms ziet er ook wel erg goed uit zeg. Hopelijk gaan ze zoiets ook doorvoeren als 'echte' standaard.

[ Voor 3% gewijzigd door Michali op 18-08-2005 18:22 ]

[Gomez12]

Wat ik graag toegevoegd zou willen zien op dit moment is maar 1 simpel ding : een eis dat de implementatie binnen x tijd in elke browser 100% ondersteunt wordt. Nu heb je nog steeds bijna van die heerlijke browsersdetection scripts nodig ( of vage hacks ) om rond de nog niet geimplementeerde browser verschillen heen te komen, je ondersteunt css 1.0/2.0/3.0 100% of je ondersteunt het niet.

[Verwijderd]

Verwijderd schreef op donderdag 18 augustus 2005 @ 16:25:
ik vind het idd voor een groot deel uitgemolken en na te zoeken discussie om eerlijk te zijn. Dit is niet de enige plek waar dingen worden besproken, veel is gewoon na te zoeken. Ik vind het raar dat mensen allerlei dingen "bedenken" en er vervolgens over gaan discussieren hoe het geimplementeerd moet worden als het allang in de molen zit.

Kerel hou je dan buiten het topic en stop met dat gejammer. De laatste drie replies van jou waren "wat is het nut van dit topic" "is al behandeld" "staan de mailinglists vol van". Het hele punt van een forum is dat je een discussie kunt houden

[sjaakaq]

Blue-eagle schreef op donderdag 18 augustus 2005 @ 14:58:
Fonts. Ik wil exotischer fonts kunnen gebruiken zonder vieze noodoplossingen of Flash te gebruiken. Ik wil gewoon tekst kunnen typen in ieder willekeurig (rechtenvrij?) font. Misschien is dat erg veiligheidsgevoelig omdat er een font bestand moet worden ingelezen over http maar ik denk dat met een slimme opzet de browser dit wel kan isoleren of iets dergelijks. In ieder geval, een standaard font oplossing.

Goed idee; ik snap het gehannes met IE only embedded fonts ook nooit zo goed; je zet in je CSS een linkje naar een font bestand (.ttf e.d.), wat de browser vervolgens in je temp map zet en gebruikt...

[Verwijderd]

Verwijderd schreef op donderdag 18 augustus 2005 @ 19:46:
[...]


Kerel hou je dan buiten het topic en stop met dat gejammer. De laatste drie replies van jou waren "wat is het nut van dit topic" "is al behandeld" "staan de mailinglists vol van". Het hele punt van een forum is dat je een discussie kunt houden

Mijn hele punt is eigenlijk dat ik van heel veel "ideeen" die hier aangedragen worden het vermoeden heeft dat men niet eens weet waar ze over discussieren en dat lijkt me bij een goede discussie toch wel van belang. Ik gooi niet voor niks zoveel links in de strijd. Er zijn een hoop dingen waar je je gewoon aan moet houden in css, zoals backwards compatibility etc. Als mensen een idee hier neergooien zou ik het leuk vinden als ze ook nadenken hoe je dat dan zou moeten implementeren en of dat eigenlijk wel kan. Dat maakt een topic als deze imho interessant, anders wordt het gewoon een opsom topic met "ik wil dit, ik wil dat". En niet eens weten dat het merendeel gewoon al in de pipeline zit.

Wat ik dus eigenlijk bedoel: weet wat er in de pipeline zit voordat je hier een idee neergooit (dus: lees css3 en html5) en denk een beetje verder dan alleen een idee, dat houdt een topic op een niveau wat denk ik op GoT wel op z'n plaats is.

M'n bedoeling is iig echt niet om iedereen neer te maaien, ik denk dat dit potentieel een heel interessant topic kan zijn, maar dan hoop ik wel dat mensen weten wat er op dit moment speelt hier en daar.

Ik vind ook niet dat iedereen alle specs uit z'n hoofd moet kennen (ken ik zelf ook niet), maar in een topic als deze lijkt het me toch wel handig om voor je een idee (of een reactie) aankaart even te kijken of het al niet bestaat of in de pipeline zit, want in dat geval zie ik de discussie niet zo (ja ik wil graag kolommen - nou daar is al aan gedacht, zit in css3). kan je verder wel discussieren over de specifieke implementatie, maar over de syntax etc liggen er al gewoon specs

[ Voor 19% gewijzigd door Verwijderd op 18-08-2005 23:57 ]

[alienfruit]

Goed idee; ik snap het gehannes met IE only embedded fonts ook nooit zo goed; je zet in je CSS een linkje naar een font bestand (.ttf e.d.), wat de browser vervolgens in je temp map zet en gebruikt...

Dan moet je IE/browser wel de juiste rechten hebben, normaal kan een gebruiker onder Limited geen lettertypes installeren

[Verwijderd]

Het enige dat ik zou willen lijkt me eenvoudig onmogelijk.
Namelijk uniforme, quirksvrije webbrowsers die alles op dezelfde manier afhandelen.

En los daarvan een ondersteuning voor het mime-type aplication/xhtml , zal er prolly al aankomen maar is toch iets dat ik zo snel mogenlijk ondersteund zou zien worden door IE.

[Gomez12]

Verwijderd schreef op donderdag 18 augustus 2005 @ 23:21:
[...]

Mijn hele punt is eigenlijk dat ik van heel veel "ideeen" die hier aangedragen worden het vermoeden heeft dat men niet eens weet waar ze over discussieren en dat lijkt me bij een goede discussie toch wel van belang. Ik gooi niet voor niks zoveel links in de strijd. Er zijn een hoop dingen waar je je gewoon aan moet houden in css, zoals backwards compatibility etc. Als mensen een idee hier neergooien zou ik het leuk vinden als ze ook nadenken hoe je dat dan zou moeten implementeren en of dat eigenlijk wel kan. Dat maakt een topic als deze imho interessant, anders wordt het gewoon een opsom topic met "ik wil dit, ik wil dat". En niet eens weten dat het merendeel gewoon al in de pipeline zit.

Wat ik dus eigenlijk bedoel: weet wat er in de pipeline zit voordat je hier een idee neergooit (dus: lees css3 en html5) en denk een beetje verder dan alleen een idee, dat houdt een topic op een niveau wat denk ik op GoT wel op z'n plaats is.

M'n bedoeling is iig echt niet om iedereen neer te maaien, ik denk dat dit potentieel een heel interessant topic kan zijn, maar dan hoop ik wel dat mensen weten wat er op dit moment speelt hier en daar.

Ik vind ook niet dat iedereen alle specs uit z'n hoofd moet kennen (ken ik zelf ook niet), maar in een topic als deze lijkt het me toch wel handig om voor je een idee aankaart even te kijken of het al niet bestaat of in de pipeline zit, want in dat geval zie ik de discussie niet zo (ja ik wil graag kolommen - nou daar is al aan gedacht, zit in css3. kan je verder wel discussieren over de specifieke implementatie, maar over de syntax etc liggen er al gewoon specs)

Ja en nee, iemand zou zich moeten inlezen in de standaarden die eraan gaan komen voor hier een idee te opperen mits deze standaarden binnen aanzienlijke tijd geimplementeerd worden....
Als ik zou verwachten dat ie7.0 css 2.1 volledig zou gaan ondersteunen dan zou ik (misschien want wanneer komt ie8.0 met css 3.0 support uit ) ook zeggen dat ze eerst eens moeten kijken wat er in de pipeline zit.

Maar zolang er op dit moment in de browser die 85 % van het internet beheerst nog niet eens 100% css 1.0 ondersteuning zit denk ik niet dat je echt hoeft te wachten op een IE / FF die 100% css 3.0 ondersteunt, en dat je maar beter in een topic als dit je ideeen kan spuiten en hopen dat iemand van het dev-team via via via via via via iets van jouw idee hoort en hoort dat er nog over gesproken wordt ook en dat het hij het implementeert in een volgende versie...

[Verwijderd]

Misschien leuk om ook iets toe te voegen :

een lopende discussie op www-style gaat over gradienten. Zijn die gewenst in CSS3, of zeggen we dat het het terrein van SVG is? als we gradienten gaan implementeren, hoe moet dat dan, en tot hoe ver gaan we?

Aangezien je een gradient als kleur zou willen toepassen ligt het voor de hand het als functie te definieren: gradient(), analoog aan rgb() of lsb().

Maar binnen die functie gradient() zal je minstens 2 kleuren moeten zetten, dus worden er (voor het eerst) functies genest, gaat dit wellicht geen problemen opleveren?

Wat voor gradienten willen we? lineair? of meer? 2 kleuren? of meer? hoe complex mag de syntax worden? wanneer trek je een streep en ga je het met SVG doen?

hoe zorg je ervoor dat als je bijvoorbeeld een gradient achtergrond (background-color: gradient()) van linksboven naar rechtsonder in een box hebt gedefinieert dat de rendering lekker loopt. De box kan namelijk groeien tijdens het laden van een pagina, dus dan moet je steeds opnieuw die gradient gaan berekenen, zulke dingen willen we in CSS eigenlijk zoveel mogelijk bepreken (zie die faq die ik postte).

[Michali]

Gradients zou best een leuke optie zijn. Als het geimplementeerd wordt, dan zou ik toch graag meerdere vormen willen zien. Denk dan aan types als linear, circle, elipse, bars, rectangular etc. Ik denk dat je dan al aardig uit de voeten kunt. Kwa implementatie is het mischien handig om voor ieder type een andere functie te maken, of 1 algemene functie die als 1ste parameter het type vraagt en daarna een vast aantal argumenten verschillend per type. Ik denk dat het toch fijn is om dit ook naast SVG te kunnen gebruiken. Kwa kleur zou ik het toch bij 2 houden. Anders wordt het specificeren wel zo complex dat je beter kunt overstappen naar SVG. Ik weet trouwens ook niet wat allemaal mogelijk is met SVG op gebied van gradients.

[sjaakaq]

alienfruit schreef op donderdag 18 augustus 2005 @ 23:32:
[...]


Dan moet je IE/browser wel de juiste rechten hebben, normaal kan een gebruiker onder Limited geen lettertypes installeren

Hmm ja ATM kan een browser allelei afbeeldingen, swf bestanden, ico bestanden, mpeg/wmv/andere video bestanden etc. etc. downloaden en in de temp folder zetten om te gebruiken, dus voor fomts lijkt het me ook niet zo'n rpobleem, toch?

[-Lars-]

BioWEB schreef op woensdag 17 augustus 2005 @ 16:44:
[...]


Grafieken kun je heel makkelijk in allerlei programma's maken (maak er een mooi plaatje van in Paint ?). Je zou zelfs met wat divjes onder/naast elkaar al een leuk ogende grafiek kunnen maken.

Dat is mijn punt ook niet. Mijn punt is dat de huidige technieken die ik kan gebruiken voor grafieken, wel kunnen worden begrepen door de mens, maar niet door de computer. En dat is juist wat niet de bedoeling was: de mens kon immers wel een table-layout begrijpen, maar de computer niet. En aangezien we allemaal dromen van een semantisch web, zou aparte grafiekondersteuning gewenst zijn.

Yoozer slaat de spijker op de kop.

Ik heb nu geen tijd om de hele SVG-W3C-documenten door te lezen, maar dat ga ik zeker nog eens doen. Toch kun je het niet maken als een bezoeker eerst een plugin of andere browser zou moeten instaleren voordat ze jouw grafieken op de site zouden kunnen zien. En aldus zal het wachten op browserondersteuning eeuwig blijven...

[Blue-eagle]

Gradients? What's next? Complete plaatjes kunnen opbouwen met CSS? Gradients gaan te ver, als je gradients wilt kan je die gewoon met een plaatje maken. Zeker als PNG volop wordt ondersteund hebben we meer dan genoeg aan plaatjes (transparante gradients bijvoorbeeld).

CSS != IMG

offtopic:
Bedankt trouwens voor die links, handig bookmarken zo

[Michali]

Blue-eagle schreef op vrijdag 19 augustus 2005 @ 16:06:
Gradients? What's next? Complete plaatjes kunnen opbouwen met CSS? Gradients gaan te ver, als je gradients wilt kan je die gewoon met een plaatje maken. Zeker als PNG volop wordt ondersteund hebben we meer dan genoeg aan plaatjes (transparante gradients bijvoorbeeld).

CSS != IMG

Dat kan toch al? In princiepe is een website een soort van dynamische en interactieve afbeelding. Gradients vind ik zelf niet zo vergezocht. Je kunt een element al een achtergrond kleur geven. In dit geval is het dan een solide kleur (eigenlijk zou je dit ook kunnen zien als een kleur verdeling, dan in de vorm van 1 enkele kleur geheel gelijkmatig verdeeld). Een gradient is gewoon een volgende stap. Het werkelijk beschrijven en stijlen van complexe vormen zou ik wel geheel aan SVG overlaten. Daar is dat ook voor bedoelt.

[Verwijderd]

Blue-eagle schreef op vrijdag 19 augustus 2005 @ 16:06:
Gradients? What's next? Complete plaatjes kunnen opbouwen met CSS? Gradients gaan te ver, als je gradients wilt kan je die gewoon met een plaatje maken. Zeker als PNG volop wordt ondersteund hebben we meer dan genoeg aan plaatjes (transparante gradients bijvoorbeeld).

CSS != IMG

offtopic:
Bedankt trouwens voor die links, handig bookmarken zo

da's idd een van de punten waar nu over gediscussieerd wordt, waar trek je de grens? het lijkt erop dat er een redelijke consensus bestaat dat simpele lineaire gradienten 90% van de behoeften wel dekt.

het idee: http://www.hesido.com/dis.../gradbrowserinterpret.png
dus een begin kleur, een eindkleur en een hoek.

de vraag is nog of een hoek nodig is, misschien windrichtingen (45 graden increments) of iets als tl-br ofzo wel handiger.

[Verwijderd]

Behalve de discussie of gradients nu wel of niet moeten, zijn gradients dmv afbeeldingen niet schaalbaar genoeg.

[alienfruit]

Hmm ja ATM kan een browser allelei afbeeldingen, swf bestanden, ico bestanden, mpeg/wmv/andere video bestanden etc. etc. downloaden en in de temp folder zetten om te gebruiken, dus voor fomts lijkt het me ook niet zo'n rpobleem, toch?

Moet de gebruiker wel de rechten hebben om de HKEY_LOCAL_MACHINE-key de benaderen, iets wat niet zo is bij gebruikers met "Limited"-rechten in Windows XP. Misschien kan het in IE wel omdat ze alle rechten hebben, maar ik zou het niet van Firefox verwachten. Als je namelijk Suitcase onder "Limited" wilt draaien moet je ook de gebruiker/groep ook de rechten geven op drie keys in HKEY_LOCAL_MACHINE. Zodat er nieuwe fonts kunnen worden geïnstalleerd.

[ Voor 33% gewijzigd door alienfruit op 20-08-2005 00:33 ]