Forumet - Olika doctypes HTML

Olika doctypes HTML

165 0 16
Är lite förvirrad över alla dessa doctypes som man kan ange. Om nu det är meningen att man ska skriva korrekt HTML eller XHTML, varför finns Transitional och Frameset doctypsen överhuvudtaget?
Finns det någon anledning till att de inte bara har XHTML Strict så alla uppmanas att formatera koden rätt och undvika utdaterade element.
sylar:

Finns det någon anledning till att de inte bara har XHTML Strict så alla uppmanas att formatera koden rätt och undvika utdaterade element.


Därför att då skulle äldre hemsidor renderas inkorrekt i moderna webbläsare. Eftersom många företag förlitar sig på att deras gamla webapp från 2001 ska fungera så kan man inte bara ge dem fingret och säga åt dem att göra om och göra rätt.

Sedan utvecklas ju HTML specifikationerna, som allt annat, så om 5-10 år lär du troligen klaga över alla jävlar som inte använder vad det nu är som gäller då.
Åtta:

Därför att då skulle äldre hemsidor renderas inkorrekt i moderna webbläsare. Eftersom många företag förlitar sig på att deras gamla webapp från 2001 ska fungera så kan man inte bara ge dem fingret och säga åt dem att göra om och göra rätt.


Haha jo det är ju sant förstås. Det besvarade väl min fråga antar jag.
Om en sisådär 7-10 år är *förhoppningsvis* HTML5 standard.

Då jävlar! Då kortas doctypen ner till: <!DOCTYPE html /> och inget annat!

HTML5 och CSS3 är ju kärlek som fan. [love]

Edit: Nuförtiden är det dock smart att använda antingen XHTML 1.0 Strict eller HTML 4.01 Strict som sin doctype. Bara för att veta att man inte kodat dumheter. :)

Spana också in:

Sterd:

Fast de har fortfarande inte fattat att CSS måste delas upp i två delar och att boxmodellen måste tänkas om nåt in i helvete.


Well, personligen uppskattar jag boxmodellen som den är nu ... men, jag är verkligen inte insatt i ämnet nog för att kunna avgöra vad som objektivt är bra respektive dåligt.

Vad är det som borde delas upp inom CSS, för övrigt?
Åtta:

Ptja, jag är inte någon speciellt brinnande aktivist för detta, men det känns ju som ett vettigt steg att dela upp sådant som har med var element ska vara och hur elementen ska se ut. Det är ju trots allt två olika saker.


Det känns dock ganska otympligt att tvingas använda två textdokument för styling. Lämpligare, imho, vore att framtvinga CSS-struktur, i så fall. T.ex. att all "styling" måste ligga efter positionsrenderingen eller dylikt.

Och vad är padding, egentligen? Är det position, eller styling? Man kan argumentera för båda delarna.
Lambda89:

Det känns dock ganska otympligt att tvingas använda två textdokument för styling.


Det håller jag med om. Ingen har sagt att du måste ha två olika dokument eller något, bara att det bör upprättas någon typ av separering mellan stylningen och positionsangivelserna.

Lambda89:

Och vad är padding, egentligen? Är det position, eller styling? Man kan argumentera för båda delarna.


Jupp. Därför kan det ju vara vist att helt enkelt välja en utav dem.
Lambda89:

Well, personligen uppskattar jag boxmodellen som den är nu ...


Det gör inte jag. Den är hemsk. Det ska inte behövas konstiga haxx för att få multikolumnlayout med samma höjd, det borde vara världens enklaste grej. CSS3 har inte löst problemet, bara byggt in haxxet.

Boxmodellen borde kastas ut och göras om som något slags constraint-baserat system istället, där man anger hur (kanske t.o.m arbiträrt formade) "boxar" förhåller sig till varandra - inte hur de ska tvingas ur ett vertikalt default-flow som det är nu.
Sterd:

Det ska inte behövas konstiga haxx för att få multikolumnlayout med samma höjd, det borde vara världens enklaste grej


Haller med! Det dar problemet stoter man ju pa hela tiden,
och att fa det att funka i olika weblasare samtidigt... Usch!

Sterd:

constraint-baserat system istället, där man anger hur (kanske t.o.m arbiträrt formade) "boxar" förhåller sig till varandra - inte hur de ska tvingas ur ett vertikalt default-flow som det är nu.


Det okar nog komplexiteten ratt mycket. Gor du det for rikt,
kan du kanske till och med ge boxar med siffror i constraints sa att de loser ett sudoku-problem, nagot som ar NP-hard.

Och hur hittar man formuleringar som inte blir den komplexiteten?

Jamfort med DET ar flashmissbruk ingenting, skulle jag tro.
Gifted:

Det okar nog komplexiteten ratt mycket


Det har jag svårt att se. Oavsett är det värt det.

"Den här boxen ska vara här och dess höjd ska anpassa sig efter innehållet.
De här boxarna ska ligga i den första, och deras underkanter ska följa med parent-boxens underkant."

Där har du multikolumnlayout i två meningar. Knappast svårare i ett markupspråk.
Sterd:

"Den här boxen ska vara här och dess höjd ska anpassa sig efter innehållet.
De här boxarna ska ligga i den första, och deras underkanter ska följa med parent-boxens underkant."


Jovisst, men du skulle kunna konstruera A beror pa B, beror pa C, ...
och fa ett otroligt komplex beroende. Sadana system kan losa sudoku,
(har for mig att bade "make" och "apt-get" stalls infor denna typen av problem, och man har fatt NP-hard komplexitet)