- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 23 Mar 2016 17:31:22 -0400
- To: www-style@w3.org
========================================= These are the official CSSWG minutes. Unless you're correcting the minutes, Please respond by starting a new thread with an appropriate subject line. ========================================= A report on research into automatic layout ------------------------------------------ - Bert had visited groups from Monash University and YesLogic to hear about the work they're doing creating algorithms in constraint spaces. Their algorithms not only take the known constraints, but can recompute as they get additional information. - Uses for constraint solving include footnotes, sidenotes, indexing, table layout, and line breaking. It was mentioned some of this could be hooked in via Houdini. - There was interest in working more with both groups, especially the expertise from the YesLogic folks. Specifically it was thought they would have useful feedback on the Grid spec. CSS Text -------- - There was agreement that there is a strong use case to solve for aligning to a particular character in table columns. - RESOLVED: left-align the alignment characters ===== FULL MINUTES BELOW ====== Agenda: https://wiki.csswg.org/planning/sydney-2016 Present: Rossen Atanassov, Microsoft Takao Baba, BPS L. David Baron, Mozilla Brian Birtles, Mozilla Japan Bert Bos, W3C Bogdan Brinza, Microsoft Rick Byers, Google Tantek Çelik, Mozilla Dave Cramer, Hachette Livre (via telephone) Emil A Eklund, Google Elika Etemad, Invited Expert Simon Fraser, Apple Daniel Glazman, Disruptive Innovations (via telephone) Jihye Hong, LG Electronics Joone Hur, Intel Dean Jackson, Apple Brian Kardell, jQuery Foundation (via telephone) Brad Kemper, Invited Expert Ian Kilpatrick, Google Peter Linss, Hewlett-Packard Cameron McCormack, Mozilla Edward O'Connor, Apple Simon Pieters, Opera Xidorn Quan, Mozilla Francois Remy, Microsoft Florian Rivoal, Vivliostyle Andrey Rybka, Bloomburg Hiroshi Sakakibara, BPS Simon Sapin, Mozilla (via telephone) Hyojin Song, LG Electronics Elliott Sprehn, Google Alan Stearns, Adobe Shane Stephens, Google Ojan Vafai, Google Jet Villegas, Mozilla Philip Walton, Google Levi Weintraub, Google Greg Whitworth, Microsoft Steve Zilles, Adobe Systems Regrets: Tab Atkins, Google Dongwoo Joshua Im, Samsung Electronics Co. Dael Jackson, Invited Expert Chris Lilley, W3C Scribe: fantasai A report on research into automatic layout ------------------------------------------ Bert: I was in Melbourne the last week. Went to see 2 different groups of people. Bert: First group is people from Monash University, especially Kim Marriott. Bert: He's professor at Monash, works on constraint solving etc. Bert: Met some colleagues as well. Bert: And met people from YesLogic, Michael Day and Peter Moulder who used to be at Monash. Bert: Talked about many things, Bert: What they're doing at Monash. Bert: They do document engineering, Bert: But much more than that, Bert: Algorithms for constraint solving and optimizing. Bert: Interesting equipment, 3D Printers, laser cutting, 3D environments, Bert: Can make many things and animate them with computers. Bert: Interesting parts for me were things for constraint solving and optimization. Bert: Trying to explore semi-automatic constraint solving. Bert: Number of constraints, computer finds a good solution. Bert: These problems are hard, can't do an exhaustive search. Bert: In practice many can be solved fairly well this way. Bert: One problem was a cancer treatment, placement active charges on needles. Bert: Before that make 3D model of the area. Bert: Visualized in real time, you can see the computer finding a set of points where you should stick in needles. Bert: It's interactive as well. Bert: So if you see that some needles are not where you would put them, or you have some extra knowledge not captured in constraints, can drag and drop needles around, and it will recompute solution based on this new constraint. Bert: Variant of traveling salesman problem. Bert: Computer finds optimal route. Bert: But maybe you didn't think of before, e.g. driver get sick, road is blocked, certain driver can't go a certain place, etc. Bert: Solve those. <gregwhitworth> worth looking at for this: http://marvl.infotech.monash.edu/webcola/ Bert: Also thought about applying to layout problems, Bert: Brainstormed about what an editor would look like. Bert: What are things you would want to influence? Bert: Want certain constraints, number of articles to be put on a page. Bert: But not happy with results, might might want to drag things around a bit. Bert: Couldn't think of any editor that worked that way. Bert: Maybe Daniel wants to build in constraint solvers into his editor? :) glazou: Get me funding, and no problem! Bert: This assumes the editor interactively and in real time computes the layout. Bert: What would the output be, though? Bert: Does the computer output the final set of constraints, and browser recomputes? Bert: Or should the editor not assume the computer has the same capabilities? Bert: This interactive manipulation is a way to create constraints without using syntax. Florian: Don't know how much they looked into it, but if we're thinking about CSS and the attempt that we generally make for it to be robust in varying environments Florian: These manually added constraints, have they thought about how to express that when not in authoring environment? Bert: No, they've done some demos of .e.g. table algorithms. Bert: Table layout could be very fast and always better than the current layout. Bert: But haven't tried to think about syntax lately, just about algorithms. Florian: My question isn't about syntax, but these manually added constraints? What are they expressed in terms of? When the screen size changes, what happens? Florian: One reason it's hard to make a good CSS editor is that you start with a semantic layout. Florian: How do you express these constraints that's not just wysiwyg? Florian: If you make wysiwyg, it maps poorly to CSS. Bert: They haven't done any work on that. <gregwhitworth> http://gridstylesheets.org/guides/ccss/ Bert: But there is something from other people they worked at in the past, Washington University in US, ?? and ??? constraint cascading style sheets. Bert: Using a syntax made by Apple for the internal UI. glazou: It is not difficult to write a good CSS editor that is strictly visual. glazou: Outputs layout based on mouse-defined rendering. glazou: What is extremely difficult is taking an existing document with existing stylesheets, and add stuff like that. glazou: That's why this is complex. glazou: That's why you have so many editors outputting HTML+CSS, but not using it as their native format glazou: Other than that, fairly doable. Bert: Michael Day of YesLogic has been thinking of how to use things like that <astearns> also why you have editors that do not take arbitrary HTML+CSS as input <glazou> astearns absolutely <Florian> glazou: I'll have to have a longer discussion with you about this, you know more and I have a ton of questions Bert: In a regular language, could say e.g. box a is zero or more copies of box C followed by box D Bert: Something like that. Bert: Usable by people to express how they want the layout to be. Bert: We had a thought, also mentioned there, if Houdini works well, Bert: It might be possible to keep the same underlying system, Houdini, but offer alternative ways to express your stylesheet Bert: Doesn't have to be CSS syntax. Bert: Gets translated down to same base level as Houdini. Bert: Might be a way to get away from current constraints of CSS. Bert: Talked about some of the difficult things in layout: footnotes, sidenotes, spreads of pages. Bert: Differences between superficially similar things: footnotes vs. sidenotes vs. floating images. Bert: Similar layout -- float to a side -- but different constraints. Bert: Floats can only go later, can't go higher. Bert: Sidenotes are a bit like normal floats. But don't have to be same height or lower, could be higher on the page as well. Bert: If you have a spread. Bert: Sometimes don't need to put a float on the same page. Could put on previous page -- it's still visible anyway Bert: How to formalize such constraints? Bert: Same thing for line breaking. Bert: Maybe not use a single algorithm, but plug in different algorithms to do better or faster job. Bert: Apply different rules for a particular application. Bert: Given Houdini being prepared, maybe it becomes possible. Bert: Someone mentioned during lunch that, just occurred the day before, found himself reading the same line over and over again until he realized both lines were ending with the same word. Bert: Maybe you want an algorithm that avoids situation like that: same word ending two lines. Bert: If it doesn't work quite with just changing spacing/line breaking, would be nice to have possibility to change the text. Bert: If the author is available, you can ask author to rewrite text to fit better. But on the web, author is not available. Bert: But maybe allow alternative text in the document. Florian: This also came out in a11y discussion. Florian: Some people have difficulty with metaphors, maybe you have alternative texts one literal one figurative. Florian: Multiple reasons to be interested in this other than layout itself. <glazou> +1 to what florian said, including linguistic differences Bert: Michael Day was interested in development of his market, PDF renderers. Bert: Looks like he would get more competition. Bert: He's happy about that, proves it's interesting and market is getting bigger. Bert: Makes idea of outputting to paged media / PDF more popular. Bert: But was wondering what competitors are working on? Bert: Antenna House, Vivliostyle. Bert: We noticed another one, existed for awhile but wasn't as good in the past, German company, Bert: Improved a lot. Bert: Competitor to Prince now. Bert: Looked also at indexes. Bert: If your output isn't interactive, you need things like ToC and alphabetical index. Bert: They want to do that, and at the moment they are exposing a JS interface so you can write a program that creates an index. Bert: But the index is created before the layout is done. Bert: So you can create the index, sort the index, placeholders for page numbers which get resolved after layout. * glazou notes that we can't say an element is a link through CSS...and we badly need it IMHO Bert: But then want to do fixup, like replacing duplicate numbers. Bert: Or maybe need JS that runs after formatting. Bert: Were asking if we in the WG were thinking of adopting things from XSL, since it can do that. Bert: Antenna House can do that, Prince cannot. Bert: So interesting to work on -- good indexes is a challenge. Florian: I think priorities are different when you're doing interactive docs. Florian: But even then, it's desired. Florian: Should have in general. SteveZ: Part of secret is doing indexing after you've done the document. SteveZ: In a batch process you can stick it back up front. SteveZ: In an interactive world, there'd be no particular harm in being just another page that you accessed. SteveZ: Does make sense in an interactive context. SteveZ: Stuff in XSL is not that sophisticated that it would be a performance problem. Bert: Interactive documents. Bert: Forgot name of program, but it allows you to see hypertext documents. Bert: Gives previews of documents being linked. Bert: Because screens are big enough now, can have a side panel. Bert: Don't have to click the document to see what it is. Bert: Maybe it's a nice feature for browsers. Bert: Other things that could be done interactively that could make reading easier. Bert: Exploring a document in various ways. Bert: Particularly if you have tables or math, can be very interactive. Bert: Think of what you could do with data tables. Bert: Sort tables, make a graph out of it, like an excel spreadsheet. Bert: Author says 'this shows a trend', you can make your own graph and come up with your own interpretation. Bert: You can interact with math formulas. Bert: Could also do things with images: zoom in, enhance contrast, etc. Bert: That's about it. * fantasai would like a link to the table algorithm paper <liam> [I sent a draft proposal for index fixup in January; I know TabAtkins commented on it. it needs work, but is largely based on XSL-FO] Bert: http://print-css.rocks/ Bert: Print CSS site, it's a one person site, review of various programs for making print from HTML. Bert: E.g. found links to PDF Reactor. Bert: They can do things like hanging punctuation. Bert: You can make really nice documents with PDF Reactor <dauwhe> I'd love for them to submit their tests to our test suite * fantasai too ;) Bert: That's the end of my notes glazou: First, thank you Bert for the report, very interesting. glazou: What can we take back to the CSSWG, and what is interesting for us to discuss, and how? glazou: And will the people you talked with help us to standardize? Bert: People from Monash, no, their job is teaching and writing papers. But you can talk to them and ask for algorithms. Bert: They looked at e.g. are these algorithms practical enough to use in real time, and in their opinion, yes, they are. Bert: YesLogic's Michael Day has more concrete requests. Bert: Would be best for him to join the WG, been asking for a long time. Bert: But it's a very small company, they don't have a lot of money, not even an office. Bert: They may have half of the market, but it's a small company. Bert: We can talk to them. Peter Moulder is active on ML, Michael Day not so much, but happy to answer questions. Bert: He promised me he'd give me more complaints. Bert: So I'll be asking for more complaints. Bert: Concrete things they wanted, I mentioned indexes, Bert: Michael Day was interested in more constraint-like layouts. Bert: A way to express two things side by side, third thing below. fantasai: You can do that with Grid Bert: I'll think a bit more. glazou: To enhance layout, giving constraints between elements. glazou: I had a proposal for that. glazou: I think Tab also had one. glazou: We did some constraint-based layout long ago in Grif. glazou: Maybe people at Amaya have some hints. Bert: Nobody working on it anymore, but people who worked on it might know. dauwhe: I also have a good working relationship with Michael Day, spend a lot of time on their support forums. dauwhe: Do see a lot of pain points there, can try bringing those to this group. dauwhe: Our system is based on Prince, so I have a lot of experience with them. skk: As far as I understand, the constraints is coming from users. Bert: Constraint is given by author or designer of document. skk: Not user. Bert: That's an interesting idea. Didn't think about allowing reader of document to give constraints. skk: If we can think about user also giving constraint to document, I think it is interesting. skk: At that time we think about personalization of document. skk: There is one document, many readers. skk: E.g. I like hanging punctuation, but he does not, then user can see what they like. skk: Personalization can be done using these constraints method. Bert: I like that, should think about that. skk: Can you let me know later, the ACM paper you mentioned in the talk? Rossen: In context of all of this, would be great to ask if they can look at our Grid proposal. Rossen: That's a module where a lot of these constraints can be handled very elegantly on the style layer. Rossen: Worth having people with that kind of problem space looking to the spec at least. Rossen: Getting feedback. Bert: Michael Day liked my grid better, but he'd looked into the new one. fantasai: On topic of Grid, planning to transition to CR 2 weeks from now, so would be great to get feedback within this time, otherwise hard to process. CSS Text -------- Bert: Digipub wanted to talk about character alignment. dauwhe: Top of our wish list is aligning on a character in a table column. dauwhe: This is now in CSS Text 4. dauwhe: At TPAC dbaron went and added a bunch of issues about nuts and bolts how this would work. <dbaron> I added some issues to https://drafts.csswg.org/css-text-4/#character-alignment pointing out things that need to be decided (some are technical, but some are actually questions about what the users want) dauwhe: First issue was 18: how would you align the alignment characters themselves if in different font? dauwhe: The most common use case is bold row for totals. dauwhe: Did a bit of research looking into what existing tools do in this situation. dauwhe: As far as I can tell, InDesign aligns the origins of the glyphs. dauwhe: Some discussion on ML whether this is appropriate or whether the alignment chars should be centered. <dauwhe> https://lists.w3.org/Archives/Public/www-archive/2016Feb/0000.html dauwhe: I just put together a diagram. dauwhe: This overlays bold/roman text in the same font. dauwhe: This is a very small effect. <Rossen> https://lists.w3.org/Archives/Public/www-style/2016Jan/0233.html * fantasai prefers center alignment Florian: I don't have as many examples as Dave has. Florian: I've looked into it, talked to others. Florian: General agreement that main use case is bold vs regular. Florian: Essentially they treat this as an edge case rather than a use case. Florian: Author should have taken fonts the same size. Florian: Not in that situation it's error handling. Florian: So they don't have a strong request one way or another. Florian: Tiny differences, maybe it doesn't really matter because barely visible. Florian: If not tiny differences, considered authoring error. SteveZ: I had a question about alignment when there is no alignment char in the object. SteveZ: Numeric value without decimal, e.g. SteveZ: What happens if no character? dauwhe: I think it inserts the character invisibly after the text. dauwhe: e.g. 1000 without .0 at the end. dauwhe: If you put other text in there, that would be a problem. SteveZ: In error-handling world, need to say what to do. franremy: I didn't think about this... franremy: Implementations looked into this? <franremy> The question was about implementer feedback on the proposal. fantasai: I think we should center it, it's not biased towards one directionality or alignment. fantasai: Does anyone have a different opinion? <astearns> as long as the virtual character is added in the case where it's missing, I'm for center. Florian: I don't think centering is the best option. I think it could be preferable to align to the left side of the character. Florian: Very often you are aligning numbers. Florian: If you misaligning the right is worse than misaligning the left. fantasai: I don't agree with you at all. Florian: Another way to deal is letter spacing. fantasai: No. <liam> [ front-alignment (i.e. rtl-dependent) will give the strongest result in most cases ] <liam> [ i.e. use the text direction of the table, not the actual text inside, but align everything to that, because the eye sees aligned things more strongly than centred things ] <astearns> liam - do you have examples and/or data to back up that assertion? <liam> i could probably find papers on gestalt perception and graphic design; the point is that it's a strong vertical axis, weakened when things don't quite line up on it <astearns> thanks Rossen: Going through 9.1 of text alignment. Rossen: As I understand current proposal, happens across table cells in same column. Rossen: It's a very simplified example. Rossen: What about borders, breaking, etc.? Florian: This is for the simplest use case. Florian: What would you do in such and such case? They say "you don't do it in that case." Florian: Nobody has any expectations for the complicated cases, because for people who need this nobody encounters those cases. Florian: There is a very strong demand for this from many places. Florian: Maybe less on purely web-oriented people, but as soon as you hit publishing. SteveZ: Financial publishing. <astearns> +1 to strong demand <liam> [ this isn't an edge case if you have a total of a sum of figures and put the total in bold ] Florian: Lots of people with tables with numbers in them. gregwhitworth: While there's a very specific use case, gregwhitworth: Still need to approach the generic standpoint, because people will put anything in a web page. Rossen: If you think about the way shrink-to-fit will be affected by this... just don't even want to think about it. Rossen: Currently in table algorithm, no dependency of content of tables besides knowing min/max. dbaron: To respond to what Rossen said, look at issues I added to the spec dbaron: Covered by issues 22-23. dbaron: I think it's a solve-able problem, but requires carrying around a bit more data. dbaron: But also some questions where the users need to say what they want before we can define the spec. <dbaron> (Issue 22 being the one starting with "This should have a formal definition") SteveZ: Seems like this is analogous to baseline alignment, just in the other dimension. SteveZ: Baseline can be arbitrarily aligned as well, yes. fantasai: Yes, you have this same problem in the other axis with baseline alignment, or in the column axis if the table cells' content is orthogonal. dbaron: We don't support that. Florian: My point is, a lot of these questions, we can't ask for examples because there is no such usage. We have to decide something, but it can't be based on convention because there is no such cases conventionally. dauwhe: I've been searching for pathological examples of this. dauwhe: So far very little luck. dauwhe: I think this may be as publishers, we're operating in constrained space. dauwhe: Won't see the kind of craziness in web implementations. dauwhe: Want to emphasize this is really a problem worth solving. Really clear use case. dauwhe: I think we should try. <Florian> +1 Yes, very clear demand. SteveZ: So off topic, or should we do this at all rather than where to align the character? SteveZ: Can we resolve on where to align the character, move on to other things? fantasai: I'm advocating center alignment, does anyone object? SteveZ: You'd have to compute the center, wouldn't require any kind of computation. astearns: Liam is advocating for start. Florian: Should be left, not start, because even in RTL numbers are LTR. Florian: Also, if you do have mixed directions across cells, the alignment needs to be consistent. Florian: Imho center is acceptable, left is preferable. astearns: Liam says we should use the writing mode of the table. Florian: No, because numbers are LTR. Rossen: The vertical centering is not a close behavior to how baseline alignment works. Table algorithms are based on column sizing as input and rows as results. Restarting row layout doesn't have global effect while column does. fantasai: If the numbers are shifted, that shift is going to affect alignment on both sides, and the shift in the number is going to be much bigger. fantasai: The right edge has the stronger alignment axis in general, so why would you align to the left? For example, money has a fixed number of digits on the right. SteveZ: I disagree, what's to the right is less important than what's on the left. SteveZ: Dollars more important than cents. fantasai: But the left side is not aligned anyway in many cases, so why are you caring about alignment on that side? Florian: The left edge is the easiest to implement, might as well go with that. <gregwhitworth> why can't this be controllable by authors, I can buy args for both - even though I think this will be quite complex to impl for a small usecase. <fantasai> not worth the switch <liam> [ Florian, in the case of LTR numbers in RTL it makes no difference; in the case of another character it might ] [A straw poll will be taken. Options: 1. Center 2. Left ] <fantasai> 1 <zcorpan> abstain <Florian> 2, 1 <SteveZ> left <dauwhe> 2 1 <BradK> 2 <astearns> 1 2, don't really care which <Rossen> abstain <liam> 2 out of these <gregwhitworth> abstain <dbaron> abstain, but maybe slight preference for left <koji> abstain <skk> abstain <Bert> slightly prefer 2 over 1 <jihye> like 2 more than 1 <eae> abstain <birtles> abstain <dbaron> (I'm also fine with table-start) <franremy> yes, abstaining fantasai: Visually the strongest alignment is going to be on the right edge, if you have dollars and cents, hours and minutes, etc. So if alignment is what you care about, you want the right edge, not the left edge. fantasai: So I think you're all wrong, but if you insist I'll put it in the spec. RESOLVED: left-align the alignment characters dauwhe: dpub will do what they can with the other issues, but some are beyond our capabilities, as they're implementation issues. dauwhe: Happy to answer questions about what's happening out in the world.
Received on Wednesday, 23 March 2016 21:32:26 UTC