IE, неправильно представляющий динамический контент до изменения таблицы стилей, сделан
Используя функция фильтра :
$('*').filter(function() {
return $(this).css('float') == 'left';
});
Замена '*' с соответствующими селекторами для Вашего случая.
3 ответа
Не могу сказать наверняка без тестового примера, но в целом:
Убедитесь, что вы используете
table-layout: fixed. IE плохо угадывает ширину столбцовauto, особенно когда задействованы colspans. Также медленно угадывается ширина, когда рядов много. Уберите это из рук IE, установив явные размеры для каждого столбца с фиксированным макетом таблицы.Избегайте добавления строк в большие таблицы. Когда вы говорите
children (). AppendTo ()jQuery по-прежнему выполняет каждое добавление по одному, что вскоре действительно становится очень медленным. Лучшее, что вы можете сделать, чтобы ускорить манипуляции с таблицей, - это установить всю партию за один раз, используяinnerHTMLв родительском элементе таблицы. Конечно, подготовка HTML-строки может раздражать, если вы хотите вставить данные (значения атрибутов и контент), так как она должна быть экранирована HTML. Обходной путь - записать все строки сразу со значениями-заполнителями, а затем на втором проходе заполнить реальные данные, установив.dataв текстовых узлах и так далее. Вам также нужно будет повторно прикрепить все обработчики событий, которые вы добавляете к этим кнопкам на этом шаге, если вы не используете live.Я думаю, что, написав строки с помощью innerHTML, вы сможете достаточно ускорить его, чтобы избавиться от частичных обновлений на основе тайм-аута (которые, казалось бы, могут иметь неприятные потенциальные условия гонки). Конечно, альтернативой на основе DOM было бы обновление только тех строк, которые изменились. Когда вы используете фиксированный макет, поскольку ширина не зависит от содержимого, вы можете разбить таблицу на несколько таблиц друг за другом. Они будут выглядеть как одна таблица, но вы можете работать с каждой таблицей по отдельности, либо записывая ее innerHTML за один раз, либо добавляя ее строки без потери производительности DOM, которую вы получаете от тысячи строк в одной таблице.
You could just have two tbody elements in your primary table. One would be used for displaying, and the other for buffering. That way you could skip appending the other tbody and just remove display.none from the buffer to display it. My guess is that it could be a little faster and perhaps solve the glitch in IE.
An another method (trick?) for showing or hiding elements in a table I've learned is setting position to absolute on a row or tbody to hide it, instead of using display. That still hides it, but without altering (messing up) the table's layout. You could try using it to hide the buffer.
Generally, tables are one the most quirky elements there are, even in the modern browsers. Doing anything advanced with them usually leads to these little headaches, so good luck.
Have you got a width set on the table? It occurs to me that if you're generating the table while it's hidden it may not be picking up things like the current browser window width which it would normally use to set the width of a table, so it falls back to the maximum.