target i xhtml

Hur löser man target när man ska koda i xhtml? eller går det inte?

Re: target i xhtml

voigtann1 skrev:

Hur löser man target när man ska koda i xhtml? eller går det inte?

Svaret hittar du ifall du söker.
http://www.webforum.nu/search.php?s=&action=showresults&searchid=833286&sortby=lastpost&sortorder=descending

jarvklo skrev:

Kör du xhtml 1.0 Transitional så skall det funka med target="_blank".
Kör du xhtml 1.0 Strict eller xhtml 1.1. så får du använda eventet onclick och lägga in ett JavaScript som öppnar ett nytt fönster...
Exempel på hur man kan göra finns t.ex. här

Jag tycker såhär: Om man ska koda XHTML Strict bör man respektera de principer som gäller. Dvs. det är besökaren själv som ska få bestämma om denne vill öppna sidan i nytt fönster eller ej.

Troxy skrev:

Jag tycker såhär: Om man ska koda XHTML Strict bör man respektera de principer som gäller. Dvs. det är besökaren själv som ska få bestämma om denne vill öppna sidan i nytt fönster eller ej.

Håller med, även om jag inte gör det på min egna sida. Men man kanske borde sluta med det... Javascript hit och dit, bara onödigt. :D

Dessutom invaliderar ett sådant JavaScript xhtml-koden, dvs om man går in mha js och ändrar länkarnas target-attribut. Det är ju lika rätt som att skapa ett tomt xhtml-dokument och sedan fylla ut det mha js och slänga in felaktigt avslutade font-taggar osv. Window.open-lösningen är bättre i så fall men samtidigt är, eller borde det vara, upp till besökaren att öppna länkar i nya fönster eller ej.

dAEk^ skrev:

Dessutom invaliderar ett sådant JavaScript xhtml-koden, dvs om man går in mha js och ändrar länkarnas target-attribut. Det är ju lika rätt som att skapa ett tomt xhtml-dokument och sedan fylla ut det mha js och slänga in felaktigt avslutade font-taggar osv. Window.open-lösningen är bättre i så fall men samtidigt är, eller borde det vara, upp till besökaren att öppna länkar i nya fönster eller ej.

Hur menar du nu? Min kod validerar utmärkt, även med javascript. Eller missförstod jag dig bara?

Jag tror dAEk^ menar att det inte finns någon anledning att skriva XHTML-validerande kod om man med hjälp av javascript förbigår de reglerna som är krav för valideringen.

Man validerar ju inte HTML / XHTML för att kunna säga att koden validerar? Det finns ju en viss annan anledning också...

@nders skrev:

Jag tror dAEk^ menar att det inte finns någon anledning att skriva XHTML-validerande kod om man med hjälp av javascript förbigår de reglerna som är krav för valideringen.

Man validerar ju inte HTML / XHTML för att kunna säga att koden validerar? Det finns ju en viss annan anledning också...

Ja, då förstår jag. Det är helt klart dumt! :)
*känner mig träffad*

Ingen mer target för min del iallafall :e

silfver skrev:

@nders skrev:

Jag tror dAEk^ menar att det inte finns någon anledning att skriva XHTML-validerande kod om man med hjälp av javascript förbigår de reglerna som är krav för valideringen.

Man validerar ju inte HTML / XHTML för att kunna säga att koden validerar? Det finns ju en viss annan anledning också...

Ja, då förstår jag. Det är helt klart dumt! :)
*känner mig träffad*

Det är helt klart inte alls dumt. För det första så tänker jag länka till två artiklar om ämnet:

http://www.smackthemouse.com/20030831 samt
http://www.sitepoint.com/article/standards-compliant-world
- sitepoint artikel har jag länkat till tidigare när frågan har kommit upp här på forumet.

I sitepointartikeln står det:

A Fine Line

As a bit of a perfectionist, my first impulse when I learned of this solution was to ask, "Is there really a difference?" And yes, I often talk to myself while doing research.

I mean, if the target attribute of the <a> tag is being phased out, does it really make a difference whether we're setting it with JavaScript instead of HTML? Sure, the page will validate against the HTML 4.0 Strict and XHTML 1.0 Strict Document Type Definitions, but aren't we technically cheating?

The answer is no. The Document Object Model (DOM), which governs the document objects and attributes that are available to JavaScript code, is a totally separate standard from (X)HTML. Also consider that the DOM 2.0 standard that was published in January 2003 (well after XHTML 1.0, let alone HTML 4.0) still includes this attribute. It seems clear that while this attribute is slated to be phased out of (X)HTML, it will be available to JavaScript through the DOM for the foreseeable future.

och det summerar ganska bra det som jag inte håller med er om.

Ni säger alltså att
1. Sidan kommer inte validera strict
2. Det är lika gott som att fylla ut den med font-element genererade via javascript
3. Regler är uppsatta för att hållas och ingen flexibilitet
4. (underförstått) - Alla eller många användare är tillräckligt bra på att hantera en webbläsare för att förstå hur man öppnar länkar i nya sidor.
5. "Window.open-lösningen är bättre i så fall"

Svar:
1. Jo, det kommer den om man använder ett attribut som semantiskt används för att ge logik till koden - som just rel attributet!
I smackthemouse artikel så står det

The idea is to use another attribute in the DTD, an attribute where author defined values are allowed. The most logical attribute to use instead of "target" is "rel", that is "relation". The REL attribute is not much used today, not many browsers support any of the values mentioned in the DTD. These values, e.g. "start", "contents", "previous" and "next" are just mentioned in the DTD as examples. You are allowed to define your own values.

Om ni läser det så ser ni att det visst finns validerande xhtml som kan öppna i nya fönster.

2. Det är lika bra som att fylla sidan med depreciated element säger ni - det håller jag inte alls med om. Font i sig blev omodern genom att den blandade presentation/design/styling med markup/text - sidorna blev omöjliga att hålla reda på och det slutade med en massa fula sidor över allt, som ni säkert alla minns. Så det stämmer inte alls att det skulle vara lika "fult"
t
3. Flexibilitet är ledordet, det och tillgänglighet och separation av styles och markup som ni säkert redan har läst er galna på. Om jag anser att en image map passar min sida, så kommer jag sätta in den där även om xhtml strict inte tycker om den. (numera använder jag mig av blocklänkar men för att visa vad jag menar). Rel är ett attribut som är tänkt att innehålla passande ord som visar en relation till innehållet - men de är egentligen ganska öppet. Google har tex. "nofollow" värdet i rel attributet som visar att googles spindel inte ska följa den länken. Står det i w3cs dokument? nä, och det ska det inte heller..
Om det passar mig så skriver jag om xhtml 1.1 dtdn så att den passar mig om jag behöver en extra funktion på mina sidor - webbläsaren ignorerar alla attibut den inte fattar och mitt javascript kan använda mitt attibut (eller tag eller värde) till det som passar MIG.

4. Enligt personlig erfarenhet av att se människor surfa så skulle jag säga att många är totalt inkompetenta med en webbläsare jämfört med mig. (ja, ytterligheter) Men jag är relativt lika bra som ni som läser detta är, och jag tvivlar på att personer som inte kan webbdesign läser diskussioner som denna - alltså så spelar det ingen roll om jag öppnar sidan i ett nytt fönster eller tab - bara href attributet stämmer så att jag som klickar på länken får upp samma fönster oavsett om jag mittenklickar, högerklickar för att koperia adressen eller vänsterklickar för att använda orginalmeningen av länken. Enligt mig.

5. Nä, det är det inte alls, då en länk visar att du förflyttas någonstans medan window.open förmodras öppna en sida inom siten - men det är självklart från person till person - jag fattar bara inte varför man ska krångla till det med window.open. Åter igen säger Kevin Yank det bra:

A number of other standards-compliant new-window link scripts out there propose using window.open() to load the document in a new window. While this approach generally works well on the surface, its downfall is that most browsers do not correctly report the referring URL in the request for the new page, which can be a serious issue, especially in inter-site links.

Det ska tilläggas att jag inte håller med smackthemouses artikel som ni kanske har förstått. Men innan ni svarar emot mig - läs sitepointartikeln!

Sov gott.

Jaaaaaaaaaaaaarvklo!!! ;)

Damn saknar mannen :l

The answer is no. The Document Object Model (DOM), which governs the document objects and attributes that are available to JavaScript code, is a totally separate standard from (X)HTML.

Ehum, My bad. :D Har inte kodat på typ ett år och glömde bort det. Klart att Kevins lösning är ok!

Generellt sett är jag emot nya fönster. Det krånglar till det för de ovana användarna så det naturliga är att låta användarna välja själva. Man kan tex ta Kevins script vidare lite och låta användarna välja ifall t.ex. externa länkar ska öppnas i nytt fönster eller ej. På så sätt blir alla glada. ;)

Enligt det resonemanget är det även tillåtet att göra till exempel:

document.documentElement.setAttribute("foo", "bar");

...som kommer (i ett XHTML-dokument) resultera i

<html xmlns="http://www.w3.org/1999/xhtml" foo="bar">

Uppenbarligen är foo ett ogiltigt attribut för html-elementet i ett XHTML-dokument. Det spelar ingen roll hur det kom dit. Att en validator inte ser det beror på att den inte utför skriptet, men det är ju webbläsaren som ska tolka dokumentet, inte en validator. Att använda skript för att komma runt validering för valideringens skull är i min mening helt uppåt väggarna. :)

Angående rel="":

Authors may wish to define additional link types not described in this specification. If they do so, they should use a profile to cite the conventions used to define the link types. Please see the profile attribute of the HEAD element for more details.

-- http://www.w3.org/TR/REC-html40/types.html#type-links

voigtann1 skrev:

Hur löser man target när man ska koda i xhtml? eller går det inte?

Jo, det går lika bra som i HTML4 om du använder Transitional. :)

Angående W3C DOM, så står det i DOM (HTML) Level 1:

target
Frame to render the resource in. See the target attribute definition in HTML 4.0.

elm.target = "_blank";

är i själva verket samma sak som

elm.setAttribute("target", "_blank");

i DOM (Core) Level 1, eller

elm.setAttributeNS(null, "target", "_blank");

i DOM (Core) Level 2, eller

<a href="#" target="_blank">länk</a>

i HTML4.

zcorpan skrev:

Enligt det resonemanget är det även tillåtet att göra till exempel:

document.documentElement.setAttribute("foo", "bar");

...som kommer (i ett XHTML-dokument) resultera i

<html xmlns="http://www.w3.org/1999/xhtml" foo="bar">

Uppenbarligen är foo ett ogiltigt attribut för html-elementet i ett XHTML-dokument. Det spelar ingen roll hur det kom dit. Att en validator inte ser det beror på att den inte utför skriptet, men det är ju webbläsaren som ska tolka dokumentet, inte en validator. Att använda skript för att komma runt validering för valideringens skull är i min mening helt uppåt väggarna. :)

Angående rel="": -- http://www.w3.org/TR/REC-html40/types.html#type-links

Nej, det är inte alla samma sak! Som jag skrev i min förra post så är inte rel ett oligtigt attribut. Ditt foo attribut är däremot ogiltigt. Standarderna är till för att webbläsarna ska rendera sidorna likadant, inte för att låsa fast en i dem.
Jag separerar alltså min text från det dynamiska - unobtrusive javascript helt enkelt. Det betyder att sidan fungerar exakt lika bra utan att ha det på, och en användare kan stänga av javascript när som helst.

Den länken som du skickade är till linkelementen och är inte till för att visa vart länkar pekar som befinner sig INNUTI body.

voigtann1 skrev:

Hur löser man target när man ska koda i xhtml? eller går det inte?

det har jag svarat på för strict nu i alla fall.

hltm skrev:

Jaaaaaaaaaaaaarvklo!!!

Damn saknar mannen

så? Duger inte jag kanske :)?

dAEk^ skrev:

Klart att Kevins lösning är ok!

:)

echoSwe skrev:

Nej, det är inte alla samma sak! Som jag skrev i min förra post så är inte rel ett oligtigt attribut.

Jag syftade på target="", inte rel="".

echoSwe skrev:

Ditt foo attribut är däremot ogiltigt.

Du medger att mitt foo-attribut är ogiltigt. Berätta för mig, vad är skillnaden mot ditt target-attribut? Båda är ogiltiga i Strict.

echoSwe skrev:

Standarderna är till för att webbläsarna ska rendera sidorna likadant

HTML och XHTML-specifikationerna säger i princip ingenting om hur webbläsare ska rendera sidor.

echoSwe skrev:

Jag separerar alltså min text från det dynamiska - unobtrusive javascript helt enkelt.

Good for you. :) Du måste ändå inse att du sätter ett target-attribut med hjälp av javascript, och att target-attributet inte är tillåtet enligt Strict?

echoSwe skrev:

Den länken som du skickade är till linkelementen och är inte till för att visa vart länkar pekar som befinner sig INNUTI body.

<!ATTLIST A
...
rel %LinkTypes; #IMPLIED -- forward link types --
...
>

"Link types" har samma definition för A-elementet som för LINK-elementet.

Tjena

Jag syftade på target="", inte rel="".

okej, fel av mig

Du medger att mitt foo-attribut är ogiltigt. Berätta för mig, vad är skillnaden mot ditt target-attribut? Båda är ogiltiga i Strict.

jag har aldrig sagt att man ska använda ett target attribut i strict. - i markupen - skilj på de båda (mer nedan)

HTML och XHTML-specifikationerna säger i princip ingenting om hur webbläsare ska rendera sidor.

nä, men det var heller inte det jag sade. jag sade standarder. i och med att xhtml tillsammans med css bygger layouter och webbläsare render(ade) detta olika, så är standarder till för att det ska bli lika bra i alla. i alla fall i bästa möjliga fall.
vad gäller attribut så är de väl också en del av standarderna, och om jag då utökar det jag sade med "[...] rendera sidor _och_ hantera användarinput och events" (som just en länk-klick)

Good for you. Du måste ändå inse att du sätter ett target-attribut med hjälp av javascript, och att target-attributet inte är tillåtet enligt Strict?

ja, det är good for me. och det är good for alla andra också. det är därför jag gör det, och säger att om man vill öppna en länk i nytt fönster så _kan_ man göra såhär. OM MAN VILL - är man låst vid tanken att man inte kan utöka definitionerna med dhtml, så visst, för all del.

jag är medveten om att man sätter targetatributen till alla länkar ja, men skillnaden mot att skriva det i koden är att här så hanterar man... om jag tar det på engelska - the interaction between the user and the browser, alltså hur läsaren beter sig - det som javascript är till för alltså.

den här diskussionen kan ju förlängas till år och dar, och komma att inkludera att man inte ska ändra storleken på webbläsaren, att man inte ska ta bort adressraden på popups osv osv. jag gav honom svar på frågan och visade att det inte är fel att använda den här tekniken. det är upp till dig om du gör det. problemet du har zcorpan är just att du anser att det är fel att göra på det här sättet, och det är det jag argumenterar mot.

Jag är mer inne på zcorpans spår. Det spelar ingen roll om man lägger till det via JS (endast för att slippa fel i validatorn?) istället för direkt i XHTML, efter att scriptet körts av JS ligger ju samma funktion på sidan.

Jag förstår inte varför man tvunget måste ha XHTML strict med om man ändå undgår riktlinjerna genom att lägga till förbjudna attribut på omvägar, det är bara att slänga in det i koden direkt om man vill ha det men då får man ta konsekvenserna - alltså kan man inte längre kalla det strict.

Vad är fel med det?

rel="external" är inte ett förbjudet attribut. det ger logisk information om hur länken fungerar - den visar att den går ut från sidan (tex.). så sluta säga "förbjudet"! Attributet heter rel och är inte förbjudet.

Om det är i JS så handlar det om events medan markup handlar om att förmedla data! Enligt ert resonemang så är det lika fel att skriva

img { border:0; }

i sin css för att undvika fel i validatorn i strict juh!!! css handlar om presentation, html handlar om data och javascript handlar om events, kortfattat. separation av lagerna helt enkelt.

hehe - här var det livat :)

Mina tio öre då:

Oavsett hur man lägger till ogiltiga attribut eller element i ett XML-dokument (dvs oavsett om man lägger till det som text eller mha anrop till DOM när dokumentet råkar vara inläst via en parser) så blir dokumentet bara "Välformat" efteråt (förhoppningsvis) - men det kommer inte längre att vara "Giltigt" iom att det inte längre uppfyller den aktuella DTD:n eller det aktuella Schemat. Validering av ett visst givet XML-dokument är alltså att kolla att det är "Giltigt" (dvs både välformat och uppfyllande en angiven DTD eller ett angivet Schema)

Vad "Välformat" innebär framgår av XML-specen - men vi känner alla till reglerna för hur taggar får skrivas i t.ex. XHTML som ju är en applikation av XML :)

Target inpetat i DOM-trädet för ett dokument skrivet i XHTML 1.0 Strict på ett eller annat sätt bryter alltså giltigheten gentemot dokumenttypen XHTML 1.0 Strict lika effektivt som att infoga ett attribut kallat foo i textrepresentationen av dokumentet. - Jag menar text- och DOM-representationerna är i alla lägen ekvivalenta... Modifierar man den ena, ändras också den andra...

... Att man sedan kan ha nytta av att göra det i praktiken för att få till en eller annan funktionalitet som man vet att besökarens webbläsare ändå stödjer är liksom en annan diskussion - men man bör vara medveten att man slaktar alla anspråk på att dokumentet skall vara giltigt (kunna valideras) enligt den DTD man anger - iallafall om DTD:n är XHTML 1.0 Strict :)

IMHO är det oavsett vad man tycker förmodligen enklast och på alla sätt effektivast att bara helt enkelt byta DTD till XHTML 1.0 Transitional för de sidor man vill ha target-attribut på - Jag menar, man kan ju koda sidan på exakt samma sätt som vore DTD:n Strict ändå - och en sådan lösning tar förmodligen också garanterat färre bytes/tecken i källkoden/bandbredd/exekveringstid i klienten/osv in absurdum i anspråk än att skicka med en massa scripts som ändrar sidans struktur efter leverans för att lura sig till ett OK från en buggig validator på W3C :birp