Expected Behavior:
Display the digit “6”.
Actual Behavior:
The rendered character appears as a composite glyph—the left half resembles “9” and the right half resembles “6”, resulting in a malformed digit.
other examples：
Environment & Characteristics:
Occurs intermittently on iPhone 15 Pro Max and iPhone 16 Pro Max.
Reproducible within the Taobao App, specifically in WKWebView.
Font Used:
AlibabaSans102_v1_TaoBao-Bd.ttf
CSS
RSS for tagCascading Style Sheets (CSS) is a style sheet language used for describing the presentation of a document written in a markup language like HTML.
Posts under CSS tag
10 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I'm using a CSS filter to achieve dark mode for my HTML page. I know it's imperfect, but I have no choice for many reasons.
However, I found that the CSS filter produces incorrect colors in iOS 26.2 WebView, while it works fine in iOS 18.6.2 WebView.
Here is my HTML and CSS filter:
<html>
<head>
<style>
.filter_container {
/* invert colors for the entire page */
filter: invert(1) hue-rotate(180deg);
}
.filter {
/* restore colors for specific elements, such as img */
filter: hue-rotate(180deg) invert(1);
}
</style>
</head>
<body>
<div>original & bgcolor+filter & img+filter</div>
<table>
<tr>
<td>
<div style="display:flex; gap:1px; align-items:center; justify-content:center;">
<div class="origin_container"><div class="origin" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px;"></div></div>
<div class="filter_container"><div class="filter" style="background-color:#FFFFFF; height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></div></div>
<div class="filter_container"><img class="filter" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADwAAAA8CAYAAAA6/NlyAAAAdklEQVR4nOXOQQEAIACEMKR/57OFPliCnW0jRGIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkRmIkxt+B1y6HmAR0uIzOQQAAAABJRU5ErkJggg==" style="height:60px; width:60px; border-style: solid; border-color: #000000; border-width: 1px"></img></div>
</div>
<div style="text-align:center;">#FFFFFF</div>
</td>
...many other colors
</table>
</body>
</html>
It works fine in iOS 18.6.2 WebView:
But renders incorrectly in iOS 26.2 WebView:
On iOS Devices with ProMotion (120HZ) if you animate Elements on your Page with animation-timeline you get Ghosting Effects.
You can not see the Ghosting with a Simulator or on Screenshots, only on real Devices.
To Reproduce I made a Minimal Example:
https://codesandbox.io/p/sandbox/120hztest-xrwgtc
When you scroll quickly on the Page with an iOS 120HZ Device (https://en.wikipedia.org/wiki/List_of_smartphones_with_a_high_refresh_rate_display)
you will see ghosting on the Top of the right Element (animation-timeline) and no ghosting on the other animated Element.
(I edited the Screenshot, to Illustrate how the Effect looks like, since it is only visible on the real Display)
As of iOS 26.1, Safari and WebKit views have an issue when rendering the <details> html tag.
The disclosure-closed icon / character appears as an emoji arrow ▶️ instead of the unicode character ▸ (U+25B8 - Black Right-Pointing Small Triangle)
For example:
<details>
<summary>Summary</summary>
<p>Additional details....</p>
</details>
This wasn't the case in iOS 26.0 / iOS 18.
From what I can observe it seems ▶ (U+25B6 - Black Right-Pointing Triangle) may be used in iOS 26.1 which renders as the emoji ▶️ on iOS (at least as far back as iOS 18).
The only workaround I found for the moment is to specify explicit CSS to revert back to using the ▸ (U+25B8 - Black Right-Pointing Small Triangle)
details > summary {
list-style-type: "▸ ";
}
details[open] > summary {
list-style-type: "▾ ";
}
Is this expected? I've filed a feedback for this FB20997955.
Thanks!
System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
After updating to the new iOS, in Safari, my overlays and backdrops using 100dvh no longer cover the full screen there's now a gap at the bottom.
Switching to 100vh fixes it, but that causes scrolling issues on older Safari versions since 100vh includes extra height.
Has anyone else experienced this? What's the recommended fix that works across iOS versions?
1. System/device combinations where the issue does not occur:
Physical device: iOS 26.0 (23A5318c) + iPhone 16 Pro Max
2. System/device combinations where the issue does occur:
System versions:
Physical device: iOS 26.0 (23A5330a), iOS 26.0 (23A340)
Simulator: iOS 26.0 (23A339)
Device models:
Physical device: iPhone 12
Reproducible in Safari, WKWebView, and UIWebView:
Yes
Actual behavior
In WebView (and identically in Safari):
Before the keyboard is shown, header/footer elements with position: fixed are correctly aligned with the screen viewport. Scrolling up/down works as expected.
After the keyboard appears, the visualViewport position changes.
Bug: When the keyboard is dismissed, visualViewport.offsetTop does not reset to 0. As a result, fixed header/footer elements remain misaligned:
When scrolling down, the position looks correct.
When scrolling up, the header/footer are visibly offset.
Steps to reproduce
Focus an input field → the keyboard appears
Dismiss the keyboard
Observe that visualViewport.offsetTop remains >0 (does not reset to zero)
position: fixed header/footer elements are misplaced relative to the screen
Expected behavior
After the keyboard is dismissed, visualViewport.height should return to match the layout viewport, and visualViewport.offsetTop should reset to 0.
When scrolling upward, fixed elements should remain correctly positioned within the layout viewport.
Minimal reproducible demo
A simple HTML file containing:
A header and footer with position: fixed
An input element to trigger the keyboard
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover" />
<title>H5 吸顶吸底页面 Demo</title>
<style>
* {
margin: 0;
padding: 0;
box-sizing: border-box;
}
body {
font-family: Arial, sans-serif;
height: 2000px; /* 设置内容高度 */
background-color: #f0f8ff; /* body 背景浅蓝色 */
padding-top: 120px; /* 预留 header 高度 */
padding-bottom: 60px; /* 预留 footer 高度 */
overflow-x: hidden;
}
/* 吸顶 Header */
header {
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 120px;
background-color: #ff6b6b; /* 红色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 24px;
font-weight: bold;
z-index: 1000;
}
/* 吸底 Footer */
footer {
position: fixed;
bottom: 0;
left: 0;
width: 100%;
height: 60px;
background-color: #4ecdc4; /* 青绿色 */
display: flex;
align-items: center;
justify-content: center;
color: white;
font-size: 18px;
font-weight: bold;
z-index: 1000;
}
/* 输入框样式 */
.input-container {
margin: 100px auto;
width: 80%;
max-width: 600px;
text-align: center;
}
input[type='text'] {
padding: 12px;
font-size: 16px;
border: 2px solid #ddd;
border-radius: 8px;
width: 100%;
box-sizing: border-box;
}
input[type='text']:focus {
outline: none;
border-color: #4ecdc4;
}
</style>
</head>
<body>
<!-- 吸顶 Header -->
<header>吸顶 Header (120px)</header>
<!-- 主体内容 -->
<div class="input-container">
<input type="text" placeholder="请输入内容..." />
</div>
<!-- 吸底 Footer -->
<footer>吸底 Footer (60px)</footer>
</body>
</html>
Bug Report:
Safari refuses to render content that is position: fixed or position: sticky if it goes below the iOS 26 navigation controls at the bottom of the browser. Since the controls are transparent and floating, this is a problem as fixed content is effectively unable to reach the bottom of the page. Attempting to move it below 100vh causes it to be cut off rather than rendering behind the navigation elements.
Here is some code reproducing the issue:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<style>
html,
body {
margin: 0;
padding: 0;
background-color: #363636;
}
#just-a-bird {
position: fixed;
bottom: -100px;
width: 300px;
height: auto;
background: red;
}
</style>
</head>
<body>
<img id="just-a-bird"
src="https://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg/640px-Cattle_tyrant_%28Machetornis_rixosa%29_on_Capybara.jpg">
</body>
</html>
With Swift being brought to new places, is anyone working on interoperability with PHP? I'd love to replace much of my PHP and Javascript web code with Swift (and ideally SwiftUI for UI design). Are there any projects/people working in this space?
Hello,
I am looking for help with displaying Smart Banners on mobile devices. What is the preferred coding that can have Smart Banners appear on all devices? I am having an issue where an Smart Banner is not properly functioning as I would like it to. I would like the CTA (Call-To-Action) to be positioned on the top of a mobile screen. If a user has the mobile app already, it should read OPEN and opens into the app when it is clicked. If the user does not have the app, it should read GET and take a user to the mobile app store when it is clicked.