Webkit text size adjust что это
Свойство «text-size-adjust» становится более кроссбраузерным
Читателям справочника «Safari CSS Reference» уж конечно попадалось в нём свойство которое, согласно справочнику, управляет отображением текста на мобильнике (iOS) и может принимать одно из трёх следующих значений:
→ «auto» (текст на мобильнике подстраивается автоматически);
→ «none» (размер текста на мобильнике не изменяется);
→ «60%» (или другой процент) означает желаемый относительный размер текста на мобильнике.
Роджер Йоханссон в своём блоге «456 Berea Street» предостерегал от употребления этого свойства и призывал отказаться от него напрочь, потому что однажды столкнулся с сайтом, на котором это свойство имело значение «none» и привело к тому, что размер шрифта нельзя было увеличить не только в мобильнике, но и в обыкновенном компьютере (нажатием ни в одном из браузеров на основе WebKit: ни в Safari, ни в Chrome, ни в OmniWeb, ни в iCab…
Несмотря на это, WebKit — не единственная основа мобильных браузеров; как мы знаем, существует ещё и мобильный Firefox. Разработчики Firefox объявили в вики MDN, что Firefox 11 и более новых версий также станет поддерживать свойство которое, таким образом, становится ещё более кроссбраузерным. (Как XaocCPS мне подсказывает, это свойство под именем поддерживается также и в Windows Phone 7.)
Как Firefox будет воспринимать значение «none», покажет время. Даже если и нормально, то я бы поостерёгся натравливать на это значение, а не то в WebKit результат выйдет малоприятным.
Неизвестное свойство font-size-adjust
December 10, 2013
При создании CSS-правил сталкивались ли вы с ситуацией, когда при откате (fallback) шрифта у последнего менялась пропорциональность и текст начинал выглядеть больше или меньше оригинального?
Возможно, новое замечательное свойство font-size-adjust из стандарта CSS3 поможет нам исправить ситуацию?
Что делает свойство font-size-adjust
Свойство font-size-adjust позволяет установить оптимальный коэффициент пропорциональности при использовании отката шрифта; если шрифт-заменитель имеет коэффициент пропорциональности, отличающийся от такого же коэффициента у главного шрифта, высота текста x-height (которая приблизительно равна размеру буквы х этого шрифта в нижнем регистре) останется неизменной.
Давайте рассмотрим рисунок ниже:
Как видим на рисунке, шрифт Baskerville и Georgia имеют разный коэффициент пропорциональности. Если произойдет замещение шрифта (с учетом того, что шрифт Baskerville является главным), то в реальности размер шрифта визуально будет больше, при одинаковой величине.
Теперь, если принимать во внимание картинку “Сравнение двух шрифтов”, то нетрудно представить, что произойдет при такой замене (откате).
Как определить значение свойства font-size-adjust
Отрывок из спецификации W3C однозначен:
У вас все квадраты на странице примера имеют одинаковую высоту? Что я говорила?
Пример работы свойства font-size-adjust
Для того чтобы показать, как в действительности работает свойство font-size-adjust для текста, мною был создан следующий пример.
На этой странице font stack состоит из следующих шрифтов: Calibri, Lucida Sans и Verdana (именно в этом порядке шрифты должны отображаться на странице в окне браузера).
Браузер Safari генерирует эту страницу следующим образом:
А вот так генерирует эту страницу браузер Firefox:
Как видите, браузер Firefox поддерживает одинаковую x-высоту ( x-height ) букв в зависимости от того, какой шрифт используется.
Мною не рассматривался вопрос выравнивания текста (свойство text-align ), так как цель этой статьи была показать, каким образом свойство font-size-adjust может быть применено для сохранения целостности и удобочитаемости текста.
Заключение
Признаюсь, что я не тестировала свойство font-size-adjust в реальных условиях, поэтому была бы рада услышать ваши отзывы по этому поводу. Данное свойство на сегодняшний день поддерживается только браузером Firefox версии от 1.0 до 3.0.
Safari Web Content Guide
Customizing Style Sheets
Although configuring the viewport is an important way to optimize your web content for iOS, style sheets provide further techniques for optimizing. For example, use iOS CSS extensions to control text resizing and element highlighting. If you use conditional CSS, then you can use these settings without affecting the way other browsers render your webpages.
Read Optimizing Web Content for how to use conditional CSS and CSS Basics for how to add CSS to existing HTML. See Safari CSS Reference for a complete list of CSS properties supported by Safari.
Leveraging CSS3 Properties
Allows you to use an image as the border for a box. See CSS Property Functions for details.
Creates elements with rounded corners. See Customizing Form Controls for code samples. See CSS Property Functions for details.
Adjusting the Text Size
In addition to controlling the viewport, you can control the text size that Safari on iOS uses when rendering a block of text.
Adjusting the text size is important so that the text is legible when the user double-taps. If the user double-taps an HTML block element—such as a
Figure 4-1 Comparison of text adjustment settings 
Listing 4-1 shows setting this property for different types of blocks using inline style in HTML.
Listing 4-1 Setting the text size adjustment property
Controlling Layout with Fixed Positioning
CSS controls the placement of content within the viewport. Use the position CSS property to keep portions of the layout in view regardless of page scrolling. To use fixed positioning set the margins, padding, and size of an object with CSS. Then add the position property with a value of fixed as follows:
The fixed value enforces the other placement information regardless of scrolling and resizing.
Highlighting Elements
The syntax for setting this CSS property is:
This is an inherited property that changes the tap highlight color, obeying the alpha value. If you don’t specify an alpha value, Safari on iOS applies a default alpha value to the color. To disable tap highlighting, set the alpha to 0 (invisible). If you set the alpha to 1.0 (opaque), then the element won’t be visible when tapped.
Listing 4-2 Changing the tap highlight color
Note that changing this behavior does not affect the color of the information bubble when the user touches and holds.
Now when the button is tapped and held on iOS, the button changes to the specified color without the surrounding transparent gray color appearing.
Copyright © 2016 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2016-12-12
Адаптивная верстка писем, всё о ней и не только
Адаптивная верстка писем отличается от привычной веб-вёрстки из-за особенностей интерпретирования в различных веб-интерфейсах и почтовых клиентах.
Давайте на примерах рассмотрим, как добиться хорошего отображения письма во всём разнообразии ISP и почтовых клиентов.
Как выглядит общий шаблон адаптивного письма:
Разберём по этапам код: что и зачем мы добавили.
Чтобы решить проблему с автомасштабированием писем в iOS 10 и iOS 11, мы добавили:
не даёт устройствам на iOS изменять контент письма для удобства чтения. Обычно это противоречит дизайну и может поломать вёрстку:
Перейдём к телу письма — раздел body. Цвет фона веб-интерфейса может быть различным, поэтому необходимо всё обернуть в таблицу с желаемым цветом фона, даже если он белый, как в данном случае:
Из-за ограниченной поддержки стилевых свойств, например max-width, почтовыми клиентами Outlook 2007–2016, а также IE-подобными почтовыми клиентами Outlook 2003 и Lotus Mail в условных комментариях необходимо построить вспомогательную табличную структуру, которая ограничит ширину письма в этих почтовых клиентах:
После этого следует основная контентная таблица с шириной 100% и ограничением максимальной ширины в 600 px.
Что нужно помнить при емейл-вёрстке:
Адаптивная верстка писем. Основные элементы
Отступы
Платформы по-разному работают с вертикальными и горизонтальными отступами.
Например, в начале 2013 года оutlook.com начал вырезать отступы margin из кода емейлов. В результате для создания в емейле необходимых интервалов по горизонтали приходится использовать свойство отступов padding. Осложняет ситуацию то, что почтовый клиент Outlook не поддерживает отступы padding для div, а отступы margin — поддерживает. В связи с этим лучше отказаться от использования как padding, так и margin.
Горизонтальный отступ можно сделать с помощью пустой ячейки с символом неразрывного пробела. Чтобы задать отступ справа и слева, можно создать вложенную таблицу меньших размеров. Вертикальный отступ можно задать следующим образом:
Outlook 2013 имеет ещё одну интересную особенность: при создании ячейки меньше 19 пикселей в высоту она растянется до 19 пикселей. Чтобы этого избежать, вы можете добавить стилевое свойство line-height при описании стиля ячейки.
Текст
При оформлении текста также есть ряд особенностей. Используйте теги, не имеющие специфического оформления по умолчанию, — span. От использования p, h1–h6 и т. д. следует отказаться.
Для родительской ячейки или блока следует указать line-height. Так как в различных веб-интерфейсах и почтовых клиентах отображение по умолчанию для текста может отличаться, необходимо в явном виде прописывать следующие стилевые свойства:
Если учесть эти рекомендации, то оформление текстового блока будет иметь следующий вид:
Ссылки
Оформление ссылок аналогично оформлению обычного текста, соответственно, используется тег «a» и появляется атрибут href. А также для ссылок в письмах необходимо указывать атрибут target со значением _blank для открытия их в новом окне.
Цвет ссылок следует задать в явном виде и прописать стилевое свойство text-decoration с желаемым значением, так как во многих почтовых клиентах и веб-интерфейсах данное свойство имеет значение по умолчанию underline у ссылок.
Ссылка будет иметь вид:
Изображения и фон
Работа с изображениями в письмах также имеет ряд особенностей. Помимо обязательных атрибутов (src и alt), здесь необходимо в явном виде указывать размеры (width и height) изображения, а также для исключения нежелательных отступов прописывать стилевое свойство display со значением block:
Если в ячейке содержится только одно изображение, которое в высоту не превышает 19 px, то у этой ячейки следует прописать стилевое свойство line-height с указанием необходимой высоты — для исключения проблем отображения в Outlook 2013.
В большинстве почтовых клиентов и в некоторых веб-интерфейсах (outlook.com, в некоторых случаях yahoo и в некоторых случаях gmail) изображения по умолчанию не загружаются, поэтому необходимо обеспечить приемлемое отображение без картинок, для этого используйте альтернативный текст (alt), стилизованный под дизайн письма, фоновые цвета и т. д.
Так как речь идёт о современных адаптивных письмах, нельзя не упомянуть про Retina-адаптацию. Под этим термином подразумевают подготовку изображений для чёткого отображения на экранах с повышенной плотностью пикселей.
При вставке изображений в адаптивное письмо не всегда можно указать размеры width и height в пикселах, иногда приходится указывать в процентах: часто у креативов прописывается ширина 100%. При этом большинство веб-интерфейсов и почтовых клиентов растянут данное изображение на 100% ширины родительского блока, однако Outlook 2007–2016 отобразит изображение в масштабе 1:1. Поэтому ширина такой картинки должна совпадать с выводимой шириной.
Фоновые изображения
Outlook 2007–2016 не поддерживает фоновые изображения. Исключением является фоновое изображение, прописанное в body. Однако применение данного приёма сильно повышает риск попадания письма в спам, так что использовать его не рекомендуется.
Данное ограничение можно обойти, используя VML. Для удобного его применения можете воспользоваться нашим сервисом.
Товарная сетка
Базовым подходом при адаптации писем является «резиновая» вёрстка. Для обеспечения удобного взаимодействия с письмом на небольшом экране мобильного устройства и на экране стационарного компьютера или ноутбука часто применяется приём блочного перестроения.
Он основан на применении инлайновых блоков. При уменьшении экрана, когда блоки перестают помещаться, они перестраиваются один под другой:
Так как Outlook 2007–2016 не поддерживает плавающие блоки, то специально для них строится вспомогательная структура в условных комментариях:
Код, заключённый между:
будет проигнорирован всеми почтовыми клиентами, кроме Оutlook 2007–2016 и IЕ-подобными почтовыми клиентами.
А каждый из блоков будет иметь следующую структуру:
Также в письмах иногда встречается ситуация, когда блоки расположены в шахматном порядке, однако при перестроении желательно сохранить логическое следование блоков и перестраивать не правый блок под левый, а наоборот — левый блок под правый. Это можно сделать, поменяв направление текста, выглядеть это будет следующим образом:
Адаптивная верстка писем. Прочие элементы и приёмы
Невидимый прехедер
Практически все веб-интерфейсы выводят рядом с темой письма также и первый текст:
В рассылках это обычно техническая информация, вроде «отписаться» и «открыть в браузере», что явно не мотивирует подписчика открыть письмо, однако, контролируя выводимый текст, можно значительно повысить шанс открытия письма.
Для этого следует добавить в самое начало html-тела письма код со следующей структурой:
Использование невидимого прехедера может негативно сказаться на доставляемости, поэтому используйте данный приём аккуратно и тщательно следите через постмастер за доставляемостью.
Видео в письмах
С выходом iOS 10 стандартный почтовый клиент Mail вновь стал воспроизводить html5-видео, однако оптимальный вариант вставки видео в письмо — прямая ссылка на youtube-видео, поставленная на изображение.
При такой реализации видео отобразится на слое в веб-интерфейсах Mail.ru (около 55%) и Gmail (около 14%). При этом на большинстве мобильных устройств видео будет открыто в приложении Youtube, без открытия браузера.
Недостатком такого подхода является невозможность собрать статистику кликов, т. к. ссылка на Youtube должна быть прямой, и отслеживание кликов у данной рассылки придётся отключить в вашей ESP.
Тестирование
Важнейший этап вёрстки — тестирование писем. Лучший способ по-прежнему — ручная проверка отображения письма в различных веб-интерфейсах и почтовых клиентах, в этом может помочь наш бесплатный сервис для отправки «сырой» вёрстки писем в виде архива. Необходимо знать, какие платформы используют ваши подписчики, каким почтовым провайдерам отдают предпочтение, и провести ручную проверку хотя бы в самых популярных из них.
Для ускорения процесса тестирования можно воспользоваться сервисами Litmus и EmailOnAcid, однако это не отменяет необходимости проверки отображения каждого отдельного письма вручную.
В статье упоминались некоторые сервисы, ресурсы и инструменты, которые несомненно будут полезны верстальщику писем и не только. Приведу небольшой список полезных ресурсов.
Инструменты и сервисы:
Email buttons — генератор кнопочек с использованием VML.
Background generator — вставка фоновых изображений в письма с использованием VML.
Litmus — тестирование отображения писем.
Email On Acid — альтернатива Litmus: тестирование отображения писем.
Полезные материалы:
Блог Litmus — лидер рынка емейл-тестирования. Интересные кейсы и последние новости из мира емейл-маркетинга и вёрстки емейл-писем.
Блог Email On Acid — интересные кейсы и последние новости из мира емейл-маркетинга и вёрстки емейл-писем.
EmailsLab — первый блог о емейл-маркетинге, рассказывает о том, как сделать письма эффективными.
Tod’s blog — интересные кейсы и полезные материалы о вёрстке и разработке.
CSS Mobile Text Size Adjustment Module Level 1
More details about this document
Abstract
This module contains features of CSS relating to one possible mechanism for adapting pages designed for desktop computer displays for display on smaller screens such as those of mobile phones. This mechanism involves displaying a scaled down display of the Web page and allowing the user to pan and zoom within that display, but within that scaled down display making certain text and similar elements larger than specified by the page author in order to ensure that when a block of wrapped text is zoomed to the width of the device (so it can be read without side-to-side scrolling for each line), the text is large enough to be readable.
CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, etc.
Status of this document
This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.
Please send feedback by filing issues in GitHub (preferred), including the spec code “css-size-adjust” in the title, like this: “[css-size-adjust] …summary of comment…”. All issues and comments are archived. Alternately, feedback can be sent to the (archived) public mailing list www-style@w3.org.
The following features are at risk:
1. Introduction
A common mechanism for displaying Web pages that were designed for large desktop displays on much smaller displays such as those of mobile phones involves allowing the user to pan and zoom around within a view of the Web page drawn as though it were drawn into the width of a typical desktop Web browser display. The ability to pan and zoom the page lets the user both see an overview of the page and zoom in to specific parts to read or interact with them.
One common problem with this type of interaction occurs when the user wants to read a large block of text. It might be that a block of text within this desktop-formatted page might be laid out so that when the user zooms in so that the text is large enough to read, each line of text is wider than the display on the small device. This means the user needs to scroll side to side to read each line of text, which is a serious inconvenience to the user.
One way for software that displays Web pages or other CSS-formatted content on a mobile device is to make some of the text larger so that this problem does not occur. The goal of this enlargement is to make the text big enough so that when the block it is in is scaled to the width of the display, the text is large enough to read. At the same time, this needs to be done with minimal disruption to the overall design of the page.
While implementations of CSS are not required to use this technique, this module describes how implementations of CSS that do use this technique must do so. In other words, while implementations of CSS are not required to implement this module, this module nonetheless places requirements on implementations of this module.
This module describes how this size adjustment works and describes a new CSS property that authors of CSS can use to provide hints to the implementation about which text or other elements should or should not be enlarged.
1.1. Module interactions
This module adds additional features that are not defined in [CSS21]. These features may lead to a different size being computed than would be computed when following [CSS21] alone.
1.2. Value Definitions
In addition to the property-specific values listed in their definitions, all properties defined in this specification also accept the CSS-wide keywords as their property value. For readability they have not been repeated explicitly.
2. Default size adjustment
This section defines the default size adjustment rules. These rules are then referenced by the definition of the text-size-adjust property in the following section.
All of the subsections of this section need significant refinement: additional detail, verification that the detail already present is correct, etc.
It’s not clear how much this section should define precise behavior versus how much it should allow future room for innovation and improvement.
2.1. Types of boxes adjusted
The default size adjustment affects text and form controls, whether those form controls contain text (e.g., text inputs, selects) or do not (e.g., radio buttons, checkboxes).
2.2. Conditions that suppress adjustment
A number of conditions suppress the default adjustment because these conditions are associated with layouts for which the user experience would be worsened by size adjustment rather than improved by it. These conditions are:
2.3. Calculation of default adjustment
The size adjustment involves multiplication of sizes by a ratio determined by the minimum block text size and the computed value of font-size. This ratio must be at least the first divided by the second; however, in order to maintain differentiations between font sizes, it should often be slightly larger. Define this with more detail/precision.
3. Size adjustment control: the text-size-adjust property
In only one current engine.
Renderers must use the default size adjustment when displaying on a small device. Renderers must not do size adjustment when displaying on a small device. When displaying on a small device, renderers must not do size adjustment but instead the computed value of font-size must be multiplied by this percentage.
Note: This means that ‘text-size-adjust: 100%;’ is equivalent to ‘text-size-adjust: none;’.
Negative values are invalid.
«Small device» is not well defined. We should clearly specify when text size adjustment should apply. For example, in practice a large tablet is considered by vendors to be a small device.
4. Acknowledgments
Conformance
Document conventions
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
This is an example of an informative example.
Note, this is an informative note.
Tests relating to the content of this specification may be documented in “Tests” blocks like this one. Any such block is non-normative.
Conformance classes
Conformance to this specification is defined for three conformance classes:
style sheet A CSS style sheet. renderer A UA that interprets the semantics of a style sheet and renders documents that use them. authoring tool A UA that writes a style sheet.
A style sheet is conformant to this specification if all of its statements that use syntax defined in this module are valid according to the generic CSS grammar and the individual grammars of each feature defined in this module.
A renderer is conformant to this specification if, in addition to interpreting the style sheet as defined by the appropriate specifications, it supports all the features defined by this specification by parsing them correctly and rendering the document accordingly. However, the inability of a UA to correctly render a document due to limitations of the device does not make the UA non-conformant. (For example, a UA is not required to render color on a monochrome monitor.)
An authoring tool is conformant to this specification if it writes style sheets that are syntactically correct according to the generic CSS grammar and the individual grammars of each feature in this module, and meet all other conformance requirements of style sheets as described in this module.
Partial implementations
So that authors can exploit the forward-compatible parsing rules to assign fallback values, CSS renderers must treat as invalid (and ignore as appropriate) any at-rules, properties, property values, keywords, and other syntactic constructs for which they have no usable level of support. In particular, user agents must not selectively ignore unsupported component values and honor supported values in a single multi-value property declaration: if any value is considered invalid (as unsupported values must be), CSS requires that the entire declaration be ignored.
Implementations of Unstable and Proprietary Features
To avoid clashes with future stable CSS features, the CSSWG recommends following best practices for the implementation of unstable features and proprietary extensions to CSS.
Non-experimental implementations
Once a specification reaches the Candidate Recommendation stage, non-experimental implementations are possible, and implementors should release an unprefixed implementation of any CR-level feature they can demonstrate to be correctly implemented according to spec.
To establish and maintain the interoperability of CSS across implementations, the CSS Working Group requests that non-experimental CSS renderers submit an implementation report (and, if necessary, the testcases used for that implementation report) to the W3C before releasing an unprefixed implementation of any CSS features. Testcases submitted to W3C are subject to review and correction by the CSS Working Group.