rash

Здравствуйте.

Вопрос предельно нубский, но попробую не стесняться

Задача — после загрузки страницы обойти все элементы по селектору (в частности, с заданным классом) и инициализировать для них некоторое поведение.

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

Первый — обработчики создаются в замыкании для каждого экземпляра:

$('.class').each(function() {	var self = $(this);	var data = 1;	self.on('event1', 'child1', handler1)	    .on('event2', 'child2', handler2)	    .on('event3', 'child3', handler3);	function handler1() {		...	}	function handler2() {		...	}	function handler3() {		...	}});

Здесь при каждой итерации each в замыкании будет создаваться новый комплект обработчиков, из которых будут доступны данные data и сам элемент self просто из скоупа. Это упрощает доступ к данным, их сохранение и обмен между обработчиками.

Второй способ — обработчики создаются внутри внешнего замыкания:

(function() {	$('.class').each(function() {		var self = $(this);		var data = 1;		self.on('event1', 'child1', function() { handler1(self, data); })		    .on('event2', 'child2', function() { handler2(self, data); })		    .on('event3', 'child3', function() { handler3(self, data); });	});	function handler1(self, data) {		...	}	function handler2(self, data) {		...	}	function handler3(self, data) {		...	}}());

Здесь обработчики существуют в единственном экземпляре, но чтобы они могли оперировать общими данными, эти данные необходимо передавать в явном виде. Можно, конечно, привязать их к DOM-элементу, но его, тем не менее, передавать придется.

Вот и вопрос — стоит ли экономия на количестве обработчиков усложнения доступа к данным? Какой из вариантов выбрали бы вы?

Вы открывали demo.html со своего хостинга?

.htaccess сам по себе является файлом конфигурации веб-сервера.

Значит не хватает данных, раз это не помогает. Пока ничего нового сказать не могу.

Хотя... А не могли бы вы выложить сюда свой существующий .htaccess и дать ссылку на какую-нибудь страницу, где используется шрифт?

Не уверен, но вдруг это подскажет варианты...

Цель вполне может быть объективно недостижимой. Я не про ваш заработок, который вы себе наметили. Просто как-то слишком часто приходится слышать «нужно захотеть», «нужно поверить» и т. д. Это не работает

 

Блин.. затерся феерический пост о том, как я тупею от верстки... ну да ладно...

Ох, я думал это не такое частое явление, у меня уже давно так

"application/x-font-ttf" — это не папка. Это и есть сам content-type, который сервер должен будет отдвать в заголовках, когда клиент запросит файл с расширением ttf или ttc, ничего менять не надо, никакие пути подставлять тоже не надо.

Просто добавьте эти строки в файл .htaccess, скопировав их из какого-нибудь примера. Допишите в самый конец, например.

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

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

Это не псевдоэлемент, а псевдокласс.

И вопрос не очень понятен. А обычно он как применяется, если не встроенным способом?

 

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

обкакал весь фронтэнд

 

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

Или фронтенд в опыте был в основном простой, или бекенд сразу зверский какой-то.

Проверяли всегда все до мелочей. Лишний див - исправить, сss - отсортировать в соответствии с зен-кодингом, вложенность меньше - больше псевдоэлементов и т.д. Все не перечислить.

 

Дикость какая-то. Я по таким вещам вообще не парюсь. С точки зрения типичного верстальщика у меня код избыточен в большинстве случаев.  Зато поведение более предсказуемое. Надеюсь, и другим в нем разобраться проще при необходимости.

Объясните нахрена нужен бутстрап? Меня один раз заставили использовать так я весь изматерился, ну не мудрено, у меня ведь руки из жопы, всё хорошее у меня в руках будет работать не правильно. Тем не менее суть я так и не понял, что касается css вообще не очевидны преимущества. 

Я почти не пользовался, когда пользовался была еще только вторая версия.

Для себя пришел к выводу, что полезно не так для версти, как для прототипирования. Например, позволяет «накидать» что-то вроде: «вот здесь у нас будет текст в 4 колонки, тут форма с тремя инпутами и 24 кнопками, тут — содержание, которое не скрывается при прокрутке» и т. д. Чтобы оценить удобство формы до того, как дизайнер начал ее рисовать, например.

Ну или иногда бывает, что нужно просто публиковать контент, не так важно, как именно он оформлен (например, документация или что-нибудь подобное). Бутстрап позволит сделать это быстро и относительно аккуратно.

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

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

Кому что, действительно, и в любом случае как справочник я ее скорее порекомендую

Сам прочитал гораздо меньше половины, потом понял, что читать подряд ее и не нужно — не для того она. Стал заглядывать по мере необходимости.

Сам еще не закончил, но пока из того, что понравилось — в первую очередь http://learn.javascript.ru

В pdf он тоже есть, но продается за деньги. Онлайн — бесплатно

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

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

Также, не очень надейтесь на то, что знание других языков вам сильно поможет. Базу, конечно, поможет усвоить, но различий будет все равно очень много. Несколько способов объявления функций, области видимости переменных, замыкания, прототипное наследование и т. д. Я не могу сравнить с C# сейчас (а вы же сейчас его используете?), поскольку сам писал на нем очень недолго, несложно и 5 или 6 лет назад Но в любом случае будут значительные отличия от большинства C-подобных языков.

На всякий случай обращу ваше внимание (скорее всего вы в курсе, но вдруг). Это не учебник. Если вы хотите использовать ее как учебник — лучше подберите что-нибудь другое.

Это справочник. Справочник в целом хороший. Но справочник именно по языку, DOM. Новые модные API в нем не описаны (у меня, правда, пятое издание). Просто чтобы имели в виду.

Склоняюсь к тому, что браузерным масштабом управлять все-таки нельзя (по крайней мере кроссбраузерно). Вот есть статья на эту тему http://blog.sebastian-martens.de/2009/12/how-to-detect-the-browser-zoom-level-change-browser-zoo/ и обсуждение на SO http://stackoverflow.com/questions/1713771/how-to-detect-page-zoom-level-in-all-modern-browsers

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

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

Если надо просто отмасштабировать страницу, без связки с браузерным зумом, можно попробовать zoom/scale в css.

Нет, ну чужие в квирксе доделывать приходилось, конечно, но вот так, чтобы сознательно начинать писать свой новый код в квирксе — нет

В принципе IE 5.5 я поначалу пытался даже поддерживать, но ограничено, чтобы только не разваливалось, хотя этого никто уже и не требовал. Но они еще встречались

Гм, можно, конечно, но что это вам даст? Поисковик, скорее всего, такие теги не поймет, и увидит только их изначальное содержимое.

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

И на очереди вот такой:

в чем разница между стандартным режимом и квирксом с позиций js? Если взять один и тот же документ в quirks и обработанный html5-парсером — что будет отличаться? Работа некоторых функций, построенный DOM, еще что-нибудь?

Я и в верстке (то ли к сожалению, то ли к счастью) quirks почти не застал, что касается js — то это скорее вопросы не для практического применения, а для утоления любопытства. Нагуглить хотя бы кратко подборку различий пока не получилось

Блин, а для меня студенческие годы все-таки были только учебой. Почти только учебой. А вот как весело можно было...

 

зависит от реализации

объект js, а не объект окружения. Какой он?

 

Я не уверен, что правильно понял ваш вопрос, но вы имеете в виду случайно не Object как корень любой иерархии объектов?

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

И все-таки что такое «принципы функционирования JS»?

Любопытно, что они подразумевают под принципами функционирования JS.

 

 

Особенно это касается пальцев, которыми набираю пробел.

Я так и не смог освоить пробел как нужно, все время нажимаю пальцем правой руки. Тоже самое и с шифтом, только левым мизинцем.

 

Во-во, та же фигня