Jump to content

rash

User
  • Posts

    1,953
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by rash

  1. Принципиально не пользуюсь ничем подобным. На нормальных сайтах реклама не мешает, а ее показ может помочь авторам поддерживать сайт. А навязчивая реклама — хороший индикатор того, что надо бы поискать альтернативу этому сайту.
  2. На юзеров, похоже, в этом случае плевать?
  3. *С подозрением* А вы, случайно, не СЕОшник?
  4. А как в таком случае объяснить, что лучше находятся те страницы, которых не касались сеошники? Это тоже субъективное мнение, но поскольку не только мое, то в нем, скорее всего, есть хотя бы доля правды.
  5. Не значит, так лучше не делать, на самом деле, если случай не слишком уж простой и вы не уверены на 100% что в этом случае так делать можно. Тут мы пользуемся тем, что при вычитании оба операнда должны быть числами, и JS по возможности пытается привести их к числам. Это не аналог parseInt, но более подробно рассказать не смогу, потому что автоматическое приведение типов происходит по сложной схеме, которую я сам до конца не знаю и не понимаю.
  6. Точно, это же строки. Ну проще всего total = 0; $("input.Klass").each(function() {total += this.value - 0}) ну или более наглядно и традиционно: total = 0; $("input.Klass").each(function() {total += parseInt(this.value, 10)})
  7. Не проверял, но должно сработать что-то такое (самый простой, вроде бы, вариант). total = 0; $("input.Klass").each(function() {total += this.value})
  8. Эээ, нет. Но какая-то общая стандартная комбинация клавиш для этого так и просится сама собой Уже думал о том, чтобы использовать для этого accesskey.
  9. О, холиварчик, не могу пропустить К счастью я к СЕО не имею никакого отношения, так что все мои доводы — результат собственных выводов. H1 на странице должен быть один не потому, что так требуют сеошники, а потому что этого требует здравый смысл. Страница подразумевает под собой какую-то более-менее однородную информацию, и если она структурируется — у структуры должен быть корень. То есть если мы натравим валидатор на страницу со включенной опцией «show outline», то мы должны получить дерево с одним корнем и (не так принципиально, но желательно) без «провалов» в уровнях. Пример с рефератами Сережи стоило бы структурировать так: «Рефераты Сережи» — вообще не заголовочный элемент. Это название сайта, а на страницах сайта, как правило, не пишут именно о названии сайта. Тема реферата — h1, если он один на странице, и h2 — если на странице выводится несколько рефератов, объединенных по какому-то критерию. Критерий — в h1. Далее содержимое самих рефератов структурируется заголовками более низкого уровня. Получаем логичную и последовательную структуру. Возможно, при использовании section более допустимы несколько заголовков первого уровня, однако и в этом случае эти самые секции/разделы выводятся на страницу по определенному критерию, которому и стоило бы быть корнем структуры документа. В общем, в этом случае требование спецификации противоречит здравому смыслу. В таких ситуациях приоритет, увы, не за спецификацией (во всяком случае, пока я не найду подтверждения, что ее требования оправданы чем-то объективным). А насчет noindex — разве еще какие-то доказательства нужны, после этого?
  10. Доля Не представляю, зачем (а следовательно, никогда и не задумывался, как) эмулировать, например, системные контролы в формах с помощью чего-либо, кроме, собственно, инпутов.
  11. Нет, большое количество элементов в тех случаях действительно нужно. Насчет вложенности — ну тут я, может, преувеличил, в среднем — не так уж и много уровней, да.
  12. Мне на такие случаи как-то везет. Не каждый день, конечно, но несколько было
  13. Переопределение стилей замедляет их применение, особенно на страницах с большим количеством элементов и глубокой вложенностью. Не в весе дело. Может потребоваться, например, в сложном и динамичном интерфейсе.
  14. Кстати, бывают нечастые ситуации, когда рационально по максимуму использовать именно div и span, у них нет стилей по умолчанию, и это иногда бывает весьма хорошо.
  15. Если это требование указано явно — верный и ранний признак того, что заказчик вынесет мозг в дальнейшем. Нет.
  16. 76$?!! Уж лучше подожду доставки Ожидание окупит такую наценку.
  17. Если на десктопе — почему бы не поставить анстейбл-ветку?
  18. Кстати, а Good Parts можно где-то купить оффлайн, чтобы не заказывать из-за границы? Сейчас читаю, книга нравится (но там чистый JS, без акцента на применение в браузерах), но через некоторое время придется ее вернуть Хочется оставить и себе бумажную копию.
  19. В нормальных браузерах везде все нормально с канвасом
  20. rash

    Mac OS

    Ну почитайте То вайфай не работает, то звука нет, и что-то такое постоянно… Ну то есть, конечно, некоторые, подобрав железо и покопавшись по локоть в кекстах, заводят все, но это уже от линуксоидства мало отличается.
  21. rash

    Mac OS

    Разница будет Достаточно почитать какие-нибудь обсуждения хакинтошей на форумах, чтобы в этом убедиться.
  22. Одно другому мешать не должно. Вообще, проблемой это начал считать совсем недавно, но когда оцениваешь полезность того или иного аспекта стандарта, смотришь с точки зрения применимости либо к крупным, либо к мелким проектам (в зависимости от того, над какими сейчас работаешь). И вот для не слишком крупных и мелких проектов переменные меня бы несколько раз могли выручить, тогда как в крупных все не так радужно. А разработчикам стандартов стоит учитывать применимость в задачах разного масштаба. Так что для мелких проектов такую возможность я по-прежнему считаю полезной.
  23. Я знаю. Но именно такая запись выглядит абсурдно. От наследования уходим чуть более красивыми способами (но лишь чуть более красивыми). Хотя наследование — возможность, применяемая браузером, Отключить ее не получится все равно, тут просто на нее не полагаемся. Ну и уходим от селекторов вложенности, что тоже бывает полезно. А какая разница, если поведение стандартизировано и предсказуемо? Большинство проблем происходит от неопределенности. Если все будут вести себя одинаково, то основная масса проблем будет решена продуманной архитектурой. Не язык программирования, а язык оформления. Просто более мощный чем то, что сейчас. Сколь-нибудь серьезную логику поведения все равно в нем не задашь, а базовую логику оформления — так это то, что надо.
  24. rash

    Mac OS

    Я не знаю, кто такой рядовой юзер и что он обычно делает Виндовс традиционно достаточно хорош в лане ГУИ (мелкие огрехи есть у всех, многие проблемы связаны со странностями разработчиков отдельных сторонних программ, но у ОС все более-менее хорошо). У линуксов традиционно хорош командный интерфейс (удачное наследие UNIX-ов), но довольно слаб графический (после многочасового допиливания он становится немного лучше, но все равно с серьезными шероховатостями, даже учитывая все эти композитные оконные менеджеры и прочую клоунаду). Макось не идеальна (идеальных нет, как и среди браузеров, можно долго повторять), хотя более-менее удачно объединяет нормальный ГУИ и хорошие командные оболочки с консольными инструментами. Что весьма полезно при желании автоматизировать свою работу с помощью скриптов, или просто если хочется некоторые длительные и однообразные рутинные действия делать одной или несколькими командами. В общем-то именно UNIX-основа и является для многих привлекательной стороной. А если рассматривать действия, которые вы относите к действиям «рядового пользователя», то если ограничиться ими — да, PC хоть и не выигрывает принципиально, но и не отстает.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy