Idag på jobbet skulle vi växla mellan två utseenden på ett HTML-dokument i en webbläsarkontroll i en .Net-applikation. Tanken var att ändra attributet class på bodyelementet. Att köra browser.Document.Body.setAttribute("class", "...") gick inte. Inte heller browser.Document.Body.className = "..." funkade. Dessa två sätt är standardiserade. Men Microsoft har förstås valt att blanda ihop dessa: browser.Document.Body.setAttribute("className", "...").

Varför? Hur sjutton har man tänkt?

<b>Hur sjutton har man tänkt?</b>
Meningen är att Window-elementet är själva browserfönstret. Document-elementet är en HTML-sida i en container som kan vara antingen ett browserfönster eller ett frameset. Mot bakgrund av det vore det fel att försöka modifiera en BODY-tagg som tillhör Window-elementet.

<b>Edit:</b>
Måste bara fråga, ska inte din fråga vara i Javascript-forumet?

<b>Måste bara fråga, ska inte din fråga vara i Javascript-forumet?</b>

Absolut inte. Applikationen är skriven i C# och har webbläsarkontroller (http://msdn2.microsoft.com/en-us/library/system.windows.forms.webbrowser.aspx) ordnade i en "lista". När man klickar på en post i listan (dvs på en webbläsarkontroll), skall posten markeras. Vi har löst det genom att utnyttja stilmallar och ändra stilmallsklassen på bodyelementet.



<b>Meningen är att Window-elementet är själva browserfönstret. Document-elementet är en HTML-sida i en container som kan vara antingen ett browserfönster eller ett frameset. Mot bakgrund av det vore det fel att försöka modifiera en BODY-tagg som tillhör Window-elementet.</b>

Förstår inte hur du menar att det skulle vara fel att modifiera bodyelementet i ett dokument där man vet att ett bodyelement finns.

du sätter stilmall på din sida med Page.StyleSheetTheme

du behöver altså inte trixa med nått javascript om du har en postback.
ska du byta css class på body tagen så får du sätta den som runat="server"

när man byter stilmall kan det dock bli problem med att den är cachad på clienten.

Andreas har rätt. Exempelvis kan du sätta runat=server på din HEAD-tag för att komma åt den via Header-egenskapen i Page-klassen. Du kan modifiera vilken HTML-tag som helst innan renderingen sker till webbläsaren.

Anledningen till att jag frågade om Javascript var att den syntax du skrev ut var Javascript-kod...

<b>du behöver altså inte trixa med nått javascript om du har en postback.</b>

Men vi har INTE använt JavaScript alls.



<b>ska du byta css class på body tagen så får du sätta den som runat="server"</b>

Gäller inte runat="server" bara webbapplikationer? Detta är en fristående applikation. Webbsidan är INTE skriven i C# utan i PHP.

"Gäller inte runat="server" bara webbapplikationer? Detta är en fristående applikation. Webbsidan är INTE skriven i C# utan i PHP."

vad gör du då i C# tråden ?

Den fristående applikationen är skriven i C#.

Nu har du tappat bort mig totalt... Vad är det du försöker göra? Redigera en textfil?

Vi har ett program skrivet i C#. Detta är <b>inte</b> en webbapplikation, utan en fristående .Net-applikation.

I detta program finns ett antal webbläsarkontroller som hämtar sidor från webben för att presentera information om olika produkter. Dessa sidor genereras av PHP, men det har ingen egentlig betydelse för uppgiften. Programmet ser ju ändå bara den genererade HTML-koden.

När man klickar på informationen för en viss produkt, alltså på tillhörande webbläsarkontroll, skall bakgrunden för produktinfon bli mörk och texten ljus, så att den ser markerad ut. Detta sköter vi genom att från programmet ändra attributet class på bodyelementet i webbsidan.

Det hela fungerar bra och vi har egentligen inget problem.

Som vanligt har dock Microsoft hittat på något konstigt. För att ändra värdet på attributet class i elementet e, borde man kunna skriva e.SetAttribute('class', '...'). Men si, det går inte. I stället skall man namnge attributet som 'className', alltså skriva e.SetAttribute('className', '...').

Min fråga är därför varför Microsoft ännu en gång har kringgått standarderna.

<b>Det hela fungerar bra och vi har egentligen inget problem.</b>

Så vad <b>är</b> problemet då? :) Jag var inte medveten om att det fanns någon ratifierad standard för hur embedded web controls ska fungera i WinForms...

<b>Jag var inte medveten om att det fanns någon ratifierad standard för hur embedded web controls ska fungera i WinForms...</b>

Inte för hur webbkontrollerna skall fungera, däremot för hur man kommer åt och ändrar i elementen. Har du inte hört talas om DOM?


<b>Så vad <b>är</b> problemet då? :)</b>

Att Microsoft inte följer standard.

Sluta gnäll, lös problemet! =)

För övrigt har inte DOM att göra med vilken syntax <b>Microsoft</b> använder för <b>Microsoft</b>-kontroller. Jag tror du blandar ihop saker lite grann...

<b>Sluta gnäll, lös problemet! =)</b>

Och hur påverkar jag Microsoft?


<b>För övrigt har inte DOM att göra med vilken syntax Microsoft använder för Microsoft-kontroller.</b>

Varför inte? De följer ju nästan DOM, men på just denna punkt har de hittat på något annat. Hur förväntar du dig att ett attribut med namnet xyz skall ändras? Genom SetAttribute("uvw", "...")? Varför skall man ange ett annat namn än attributet har?

Men i Javascript använder man en egenskap vid namn "className" för att sätta attributet "class" på ett objekt i DOM-trädet.

Så viss logik finns det väl? Du pratar ju trots allt om att modifiera DOM-objekt på klientsidan...

Eller så ogillar du Javascript-notationen också? ;)

Visst, jag ser kopplingen till den egenskapen. Men i det fallet skriver man e.className = '...'. Det är alltså en egenskap direkt på elementet. Attributet heter däremot fortfarande class.

De två varanter som hade varit korrekta är alltså
1) e.className = "..."; // Jag hade accepterat e.ClassName för att följa Microsofts CamelCase.
2) e.setAttribute("class", "..."); // Och här accepterar jag e.SetAttribute()

Varianten e.SetAttribute("className", "...") är dock ologisk.

Ni var inne på att vi använde fel metod för att lösa problemet. Var det någon av er som hade ett bättre förslag?

(Och tycker ni fortfarande att tråden ligger i fel forumdel?)

Ingen som har ett bättre förslag? Och är det någon som fortfarande tycker att tråden ligger i fel forumdel?