- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Feb 2019 22:56:28 +0000
- To: public-houdini-archive@w3.org
The CSS Working Group just discussed `Houdini <3 text`. <details><summary>The full IRC log of that discussion</summary> <emilio> topic: Houdini <3 text<br> <emilio> github: https://github.com/w3c/css-houdini-drafts/issues/854<br> <emilio> myles_: So, houdini has a lot of stuff, and I think everything is things that browsers do already, which is cool<br> <emilio> myles_: there's one of these things that is not in houdini so far, which is text<br> <emilio> myles_: so there's a chance that authors are going to want text layout<br> <emilio> myles_: there's a lot of ways this could go, text is complicated, and different to other parts of houdini, in the sense that (a) it's pretty easy to get wrong and (b) if it is, users will be misled and confused<br> <emilio> myles_: it's easy to get it wrong when things like how BiDi works should work by default, we don't want authors to have to remember how to do these<br> <emilio> myles_: there's a bunch of things like that listed in the issue<br> <emilio> myles_: so I wanted to discuss how should we approach such an API to avoid causing pain<br> <emilio> myles_: a strawman proposal just to get the discussion started would be a region-like API, where your content flows from one box to the other, and regular CSS properties apply in that box<br> <emilio> myles_: that'd be very high level. Another approach would be to expose glyph indices and fonts and let the author place all of them<br> <emilio> myles_: I think that'd be bad<br> <fantasai> +1 to that being bad<br> <emilio> myles_: So, there are these two extremes, these high-level things, and there's this low-level thing which we can agree it's a bad idea. There's a range in there that we should figure out<br> <emilio> AmeliaBR: (summarizing her comment in the issue)<br> <emilio> AmeliaBR: (https://github.com/w3c/css-houdini-drafts/issues/854#issuecomment-459146355)<br> <florian> q+<br> <fantasai> AmeliaBR: There's a lot of steps, like [...], that we need to break this down into.<br> <dauwhe> q+<br> <fantasai> q+<br> <emilio> AmeliaBR: within all the individual steps which happen during text layout, we need to figure out which of them authors want to customize. One of them could be justification<br> <emilio> AmeliaBR: other things like bidi unicode stuff we don't want to ever expose<br> <iank_> q+<br> <florian> q-<br> <florian> q+<br> <emilio> AmeliaBR: we could expose (though maybe trickier) glyph selection (sounds scary, but there's lot of fun stuff you could do with OT glyph selections instead of having to create a new font because you want to create a space-maximizing layout)<br> <emilio> AmeliaBR: that's something that people may want but that is easy to get wrong / break<br> <emilio> AmeliaBR: also, the steps are very dependent on one another, so we need to come up with a nice model of the data that goes through the pipeline if we want authors to insert their custom stuff<br> <emilio> fantasai: this is not just a sequential pipeline, some of the steps interact with each other. An excellent line-breaking engine will account for glyph selections and such<br> <Rossen> q?<br> <emilio> fantasai: so you can't just break that up<br> <Rossen> ack fantasai<br> <Rossen> ack ia<br> <emilio> iank_: I think we agree in spirit models, we don't want to get into the bussiness of bidi resolution or glyph selection or such<br> <emilio> iank_: we may want to get smarter about where to break and such, but not atm<br> <emilio> iank_: the current model in the spec is a box where you run layout giving the avail width and you get back an inline box / line box fragment<br> <emilio> iank_: you can re-request that if the resulting height is too big for your layout<br> <emilio> iank_: some layouts require the available width to change on a per-line-box basis<br> <emilio> iank_: we want to prototype that<br> <Rossen> q?<br> <emilio> myles_: so, I also agree that we mostly agree<br> <dholbert> s/models/myles_/<br> <emilio> myles_: the idea of giving avail width works well if the area has vertical end, but if you're not a perfectly vertical container it doesn't, it's not clear how much we care for shapes<br> <emilio> iank_: in our engine we do at most two layout passes to avoid shapes<br> <fantasai> iank_^: We care about shapes a lot<br> <emilio> iank_: which sort of fits in this model<br> <fantasai> s/for shapes/for shapes in Houdini/<br> <emilio> myles_: I think doing two layouts is unfortunate, describing geometry would be nicer<br> <emilio> iank_: that'd be difficult, a lot of the use cases that devs want to place a line depending on how the previous line has been laid out<br> <emilio> iank_: I think describing all the geometry upfront would be limiting<br> <emilio> iank_: one of the examples we want to work is an arbitrary line grid<br> <fantasai> q+ to talk about justification<br> <emilio> iank_: the avail width of the next line really depends on the line height of the previous line box<br> <iank_> q-<br> <xfq> ack da<br> <Rossen> q+<br> <emilio> dauwhe: My industry is very interested in using houdini to improve justification / hyphenation, since the browsers have different requirements<br> <Rossen> ack florian<br> <fremy> q?<br> <fremy> q+<br> <emilio> florian: I share the concern that this is important and hard to let people do a lot of random stuff<br> <emilio> florian: but they shared examples for i18n where a lot of effects needs a lot of low-level access<br> <emilio> florian: but Japanese people may want to increment distance between some glyphs or such<br> <emilio> florian: or implement stuff that isn't in browsers yet<br> <fremy> q- because basically florian just said what I wanted to say<br> <fremy> q-<br> <emilio> florian: the approach of get line boxes doesn't get far enough, but I'm not sure how to get far enough but not being dangerous<br> <fantasai> +1 to ensuring legibility<br> <emilio> myles_: you're right, but we have competing desires, letting authors implement nice effects, and making pages legible, the latter has been historically more of a priority<br> <Rossen> ack fantasai<br> <Zakim> fantasai, you wanted to talk about justification<br> <skk> q+<br> <emilio> fantasai: side comment, about justification and the model that is in houdini, which I agree is the right one to get started. For justification would it make sense to return the fragment without filling the available width, but also let the user set it to be wider and that'd trigger justification<br> <emilio> ... and alignment<br> <emilio> fantasai: that way I can see where it fits much more easily, and position it more easily<br> <emilio> fantasai: and justification properties would work the same way it works when you place it in a bigger size. Justification control would still be in control of the user-agent<br> <florian> s/but Japanese/for example, Japanese/<br> <Rossen> q?<br> <emilio> myles_: dauwhe, when you said for example you wanted to improve justifications, is ^ what you were referring to?<br> <emilio> dauwhe: I think we want more<br> <fantasai> s/Justification control/Justification/<br> <fantasai> s/justification properties/justificaiton and alignment properties/<br> <florian> s/but they shared examples for i18n/but Dave shared examples about hyphenation and justification, and there are many more of the same kind of when you consider i18n/<br> <emilio> Rossen: thanks for bringing the issue, and I'm glad it's getting more and more traction. The one common theme that I see so far is that we are trying to get the "custom" part of layout out of custom layout. Everything that's been discussed so far how to force people to do the thing what we're already doing and tweak it a bit here and there<br> <dauwhe> q?<br> <dauwhe> q+<br> <emilio> Rossen: the nice thing of custom layout is that we're not giving restrictions for where people to position boxes in the block layout case, but when it comes around text we through our hands in the air and say it's too hard, and I don't agree with that<br> <koji> q+<br> <fantasai> TabAtkins: We have existence proof that every single custom layout has done bidi wrong.<br> <emilio> Rossen: it seems to me that we're talking about levels of customisability<br> <AmeliaBR> q+ to follow up on Rossen's comments<br> <emilio> Rossen: one where you expose bidi and shaping at every breaking opportunity, the other where you give it a box and we'll do the layout inside<br> <florian> q+<br> <emilio> Rossen: I'd be interested to go and explore the options in the middle which would allow most custom layouts that people want<br> <fantasai> q+<br> <emilio> Rossen: so that we're still not insisting on that rigid one box<br> <emilio> Rossen: we're also assuming that we're doing inline layout the way browsers do it now, but maybe my lines are spiral, or I want to go on top of floats<br> <emilio> Rossen: let's not try to take the custom part of layout outside of css<br> <Rossen> q?<br> <Rossen> ack dbaron<br> <emilio> dbaron: I just wanted to bring up another use case that hasn't come up today<br> <emilio> dbaron: I think having a low level API is very important for minority languages<br> <astearns> [general nodding]<br> <emilio> dbaron: Gecko has shipped graphite support<br> <dbaron> https://en.wikipedia.org/wiki/Graphite_(SIL)<br> <Rossen> q?<br> <emilio> dbaron: one of the things it does is let languages that have shaping requirements that aren't in browsers do it in fonts instead<br> <emilio> dbaron: another approach for this would be a low-level JS API using houdini<br> <dholbert> (I believe "glat" is one of these graphite font tables that dbaron is referencing)<br> <dauwhe> "For example, it may be the case that a minority language is tonal, while the national language is not, and the orthographic solution involves using the standard writing system with some extra diacritics to indicate tone. Or the minority language might have a set of sounds characterized by a certain linguistic feature, such as aspiration or breathiness, that are not present in the national language, and the desire is to add to the standard orthograp<br> <dauwhe> hy a set of variant characters to represent these variant sounds."<br> <emilio> dbaron: I think that's a potential real usecase<br> <xfq> ack skk<br> <emilio> skk: From Japanise digital books perspective, more precise Ruby would be amazing<br> <emilio> skk: We'd like more control over ruby text positioning<br> <Rossen> ack dauwhe<br> <emilio> dauwhe: Responding to the phylosophical point, being able to explain and expose all the platform features?<br> <emilio> Rossen: it is, what I'm saying is, let's not prevent that<br> <myles__> q+ to respond to Rossen<br> <emilio> Rossen: so that we can avoid limiting the inner pinnings of how things work. Said that, we want to open the engine so that we don't need to implement all the stuff people want, that's the fun part of it.<br> <emilio> Rossen: we've never said "and we don't want to let you do this because it's hard"<br> <dauwhe> s/phylosophical/philosophical/<br> <emilio> Rossen: why?<br> <Rossen> q?<br> <emilio> myles__: if your layout is wrong, the text still exists. For layout no layout is wrong, for text it is<br> <Rossen> q?<br> <emilio> Rossen: if it's unreadable it's unreadable because of me<br> <emilio> fantasai: it may be because somebody typed something you didn't expect<br> <emilio> fantasai: and you didn't care of thinking of those users<br> <dauwhe> q?<br> <emilio> fantasai: and those users are our users<br> <myles__> s/layout is wrong/layout is not what the author intended/<br> <emilio> Rossen: that's my problem, those users are going to complain to me<br> <Rossen> Zakim, close queue<br> <Zakim> ok, Rossen, the speaker queue is closed<br> <Rossen> ack koji<br> <emilio> koji: From my POV I think "don't do bidi and don't you your own thing" is more "we want to start from simple things", and as we can confirm it performs properly and works we can extend further<br> <emilio> koji: but I'm not very confident that JS running through glyphs is performant enough, so box-level layout seems simpler<br> <emilio> koji: so re. Rossen's point, we're not against, but we want to start from the simple thing<br> <xfq> ack AmeliaBR<br> <Zakim> AmeliaBR, you wanted to follow up on Rossen's comments<br> <emilio> AmeliaBR: I agree with Rossen and dauwhe, the point of houdini is being able to tweak one of the little things the browser does without having to re-implement the browser, and we want to let authors do what they want<br> <Rossen> q?<br> <emilio> AmeliaBR: you can do some sort of custom layout with SVG, but probably badly. we should let authors do what they want without forcing to reimplement what they don't want to tweak<br> <emilio> AmeliaBR: I think we should prioritize our work to start with the safest things to change and isolate<br> <Rossen> q?<br> <xfq> ack florian<br> <Rossen> ack fantasai<br> <heycam> agree with AmeliaBR -- we should bias towards coming up with APIs that allow users to benefit automatically from the browser implemented bidi, complex text shaping, etc. features that the author doesn't want to reimplement<br> <heycam> make it harder for them to accidentally not support those things<br> <emilio> florian: so, I think when we say is "this is too hard", this is not saying that devs in this room are smarter than all of them. But very litte people have resources to implement all the complexities right<br> <emilio> florian: very few people have the bussiness justification to deal with all languages<br> <emilio> florian: minority languages is where this is interesting and dangerous<br> <emilio> florian: the low level things that enable minority languages to work on the web, are also what enable companies to write western-only layouts that don't work on other minority languages that browsers support today<br> <emilio> florian: in the process of creating an api that's good enough to support minority languages we'd have created the chance of chinese languages where you only can write in chinese, or english pages that allow you to only work in languages<br> <emilio> florian: so if you force people to rebuild text-layout itself, they will not do the right thing, and we'd have disabled some languages instead of enabling others<br> <emilio> florian: so I'm more on the side of caution, and making sure that everything we add to this API is a thing we can tweak<br> <Rossen> astearns, assuming this was the interface they have to implement?<br> <emilio> florian: And yes, people will break stuff for their own customers, but we'll also break the fact that the web is multilingual<br> <emilio> fantasai: I think koji and AmeliaBR and florian said everything I wanted to say<br> <xfq> ack my<br> <Zakim> myles__, you wanted to respond to Rossen<br> <emilio> myles__: most of my job is fixing bugs that the text experts in the piece of software they created cause they only spoke english<br> <emilio> myles__: there's tons of places in WK where there are assumptions because of english only speakers<br> <emilio> myles__: I agree we should investigate the middle parts in the spectrum, but I think we disagree with the criteria for success<br> <emilio> myles__: I think text is different, where if you get it wrong it may work for you but not for your users<br> <dauwhe> q?<br> <fremy> q+<br> <emilio> myles__: an approach where we take every thing the browser does and making it scriptable is not the highest priorities<br> <emilio> myles__: raising use cases is a good way to prioritize, the idea of tweaking specific parts of the browser is great and makes total sense<br> <emilio> myles__: picking specific use cases and filing in holes is probably the right idea, creating a low level platform and tell people to write it yourself is probably not<br> <florian> +111!1!1<br> <fantasai> myles++<br> <emilio> myles__: minority languages is a very interesting case, apart from Graphite we also have a similar thing with AAT<br> <emilio> myles__: I wish we could find a way to solve that problem in a way where safety is preserved<br> <florian> q?<br> <emilio> Rossen: I see a lot of passion and interest, zero reasons for us to stop working on this. A lot of things said will hopefully be taken into account as we move forward. One thing that I wanted to make sure that the record reflects what I said.<br> <emilio> Rossen: I wasn't suggesting to start exposing the far end, like glyphs<br> <emilio> Rossen: but as we go forward we should start walking towards the end, I just want to ensure that we don't preclude us from going forward<br> <emilio> Rossen: is there something that you think it wasn't discussed?<br> <emilio> to myles__<br> <AmeliaBR> q+<br> <emilio> myles__: I think the next thing is gathering use cases, so we're done<br> <emilio> Rossen: queue time<br> <jensimmons_> q+<br> <dauwhe> q+<br> <Rossen> Zakim, open queue<br> <Zakim> ok, Rossen, the speaker queue is open<br> <dauwhe> q+<br> <jensimmons_> q+<br> <emilio> iank_: to try to wrap up, is there anything inside of the current version of the spec that particularly scares you?<br> <emilio> myles__: my biggest concern is about encouraging authors to do layouts in loops<br> <Rossen> q?<br> <emilio> myles__: where they try over and over, but I understand such and approach allows for dynamic use-cases, so I guess the question is to which side we fall<br> <AmeliaBR> q+<br> <emilio> iank_: I think we agree, but we don't want to limit people which is why we chose this approach<br> <emilio> myles__: We heard a lot of use-cases in this discussion that aren't covered by the API, so maybe it's too early to create APIs<br> <xfq> ack dauwhe<br> <emilio> Rossen: we have a proposal and we have a lot of discussions, let's not say yay or nay<br> <jensimmons_> q-<br> <emilio> dauwhe: I wanted to make a point re. the responsibility about us making software for our usecase vs. browsers<br> <Rossen> q?<br> <emilio> dauwhe: we publish english and spanish, I don't think there should be obligation for us to handle vertical or rtl<br> <xfq> ack AmeliaBR<br> <Rossen> Zakim, close queue<br> <Zakim> ok, Rossen, the speaker queue is closed<br> <emilio> AmeliaBR: I'm glad myles__ brough this discussion<br> <emilio> AmeliaBR: one thing that myles__ and fantasai said is that text was different because it made stuff unreadable<br> <emilio> AmeliaBR: I don't think that's true, there are lots of ways you can break content in another ways<br> <emilio> AmeliaBR: I agree with Rossen that the developers of the websites are responsible for being user friendly and would be the ones to pay the price. I don't think that this proposed ways which could break websites are worse that other ways to break stuff with CSS<br> <florian> q+<br> <emilio> fantasai: I think it's actually worse<br> <florian> q?<br> <astearns> I disagree with AmeliaBR's comment, and agree with fantasai. Bad text layout has uniquely bad ways of making content inaccessible<br> <emilio> Rossen: this is not the end of the discussion, but some of the starting points<br> <emilio> Rossen: we need go back and work more on this, we should keep participating passionately<br> <emilio> Rossen: next steps is engaging in the specs<br> <emilio> Rossen: so go help iank_ ;)<br> <emilio> iank_: I'd love that<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/854#issuecomment-468064493 using your GitHub account
Received on Wednesday, 27 February 2019 22:56:30 UTC