Just nu i M3-nätverket
Gå till innehåll

Hierarkiska relationer mellan element i trädstruktur (förälder, barn, syskon, ättling)


jbo

Rekommendera Poster

Jag önskar reda ut den exakta inbördes hierarkiska trädstrukturen (ancestor, child, sibling, decendant, etc.) mellan de olika element som förekommer i HTML.

 

Det finns en fingervisning på W3Schools men här saknas ju mycket i mitt tycke (var skulle t.ex. en div hamna i hierarkin?).

Här skulle man vilja ha en mer utförlig redogörelse.

En som förklarar hur vart element förhåller sig till andra, från html, via body och ner till små element som span eller abbr - alternativt en logisk regel med vilken man själv kan räkna ut vad som gäller för vart element man stoppar in i ett HTML-dokument. Vissa element är ju föräldrar till flera barn, vad styr detta (och vad är det som styr att en h1 inte är förälder till en p t.ex.)? - Och liknande frågor.

 

Jag har trots en hel del sökande inte lyckats hitta något på W3C så jag är tacksam för alla bra länkar eller annan info som kan klargöra detta.

Länk till kommentar
Dela på andra webbplatser

Sibling = syskon. Element som ligger på samma nivå som refererande element.

Parent, elementets närmaste förälder (säger sig självt)

 

Allt är relativt. ett element som är child till ett element kan också vara parent till undernod.

Antcestor är släkting, typ parent längre ner på skalan (förförälder skulle man kunna uttrycka sig).

 

<body>
<div class="parent">
 <div class="parent child">
   <div class="child2"></div>
 </div>
 <div class="child"></div>
 <div class="child"></div>
 <div class="child"></div>
</div>
</body>

 

Enligt w3c-standard för html får inte block-element som rubriker H1-6 och p innehålla blockelement, utan endast inline-element som span, abbr, a, strong, em m fl.

 

DIV är containers som kan innehålla andra divvar och blockelement.

 

 

här är liten text innhållandes information om detta: http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/abstract_modules.html#s%5Ftextmodule

Länk till kommentar
Dela på andra webbplatser

Anjuna Moon

Vad elementen heter (div, h3, span, osv.) är helt ointressant, html är inget annat än XML. Så som svar på frågan så kan man ta det på teoretisk xml-nivå (och detta gäller rakt över alla xml-baserade dokument.

 

Det de olika selektorerna syftar på är ganska självbeskrivande (om man kan engelska).

 

En "parent" är ett, och endast ett, steg ovanför dig. (din förälder)

En "ancestor" är alla trädnoder, ovanför dig - inklusive "parent". (dina föräldrar och alla stamfädrer/stammödrar)

 

Nedåt resonerar du på samma sätt:

En "child" är ett, och endast ett, steg under dig (ditt barn)

En "descendant" är ett och alla andra steg under dig (ditt barn och alla ättlingar därunder)

 

"Sibling" är alla som ligger på samma nivå (syskon)

Länk till kommentar
Dela på andra webbplatser

Sibling = syskon. Element som ligger på samma nivå som refererande element.

Parent, elementets närmaste förälder (säger sig självt)

 

Allt är relativt. ett element som är child till ett element kan också vara parent till undernod.

Antcestor är släkting, typ parent längre ner på skalan (förförälder skulle man kunna uttrycka sig).

 

 

Vad elementen heter (div, h3, span, osv.) är helt ointressant, html är inget annat än XML. Så som svar på frågan så kan man ta det på teoretisk xml-nivå (och detta gäller rakt över alla xml-baserade dokument.

 

Det de olika selektorerna syftar på är ganska självbeskrivande (om man kan engelska).

 

En "parent" är ett, och endast ett, steg ovanför dig. (din förälder)

En "ancestor" är alla trädnoder, ovanför dig - inklusive "parent". (dina föräldrar och alla stamfädrer/stammödrar)

 

Nedåt resonerar du på samma sätt:

En "child" är ett, och endast ett, steg under dig (ditt barn)

En "descendant" är ett och alla andra steg under dig (ditt barn och alla ättlingar därunder)

 

"Sibling" är alla som ligger på samma nivå (syskon)

 

Tack för svar Jonas_B och Anjuna Moon!

 

Jag kanske inte var tydlig nog med frågan.

Jag är införstådd med betydelserna/definitionerna gällande arvs-/familjenamnen (förälder, barn, syskon etc.). De finns väldigt bra redovisade på W3C - 3 Conformance:

Requirements and Recommendations där även en bra schematisk skiss för arvshierarkin finns demonstrerad.

Man länkar även till W3C - 6 Assigning property values, Cascading, and Inheritance som ger en del ytterligare information.

 

Det jag vill förstå bättre, och som jag inte är helt säker på om jag lyckats lista ut än, är vad som, i vissa avvikande fall, gör t.ex. en förälder till just en förälder i dessa sammanhang. Framförallt om det finns någon stans där det står beskrivet exakt hur logiken är tänkt att fungera.

Syftet med frågan är främst för att förstå, och kunna använda, float på ett förutsägbart och kontrollerat sätt i HTML/CSS (jag har inte hållit på så länge än) och det har jag alltså inte lyckats lista ut ännu via länkarna ovan eller på andra ställen.

 

I ditt exempel ovan är det ju inga större frågetecken i arvsförhållandena.

I exemplet nedan har jag utökat ditt exempel med en div och ett par andra element för att göra min fråga lite mer tydlig:

 

<html>
<body>
<head>
<title>En Titel</title>
</head>
 <div class="parent1">
  <div class="parent child">
    <div class="child2"></div>
     <p id="1"></p>
     <p id="2"></p>
     <img scr="url" alt="en bild" />
     <p class="3">
       <img scr="url" alt="en till bild" />
     </p>
  </div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
 </div>
 <div class="parent2">
 </div>
</body>
</html>

 

Att body är barn till noden html (som är den enda nod som inte har någon förälder) vet vi.

Och att i exemplet ovan både "parent1" och "parent2" blir barn till body" vet vi också.

 

Att head är barn till html är också något vi vet - men vad är det som gör att body är förälder till "parent1" och "parent2" i stället för att head skulle vara den föräldern, är något jag funderat lite över, (än så länge är det något jag alltså bara lärt mig "att så är det", vilket ju också är logiskt eftersom body är har de egenskaper som just body har, men det skulle vara intressant att veta om det finns någon regel eller logik som beskriver sådant - d.v.s. om det finns andra sammanhang där ett liknande förhållande upprepas längre ned i trädstrukturen - eller om head är det enda undantaget i en övrigt rätt självklar hierarki, [enl. vad jag antar nedan]).

 

Vad som, så vitt jag har testat mig fram - och i enlighet med vad Anjuna Moon visar och Jonas_B säger om att "allt är relativt" - verkar logiskt är ju också hur släktskapet hänger samman med hur man själv lagt upp strukturen för koden:

Det som är inneslutet i ett element bli barn till just det omslutande elementet och de element som läggs "under" eller "bredvid" blir syskon, o.s.v. (i exemplet ovan: img "en bild" är syskon med de omkringvarande paragraferna "1","2" och "3" samt barn till div "child2"; medan img "en till bild" är syskonlöst barn till paragraf "3").

Det är ju vad man kan sluta sig till även genom att testa. Men det vore intressant att se även det beskrivet någonstans på W3C - om det är någon som har en länk till en sådan beskrivning (men det kanske är det Anjuna Moon refererar till med hänvisning till XML?).

 

Och kanske finns annat som jag missat i det som berör dessa arvsrelationer som det kan vara bra att känna till?

Allt som ytterligare kan klargöra dessa förhållanden är av intresse.

Länk till kommentar
Dela på andra webbplatser

Det enda jag kommer på just nu är reglerna för blockelement, att ett blockelement inte får finnas under ett annat, annars finns det inte några speciella regler.

 

Och vad gäller layout spelar egentligen ingen roll, man kan- med css- få det att se ut hur som helst med att ändra i css-reglerna.

 

Sedan skriver du att paragraferna är barn till child2, vilket inte stämmer i din modell, men det är kanske ett "stavfel".

Länk till kommentar
Dela på andra webbplatser

Anjuna Moon
men vad är det som gör att body är förälder till "parent1" och "parent2" i stället för att head skulle vara den föräldern

Till att börja med har du placerat HEAD fel, denna tag är ett syskon till BODY och inte ett barn som du har skrivit koden.

 

Men i övrigt beror det på att det inom varje start- och slut-tag existerar en egen hierarki. Eftersom "parent1" och "parent2" inte ligger inom denna hierarki så är HEAD inte förfader eller förälder till någon av dessa två taggar. Däremot ligger dessa två innanför BODY:ns start och slut-tag och har därför BODY som förälder.

 

När det handlar om FLOAT-beteende så har detta bara delvis med XML-hierarkin att göra, utöver detta handlar det om utökade layout-egenskaper som CSS definierar.

Länk till kommentar
Dela på andra webbplatser

Sedan skriver du att paragraferna är barn till child2, vilket inte stämmer i din modell, men det är kanske ett "stavfel".

 

Tack för påpekandet Jonas!

Det var dock inget "stavfel". Jag tror på allvar att det är så att paragraferna 1-3 är barn till child2. Om de inte är så har jag verkligen missförstått hela idén :unsure: . Vilket element menar du är förälder till dessa paragrafer?

 

Jag hade en fråga till, men den spar jag till senare och blir glad om du kan reda ut detta först :rolleyes: !

Länk till kommentar
Dela på andra webbplatser

Till att börja med har du placerat HEAD fel, denna tag är ett syskon till BODY och inte ett barn som du har skrivit koden.

 

Du har alldeles rätt. Jag missade helt där :blush:

Med "huvudet" på rätt ställe blir det mer ordning på det mesta, även logiken i HTML...

 

Men i övrigt beror det på att det inom varje start- och slut-tag existerar en egen hierarki. Eftersom "parent1" och "parent2" inte ligger inom denna hierarki så är HEAD inte förfader eller förälder till någon av dessa två taggar. Däremot ligger dessa två innanför BODY:ns start och slut-tag och har därför BODY som förälder.

 

Så då är jag inte helt ute och cyklar med mitt resonemang om arvsordning, om jag förstått dig rätt?

 

När det handlar om FLOAT-beteende så har detta bara delvis med XML-hierarkin att göra, utöver detta handlar det om utökade layout-egenskaper som CSS definierar.

 

Jag misstänkte det (märkte det när jag testade lite olika varianter av CSS-kod och fick rätt olika resultat än vad jag utifrån vad jag hade förväntat mig med, än så länge, ringa CSS-kunskaper).

Kanske du har några bra tips om var jag enklast reder ut dessa begrepp?

Länk till kommentar
Dela på andra webbplatser

Anjuna Moon
Kanske du har några bra tips om var jag enklast reder ut dessa begrepp?

Jag kan inte säga att jag har något bra lästips, jag har lärt mig det jag kan från så många olika håll och via klassisk "trial-and-error".

 

Några tips på vägen för att förstå helheten är följande:

- I ren HTML, utan någon form av CSS- eller HTML-layout inblandning så kommer elementen placeras i samma ordning som de gör när du läser html-sidan uppifrån och ner, dvs. ett element per rad i ett textdokument typ.

- Förstå skillnaden mellan in-line och block-element i HTML. Här kommer lite grundläggande HTML-layoutdetaljer in som påverkar om två element hamnar på samma rad eller med en radbrytning emellan (väldigt förenklat uttryckt förstås, det finns annat också som skiljer dessa två grundtyper)

- Vissa element i HTML har ingen layout-påverkan utan fungerar som informationsbehållare (HEAD, SCRIPT, STYLE osv.)

- Vissa element har implicit satta stilar, dvs. layout-beteenden vars utseende bestäms av webbläsaren (H1,H2,H3...I, B, osv.). Dessa typer av element vill man komma ifrån med utvecklingen av CSS, då element i HTML ultimat bara skall beskriva information och inte utseende/layout.

- Layout och visuella stilar i övrigt styrs av stilmallar. Det är här man visuellt manipulerar alla element på det sätt som XML-modellen inte kan göra.

 

Vet inte om detta hjälpte lite eller bara lät för självklart. Men jag är trött och kan beskriva bättre imorgon.

Länk till kommentar
Dela på andra webbplatser

Tack för påpekandet Jonas!

Det var dock inget "stavfel". Jag tror på allvar att det är så att paragraferna 1-3 är barn till child2. Om de inte är så har jag verkligen missförstått hela idén :unsure: . Vilket element menar du är förälder till dessa paragrafer?

 

Jag hade en fråga till, men den spar jag till senare och blir glad om du kan reda ut detta först :rolleyes: !

 

Eftersom du stänger child2 direkt är paragraferna syskon till child2. Paragraferna är barn till "parent".

Länk till kommentar
Dela på andra webbplatser

Eftersom du stänger child2 direkt är paragraferna syskon till child2. Paragraferna är barn till "parent".

 

Du har alldeles rätt i att child2 var stängd. Missade det när jag flyttade runt i din ursprungliga kod. Billig miss :blush: Om det kan vara till något försvar kan jag säga att jag var rejält laggad när jag skrev det där i går kväll.

Men, eftersom child2 tillsammans med paragraferna 1 - 3 ligger inom "parent child", så antar jag att du menar att "parent child" (och inte "parent" ["parent1"?]) är förälder till dessa?

 

För de eventuella läsare som vill få ut något vettigt i all den oreda som min slarviga kod orsakat ställer jag upp koden ovan igen, något rättad och med lite tydligare struktur för att förtydliga de inbördes relationerna.

 

<html>
 <head>
 <title>En Titel</title>
 </head>
 <body>
   <div id="parent1">
     <div id="parent child">
       <div id="child2">
       </div> <!-- end "child2" -->
       <p id="1"></p>
       <p id="2"></p>
       <img scr="url" alt="en bild" />
       <p id="3">
         <img scr="url" alt="en till bild" />
       </p>
     </div> <!-- end "parent child" -->
     <div id="child3"></div>
     <div id="child4"></div>
     <div id="child5"></div>
   </div> <!-- end "parent1" -->
   <div id="parent2">
   </div> <!-- end "parent2" -->
 </body>
</html>

 

Om jag inte missat något så skall det i exmplet ovan vara följande som gäller:

"parent1" och "parent2" är syskon, samt barn till "body".

"parent1" är förälder till "parent child", "child3", "child4" och "child5" som alla är syskon och alltså även barn till "parent1".

"child2", paragraferna 1-3 samt img "en bild" är samtliga syskon, samt barn till "parent child".

img "en bild till" är ensamt barn till paragrafen 3.

 

 

Och i exemplet nedan följer hur jag ursprungligen tänkt mig att det skulle ha sett ut:

 

<html>
 <head>
 <title>En Titel</title>
 </head>
 <body>
   <div id="parent1">
     <div id="parent child">
       <div id="child2">
         <p id="1"></p>
         <p id="2"></p>
         <img scr="url" alt="en bild" />
         <p id="3">
           <img scr="url" alt="en till bild" />
         </p>
       </div> <!-- end "child2" -->
     </div> <!-- end "parent child" -->
     <div id="child3"></div>
     <div id="child4"></div>
     <div id="child5"></div>
   </div> <!-- end "parent1" -->
   <div id="parent2">
   </div> <!-- end "parent2" -->
 </body>
</html>

 

Här blir paragraferna 1-3 och img "en bild" alla syskon, samt barn till "chid2" som det var tänkt från början.

Länk till kommentar
Dela på andra webbplatser

Vet inte om detta hjälpte lite eller bara lät för självklart. Men jag är trött och kan beskriva bättre imorgon.

 

Jovisst var det en hjälp :thumbsup: .

Jag har visserligen läst en del HTML och CSS, även kodat och lagt upp någon hemsida, men jag kom in på det utan några som helst förkunskaper eller tidigare erfarenheter från datorvärlden. Så man kan säga att det blivit lite slumpvis och kanske inte en så genomtänkt och strukturerad kunskapsinlärning. Det är därför jag nu försöker få lite ordning och reda på det hela.

Ett exempel på något jag missat betydelsen av är det där med att skilja mellan in-line- och blockelement. Jag vet att jag kommit över dessa begrepp när jag läst, men som sagt inte insett den verkliga vikten och betydelsen av dem. Det, och antagligen en hel del annat, får jag kolla upp lite mer noggrant. XML är jag t.ex. inte alls insatt i (hade hoppats på att jag inte skulle behöva sätta mig in i det heller om mitt syfte huvudsakligen är att kunna designa och utföra så bra och enkel kod som möjligt för webbsidor).

 

Självklart är jag tacksam för alla tips och råd som jag kan få!

Länk till kommentar
Dela på andra webbplatser

betydelsen för block och inlineelement är inte viktig för strukturen i sig, utan valideringen, baserad på det som Anjuna förklarat tidigare - att vissa element är inställda att renderas på ett visst sätt.

 

Sådan "anal" ordning du försöker dig på känns inte så viktig imo, det kommer att falla sig naturligt.

Läs lite om html5 vettja. Där kommer lite förändringar som förenklar en del, bl a introduceras elementen header, footer, nav, section, article och aside vilket i stort sätt bara är divvar med ett vissa syfte - vilket framgår av namnen.

Länk till kommentar
Dela på andra webbplatser

betydelsen för block och inlineelement är inte viktig för strukturen i sig, utan valideringen, baserad på det som Anjuna förklarat tidigare - att vissa element är inställda att renderas på ett visst sätt.

Jag är inte säker på att jag förstår den exakta användningen av termen "rendera" här.

Jag har dock, i det lilla jag läst om just detta, sätt tydliga exempel på att det kan se rätt galet ut om man använder in-line- och blockelement på felaktigt vis. Det är kanske det du menar med "rendera"?

 

Sådan "anal" ordning du försöker dig på känns inte så viktig imo, det kommer att falla sig naturligt.

Vet inte riktigt vad du menar med "anal" ordning, men antar att syftar till någon slags väldigt strikt och hårt hållen ordning, vilket väl imo inte kan vara någon större nackdel om man just håller sig till de grundläggande regler som det är tänkt koden skall bygga på. Grunden till mina frågor har just med det att göra - en önskan att skapa en så enkel och funktionell kod som möjligt - från steg ett och vidare. Det finns så många exempel på sidor där man börjar utan bra förankring i grunderna och sedan får rädda det med en massa "nödlösningar" vartefter arbetet fortskrider.

I och med tillämpningen av Responsive Webb Design känns det som om betydelsen av detta har blivit än mer viktig.

 

Läs lite om html5 vettja. Där kommer lite förändringar som förenklar en del, bl a introduceras elementen header, footer, nav, section, article och aside vilket i stort sätt bara är divvar med ett vissa syfte - vilket framgår av namnen.

Absolut. Har dock bara ägnat det en flyktigt blick hittills. Vet du hur det är med stödet för HTML5 i olika webbläsare, d.v.s. om man måste kompensera med alternativa lösningar för de browsers som inte har stöd för HTML5, och hur mycket extra arbete det i så fall medför?

Länk till kommentar
Dela på andra webbplatser

leta reda på en sida som skriver ut alla element så märker du att de ter sig lite annorlunda ibland.

rubrikerna har olika storlekar och marginaler och andra element har andra stilar.

 

Bra att kunna grunderna som du skriver men ser inte kopplingen till Responsive du gör.

 

Nyare browser stödjer delar (och gärna olika) av html5. Finns massor av information på nätet om detta.

Länk till kommentar
Dela på andra webbplatser

leta reda på en sida som skriver ut alla element så märker du att de ter sig lite annorlunda ibland.

rubrikerna har olika storlekar och marginaler och andra element har andra stilar.

 

Nyare browser stödjer delar (och gärna olika) av html5. Finns massor av information på nätet om detta.

Jodå, det är ganska precis så jag, likt de flesta andra, brukar göra, tittar på andras kod och söker information på nätet, vilket gav upphov till min ursprungliga fråga - eftersom det (som jag tidigare i #12, nämnde) av detta tillvägagångssätt gärna blir: "slumpvis och kanske inte en så genomtänkt och strukturerad kunskapsinlärning".

 

I det sammanhanget, när man surfat runt och bekantat sig med vad det nu är man vill lära sig, är det bra att kunna hitta de mer specifika regler och grunder som stadfäster det samma. D.v.s. på samma sätt som att du kan lära dig franska enbart genom att åka till Frankrike och umgås med fransoser i ett par år ger dig en hyfsad vardagsfranska, men stora luckor i förståelsen av varför och på vilka grunder språket bygger, sådant du behöver för att komma längre i din språkliga utveckling.

 

Så även om jag fått en hel del bra tips :thumbsup: och lärt mig en del nytt (inte minst genom mina felaktiga exempel) kvarstår min fråga (den om regelbeskrivningen på W3C el. likn.) i det hänseendet i viss mån ännu.

Länk till kommentar
Dela på andra webbplatser

Arkiverat

Det här ämnet är nu arkiverat och är stängt för ytterligare svar.

×
×
  • Skapa nytt...