Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 67
Наркоман чтоли?
Если я правильно понял вашу задумку, ты вы в какой-то мере хотите повторить flexbox? Направляющие, раскладка блоков, отношения занимаемого пространства и т.д.
Не совсем. Как я понимаю, flexbox — помогает более удобно позиционировать блоки в css. Я же предлагаю позиционирование выполнять используя JavaScript, а css — оставить функцию оформления элементов, т.е. то ради чего он и был создан.
JavaScript позиционирование позволяет сделать очень гибкую, подстраивающуюся под ситуацию разметку, путем объявления достаточно простых «правил». При этом отсутствуют проблемы совместимости (вернее их учет ложиться на создателей движка, а не верстальщика).
При этом естественно я не предлагаю отказываться от css верстки. Предлагаемый инструмент только помогает реализовать некоторые вещи проще и быстрее, а степень его использования определяет верстальщик.
JavaScript позиционирование позволяет сделать очень гибкую, подстраивающуюся под ситуацию разметку, путем объявления достаточно простых «правил». При этом отсутствуют проблемы совместимости (вернее их учет ложиться на создателей движка, а не верстальщика).
При этом естественно я не предлагаю отказываться от css верстки. Предлагаемый инструмент только помогает реализовать некоторые вещи проще и быстрее, а степень его использования определяет верстальщик.
… а css — оставить функцию оформления элементов, т.е. то ради чего он и был создан.
Вы ошибаетесь. Позиционирование блоков — одна из исторически важных функций каскадных таблиц стилей.
css имеет свои недостатки — которые, к сожалению очень медленно исправляются в глобальном плане.
JS часто используется для исправления этих недостатков.
И такой мини-фреймворк предложенный Вами — может быть очень полезен.
Но чем дальше, тем CSS берет на себя все больше и больше нагрузки.
FlexBox, Multiple column layout уже близко.
Что то, например Grid Layout еще только в наметках, но это все значительно упростит решение различных проблем верстки.
Вообще web уже давным-давно — это такой сплав, гремучая смесь технологий, что пытаться четко разделить рамки использования той или иной технологии, думаю, не стоит.
JS часто используется для исправления этих недостатков.
И такой мини-фреймворк предложенный Вами — может быть очень полезен.
Но чем дальше, тем CSS берет на себя все больше и больше нагрузки.
FlexBox, Multiple column layout уже близко.
Что то, например Grid Layout еще только в наметках, но это все значительно упростит решение различных проблем верстки.
Вообще web уже давным-давно — это такой сплав, гремучая смесь технологий, что пытаться четко разделить рамки использования той или иной технологии, думаю, не стоит.
Не сомневаюсь что со временем CSS станет удобным и главное простым средством разметки. Даже уверен что это произойдет довольно скоро. Но сейчас многое в нем сложно и непонятно начинающим, что приводит к поискам на форумах кусков «на коленке» написанного JS-кода и сборка этого всего без особого понимания работы…
Во многом предлагаемый инструмент просто коллекция решений распространенных проблем верстки объединенный простым синтаксисом и с расширяемыми возможностями.
Это временное решение, для непрофессионалов в области верстки, которые и не слышали о технологиях о которых вы говорите.
Во многом предлагаемый инструмент просто коллекция решений распространенных проблем верстки объединенный простым синтаксисом и с расширяемыми возможностями.
Это временное решение, для непрофессионалов в области верстки, которые и не слышали о технологиях о которых вы говорите.
Вроде что-то в этом есть. Только вот если вам не нравится создавать это с помощью синтаксиса CSS, гораздо лучше используя определения в синтаксисе подобном тому что придумали вы, но производить основные манипуляции на стороне сервера. Как неплохой пример, генерить в результате CSS-файл.
Мне видится основное назначение инструмента не в верстке обычных сайтов, а в разнообразных приложениях, когда страница должна подстраиваться под пользователя, интерактивно меняться и т.п. Использование CSS для этих целей не очень эффективно.
В приложениях как раз таки узкое место производительность, т. к. приложения и так насыщены различным функционалом в JS. В таком случае всё же лучше выполнить основные тяжелые действия на стороне сервера. Часть функционала можно генерить в CSS (всё то, с чем справится современный CSS), а всё остальное в легковесный JS для максимальной производительности на стороне клиента.
Возможно вы правы. Но тут во первых теряется простота использования — нужен еще какой-то скрипт на сервере, т.е. начинающему верстальщику или даже дизайнеру который хочет посмотреть как будет тянуться его макет — это все становится куда сложнее.
А во-вторых — часть функций обычных приложений как раз может взять на себя этот движок, что соответственно снизит нагрузку.
А во-вторых — часть функций обычных приложений как раз может взять на себя этот движок, что соответственно снизит нагрузку.
Я с Вами полностью согласен. Даже MS это признала для своих WinJS приложений. Только они пошли как раз по пути «допиливания» css -ms-свойствами.
В других языках разметки же, это было из коробки
В других языках разметки же, это было из коробки
Имея не один год опыта в верстке сайтов, хочу поделится своим мнением:
1. Вам стоит подумать над «архитектурой» таблиц стилей
2. Именно благодаря своей «каскадности» добавление дополнительных стилей на страницу для разных устройств (раньше так делали для разных браузеров) куда эффективнее и существенно быстрее, чем манипуляции на сервере или клиенте для задания оных.
3. Не вижу препятствий для отделения классов которые отвечают за позиционирование от классов отвечающих за оформление.
1. Вам стоит подумать над «архитектурой» таблиц стилей
2. Именно благодаря своей «каскадности» добавление дополнительных стилей на страницу для разных устройств (раньше так делали для разных браузеров) куда эффективнее и существенно быстрее, чем манипуляции на сервере или клиенте для задания оных.
3. Не вижу препятствий для отделения классов которые отвечают за позиционирование от классов отвечающих за оформление.
В этом что-то есть от SASS/LESS
Stylus очень и очень хорош. Ближе по духу даже чем LESS и SASS. Но, блин, тут кто первый встал — того и тапки.
Ну, я о том, что LESS/SASS стали мейнстримом в тех или иных комьюнити, и даже стандартом де факто, поэтому незаслуженно и забывают про позже появившийся Stylus.
P.S. Про Jade согласен — он прекрасен, кто бы что ни говорил. И даже несмотря на скорость (включая runtime).
Я вообще сторонник CoffeeScript, Jade, Stylus. Очень нравится компактность и отсутствие шума в коде.
P.S. Про Jade согласен — он прекрасен, кто бы что ни говорил. И даже несмотря на скорость (включая runtime).
Я вообще сторонник CoffeeScript, Jade, Stylus. Очень нравится компактность и отсутствие шума в коде.
Кое-что из этого уже можно легко реализовать средствами CSS (особенно если правильно продумывать структуру), кое-что «вот-вот будет можно, когда ИЕ7-8-9 наконец умрут».
Некоторая «интересность» в вашей идее, безусловно, есть, но… как уже выше отметили, зачем? :)
Некоторая «интересность» в вашей идее, безусловно, есть, но… как уже выше отметили, зачем? :)
В CSS многое можно сделать если правильно продумывать структуру, иметь опыт верстки в несколько лет и т.п… Но всегда есть начинающие которым непросто прицепить подвал к низу страницы, или растянуть картинку для заполнения всего экрана.
Мне хочется дать непрофессионалу возможность написать несколько строк в понятном ему виде и знать получить хорошую понятную ему, кроссбраузерную верстку.
Понятно что это решение не для профессионалов. Они сами знают как решить свою конкретную задачу наиболее оптимально.
В начале статьи я написал что я дилетант. И я хочу помочь таким же дилетантам как я.
Мне хочется дать непрофессионалу возможность написать несколько строк в понятном ему виде и знать получить хорошую понятную ему, кроссбраузерную верстку.
Понятно что это решение не для профессионалов. Они сами знают как решить свою конкретную задачу наиболее оптимально.
В начале статьи я написал что я дилетант. И я хочу помочь таким же дилетантам как я.
Проблема даже не в том, что CSS в плане layout-а плох.
Проблема в том, что не видно пока хорошего универсального решения для layout-ов вообще. Гриды, например, не работают когда нужно на мониторах класть 3 элемента в ряд, а на телефонах — в столбец. Потом нужно учитывать что контент внутри может сам менять размер, например текст в зависимости от языка, и ценнее уместить текст чем выполнить ограничение в 80% ширины.
В этом деле вообще можно сильно загнаться, и докопать, например до такого матана как этот: «A Modular Geometric Constraint Solver for User Interface Applications», гуглится.
Но даже если ты найдешь универсальную мат. модель, реализуешь ее, будет ли это удобнее и понятнее для простых веб-разработчиков?
Проблема в том, что не видно пока хорошего универсального решения для layout-ов вообще. Гриды, например, не работают когда нужно на мониторах класть 3 элемента в ряд, а на телефонах — в столбец. Потом нужно учитывать что контент внутри может сам менять размер, например текст в зависимости от языка, и ценнее уместить текст чем выполнить ограничение в 80% ширины.
В этом деле вообще можно сильно загнаться, и докопать, например до такого матана как этот: «A Modular Geometric Constraint Solver for User Interface Applications», гуглится.
Но даже если ты найдешь универсальную мат. модель, реализуешь ее, будет ли это удобнее и понятнее для простых веб-разработчиков?
Спасибо за ссылку, буду изучать. Пока прокомментирую другие замечания.
В данном случае, можно было бы ввести дополнительные операторы, для автоматической ориентации блоков.
В статье есть описание реализации тянущихся блоков. Более сложные зависимости можно реализовать за счет «правил».
Этот момент меня тоже волнует. Я старался делать систему максимально простой, чтобы даже зная 10% синтаксиса — можно было ее полезно применять.
Повторюсь — эта система для простых сайтов. Чтобы можно было написать
Гриды, например, не работают когда нужно на мониторах класть 3 элемента в ряд, а на телефонах — в столбец.
В данном случае, можно было бы ввести дополнительные операторы, для автоматической ориентации блоков.
Потом нужно учитывать что контент внутри может сам менять размер, например текст в зависимости от языка, и ценнее уместить текст чем выполнить ограничение в 80% ширины.
В статье есть описание реализации тянущихся блоков. Более сложные зависимости можно реализовать за счет «правил».
Но даже если ты найдешь универсальную мат. модель, реализуешь ее, будет ли это удобнее и понятнее для простых веб-разработчиков?
Этот момент меня тоже волнует. Я старался делать систему максимально простой, чтобы даже зная 10% синтаксиса — можно было ее полезно применять.
Повторюсь — эта система для простых сайтов. Чтобы можно было написать
block.my_div='center middle'; — и знать что этот блок будет по центру экрана.Ну добавят опции в гриды чтобы из линии в стопочку переставлять — захочется чего-нибудь еще эдакого. Например есть сайт, на нем блоки с каким-то количеством модулей слева и справа. И вот хочется чтобы модули эти брали высоту от контента, но при этом автоматически выравнивали нижнюю и верхнюю границу по 20-ти пиксельной сетке.
Я же вообще абстрактно писал что проблема не в CSS, проблема в том что автоматизация layout-а — это не решенная (и видимо не решаемая) задача. Посмотри как тот же вон как схему метро раскладывают — это же тоже задача по layout-у в конечном итоге, как такое автоматизировать?
Я же вообще абстрактно писал что проблема не в CSS, проблема в том что автоматизация layout-а — это не решенная (и видимо не решаемая) задача. Посмотри как тот же вон как схему метро раскладывают — это же тоже задача по layout-у в конечном итоге, как такое автоматизировать?
Как верстка у Вас будет «знать», что на телефоне Вам нужно раполагать элементы не по три в ряд а по одному? Об этом должен заботиться верстальщик.
Верстальщику нужно дать удобный инструмент, чтобы сказать когда ставить в ряд, а когда — нет. Можно явно, типа: «ниже такого-то разрешения ставь в ряд», можно — более декларативно, типа «вот эти элементы лучше в ряд, но не обязательно», можно придумать еще более хитрую систему взаимосвязей. Речь собственно об этом.
Гриды, например, не работают когда нужно на мониторах класть 3 элемента в ряд, а на телефонах —в столбец.
Откройте для себя media queries и не позорьтесь.
Постойте. Я это уже видел!
Это же expression в IE.
Идея хороша, но надо очень много работать над оптимизацией расчетов значений свойств.
Это же expression в IE.
Идея хороша, но надо очень много работать над оптимизацией расчетов значений свойств.
Идея занимательная и интересная, мне понравилась.
Но реализовывать это надо на стороне браузера, ибо даже ресайз блока по событию ресайза браузера подтормаживает.
Но реализовывать это надо на стороне браузера, ибо даже ресайз блока по событию ресайза браузера подтормаживает.
Всё это может и удобно, но какова будет скорость работы?.
К примеру:
Представьте процесс загрузки основного контента сайта на медленном соединении.
При реализации с помощью css замедляется в основном загрузка изображений, но они уже позиционируются на своём месте. А в данном случае не только будет замедление в зазрузке изображений, но и в расчётке координат всего на странице. У вас появится почти белый лист и на нём постепенно будут двигаться блоки на свои места.
Это сугубо моё мнение, т.к. сталкивался с такими вещами даже на вычислении размеров блоков на странице. После нескольких перезагрузок страницы замечаешь эффект, подобный slideDown…
К примеру:
Представьте процесс загрузки основного контента сайта на медленном соединении.
При реализации с помощью css замедляется в основном загрузка изображений, но они уже позиционируются на своём месте. А в данном случае не только будет замедление в зазрузке изображений, но и в расчётке координат всего на странице. У вас появится почти белый лист и на нём постепенно будут двигаться блоки на свои места.
Это сугубо моё мнение, т.к. сталкивался с такими вещами даже на вычислении размеров блоков на странице. После нескольких перезагрузок страницы замечаешь эффект, подобный slideDown…
Возможно я не прав, но как медленное соединение будет в данном случае влиять на отрисовку? Код движка не будет большим и загрузится только раз, после чего пока грузится html — скрипт успеет отработать и определить положение основных div блоков. Загружавшиеся картинки уже будут правильно позиционироваться. Потом сдвиги будут только в случае если где-то контент не влезет в блок.
Конечно при сложном макете полностью сверстанном в этой технологии — многократная перерисовка возможна (зависит от того насколько удачна будет реализация), Но я изначально ориентировался не на замену верстки, а на реализацию вещей которые в css делать сложно и неудобно. Т.е. на то что уже сейчас делается часто средствами JavaScript.
Конечно при сложном макете полностью сверстанном в этой технологии — многократная перерисовка возможна (зависит от того насколько удачна будет реализация), Но я изначально ориентировался не на замену верстки, а на реализацию вещей которые в css делать сложно и неудобно. Т.е. на то что уже сейчас делается часто средствами JavaScript.
Возможно, с картинками привёл неудачный пример.
В маленьком проекте данная технология вполне может быть применима, а в большом проекте большое количество скрипта. На его загрузку также потребуется время, отсюда соответственно и задержки в необходимом позиционировании и вычислении размеров.
Ни в коем случае не говорю о том, что данная технология не имеет права на существование. Но сам как можно меньше стараюсь использовать скрипта для определения размеров блоков при загрузке страниц…
В маленьком проекте данная технология вполне может быть применима, а в большом проекте большое количество скрипта. На его загрузку также потребуется время, отсюда соответственно и задержки в необходимом позиционировании и вычислении размеров.
Ни в коем случае не говорю о том, что данная технология не имеет права на существование. Но сам как можно меньше стараюсь использовать скрипта для определения размеров блоков при загрузке страниц…
В идеале хотелось бы создать некий «мини-язык» упрощающий возможности разметки документа для человека не являющегося специалистом в JavaScript. В таком «мини-языке» можно было бы максимально просто сформулировать правила адаптации макета к любому разрешению экрана. А JavaScript обеспечил бы выполнение этих правил.
Было уже, выпилили.
Как я понимаю это было только в IE. Конечно использовать разный подход к верстке для разных браузеров — не лучшее решение.
У них была идея, схожая с вашей. Вместо задания CSS свойства константой, была возможность использовать JS-выражения в том же констексте, для динамического вычисления свойств в рантайме. Как я понимаю, было даже автоматическое пере-вычисление при изменении других CSS свойств, чьи значения использовались при вычислении.
Поскольку вы предлагаете что-то похожее, я считаю вам надо ознакомиться с этим подходом и понять причины неудачи.
Поскольку вы предлагаете что-то похожее, я считаю вам надо ознакомиться с этим подходом и понять причины неудачи.
Как то нехорошо пользователей с отключенным js отсекать.
С отключенным js большинство «фишек» ради которых есть смысл использовать этот подход — по любому не будут работать.
А чем media queries для адаптации под разные разрешения не устроил?
Вероятно потому, что:
И:
При обычной верстке html – задает структуру контента, а css – управляет и позиционированием и визуальным представлением документа. Эта двойственность css приводит к раздутым файлам стилей, внутри которых бывает сложно ориентироваться. Одни и те же свойства управляют и положением и внешним видом элементов – это вносит путаницу и затрудняет отладку.
И:
При этом естественно я не предлагаю отказываться от css верстки. Предлагаемый инструмент только помогает реализовать некоторые вещи проще и быстрее, а степень его использования определяет верстальщик.
Все ждал когда же здесь скажут 'а что если у пользователя Javascript отключен'.
Дежавю какое-то :) лет 10 назад, нечто похожее городил на одном из проектов (JS-сом блоки расставлял), но тогда была веская причина — реализация CSS.
elasticss.com/
Там тоже частично js для позиционирования.
Там тоже частично js для позиционирования.
Забавно, но чем для решения всего описанного не подходит CSS? У одного свойства display уже множество значений (новомодная модель Flexbox чего только стоит...). + функция calc поможет складывать различные величины из вашего примера. К чему все эти велосипеды? Ведь их тоже нужно будет понимать, дабы применять. Так не лучше ли начать читать пособия, да спецификации?
Напомнило SproutCore до Handlebars.
Я думаю дело не в косости CSS, а в том, что HTML не предназначался для таких UIшных вещей. Тут нужен язык разметки другой со своими правилами и скрипт, который будет всё это под браузер адаптировать.
Вот что бывает, когда программисты начинают верстать ;) Думаю, куда более релевантным занятием было бы создание библиотеки, эмулирующую Flexbox для браузеров его не поддерживающих.
идея интересная, мне нравится, возможно, если позволит время, даже попробую ее реализовать в текущем проекте.
Теперь чтобы сверстать сайт, а потом и что-то в нем изменить, нужно будет иметь специалиста по css, специалиста по js и специалиста по вашему придуманному движку.
Мне кажется с такими идеями можна дойти до отдельного языка по оформлению текста, тдельного для блоков и например для изображений и для работы со всем этим пригнать сюда вагон индусов
Мне кажется с такими идеями можна дойти до отдельного языка по оформлению текста, тдельного для блоков и например для изображений и для работы со всем этим пригнать сюда вагон индусов
посмотрите в сторону dojo (dijit layout)
там возможна как декларативная верстка (в конечном итоге размеры и позиция автоматически (и динамически) вычисляются в абсолютных значениях)
либо программная
там возможна как декларативная верстка (в конечном итоге размеры и позиция автоматически (и динамически) вычисляются в абсолютных значениях)
<div data-dojo-type="dijit/layout/BorderContainer" data-dojo-props="gutters:false, liveSplitters:false" style="width: 100%; height: 100%;">
<div data-dojo-type="dijit/layout/ContentPane" data-dojo-props="splitter:false, region:'top'" id="header">
</div>
<div data-dojo-type="dijit/layout/ContentPane" data-dojo-props="splitter:false, region:'center'" id="main_content">
</div>
</div>
либо программная
new dijit.layout.BorderContainer().placeAt('bc');
...
JSSS же
Сам давно думаю в эту сторону. Однако подход с направляющими меня смущает: при более-менее сложной системе получится, что направляющих будет ооочень много. К тому же поддерживать верстку в таком виде, как мне кажется, достаточно проблематично. Лучше посмотреть в сторону аналогичных идей в настольных приложениях: layout-менеджеры, с возможностью вложения друг в друга. Это во-первых похоже на ныне существующую вложенную структуру блоков html, и в то же время убирает необходимость «визуально-размещательной» части верстки (весь функционал переносится в код layout-менеджера).
Я считаю — очень правильная мысль. Многие вещи в вебе вообще «скрипто-центрированы», декларативная разметка в чистом виде применяется, пожалуй, даже реже, чем «процедурная смесь технологий». Вообще предлагаю — давайте браузер первым делом пусть загружает index.js файл, который, если потребуется — загружает внешние ресурсы типа html, css, картинок и т.п. А не наоборот. Это сразу целую пачку проблем решит.
Немного удивлен, не увидев тут в обсуждении bootstrap
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли о верстке с JavaScript позиционированием