Hola otra vez.
Es cierto lo que descubrió
Bravenap: las páginas deben estar alojadas en el mismo sitio, o no funciona. No es la única limitación, estuve preguntando y me enviaron un tutorial que estoy seguro sacaron de la página de
Microsoft (si alguien sabe del comportamiento de un
iframe en
Internet Explorer son ellos). Lo posteo al final.
Pero no te desanimes
debspain, aún te falta probar con ventanas
pop-up y
SSI (
<!--#include file="mi_libro_de_visitas.html" --> ).
Por otro lado, disiento con
Bravenap y
JavierB sobre el tema "cambios en documentos ajenos". Si empezamos a hilar fino, es lógico que no podamos modificar un código fuente, pero éste sirve al navegador sólo para escribir la página ; una vez
rendereada ¡La página es nuestra!.
De hecho, con ese principio funcionan los bukmárlets.
Un ejemplo: estamos viendo un documento que pertenece a los
Foros del WEB, el cual no podemos modificar desde el
source porque no somos
crackers; pero como no nos gusta el color del texto, lo podemos cambiar en nuestra copia escribiendo ( o copiando y pegando ) en la barra de direcciones
javascript:void(document.fgColor='red')
y dándole un
[ENTER] ( o un
Go , o un
Ir a ) cambiamos el formato del texto.
Si lo que no nos gusta es como se ve la barra de desplazamiento en el
Internet Explorer :
javascript:void(document.body.style.scrollbarFaceC olor='greenyellow')
Para volver al formato original alcanza con recargar la página.
Gracias
JavierB por el dato de
document.readyState) , y no te preocupes en ponerlo en mi código, el problema se da solamente en máquinas lentas como la mía
Un saludo a todos
furoya
NOTA : Este tema fue publicado antes de mayo del 2004; para esa fecha, un cambio en el diseño del foro dejó sin efecto el
bookmarklet para el cambio de color de texto. Si bien éste no debe ser el más práctico ( además, es para
IE ), lo dejo para que aún se pueda entender de qué estamos hablando.
javascript:for (i=0; i<document.all.length; i++){document.all(i).style.color='red'};void(0)
El uso es igual al del bukmárlet mencionado en el mensaje.
Cross-Frame Scripting and Security
With Dynamic HTML, content in different windows and frames can interact in powerful ways by scripting with the object model. However, since it is possible for a browser to simultaneously display unrelated documents in its various windows and frames, certain rules must be enforced to protect data integrity and privacy of information.
This section describes how and why these restrictions apply in the DHTML object model. All rules about script interaction apply equally to windows, dialog boxes, FRAMESETs, FRAMEs, and IFRAMEs.
For most content, only interactions with content from the same domain are allowed. For example, a typical page on http://www.microsoft.com/ can freely script content on any other page on http://www.microsoft.com/ but cannot script to pages that are located on a different Web domain. The DHTML object model uses the document.domain property to enforce this restriction: only pages with identical domain properties are allowed free interaction. The protocol of the URL must also match. For instance, an HTTP page cannot access HTTPS content.
The range of permissible access for a page can be expanded when a script assigns the document.domain property to a suffix of the site name space, up to the second-level domain. For example, a page on http://www.microsoft.com/ can assign the document.domain property—initially "www.microsoft.com"—to be "microsoft.com" to broaden access to include pages in http://home.microsoft.com or any other site, as long as the other pages also set the document.domain property to the identical value. Since only pages from a site whose name ends with "microsoft.com" will permit this domain to be set, it is assured that content from the same provider mutually agrees to interact and is free to do so. Domain suffixes shorter than the second-level domain (such as just "com") are disallowed because they expose beyond a single provider. For international site names such as http://www.microsoft.co.jp/, the second-level domain for widest access would be "microsoft.co.jp" (not "co.jp").
Since it is important to be able to navigate windows or frames to any URL beyond the domain restriction, these types of accesses are always permitted. Only access that attempts to read-out or modify content is restricted. For instance, the window.location might be assigned to cause navigation to occur, but this property cannot be read if the URL is of a different domain. This would allow one page to learn where the user has been browsing, and to allow this is a breach of the user's privacy. Some restrictions that apply to pages of different domains include:
window.location = Property can be set to navigate, but cannot read.
Other location = Functionality is blocked.
document.href = Property can be set to navigate but cannot read.
Other document = Functionality is blocked.
<IFRAME> src = property can be set to navigate but cannot read
Scripts that attempt to access parts of the object model to which they do not have access will be blocked with a "permission denied" error.
While domain security can prevent certain types of content interaction, it is important to understand that this restriction is necessary to ensure security. For example, without domain security, a rogue page could "snoop" on other pages or, using DHTML, manipulate its content. http://www.w3.org/Jigsaw/Doc/User/SSI.html