Можно называть таблицей всё что выглядит как таблица. Эксель это универсальное средство, соответственно его нужно под себя донастраивать в любом случае. Расставлять форматирование, писать макросы, подгонять имеющиеся интеграции.
Много кто начинает деятельность имея вместо БД всего пару листов в гугл-доках. Когда возрастает сложность, тогда и начинают делать именно заточенное под редактирование типизированных данных свою платформу. Про них я и говорю. Многие пользователи привыкли к строчке вверху для редактирования, необходимости писать макросы и создавать свои форматы. Но если за пользователя это сделает пара программистов — обратно в эксель он не пойдет
Рассматривал такой подход, пользователям ранее пользовавшимся только экселем это было бы очень удобно.
Но целью было создание таких таблиц, которые будут удобнее, шустрее и гибче. В основном это касалось того, что не всегда было понятно какие столбцы можно редактировать, какие из них обязательные для заполнения. Разделить отображение и редактирование — это круто и быстро работает, но пользователи не хотят второй эксель
В случае простой таблицы, без горизонтального скролла, фиксированных столбцов и строк — вы правы. Собственно про это я и говорю. Что если бы была возможность оптимизировать это избавившись от transform, то было бы супер
Пользовался оригиналом статьи для реализации сложной, редактируемой таблицы в рабочем проекте на Ангуляре. Многие советы отсюда сэкономили львиную часть времени.
Я сделал граф для своего набора возможных полей, со всеми вариантами взаимодействия. Дорисовал UI там где его не хватало и всё это чудо завелось, хоть и с небольшими тормозами. Вот список того, о чём возможно, предстоит знать, когда сталкиваешься с такой задачей:
Фиксированные колонки – истинное зло, когда в них или в соседних к ним появляется большое количество dom-элементов. В случае, когда необходимо редактирование прямо в строке со всеми вытекающими, лучше будет высчитывать не позицию скролла строк. Рендерить миллионы раз тысячи дочерних элементов изменяя transform: translate3d(...) – не самая легкая работа. Упростить задачу можно перевернув таблицу. Если во многих готовых проектах делают таблицу построчно, то в таком случае, возможно, поможет колоночная таблица. Высчитывать только высоту ячеек и выставлять их при инициализации, а ререндер будет только при изменениях в контенте. Можно будет отцепиться от скролла и дать браузеру выдохнуть(не проверенная инфа, только начал этим заниматься)
Редактирование прямо в строке выглядит удобно и работает быстро до тех пор, пока колонок меньше 10, а строк меньше 20. Поэтому первым из решений по оптимизации было замена сразу проинициализированных инпутов, селектов, чекбоксов и всех остальных элементов ввода на их имитацию. Выглядели и вели себя они так же, но включались только после клика. Селекты начинали подтягивать значения с бэка, календарь выпадал и выставлял дату из заданного значения и т.д. Тем самым количество dom-элементов в самой таблице значительно снизилось, но усложнился процесс создания самих этих полей для ввода. Много мороки было с автофокусом, невалидными данными, универсализацией и общением с бэкендом.
Когда видел эту статью в первый раз, то чертовски захотелось реализовать все эти крутые идеи в виде готового модуля. Но после того как начинаешь пользоваться чужими наработками, быстро понимаешь, что тут ещё копать и копать в плане исследования самих таблиц и удобства их использования
Разница в отношении дробей. Измени сетку с 12 на 16-колоночную, у тебя как была одна вторая, так она и останется. А с типичной придётся переписывать все вхождения .col
Меня с самого первого момента появления сеток удручала во float необходимость пользоваться clearfix.
Сетка на inline-block действительно хороша. Большинство тут восклицает о том, что пробельный символ будет мешать и фиксы с размером шрифта не идеальны. Так и есть. Но ведь достаточно просто сжимать html? Если сейчас ещё кто-то не пользуется препроцессорами для html, то уж минификаторы то смогут освоить. И пробельные символы больше никогда не помешают. На фрилансе, конечно, приходится объяснять заказчику, что минификация обязательна. Но из моей практики — никто не возражал и даже радовался тому, что html-ка весит на один-два килобайта меньше.
Единственное, что меня коробит — почему все до сих пор пользуются фиксированным количеством колонок? Один небольшой mixin и можно организовать сетку на дробях. С классами вида: .col-1-2, .col-2-10. Несомненно, классов будет чуть больше, но в целях универсальности и расширяемости это круто, когда ты можешь задать любые пропорции. Частенько радовали ребята, которые брали бутстраповскую сетку на 16 колонок и пытались через неё организовать три равных блока по ширине после того, как в дизайне неожиданно они появились. Извращения с вложениями колонок друг в друга или дополнительные классы с паддингами. Сплошное веселье.
Я пользуюсь чем-то подобным:
.row-el
display: block
> [class^='col-']
display: inline-block
vertical-align: top
&.row-middle
> [class^='col-']
vertical-align: middle
.row-el
@for $a from 1 through $column-count
@for $b from 1 through $a
@if $a != $b or ($a == 1 and $b == 1)
$result: 100% / $a * $b
> .col-#{$b}-#{$a}
width: $result
Цепочка из else в коде скрипта выглядит потрясающе. Особенно если представлять, что человек это написал ссылаясь на удобство, но тем самым добавив звено между html — link to css — обработка браузером. Теперь это html — jQuery — ornajs — inline css — обработка браузером.
Хотя если бы это было как часть препроцессора для html. Если бы в jade в классы писались свойства, а css генерировался исходя из этих классов, то может быть что-то более-менее адекватное получилось бы, но верится, все равно, с трудом.
Много кто начинает деятельность имея вместо БД всего пару листов в гугл-доках. Когда возрастает сложность, тогда и начинают делать именно заточенное под редактирование типизированных данных свою платформу. Про них я и говорю. Многие пользователи привыкли к строчке вверху для редактирования, необходимости писать макросы и создавать свои форматы. Но если за пользователя это сделает пара программистов — обратно в эксель он не пойдет
Но целью было создание таких таблиц, которые будут удобнее, шустрее и гибче. В основном это касалось того, что не всегда было понятно какие столбцы можно редактировать, какие из них обязательные для заполнения. Разделить отображение и редактирование — это круто и быстро работает, но пользователи не хотят второй эксель
Я сделал граф для своего набора возможных полей, со всеми вариантами взаимодействия. Дорисовал UI там где его не хватало и всё это чудо завелось, хоть и с небольшими тормозами. Вот список того, о чём возможно, предстоит знать, когда сталкиваешься с такой задачей:
Когда видел эту статью в первый раз, то чертовски захотелось реализовать все эти крутые идеи в виде готового модуля. Но после того как начинаешь пользоваться чужими наработками, быстро понимаешь, что тут ещё копать и копать в плане исследования самих таблиц и удобства их использования
Сетка на inline-block действительно хороша. Большинство тут восклицает о том, что пробельный символ будет мешать и фиксы с размером шрифта не идеальны. Так и есть. Но ведь достаточно просто сжимать html? Если сейчас ещё кто-то не пользуется препроцессорами для html, то уж минификаторы то смогут освоить. И пробельные символы больше никогда не помешают. На фрилансе, конечно, приходится объяснять заказчику, что минификация обязательна. Но из моей практики — никто не возражал и даже радовался тому, что html-ка весит на один-два килобайта меньше.
Единственное, что меня коробит — почему все до сих пор пользуются фиксированным количеством колонок? Один небольшой mixin и можно организовать сетку на дробях. С классами вида: .col-1-2, .col-2-10. Несомненно, классов будет чуть больше, но в целях универсальности и расширяемости это круто, когда ты можешь задать любые пропорции. Частенько радовали ребята, которые брали бутстраповскую сетку на 16 колонок и пытались через неё организовать три равных блока по ширине после того, как в дизайне неожиданно они появились. Извращения с вложениями колонок друг в друга или дополнительные классы с паддингами. Сплошное веселье.
Я пользуюсь чем-то подобным:
Хотя если бы это было как часть препроцессора для html. Если бы в jade в классы писались свойства, а css генерировался исходя из этих классов, то может быть что-то более-менее адекватное получилось бы, но верится, все равно, с трудом.