Скажите, а как сделать простую резиновую верстку? Если класть фиксированные макеты в браузер, это отбросит вопросы у заказчика?
И поясните, о каких свистоперделках и скролле вы говорите?
Можно вам несколько предложений по present-tpl?
— Во-первых, сделайте слой BG через pattern-layer: это уменьшит объем файла, позволит элементарно сменить фон (на любой из subtlepatterns.com, к примеру), позволит позаимствовать ваш чудный фон для других проектов.
— Во-вторых, налогооблагает то, что вы линии-разделители «line» сделали через растровый слой, а не через fill-layer или text layer. Это несет те же недостатки.
— Слой greenline: почему он черный fill-layer, а не gradient-layer? В том виде, в котором вы его использовали это не самый удобный для кастомизации вариант.
— Ну и сафари. Кому-то может и по нраву, но насколько вы делаете этот макет паблик, настолько должны быть возможности кастомизации под другие броузеры.
Так что к сожалению, пока что макет дальше от моей конечной цели, чем пустой документ того же разрешения.
БЭМ лечит только неконкретность, сводя глубину к единице. Число селекторов, однако, разрастается до числа элементов (не из БЭМ, а N из статьи). Это действительно может до нескольких раз облегчить выборку по селектору. Но в динамике, как и замечено в статье, ситуация не поменяется, а именно она часто наиболее наглядна.
Плюс некоторые классы все равно хочется сделать общими.
Большое спасибо за разъяснения. Недавно столкнулся с этим наглядно. В последнем проекте на перетаскивании шла проверка пересечений. Элементу, если он доступен для drop, присваивался класс highlighted. Body также был доступен для drop, и ему периодически присваивался/отнимался класс highlighted, что вызывало заметный лаг. Когда body перестали присваивать класс, все пошло заметно шустрее, но главное не была понятна причина — казалось бы, лишь класс. Теперь все ясно.
Хм. Поставил возможные for'ы на макросы в нетбинсе и как-то проблем не испытываю.
«for (var i = 0; i < .length; i++){» insert-break
«for (var i = .length; i--;){» insert-break
Большим это каким? Пробовал разные размеры сенсорных ноутбуков, у самого 12-дюймовый. Работать удобно, если софт хороший. С планшетом же удобно вам работать?
Может более 17 дюймов действительно неудобно — кто знает. Но это уже ни в коей мере не довод против пальцеориентированности, — речь не об отказе от десктопов.
Ловко вы межуете. Только говорить о win8 «сейчас», безотносительно тенденций, не имеет никакого смысла. Лет через N, когда у существенной аудитории будут сенсорные экраны, все эти ваши (не только лично ваши) препирания обнаружат вам свою близорукость, которая в свете подавляющего веса мнения пользователей настольных компьютеров сейчас выглядит правой.
Неверность фразы вы обосновали тем, что вам удобно?
Даже если так, вы придираетесь к словам. Сенсорные средства ввода уж точно не менее важны, чем мышь.
Я не пойму, за что минусы? Вы пробовали win7 на сенсорном ноутбуке? Невероятно сложно, порой просто невозможно в нем работать. Под сенсорные ноуты вообще сейчас не существует полноценных удобных систем. Пальцеориентированные элементы, даже в скупом их количестве win8 developer preview демонстрируют невероятное удобство по сравнению с предшественником. Я не в курсе точной идеологии нового интерфейса, но ваш аргумент «мне надоел этот планшетный фетишизм» — чепуха.
Прекрасная, наглядная аналогия!
Из неё можно было бы извлечь больше пользы, если перечислить еще некоторые операции по времени выполнения. К примеру, какие-то действия выполняются секунды, как сравнение, или арифметика, а какие-то — задачи на годы, как сортировки или сложные процедуры. Ведь в процессе программирования этот вес обезличивается, порой не понимаешь, не слишком ли это тяжелая процедура, чтобы помещать её в mousemove событие. Все обозначается некоторым набором символов.
Также это событие mousemove (вообще прерывание) — с каким периодом в этих мелких масштабах оно срабатывает? Раз в год? Раз в десятилетие? Или раз в месяц?
В общем можно было бы более ясно дать понять, что стоит оптимизации, а что нет. К примеру, многие операции сравнения в условных операторах не стоят оптимизации.
И поясните, о каких свистоперделках и скролле вы говорите?
— Во-первых, сделайте слой BG через pattern-layer: это уменьшит объем файла, позволит элементарно сменить фон (на любой из subtlepatterns.com, к примеру), позволит позаимствовать ваш чудный фон для других проектов.
— Во-вторых, налогооблагает то, что вы линии-разделители «line» сделали через растровый слой, а не через fill-layer или text layer. Это несет те же недостатки.
— Слой greenline: почему он черный fill-layer, а не gradient-layer? В том виде, в котором вы его использовали это не самый удобный для кастомизации вариант.
— Ну и сафари. Кому-то может и по нраву, но насколько вы делаете этот макет паблик, настолько должны быть возможности кастомизации под другие броузеры.
Так что к сожалению, пока что макет дальше от моей конечной цели, чем пустой документ того же разрешения.
Плюс некоторые классы все равно хочется сделать общими.
«for (var i = 0; i < .length; i++){» insert-break
«for (var i = .length; i--;){» insert-break
Может более 17 дюймов действительно неудобно — кто знает. Но это уже ни в коей мере не довод против пальцеориентированности, — речь не об отказе от десктопов.
Даже если так, вы придираетесь к словам. Сенсорные средства ввода уж точно не менее важны, чем мышь.
И как это можно «не считать интерфейс»?
Из неё можно было бы извлечь больше пользы, если перечислить еще некоторые операции по времени выполнения. К примеру, какие-то действия выполняются секунды, как сравнение, или арифметика, а какие-то — задачи на годы, как сортировки или сложные процедуры. Ведь в процессе программирования этот вес обезличивается, порой не понимаешь, не слишком ли это тяжелая процедура, чтобы помещать её в mousemove событие. Все обозначается некоторым набором символов.
Также это событие mousemove (вообще прерывание) — с каким периодом в этих мелких масштабах оно срабатывает? Раз в год? Раз в десятилетие? Или раз в месяц?
В общем можно было бы более ясно дать понять, что стоит оптимизации, а что нет. К примеру, многие операции сравнения в условных операторах не стоят оптимизации.