rash
User-
Posts
1,953 -
Joined
-
Last visited
-
Days Won
3
Content Type
Profiles
Forums
Calendar
Store
Everything posted by rash
-
Принципиально не пользуюсь ничем подобным. На нормальных сайтах реклама не мешает, а ее показ может помочь авторам поддерживать сайт. А навязчивая реклама — хороший индикатор того, что надо бы поискать альтернативу этому сайту.
-
На юзеров, похоже, в этом случае плевать?
-
*С подозрением* А вы, случайно, не СЕОшник?
-
А как в таком случае объяснить, что лучше находятся те страницы, которых не касались сеошники? Это тоже субъективное мнение, но поскольку не только мое, то в нем, скорее всего, есть хотя бы доля правды.
-
Не значит, так лучше не делать, на самом деле, если случай не слишком уж простой и вы не уверены на 100% что в этом случае так делать можно. Тут мы пользуемся тем, что при вычитании оба операнда должны быть числами, и JS по возможности пытается привести их к числам. Это не аналог parseInt, но более подробно рассказать не смогу, потому что автоматическое приведение типов происходит по сложной схеме, которую я сам до конца не знаю и не понимаю.
-
Точно, это же строки. Ну проще всего total = 0; $("input.Klass").each(function() {total += this.value - 0}) ну или более наглядно и традиционно: total = 0; $("input.Klass").each(function() {total += parseInt(this.value, 10)})
-
Не проверял, но должно сработать что-то такое (самый простой, вроде бы, вариант). total = 0; $("input.Klass").each(function() {total += this.value})
-
Эээ, нет. Но какая-то общая стандартная комбинация клавиш для этого так и просится сама собой Уже думал о том, чтобы использовать для этого accesskey.
-
О, холиварчик, не могу пропустить К счастью я к СЕО не имею никакого отношения, так что все мои доводы — результат собственных выводов. H1 на странице должен быть один не потому, что так требуют сеошники, а потому что этого требует здравый смысл. Страница подразумевает под собой какую-то более-менее однородную информацию, и если она структурируется — у структуры должен быть корень. То есть если мы натравим валидатор на страницу со включенной опцией «show outline», то мы должны получить дерево с одним корнем и (не так принципиально, но желательно) без «провалов» в уровнях. Пример с рефератами Сережи стоило бы структурировать так: «Рефераты Сережи» — вообще не заголовочный элемент. Это название сайта, а на страницах сайта, как правило, не пишут именно о названии сайта. Тема реферата — h1, если он один на странице, и h2 — если на странице выводится несколько рефератов, объединенных по какому-то критерию. Критерий — в h1. Далее содержимое самих рефератов структурируется заголовками более низкого уровня. Получаем логичную и последовательную структуру. Возможно, при использовании section более допустимы несколько заголовков первого уровня, однако и в этом случае эти самые секции/разделы выводятся на страницу по определенному критерию, которому и стоило бы быть корнем структуры документа. В общем, в этом случае требование спецификации противоречит здравому смыслу. В таких ситуациях приоритет, увы, не за спецификацией (во всяком случае, пока я не найду подтверждения, что ее требования оправданы чем-то объективным). А насчет noindex — разве еще какие-то доказательства нужны, после этого?
-
Доля Не представляю, зачем (а следовательно, никогда и не задумывался, как) эмулировать, например, системные контролы в формах с помощью чего-либо, кроме, собственно, инпутов.
-
Нет, большое количество элементов в тех случаях действительно нужно. Насчет вложенности — ну тут я, может, преувеличил, в среднем — не так уж и много уровней, да.
-
Мне на такие случаи как-то везет. Не каждый день, конечно, но несколько было
-
Переопределение стилей замедляет их применение, особенно на страницах с большим количеством элементов и глубокой вложенностью. Не в весе дело. Может потребоваться, например, в сложном и динамичном интерфейсе.
-
Кстати, бывают нечастые ситуации, когда рационально по максимуму использовать именно div и span, у них нет стилей по умолчанию, и это иногда бывает весьма хорошо.
-
Если это требование указано явно — верный и ранний признак того, что заказчик вынесет мозг в дальнейшем. Нет.
-
Это было воззвание к силам UNIX-а
-
76$?!! Уж лучше подожду доставки Ожидание окупит такую наценку.
-
Если на десктопе — почему бы не поставить анстейбл-ветку?
-
Кстати, а Good Parts можно где-то купить оффлайн, чтобы не заказывать из-за границы? Сейчас читаю, книга нравится (но там чистый JS, без акцента на применение в браузерах), но через некоторое время придется ее вернуть Хочется оставить и себе бумажную копию.
-
В нормальных браузерах везде все нормально с канвасом
-
Ну почитайте То вайфай не работает, то звука нет, и что-то такое постоянно… Ну то есть, конечно, некоторые, подобрав железо и покопавшись по локоть в кекстах, заводят все, но это уже от линуксоидства мало отличается.
-
Разница будет Достаточно почитать какие-нибудь обсуждения хакинтошей на форумах, чтобы в этом убедиться.
-
Одно другому мешать не должно. Вообще, проблемой это начал считать совсем недавно, но когда оцениваешь полезность того или иного аспекта стандарта, смотришь с точки зрения применимости либо к крупным, либо к мелким проектам (в зависимости от того, над какими сейчас работаешь). И вот для не слишком крупных и мелких проектов переменные меня бы несколько раз могли выручить, тогда как в крупных все не так радужно. А разработчикам стандартов стоит учитывать применимость в задачах разного масштаба. Так что для мелких проектов такую возможность я по-прежнему считаю полезной.
-
Я знаю. Но именно такая запись выглядит абсурдно. От наследования уходим чуть более красивыми способами (но лишь чуть более красивыми). Хотя наследование — возможность, применяемая браузером, Отключить ее не получится все равно, тут просто на нее не полагаемся. Ну и уходим от селекторов вложенности, что тоже бывает полезно. А какая разница, если поведение стандартизировано и предсказуемо? Большинство проблем происходит от неопределенности. Если все будут вести себя одинаково, то основная масса проблем будет решена продуманной архитектурой. Не язык программирования, а язык оформления. Просто более мощный чем то, что сейчас. Сколь-нибудь серьезную логику поведения все равно в нем не задашь, а базовую логику оформления — так это то, что надо.
-
Я не знаю, кто такой рядовой юзер и что он обычно делает Виндовс традиционно достаточно хорош в лане ГУИ (мелкие огрехи есть у всех, многие проблемы связаны со странностями разработчиков отдельных сторонних программ, но у ОС все более-менее хорошо). У линуксов традиционно хорош командный интерфейс (удачное наследие UNIX-ов), но довольно слаб графический (после многочасового допиливания он становится немного лучше, но все равно с серьезными шероховатостями, даже учитывая все эти композитные оконные менеджеры и прочую клоунаду). Макось не идеальна (идеальных нет, как и среди браузеров, можно долго повторять), хотя более-менее удачно объединяет нормальный ГУИ и хорошие командные оболочки с консольными инструментами. Что весьма полезно при желании автоматизировать свою работу с помощью скриптов, или просто если хочется некоторые длительные и однообразные рутинные действия делать одной или несколькими командами. В общем-то именно UNIX-основа и является для многих привлекательной стороной. А если рассматривать действия, которые вы относите к действиям «рядового пользователя», то если ограничиться ими — да, PC хоть и не выигрывает принципиально, но и не отстает.