- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jul 2020 15:46:12 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `String based inline layout API`. <details><summary>The full IRC log of that discussion</summary> <Rossen_> Topic: String based inline layout API<br> <Rossen_> github:https://github.com/w3c/css-houdini-drafts/issues/990<br> <fantasai> Rossen_: More and more desire to be able to perform typographic text layout from Canvas<br> <Rossen_> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Canvas/FormattedText.md<br> <fantasai> Rossen_: There were some proposals put forward to essentially expose API in the platform that will allow developers to do that<br> <fantasai> Rossen_: e.g. ^<br> <fantasai> Rossen_: When I looked at it, and when we discussed it, my initial reaction was, hey, we have Houdini, and Houdini Custom Layout API was intended to handle exactly this<br> <fantasai> Rossen_: Overall idea, instead of performing layout that is based on a particular subsection of DOM that has text, inline markup, etc.<br> <fantasai> Rossen_: Instead expose an API that simply, for custom layout or maybe different API, takes as input a string<br> <fantasai> Rossen_: and does layout into the given space<br> <fantasai> Rossen_: If Houdini is not able to handle this, we are failing this on some higher level<br> <fantasai> Rossen_: So talked about it with iank_ and he expanded in the issue why this makes perfect sense and is good fit for the API<br> <fantasai> Rossen_: Since then see that some additional comments by Travis and ?<br> <fantasai> Rossen_: from Edge Team<br> <AmeliaBR> q+<br> <fantasai> Rossen_: and I wanted to essentially turn this into a question and ask, does it seem like a reasonable API?<br> <fremy> q+<br> <fantasai> Rossen_: Is this a good API to add, given intended functionality?<br> <fantasai> Rossen_: Will it serve the purpose motivating the other proposal?<br> <fantasai> AmeliaBR: Ian had a question in the issue about, once you've laid out, how do you query back the position of content?<br> <fantasai> AmeliaBR: If you're going down that road, might look at APIs from SVG<br> <fantasai> AmeliaBR: Can't promise they'll be all you want, but if can harmonize it's better<br> <fantasai> AmeliaBR: More specifically on the proposal, like the idea of being able to run layout separately from full CSS layout context<br> <fantasai> AmeliaBR: And re-using Houdini Layout APIs sounds good<br> <fantasai> AmeliaBR: I'm concerned about being based on simple text strings<br> <fantasai> AmeliaBR: As soon as you go beyond the simplest things, need annotations<br> <fantasai> AmeliaBR: Need info on languages, need markup for bidi, going to need nest it with italic phrase inside regular text phrase, etc.<br> <iank_> q+<br> <fantasai> AmeliaBR: So it might be better to keep thinking of styling a DOM fragment<br> <fantasai> AmeliaBR: but DOM fragment doesn't necessarily need to be attached to the document<br> <fantasai> AmeliaBR: Because you will need some hierarchy of content<br> <fantasai> Rossen_: what you're asking for already exists, just extending to handle string only<br> <Rossen_> ack AmeliaBR<br> <Rossen_> ack fremy<br> <fantasai> fremy: One issue of doing with strings is, if you have ? such as text selection<br> <fantasai> fremy: Doesn't work if you don't have something in the DOM to select<br> <fantasai> fremy: Don't know the use case for the text<br> <fantasai> fremy: But selection is something users expect, and problematic if we can't handle selection<br> <fantasai> fremy: But at the same time, think about what Amelia said<br> <fantasai> fremy: if you have something in the DOM to represent the string<br> <fantasai> fremy: [something about spans]<br> <fantasai> fremy: If in the DOM, you can copy and paste, etc.<br> <fantasai> fremy: A lot of times you don't want to have everything possible in CSS<br> <fantasai> fremy: Sounds useful in many cases<br> <Rossen_> ack iank_<br> <fantasai> iank_: The linked formatted text explainer is much more well thought out<br> <fantasai> iank_: and seems pretty good<br> <fantasai> iank_: Amelia brought up point wrt doing on document fragments<br> <fantasai> iank_: Issue there is, this API wanted to work inside of workers<br> <fantasai> iank_: because have the Canvas API<br> <fantasai> iank_: I don't think needs that much of hierarchy<br> <fantasai> iank_: styling particular runs is roughly equivalent to structured hierarchy<br> <sushanth> q+<br> <fantasai> iank_: One thing to think about there is bidi reordering, though<br> <fantasai> iank_: To harmonize APIs<br> <fantasai> iank_: call out some core ? or mixins that can be shared between the APIs<br> <fantasai> iank_: Once you have a line of text, what info can you query?<br> <Rossen_> q<br> <fantasai> iank_: no reason they should be different<br> <fantasai> ??: Motivation was apps, like photoshop / excel<br> <fantasai> sushanth: API was trying to give them ability to do multiline text<br> <astearns> s/??/sushanth/<br> <fantasai> sushanth: Houdini, they have control over canvas context they'd want text to be rendered?<br> <fantasai> sushanth: Paint Worklet, Houdini controls context<br> <fantasai> sushanth: but these cases rendering other things, just want a few lines of text<br> <fantasai> sushanth: In terms of measuring API, we went towards existing Canvas Text Metrics API<br> <fantasai> sushanth: exposes same set of things<br> <fantasai> sushanth: Not the same as SVG, but has precedence on having some APIs<br> <fantasai> sushanth: Chromium has advances as well<br> <jfkthame> q+<br> <fantasai> sushanth: I think last question, selection / background / borders missing from this API<br> <fantasai> sushanth: with metrics can implement this<br> <fantasai> sushanth: in JS<br> <Rossen_> q?<br> <fantasai> sushanth: Just wanted basic multiline text<br> <fantasai> jfkthame: I wanted to comment that what I've seen of the text metrics API for canvas there, particularly advances from Chromium, that really does not address the needs of international text well<br> <fantasai> jfkthame: Does not handle that one character can map to arbitrary number of glyphs and vice versa<br> <fantasai> jfkthame: the mapping between glyphs and characters can be quite complex, and it doesn't handle that<br> <Rossen__> q?<br> <fantasai> AmeliaBR: Hadn't clicked through to explainer previously, and only saw the examples in the issue. Explainer looks like a much more complex model, allows annotations<br> <fantasai> AmeliaBR: if that's extended to handle i18n issues, that's a good start [wrt bidi and lang?]<br> <fantasai> AmeliaBR: Might be useful to export a DOM fragment to this format<br> <fantasai> AmeliaBR: so if you have CSS-styled markup in Canvas Shadow DOM or in your SVG<br> <fantasai> AmeliaBR: and want to run through this API to get layout, would be a great feature<br> <Rossen__> q<br> <sushanth> q+<br> <fantasai> Rossen__: SVG has had this capability request for the longest time<br> <fantasai> Rossen__: some such as inkscape that support, no renderers<br> <fantasai> Rossen__: Want it in Canvas<br> <fantasai> Rossen__: If for every one of these [sound breaks]<br> <fantasai> AmeliaBR: He was talking about how SVG has long wanted formatted multiline text, haven't been able to get implemented in browsers, so will be very jealous if Canvas gets it before we do<br> <astearns> ack sushanth<br> <fantasai> sushanth: Point about advances in text metrics, it's incomplete<br> <fantasai> sushanth: flag to get it to wokr<br> <fantasai> sushanth: Does handle multiple glyphs per characters<br> <fantasai> sushanth: We augmented with hierarchy to allow advances within ?<br> <fantasai> sushanth: It addresses multiple chars into single glyph is that it gives you the same advance value<br> <fantasai> sushanth: They'll all have the same advance value<br> <fantasai> sushanth: advance = position from the start<br> <Rossen___> q?<br> <fantasai> jfkthame: That won't be any different than a zero-width character right?<br> <AmeliaBR> This is similar to how the SVG API works: multiple characters will match to the same glyph box<br> <fantasai> sushanth: true<br> <fantasai> sushanth: Some other issues also?<br> <fantasai> Rossen__: Main point I wanted to make before network drop...<br> <fantasai> Rossen__: If we're not looking for ways to harmonize Houdini APIs with rest of platform<br> <fantasai> Rossen__: failing main use case of exposing ? to other things like Canvas and SVG<br> <AmeliaBR> s/?/text layout/<br> <fantasai> Rossen__: As we all know, text seems very benign and easy, when you thinking only about a few ascii glyphs<br> <fantasai> Rossen__: breaks based on simple logic<br> <fantasai> Rossen__: Things get increasingly complex<br> <fantasai> Rossen__: to the point where you're mostly ending up re-implementing layout for CSS<br> <fantasai> Rossen__: which now intended to be exposed as Houdini APIs<br> <iank_> q+<br> <Rossen___> ack fantasai<br> <Zakim> fantasai, you wanted to ask us to get Myles's opinion before signing off on anything like this<br> <fremy> q+<br> <fantasai> fantasai: Just wanted to say, I echo concerns about getting i18n right.<br> <iank_> q-<br> <iank_> q+<br> <fantasai> fantasai: Also want to say, I would be very uncomfortable resolving to add a new major text API without Myles signing off<br> <fantasai> fremy: Was thinking about use case, the idea is to run this in workers<br> <fantasai> fremy: because can't ? directly<br> <fantasai> fremy: So that's why don't want to take something from the DOM and draw it<br> <AmeliaBR> s/?/access the DOM/<br> <fantasai> fremy: ...<br> <fantasai> fremy: HTML content and canvas can automatically update<br> <fantasai> fremy: what gets drawn on it<br> <fantasai> fremy: that could get the other things to work<br> <fantasai> fremy: for ppl using the API<br> <fantasai> fremy: Draw on the canvas, put this in the DOM, and gets updated<br> <fantasai> fremy: enables selection, a11y, etc. everything to wokr<br> <astearns> s/.../describes an export from this API to a DOM fragment/<br> <fantasai> fremy: That's an idea, another way of looking at it<br> <fantasai> iank_: Based on the canvas text explainer here, definitely possible to harmonize SVG and layout API with htis<br> <Rossen___> ack iank_<br> <Rossen___> ack fremy<br> <fantasai> iank_: might me helpful to get on videochat and talk about details in detail at some point<br> <fantasai> Rossen___: As stated in the beginning, wanted to get opinion on whether good approach in general<br> <fantasai> Rossen___: For the proposed solution put together by ian on that issue, wanted to get feedback from sushanth and others<br> <fantasai> Rossen___: whether approach worth pursuing<br> <fantasai> Rossen___: Closing remarks are let's get together and work on this<br> <sushanth> thank you Ian, happy to follow up. :D<br> <florian> q+<br> <Rossen___> ack fantasai<br> <fantasai> fantasai: bidi, lang-tagging or markup for change in formatting, selection, a11y, character to glyph mapping ...<br> <fantasai> fantasai: justification? would it be possible?<br> <Rossen___> q<br> <fantasai> sushanth: ? has some some text justification, has just left/right/center<br> <AmeliaBR> s/?/canvas/<br> <fantasai> fantasai: just wanted to make sure these points don't get lost<br> <fantasai> florian: Want to echo a bit of the warning Myles gave us last time on this topic<br> <fantasai> florian: needs to be foolproof, so that if user of API doesn't think about them, they still work<br> <fantasai> florian: otherwise we make large parts of internet inaccessible or unusable to a lot of the world population<br> <fantasai> florian: ...<br> <fantasai> florian: getting the right balance is hard, but we have to do it<br> <fantasai> iank_: This API is a substantial leap forward from current Canvas APIs<br> <fantasai> [Note to scribe: insert link to Myle's comments here]<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/990#issuecomment-667190629 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 July 2020 15:46:14 UTC