html-kod fungerar lokalt men inte på servern

Nu är det rätt många år sedan jag pysslade med HTML. Men jag undrar vad det är för fel på:

<b>På gång!</b> <i>Ny bok!</i>

alternativt

<strong>På gång!</strong> <em>Ny bok!</em>

Span-taggarna behöver du väl knappast för det du är ute efter och de underlättar ju inte heller läsningen av koden.

Alltså, jag fattar att man kör span om man vill skapa id:n eller classer och styra dessa med en central stilmall. Typ <span class="uppmaning"> och sedan knyter den class:en till kursiv text. Men att skriva in CSS:en direkt i span-taggen verkar... inte optimalt.

Det har att göra med koduppdelning. HTML för innehåll, CSS för design och layout (och javascript för beteende). Det underlättar utvecklingen när man slipper meka i både html- och css-filen när man bara ska ändra utseendet. Om man är flera utvecklare, t.ex. en som gör innehållet och en designer, blir det ännu viktigare att dela upp det.

Dessutom blir det mycket lättare att ändra layouten om man använder CSS istället för stiltaggar. Tänk dig att du har 50 fetstilta ord på en sida med <b>-taggen. Om du kommer på att det inte blev bra, eller om du vill testa nåt annat, så måste du ändra på 50 ställen för att ta bort fetstilen. Om du gör det med CSS behöver du bara ändra på ett ställe.

Det verkar som att även W3C gillar att man använder de riktiga taggarna i första hand:

Källa: 4.5 Grouping content — HTML5

Nu handlar citaten ovan visserligen om div, men om jag har förstått saken rätt fungerar span på ungefär samma sätt, men på textnivån.

Ja, om det är en betoning (<em>, emphasis) eller förstärkning (<strong>) man är ute efter så ska man generellt använda de taggarna, då t ex skärmläsare då läser texten med önskat tonfall. Är man däremot bara ute efter fet (<b>) och kursiv (<I>) stil så kan man välja fritt mellan de kortare taggarna och <span> med CSS, eller vad man nu känner för.

Mao, <em>/<strong> = betydelse & textstil, <b>/<i> = enbart textstil.

Absolut. Men om du kallar din CSS-klass för "bold" och den sedan inte innebär att texten är fet är det så vetetusan om det är rätt gjort, även om det fungerar.
Är det inte då bättre att försöka vara hyggligt semantisk när man skriver sin HTML? Exempelvis att antingen använda <em> eller kanske en <span class="uppmaning"> och förändra em:n eller klassen uppmaning i stilmallen efter vad som såg bäst ut. Kanske är det ändå bättre att använda <em class="uppmaning">?

Instämmer helt och hållet med jahve.
Css-klasser som heter såsom det är tänkt att texten skall se ut håller inte. Lika lite skall man ersätta existerande html-taggar med klasser som syftar till att göra samma sak. (tex <div class="title"> isf <h1>). Att göra som jac är att gå över ån efter vatten.
Men det har varit en ganska utbred vanföreställning när trenden inom webblayout gick över från table-baserat till css-styrd och den sk divitis spred ut sig över nätet.

Du kallar en klass för bold för att ha möjlighet att inte göra texten fetstilad i framtiden. Det innebär att du eftersöker möjligheten att senare ändra klassens egenskaper till något tvärtemot vad den heter, vilket jag menar är lite tokigt. Vad vinner du på möjligheten att göra klassen bold icke-fet, förutom förvirring?

Jag menar att man i första hand ska använda semantiska taggar, typ <h1>, <em>, <strong> som visar vad texten är för något. Göra HTML-koden meningsfull helt enkelt. Om det skulle vara så att du faktiskt behöver en <em class="uppmaning">, <strong class="uppmaning">, kanske t o m <span class="uppmaning"> - så kalla din klass för vad det är istället för hur den ska se ut. Varför då? Jo, för att skilja form från innehåll - det du säger att du vill uppnå.

Då kan du ju vid ett senare tillfälle bestämma att alla uppmaningar på din hemsida ska vara stora röda feta versaler. Men ett namn som bold säger ju ingenting om stora röda versaler. Och ännu värre blir det när du ändrar så att de bara ska vara röda och stora. Klassen bold betyder då allt annat än fet teckenstil.

Se Web development mistakes | 456 Berea Street, särskilt punkterna <span> mania och Lack of semantics.