lexxcode

имхо все эти winscp и плагины подключалки неудобные. Гораздо удобнее монтировать удаленный раздел как в линуксе через sshfs. Для windows есть программки, которые позволяют удаленную файловую систему представить будто это еще один локальный диск. Программки, например, WebDrive (платная), либо на базе библиотеки Dokan программка DokanSSHFS (бесплатная). Может в скором времени все таки дойдут руки, и я допишу свою программку тоже на базе Dokan для монтирования ftp и sshfs в windows

Именно, в разделе Effects Да кто же мешает

Градиентное наложение (Gradient Overlay) на цвет, вполне логично Портировали, да недопортировали. В svg как раз есть более адекватное понятие - fill, то есть заливка. Что в свою очередь позволяет относиться к градиенту как градиенту, эффекту, который может быть наложен на что угодно.

весьма странно градиент называть картинкой вот картинка: А градиент - это градиент

Градиент это не картинка это градиент, и он никак не связан конкретно с фонами. просто градиент. Его же не назвали background-gradient, например, а просто linear-gradient, что не привязывает его к чему либо конкретному. Так что чисто логически можно спокойно применить и для других цветов, хоть текста, хоть бордеров, хоть фона.

стоит признать, что это весьма неплохая отсебятина. Но лучше было бы что-то вроде такого: .class { color : linear-gradient(#fff, #e1e1e1);}

там имеется ввиду градиент для текста, а не для кнопки, так что колорзилла тут не помошник

Так что ли? Только я там градиент изменил, а то плохо видно было

Если обычный день, то тоже засиживаюсь до 2-4 часов утра. А в тренировочный день за полночь уже выключает адово просто. Занимаюсь примерно с 5 - 6 вечера до 7-8, то есть часа 2.

Имена шрифтов которые содержат пробелы, нужно оборачивать в кавычки, ну и не мешало бы еще шрифт в формате woff подключить. Сгененрировать можно белкой

Большинство из нас большую часть дня сидит за компьютером, а некоторые так вообще не встают из-за него. Энергия тратится максимум на мозговую деятельность и на переваривание пищи. Конееечно спать не сможете. Запишитесь в зал и ходите таскать железо по вечерам часик - полтора. После нормальной тренировки сил в лучшем случае поужинать хватит. Выключает организм только так. И для здоровья полезно и сон ровный. А считать, дышать.... это все не настолько хорошо действует и не для всех.

Там просто, если использовать БЭМ в полной мере, многие вещи сильно автоматизированны. То есть разработчику не приходится писать эти несуразные классы самому. Это все компилируется на этапе сборки. А разработчик просто создает модули и структуру папок и файлов с не большими кусками кода. Но по правде сказать, как по мне, все равно это мозгодробильня Но модульность, при разработке даже верстки, иногда может быть полезна, если не зацикливаться на это так сильно как это сделано в БЭМ. А то потом получаются, как выше пример был, элементарная менюшка, а там 100500 абсолютно не нужных элементов скомпоновано

что не так, по твоему? сейчас это вполне себе разрешено. Строго говоря это даже в html4 проблем не вызывало, кроме ругани валидатора. ааа блин, я картинку не связал с тем, что ты сказал ахах, ну да, вообще-то. Я что-то не обратил внимание. Просто когда открыл страницу, сразу клацнул на ссылке проинспектировать, оно в девтулзе перешло туда по коду, и доктайп остался за границей экрана, и я не посмотрел Ну да, тогда с точки зрения доктайпа бредок. Но с точки зрения браузера пофиг, в любом случае он парсит html по современному стандарту. На сколько я понял, вроде товарищ SelenIT кидал ссылку по этому поводу. Но я не знаю просто по какому запросу найти эту инфу. Да нам этого не понять Не, как подход, весьма хорош, тут бесспорно и да для малых команд все инструменты БЭМ будут слишком переизбыточны, хоть сам яндекс часто говорит обратное. Но вот с синтаксисом они наворотили конечно ппц. Идея идет от обычного АНБ подхода. Я в свое время пробовал БЭМ применять, но километровые классы меня огорчали как Винни-пуха длинные слова. Я для себя некоторые фишки почерпнул, конечно. Но использую свой подход к написанию классов.

вообще мне больше даже понравилось объяснение SelenIT'а. Если нам приходится избавляться от внешнего вида списков, то скорее всего это действительно не список. Вот если обращаться к спецификации по элементу nav Там нет строгой регламентации, что нужно применять только список для ссылок. Но навигация по документу выполнена в виде списка вложенного в nav. при этом в первом примерчике ссылки на страницы новостей, блога и форума, вообще оформлены в параграфе и без списка, просто ссылки насыпом. При этом списки ul и ol, явно применяются только лишь для каких-то текстовых данных. Но не для более сложных вещей. В общем, я могу конечно и ошибаться в своих суждениях, я этого не отрицаю и вообще сразу об этом сказал. Ну если тебя смущает блочный элемент внутри строчного, то в html 5 так можно. Если тебя смущает БЭМ, то тут скажем так, идея хорошая реализация через опу Ну и объективно для реализации той менюшки нафиг не нужно было городить всю это вакханалию) Да и вообще, вся эта семантика-шмемантика Есть еще один момент в моем понимании, что не стоит слишком усложнять вещи. Ну то есть мы обозначили навигацию навигацией тегом nav, и все. Если эта навигация не предполагает выглядеть как список, то и не нужен там список, а если предполагает, как в примере на w3c, то пускай будет список. Что касается поисковиков, тут я не могу сказать что-то конкретное по этому поводу, но по идее для поисковика присутствие или отсутствие списка в навигации, особой роли не должно сыграть. Так же как для устройств предназначенных для людей с ограниченными возможностями. Если это обозначено как навигация значит оно будет каким-то образом для них доступно.

Почему же нереализуемо?

Слайдер может быть и списком, я об этом писал. Зависит, от того какой смысл в этом всем заложен. Что касается просто листалки картинок, то не список это нифига. С тем же успехом эти фотки можно было просто положить на странице все. По смыслу бы ничего не изменилось вообще. А работы, ну хз. Если это просто показывает что ты когда либо делала, то я бы не делал это списком. А вот допустим если работы иллюстрируют некий прогресс твоих способностей как специалиста, то вероятнее список. Если с новостями все довольно понятно, то со слайдерами тут могут быть массы смысловых вариантов, по этому может быть по разному. Я, в данном, случае не могу сказать, что слайдер однозначно не список или однозначно список. Это было бы не правильно.

http://bxslider.com/ <--- глубоко индифферентно что ты в него вставишь Ну хорошо это галерея твоих работ в виде слайдера. почему вдруг это список?

Это в первую очередь способ мышления. Думать тегами - плохо. Думать элементами (сущностями) - хорошо. Вот взять муху. Это сущность которая наделена рядом свойств, может летать, кушать, размножаться. Но так же муха состоит из компонентов, можно разорвать ее на крылышки, лапки и туловище. Так же и тут, вот есть пост в этой теме. Это сущность, у нее есть id, текст сообщения и еще вложенная сущность описывающая автора поста. Кнопка отправки сообщения тоже сущность, хоть и простая, не имеющая вложенных компонентов. Но так же имеет ряд свойств, может менять свой вид, содержит текст, может обрабатывать события, и так далее. То есть понятие сущности позволяет абстрагироваться от реализации, я бы так сказал.

Я не очень понял вопрос. Список это список, навигация это навигация. Не нужно их смешивать

Меню это не список. Если это являет собой навигацию по сайту, то это тег nav и внутри него могут быть ссылки <nav> <a href="#">Главная</a> <a href="#">О компании</a> <a href="#">Новости</a> <a href="#">Каталог</a> </nav> Само собой ссылки можно обвернуть в div, например, который не имеет никакого семантического веса, если без этого невозможно реализовать какие-то дизайнерские выверты. Да, раньше это делалось списками. Но только потому, что более подходящей альтернативы не было. Но это, на самом деле, не список, совсем. Ссылки списком могут быть, в тексте, к примеру, перечисления использованных источников. Но в то же время это уже и не навигация по сайту, да и вообще не навигация как таковая. По этому в такой ситуации это будет списком. Слайдер это не список. Вообще это какое-то за уши притянутое понятие "список слайдов" или "перечисление слайдов". Это просто слайды. Каждый слайд представляет абсолютно законченную и независимую сущность. Я могу взять выдернуть любой слайд и слайдера и смотреть на него и он не будет требовать для себя каких-то дополнительных объяснений. Так же как и сам слайдер не потеряет смысла абсолютно, без пропавшего слайда. Единственный случай, который по быстрому всплывает в голове, когда возможно нужна какая-то связная структуризация это в каких-нибудь пошаговый слайдерах, ну к примеру презентация. Своего рода тоже ведь слайдер, но он имеет относительно четкую структуру, строгость порядка слайдов, их нумерацию, название т.п. служебная информация. Но если выдернуть слайд или перемешать их, идея презентации может пропасть вовсе. Ну по крайней мере просто каруселька с котиками, рекламными предложениями, баннерами и с другими самодостаточными данными это не список. А вот что-то связное, как в примере выше, возможно и требует какой-то отдельной структуризации. "Список новостей" (я так понял имеется ввиду лента новостей) -- ну снова таки, каждый новостной пост, самодостаточен. Проблема открыта, описана, закрыта. Все. Да бывает когда одна новость ссылается на другую, но это, так скажем, символическая ссылка. Абсолютно не имеет значение где находится одна новость относительно другой в выдаче. Вот меня заинтересовала новость о миграции тушканчиков, я ее беру и читаю. При этом мне не важно, что в Мексике ураган, а на Киев упал метеорит. Меня интересует насколько успешно мигрировали тушканчики. Так, что это ни разу не список. Каждый новостной пост можно оформить в тег article. "Список отзывов клиентов на лендинге" -- отзывы принципиально то же самое, что и комментарии. Что такое комментарий? Это, как правило, четко сформулированная (ну да да не всегда люди четко формулируют свои мысли) мысль либо вопрос, относительно поста/товара/новости etc. С одной стороны комментарий представляет самодостаточную сущность, но не совсем. Комментарий довольно жестко привязан к посту. По этому сам пост оформляем в тег section, а внутри после содержимого поста создаем блок комментариев, в котором каждый комментарий оформляется тегом article. И все. Тем самым формально мы связываем пост и комментарии. Но при этом я могу удалить комментарий и ничего от этого по смыслу не изменится. Я могу с тем же успехом менять их порядок. Могут быть комментарии к комментариям, по такому же принципу вкладываем комментарии. Так мы получаем структурированное дерево комментариев. С четкими связями там где это нужно. Так, что применение article - да, организация узлов и дочерних им потоков комментариев - да. Списки - нет, не клеится оно тут. Потому что это не перечисление. Что может быть списком, к примеру, я хочу собрать компьютер с нуля. Для этого мне нужны такие комплектующие: Материнская плата Процессор ОЗУ HDD Блок питания Видеокарта Кейс Это список необходимых, либо уже выбранных, товаров. Я могу менять их порядок (поэтому ненумерованный список), но я не могу ничего из этого убрать (грубо говоря). Иначе у меня не получится собрать компьютер. А вот когда ищу в магазине материнскую плату, то результат поиска уже не будет списком. Ибо там можно и убрать что-то и добавить, и посмотреть на конкретный товар, при этом мы ничего не заденем. P.S. Все выше сказанное является моим пониманием всего этого добра и трактовкой описаний некоторых элементов HTML5. Со мной можно соглашаться, можно не соглашаться. Это ваше право, я ничего не навязываю, никому. По скольку вся эта тема весьма мутная, на самом деле. Новые элементы html имеют достаточно расплывчатое описание. А те же списки, так уж исторически сложилось, долгое время приходилось применять там где это совсем не нужно, но другого выхода не было. Так, что как-то вот так

На начальном этапе да. Я имел ввиду, что (в поддержку слов klierik'а) нужно стремиться найти 2-5 заказчиков, которые будут постоянно обеспечивать тебя потоком проектов, которые будут нравиться тебе, в первую очередь. Либо просто работа над каким-то одним большим проектом на длительный период. Не стоит хвататься за что попало, просто потому что за это платят. Если ты видишь откровенно лажовый макет, который объективно не принесет тебе профита в знаниях, то зачем тебе такой проект? Нужно требовать. Если доработки выходят за рамки начальной договоренности, то они оплачиваются отдельно. Понятное дело, что если там прилетела одна единственная просьбочка, которая решается за пять минут и больше за собой ничего не тянет, то нечего и заводиться с доп. оплатой. А за 2-3 часа, ты могла бы, что-то прочитать, или позаниматься спортом, или банально поспать. Время не возобновляемый ресурс, к сожалению. Те 2-3 часа, это не просто часы работы, а часы твоей жизни. А жизнь одна, не стоит разбрасываться ею направо и налево. Цени, в первую очередь себя и свое время. Заказчик не оценит твои затраченные бесплатно 3 часа времени, он просто получит выгоду, а ты просто потратишь 3 часа времени.

Полностью поддерживаю. Погоня за разовыми шабашками толку не приносит. А чем бесплатно работать, лучше бесплатно заниматься самообразованием

Такс, здесь продолжаем тему по теме., а обсуждения фриланса я перенес сюда

Мой подход, совершенно не вызывает проблем если придется (та ну нафиг), поддерживать IE6+ и старые хромы, фаерфоксы (да лаааадно, по сравнению с IE6, они идеальны)

Я оооочень долго использовал сброс * {margin: 0; padding: 0;}, еще дольше использовал сброс Мейера. Так, что более чем в курсе их уязвимых мест. Но когда действительно доходит, как все это работает, именно в этот момент приходит понимание, почему это плохо, а что-то нет. Я был абсолютно таким же как и вы (кто защищает сбросы). Я был готов защищать этот подход до последнего, это казалось чем-то невероятно крутым и мега-полезным. Да я был таким, я это честно признаю. Всего навсего я пытаюсь помочь другим не допустить такие же ошибки, какие допустил я. Я вполне объективно понимаю как это выглядит со стороны. Что вооот, взрослые дяди, на протяжении 10 лет твердят, что это хорошо. Многие разработчики это применяют. И тут выскочил, какой-то непонятно откуда, и начинает говорить, что все это не правильно. Я прекрасно понимаю, что ваше внутренние чутье статистики не дает вам отказаться от своих убеждений. Но статистика тоже может ошибаться. У меня не возникает таких проблем, которые ты описываешь. Я один раз настроил, как мне нужно, и больше не думаю об этом Все не списки, но это тема для отдельной дискуссии, в 10 часов вечера, на такое я уже не подписываюсь, простите меня