On Wed, Nov 30, 2022 at 11:54 AM Alex Russell <[email protected]> wrote:
> LGTM1 with nits: > > In the list above, it doesn't seem correct to me that we'll be able to > change this one later if WebKit and Blink agree on a behaviour and the > future spec changes: > > > 1. 887 <https://github.com/w3c/csswg-drafts/issues/887> should define > how the initial-letter relates to line boxes > - We can match when resolved even after ship > > > Is there future compat risk here that we can reduce via WPT tests? > > Best, > > Alex > > On Monday, November 28, 2022 at 4:44:28 AM UTC-8 Koji Ishii wrote: > >> I think the one Yosi pointed out has some compat risks, but majority of >> usages won't be affected, and that we can change Blink if the WG >> resolves to change the spec. >> >> Let me also note that Blink shipping the initial-letter property solves a >> big interoperability issue authors have today. Adjusting the drop caps >> position without the property requires hard coding the font metrics into >> their CSS, and the font metrics vary between Blink/WebKit and Gecko. So >> today, authors must detect the browsers and apply different baseline shift >> values for Blink and Gecko. When Blink ships this property, authors can use >> the property for Blink and WebKit (with prefix), and apply the font metrics >> only for one browser, eliminating the need to detect the browsers. >> >> >> On Mon, Nov 28, 2022 at 10:50 AM Yoshifumi Inoue <[email protected]> >> wrote: >> >>> Thanks for reply! >>> We think these open issues are related feature we don't support yet and >>> edge case except below. >>> >>> 4988 <https://github.com/w3c/csswg-drafts/issues/4988> initial-letters >>> changing used, not computed font-size >>> >>> At this time, the spec uses used font but this issue wants to use >>> computed font. >>> If the resolution is changed to use computed font, meaning of font >>> relative unit "em", "ex", "n" are changed. >>> This can be avoided by using non-font-relative unit. >>> >>> Do you have open issues will cause compatibility risk? >>> -yosi >>> >>> 2022年11月25日金曜日 18:38:06 UTC+9 Yoav Weiss: >>> >>>> That's a lot of open issues :) Can you tell which of them have >>>> compatibility risk once resolved? >>>> >>>> On Thu, Nov 24, 2022 at 1:11 PM Yoshifumi Inoue <[email protected]> >>>> wrote: >>>> >>>>> This is summary of CSS WG Open Issues >>>>> <https://github.com/w3c/csswg-drafts/issues?q=label%3Acss-inline-3+initial-letter+is%3Aopen+> >>>>> discussed with kojii and yosin. >>>>> >>>>> >>>>> 1. 5527 <https://github.com/w3c/csswg-drafts/issues/5527> Hindi >>>>> example for initial letter applicability >>>>> - non-Latin, not supported in the initial release >>>>> 2. 5476 <https://github.com/w3c/csswg-drafts/issues/5476> kerning >>>>> of initial letter when initial letter has negative side bearing >>>>> <https://github.com/w3c/csswg-drafts/issues/5476> >>>>> - New feature, can add without breaking change >>>>> 3. 5425 <https://github.com/w3c/csswg-drafts/issues/5425> Define >>>>> interaction of initial-letter and ::first-line >>>>> - : Add a test of ::first-line + ::first-letter (example >>>>> >>>>> <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3A%3Afirst-line%20%7B%20font-size%3A%20200%25%3B%20%7D%0A%3A%3Afirst-letter%20%7B%20font-size%3A%20300%25%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3EXXXXX%3Cbr%3EXXXX>) >>>>> CL/4054845 <http://crrev.com/c/4054845> >>>>> 4. 5398 <https://github.com/w3c/csswg-drafts/issues/5398> Add new >>>>> value "auto" for initial-letter-align >>>>> - initial-letter-align not supported in the initial release >>>>> 5. 5366 <https://github.com/w3c/csswg-drafts/issues/5366> >>>>> initial-letter >>>>> sizing for non-western scripts >>>>> - non-Latin, not supported in the initial release >>>>> 6. 5244 <https://github.com/w3c/csswg-drafts/issues/5244> top >>>>> metrics for non-Western non-CJK writing systems with obvious top edge >>>>> - : non-Latin, not supported in the initial release >>>>> 7. 5220 <https://github.com/w3c/csswg-drafts/issues/5220> Alternative >>>>> initial-letter-align based on glyph bounds >>>>> - New feature, can add without breaking change >>>>> 8. 4988 <https://github.com/w3c/csswg-drafts/issues/4988> >>>>> initial-letters >>>>> changing used, not computed font-size >>>>> - Current matches spec and WebKit. If the proposal is accepted, >>>>> I think we can change even after ship. >>>>> 9. 3968 <https://github.com/w3c/csswg-drafts/issues/3968> >>>>> initial-letter >>>>> should allow zero sink? >>>>> - New feature, can add without breaking change >>>>> 10. 3240 <https://github.com/w3c/csswg-drafts/issues/3420> Leading >>>>> control at start/end of block >>>>> - New feature, can add without breaking change >>>>> 11. 3217 <https://github.com/w3c/csswg-drafts/issues/3217> >>>>> initial-letters >>>>> applicability to inlines after a forced break >>>>> - test >>>>> >>>>> <https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3A%3Afirst-letter%20%7B%20font-size%3A%20200%25%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%3E%3Cbr%3EXXXXX%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22white-space%3A%20pre%22%3E%0AXXXXX%3C%2Fdiv%3E>, >>>>> when impl is limited to `::first-letter`, this is an edge case that >>>>> we can >>>>> match when resolved even after ship >>>>> 12. 2886 <https://github.com/w3c/csswg-drafts/issues/2886> Line >>>>> breaks inside drop-caps? >>>>> - Without ::first-letter case, not supported in the initial >>>>> release >>>>> 13. 965 <https://github.com/w3c/csswg-drafts/issues/965> support >>>>> adjacent initial-letter as well >>>>> - New feature, can add without breaking change >>>>> 14. 887 <https://github.com/w3c/csswg-drafts/issues/887> should >>>>> define how the initial-letter relates to line boxes >>>>> - We can match when resolved even after ship >>>>> 15. 864 <https://github.com/w3c/csswg-drafts/issues/864> alignment >>>>> of initial-letter for South Asian scripts without hanging baseline >>>>> - non-Latin, not supported in the initial release >>>>> 16. 410 <https://github.com/w3c/csswg-drafts/issues/410> should >>>>> initial-letter-wrap have an auto value? >>>>> - `initial-letter-wrap` not supported in the initial release >>>>> 17. 310 <https://github.com/w3c/csswg-drafts/issues/310> Initial >>>>> Letter selection and hanging punctuation >>>>> - : N/A because we don't support hanging punctuation yet >>>>> >>>>> -yosi >>>>> >>>>> 2022年11月24日木曜日 11:22:22 UTC+9 Yoshifumi Inoue: >>>>> >>>>>> Thanks for reviewing! >>>>>> >>>>>> I forgot to update web-platform-test section in the tool. We have >>>>>> test cases in wpt. >>>>>> https://wpt.live/css/css-inline/initial-letter/ >>>>>> >>>>> Thanks for this. It looks like the feature is status=test instead of status=experimental, so I can't easily see WPT results on the dashboard <https://wpt.fyi/results/css-inline/initial-letter?label=experimental&label=master&aligned>. Can you share the test results please? Also can you characterize the extent to which our implementation is compatible with the prefixed WebKit implementation? Are there known major differences? Especially in the case of the open spec issues which could have future compat implications, I'd feel much more comfortable aligning with what developers are already using via -webkit-initial-letter than if we were aligning with some new behavior with an open issue that considers matching WebKit. *>Any idea what the position in the CSS WG is about the maturity of the >>>>>> spec for this feature? I see a bunch of open spec issues >>>>>> <https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+label%3Acss-inline-3+initial-letter> >>>>>> mentioning >>>>>> initial letter. To what extent are you confident that none of them >>>>>> represent a potential breaking change depending on their resolution?* >>>>>> >>>>>> In this release, we focus on basic functionality, apply only to >>>>>> ::first-letter, as WebKit does. >>>>>> >>>>>> I think current spec is stable for Western language in >>>>>> ::first-letter. So, I don't think we'll have breaking change for them. >>>>>> For non-Western language, we need to do some handling of them once >>>>>> CSS WG has resolutions. >>>>>> >>>>>> We also hope web developers will have some idea from experience, >>>>>> these help CSS WG's resolutions somehow. >>>>>> >>>>>> - yosi >>>>>> >>>>>> 2022年11月24日木曜日 1:27:09 UTC+9 Rick Byers: >>>>>> >>>>>>> On Tue, Nov 22, 2022 at 3:41 AM Yoshifumi Inoue <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Contact [email protected], [email protected] >>>>>>>> >>>>>>>> ExplainerNone >>>>>>>> >>>>>>>> Specification >>>>>>>> https://drafts.csswg.org/css-inline/#initial-letter-styling >>>>>>>> >>>>>>>> Design docs >>>>>>>> https://bit.ly/3KzJ27G >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> Initial letters are large, decorative letters have been used to >>>>>>>> start new sections of text since before the invention of printing. In >>>>>>>> fact, >>>>>>>> their use predates lowercase letters entirely. Blink will support CSS >>>>>>>> property "initial-letter". >>>>>>>> >>>>>>>> >>>>>>>> Blink componentBlink>Layout>Inline >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3EInline> >>>>>>>> >>>>>>>> TAG reviewWebKit shipped `-webkit-initial-letter`. >>>>>>>> >>>>>>>> TAG review statusNot applicable >>>>>>>> >>>>>>>> Risks >>>>>>>> >>>>>>>> >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> Chrome supports full syntax of `initial-letter`: 1 >>>>>>>> `initial-letter:` number 2 `initial-letter:` number integer >>>>>>>> 3.`initial-letter:` number `drop` 4.`initial-letter:` number `raise` >>>>>>>> However Safari supports: 1. `-webkit-initial-letter:` integer 2. >>>>>>>> `-webkit-initial-letter:` integer integer So, web authors needs to use >>>>>>>> Safari compatible syntax. >>>>>>>> >>>>>>>> >>>>>>>> *Gecko*: In development ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/711) No >>>>>>>> active development since 2017. >>>>>>>> >>>>>>>> *WebKit*: Shipped/Shipping ( >>>>>>>> https://github.com/WebKit/standards-positions/issues/94) Needs to >>>>>>>> use prefix version `-webkit-initial-letter`. Supports only an integer >>>>>>>> size. >>>>>>>> No `drop` and `raise` keyword support. >>>>>>>> >>>>>>>> *Web developers*: No signals It’s implemented only in Safari, but >>>>>>>> the usage is high. * 40.2% usage ratio according to CSS2021 Usage >>>>>>>> Overview[1]. * 23.9% have used it according to CSS2021 Typography >>>>>>>> features[2]. [1] >>>>>>>> https://2021.stateofcss.com/en-US/features/#features_overview [2] >>>>>>>> https://2021.stateofcss.com/en-US/features/typography/#initial_letter >>>>>>>> >>>>>>>> *Other signals*: >>>>>>>> >>>>>>>> WebView application risks >>>>>>>> >>>>>>>> Does this intent deprecate or change behavior of existing APIs, >>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>> applications? >>>>>>>> >>>>>>>> None. >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?No >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ?No >>>>>>>> >>>>>>> >>>>>>> Why not? Is there any reason tests couldn't reasonably be added >>>>>>> prior to shipping? >>>>>>> >>>>>>> DevTrial instructionshttps://output.jsbin.com/basukanebo/1 >>>>>>>> >>>>>>>> Flag name >>>>>>>> >>>>>>>> Requires code in //chrome?False >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1276900 >>>>>>>> >>>>>>>> Non-OSS dependencies >>>>>>>> >>>>>>>> Does the feature depend on any code or APIs outside the Chromium >>>>>>>> open source repository and its open-source dependencies to function? >>>>>>>> No. >>>>>>>> >>>>>>>> Sample links >>>>>>>> https://output.jsbin.com/basukanebo/1 >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> >>>>>>>> M110 >>>>>>>> >>>>>>>> >>>>>>>> Anticipated spec changes >>>>>>>> >>>>>>>> Open questions about a feature may be a source of future web compat >>>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>>> issues in the project for the feature specification) whose resolution >>>>>>>> may >>>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>>> structure of >>>>>>>> the API in a non-backward-compatible way). >>>>>>>> None. >>>>>>>> >>>>>>> >>>>>>> Any idea what the position in the CSS WG is about the maturity of >>>>>>> the spec for this feature? I see a bunch of open spec issues >>>>>>> <https://github.com/w3c/csswg-drafts/issues?q=is%3Aopen+label%3Acss-inline-3+initial-letter> >>>>>>> mentioning >>>>>>> initial letter. To what extent are you confident that none of them >>>>>>> represent a potential breaking change depending on their resolution? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> https://chromestatus.com/feature/5167442033115136 >>>>>>>> >>>>>>>> Links to previous Intent discussionsIntent to prototype: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ-EHNMC29gEMkgopMJFW6LfWCCuxXmC0F%2BRPpOuM%3Dznbo5LQ%40mail.gmail.com >>>>>>>> Intent to Experiment: >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABJ-EHPFVLa-frSXmjhbK97L%3D8eh7ZeS6Uap3BiSNfksDicdHA%40mail.gmail.com >>>>>>>> >>>>>>>> >>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>> <https://chromestatus.com/>. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dcc32334-ed12-4c85-b80e-0eb97027496cn%40chromium.org >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/dcc32334-ed12-4c85-b80e-0eb97027496cn%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca90a9b3-e58d-48c8-a46f-62a2c39ed429n%40chromium.org >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca90a9b3-e58d-48c8-a46f-62a2c39ed429n%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01366215-cf05-4acf-beff-fefbc5f08757n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/01366215-cf05-4acf-beff-fefbc5f08757n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-8fWVHxN2LQuHqftf%2BogyV7rgVwFBgbBcg0ARHuEYbHw%40mail.gmail.com.
