Re: Intent to prototype: glyph-scale-factor descriptor for @font-face rules

2021-03-15 Thread
在 2021年3月15日星期一 UTC+8 下午8:39:36, 写道:
> Summary: For a given "font size" as expressed e.g. in CSS px or points, 
> different fonts can vary significantly in how visually large they look. 
> The nominal "font size" does not necessarily relate to any specific 
> dimension of the glyphs; it sizes the coordinate space within which the 
> glyph shapes are drawn, but different designs may fill that space in 
> very different ways. 
> The proposed glyph-scale-factor descriptor (name to be bikeshedded) will 
> allow authors to adjust the scaling of individual fonts loaded using 
> @font-face, to better harmonize the visual sizes of different designs, 
> or to more closely match a fallback face to a resource that may be 
> swapped in later, thereby minimizing visual layout shift when the final 
> font becomes available. 
> Unlike modifying the font-size property, this will scale the glyphs (and 
> metrics) of the font but will *not* affect things like the CSS 'em' 
> unit. It affects how glyphs scale within the font's em square, not the 
> size of the em square itself. 
> Bug: 
> Standard: This is currently under discussion for CSS Fonts 5; details 
> still to be worked out. See 
> Platform coverage: All 
> Preference: layout.css.glyph-scale-factor.enabled 
> DevTools bug: None needed. (More generally, it would be awesome to have 
> a @font-face rule inspector in DevTools -- distinct from the existing 
> font *properties* inspector; such an inspector would expose this along 
> with the other @font-face descriptors. But that's not specific to this 
> new descriptor.) 
> Other browsers: 
> Blink: Considering (already experimented with possible implementation, 
> see 
> Webkit: Present in CSS WG discussions but no clear signals yet AFAIK. 
> web-platform-tests: To be added to web-platform/tests/css/css-fonts (as 
> .tentative initially, until spec is finalized).

It seems that this is more useful for emoji fonts, have you researched it?
dev-platform mailing list

Re: Intent to implement: -webkit-line-clamp

2020-03-07 Thread
Chrome began standardizing the line-clamp property.!msg/blink-dev/SVD5wSqVwKU/eY28UiNkAwAJ
dev-platform mailing list

Re: Intent to ship: multi-keyword values on the CSS 'display' property

2019-08-22 Thread
Is there a plan to implement multi-valued table | flex | grid? E.g display: 
inline flex.
dev-platform mailing list

Re: Intent to Implement: CSS Scroll Snap Points

2014-12-09 Thread 冰凉
dev-platform mailing list

Re: Intent to ship: CSSOM-View Scroll-Behavior CSS Property and CSSOM-View DOM Extensions for Smooth Scrolling

2014-11-03 Thread 冰凉
在 2014年10月28日星期二UTC+8上午4时32分46秒,Kip Gilbert写道:
 As of October 28, 2014 I intend to turn on by default CSSOM-View
 Scroll-Behavior CSS Property and CSSOM-View DOM Extensions related to
 smooth scrolling.  They have been developed behind the
 layout.css.scroll-behavior.enabled and preferences.  Firefox is
 the first UA to ship this feature.  Chrome has an implementation,
 disabled by default.
 Platform coverage: This will be enabled on all platforms except for
 Fennec.  (Fennec will be enabled once the C++ based APZC
 implementation ships for Fennec)
 This feature was previously discussed in this intent to implement
 Further discussions occurred on www-style:
 Bugs to turn on by default:
 Bug 1087562 - Enable CSSOM-View scroll behavior CSS property by
 default (Except for Fennec)
 Bug 1087559 - Enable CSSOM-View scroll behavior DOM method extensions
 by default (Except for Fennec)
 Since the original intent to implement email, the specification has
 evolved.  The CSSOM-View DOM Extensions have been changed to accept
 dictionaries for options and the 'instant' value for scroll-behavior
 has been changed to 'auto'.
 Bug: 964097 - [meta] Implement CSSOM-View smooth scrolling spec
 Link to standard:

a href=#/a

I hope this also has smooth scrolling effect.
dev-platform mailing list