s0rr0w

Так это было бы слишком просто

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

Сделать картинкой.

Сабж.

Читать про растровую и векторную графику. Что это такое и в чем отличия.

Получится ли это сделать или надо попиксельно подбирать.

Получится, если почитать документацию по CSS про строчные и блочные элементы.

В каждом большом проекте наступает момент, когда внимательность и усердность снижаются до минимального уровня. Самое время для создания пары трудноотловимых багов. И один из самых распространенных - дубликаты идентификаторов.

Любая попытка создать модуль автоматической идентификации провалилась еще на стадии проектирования. В надцать раз проще создать идентификатор руками, чем городить монстровидный модуль, который учитывал бы все причуды разработчиков.

Кто-то воскликнет, но это же проще пареной репы, поставить плагин валидации к FF и валидировать на лету! Это подходит для классического метода построения страницы - все на одной странице, переходы сделаны между страницами. А для AJAX-генерируемых страниц это нереальная задача.

Как выйти из ситуации? Два пути. Оба не сильно "веселые", но сполне реализуемые. Написать специальный JS-модуль для проверки на совпадения ID, который рапортовал бы о повторах, или же максимально возможно отказываться от идентификаторов, перекладывая эти функции на CSS className.

Второй способ имеет ряд позитивных моментов. Это возможность выборки нескольких нод по одному признаку. Правда нужно будет немного поменять стиль мышления.

Есть еще один способ, но про него я расскажу позже.

Теперь возьмем простой пример. Нужно активировать некий таб. Что пишут обычно? Берут ID контейнера, по идентификатору получают ноду контейнера и перебирают все ноды, присваивая им определенные классы. Зачем перебирать, спросите вы, если проще запомнить, какой таб активный, его выключить, а нужный - включить? Этот способ хорош ровно до тех пор, пока не случится ситуация, когда случайно не "потеряется" переменная со ссылкой на активную ноду. Более универсальный и стрессоустойчивый способ перебора нод для активации.

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

Некоторые редактор создают мне дополнительную проблемы, делая автодополнения и автопереносы(например, когда пишу цикл), у меня другой стиль программирования. Думаю, стоит ли ради подсветки работать в другом редакторе. С одной стороны, это несколько ускоряет работу, с другой, когда нет подсветки я лучше оформляю так, чтобы его можно было найти без всяких подсветок.

Лично я использую только две подсветки.

Комментарии и директивы(функции). Все.

Рассмотрим тему, которая является логическим продолжением темы про фреймворки.

Есть куча темплейт-систем для серверных языков программирования, но почему бы не применять аналогичный подход для темплейтирования HTML блоков? Что же такое, это HTML-темплейтирование? Все очень просто. Это способ использования неких HTML-структур для быстрого изменения дизайна различных фукнциональных компонентов.

Давайте рассмотрим следующий пример. Возьмем простой компонент - таббер. По сути таббер состоит из двух частей - блока переключателей-закладок и нескольких контентов.

Вариантов решения задачи множество. Давайте начнем с простого и пойдем по пути усложнения.

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

Это можно решить на этапе формирования контента, создавая контент серверным скриптом, тогда проблема равного количества отпадет. Есть другой способ - выводить таб и контейнер в одном блоке, а потом собрать все табы и переместить их в нужный контейнер. Это решение красиво с многих сторон, но у него есть ряд недостатков. Это стандартизация обработчиков, которые нужно повесить на переключатель. Это можно сделать при помощи JS, создавая переключатель динамически. Решается множество головных болей, вроде бы кажется красиво и понятно.

Теперь ложка дегтя. Автоматическое создание табов при помощи JS не сильно удобно с точки зрения редизайна. Придется лепить кучу дополнительного, зачастую неудобного кода, чтобы добавить простые вещи. И вот тут (та-да-дам!) ... приходит на помощь подход HTML-темплейта. Мы подготавливаем некий шаблон таба, который будет использоваться по умолчанию. Это будет кусочек кода, который будет заполняться нужными данными. Если нам нужно сделать один таб сильно отличный от других, то мы добавляем уникальный шаблон вместе с контентом таба в код, а потом уже используем его как болванку. Вуаля!

Какие выводы можно сделать из сказанного?

Если генерировать ноды при помощи JS, то создание уникальных функций или стилистических конструкций будет схоже на Ад, потому что вместо того, чтобы написать простой кусок HTML кода и предусмотреть его в качестве темплейта, вам придется написать множество JS-кода. И никакие фреймворки не спасут. Ваш скрипт можно считать одноразовой поделкой, которую невозможно использовать повторно в других проектах. HTML-темплейтирование поможет легко переносить функциональность практически на любые проекты с любым дизайном или функциональностью.

Да, решения "в лоб" иногда можно сделать быстрее. Но это в единоразовой перспективе. Если брать долгосрочную перспективу, то нужно использовать другие принципы.

s0rr0w :

без кода каляки-маляки overflow: hidden; в id="content" ничего не менял.

дак я так и не понял, каким образом свойство "overflow: hidden;" блока id="content" сделало так, что теперь в этот блок влезает все и полноценно.

ведь даже если просто перевести это свойство на русский язык, то "при переполнении блока то, что вышло за его пределы - скрыть".

Это вам домашнее задание, разобраться в содержании той ссылки, которую я вам дал.

Не понимая почему что-то происходит, вы никогда не сможете качественно делать свою работу.

без проблем. Возьмем пример работы с бд mysql без фреймворка:

рутина или нет писать столько повторяющегося кода?

А если код вынести в отдельную функцию? Это ведь можно сделать БЕЗ фреймворка!

меньше рутинной работы или нет?

Расширьте запрос. Пусть он будет выбирать не все подряд, а только нужное. Причем нужно сформировать два разных списка, например, отдельно все свежие посты, отдельно - все несвежие. Вперед!

Ловушка заключается в том, что на примитивных примерах все просто. А как только нужно написать что-то больше, упс... начинаются танцы с бубном.

любой код больше сотни строк уже нуждается в комментариях. А если он организован в виде функций и классов, то тем более. В фреймворк намного легче что-то встроить и изменить, поскольку в нем есть четкая структура, есть стандарт (обычно есть), есть нормальный мануал. В отличие от самописных движков, в которых придется неделю разбираться, чтобы хоть что-то понять. Про документацию к самописным движкам я вообще молчу.

В коде нашего продукта почти нет комментариев. Их менее 1%. Не используется ни одного стороннего фреймворка. И в коде почти всего проекта новый программер разобрался меньше чем за неделю.

Ведь достаточно применять несколько соглашений программеров, и все становится понятно всем.

от этого отношения к совмещению "мозгов" и "крутых средств разработки"

Я сторонник универсализации. Лучше иметь один не очень мощный инструмент, который умеет делать все, чем десять могучих инструментов, которые нужно использовать по-очереди, чтобы добиться результата.

В нынешнем нашем продукте 95% JavaScript'а находится в smarty tpl файлах. Толку от умного и навороченного редактора будет почти ноль.

Я считаю, что фреймворки можно использовать. Это что-то вроде инструментария, который всегда под рукой. Здесь есть почти все, что нужно для разработки сайта (остальное можно самому дописать). Фреймворк облегчает работу программиста, освобождая его от кучи рутинной работы. Конечно, если сайт на две странички, то использовать фреймворк просто неэффективно, а вот при разработке среднего или большого сайта можно использовать фреймворк с большим успехом.

Да что вы говорите? Правда?

1. Покажите мне кучу рутиной работы, которую может облегчить фреймворк. Реальный пример.

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

Давайте общаться предметно!

Покажите? А то меня уже колотит!

вот так сделал в КСС, везе прописал размер шрифта.

А ничего, что у вас три раза одно и то же написано?

ничего не выходит, все вариации перебрал!

А у меня все вышло, все работает.

так текстом выходит, но когда я кликаю ничего не происходит.

Так и должно текстом выходить, не картинками же!

Я конечно извиняюсь, а может есть какой нибудь рабочий пример?

Вам уже дали рабочий пример.

У меня ссылки в ДИВАХ не кликаются Малый Средний Большой - просто текстом выходит!

Врете вы все, кликаются ссылки в ДИВАХ!

А Малый Средний Большой просто обязан текстом выходить!

не понял.. и где мне надо было применить этот хидден ? в id="content" ?

Подумайте, поэкспериментируйте... Ответ у вас под самым носом.

Поговорим про моду. Мода бывает на одежду, на автомобили, на все что угодно. Веб-технологии не исключение.

Сегодня царит мода на фремворки. Они рождаются как грибы после дождя. Каждый стремится сделать что-то эдакое, чего не делал до него никто, но по сути они все одинаковы. На форумах разгораются священные войны относительно того, какой из фреймворков лучше, удобнее, быстрее, компактнее. Тонны флуда генерируются каждый день, увлекая за собой все больше и больше людей. Люди носятся с фреймворками как курицы с яйцом.

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

Фреймворк позволяет меньше писать, но он не умеет думать за вас. Вместо того, чтобы посидеть и подумать, кодер выбирает наипростейший метод решения задачи - сесть и написать все в лоб. На мелких задачах эффективно, но мелких задач в больших проектах нет.

Возьмем простой пример. Тот же форум. При нажатии на кнопку "ответить" внизу показывается скрытая форма для ответа. Какое решение выберет тру-фреймворк программист? Установить любимый фреймворк и сделать финт ушами. Каждой кнопке присваиваем ID, внизу делаем скрытый блок со своим ID, перебираем все кнопки и навешиваем обработчики через addEventListener, который будет откывать или закрывать блок, попутно присваивать какому-то хиддену значение ID поста. Решение не сильно эффективное, так как есть ряд трудностей. AddEventListener не может "нести" дополнительные данные при присвоении, а значит, чтобы идентифицировать, на какой именно пост делается ответ, придется городить огород. Метод упрощения - использовать столь некошерный и не-тру метод onclick обработчиков. Код становится проще в несколько раз. Остается только найти нужную ноду и хидден и сделать примитивные действия. Окей. Все хорошо, разработчик счастлив.

Но форум без плагинов - почти нонсенс. В дело вступает вторая фаза - добавление дополнительного функционала. Допустим, по кнопке "ответить" надо добавить еще пару функций. Например, захотелось сделать ответ прямо возле поста, причем можно делать несколько ответов одновременно. Упс. Алгоритм решения прост - нужно сделать клон блока с формой, поставить его рядом с постом, заполнить данными. И вот тут начинается коматоз. Первая проблема, которая возникает - идентификация блоков. Это можно делать путем установки ID, className, или использовать поиск бульбашки, при которм нужный блок будет найден путем подъема по дереву вверх. Окей, справились. Вторая проблема - идентификация уникальных нод внутри блока с формой. Нельзя просто клонировать, нужно клонировать с новыми, уникальными идентификаторами, иначе ничего работать не будет. Справились. Нужно еще навешивать обработчики на кнопку "отправить", потому что попытка отправить кусок не тех данных равно полной неработоспособности скрипта. Дальше развивать драматические события не имеет смысла, я думаю всем и так понятно, что фремворк не спас от всех проблем, которые возникли в процессе доработки функционала.

Форум наглядно показывает, что любой плагин зачастую кардинально меняет суть и процесс. Дерево нод может не быть статичным, может изменить свою структуру, могут измениться не только структура, но и местоположение ветки в дереве. Есть много других факторов, но основной звучит так - нет ничего статичного в документе. Все может измениться в один прекрасный момент, и нужно быть готовым к этому. Скрипты и компоненты должны быть готовы к такому развитию событий.

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

http://www.w3.org/TR/CSS21/visuren.html#block-formatting

Floats, absolutely positioned elements, inline-blocks, table-cells, table-captions, and elements with 'overflow' other than 'visible' (except when that value has been propagated to the viewport) establish new block formatting contexts.

ваша рекомендация, чтобы я ртфм, не пройдет мимо )

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

overflow: hidden решает!

Far. Для всех видов текстовых файлов.

s0rr0w:

как раз таки об этом то я и подумал. и долго думал, почему рамка пустая, но к результату так и не пришел (

Намного легче думается и куда быстрее можно придти к решению, если почитать спецификацию.

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

Зачем все помнить? Достаточно помнить где искать информацию, чем запоминать тонны практически ненужного спама.

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

Пример посмотрите здесь:

http://www.bfm.ru/news/2008/12/03/eldorado.html

там три буквы А А А - надо сделать так же с помощью JavaScript

подскажите как это реализовать!

Путем присвоения класса контейнеру со статьей.

А в классе описать нужные размеры.

хм, про флоат покапаю.. я когда рамку делал вокруг <div id="content">, тоже заметил, что в фф рамка пуста, пока ей не задать конкретное значение height.

А вы не подумали о том, что неспроста рамка пуста? Напрягите извилины, поищите в гугле информацию про float-элементы (уверен, что ее больше чем "масса"), и решите "проблему". Если за вас это сделает народ, то в вашей голове ничего не останется из полезного.

Есть некий одностраничный HTML файл. В нем текст. Мне нужно, чтобы юзеры(имеющие мониторы с разным разрешением) сразу видел весь текст целиком, а не листали скроллером. Меня устроит явное объявление zoom'а в HTMl файле (ежели кто знает метод/свойство масштабирование страницы в IE - еще лучше).

Пациент делает успехи!

Используйте флеш, если очень критично.

И что нам делать с твоим кодом CSS?