-
Posts
493 -
Joined
-
Last visited
-
Days Won
25
Content Type
Profiles
Forums
Calendar
Store
Everything posted by Catherine
-
Ну, если совсем по-быстрому, можно задать дополнительный класс последнему sub-menu (или, вместо этого, воспользоваться псевдоклассом :last-child) и задать ему right: 0, чтобы выпадающее меню позиционировалось от правого края, как-то так http://jsfiddle.net/Cath_kb/8HzWp/2/
-
Возможно, эта статья вам поможет узнать, что происходит?
-
У меня, помимо чата хтмлбук, висит несколько чатов, в том числе и свыше 200 человек в группе. Тоже иногда сообщения запаздывают, а в остальном полет нормальный. Но у меня Win7.
-
Мне не кажется — активные области там (по крайней мере у меня в Fx24) тупо прямоугольники... Прямоугольники
-
Полностью поддерживаю! Придерживаюсь того же мнения.
-
Надеюсь, что это была опечатка Потому что лично мне всё понравилось. Спасибо всем присутствовавшим за полезное и интересное времяпровождение в приятной компании! Выражаю отдельную благодарность организаторам. С нетерпением жду следующую встречу.
-
Серая линия вверху страницы - это ничто иное, как место, отведенное под ErrorLine. То, что блок сдвинули на 260рх вниз, дает лишь смещение этому блоку относительно области, отведенной ему в потоке. Подробнее можно почитать, например, тут. Если нет возможности поменять порядок элементов в коде, то с помощью css можно абсолютно спозиционировать ErrorLine, тогда он будет "вытеснен" из основного потока и серая полоса не появится. Как-то так: position: absolute;/*вместо pelative*/ top: 223px;/*-37рх*/ left: 50%; margin-left: -177px;/*половина ширины ErrorLine и 1рх - поправка*/ И не забыть, что позиция элемента будет отсчитываться от ближайшего родителя с позиционированием, отличного от static, и если такого нет, то отсчет ведется от начала страницы (как в данном случае). Но правильнее, конечно, если есть такая возможность, было бы поместить ErrorLine внутрь registerBox сразу за admin_page_logo и не забыть убрать лишние стили, включая верхний сдвиг. Тогда сообщение будет на своем законном месте
-
Это не ко мне, я вакансии "верстал" смотрю много где, чисто случайно и просто для интереса, а не для поиска работы Создавайте отдельную тему, возможно, что-то и подскажут более опытные соискатели из столицы.
-
У кого-то из тех, кто предлагает различные пути решения данной проблемы, множественный фон в ие старых версий получилось подключить с помощью PIE?
-
SelenIT, спасибо!
-
Чтобы бывать на ваших мероприятиях, некоторым пришлось переезжать из других городов С удовольствием буду, если никто не против.
-
Sorrow, спасибо! В документации 'replaced', 'non-replaced', 'bindings', 'Frames and framesets' идут разными разделами. Это всё разделение по поведению? input (насколько я понимаю, всех типов) - замещаемый элемент, но он в разделе bindings. img - замещаемый, но в разделе replaced elements. Означает ли это, что и в других разделах (теоретически) также могут находиться замещаемые элементы? Получается, что на данный момент нет формального документа с полным списком замещаемых элементов, на который можно было бы сослаться в случае затруднений, вызванных при попытке однозначного определения замещаемый элемент Х или нет?
-
SelenIT, спасибо за тему! Прочитала про замещаемые элементы на whatwg.org (на w3.org то же самое). Исходя из документации (ссылаясь на вышеуказанные в этом посте ссылки), есть замещаемые элементы, которые идут отдельным пунктом (10.4 Replaced Elements), а "связанные" (не уверена, что правильно перевела bindings) элементы идут под другим пунктом (10.5 Bindings). Есть также Frames and framesets, Non-replaced elements и прочее. У меня возник следующий вопрос. Получается, что с точки зрения HTML, bindings и replaced - абсолютно разные вещи, а с точки зрения CSS (если ссылаться на перечень примеров замещаемых элементов из рекомендации CSS2) - часть (или все из них) замещаемые? Другими словами, означает ли данное расхождение в группировке элементов вкладывание различного смысла в термин "replaced element" в зависимости от контекста ('replace elements HTML' vs 'replaced elements CSS')? Или разбивка на пункты одного уровня в данном случае не означает разделения на группы элементов? Или информацию из рекомендации CSS2 касательно замещаемых элементов можно считать устаревшей? Подскажите, пожалуйста, как однозначно определить замещаемый элемент с точки зрения CSS. Например, как определить: <details>, </marquee> - это замещаемые элементы или нет? Понимаю, что с момента последнего поста прошло уже больше года, но буду благодарна, если кто-нибудь поможет мне окончательно разобраться в немного запутанном для меня вопросе. Может, что-то изменилось за это время? Спасибо!
-
Ну так тем более, чего скрываться-то? Талантливым людям не стоит зацикливаться на клубе анонимных верстальщиков! Возраст, пол и страна проживания - не помеха на пути совершенствования специализации и проф. общения. Нам нужны такие люди
-
Клуб анонимных верстальщиков Жуть... Под личиной миловидной неопытной девочки скрывается сорокалетний бородатый мужыг, а матерый фронтендщик с многолетним стажем 2001 года рождения. Я бы тоже в таком случае не хотела светить свои личные данные. Люди, я хочу вам помочь. Вы пишете о насущной необходимости создания чата непосредственно на форуме. И я действительно пытаюсь услышать весомые аргументы, которые, в меру своей недалекости могу не замечать. Я так понимаю, что основная цель этого ресурса (по-крайней мере для меня) - возможность обмена опытом и поиск решений в рамках специализации (и не только, но в соответствующем разделе - все мы живые люди и иногда просто хотим пофлудить). Что вы конкретно хотите от чата? Зачем еще один чат, но именно на форуме? Кто-нибудь из желающих может аргументированно ответить на эти вопросы? Кстати, вероятность того, что общение будет в более активном и продуктивном режиме не на форуме, а в чате форума - крайне мала. Там будут сидеть те же люди, что и на форуме
-
Можно подумать, что все такие умные становятся после 100 сообщения на форуме Извините, но я еще раз хочу напомнить, что есть скайп-чат, и есть форум, за которым следят одни и те же люди. Чтобы делать еще один чат, нужны довольно веские основания. К тому же, это дополнительная нагрузка для модераторов. "Веские" основания Zverushka не обоснованы. Никто не просит добавлять к себе в скайп людей, которых вы не знаете. К тому же, есть некий отбор заявок создателями скайп-чата, поэтому, скорее всего, маньяков среди них нет, а если и есть, то они и без скайпа ваши данные из сети вытянут. И еще. Скайп-чат УЖЕ есть. В нем живое общение в режиме реального времени. Этот способ прижился. Кто хочет - общается. Кто не хочет - ищет причины не присоединяться.
-
Уважаемые желающие чата на форуме. А кто из вас за ним следить будет? Я, может, сейчас Америку открою, но особенность чата в том, что сообщения может писать кто угодно, когда угодно и как угодно. Модераторам остается либо круглосуточно жить на этом форуме, "подтирая" лишнее, либо "забить" и оставить хм... "кашу" как она есть. Если кто-то думает, что в чате люди начнут отвечать чаще на ваши "срочные вопросы", чем на форуме - это заблуждение. Кто может - абсолютно одинаково быстро ответит и в конкретной теме, и в чате. Всё-равно чаще на сайт заходить не станет. Для "поболтать" есть флейм, и есть скайп-чат, которые активно модерируются. Или я чего-то не понимаю? Что вы там уже обсуждать собрались, что он критически необходим?
-
Не по тем источникам учите, начните хотя бы с азов блочной верстки ) Оставьте таблицы для табличных данных. http://htmlbook.ru/samlayout/blochnaya-verstka
-
Посмотрите на фриланс ресурсах портфолио верстальщиков. Там часто описывают перечень выполненных задач и время разработки. Будете иметь хотя бы общее представление о сроках. Можно и 10 страниц за один день сверстать, но попадаются и такие проекты, где на разработку 1 страницы уходит неделя, а то и больше. Всё зависит от сложности страницы, ТЗ, дизайна, личного опыта и индивидуальных особенностей верстальщика. Лично у меня нормы, как таковой, нет. Я могу назвать только приблизительное время разработки, посмотрев на все макеты и детально изучив ТЗ. Макеты и задачи всегда разные.
-
Мой ответ предназначался Alarr: Очень хотелось посмотреть на его реализацию По теме. Я бы делала с использованием псевдоэлементов, как предложил mrnobody, например, как-то так: http://jsfiddle.net/Cath_kb/svrjp/ Вместо однородного фона для псевдоэлементов я обычно использую border'ы.
-
с помощью jQuery, наверное, так: $.each($('img'), function(i, val) { if ($(val).css('float')=='right') { console.log(i,$(val)); } }) http://jsfiddle.net/Cath_kb/aExUq/ Zverushka, $("img[style*=right]"), если не ошибаюсь, работает, только если у картинки стили прописаны в атрибуте 'style'. http://jsfiddle.net/Cath_kb/aExUq/1/
-
Покажите на примере.
-
Да, что-то намудрила я) Всё верно у вас получилось. Картинка по умолчанию имеет "загадочный отступ", присущий всем сточным элементам Его можно было также убрать, выровняв картинку по верхнему краю.
-
.box .main { margin: -2px 18px 0 18px; border: 1px solid hsla(0, 0%, 80%, .1); border-top: 2px ridge hsla(0, 20%, 10%, .15); padding: 20px; height: 305px; overflow-x: hidden; overflow-y: auto; } Применяем математику Возьмем блок .trailer .main 304рх(высота картинки)+20рх(padding-top)+20рх(padding-bottom)+2рх(border-top)+1рх(border-bottom)-2px(margin-top) = 345px 345 > 305 и overflow-y: auto Упс, не то
-
А чего пробовать-то? Читаем документацию: То-есть буквы кириллицы теоретически могут использоваться в именовании переменных, так как попадают в указанный диапазон. Но, тем не менее, у каждого символа свой ASCII-код. А это означает, что визуально идентичные символы станут идеальным способом подпортить несколько часов времени на выявление ошибки. Удобства в применении я категорически не вижу. Синтаксис PHP, HTML, CSS, JS (как, собственно, и большинство других языков) всё-равно построен на использовании латинских символов. Так что теперь, из-за каких-то языковых комплексов баловаться переключением раскладки клавиатуры? Не рационально. UPD. Кстати, с кодировками проблем не предвидится?