Комментарии 38
А чем плох вариант справа? Не Web 2.0? По мне так инфа на левой картинке теряется в белизне и пространстве. Вспомните историю торгового терминала Bloomberg, он недалеко ушёл от правой картинки. Но он такой по определённым причинам и он эффективен в том, для чего создавался.
Наступили на мой больной мозоль. Тема с таблицами в вебе — без слез не взглянешь! (с)
Что бы сделать банальную вещь, например фиксированный заголовок — в браузерах поддержки нет от слова совсем! Казалось бы… Что бы достичь желаемого результата — приходится применять костыли и грязные хаки.
К слову я не видел рабочей версии фиксированого многорядного заголовка где есть обьеденение колонок в первом ряду и сабколонки во втором ряду (rowspan / colspan)
Тоже самое относится к фиксированию первой кологки. А если хочется и фиксиорванный заголовок и фиксированную колонку — так это уже из области фантастики, ну или надо обмазатся хаками более чем полностью, и то, будет работать лишь в лимитированном сете данных…
TL;DR: я очень расстроен текущим положением дел с веб талицами
Что бы сделать банальную вещь, например фиксированный заголовок — в браузерах поддержки нет от слова совсем! Казалось бы… Что бы достичь желаемого результата — приходится применять костыли и грязные хаки.
К слову я не видел рабочей версии фиксированого многорядного заголовка где есть обьеденение колонок в первом ряду и сабколонки во втором ряду (rowspan / colspan)
Тоже самое относится к фиксированию первой кологки. А если хочется и фиксиорванный заголовок и фиксированную колонку — так это уже из области фантастики, ну или надо обмазатся хаками более чем полностью, и то, будет работать лишь в лимитированном сете данных…
TL;DR: я очень расстроен текущим положением дел с веб талицами
position: sticky для ячеек заголовка.
Следующий уровень, сделать фиксацию ДВУХ строк :)
Таким образом можно фиксировать любые ячейки, хоть из середины таблицы. Только top и left надо правильные выставлять.
position: sticky не работает на произвольном наборе данных, т.е для каких-то динамических данных не годится. Возможно я не правильно его «готовил», но у меня не получилось заставить это работать на приемлимом уровне. Плюс, насколько я помню, там нужно наперед знать сколько колонок будет в таблице что бы правильно ширину расставить для каждой колонки, хотя могу ошибаться
Вот то-то и оно. Для первой строки дефолтного «top:0» хватает просто так, прописал «position: sticky», и оно работрает. А для всех следующих срок надо гемороиться или с высчитыванием отступов или с перекладыванием в отдельный фиксированный контейнер.
Только если для вас критична поддержка IE.
Я не про IE, а про количество сносок вида «в X не поддерживается на элементах A, B, C».
Для ячеек поддерживается везде.
Закреплять области таблицы по отдельным ячейкам — ничем не лучше, чем «возьму-ка я JS и быстренько там буду сопоставлять скролл». Количество действий «вручную» и там и там остаётся большим.
th { position: sticky }
thead > tr > th { height : 2rem }
thead > tr:nth-child(0) > th { top : 0 }
thead > tr:nth-child(1) > th { top : 2rem }
thead > tr:nth-child(2) > th { top : 4rem }Я аж вспотел от этих действий…
Ну если вам нравится переписывать стили под каждый конкретный случай таблицы — то норм, да. И высоту можно подогнать, и :nth-child набить, сколько нужно.
А если в проекте таблиц 50 с разными стилями — можно под это выделить еженедельное время. А если проектов таких несколько штук — человека нанять, чтоб он стили для sticky подгонял. Всё решаемо!
А если в проекте таблиц 50 с разными стилями — можно под это выделить еженедельное время. А если проектов таких несколько штук — человека нанять, чтоб он стили для sticky подгонял. Всё решаемо!
Придётся аж вынести эти константы в переменные. На это нужен отдельный человек. А лучше отдел.
Ну да, если вынесем в переменные — то сразу же высота станет сама подбираться, да и количество разных случаев уменьшится.
Или нет.
А еще можно вспомнить про то, что фиксировать иногда надо не только заголовок, а еще левую колонку. Или левые колонки. Но конечно же можно пойти и зафиксировать ширину, да?
PS: Мне интересно, вы всерьез считаете, что фиксация высоты вручную в общем случае принципиально лучше кода на JS, скроллящего один блок в связке со вторым?
Или нет.
А еще можно вспомнить про то, что фиксировать иногда надо не только заголовок, а еще левую колонку. Или левые колонки. Но конечно же можно пойти и зафиксировать ширину, да?
PS: Мне интересно, вы всерьез считаете, что фиксация высоты вручную в общем случае принципиально лучше кода на JS, скроллящего один блок в связке со вторым?
codepen.io/deamondz/pen/MWWPvZL
я тут набросал небольшое демо. На хроме под убунту (может где-то ещё, пока нет возможности проверить) при скролле пропадают бордеры на ячейках, и иногда между ячейками видно содержимое других ячеек, не подскажите как это побороть?
я тут набросал небольшое демо. На хроме под убунту (может где-то ещё, пока нет возможности проверить) при скролле пропадают бордеры на ячейках, и иногда между ячейками видно содержимое других ячеек, не подскажите как это побороть?
Как вам такое Complex Ant table
Спасибо что поделились. Не знал про этот фреймворк, выглядит достойно.
По поводу хаков и лимитированных сетов данных я имел ввиду это:
Ряд по высоте не совпадает с высотой в фиксированных колонках
По поводу хаков и лимитированных сетов данных я имел ввиду это:
Ряд по высоте не совпадает с высотой в фиксированных колонках
Да вижу, в этом случае нужно просто ширину указать в колонках (column width). Ну и поиграться с шириной скролла для таблицы. Но всё равно немножко криво выходит stackblitz.com/edit/react-ljbsoh
Я сознательно выбрал строгий брутальный стиль для макетов, чтобы мы могли сосредоточиться на функциональности, а не на внешности.
А получилось очень симпатично и приятно, в отличие от скруглённой мерзости, заполонившей буквально все интерфейсы.
НЛО прилетело и опубликовало эту надпись здесь
Получился несколько старомодный вариант. В современных интерфейсах по возможности прячут все, что можно спрятать до наведения или клика на элемент. Например, переключатели Status справа могли бы появляться только при наведении и не отъедать довольно широкую колонку.
Чтобы понимать статус переключателя без наведения, надо подобрать грамотное цветовое решение. То же самое относится к галочкам слева и иконкам действий над таблицей.
Так же, цветами (или, например, просто цветным уголком) можно обозначать редактируемые элементы, чтобы избавиться от лишних рамочек. Единицы измерения могут идти через запятую после заголовка, чтобы не отъедать место по вертикали.
Ну и строки стоит прорисовывать линиями, а без линий столбцов очень часто можно обойтись, если данные хорошо выравниваться и образуют и без того визуально понятную вертикаль.
Пользовался оригиналом статьи для реализации сложной, редактируемой таблицы в рабочем проекте на Ангуляре. Многие советы отсюда сэкономили львиную часть времени.
Я сделал граф для своего набора возможных полей, со всеми вариантами взаимодействия. Дорисовал UI там где его не хватало и всё это чудо завелось, хоть и с небольшими тормозами. Вот список того, о чём возможно, предстоит знать, когда сталкиваешься с такой задачей:
Когда видел эту статью в первый раз, то чертовски захотелось реализовать все эти крутые идеи в виде готового модуля. Но после того как начинаешь пользоваться чужими наработками, быстро понимаешь, что тут ещё копать и копать в плане исследования самих таблиц и удобства их использования
Я сделал граф для своего набора возможных полей, со всеми вариантами взаимодействия. Дорисовал UI там где его не хватало и всё это чудо завелось, хоть и с небольшими тормозами. Вот список того, о чём возможно, предстоит знать, когда сталкиваешься с такой задачей:
- Фиксированные колонки – истинное зло, когда в них или в соседних к ним появляется большое количество dom-элементов. В случае, когда необходимо редактирование прямо в строке со всеми вытекающими, лучше будет высчитывать не позицию скролла строк. Рендерить миллионы раз тысячи дочерних элементов изменяя transform: translate3d(...) – не самая легкая работа. Упростить задачу можно перевернув таблицу. Если во многих готовых проектах делают таблицу построчно, то в таком случае, возможно, поможет колоночная таблица. Высчитывать только высоту ячеек и выставлять их при инициализации, а ререндер будет только при изменениях в контенте. Можно будет отцепиться от скролла и дать браузеру выдохнуть(не проверенная инфа, только начал этим заниматься)
- Редактирование прямо в строке выглядит удобно и работает быстро до тех пор, пока колонок меньше 10, а строк меньше 20. Поэтому первым из решений по оптимизации было замена сразу проинициализированных инпутов, селектов, чекбоксов и всех остальных элементов ввода на их имитацию. Выглядели и вели себя они так же, но включались только после клика. Селекты начинали подтягивать значения с бэка, календарь выпадал и выставлял дату из заданного значения и т.д. Тем самым количество dom-элементов в самой таблице значительно снизилось, но усложнился процесс создания самих этих полей для ввода. Много мороки было с автофокусом, невалидными данными, универсализацией и общением с бэкендом.
Когда видел эту статью в первый раз, то чертовски захотелось реализовать все эти крутые идеи в виде готового модуля. Но после того как начинаешь пользоваться чужими наработками, быстро понимаешь, что тут ещё копать и копать в плане исследования самих таблиц и удобства их использования
Рендерить миллионы раз тысячи дочерних элементов изменяя transform: translate3d(...)
Вы что, участвовали в соревновании «как сделать программный скролл максимально медленным способом»? Или у вас scrollLeft/scrollTop под запретом?
В случае простой таблицы, без горизонтального скролла, фиксированных столбцов и строк — вы правы. Собственно про это я и говорю. Что если бы была возможность оптимизировать это избавившись от transform, то было бы супер
Сложная таблица делится на кусочки (с точки зрения DOM), скроллящиеся синхронно. Свести редактирование кусков таблицы в одно, чтоб пользователь (а так же screenreader и тэ дэ) ничего не заметил — задача довольно простая, особенно если учесть, что на «большие сложные таблицы» всё равно как правило нужно навешивать много кастомизации, от простой копипасты из таблицы до tabIndex.
А не пробовали разделить отображение и редактирование? Например, как тут: https://mol.js.org/app/calc/
Рассматривал такой подход, пользователям ранее пользовавшимся только экселем это было бы очень удобно.
Но целью было создание таких таблиц, которые будут удобнее, шустрее и гибче. В основном это касалось того, что не всегда было понятно какие столбцы можно редактировать, какие из них обязательные для заполнения. Разделить отображение и редактирование — это круто и быстро работает, но пользователи не хотят второй эксель
Но целью было создание таких таблиц, которые будут удобнее, шустрее и гибче. В основном это касалось того, что не всегда было понятно какие столбцы можно редактировать, какие из них обязательные для заполнения. Разделить отображение и редактирование — это круто и быстро работает, но пользователи не хотят второй эксель
Вы уж определитесь, либо они хотят таблицы, либо не хотят эксель. В экселе, кстати, есть инплейс редактирование, но инплейс редактировать часто не удобно, поэтому и есть отдельный от таблицы редактор.
Можно называть таблицей всё что выглядит как таблица. Эксель это универсальное средство, соответственно его нужно под себя донастраивать в любом случае. Расставлять форматирование, писать макросы, подгонять имеющиеся интеграции.
Много кто начинает деятельность имея вместо БД всего пару листов в гугл-доках. Когда возрастает сложность, тогда и начинают делать именно заточенное под редактирование типизированных данных свою платформу. Про них я и говорю. Многие пользователи привыкли к строчке вверху для редактирования, необходимости писать макросы и создавать свои форматы. Но если за пользователя это сделает пара программистов — обратно в эксель он не пойдет
Много кто начинает деятельность имея вместо БД всего пару листов в гугл-доках. Когда возрастает сложность, тогда и начинают делать именно заточенное под редактирование типизированных данных свою платформу. Про них я и говорю. Многие пользователи привыкли к строчке вверху для редактирования, необходимости писать макросы и создавать свои форматы. Но если за пользователя это сделает пара программистов — обратно в эксель он не пойдет
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проектировать большие и сложные веб-таблицы