css reset

Status
Niet open voor verdere reacties.
J

janyep

Gebruiker
Lid geworden
7 mei 2008
Berichten
261
Hallo,

Meyer werkt in zijn reset.css met http://meyerweb.com/eric/tools/css/reset/ :
Code: 
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed, 
figure, figcaption, footer, header, hgroup, 
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}

Weet iemand waarom dat niet zo zou kunnen:

Code: 
* {
	margin: 0;
	padding: 0;
	border: 0;
	font-size: 100%;
	font: inherit;
	vertical-align: baseline;
}

?
Ik hoop dat iemand wil reageren!
Bedankt, groeten janyep
 
Hoi janyep,
Dat zou in principe ook kunnen, lijkt me (ik heb het niet nageplozen, maar misschien zitten in html een aantal andere elementen, die niet op deze manier behandeld kunnen worden).
Ik vermoed dat Eric Meyer het complete opsommingsrijtje gebruikte om er makkelijk één of meer elementen uit te kunnen (laten) pikken die in een concrete site niet voor de reset in aanmerking moeten komen.

Maar terwijl een css-reset een jaar of 6 geleden best praktisch kon zijn (met IE5, IE5.5, IE6 en Netscape 5/6/9 als browsers): intussen zijn de browsers een stuk beter geworden in de ondersteuning van CSS en het volgen van de CSS-standaarden, en brengt een css-reset m.i. nu meer last dan gemak met zich mee.



Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
Hallo csshunter

oeps: wist niet dat dit topic nog openstond.
Je hebt wellicht wel gelijk: "intussen zijn ... ... en brengt een css-rest m.i. nu meer last dan gemak met zich mee."
Die reset is ook al weer van begin 2011.

En weer bedankt voor de reactie!
vriendelijke groet, janyep

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////


Ondertussen toch een verklaring van Meyer zelf gevonden op http://meyerweb.com/eric/thoughts/2007/04/18/reset-reasoning/
it does unfortunately mean that all elements will have their padding and margin zeroed, including form elements like textareas and text inputs.
In some browsers, these styles will be ignored. In others, there will be no apparent effect.
Klik om te vergroten...

Ook een paar interessante op http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/
#19 Kozio?ek wrote in to say...
Hi!
In first rule better is:
font-size:62.5%;
Why? All popular browsers has default font size equal 16px.
If we set font size equal 62.5% then font size is equal 10px at screen
(but not set 10px, IE6 not resize this rule).
Now we have 1em = 10px, so 1..1em=11px etc. It is easyer way to calculate font size.
//// wellicht: * {font-size:62.5% } ////
Klik om te vergroten...

#34 Jochen wrote in to say...
My only suggestion would be to exclude the ol-tag from the margin reset because it will
disable the browser to automatically determine the space needed based on how much space
the numeration actually needs. Defining this manually is fine as long as you have control
over the number of li-tags inside any given ol but if you have to deal with ol’s of
varying length it can be helpful to leave this to the browser.
Klik om te vergroten...
 
Over font-size !

Hoi janyep,
//// wellicht: * {font-size: 62.5% } ////
Klik om te vergroten...
Nou ...
  1. Dit was geen idee van Eric Meyer zelf, maar een suggestie van een meneer of mevrouw Koziołek.
  2. Eric Meyer is het daar duidelijk niet mee eens, in zijn algemene opmerkingen een stukje verderop: "To those who advocated using the universal selector, please see the post “Reset Reasoning” for an explanation of why I specifically don’t want to use the universal selector."
  3. Er speelt hier nog iets mee: een erfenis-kwestie! :rolleyes:

==========
Eerst de recht-voor-zijn-raap toepassing van de universele * {font-size: 62.5%} van Koziołek:

Hier komen veel te kleine letters uit, en ook aanzienlijke verschillen tussen de browsers; screenshots van 3 stuks:

font-sizing.png

Hierbij is in Internet Explorer (7) de "tekengrootte" (= lettergrootte) ook nog op Extra Groot gezet (dat helpt niet erg) ...
In IE8, IE9 en IE10-ConsumerPreview is er niet de te grote regelafstand van IE7.

==========
Maar er is méér aan de hand. Door de kleine letters zie je het bijna niet, maar er geldt volgens de CSS-standaarden:

  • "Percentage values are always relative to another value, for example a length." en
    "Child elements (generally) inherit the computed values of their parent" (zie hier)
  • "15.7 Font size: the 'font-size' property
    Inherited: yes. (zie hier).

Dat betekent: bij elke tag die de browser op zijn weg door de html-code tegenkomt, moet de lettergrootte met een stap van 62,5% verkleind worden. Het effect daarvan is nogal desastreus voor een beheersbare opmaak. Zodra je een nieuwe tag binnen een bestaand element plaatst (bv. een <div> om de positie der elementen te regelen, of een <span> om de letterkleur o.i.d. aan te passen), gaat het letterformaat ongevraagd (eigenlijk: wel gevraagd!) omlaag.
Dit gaat eindeloos door!

Nogmaals de recht-voor-zijn-raap toepassing van de universele * {font-size: 62.5%}, maar nu met een font-size van 500% voor de <html> (de root = "hoogste tag" waar alle percentages vandaan komen):

Hier is duidelijk te zien dat alles kleiner wordt als je de vertakkingen van de DOM-stamboom volgt.

==========
Hoe dan wel?
Om niet onderhevig te zijn aan onbedoelde lettergrootte-veranderingen, pas ik altijd het volgende toe:
  • De <html> geef ik geen font-size (dan wordt dat de default-waarde van 100%).
  • De <body> geef ik een font-size van 100.1%.
    Reden: zonder een percentage voor de <body> zijn de stappen van Internet Explorer tussen de browser-instellingen "Beeld > Tekengrootte > Extra klein | Kleiner | Normaal | Groter | Extra groot" veel te groot; door een <body>-percentage wordt dat genormaliseerd.
    De .1% extra op de 100% was vroeger nodig tegen een bug in Opera; veiligheidshalve laat ik dat er in staan.
  • Vervolgens kan ik bij alle elementen waarbij daar behoefte aan is, via de relatieve em-eenheid een afwijkende font-size geven, zonder dat de kinderen van die elementen ook automatisch meegeschaald worden.
    De kinderen erven gewoon de font-size van hun parent-element.

Nu deze manier, zonder de universele * {font-size: ..%}:

Browser-verschillen: geen. :)
(resp, minimale afwijkingen door afrondingsverschillen bij percentages en em's, en door minieme verschillen in afspatiëring van afzonderlijke lettertekens; maar daar is niets aan te doen).

PS/NB:
Er moeten geen absolute lettergroottes opgegeven worden (in px), want dan kunnen bezoekers met IE de lettergrootte niet naar behoefte in de browser aanpassen (dan kan alleen gezoomd worden, maar dan wordt alles vergroot, niet alleen de lettergrootte; en dan komt er dus een lelijke en onhandige scrollbar Links/Rechts bij!).

Met vriendelijke groet,
CSShunter
 
Laatst bewerkt:
Hallo csshunter

Doe je padding's en margin's ook in relatieve em's of gaan die in absolute px's ?

gr janyep


nb. dit was weer een geweldige reactie van je : daar kan een mens mee voort!
 
Ha janyep,
Dat laat ik van de opmaak afhangen; meestal zet ik de margins en paddings in pixels.

Maar soms kan het nodig zijn om em's te gebruiken, bv. bij het uitlijnen van een zelfgebakken image als bullet voor een opsommingsrijte.
En bij bv. h1, h1, h3, p is het soms ook mooier om voor de verticale margins em's te gebruiken: dan rekken de tussenruimtes wat mee als de bezoeker zijn/haar lettergrootte aanpast.

Voor horizontale margins of paddings bij text-elementen is het vaak onhandig om em's te gebruiken. Afhankelijk van de lettergrootte wordt dan bv. de linkermargin opgerekt (hoe groter de lettergrootte, hoe groter de margin). Maar omdat er bij grotere letters toch al minder op een regel kan, is zo'n grotere kantlijnmarge net niet wat gewenst is.
Zo ongeveer.
Dit geldt dan zo'n beetje voor een fixed-width opmaak.
Ga je liquidizen (met een liquid design voor aanpassing op de resolutie-breedte), dan kan het weer anders komen te liggen. Dan zijn vaak weer wel margins in relatieve maten (% van een breedte van een parent-element bv.) noodzakelijk. *)

Kortom, hier zijn geen vaste regels voor te geven.

Grappig is, dat vroeger de css-validator opmerkingen maakte als je in één style-regel em's en px klutste, bv. a {.1em 6px;}. Dan kwam de kritiek: "Dat is geen robuuste style!".
Maar de laatste jaren komt die opmerking niet meer: ook de css-validator heeft wat bijgeleerd. ;)

Met vriendelijke groet,
CSShunter
__________
*) Bv.:
Code: 
#header h1 span {
	...
	padding: 80px 0 35px 6.6em; 
	/* de padding-left in em's centreert de tekst,
	   terwijl de background-figuur links kan uitlijnen */ 
}
... is toegepast in de Elastico-style.
 
Ahh ...
dit doet zeer ...

het kwartje wil niet vallen waarom padding-left op 6.6 wordt gesteld.
Aan het experimenteren geweest, maar :cool:

En waarom rechts en links op 0, en text-align:center, niets doet, mag ook Joost weten

Code: 
#header h1 {
	height: 156px;
	margin-right: -5px;
	font-size: 2.4em;	
        background: url('elastico_images/elastico-right.gif') no-repeat 100% 0; 
}

#header h1 span {
	position: absolute;
	height: 156px;
	margin-left: -5px;
	
        padding: 80px 0 35px 6.6em;  
	/* de padding-left in em's centreert de tekst,
	   terwijl de background-figuur links kan uitlijnen */
	background: url('elastico_images/elastico-left.gif') no-repeat;
}

Dit lijkt toch wel op CSS voor gepromoveerden :thumb:
 
Au, dat doet zeker zeer! :)
Dacht ik er met een plastisch voorbeeld van af te zijn, ga je het napluizen! Moet ik ook in de spelonken van mijn duistere beweegredenen gaan duiken, want helemaal vanzelfsprekend is het nu ook weer niet. Dat komt er van! ;)

Afijn (na enige tijd), we hebben deze:
Code: 
#header {
   ...
   width: 48em; /* breedte verandert bij andere lettergrootte! */
   max-width: 95%;
} 
#header h1 {
   ...
   font-size: 2.4em;
}
Bij opschaling van de lettergrootte via de browser-instellingen blijft de verhouding tussen deze twee gehandhaafd, zolang niet de max-width wordt bereikt.
De #header-h1-span kan dan redelijk straffeloos een padding-left in ook em's krijgen om gecentreerd te worden/blijven.

Als ik me niet vergis, had ik voor het gemak de waarde van 6.6em proefondervindelijk vastgesteld: paar keer trial&error + nameten screenshotjes. :rolleyes:
  • Maar bij bereiken van de max-width (bij stevige opschaling, of bij kleine schermbreedte) loopt de padding-breedte gewoon door, en komt de tekst dus steeds meer rechts van het midden uit.
  • Ook bij downscaling (in Firefox) gaat het mis, want FF heeft een minimum kleinste letterformaat; daarvan is ook de h1 afhankelijk, en dan blijven de verhoudingen niet meer overeind (tekst te veel naar links). *)

=======
En waarom rechts en links op 0, en text-align:center, niets doet, mag ook Joost weten
Klik om te vergroten...
Joost weet in dit geval: er is geen breedte voor de h1-span opgegeven maar wel een absolute positie, dus de breedte = de tekstbreedte en er valt weinig te centreren.
  • De onhandigheid en de uitdaging van de pagina-opdracht was, dat er niets aan de html mocht gebeuren; vandaar dat een aantal dingen met een {position:absolute;} werden opgelost, wat altijd nadelen met zich mee brengt.

Intussen, "met de kennis van nu", zou ik het anders doen. :d
De absolute positie (voor het tonen van de achtergrondfiguur) kan vervallen als je een {display: inline-block;} voor de span instelt. Een breedte erbij, en dan kan wel de {text-align:center;} toegepast worden, en die 6.6em padding-left verdwijnen:
Code: 
#header h1 span {
    width: 100%;
    height: 80px;
    display: inline-block;
    margin-left: -5px;
    padding: 80px 0 0 0; /* verticale tekst-positie */
    text-align: center;
    background: url('elastico_images/elastico-left.gif') no-repeat;
    /* hier wordt de linkerhand over de elastiekje-achtergrondfiguur geplakt */
    color: #008000;
    white-space: nowrap;
}
En, aldus Firebug: dit werkt ideaal, ook bij extreme vergroting/verkleining, plus bij overtreding van de max-width, en ook bij weinig schermbreedte.
Niet gedurfd te testen in IE. ;)

Met vriendelijke groet,
CSShunter
_____________
*) Dwz de kleinste lettergrootte voor de <body> bepaalt de breedte van de h1. Die neemt dus op een gegeven moment niet meer af.
Tegelijkertijd is de font-size van de h1 2.4 keer zo groot, en nog niet op zijn minimum. Die zoomt dus kleiner, en de padding-left (die niets van minimum font-size afweet) zoomt ook kleiner = naar links t.o.v. de container!
 
Laatst bewerkt:
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan