#5:
#4 ciertamente no es un lenguaje de programacion, es un lenguaje de presentacion... pero dejemos que los diseñadores web se crean importantes
#11:
#9 Una alternativa sería poner el menú en una capa fija (position: fixed, el IE6 no lo implementaba, pero IE7 sí) con un tamaño concreto, el que le habrías dado al frame. Con esto tienes siempre el menú en su sitio
Para que aparezca en todas las páginas, usas el include habitual en asp / jsp / php o lo que sea. Y si estás usando algún sistema de plantillas, mejor que mejor. Si usas páginas estáticas, a copiar y pegar toca, aunque en un entorno empresarial o de intranet, dudo mucho que uses páginas estáticas.
#4:
Sorry pero no es lenguaje de programación (/voydepro) interesante noticia.
#13:
#11 "el menú lateral está siempre a la izquierda, fijo y sin necesidad de frames" –> Ahora mira la misma página en IE...
#2:
El artículo no está mal, pero me parece más interesante el enlace que da para hacerse una idea de las diferencias con el HTML actual: http://www.w3.org/html/wg/html5/diff/
#9 Una alternativa sería poner el menú en una capa fija (position: fixed, el IE6 no lo implementaba, pero IE7 sí) con un tamaño concreto, el que le habrías dado al frame. Con esto tienes siempre el menú en su sitio
Para que aparezca en todas las páginas, usas el include habitual en asp / jsp / php o lo que sea. Y si estás usando algún sistema de plantillas, mejor que mejor. Si usas páginas estáticas, a copiar y pegar toca, aunque en un entorno empresarial o de intranet, dudo mucho que uses páginas estáticas.
El artículo no está mal, pero me parece más interesante el enlace que da para hacerse una idea de las diferencias con el HTML actual: http://www.w3.org/html/wg/html5/diff/
El frame está fuera del standard desde hace muchos años, al menos del strict, estaba permitido en el transitional y en el loose. Usar un frame para eso es una guarrada, al menos desde el punto de vista del standard, como alternativa... tienes por ejemplo asp.net y las master pages.
#38 Una pista, explorer para medir el ancho no cuenta ni el "padding" ni el "margin" mientras que el resto de los navegadores lo único que no cuentan es el margin, lo más lógico claro. La siguiente declaración en el CSS ahorra muchos dolores de cabeza:
body
El problema, como no, viene cuando se quiere utilizar la propiedad padding, no hay más remedio que anidar otro div y usar su margen a modo de separación.
#35 Comparto la sospecha... (Opera es el único navegador que soporta los contadores de forma plena. Mozilla tiene algunas lagunas y el IE nada de nada)
tanto bla, bla, bla... si al final lo que importa es que el puto navegador haga caso de lo que dice la w3c, porque de nada vale que se marquen reglas si luego cada uno parsea de la manera que le sale del bigote.
Es decir fixed funciona en todos los navegadores actuales ( Firefox2, Opera9, IE7, Safari3, Konqueror, etc). Sinceremante, y dime anti-IE si quieres, pero si estamos hablando de HTML5, hablemos de navegadores modernos.
Tiene buena pinta, si señor, muy buena pinta. El cambio de HTML 4 a HTML5 me recuerda al cambio de ASP a ASP.net, usar la misma base para hacer algo totalmente distinto que es facil de entender y aumenta la facilidad de uso. Me gusta la manera de estructurar las paginas, las nuevas etiquetas... a ver si pronto sale la version definitiva y empiezan a salir navegadores compatibles.
#19 De la Wikipedia en inglés: "The HTML 5 draft defines a parallel XML serialization for HTML5. The XML serialization is called XHTML5. Unlike XHTML 2.0, XHTML5 is compatible with XHTML 1.x"
Habrá que ver que es más conveniente para cada caso, XHTML 2.0 puro y duro o la serialización XML de HTML5. Y también habrá que ver qué gana en el mercado
#40 Vale, muchas gracias, lo revisaré en cuanto pueda mirar el código. (Ahora no recuerdo si uso el padding en algun sitio... creo que si)
Si, lo que mi pecado fué empezar todo basándome en Firefox para luego ver que en Explorer no encajaba nada.
Y Firefox tampoco cumple algunas normas, pero Explorer creo que se lleva la palma de oro.
#22 Gracias, c&p del comentario que hice en su momento, relativo a la compatibilidad:
En cuanto a los problemas de no implementación , c&p:
"Finally, when the caveman fired up the 300MHz laptop running Windows 98 that was also frozen in 1999, they might be astonished to realize that the new pages display fine in Netscape 4 and Windows® Internet Explorer® 5. Sure, the browser wouldn't recognize or do anything with the new elements, but the page still displays, and the content is all there.
That's not a happy coincidence. HTML 5 was explicitly designed to degrade gracefully in browsers that don't support it. The reason is simple: We are all cave people. Browsers now have tabs, CSS, and XmlHttpRequest, but their HTML renderers are stuck in 1999. The Web can't move forward without accounting for the installed base. HTML 5 understands this. It offers real benefits to page authors today while promising even more to page readers tomorrow as browsers are slowly upgraded. With that in mind, let's look at what HTML 5 brings you."
En cuanto a temas de compatibilidad, no debe ser demasiado complicado hacer un script genérico que sustituya las etiquetas semánticas por los divs y los spans correspondientes en navegadores antiguos.
En realidad implementar estas etiquetas es sencillisimo, pues se comportan igual que los spans y los divs. Solo es cuestión de que quieran hacerlo.
#8 Bueno, me refiero a un sustituto para tener un menu fijo que al pulsar cambie la página que se pretende ver.
Quizá sea malo para motores de búsqueda pero , en un entorno empresarial o intranet, ¿ qué problemas hay ? Puede ser útil.
Por eso quiero saber cual es la alternativa a FRAME que haga lo mismo pero sin sus perjuicios.
No pueden quitarme algo del estandar sin ofrecerme una alternativa.
#27 La última vez que usé Dreamweaver, tenía la opción de realizar la maquetación mediante divs + css, aparte de en tablas. Y era la versión 3, hace unos cuantos años ya.
#2 hombreeeeee eso de los frames no es precisamente nuevo en el 4 tambien estaba firmada su muerte...
No entiendo muy bien el razonamiento detras de 3.1, no le veo utilidad otra que limitar el uso de las etiquetas y añadir una dificultad añadida a la creacion de html valido.
Podeis poner mas ejemplos como el de #11, gracias ademas, porque no entendia ni papa hasta que has puesto un ejemplo, y queda mas claro asi del tipo de mejoras que traera.
Me gustan las nuevas etiquetas, creo que hará mucho mas sencillo ese tipo de maquetación, pero claro, esto siempre va por delante de los navegadores y mucha gente seguirá con los que no leen HTML5 y se tardarán en aplicar los nuevos cambios.
Las que mas me llaman la atención son las etiquetas de audio y video, creo que eso será un muy buen avance s se implementa bien como se espera.
#9 si lo que pretendes es que la parte del menú no cambie siempre puedes usar AJAX, de todas maneras sigo sin ver el motivo para necesitar un FRAME. Igual bajo ciertas circunstancias especiales puede resultar más cómodo (aunque lo dudo...) pero estoy casi seguro de que su necesidad no está en absoluto justificada.
Esto de los navegadores es la leche.
Hace poco tuve que realizar un catalogo online y me tocó aprender html, php, etc, vale, aprenderemos...
Lo que que no aguantaba eran las horas perdidas intentando cuadrar los divs en el firefox sin que el explorer me los esparciese por la pantalla de cualquier manera.
Y la cantidad de porqueria que tenia que meter para "compatibilizar".
Ahora entiendo cuando dicen que el explorer es kk, la de malos ratos que me ha hecho pasar... y me hará pasar.
Y aún no he probado la página en el visor ese en modo texto, como se llamaba... lynx o así.
Comentarios
#4 ciertamente no es un lenguaje de programacion, es un lenguaje de presentacion... pero dejemos que los diseñadores web se crean importantes
Sorry pero no es lenguaje de programación (/voydepro) interesante noticia.
#9 Una alternativa sería poner el menú en una capa fija (position: fixed, el IE6 no lo implementaba, pero IE7 sí) con un tamaño concreto, el que le habrías dado al frame. Con esto tienes siempre el menú en su sitio
Para que aparezca en todas las páginas, usas el include habitual en asp / jsp / php o lo que sea. Y si estás usando algún sistema de plantillas, mejor que mejor. Si usas páginas estáticas, a copiar y pegar toca, aunque en un entorno empresarial o de intranet, dudo mucho que uses páginas estáticas.
Puedes ver un ejemplo de esto en: http://www.w3.org/Style/Examples/011/firstcss.es.html . Fíjate como el menú lateral está siempre a la izquierda, fijo y sin necesidad de frames.
El artículo no está mal, pero me parece más interesante el enlace que da para hacerse una idea de las diferencias con el HTML actual: http://www.w3.org/html/wg/html5/diff/
Entre cosas a destacar: ¡no más frames!
#11 "el menú lateral está siempre a la izquierda, fijo y sin necesidad de frames" –> Ahora mira la misma página en IE...
#26 ¡Por el culo te la hinco! (¿Cómo has picado? Era muy obvio... :-P)
#11 muerte a los frames, pero... gmail usa frames
#6 ¿ninguno? no existe ninguna razon para usar frames, como mucho Iframes y porque son utiles para la tecnologia AJAX.
Ya tenemos nuevos elementos en HTML 5
Ya tenemos nuevos elementos en HTML 5
ibm.comNo están todos los que hay en esta noticia, per sí algunos...
El frame está fuera del standard desde hace muchos años, al menos del strict, estaba permitido en el transitional y en el loose. Usar un frame para eso es una guarrada, al menos desde el punto de vista del standard, como alternativa... tienes por ejemplo asp.net y las master pages.
#38 Una pista, explorer para medir el ancho no cuenta ni el "padding" ni el "margin" mientras que el resto de los navegadores lo único que no cuentan es el margin, lo más lógico claro. La siguiente declaración en el CSS ahorra muchos dolores de cabeza:
body
El problema, como no, viene cuando se quiere utilizar la propiedad padding, no hay más remedio que anidar otro div y usar su margen a modo de separación.
Y que pasa con XHTML 2.0?, ¿no habíamos quedado en que HTML no se iba a usar?.
#20 Lo que pides ya se puede hacer, mediante CSS (la numeración de los acápites es una cuestión de formato):
http://www.w3.org/TR/CSS21/generate.html#counters
#35 Comparto la sospecha... (Opera es el único navegador que soporta los contadores de forma plena. Mozilla tiene algunas lagunas y el IE nada de nada)
tanto bla, bla, bla... si al final lo que importa es que el puto navegador haga caso de lo que dice la w3c, porque de nada vale que se marquen reglas si luego cada uno parsea de la manera que le sale del bigote.
#13 No tengo IE a mano
¿Qué versión de Iexplorer tienes? Internet Explorer 7 sí implementa fixed
( http://blogs.msdn.com/ie/archive/2006/08/22/712830.aspx ).
Es decir fixed funciona en todos los navegadores actuales ( Firefox2, Opera9, IE7, Safari3, Konqueror, etc). Sinceremante, y dime anti-IE si quieres, pero si estamos hablando de HTML5, hablemos de navegadores modernos.
uf de 10 a 15 años...
Tiene buena pinta, si señor, muy buena pinta. El cambio de HTML 4 a HTML5 me recuerda al cambio de ASP a ASP.net, usar la misma base para hacer algo totalmente distinto que es facil de entender y aumenta la facilidad de uso. Me gusta la manera de estructurar las paginas, las nuevas etiquetas... a ver si pronto sale la version definitiva y empiezan a salir navegadores compatibles.
#19 De la Wikipedia en inglés: "The HTML 5 draft defines a parallel XML serialization for HTML5. The XML serialization is called XHTML5. Unlike XHTML 2.0, XHTML5 is compatible with XHTML 1.x"
Habrá que ver que es más conveniente para cada caso, XHTML 2.0 puro y duro o la serialización XML de HTML5. Y también habrá que ver qué gana en el mercado
#40 Vale, muchas gracias, lo revisaré en cuanto pueda mirar el código. (Ahora no recuerdo si uso el padding en algun sitio... creo que si)
Si, lo que mi pecado fué empezar todo basándome en Firefox para luego ver que en Explorer no encajaba nada.
Y Firefox tampoco cumple algunas normas, pero Explorer creo que se lleva la palma de oro.
#22 Gracias, c&p del comentario que hice en su momento, relativo a la compatibilidad:
En cuanto a los problemas de no implementación , c&p:
"Finally, when the caveman fired up the 300MHz laptop running Windows 98 that was also frozen in 1999, they might be astonished to realize that the new pages display fine in Netscape 4 and Windows® Internet Explorer® 5. Sure, the browser wouldn't recognize or do anything with the new elements, but the page still displays, and the content is all there.
That's not a happy coincidence. HTML 5 was explicitly designed to degrade gracefully in browsers that don't support it. The reason is simple: We are all cave people. Browsers now have tabs, CSS, and XmlHttpRequest, but their HTML renderers are stuck in 1999. The Web can't move forward without accounting for the installed base. HTML 5 understands this. It offers real benefits to page authors today while promising even more to page readers tomorrow as browsers are slowly upgraded. With that in mind, let's look at what HTML 5 brings you."
En cuanto a temas de compatibilidad, no debe ser demasiado complicado hacer un script genérico que sustituya las etiquetas semánticas por los divs y los spans correspondientes en navegadores antiguos.
En realidad implementar estas etiquetas es sencillisimo, pues se comportan igual que los spans y los divs. Solo es cuestión de que quieran hacerlo.
#25 ¿HTML 5?
#20 Pues comenta algo sobre que eso no hay quien lo haga sin mil historias en CSS...
#8 Bueno, me refiero a un sustituto para tener un menu fijo que al pulsar cambie la página que se pretende ver.
Quizá sea malo para motores de búsqueda pero , en un entorno empresarial o intranet, ¿ qué problemas hay ? Puede ser útil.
Por eso quiero saber cual es la alternativa a FRAME que haga lo mismo pero sin sus perjuicios.
No pueden quitarme algo del estandar sin ofrecerme una alternativa.
#27 La última vez que usé Dreamweaver, tenía la opción de realizar la maquetación mediante divs + css, aparte de en tablas. Y era la versión 3, hace unos cuantos años ya.
#31 Jeje, es que veía tan ilusionado a #25 ... que decidí darle una alegría
#2 hombreeeeee eso de los frames no es precisamente nuevo en el 4 tambien estaba firmada su muerte...
No entiendo muy bien el razonamiento detras de 3.1, no le veo utilidad otra que limitar el uso de las etiquetas y añadir una dificultad añadida a la creacion de html valido.
HTML 5 vs Xhtml 2.0 la guerra está servida, prefiero el segundo
#38 La culpa no es de explorer, es de ambos, que no siguen las normas standar de la W3C (firefox se acerca mucho más a dichas normas, eso sí).
esto va a ser revolucionario, pasar de
gracias #33 me lo miraré, pero cuando en la propia web de w3.org para hacer estas listas ponen:
y en otros sitios se ven inventos parecidos. De numeracion automática nada
Podeis poner mas ejemplos como el de #11, gracias ademas, porque no entendia ni papa hasta que has puesto un ejemplo, y queda mas claro asi del tipo de mejoras que traera.
#34 ¿Será porque el maravilloso Explorer (incluido el 7) no soporta contadores ni contenido generado?
Me gustan las nuevas etiquetas, creo que hará mucho mas sencillo ese tipo de maquetación, pero claro, esto siempre va por delante de los navegadores y mucha gente seguirá con los que no leen HTML5 y se tardarán en aplicar los nuevos cambios.
Las que mas me llaman la atención son las etiquetas de audio y video, creo que eso será un muy buen avance s se implementa bien como se espera.
#9 iframe
#9 si lo que pretendes es que la parte del menú no cambie siempre puedes usar AJAX, de todas maneras sigo sin ver el motivo para necesitar un FRAME. Igual bajo ciertas circunstancias especiales puede resultar más cómodo (aunque lo dudo...) pero estoy casi seguro de que su necesidad no está en absoluto justificada.
No te están "quitando" algo, si no cambiándolo.
Me pregunto qué harán todos esos dreanweveros maqueta en tablas con dos clics ahora.
Esto de los navegadores es la leche.
Hace poco tuve que realizar un catalogo online y me tocó aprender html, php, etc, vale, aprenderemos...
Lo que que no aguantaba eran las horas perdidas intentando cuadrar los divs en el firefox sin que el explorer me los esparciese por la pantalla de cualquier manera.
Y la cantidad de porqueria que tenia que meter para "compatibilizar".
Ahora entiendo cuando dicen que el explorer es kk, la de malos ratos que me ha hecho pasar... y me hará pasar.
Y aún no he probado la página en el visor ese en modo texto, como se llamaba... lynx o así.
Salute!
¡¡¿¿Que número, que número??!!
#2 ¿ Cual es el sustituto de los frames ?
El adelanto será que me aprenda el código de una maldita vez…?