#39001 Pues mejor que no tengas que hacerlo, que dandole un par de vueltas, creo que es más lio de lo que parece la verdad xDD
#38997 Cuidadin con estas cosas... mira si puedes emplear otra estrategia para tus propósitos ya que andar consultando los límites de los elementos causa lo que se llama "reflow": https://gist.github.com/paulirish/5d52fb081b3570c81e3a
Quizás puedas usar: https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/elementFromPoint
#39004 Me gusta el document.elementFromPoint(x, y); y no lo conocía.
Lo unico es que, para el caso que comenta @eXtrem3, habría que iterar por cada pixel del alto total del documento, no?
Y no solo eso, si hay un div de 200 pixeles que está a 50 de la izq, estará entre 50 y 250 y al preguntar por lo que hay en el pixel 400, no aparecerá. por lo que también habría que iterar los primeros 400px de cada uno de los px de alto.
Con una página con un alto de 4000px, se ejecutaría esa funcion 1.600.000 veces..
Supongo que lo ideal tampoco sería comprobar pixel a pixel, si no cada 5px por ejemplo, lo cual reduciría el nº de ejecuciones a 64000 xD
De todas formas, corrígeme pq es la primera vez que veo la función y es lo que he entendido por la descripción xD
#39005 La verdad que es un método que vi que comentaban en el gist que puse... y tienes razón habría que andar mirando todo el rango de pixeles donde se espere que este el elemento a buscar.... desconozco si el método puede disparar el "reflow".
Igual una forma, que me parece un poco enrevesada, sería crear un QuadTree mediante un observer que este mirando cuando se añade un elemento al DOM e ir creando nuestro árbol. Luego sería cuestión de consultarlo.... Me parece raro que de no existir algo nativo alguien no haya hecho una librería para consultar por limites.
#39006 Quito el edit del post anterior y lo pongo en uno nuevo:
Buscando gracias al tuyo, he encontrado este, que supongo que si que valdría ejecutándolo una sola vez, aunque pone que es solo de Internet explorer, manda cojones xD:
https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/msElementsFromRect
#38997 solo te importa el caso para 1920px? Mirar si hay un elemento en los primeros 400px no es nada responsive. Puedes usar porcentajes, 400px debe de ser el 20%,
#39010 Por curiosidad cuál es el problema que intentas solucionar? Parece que vas a hacer una guarrada guapa, la solución la puedes subir a xvideos.
Por buscar un uso real... podría ser que desarrollases una extensión para chrome que insertase un div flotante a la izquierda de una página con unas power tools y no quieres que ese div esté por encima o por debajo de algún div nativo de la página en un momento dado.
#39021 Si puedes guardar cada versión en un disquete de 3.5 y ponerle en la etiqueta el código de la versión con un boli.
Por cierto, en mi curro antiguo uno de los dinosaurios decía que una base de código que no entra en un disquete de 3.5 es porque le sobra código. Lo dejo por aquí como dato que no le importa una mierda a nadie pero que es gracioso.
#39022 Pues sí, toda la puta razón.
Ahí tienes a Raylib, haciendo GUIs y binarios a full que pesan unos pocos kb
Windows 95 was 30MB. Today we have web pages heavier than that! Windows 10 is 4GB, which is 133 times as big. But is it 133 times as superior? I mean, functionally they are basically the same. Yes, we have Cortana, but I doubt it takes 3970 MB. But whatever Windows 10 is, is Android really 150% of that?
Google’s keyboard app routinely eats 150 MB. Is an app that draws 30 keys on a screen really five times more complex than the whole Windows 95? Google app, which is basically just a package for Google Web Search, is 350 MB! Google Play Services, which I do not use (I don’t buy books, music or videos there)—300 MB that just sit there and which I’m unable to delete.
#39023 Yo creo que el problema con el tamaño de las bases de código hoy día surge más a raíz del uso excesivo de librerías que a otra cosa. Hablo de bases de código puras, con imágenes vectoriales como mucho sin más movidas raras.
Cualquier proyecto de JS - por decir el lenguaje más amado en la actualidad - que tire de Angular ya tiene 500K solo en librerías.
#39027 No es lo mismo un compilado (que incluye librerías del sistema por ejemplo) que una base de código que es a lo que me refería, pero te lo compro.
De todos modos no decía lo de gracioso en plan "mira lo que dice este subnormal" sino porque aún no he visto ninguna base de código con un mínimo de complejidad, que no sea una librería hecha por alguien bueno, que baje de los 100M. En el proyecto que estoy ahora, que trabajamos con Elgg, solamente el framework ya son 50M, que si luego le empiezas a sumar plugins e historias varias se planta en 150M sin haber empezado a meter mano.
