Обновить
46
0
Marat Tanalin@MTonly

Пользователь

Отправить сообщение
Начальнику полезно озвучить, какова текущая доля IE8 в России. :-)
Проблема не в том, что без JS сайт не работает, а в ложном предположении, что отключённый JS говорит об устаревшем браузере (иначе говоря, божий дар с яичницей):

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

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

Т. е. имеем не только ошибочную увязку не связанных вещей (отлючённый JS и устаревший браузер), но и технически безграмотное решение, снижающее удобство пользователя, а также нежелание со стороны их веб-разработчиков пошевелиться и элементарным образом решить этот тривиальнейший вопрос. Какой там UTF-8, что вы. ;-)
Кстати, VK вы, вероятно, переоцениваете. Например, они уже три месяца (после сообщения от автора этих строк) не могут «исправить» тривиальную ошибку типа «тёплое с мягким», из-за которой пользователя современного браузера перенаправляют на страницу «Вы используете устаревший браузер» лишь на основании отключённого JavaScript:

<noscript><meta http-equiv="refresh" content="0; URL=/badbrowser.php"></noscript>

Дополнительно впечатляет, что баг-трекер у них тоже есть, но там, судя по всему, почему-то доступен только поиск без возможности добавления новых баг-репортов, поэтому приходится действовать приватно через раздел «Помощь».
Тем, что один реальный символ представлен более чем одним символом на уровне кода. Если есть универсальная кодировка, где все символы, кроме 4-х спецсимволов HTML, можно хранить непосредственно (UTF-8), нет смысла использовать другую кодировку. Экономия трафика путём использования ограниченной 8-битной кодировки вместо универсальной UTF-8 — это, пожалуй, экономия на спичках.
hasLayout можно включить разными способами, и каждый работает чуть по-своему. По моему опыту, самый «пуленепробиваемый» — height: 1px (или любая другая явно заданная ширина или высота в пикселах) (именно px, т. к. % в определённых ситуациях к желаемому результату не приводил) для IE6 и min-height: 0 для IE7.

Если hasLayout уже включён, например, с помощью ширины, то zoom для этой цели, разумеется, уже не нужен. Кстати, с zoom в контексте включения hasLayout были определённые проблемы, поэтому я его для этой цели не использовал.
Да, современные браузеры при отправке форм вынужденно экранируют символы, отсутствующие в наборе символов используемой на странице кодировки. Эти коды — и есть подстановки (entities), с которыми в общем случае лучше не связываться без реальной необходимости. А реальная необходимость одна — экранирование служебных символов HTML (<, >, &, ") в текстовых узлах и значениях атрибутов.

И даже в «мессенджере» пользователь может вставить фрагмент текста, откуда-то его скопировав. ;-)
Приведите пожалуйста пример спецсимволов, которые люди могут использовать в мессенджере общего назначения, и которых нет в однобайтовой кодировке)
Не уверен, что вы подразумеваете под мессенджером общего назначения, а на сайтах вполне могут использоваться, например, такие символы:

→ ← ↓ ↑ μ × − ² ³

Просто не вижу смысла в юникоде, когда в сообщениях только русский и латиница. И кстати — ВК для российских пользователей использует CP1251, насколько я знаю.
Подобные доводы, равно как и упоминание CP1251 вместо Windows-1251 пробуждает во мне впечатляющие воспоминания об одном человеке, который писал движок сайта на Delphi. :-)
либо прописать нужным блокам (например, вторым в контейнере) особый класс во всех местах в HTML, либо написать одну JavaScript функцию, и в ней назначить нужные стили через style.
Можно ещё добавлять классы средствами JS.

IE7 (и IE8 в режиме эмуляции) добавляет слева от всех пунктов отступ
Такого бага уже не припомню (давно IE9+, а задолго до этого — IE8+), но включение так называемого hasLayout с помощью min-height: 0 для IE7 и height: 1px для IE6 решало большинство абсурдных проблем, свойственных IE 6/7. У списков была другая проблема — увеличенный относительно номинального line-height даже при list-style: none для списка, обходилась с помощью vertical-align: top для LI.

А что насчёт IE6?
IE6 (0,05%) уже давно нет. Как и IE7 (0,2%) и, в общем-то, IE8 (0,6%). Для них достаточно использовать подход с унифицированной упрощённой таблицей стилей, основанной на семантике.
Чтобы не иметь проблем со спецсимволами и их вставкой с помощью подстановок (entities)? ;-)

Про Gzip тоже забывать не стОит.
7-страничный PDF-фрагмент существует, значит есть и полная версия, из которой этот фрагмент вырезан. ;-)
На текущий момент только две компании достаточно активно продают телевизоры на базе матрицы OLED: Samsung и LG.
Samsung на рынке OLED-телевизоров сейчас практически нет и по сути не было — не считая формально доступного на Amazon единственного (либо залежавшегося, либо на самом деле несуществующего) экземпляра OLED-телевизора Samsung первого и единственного для Samsung поколения, выпущенного на рынок ограниченной партией, скорее всего, лишь для того, чтобы не [совсем] ударить в грязь лицом на фоне успехов LG на поприще OLED-телевизоров.
Эту технологию называют WRGB или WOLED-CF: помимо привычных трех цветов добавляется субпиксель белого цвета — в этом случае цветные фильтры располагаются сверху (RBG и W).
4-й субпиксел (вероятно, именно он отвечает за функцию, которую LG называет Color Refiner) никак не связан с фактом использования белых субпикселов с цветовыми фильтрами. Суть технологии LG/Kodak в том, что все субпикселы на самом деле белые (сделаны из одного и того же материала), а красный, зелёный и синий цвета получают применением цветовых фильтров, как в ЖК-дисплеях. В дополнительном белом субпикселе (которого могло бы и не быть, и светодиоды под 3-мя цветовыми фильтрами не перестали бы быть белыми, а технология — WOLED-CF) фильтра, соответственно, просто нет.
Когда уже издательства начнут использовать для кода более плотные моноширинные шрифты вместо трудновоспринимаемых шрифтов типа Courier New с патологически тонкими штрихами? Например, в PDF-примере данной книги штрихи букв во фрагментах кода почти вдвое (!) тоньше штрихов основного текста — это автоматически делает книгу значительно менее ценной.
Такие UTF-8-строки — на самом деле набор байтов:
The type of a u8"..." string literal is const char[].
А нужен бы стандартный способ работы с массивами нормализованных символов как неделимых логических сущностей — в частности со встроенной нормализацией (простым использованием UTF-32 это автоматически не решается, т. к. один символ может быть образован более чем одним code point).
имя короткое и оно плохо ищется
Кстати, удивительно, что в IDE-программе, априори способной на синтаксический разбор кода, искать обычно можно лишь текст без возможности указания типа искомой сущности — например, имя переменной, имя функции или что-то ещё.
Смешивать на одном логическом уровне разные сущности (в данном случае — имена элементов типа tbody и действия типа each или render) — путь в никуда. Вот добавят в стандарт HTML элементы each или render, и приехали. ;-)
Вероятно, как в Firefox, используются системные декодеры.
Не оч. удачная инфографика: сразу неочевидно, к какому из событий относится каждый из относительно больших фрагментов блеклого текста — расположенному над ним или сбоку от него, или это вообще «заметки на полях», к конкретным событиям не привязанные. И, да, было бы здорово видеть SVG- или HiDPI-вариант.
В ассортименте OCZ поначалу были полноразмерные 3,5"-накопители типа Colossus, а также 3,5"-варианты (чуть дешевле 2,5"-вариантов) Vertex 2 и Agility 2 (последние две модели при этом были такими же тонкими, как модели типоразмера 2,5").

Сейчас форм-фактор 3,5", похоже, применяется лишь в некоторых корпоративных накопителях других производителей типа HP, т. к., собственно, особого смысла нет — текущие объёмы Flash-памяти при современных техпроцессах без проблем умещаются в 2,5 дюйма.
Разве 3D V-NAND намного более живучая по сравнению с классическими MLC/TLС NAND?
Да. Благодаря использованию менее тонкого техпроцесса (у 3D V-NAND от Samsung сейчас 40 нм).

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность