Come evitare il costo delle prestazioni di overflow: nascosto?

Question

Ho una tabella HTML che può contenere più di 1K righe e una dozzina circa di colonne.

Desidero che le colonne abbiano una dimensione fissa (controllabile dall'utente) e non crescano/si restringono verticalmente o orizzontalmente. Quindi visivamente il contenuto di una particolare cella di una tabella sarà su una riga e l'overflow verrà troncato alla fine della cella.

Esecuzione dell'analisi delle prestazioni in Chrome su un grande tavolo il principale killer delle prestazioni è overflow: nascosto.

Ho provato a inserire il contenuto di ogni cella all'interno di un input, poiché ciò replicherebbe lo stesso comportamento visivo, ma ha un impatto simile sulle prestazioni.

Cosa consiglia la gente per migliorare le prestazioni?

Se necessario, non è necessario utilizzare un tag di tabella, ma preferirei attenersi al tag di tabella se è possibile ottenere buone prestazioni.

Aggiornamento 1: Ho incluso un file che dimostra il problema di prestazioni here. Attenzione il file è piuttosto massiccio (25 MB) e rallenterà il tuo computer. Per impostazione predefinita, la tabella non ha overflow impostato su hidden e una volta caricata la tabella (può richiedere un po 'di tempo) le prestazioni del browser relativamente agevolmente.

Tuttavia, se si modificano il file e le righe di commento 12-15 e quindi lo si apre. Vedrai dopo aver caricato il browser attorno al tavolo è sensibilmente meno reattivo.

Answer 1

Prima di tutto, la quantità di markup richiesta per avere una tabella è molto più grande di quella che si ottiene usando div con clear: entrambi i CSS per una nuova riga. quindi questo è il primo successo in termini di prestazioni.

anche, si sta impostando l'overflow come classe (?)

<style type="text/css"> .ovfl { overflow:hidden; }</style> 

    <td class="ovfl"></td> 

Per inciso, 1000 righe è un peso per consegnare.

Con div avere almeno un'opportunità più facile da buttare quelli da vista (oltre lo scorrimento) in un div con display: none fino i rotoli visitatori a loro.

poche pelli di gatto più probabile su questo lavoro,

Speranza avevano alcuni buoni pensieri.

Answer 2

Si potrebbe provare a utilizzare un approccio affiancato. È un approccio abbastanza tipico per rendere le cose come i giochi a scorrimento laterale infinitamente efficienti.

Inserire tutti i dati in un array Javascript e quindi disporre di N + 1 righe in una tabella con N righe visibili. Quando scorri verso il basso, l'ultimo oggetto verrà spostato in vista. Nel momento in cui si è fatto scorrere abbastanza lontano da spostare il primo oggetto fuori dalla vista, si spostano tutti i dati su una riga e si ripristina la posizione di scorrimento sul punto di partenza. Fatto correttamente, lo spostamento sarebbe completamente trasparente per l'utente. Lavorerai solo con N + 1 righe in una tabella visibile N-rows.

L'ho già fatto, ma con vincoli UI molto specifici. Ho una sorta di otturatore al pensiero di renderlo coerente usando le barre di scorrimento del browser e così via.

Answer 3

A proposito: ho incontrato questo problema su iPad/iOS causando problemi di prestazioni con una pagina che ha circa un centinaio di righe in una tabella con layout di tabella: corretto.

Non appena una cella, o un div in una cella, ottiene un attributo che lo costringe a disegnare individualmente, occorrono circa 300ms anziché 100ms per disegnare (il che fa sì che l'interfaccia utente si senta piuttosto abissalmente lenta per il mio situazione).

Una delle due proprietà (position:relative o overflow:hidden) ha causato il problema per me, rimuovendole ha ottimizzato la velocità ma ha causato l'overflow del testo se il testo della cella era troppo ampio per le colonne a larghezza fissa.

Il rallentamento stava accadendo anche dopo l'estrazione delle tabelle, perché sto facendo apparire in modo dinamico un div assoluto sul tavolo. Quando si profila il javascript (usando (new Date).getTime()), il rallentamento viene misurato in punti nel javascript che non hanno nulla a che fare con la tabella.

[edit: aggiunto come soluzione seguente parte]

1. Mettere tutto contenuto della cella all'interno di un elemento span (così può misurare offsetWidth di contenuto piuttosto che larghezza contenente elemento di blocco).
2. Dopo aver aggiunto la riga nel documento, verificare se ogni span.offsetWidth è maggiore della larghezza della colonna, in tal caso aggiungere "overflow: hidden" allo stile (o tramite una classe) del blocco contenitore.
3. È possibile saltare 1 e 2 sopra per alcune colonne (se è noto che il contenuto della cella non avrà mai bisogno di clipping).

Avvertenze:

1. Le misurazioni effettuate solo per iOS5 Safari (non ho profilo nessun altro browser).
2. Funziona per noi perché creiamo dinamicamente righe di tabella (l'elaborazione del tuo esempio utilizzando javascript sarebbe lenta?).
3. La maggior parte delle celle per i nostri dati non ha un overflow (il clipping è richiesto solo scarsamente - solo un numero limitato di celle).
4. Caricamento della pagina iniziale compromesso (la generazione della tabella nella pagina è passata da 80 ms a 800 ms).
5. Ma velocizza il popup combo dinamico (340 ms fino a 130 ms) per una reattività della tastiera molto migliore.

Nel suo caso, potrebbe essere veloce per primo utilizzando colonne larghezza variabile, misurare offsetWidth di tutte le colonne, modificando la larghezza delle colonne di larghezze di pixel e impostando overflow: hidden solo su colonne in cui offsetWidth di colonna è maggiore della larghezza di pixel userete per la colonna.

Answer 4

Webkit bug 75001 è correlato a questo problema e copre il lavoro svolto per risolverlo (vedere anche le dipendenze bugzilla per informazioni).