mboost-dp1
W3C
Glæder mig virkelig til at se hvad de får bikset sammen. Håber de laver noget der er nemmere at style, fx mht tabelløst design med 100% højde.
Men hvad blev der af XHTML 2?
Men hvad blev der af XHTML 2?
Så mangler vi bare css3 også udkommer :) det bliver godt nok dejligt med en ny html standard..
Så kan det være vi definitivt er ude over browserspecifik kode
Så kan det være vi definitivt er ude over browserspecifik kode
#4 sidst jeg tjekkede var det Matrix version 7632.004
Er det min kommetar om enden for browserspecifikkode du hoster over..? Førende browsere ville ikke være førende længere, hvis ikke de fulgte standarderne.. så mon ikke motoren til at lave kode til grafik, bliver liiidt mere ensartet..?
Kan godt være jeg lever i min egen lille Alice in Wonderland verden
Er det min kommetar om enden for browserspecifikkode du hoster over..? Førende browsere ville ikke være førende længere, hvis ikke de fulgte standarderne.. så mon ikke motoren til at lave kode til grafik, bliver liiidt mere ensartet..?
Kan godt være jeg lever i min egen lille Alice in Wonderland verden
#11 okay sorry, forkert skrevet af mig.. ville ha skrevet det i nutid.. ved godt at IE da den blev skrevet ikke fulgte noget som helst.. men den bliver skrottet med en lynende hast, hvis ikke den gør det fremover
Altså mener jeg egentlig nærmere, at:
Førende browsere vil ikke blive ved at være førende længere, hvis ikke de følger standarderne
Altså mener jeg egentlig nærmere, at:
Førende browsere vil ikke blive ved at være førende længere, hvis ikke de følger standarderne
#13 Den bedste måde at forudsige fremtiden er nu engang at se på hvordan folk har opført sig indtil nu. Hvad mener du skulle gøre at IEs udviklere pludselig er nødt til at opføre sig pænt? Markedssituationen er stort set uændret i forhold til for 5 år siden. Andre browsere har større markedsandel nu, men tilsyneladende har de ikke nået den kritiske masse som de skal have for at markedet kan undgå at designe til IE...
http://www.w3.org/TR/2008/WD-html5-diff-20080122/ - De forskellige forskelle fra den gamle version 4. (gravet ud fra et link i linket)
#14 og #15
Altså det er ren spekulation, men går ud fra de ikke sidder hos ms og gnider sig i hænderne mens de tænker på hvordan de kan ødelægge IE8 mest muligt..
Almen sund fornuft og muligvis et forsøg på at vinde de oplystes tillid igen, burde vel gøre at de retter sig efter mængden.. så slipper de for hagl for at deres browser ikke håndterer koden ordentligt og at lave rettelser, hvis de en dag får en retsag på halsen for det
På den anden side, hvis jeg tager de finansielle briller på, så kunne man måske se på det som at det er med vilje for at holde på folk? De fleste tror jo det er firefox o.l. den er gal med og ikke ie
Altså det er ren spekulation, men går ud fra de ikke sidder hos ms og gnider sig i hænderne mens de tænker på hvordan de kan ødelægge IE8 mest muligt..
Almen sund fornuft og muligvis et forsøg på at vinde de oplystes tillid igen, burde vel gøre at de retter sig efter mængden.. så slipper de for hagl for at deres browser ikke håndterer koden ordentligt og at lave rettelser, hvis de en dag får en retsag på halsen for det
På den anden side, hvis jeg tager de finansielle briller på, så kunne man måske se på det som at det er med vilje for at holde på folk? De fleste tror jo det er firefox o.l. den er gal med og ikke ie
#18
Sikker?
De har i hvert faldt en sjov form for sikerhed
lille citat fra IE8 dev blogen
Frame/iframe del:
http://blogs.msdn.com/ie/archive/2008/01/18/using-...
selv blogen:
http://blogs.msdn.com/ie/archive/2007/12/05/intern...
Sikker?
De har i hvert faldt en sjov form for sikerhed
Using Frames More Securely
HTML frames (FRAMESETs and IFRAMEs) are a feature of all modern web browsers that enable content from multiple pages to be displayed within a single view. Historically, frames were primarily used to enable partial page updates, where page navigation was contained in one frame, and page content was contained in another. Over time, use of frames expanded to include advertising, mashup, and AJAX scenarios. Today, the majority of popular websites use IFRAMEs for myriad reasons.
From a security point of view, frames can help increase the security of web applications by creating isolation between content delivered from different sources. For instance, a Web mail account (http://mail.example.com) might choose to render HTML email within an IFRAME (http://untrusted.example.com/getmsg?msgid=1234) to ensure that any script in the HTML mail cannot execute in the context of the Web mail application delivered from mail.example.com. Instead, any script would execute in the context of the “untrusted.example.com” domain. This isolation prevents tampering with the Web mail UI, leaking user credentials and cookies, snooping on other messages, etc.
lille citat fra IE8 dev blogen
Frame/iframe del:
http://blogs.msdn.com/ie/archive/2008/01/18/using-...
selv blogen:
http://blogs.msdn.com/ie/archive/2007/12/05/intern...
#21 Der er en sikkerhedsmodel indbygget der sørger for at javascript fra ét domæne ikke kan tilgå data fra javascript der kører fra et andet domæne samtidig. Det er ganske godt, for ellers ville det være ret let at lave en hel masse ballade.
Det dokument du har fundet påpeger bare at man også kan bruge dette aktivt selv, hvilket sådan set er rigtigt nok. Det er ikke iframen i sig selv der gør det mere sikkert, det er det faktum at koden i iframen kommer fra et andet domæme.
Object tagget kan godt tilgå dine data, målet er at kunne køre javascript fra kilder som man ikke stoler på...
Det dokument du har fundet påpeger bare at man også kan bruge dette aktivt selv, hvilket sådan set er rigtigt nok. Det er ikke iframen i sig selv der gør det mere sikkert, det er det faktum at koden i iframen kommer fra et andet domæme.
Object tagget kan godt tilgå dine data, målet er at kunne køre javascript fra kilder som man ikke stoler på...
#23 BobSlaede skrev:untrusted.domain.com og mail.domain.com er ikke det samme.
Derfor kan en side fra unstrusted i en iframe ikke få adgang til parent.window.
Ikke korrekt. Subdomains på et domæne har samme rettigheder til javascript.
Derimod er mail.foo.com og mail.bar.com ikke det samme.
#25
Det kommer lidt an på browser og hvilke ting du gerne vil køre. Har oplevet problemer med IE7 og javascript på tværs af subdomæner.
Altid rart at man overholder standarderne, tester i tilgængelige brosere, finder ud af at alt kører og så regner man med at siden kører indtil man laver noget om. Men nej, så kommer der lige en ny browser, med ny sikkerhed. Og det skulle undre mig meget hvis IE7 er det eneste der kommer med den slags ændringer.
Det kommer lidt an på browser og hvilke ting du gerne vil køre. Har oplevet problemer med IE7 og javascript på tværs af subdomæner.
Altid rart at man overholder standarderne, tester i tilgængelige brosere, finder ud af at alt kører og så regner man med at siden kører indtil man laver noget om. Men nej, så kommer der lige en ny browser, med ny sikkerhed. Og det skulle undre mig meget hvis IE7 er det eneste der kommer med den slags ændringer.
Ikke korrekt. Subdomains på et domæne har samme rettigheder til javascript.
Derimod er mail.foo.com og mail.bar.com ikke det samme.
Absolut ikke enig.
http://domain.com og http://www.domain.com er MEGET forskellige. De har sågar forskellige cookies.
Og jeg får også sikkerhedsfejl mht. xmlhttprequest på overstående eksempel. Måske på frames , men tvivler stært. I Firefox altså.
Men måske snakker du kun om Internet Explorer ?-)
#28
Nej jeg snakker ikke kun IE, bruger den aldrig så skal ikke kunne udtale mig om hvordan den opererer.
Men er ganske sikker på at subdomains har samme retiigheder, så man kan lave interne scripts.
Jeg kan desværre ikke henvide til documentation.
Og nej de har ikke nødvendigvis forskellige cookies, kommer an på hvordan du gemmer din cookie.
Nej jeg snakker ikke kun IE, bruger den aldrig så skal ikke kunne udtale mig om hvordan den opererer.
Men er ganske sikker på at subdomains har samme retiigheder, så man kan lave interne scripts.
Jeg kan desværre ikke henvide til documentation.
Og nej de har ikke nødvendigvis forskellige cookies, kommer an på hvordan du gemmer din cookie.
#1... Man kan da sagtens sætte en 100% højde. Men 100% skal jo komme fra noget, så hvis du f. eks. vil sætte et div-element hvis parent er body, så skal body have en højde. Eller vil der ikke være noget at tage 100% af.
Du kan stadig få en "top-til-bund" effekt ved at sætte højden på body til 100%, og så derefter sætte 100% på det element du vil have til at gå fra top til bund. Du skal dog her huske at sætte position: absolute, så den håndterer højden udfra dens parent.
Så nøglen er at have body til 100% og så derefter have elementets parent til at være den størrelse man vil have den til, hvis man altså går efter 100% :)
Du kan stadig få en "top-til-bund" effekt ved at sætte højden på body til 100%, og så derefter sætte 100% på det element du vil have til at gå fra top til bund. Du skal dog her huske at sætte position: absolute, så den håndterer højden udfra dens parent.
Så nøglen er at have body til 100% og så derefter have elementets parent til at være den størrelse man vil have den til, hvis man altså går efter 100% :)
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund