/irc-logs / w3c / #css / 2015-08-26 / end

Options:

# Session Start: Wed Aug 26 00:00:00 2015
# Session Ident: #css
# [00:01] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [00:03] * Joins: ed_work_ (~ed@public.cloak)
# [00:15] * Quits: ed_work_ (~ed@public.cloak) (Ping timeout: 180 seconds)
# [00:24] * Joins: dauwhe (~dauwhe@public.cloak)
# [00:24] * Quits: dauwhe_ (~dauwhe@public.cloak) (Client closed connection)
# [00:26] * Joins: ed_work_ (~ed@public.cloak)
# [00:38] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [00:55] * Quits: ed_work_ (~ed@public.cloak) (Ping timeout: 180 seconds)
# [01:46] * Quits: darktears (~darktears@public.cloak) ("Leaving...")
# [01:49] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [01:50] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [01:51] * Joins: jdaggett (~jdaggett@public.cloak)
# [02:29] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [02:35] * Joins: estellevw (~estellevw@public.cloak)
# [03:15] * Joins: kwkbtr (~kwkbtr@public.cloak)
# [04:17] * Joins: skk (~skk@public.cloak)
# [04:19] * Joins: tantek (~tantek@public.cloak)
# [05:03] * Joins: liam_ (liam@public.cloak)
# [05:06] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [05:25] * Quits: myakura (~myakura@public.cloak) (Client closed connection)
# [05:25] * Joins: myakura (~myakura@public.cloak)
# [05:28] * Joins: skk_ (~skk@public.cloak)
# [05:32] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [05:37] * Quits: myakura (~myakura@public.cloak) ("Leaving...")
# [05:42] * Quits: tantek (~tantek@public.cloak) (tantek)
# [05:50] * Joins: skk (~skk@public.cloak)
# [05:53] * Joins: skk__ (~skk@public.cloak)
# [05:55] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [05:57] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [06:08] * Joins: skk (~skk@public.cloak)
# [06:12] * Quits: skk__ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [07:16] * Joins: skk_ (~skk@public.cloak)
# [07:20] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [07:38] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [07:48] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:54] * Joins: skk (~skk@public.cloak)
# [07:54] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [07:55] * Joins: dauwhe (~dauwhe@public.cloak)
# [07:57] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:02] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [08:03] * Joins: skk_ (~skk@public.cloak)
# [08:07] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:07] * Joins: skk (~skk@public.cloak)
# [08:08] * Quits: logbot (~logbot@public.cloak) (Ping timeout: 180 seconds)
# [08:09] * Joins: logbot (~logbot@public.cloak)
# [08:11] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [08:12] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:14] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [08:14] * jdaggett_ is now known as jdaggett
# [08:16] * Quits: dauwhe (~dauwhe@public.cloak) (Ping timeout: 180 seconds)
# [08:21] * Joins: johanneswilm (~johannes@public.cloak)
# [08:22] * Joins: skk_ (~skk@public.cloak)
# [08:26] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:27] * Joins: Florian (~Florian@public.cloak)
# [08:29] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [08:32] * Quits: liam_ (liam@public.cloak) (Ping timeout: 180 seconds)
# [08:36] * heycam|away is now known as heycam
# [08:38] * Joins: antonp (~Thunderbird@public.cloak)
# [08:39] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:39] * Joins: Florian (~Florian@public.cloak)
# [08:40] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [08:42] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [08:42] * Joins: Florian (~Florian@public.cloak)
# [08:46] * Joins: dauwhe (~dauwhe@public.cloak)
# [08:49] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [08:51] * Joins: tantek (~tantek@public.cloak)
# [08:57] * Joins: skk (~skk@public.cloak)
# [08:57] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:58] * Joins: Florian (~Florian@public.cloak)
# [08:59] * Joins: dael (~dael@public.cloak)
# [08:59] * Quits: MozParis (~MozParis@public.cloak) ("Page closed")
# [09:00] * Joins: hyojin (~hyojin@public.cloak)
# [09:00] * Joins: rachelandrew (~59cacb34@public.cloak)
# [09:01] * Joins: projector_ (~projector@public.cloak)
# [09:03] * Quits: projector_ (~projector@public.cloak) ("Page closed")
# [09:05] * Joins: MaRakow (~MaRakow@public.cloak)
# [09:07] * Joins: liam_ (liam@public.cloak)
# [09:07] * Joins: dino (~textual@public.cloak)
# [09:11] * Joins: lajava (~javi@public.cloak)
# [09:13] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [09:14] * Joins: joone (~joone@public.cloak)
# [09:15] <dael> plinss: Let's get started
# [09:15] * liam_ is now known as liam
# [09:15] <dael> Topic: Rounded Display
# [09:15] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [09:15] <Bert> Present+ Bert
# [09:15] <gregwhitworth> present+ gregwhitworth
# [09:15] <plinss> present+
# [09:15] <Florian> present+ Florian
# [09:15] <dauwhe> present+ Dave Cramer
# [09:15] <astearns> present+ astearns
# [09:15] <liam> Present+ Liam
# [09:15] <shane> present+ Shane Stephens
# [09:15] <zcorpan> present+ Simon Pieters
# [09:15] <dael> present+ Dael Jackson
# [09:15] <hyojin> present+ Hyojin Song
# [09:15] <MaRakow> present+ Matt Rakow
# [09:15] <skk`> present+ Hiroshi Sakakibara(skk)
# [09:15] <TabAtkins> present+ Tab Atkins
# [09:15] <iank> present+ Ian Kilpatrick
# [09:15] <dino> present+ Dean Jackson
# [09:15] <fantasai> present+ fantasai
# [09:15] <hyojin> CSS Round Display - Demo, Issues, FPWD Spec: https://drafts.csswg.org/css-round-display Polyfill: https://github.com/anawhj/jRound
# [09:15] <rachelandrew> present+ Rachel Andrew
# [09:16] <dael> hyojin: I'm hyojin Song and this is CSS ROund Display
# [09:16] * Joins: johanneswilm (~johannes@public.cloak)
# [09:16] <dael> hyojin: There are several interested parties. All of the application is interested.
# [09:16] <SimonSapin> present+ SimonSapin
# [09:17] <dael> hyojin: We believe that round display will be generally useful features.
# [09:17] <dael> hyojin: The radius property media query. It is a new CSS prop. We impl the area.
# [09:17] <Florian> s/All of the application is interested/We use Web OS, so all applications running on the device are web apps/
# [09:18] <dael> Joone: I work with Chromium Dev.
# [09:18] * Joins: dbaron (~dbaron@public.cloak)
# [09:18] <astearns> new properties are device-radius, shape-inside, border-boundary, and polar
# [09:18] <dael> Joone: During the last couple months we have been implt rounded display. It's based on chromium and allows dev to work with web technology. The web API and native intention fills the gap between web and native
# [09:19] <dael> Joone: We support rounded display to allow dev to support round across platforms including watch devices. Rounded display would let them support watch divce with web tech.
# [09:19] <hyojin> s/ROund/Round
# [09:19] <hyojin> present+ Jihye Hong
# [09:20] * Rossen_away is now known as Rossen
# [09:20] <dael> Joone: Also being able to surf the web with watches may become common in the future. People spend time browseing the web on mobile devices.
# [09:20] <Bert> -> https://crosswalk-project.org/ Crosswalk Project
# [09:20] <dael> Joone: We impl device radius with a boundry and there were issues. It only provides info on if the screen is round, there is not more detail such as the device radius in the spec. There was no way to know the radius, I think there should be more information on this including the radius
# [09:21] <dael> Joone: The other issue is border boundry. When you surf you may get a scrolling border. I think the web engine should not code web pages so the border boundry is supported. Jihye will show a demo.
# [09:22] <dael> Jihye: We made a simple web app with a divice using round prop. As you can see in round display the alignment of elements is specified to the round display.
# [09:23] <dael> Jihye: It is possible because the app rec. the shape of the device. Without the device properties and when we impl only considering the web and rectangular devices, some part of the display will be conceeled from round display.
# [09:24] <dael> Jihye: This ex shows how the prop works. The border is painted around the edge of devices.
# [09:24] <dael> Jihye: I will show some example using Garnet(?)
# [09:25] * Joins: ed_work_ (~ed@public.cloak)
# [09:25] <dael> Jihye: This ex shows the sample of garnet the web app framework that is used in other digiwatch which is using web OS platform. With this example you can choose the time fromt he number elements located around the round display.
# [09:26] <dael> Jihye: Not only in these examples, there are so many use cases in which elements are layed out like this on. Dev have to consider the center points and radius of the display as well as a radial variable.
# [09:26] <dael> Jihye: Desc using our methor, the elements can be located easily using polar position, angle, and distance.
# [09:27] <dael> Jihye: This is another example to show the scrolling event in round display. Different from the normal scrolling amounts, this UI is similar to scroll event
# [09:27] <liam> s/methor/method/
# [09:28] <fantasai> This example is showing a scrol list, with each item having an image on the lefthand, title and description on the right.
# [09:28] <fantasai> There's a title at the top, which is sticky
# [09:28] <dael> Jihye: When I'm using this, the scrolling is more comfortable and fasted than the normal method in the round display. In the sample, coordinates are complicated. Rounded method is implemented in real devices, scrolling performance is lagging. When we use polar distance and angle you can get improvements in showing the scrolling and elements.
# [09:29] <fantasai> The scrollbar is wrapped from the top of the circle to the bottom, with a curved scroll tab
# [09:29] * dael thanks fantasai
# [09:29] * ed_work_ is now known as ed_paris
# [09:29] <fantasai> The previous example showed a timepicker with a digital clock across the top third of the screen, X and check buttons across the bottom third, and hour/minute numbers around the clock face.
# [09:30] <fantasai> The first example showed a weather app, with a blue sky background and a white band containing information about the weather.
# [09:30] <fantasai> In square displays the white band was a box, smaller than the width of the screen, floating over the blue sky
# [09:31] <dael> Jihye: From the example just shown, I can show the prop related with polar, but the scrolling on the display isn't so different from general devices. I found this YouTube video about scrolling events in round display. Elements are aranged constantly in round method.
# [09:31] <fantasai> In the round display UI elements in the top corners were moved to the center, and the box was turned into a band across 2/3 of the screen.
# [09:31] <dael> Jihye: When dev want to do layout like this they have to use CSS shape and the text elements loc are calc in real time. We are planning to exapnd round display to deal with the scrolling event.
# [09:32] <dael> hyojin: That's the demo, the key point is it gives us radius and boundry as a prototype. We think those things are useful for authors.
# [09:32] * Joins: SteveZ (~SteveZ@public.cloak)
# [09:32] <skk`> https://www.youtube.com/watch?v=PRWHJwHqHuM
# [09:32] <skk`> This might be the demo video.
# [09:32] <dael> hyojin: Next, I will check the status of rounded display now. It could be bigger. We impl the pictures. Would you should the spec for round display?
# [09:33] <astearns> https://drafts.csswg.org/css-round-display/#device-radius-media-feature
# [09:33] <Florian> Hyojin: In terms of status, we would like to take round display to FPWD
# [09:33] <dael> hyojin: Round display is used to make this seem very simple. We would like a FPWD. I think to express the device display sheet would be of use.
# [09:33] <dael> hyojin: Any other opinion about device radius?
# [09:34] <dael> Florian: I think the general idea is about right. We could think of very complicated MQ to be explicit, but overshooting wouldn't be a good way of solving this. The level of complexity you're exposing is approx. right. I think there is a need for more details in the spec. It doesn't say if the corner is an elliptic or cut corner.
# [09:35] <dael> Florian: I think the MQ as decribed now could work, it just needs more details in the spec. I think we should try to flesh it out. I think the device radius MQ is generally the right approah.
# [09:36] <dael> Florian: It will work for elliptid displays if it use device radius instead of pixals. For cut corner, that's not the goal of this, but we should be able to give some reasonable semantics if the corner cuts less than the rounded corner. We can us min and max to get that.
# [09:36] <dael> Florian: If we spec these details correctly, we can do that.
# [09:36] <dael> hyojin: We rec comments from Florian about the device radius. We should cover the remaining issues in device radius.
# [09:37] <dael> Florian: Has anybody else thought of a different way of fixing this, or does this sound right?
# [09:38] <dael> gregwhitworth: I tried writing a response, but we're not in the market. My response was that this is perfect for the round display spec, but what if I want to do polar distance on something that's not round. I'd like to see it generalized. All the pieces are nec to accomplish this task. Just in general generalize the pieces so that they can accomplish more, make them generic. That gives you more power down the road.
# [09:38] <dael> gregwhitworth: Def. you're providing a good use case as you showed in the demo. Such as polar distance, you can use any shape. You can calc the cent of any shape.
# [09:39] <dael> Florian: The details we need to look into, but I think it can work. If you define 100% is the edge against the edge, if you're 100% you're following the shape. There's details, but we can work out the general.
# [09:39] <dael> fantasai: Should we pull the device radius MQ into the MQ spec?
# [09:39] <dael> Florian: I'm fine either way. I suggested it last time, but there was a thought to keep the pieces together. It's a question of who is working on it.
# [09:39] <dael> fantasai: I think we should eventually.
# [09:40] <dael> gregwhitworth: I think for all of them, position polar is a great way of fleshing this out, well done. I think we should be able to use it in a positioning spec, though. I'd love to see them focus on not just the use case of watches. Something more generic.
# [09:40] <dael> fantasai: For the border boundry and shape inside display values, what happens when you have these in an elemnt that scrolls
# [09:41] <dael> hyojin: Scroll is difficult. We internally test signifincaltly to use shape inside. We had some diff to desc scroll in shape inside.
# [09:41] <dael> Florian: The scrolling problem isn't limited to shape inside display.
# [09:41] <dael> fantasai: But what happens if you just scroll the outer doc and the position of the element changes.
# [09:42] <dael> TabAtkins: The way my watch does it is while you are wrapping to the shape you can't scroll. If you tap you can scroll and it turns into a rectangle shape.
# [09:42] <dael> TabAtkins: The idea I guess would be it maintains its shape based on your initial scroll position? So if you do scroll the doc you'd get a wierd circular area moving up.
# [09:43] <dael> Bert: I see in the spec it creates an intersection of the circular area so the shape changes as you scroll.
# [09:43] <dael> Florian: The text was re-wraping as you scroll.
# [09:43] <dael> astearns: The content stayed with the same line breaks and it moved with the shape.
# [09:43] <dael> plinss: I'm not sure the demo is complicated enough to show.
# [09:44] <dael> ??: gregwhitworth I think you made a good point because I think we're going to find other shapes in the future. I think there's a danger of trying to solve too general a case.
# [09:45] <dael> TabAtkins: I'm reviewing the video and it's using padding.
# [09:45] <astearns> s/??/liam/
# [09:45] <dael> gregwhitworth: They had something where the contact list was scrolling
# [09:45] <dael> TabAtkins: That was something magic and random.
# [09:45] <dael> gregwhitworth: You can see it's not wrapping on the video.
# [09:45] <dael> TabAtkins: That's custom scroller.
# [09:46] <dael> astearns: It's prob wrapping to the widest point in the display and moving around. There's other scrolling strat for rounded shapes. If you have the content layed out for three items and you flick to scroll you can scroll the entire thing away and get new items.
# [09:46] <dael> Florian: And there's a number of similar UI to pagination.
# [09:47] <dael> astearns: That was one of the start we considered when we did shape inside.
# [09:47] <dael> fantasai: Would it make sense instead of having individual elements that match to the intersection to say this element should have the same shape as the display and have the inner elements match the parent? Then you can have multi divs and within those you can tell to match.
# [09:47] <dael> astearns: Diff is knowing if the items inside will fit in a readable size.
# [09:48] <dael> fantasai: That's what regions are for.
# [09:48] <dael> liam: It breaks the metaphor that you're moving, though. There's quite a user issue.
# [09:48] <dael> Florian: In the spec for border boundry there is a value to match the display and to match the parent. We'll need something sim. for the shape itself.
# [09:48] * dauwhe most humans fear that they will match the shape of their parents
# [09:49] <dael> astearns: Border boundry has the parent value? It prob makes sense for shape inside to have it too.
# [09:49] <dael> TabAtkins: Do we have ex of border bounder?
# [09:49] <dael> Florian: In the weather app there was a faint border and in the rectangular one there was border around the pieces of text.
# [09:50] <dael> Florian: See the thin line around, that's a border boundry matched to a display.
# [09:50] <dael> Florian: If you know the screen is round you can use border radius, but if you don't know what the screen is going to be round fitting to the display is what you're trying to do.
# [09:51] <dael> esprehn: The text seems to be carefully selected. Does the text wrap at the edges?
# [09:51] <dael> Florian: That's the shape inside part.
# [09:51] <dael> esprehn: In the blue box, if there was more text, does it wrap to the round?
# [09:51] <dael> Florian: Yes.
# [09:52] <dael> Bert: There's note in the border part saying the text map overlap the border or the other way around.
# [09:52] <dael> TabAtkins: We know shape inside works with heavy overflow.
# [09:53] <dael> hyojin: We can find use cases. We have some troble to desc spec. How can we do what it is?
# [09:53] <dael> Florian: I think we need to go issue by issue. Doing a review of the entire spec in one go is something people won't have time to. i think we need to find one issue, fix it, and move to the next one. And we'll get there.
# [09:53] <dael> gregwhitworth: He did ask for a WD, though.
# [09:53] <dael> fantasai: If we're working on it, we should note the issues and publish.
# [09:54] <dael> Florian: Is there any new issues you might want to add?
# [09:54] <dael> hyojin: We were planning to do scrolling, but we couldn't do that for now. These ideas are enough to be a FPWD.
# [09:55] <dael> Florian: As we mentioned yesterday, it's good to have the entire scope of the spec ready fo IP reasons. If you want to add one more thing we should add it before going to FPWD.
# [09:55] <dael> hyojin: It's okay to cover the whole idea.
# [09:55] <dael> Florian: If you're happy to go with this the content is interesting.
# [09:55] <dael> Bert: There will be other opp. to mention things. The IP will go over again with CR.
# [09:55] <dael> Florian: The time inbetween would be long.
# [09:56] <dael> hyojin: Would it be possible to do the WD?
# [09:56] <dael> dbaron: I think it would be good to get issues noted in the draft.
# [09:56] <dael> hyojin: The issues last time, we modified the spec. We can get all these things, but we think it's enough to impl.
# [09:57] <dael> Florian: We don't have to resolve everything, just writing in the spec there is an issue when we don't have the solution is worthwhile.
# [09:57] <dael> hyojin: We can do that.
# [09:57] <dael> RESOLVED: Pending any issues, publish fpwd of CSS round display
# [09:57] <dael> Bert: Are we continuing this, or are we discussing more?
# [09:57] <fantasai> s/Pending any issues/Pending notation of any open issues in the draft/
# [09:57] <dael> Bert: I have 2 or 3 more details
# [09:58] <dael> Bert: About shape inside, I was wondering if another def might be useful. The shape inside display results in a shape that is the overlap of the actual viewport is the current text. What if I want to use that shape not on screen and move it in?
# [09:59] <dael> Bert: So I want to make an elemnt with that shape elsewhere and I want to move it in, not overlapping witht he actual position of viewport.
# [09:59] <dael> Florian: That would make the scrolling q earlier. You have to be careful to align when you do that.
# [09:59] <dael> Bert: So reusing the shape, but independant of its position.
# [09:59] <dael> plinss: How do you compute the instesection.
# [09:59] <dael> Florian: You just do the same shape, you don't intersect. Just hte same round of the screen.
# [10:00] <dael> plinss: But if it's not the same shape?
# [10:00] <dael> Florian: Same shape and size. That's tricky. If you have a square and a circle that fits, that's fine, but if you have a rectangle the same circle could fit, but there's a different.
# [10:00] <dael> Bert: I could set top and left to 0 and it would align.
# [10:00] <dael> Bert: That was my first thought when I saw the overlap.
# [10:01] <dbaron> I think the polar positioning parts are quite underspecified, and I also don't understand why position:polar goes on the parent of the element being positioned -- but I thought we discussed that last time we discussed this spec.
# [10:02] <dael> Bert: Polar position. I think gregwhitworth mentioned it also. This might be useful independant of fixed positioning. You might have any obj and just add some angular position to that. That made me think the polar keyword shouldn't be on the position prop.
# [10:02] <dael> Bert: Should maybe be somewhre so I can have abspos or relatively positioned that use polar.
# [10:02] <dael> Florian: So you want a relative polar that's relative to whatever.
# [10:02] <MaRakow> +1 to that
# [10:03] <dael> Bert: So I set a relative position and I use polar to move it. Maybe jsut make the polar coord prop active all the time, they're just 0 by default.
# [10:03] <dael> plinss: So left is 50px and polar is 30 deg.
# [10:03] <dael> Bert: That leads me to #3, we have a prop for motion path which solves that.
# [10:03] <dael> Bert: You would have the same effect with angular coord.
# [10:04] <dael> Florian: To answer plinss previous, you do positioning ignoring polar and from there you move in a polar way.
# [10:04] <dael> plinss: So transform.
# [10:04] <dael> Florian: Basically, yeah.
# [10:04] <dael> Bert: I think motion path and angular can move in the same way.
# [10:04] <dael> Florian: If the motion path is not a circle?
# [10:05] <dael> Bert: Rounded corners, I don't know if there's a motion path.
# [10:05] <dael> Florian: I think we can do this to follow the edge without even knowing what the shape is.
# [10:05] * dauwhe CSS Spirograph Module Level 1
# [10:05] <dael> Florian: If you go into a jewlery store there are varied watch faces.
# [10:05] <dael> Bert: I was trying to avoid redundant prop, but alright.
# [10:06] <Rossen> http://en.worldtempus.com/sites/default/files/de-grisogono-crazy-skull-01_watch_face_view.jpg
# [10:06] <dael> Bert: Have you looked at transform and motion path for different way to do it?
# [10:06] <dael> fantasai: It has nothing to do with motion.
# [10:06] <Bert> http://www.w3.org/TR/motion-1/#propdef-motion-path
# [10:06] <dael> Bert: It's a way of translating an object.
# [10:07] <dael> dbaron: So bert was suggesting the polar stuff be relative to whereever it was. That seems to introduce more work for the author because they need to center it first and then move. Starting in the center is more useful.
# [10:07] <dael> Bert: Using position fixed that would default
# [10:07] <dael> dbaron: No, you wouldn't get that.
# [10:07] <dael> dbaron: It would be good to have an issue befor eyou pub.
# [10:07] <dael> plinss: The % value on polar angle doesn't make sense. So 50% is 180deg, yeah?
# [10:08] <dael> TabAtkins: Polar angle is wrong.
# [10:08] <dael> fantasai: It also puts lengths for angles. There's some copy/paste issue.
# [10:08] <dael> fantasai: There's no angle value for the polar angle.
# [10:08] <dael> fantasai: Did that make sense?
# [10:08] <dael> hyojin: Yes.
# [10:08] * Quits: tantek (~tantek@public.cloak) (tantek)
# [10:09] <dael> gregwhitworth: Do we want to action the issue before FPWD?
# [10:09] <dael> Florian: The issues are in the minutes.
# [10:09] <dael> fantasai: It would be easier to find.
# [10:09] <fantasai> ACTION hyojin Fix Value line of polar-angle propdef
# [10:09] * trackbot is creating a new ACTION.
# [10:09] <trackbot> Created ACTION-706 - Fix value line of polar-angle propdef [on Hyojin Song - due 2015-09-02].
# [10:09] <fantasai> ACTION hyojin Fix Percentages line of polar-angle propdef
# [10:09] * trackbot is creating a new ACTION.
# [10:09] <trackbot> Created ACTION-707 - Fix percentages line of polar-angle propdef [on Hyojin Song - due 2015-09-02].
# [10:10] <fantasai> ACTION hyojin Remove "For" line from polar-angle propdef
# [10:10] * trackbot is creating a new ACTION.
# [10:10] <trackbot> Created ACTION-708 - Remove "for" line from polar-angle propdef [on Hyojin Song - due 2015-09-02].
# [10:10] <fantasai> ACTION hyojin Make polar-angle animatable as an angle
# [10:10] * trackbot is creating a new ACTION.
# [10:10] <trackbot> Created ACTION-709 - Make polar-angle animatable as an angle [on Hyojin Song - due 2015-09-02].
# [10:10] <dael> MaRakow: For fig 6, it seems to show tit describing the center area when you're doing position polar, is that something that happens when you're using position polar?
# [10:10] <dael> TabAtkins: I think it's how position polar works, seems reasonable.
# [10:10] <dael> MaRakow: It would be good to specify.
# [10:10] <fantasai> ACTION hyojin Make polar-distance animatable as an angle
# [10:10] * trackbot is creating a new ACTION.
# [10:10] <trackbot> Created ACTION-710 - Make polar-distance animatable as an angle [on Hyojin Song - due 2015-09-02].
# [10:10] <dael> TabAtkins: It would mean polar distance of 0 would be in the center.
# [10:10] <Florian> ACTION hyojin to make position polar apply to the element rather than the parent
# [10:10] * trackbot is creating a new ACTION.
# [10:10] <trackbot> Created ACTION-711 - Make position polar apply to the element rather than the parent [on Hyojin Song - due 2015-09-02].
# [10:11] <dael> Bert: And fantasai mentioned that 100% put it against the edge, not over.
# [10:11] <dael> TabAtkins: Unless you're pefectly circular, though...
# [10:11] <dael> Florian: I think we can spec it property, but it's impossible in real world geometry to get it always right. But at least when there is a correct, let's go there.
# [10:12] <fantasai> ACTION hyojin Make polar-distance percentages relative to distance from center to edge of containing block (or mark this as an issue) so that it works for non-circular shapes as well
# [10:12] * trackbot is creating a new ACTION.
# [10:12] <trackbot> Created ACTION-712 - Make polar-distance percentages relative to distance from center to edge of containing block (or mark this as an issue) so that it works for non-circular shapes as well [on Hyojin Song - due 2015-09-02].
# [10:12] <dael> TabAtkins: Whole concept only works when you're perfectly circular. If it's an ellipse, you don't want to move it all the way to the side when you have this huge major axis.
# [10:12] <fantasai> ACTION hyojin Remove "for" line from polar-distance propdef
# [10:12] * trackbot is creating a new ACTION.
# [10:12] <trackbot> Created ACTION-713 - Remove "for" line from polar-distance propdef [on Hyojin Song - due 2015-09-02].
# [10:12] <dael> TabAtkins: The purpose of this is buttons and you know the height because it's an image.
# [10:12] <dael> plinss: I accept that's common, but I don't think that's always true.
# [10:12] <dael> Florian: You had the case before where it's not.
# [10:13] <dael> TabAtkins: It's too magical to have something hug the edge. If you're rectangular, what do you do.
# [10:13] * Joins: tkonno (~chatzilla@public.cloak)
# [10:13] <dael> Florian: You do it so the outer border is tagent to the edge. if it's round you poke the corner at the edge.
# [10:13] * Joins: projector_ (~projector@public.cloak)
# [10:13] <dael> fantasai: It may not want to be default, but as an author it should be able to do it.
# [10:14] <dael> plinss: There should be a way, and maybe there should be a new keyword. If 100% does it magic, that's scary. If you have a rectangle you're moving in a circle, as I move it around the center if I'm 10% off it'll be moving in this odd flower shape. It should be achievable, but it shouldn't be the default.
# [10:14] <dael> fantasai: That makes sense.
# [10:15] * astearns looking forward to the conversations we have when we get to fractal borders
# [10:15] <TabAtkins> http://www.warnerbros.com/archive/spacejam/movie/jam.htm
# [10:15] <fantasai> s/achievable/achievable without JavaScript/
# [10:15] * fantasai thinks that is important to note
# [10:15] <dael> Florian: In general I think for when designing layout and positioning, being robust to changes in the size and shape of display is something we try to do. I also accept plinss point, so we need both.
# [10:15] <dael> TabAtkins: I'm okay with more complicated requiring JS to run.
# [10:16] <dael> TabAtkins: You're doing something that's fairly difficult. There's no flow, it's jsut abspos. That's in general a fragile method. If you want complex you need JS.
# [10:16] * Joins: skk_web_ (~skk_web_@public.cloak)
# [10:16] <dael> Florian: Abspos is fragile about something things, but 0 is the edge. It's easier for abspos, but you don't go off screen by accident if you do 0.
# [10:16] * Quits: projector_ (~projector@public.cloak) ("Page closed")
# [10:17] <dael> fantasai: You could have a prop that says where the anchor point is. Instead of always the center, choose which point and have an auto that picks it.
# [10:17] <dael> gregwhitworth: This sounds like motion path again. You get to pick you anchor points and the default is in the center.
# [10:18] * Joins: jihye (~jihye@public.cloak)
# [10:18] <dael> fantasai: You could have a polar anchor. It would take a position and an auto keyword which would do the thing you want. In the cases where you want to position something exactly this distance you pick the bottom left corner.
# [10:18] <dael> gregwhitworth: And the bounding box is a rectangle?
# [10:18] <dael> TabAtkins: Border radius is
# [10:18] <dael> tantek: Does anyone else have experience designing UI with polar coordinates?
# [10:19] <dael> Florian: liam had rounded pages?
# [10:19] * Joins: projector_ (~projector@public.cloak)
# [10:19] <dael> liam: Never with polar coordinates.
# [10:19] * Joins: tantek (~tantek@public.cloak)
# [10:19] <dael> liam: It is worth thinking about if you start dealing with polar coord, if you need trig in calc.
# [10:19] <dael> Florian: Then you have to understand trig to use CSS
# [10:20] <dael> liam: You have to in order to use polar coordinantes
# [10:20] <dael> liam: You work with non rectangular if you do print work, but the page doesn't scroll so you can fake it with a shape on the outside.
# [10:20] * dauwhe http://wp.patheos.com.s3.amazonaws.com/blogs/godandthemachine/files/2014/06/codex.jpg
# [10:21] <Florian> Hyjojin: Songbo Han is no longer working on this, so I would like to become the Editor
# [10:21] <dael> hyojin: One more thing, I have a request to change the co-editor because the current editor retired. Would it be possible to change?
# [10:21] <dael> Florian: If the person who was working on this no longer is, that makes sense.
# [10:21] <dael> TabAtkins: That should be fine.
# [10:21] <dael> fantasai: So, mark as an issue, potentially add an anchor property
# [10:21] <dael> fantasai: Is that a reasonable issue?
# [10:22] <dael> Florian: Sounds reasonable to me.
# [10:22] <fantasai> ACTION hyojin Add issue about positioning items to the edge of the containing block without overflowing it; potentially solved by polar-anchor: <position> | auto
# [10:22] * trackbot is creating a new ACTION.
# [10:22] <trackbot> Created ACTION-714 - Add issue about positioning items to the edge of the containing block without overflowing it; potentially solved by polar-anchor: <position> | auto [on Hyojin Song - due 2015-09-02].
# [10:22] <dael> RESOLVED: add hyojin as an editor to round display, more Songbo Han to former editor
# [10:23] <dael> fantasai: The top item should go to MQ, shape inside goes to shapes, polar coord into positioning. Border contain into borders 4. borders 4 is shaky right now. Positioning needs a lot of work.
# [10:23] <dael> Florian: MQ is getting stable. There's a few area that are not quite there.
# [10:23] <dael> fantasai: AS MQ approaches CR, we should pull in device.
# [10:23] <dael> plinss: Ready to move on?
# [10:24] <dael> Topic: Grid Layout
# [10:24] <fantasai> Florian^: Keep it together for now, pull out as these other specs stabilize
# [10:24] <Florian> s/more Songbo/move Songbo/
# [10:24] <dael> fantasai: We had the arguement on margins and padding yesterday.
# [10:25] <plinss> s/Songbo/Soonbo/
# [10:25] <dael> fantasai: We have an issue on row gap and column gap and potentially using grid-row-gap instead of the column-gap
# [10:26] <dael> fantasai: We don't have to worry about the normal value which is good. Also if we're using grid layout to go over a multi-col we would have a conflict between the two prop which I can imagine us doing if we started working on the snap to grid. If we do that we'd have a conflict with the prop.
# [10:26] <dael> Rossen: Do you recal the reason we converged on reusing the gap prop?
# [10:26] <dael> fantasai: Because it was there and why not reuse it?
# [10:26] <dael> TabAtkins: I suspect it's better to swtich to grid specific.
# [10:26] <dael> Rossen: I'm not opposed if there's a necessity.
# [10:27] <dael> fantasai: I'm not sure we'll run into it, but it's possible.
# [10:27] <astearns> https://drafts.csswg.org/css-grid/#issue-bbfb3743
# [10:27] <dael> fantasai: Knowing if we'll run into this issue requires writing the entire snap to grid module, and that's far in the future.
# [10:27] <dael> Rossen: If you insist to add it as a preventitive measure, we could.
# [10:27] <dael> Florian: Is that the topic at NY where we decided to share?
# [10:28] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [10:28] <dael> fantasai: We discussed adding the properties. We had a resolution to add them. We had row-gap for multi-col and why not reuse that. But I thought we might use that with the grid snap. That was an issue wehre I thought we might run into this, we might not. It might be a problem.
# [10:29] <dael> fantasai: Anybody else havea comment?
# [10:29] <dael> plinss: It's prob good to sep to grid-column-gap and grid-row-gap. You don't want grid-gap to reset multi-col gap, do you?
# [10:29] <dael> fantasai: It doesn't now. I don't want it to. It doesn't make too much of a difference.
# [10:30] <dael> rachelandrew: The advantage of grid spec is if it acts the same as multi-col, they'll expect it to behave the same in the future so if there's any change the different name will keep people from expecting the same behavior.
# [10:30] <dael> fantasai: Arguements not in favor?
# [10:30] <dael> fantasai: Might as well do that then.
# [10:31] <dael> RESOLVED: switch row-gap/column-gap to grid-column-gap and grid-row-gap and maintain grid-gap as the shorthand name.
# [10:31] <dael> plinss: Would it be better for grid-gap-column/-row?
# [10:32] <dael> TabAtkins: We don't have a strong tendency on the current names. They have row or column at the end, but they are all grids and columns.
# [10:32] <dael> TabAtkins: I'd be fine either way.
# [10:32] <dael> fantasai: I think leaverou prefers matching the short hand conventions.
# [10:32] <dael> TabAtkins: Do you want to say grid-gap-rows/-columns
# [10:32] <dael> fantasai: Do we plural in any others?
# [10:32] <dael> TabAtkins: Yes.
# [10:33] <dael> fantasai: Then yeah, they should be plural.
# [10:33] <leaverou> re:shorthand conventions, that ship has sailed
# [10:33] <dael> fantasai: Let's be consistant as much as possible.
# [10:33] <leaverou> but yeah, consistency is good
# [10:33] * Quits: joone (~joone@public.cloak) (Ping timeout: 180 seconds)
# [10:33] * leaverou will be there very soon
# [10:33] <dael> hober: It sounds more like the gap in the rows.
# [10:34] <dael> esprehn: I think grid-row-gap sounds better.
# [10:34] <dael> TabAtkins: Two choices grid-row-gap and grid-gap-row
# [10:34] * astearns gnip-gnop-gnap
# [10:34] <dael> A) grid-row-gap, B) grid-gap-rows
# [10:35] <dael> TabAtkins: Why don't we just poll authors.
# [10:35] <dael> TabAtkins: This is easy to poll for.
# [10:35] <leaverou> I can poll authors pretty quickly and have results today
# [10:35] <dael> TabAtkins: If everybody is okay, we'll set up a poll.
# [10:35] <dael> fantasai: leaverou said she'll set up a poll.
# [10:36] <fantasai> leaverou, gregwhitworth suggests that authors should try to read them out loud, too :p
# [10:36] <dael> plinss: To throw another wrench, maybe use letter instead of gap?
# [10:36] <dael> fantasai: But we have gap.
# [10:36] * leaverou goes offline for a few minutes to actually come to the meeting :P
# [10:36] <dael> s/letter/gutter
# [10:36] <dael> fantasai: I do that in the tracking section.
# [10:36] <dael> plinss: It's just a suggestion.
# [10:36] <fantasai> s/have gap/have column-gap/
# [10:37] <dael> TabAtkins: grid-gutter-rows does work.
# [10:37] <fantasai> s/column-gap/column-gap, want to be consistent/
# [10:37] <dael> hober: You're deciribing the gutter not the gap.
# [10:37] <rachelandrew> i've got a lot of people on my list re layout stuff so I can share any naming poll with that group
# [10:37] <dael> dbaron: The way you desc make it sound like they count as rows.
# [10:37] <dael> TabAtkins: You have gutter rows and regular rows and for layout they're both rows.
# [10:37] * astearns this is all sounding very Seussian to me by now
# [10:37] <dael> TabAtkins: You have to use row or column in there somewhere.
# [10:38] <dael> TabAtkins: We'll figure this out.
# [10:38] * astearns beware the gutter gap nutter snitch
# [10:38] <dael> TabAtkins: I think next is the repeat stuff, or there another?
# [10:39] <astearns> https://drafts.csswg.org/css-grid/#issue-db68a1c3
# [10:39] * dauwhe through three cheese trees three free fleas flew
# [10:40] <dael> fantasai: Let me grab issue 10. There's a stretch keyword for the alignment prop. We have align content and justify content and when you put that ona grid container you can set it. You can also destribute evening. You can also use stretch which appears in flexbox. I tonly stretches tracks that are auto sized. Alt would be to stretch all the tracks. I wanted to know opinion
# [10:40] <dael> Rossen: Stretching tracks that are fixed. If anything we can add an anon column that could be stretched. I wouldn't be in favor of stretching.
# [10:40] <dael> plinss: If people do tile images and they stretch, it'll break.
# [10:40] <dael> RESOLVED: stretch stretches auto-sized tracks only
# [10:41] <dael> fantasai: Last issue is the auto-filling.
# [10:41] <dael> TabAtkins: Issue 5/6 in the draft.
# [10:41] <dael> [they head to the whiteboard]
# [10:41] <astearns> https://drafts.csswg.org/css-grid/#issue-a3dd1e18
# [10:41] <astearns> https://drafts.csswg.org/css-grid/#issue-6d21701c
# [10:42] * dauwhe seven brides for seven brothers
# [10:43] <dael> fantasai: The general issue is there's a common use case people want to solve. You have some arbitrary # of items and want to arrange them into a grid. Say I have 7 items and I want to have them in a tiled layout. People are trying to do this with flexbox and if you don't have exactly enough to fill up the last line, they don't like up into a grid.
# [10:43] <rachelandrew> something like this demo (which works in Blink with exp. web platform features flag on) http://codepen.io/rachelandrew/pen/ZGgZpB/
# [10:44] <dael> fantasai: Let's say I have 450px and I have 7 items that are 100px, I would have lets have 4 columns and 3 rows and there's an extra 50 px and I'd say please stretch to take up that extra bit of space.
# [10:45] <dael> fantasai: If you do that with flex you'll get awkwardly sized bottom box. That's fine for flexbox, it's not supposed to be a grid. However, that's the goal for the grid spec. This is a common need. The problem we have right now is the grid template rows/coumns require you to know how many you have in the main dimention.
# [10:45] <dael> fantasai: You need to spec. the num of columns in one direction. You have to give a number for the repeats too. So we were thinking lets do an auto keyword so that it repeats.
# [10:46] * leaverou is now known as leaverou_away
# [10:46] <dael> fantasai: There were two issues. Let's say my viewport is x big and I only have two items. What that will do, the repeat syntax was repeat(auto, 100px) and it will fill with the number of columns that would fit.
# [10:47] <dael> fantasai: Sometimes the author might want the fallback to do something different like center them. One idea we had was have two different keywords. auto-fit and auto-fill. Auto-fill would drop all the empy columns. Auto-fit would put things in like this.
# [10:48] <dael> fantasai: There's a limitation on this syntax, this is pre-layout so we have to put a fixed size. We can't say start putting content in and that's how wide it should be. That is a common use case, you might not want to be explicit, but we don't want to do a full pass.
# [10:48] <dael> TabAtkins: The repeat(auto) syntaxes, you'd have a second fixed grammer that only had lengths and percentages. You also could only have one repeat function as well.
# [10:48] <dael> fantasai: Thats' the best solution we've come up with. We think this is an important use case.
# [10:49] <dael> TabAtkins: Like catelogs where they want to lay things out, they know what size, but they don't know how many things there will be.
# [10:49] <dael> fantasai: So that's the best solution we've come up with, we're looking for comments and if you have anything better to add. Like we could add a size of the first item keyword.
# [10:49] <dael> TabAtkins: Um, no, I don't like it.
# [10:50] <dael> fantasai: I would work for most cases.
# [10:50] <dael> TabAtkins: If everything is going to be the same size, that's when you would know it.
# [10:50] <dael> fantasai: Okay. Thoughts from the WG?
# [10:50] <dael> Rossen: Good.
# [10:50] <dael> fantasai: Anybody else?
# [10:50] <dael> gregwhitworth: Seems good.
# [10:50] <dael> Florian: The use case makes sense, but for the solution I'm too far out in my confort zone.
# [10:50] <dael> TabAtkins: It may not be optimal, but it does the job.
# [10:51] <dael> fantasai: resolve to add it?
# [10:51] <dael> rachelandrew: I spent a lot of time thinking it through, I can't think of a better way to describe it. It's complicated, but it makes sense.
# [10:51] <dael> TabAtkins: We think we're iterating toward fixture witht he spec.
# [10:52] <dael> RESOLVED: Add repeat(auto-fill) and repeat(auto-fit)
# [10:52] <dael> fantasai: That's pretty much it for design issues. There's a ton like add example, need more picutres. We're planning to make these last edits and we're done and we need review to suss out more issues.
# [10:53] <dael> TabAtkins: We're feature complete and want to move it to bug fix and eventual CR. We need review of stuff, there is an issue or two in the layout algo that we'd like review on.
# [10:53] <dael> fantasai: We'd like to pub a WD after these last edits are in. That will be the last WD unless people raise issues, which we encourage people to do.
# [10:54] <dael> TabAtkins: So, are people okay to resolve to publish after we do the edits, or review after we edit before publish.
# [10:54] <dael> RESOLVED: Publish grid WD after the above edits
# [10:55] <dael> plinss: Okay for grid?
# [10:55] <dael> TabAtkins: That's it for grid.
# [10:55] <dael> <break=20min>
# [10:59] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [11:02] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [11:12] * Joins: Florian (~Florian@public.cloak)
# [11:21] * leaverou_away is now known as leaverou
# [11:21] * Joins: ChrisL (clilley@public.cloak)
# [11:22] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [11:22] * Joins: Florian (~Florian@public.cloak)
# [11:23] <dael> plinss: Let's get started
# [11:24] <dael> Topic: Animations
# [11:24] * dauwhe hober: we need search for w3c memes
# [11:24] <dael> birtles: The topic is CSS animations level 2
# [11:25] <dael> birtles: Most of you know animations as an API, but there's another part to web animations. How do things like repitiion work. So CRR animations and transition are using the definitions from SVg on how they work. If they do that you can use the same API to inspect those.
# [11:25] * hober dauwhe: you should tell whoever the shadowy people behind the curtain are
# [11:26] <dael> birtles: I think it both Chrome and FF have been working on moving to that code.If you're used to seeing some of that code, it's usinghte API. We'd like to expose it up, but we need a definitive was from CSS into that and the obvious place is Animations 2
# [11:27] <birtles> https://rawgit.com/shans/csswg-drafts/animations-2/css-animations-2/Overview.html
# [11:27] <dael> birtles: It exists as a delta spec to spec the cancelation event. shane and I have looked to add the definitions of how CSS animations maps onto the other animations.
# [11:27] <dael> birtles: I wanted to bring this up today to ask how we should proceed. I'm finding it difficult to handle as a delta spec. I'd like to drop in text to animations that's covered by web animations. That's the initial topic and other people might have suggestions for Animations level 2
# [11:28] <dael> dbaron: I think the work, I don't think rewirting on top of web animations will work as a delta spec, but I'm worry about starting it at this stage because there are a bunch of edits we need for level 1. If you're willing to backport that's fine, there will be more work.
# [11:28] <dael> ChrisL: Short term it will be more work, but having single souce where it could be edited would make sense.
# [11:28] * Joins: Florian_ (~Florian@public.cloak)
# [11:29] <dael> birtles: I'd like to ship this and having the edits done in animations 1 is a blocked.
# [11:29] <dael> fantasai: May I suggest you make the edits to animations 1.
# [11:29] <dael> birtles: Okay? I should check the scope, but tentitively yes. I'm not a member of the WG.
# [11:29] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [11:30] <dael> dino: Isn't there something about having animations 1 so far down in the rec track?
# [11:30] <dael> dbaron: birtles is agreeing to help with the things that need to get done with animations 1 so that we can get to animations 2
# [11:30] <dael> fantasai: Who is the editor?
# [11:30] <dael> dbaron: Me.
# [11:31] <dael> RESOLVED: add birtles as editor to Animations pending him getting added to the WG
# [11:31] <dael> fantasai: dbaron is busy and since you're working on animations it makes sense that you can help move it along and that will help you.
# [11:31] <dael> birtles: That's the main in regards to animations.
# [11:31] <dael> shane: Do you want to talk about adding the animation composition prop?
# [11:32] <dael> birtles: Not particularly. I was thinking of adding a prop to that branch, but it's not a priority.
# [11:32] <dael> plinss: That's it for animations?
# [11:32] <dael> Topic: snap points and oversized elements
# [11:32] <TabAtkins> https://drafts.csswg.org/css-scroll-snap/
# [11:33] <dael> TabAtkins: fantasai and I have been revieweing snap points recently. We havea few suggestions to go along witht he scroll snap prop. One in particular we think is required. It's the handling of snapping elements whenthey're too large for the viewport.
# [11:33] <dael> [whiteboards]
# [11:34] <dael> TabAtkins: If you have a viewport and the element is too large for the viewport and you center snap it, you have a problem. If you want you can drag over, but it will snap to the center or another point.
# [11:34] <dael> Florian_: And if it's a got bigger you wo't be able to scroll.
# [11:34] <dael> TabAtkins: And arrows would be a problem too
# [11:35] <dael> TabAtkins: This will happen all the time. I expect thigns like image gallaries will be designed for a certain width and on a smaller screen you will have overflow. So it's problematic, common, and user hostile.
# [11:36] <dael> TabAtkins: We came up with a proposed behavior. Our prop is, whenever you snap to an element and it's larger thant he viewport in some axis. In the overflowing axis you then stop snapping to that element from now on. It sticks there and no longer tries to snap. The edges become the new snap points.
# [11:37] <dael> TabAtkins: It will try and avoid escaping, but if you fling well past it will scroll off. You have to be a bit stickful, but we believe it's a fairly general user friendly behavior. This is similar to how existing apps work, like gallary on Android and MS phones.
# [11:37] <dael> TabAtkins: I think this is a fairly reasonable behavior and we should mandate this.
# [11:38] <dael> fantasai: To do that, the spec needs to be working on the basis of snapping an area to a position. A box to a box as an alignment thing. Rather than a point to a point because you don't know how big the area is for the points. So you spec not the points, but the box and the alignment of the box. You position the box.
# [11:38] <dael> fantasai: You would say if you want the border box or margin box and if you need additional margin there an offset ability.
# [11:38] <dael> TabAtkins: Though that's not strictly nec to fix this. The minimum is a slight spec change and a behavioral change.
# [11:39] <dael> fantasai: You'd still need to know what the box is.
# [11:39] <dael> dino: I wasn't quite sure what fantasai said, but I think I understand enough to support what you're proposing that you snap to the edge when you overflow.
# [11:40] <dael> TabAtkins: We are happy to look into alternates or refinements, but I think what we've desc is a reasonable first cut.
# [11:40] <dael> dino: Behaviorally, let's say you've got regular size elements and scroll the big one into view. You're on a normal element and you start scrolling into view, what happens when you get to it.
# [11:41] <dael> TabAtkins: It should still do the normal snapping first. It seems to be reasonable and simple.
# [11:41] <dael> hober: The implicite edges only activate after you snap.
# [11:41] <dael> fantasai: [whiteboards]
# [11:43] <dael> Florian_: In gerenal I agree with what you're trying to fix. I also agree with your prop. The thing I'm wondering about is if this is the behavior we should spec, or if this is a reasonable behavior and they might find other ways to provide to move.
# [11:43] <dael> fantasai: I think we can allow UA to innovate as long as they let the user get to each part of the content.
# [11:43] <dael> TabAtkins: I think we should spec based on requirements and provide this as an example.
# [11:45] <dael> MaRakow: The discussion we had last night was about trying to predict how it would feel. My experience is you can't tell if it feels natural until you spec it. I stateful example isn't intutitive in my experance. You snap to the center at a top level and snap to an individual and it's free panning. It's a good goal to say if content is too large find a smart way to show all the content. It's not clear this will solve every case.
# [11:45] <dael> TabAtkins: I'd love to spend time to prototype, I didn't have time.
# [11:45] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [11:45] <dael> TabAtkins: Are you comfortable with us drafting UA requirements for overlarge?
# [11:46] <dael> MaRakow: We need to figure out how the phrase that. I think once we prototype we'll understand what those req need to be a bit more. There's a lot of ways to ensure all the content is viewable and I don't want to go too far withour knowledge.
# [11:46] <dael> dino: Like if you make it 1px smaller you need two swips.
# [11:46] <dael> fantasai: Once you'd swiped it's fine.
# [11:46] <dael> TabAtkins: If it's huge you might need to swipe twice.
# [11:47] <dael> dino: With the photo apps you can swipe to the edge and go to the edge.
# [11:47] <dael> Florian_: This concern about hte ways you might interact is why I was suggesting lose phrasing about the UA. I think we need to change a bit the internal model so that you can work around and prop a UI.
# [11:48] <dael> MaRakow: Your 1px example, swiping would take you out, but using arrows you might not get out. Prototyping would catch that. I like the goal to make large content easier.
# [11:48] <Florian_> s/UA/UI/
# [11:48] <dael> TabAtkins: I'd be happy to help draft some text that says you must allow the user to do the whole thing and maybe this as an example and we ca revise as we find better ideas. Some sample that's better than nothing so you can see you can do it this way or something better.
# [11:49] <dael> MaRakow: Let's start down that route.
# [11:49] <dael> fantasai: Robert O'Callahan would like us to get through this sooner rather than later.
# [11:49] <dael> TabAtkins: We have several other edits to the spec which can be built on top of the spec or a simplified version that address some use cases.
# [11:49] <dael> fantasai: We'll go down the spec
# [11:50] <dael> fantasai: Some of the use cases are in the scroll snapping. A key one is snap to the start or middle of each box. Those are two of the use cases and that's how it would look in our prop [projector]
# [11:50] <dael> fantasai: There's a snap area that tells you if you're snapping to the border or margin box with some offset.
# [11:51] <fantasai> https://drafts.csswg.org/css-scroll-snap
# [11:51] <dael> TabAtkins: So whenever you scroll through, our example snaps just before the bottom of the screen. This is similar to the spec where you define the viewport as just above the edge.
# [11:51] <dael> Florian_: Just a bit of bikeshedding, the snap area with a em, shouldn't it be a snap offset?
# [11:52] <fantasai> fantasai: yes, we should probably split scroll-snap-align's offsets into a separate property
# [11:52] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:52] <fantasai> e.g. scroll-snap-margin
# [11:52] <dael> TabAtkins: Here's anice picture of it from the spec. The current spec does it via snapping two points together. It sets 50% and 100px on the scrolling area, so slightly down and 50% 0 on the item so the center top aligns slightly down from the center.
# [11:53] <dael> TabAtkins: Or prop instead says you always scroll to the top and you'll treat the boxes as a little bigger. It's just two different ways of looking at the same model, but we feel the box based is more intuitive to the author.
# [11:53] <dael> dino: So if you added your prop to this, it would move the red x...
# [11:53] <dael> TabAtkins: We talk about integrating in a bit.
# [11:54] <dael> liam: So you only do snap points hwen the used is scrolling or dragging.
# [11:54] <dael> TabAtkins: You do initially and then whenever there's an inertial scroll.
# [11:55] <dael> MaRakow: The common case was if you have a view poirt that's sized like % as you resize the scroll. THe size might change so you might see half a photo. The snap point isn't about the scroll, but a valid view.
# [11:55] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [11:55] <dael> TabAtkins: The gravity well descibes it well...in a manditory you go all the way over to the next manditory point. Which is does depends on how strongly your design requires the motion.
# [11:58] <dael> fantasai: We had a scroll snap align prop in the spec, it was the scroll snap area property.
# [11:58] <dael> fantasai: We had scroll-snap-box: [border-box|margin-box|] and scroll-snap-margin: [<length>|<percentage>]
# [11:58] <dael> fantasai: The align prop says when am I snapped. What relationship of me to my viewport causes me to snap.
# [11:59] <dael> fantasai: If you have center then the center is in the center of the box and that's a snapping position. It works kind of like background positioning
# [11:59] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [11:59] <dael> Florian_: Does edge mean start and end?
# [11:59] <dael> fantasai: Yes.
# [11:59] <dael> MaRakow: We talked about that last night and the behaviors you would expect being directional
# [11:59] <dael> fantasai: We'll get to that in the use cases.
# [11:59] <dael> hiroshi: It it impossible to align to an arbitrary place?
# [12:00] <dael> TabAtkins: The current, what's currently written it's impossible, but we were given decent use cases last night so it's fine and we should extend that.
# [12:00] <dael> TabAtkins: We'll still want start and edges, but replace center with a position.
# [12:01] <dael> TabAtkins: scroll-snap-align is scoll-snap-coordinate in the current spec.
# [12:01] <dael> MaRakow: Before we move too far, the distinction between two points and one offset, if it's more natural for the offset to be one point or two and if it's more natural to distinguish from the edge or the top.
# [12:02] <dael> fantasai: The other model is I want 100px of space between the viewport and the edge when I'm snapping.
# [12:02] <dael> MaRakow: Where it's one offset, yes. The other case is when you have two complex things where you want to share a position. You have a bunch of cities on a map and those cities might not be the center, you want to snap to the center of the region and it's a more complex destination.
# [12:03] <dael> TabAtkins: That's the distinction between 1d and 2d snapping.
# [12:04] <dael> Florian_: The map example, even if you're in 1d you may have overlays over the edge of the scroller. In the example you gave I agree it's more natural, but if you have an overlay over the scroller saying snap to after the overlay, you know the size of the overlay. most of the time 1 thing is fine, but once you're dealing with overlay having multiple points.
# [12:04] <dael> fantasai: So also having scroll snap padding on the scroller?
# [12:04] <dael> Florian_: Yes.
# [12:04] <dael> MaRakow: You can have the single point or you can do the mental gymnastics.
# [12:05] <dael> Bert: Question on the edges. YOu could have a conflict where the two edges are close, to which do you snap?
# [12:05] <dael> fantasai: Closest and if there's a tie, maybe the top one?
# [12:05] <leaverou> what happens when the elements are overlapping?
# [12:05] <dael> Bert: I don't want it flipping
# [12:05] <dael> fantasai: Once you snap it's the nearest.
# [12:05] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [12:06] <dael> MaRakow: There's a lot that goes into which you snap to, you might have velocity or weight. There's complex algo that the UA might want to use. In general that's why I phrased the spec in terms of here's a valid place to be.
# [12:06] <dael> fantasai: Use case 2 is a group snapping one, we should save that.
# [12:07] <dael> TabAtkins: 2d snapping. We have 2 ex. One is a flow chart or a call graph, you have a bunch of boxes in a graph, it would be nice to end where something is aligned with the edge. To do that, our model is a type of scroll-snap-type: proximity and on each edg eyou do align edges.
# [12:07] <dael> Florian_: And you could do margin 10px for comfort.
# [12:07] <dael> TabAtkins: Yeha.
# [12:08] <dael> TabAtkins: This shows off how some of the simple point ot point is insuffienctly strong in some points. THis is edges of a box so you have relationship nec. to do something smart.
# [12:08] <dael> TabAtkins: ex #2 is a map. You're looking at google maps, when you fling to near a city, center the city and you just give each city a snap-align of center.
# [12:08] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [12:08] <dael> TabAtkins: This example is similar the the ex in the current spec.
# [12:09] <dael> fantasai: The thing to distinguish when you're doing align to edges, you might be happy that it snaps to one corner, but it only snaps to one direction. The center is different when any dimention you're close to the center it snaps to that point.
# [12:10] <dael> TabAtkins: [whiteboards] You don't want a map with two cites where one has centered vertically and one horizontally. The algo in the spec destinguishes between 2d and 1d to make sure it falls out correctly.
# [12:10] * Joins: MaRakow (~MaRakow@public.cloak)
# [12:11] <dael> fantasai: Next is slideshow. Let's say I have a scrolling slideshow and each slide is given 100vh. I want to snap to the slides because I don't want to be halfway between. Sometimes you might have a slide that's a little bit taller because I have a really long picture, like redwood tree height.
# [12:11] <dael> fantasai: I want to be able to tell it to snap it's edges so I can scroll through it, but if I pull hard enough it snaps to the next one.
# [12:11] <dael> fantasai: This is an example of snapping both edges.
# [12:12] <dael> TabAtkins: So your slides is a horx flexbox with manditory snap points. Each slide is 100vw and a min of 100vh so that it can grow. As you go slide to slide it will align to the edges and you'll be able to scroll within.
# [12:12] * Quits: tkonno (~chatzilla@public.cloak) ("ChatZilla 0.9.92 [Firefox 40.0.2/20150812163655]")
# [12:13] <dael> TabAtkins: If you do a flick down and it's too powerful, you'll go down and hit the bottom.
# [12:13] <dael> Florian_: Is this the same rules as for center snapping that's too big for the screen.
# [12:13] <dael> fantasai: It's in terms of edge snapping.
# [12:13] <dael> Florian_: It seems these might be the same, but we might want to define sep.
# [12:13] <dael> fantasai: We currently define this as the behavior and the fallback is this is how you would do it. We could say could instead of should.
# [12:13] <dael> fantasai: That's a bunc hof use cases.
# [12:14] <dael> leaverou: With slides you have to scroll with the keyboard. I imagine with snap points you have to scroll more than half. If you have a keyboard you might not be able to get to the next slide.
# [12:14] <dael> TabAtkins: The current spec, when you scrollin a direction, we don't consider any snap points in the other direction
# [12:15] <dael> MaRakow: There's lots of ways to implement that. There are people who want light flicks to return you. I left it vague in the spec intentionally. One is that it's large enough for escape velocity. Another is that inputs are also a semantic meaning. home and end mean go to the end. Arrow keys make more sense to go to the snap point, not velocity.
# [12:15] <dael> MaRakow: Most UA should be able to come up with a sane way to do this.
# [12:16] <dael> TabAtkins: We should put that in the spec where inertial is easy to map, but that things like arrow keys need a semantic meaning.
# [12:16] <dael> MaRakow: Arrow keys might want to maintina a small amount of velocity.
# [12:16] <dael> TabAtkins: So if you hit the irhgt arrow key, you def don't want to go left.
# [12:17] * astearns upcoming: force-keypress
# [12:17] <dael> TabAtkins: If you do a tiny inertial flick it might be okay to bounce back
# [12:17] <dael> MaRakow: Right now it's intentionall avoiding the details of physics and inertia
# [12:17] <dael> TabAtkins: Yes, but the distinction is important.
# [12:17] <dael> MaRakow: I can see that.
# [12:17] * dauwhe the talk of implementation differences in physics alarms me.
# [12:18] <dael> MaRakow: As long as we're on the use case, for the edges value, should that be influenced by the directionality, Robert's e-mail said they had issues.
# [12:18] <dael> TabAtkins: Roc at some point suggested when we're scrolling down we care about top and up is bottomo but realized that was a bad idea.
# [12:18] <dael> MaRakow: I'm worried snap points on each edge might be the same bucket.
# [12:18] <dael> MaRakow: If they can snap half way up and half way down, it can be a problem.
# [12:19] <dael> TabAtkins: [whiteboard] if it's contributing two edges, if you're niavely handling this you'll scroll a little bit.
# [12:19] <dael> fantasai: A lot of these cases will be start. There's very few where you want edges.
# [12:20] <dael> MaRakow: You mentioned the flow chart and you have the edge of each item being the snap point. If you have 20 elements on screen, you lose track of what you're snapping. Each pan or scroll is snapping a defferent element.
# [12:20] <dael> TabAtkins: I feel you and I'l like to see the flow chart ex in person.
# [12:21] <dael> fantasai: I can imagine having a message app where you have edges on each message.
# [12:21] <dael> Bert: That's what I was thinking. that's a case that's useful.
# [12:21] <dael> dino: That's one dimentional. The flow chart there's so many.
# [12:21] <dael> TabAtkins: 1d and 2d are substantially different.
# [12:21] <dael> Florian_: Does manditory exist in 2d?
# [12:21] <dael> TabAtkins: Yes.
# [12:22] <dael> Florian_: Edge manditory in a flow chart would feel weird.
# [12:22] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [12:22] <dael> TabAtkins: The use case for manditory is a 2d, though.
# [12:22] <dael> Florian_: That's two 1d scrollers.
# [12:22] <dael> fantasai: So like Zelda where this is one room and then you go to another room and it snaps in.
# [12:22] <dael> Florian_: Okay.
# [12:22] * dauwhe can we animate and randomize the snap points?
# [12:23] <dael> MaRakow: One thing about the 1d case, ensuring that the element you're snapping to isn't the bottom edge of an element that's just off the top of the screen. Making sure the thing snapped to isn't off screen.
# [12:23] * Quits: dino (~textual@public.cloak) ("My MacBook Pro has gone to sleep. ZZZzzz…")
# [12:23] <dael> TabAtkins: Start edge of the box goes to the start edge of the scrolling container.
# [12:23] <dael> TabAtkins: That was the intention, though we might not have spec'ed that.
# [12:24] <dael> Bert: You skipped ex #2, grouping. I think that case makes grouping unnec.
# [12:24] <dael> TabAtkins: That was our basic exploration of lets recase the current spec into more familiar tables.
# [12:25] <dael> TabAtkins: Scroll snap type is the same. destination we can keep for compat, we tihnk it's nec. It will get auto where it matches what the element is going.
# [12:25] <dael> fantasai: Renaming it might be target.
# [12:25] <dael> TabAtkins: The new prop that's not in is scroll-group-align. On the children scroll-snap-coord. is to -align. I'm skipping area. Not too large.
# [12:26] <dael> fantasai: We're switching to an alignment model.
# [12:26] <dael> TabAtkins: We end on the same number of prop.
# [12:26] <dael> fantasai: Group snapping...
# [12:26] <dael> TabAtkins: Group based snapping isn't in the current spec.
# [12:26] <dael> fantasai: It's using the repeat syntax there.
# [12:27] <dael> TabAtkins: You might have a lot of items much smaller than the viewport and you want to scroll in a paged method. Rather than snapping each item, you can snap pages, like an address book.
# [12:27] <dael> TabAtkins: So the meaning of this is the element does its normal edge based, but it contributes the edges. If you look at the edges, the start most and end most become what you are not aligning. You take as many address pages, the first and last are what's aligned, and we continue down the scroller.
# [12:28] <dael> fantasai: [whiteboards] so I have a bunch of randomly sized boxes. I line them up and take the first edge. I go down one screenful and that becomes one page. I go down to the next, find the end edge, and that's the next screen. So what is the whole number of these items that will fit.
# [12:29] <dael> TabAtkins: So if you know the size of the items you can use wrapped divs, but if you don't know this does it for you.
# [12:29] <dael> Bert: And this is dynamic?
# [12:29] <dael> TabAtkins: We haven't gotten into a ton of detail
# [12:29] * Rossen runners unite https://wiki.csswg.org/planning/paris-2015?&#wednesday
# [12:29] <dael> fantasai: I think we wouldn't recompute so your page stay the same since you can do something like I remember seeing that three pages ago.
# [12:30] <dael> SteveZ: Some of the better scrollers for text don't jump whole pages, but give me the last few lines.
# [12:30] * Joins: tkonno (~chatzilla@public.cloak)
# [12:30] <dael> TabAtkins: That's basically example 2. So you collect a page of whole paragraphs and when you flick you go up and get the last apargraph you hadn't fully read yet.
# [12:30] <dael> TabAtkins: I would kill somebody to get this in my normal web reading experience.
# [12:30] <dael> dauwhe: You want pages :D
# [12:31] <dael> MaRakow: I had similar questions to Bert. What happens if you delete elements.
# [12:31] <dael> TabAtkins: If you change you should recompute.
# [12:31] <dael> fantasai: You don't based on scroll experience, but if the content changes.
# [12:31] <leaverou> minor: shouldn't the initial value of scroll-snap-area be margin-box? If there's spacing around the element, you'd probably want that spacing when you snap to it, in most cases, I imagine
# [12:31] <dael> MaRakow: So something like a twitter and I get rid of the stale tweets, do I get new pagination?
# [12:32] <dael> fantasai: That applies to both
# [12:32] <dael> MaRakow: The repeat is the first spec. the content moves and you don't. If the goal is nice pagination this is nice.
# [12:33] <dael> TabAtkins: 3rd option is you have a lot of images like pinterest. Theyre irregularly packed and you don't know what the size is going to be and they're going off the page. You flick, everything you haven't completely seen goes to the top of the page and it fills below.
# [12:33] <dael> Florian_: How does that behave if all the images are bigger than your page.
# [12:33] <dael> TabAtkins: Starting from the uncollected images...
# [12:34] <dael> fantasai: He's going a point. If you have a big giant image that's a screenand a half. You don't want the first group to be as tall as the image.
# [12:35] <dael> TabAtkins: [whiteboards] you have several small images in one column and one huge image in the other. How the big element behaves, I'm not sure.
# [12:35] <dael> Florian_: And what if they're all too big.
# [12:35] <dael> TabAtkins: Your group would be overly large.
# [12:35] <dael> Florian_: And then you get the behavior for when things are bigger. A prototype would be useful.
# [12:36] <dael> MaRakow: You'll start issues with 2d as well.
# [12:36] <dael> fantasai: We think you can group in either axis.
# [12:36] <dael> MaRakow: But you can't have a 2d group that looks like and area?
# [12:36] <dael> TabAtkins: The bounding box and the group is what you're defining.
# [12:36] <dael> MaRakow: A 2d scroller?
# [12:36] <dael> TabAtkins: You could, yeah.
# [12:37] <dael> MaRakow: You'll get more problems with that because the pages won't even be in a grid. If you can do both the first page will be wierd.
# [12:37] <dael> Bert: Grouping is overkill. I like snap points, but if you go too far in pagination, it's better off using real pagination. YOu can break the large box. The grouping is too complex, it doesn't give you want you really want to get.
# [12:38] <dael> Rossen: Real pagination isn't meant for this. You'll start hitting all the fragmentation rules which you don't want in presentaito media.
# [12:38] <dael> fantasai: You don't want to break into multiple pages.
# [12:38] <dael> fantasai: You want an image to be one continuous thing.
# [12:38] <dael> SteveZ: And you may want overlaps for a lot of your content. You're scrolling in sort of pages, not real pages.
# [12:38] <dael> TabAtkins: And you can use scroll snap margins on the pages.
# [12:39] <dael> TabAtkins: Group snapping, we think is useful, but they're not nec for level 1. The big use cases are from simple snapping.
# [12:39] <dael> TabAtkins: You can handle over large stuff. The big thing is renaming stuff. Do we want to do that now?
# [12:40] <dael> TabAtkins: scroll-snap-destination we can keep or change tto target. We'd like to add auto value that sets to center snapping. So destination. Keep or change?
# [12:40] <dael> Florian_: The alt?
# [12:40] <dael> TabAtkins: target
# [12:40] <dael> fantasai: unless you have another.
# [12:41] <dael> Florian_: I like target better, but it's not very important.
# [12:41] <dael> TabAtkins: Anybody feel strongly?
# [12:41] <dael> MaRakow: If target starts to feel like it has another meaning like event target.
# [12:41] <dael> hober: There is appeal in using something we're not using elsewhere. But I see the appeal of shorter.
# [12:42] <dael> TabAtkins: So the addition of the auto to destination. Right now if you want to center you have to say destination and coordinate center.
# [12:42] <dael> MaRakow: What element does it copy from?
# [12:42] <dael> TabAtkins: Whatever element it's snapping to
# [12:43] <dael> ojan: I haven't listened to all of this, but the destination vs target, I think we should minimize changes as much as we can because multi browsers are shipping.
# [12:43] <dael> TabAtkins: It's a matter of if people are okay with changing. It's okay to keep the names that are already here.
# [12:44] <dael> fantasai: smfr said they're under webkit prefix so okay to change. Roc wants something stable soon, at this f2f, but is okay changing. He thought the spec was stable because it wasn't changing, but that's not a good idea generally.
# [12:44] * heycam is now known as heycam|away
# [12:44] <dael> hober: Question about auto. Does it always mean the destination value comes from the coordinate value?
# [12:44] <dael> hober: Auto often means something idfficult to desc. You could use from coordinate.
# [12:45] <dael> fantasai: But auto can mean default. It can just mean do something I can't express explicityly.
# [12:45] <dael> Florian_: I'm not completely sure about auto. Depending on the size ofthe scroller you get different things.
# [12:46] <dael> Florian_: [whiteboards] if you're in manditory type of things you're past the middle of the second one.
# [12:46] <dael> TabAtkins: Don't mix edge and poitn alignments, it's weird.
# [12:46] <dael> fantasai: Or if you do, do it for a very good reason.
# [12:46] <dael> Florian_: So in this whiteboard it's the author being wrong.
# [12:47] <dael> TabAtkins: You can do a lot of dumb things with scroll snap if you're dumb
# [12:47] * liam likes "we try to constrain the impact of being dumb" but decides not to tweet it :)
# [12:47] <dael> Florian_: Depending on how tall your screen is you can end up with problems.
# [12:47] <dael> TabAtkins: Only if you have a small amount of information
# [12:47] <dael> TabAtkins: So destination stays named as-is
# [12:47] * dauwhe liam: all properties that accept an "auto" value should also accept a "footgun" value
# [12:47] <dael> TabAtkins: MaRakow on auto?
# [12:48] <dael> MaRakow: I was thinking what coord would make sense with auto. Top does...
# [12:48] <dael> fantasai: It works just like background position. 100% is the bottom, 0% is top and it's continuous.
# [12:48] <dael> MaRakow: So if you have a coord that's an offset of 20px and your offset 20px is that 40px?
# [12:48] * tantek dauwhe liam: gun-position: footer
# [12:49] <dael> fantasai: I think we may want to break and come up with a list of resolutions that we needf rom the WG. Let's get on the same page conceptually. Right now we're at a high level.
# [12:49] <dael> TabAtkins: We'll have auto on the table then.
# [12:49] * tantek notices https://en.wikipedia.org/wiki/SNAP_Points
# [12:49] <dael> fantasai: The critial is switching to this box model.
# [12:49] <dael> hober: Are you looking for a resolution today?
# [12:50] <dael> TabAtkins: In so far as if we're swtiching to this model we need to have a completed transition to this model in 2 weeks. Moz has shipped unprefixed. Which Roc had a lot of the concerns we had he shipped since he thought it was stable.
# [12:51] * Quits: tkonno (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [12:51] <dael> fantasai: If you're going to work on this, we've only shipped for a couple of months, then do it and do it quickly. smfr says Apple has it behind a prefix.
# [12:52] * tantek is shocked to not find a Wikipedia article on "toast points", but a few references: https://en.wikipedia.org/w/index.php?search=%22toast+points%22&title=Special%3ASearch&fulltext=Search
# [12:52] <dael> MaRakow: For the box thing, this ties into the other issue on the ML of 2d scrollers vs 1d nested scrollers and the ability to spec snap coord on a single axis and once you have enough lines you have a box. I think there might be some overlap there. I think the scenarios on the ML are compelling enough that we should explore that.
# [12:52] <dael> TabAtkins: So how do you want us to help you?
# [12:52] <dael> MaRakow: Let's start over lunch.
# [12:52] <dael> fantasai: Opinions from other members of the WG?
# [12:52] <dael> Florian_: I like the direction. I had the same concerns as Roc
# [12:53] <dael> Bert: One...maybe there was a note that the start keyword isn't writing mode dependant.
# [12:53] <dael> TabAtkins: It is.
# [12:53] <dael> TabAtkins: It's been on the scrollers writing mode. We do sometimes care about child vs parent.
# [12:53] <dael> fantasai: We need to clairy
# [12:54] <dael> fantasai: The model should be writing mode relative so if you say start edge in one axis that is the block axis, if you switch the vertical writing mode, the thing that was the blockshould translate to still be paragraph to paragraph.
# [12:54] <dael> Bert: It only depends on scroll x or y.
# [12:54] <dael> fantasai: Overflow x and y are physical, but we'll have logical equivellents. The scrolling behavior for snap points should be logical as well.
# [12:55] <dael> MaRakow: It's logical and physical similarly. There's lots of things where you have the photo where you'll go the same direction no matter the writing mode.
# [12:55] <dael> Bert: But you're missing keywords.
# [12:55] <dael> fantasai: We'll have to look at grammar, for sure.
# [12:55] <dael> Bert: But then you don't need them all
# [12:56] <dael> TabAtkins: You can still scrollin two directions.
# [12:56] <dael> Bert: If I have something scroll vertically, I set something as start it goes from the top.
# [12:56] <dael> TabAtkins: We fixed it a while ago. If you don't have to spec the axis you have start in both direction.
# [12:57] <dael> fantasai: If you want to snap in one dimention, not the other, you have to say start: none
# [12:57] <dael> Bert: But I don't want it to be start on the right side.
# [12:57] <dael> TabAtkins: Then say start: non
# [12:57] <dael> TabAtkins: Or don't make yourself scrollable in the axis and it won't matter.
# [12:57] <dael> s/non/none
# [12:57] <dael> Bert: This is getting confusing. Maybe we do need a left and right.
# [12:58] <dael> TabAtkins: Nothing you desc so far requires physical directions. If you just use start whatever direction are scrollable are snapable.
# [12:58] <dael> Florian_: What about bidi?
# [12:58] <dael> fantasai: Horizontal will changed based on bidi.
# [12:58] <dael> fantasai: You use the writing mode of the scroller.
# [12:58] <dael> Florian_: It might not be the start edge.
# [12:58] <dael> fantasai: Alignment prop work the same way.
# [12:59] <dael> fantasai: Any other comments on if this seems like a good direction. Should we work with MaRakow
# [12:59] <dael> hober: In general yes, it's just a lot to resolve on at once.
# [12:59] <dael> hober: I think continue working.
# [12:59] <dael> Bert: I'm not sure about grouping.
# [12:59] <dael> fantasai: I see dbaron and dauwhe and SteveZ nodding.
# [12:59] <dael> plinss: Does anyone think we should abandon this and ship what we got.
# [12:59] <dael> hober: If they continue working on this...
# [13:00] <dael> Florian_: This replaces the old model.
# [13:00] <dael> fantasai: Otherwise we can not do anything.
# [13:00] <dael> hober: So wholesale replacing is a bigger question.
# [13:00] <dael> TabAtkins: So it's relacing scroll-snap-coordinat with these two properties. align and area.
# [13:01] <dael> fantasai: I'm not sure you can get overly large elements to work correctly.
# [13:01] <dael> fantasai: If you have something aligned to the top, if you're aligned to a particular position. the overly large stuff kicks in if you can't see all of it. If you're top aligning you only want to snap to the top edge. Nevermind...
# [13:01] <dael> TabAtkins: I don't think edges are required if we're only doing overly large.
# [13:02] <dael> TabAtkins: Who doesn't want us to work on edge snapping over the next two weeks.
# [13:02] <dael> fantasai: We replace stuff or we do all these on level 2.
# [13:02] <dael> Florian_: +1 to replace.
# [13:02] <dael> MaRakow: We should discuss and see if there are options to do it.
# [13:02] * Quits: Florian_ (~Florian@public.cloak) (Client closed connection)
# [13:02] <dael> plinss: SO lets break for lunch, you guys sort out over lunch, and then we'll try and propose some resolutions after lunch to get this address. Okay?
# [13:03] <dael> TabAtkins: Yes.
# [13:03] * Joins: Florian (~Florian@public.cloak)
# [13:03] <dael> <break=lunch>
# [13:03] * Quits: hyojin (~hyojin@public.cloak) ("Page closed")
# [13:06] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:07] * Joins: Florian (~Florian@public.cloak)
# [13:07] * Quits: rachelandrew (~59cacb34@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [13:08] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [13:10] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [13:25] * Joins: tkonno (~chatzilla@public.cloak)
# [13:26] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [13:38] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [13:39] * Joins: ChrisL (clilley@public.cloak)
# [13:49] * Quits: BogdanBrinza (~bbrinza@public.cloak) ("")
# [13:55] * Joins: jdaggett (~jdaggett@public.cloak)
# [13:56] * Quits: ed_paris (~ed@public.cloak) ("Leaving")
# [13:56] * Joins: ed_paris (~ed@public.cloak)
# [14:00] * heycam|away is now known as heycam
# [14:01] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [14:01] * Joins: MaRakow (~MaRakow@public.cloak)
# [14:02] <ChrisL> http://dabblet.com/gist/a6c94860c2b689618680
# [14:03] * Joins: Florian (~Florian@public.cloak)
# [14:05] * Joins: Florian_ (~Florian@public.cloak)
# [14:07] <dael> plinss: Let's get started
# [14:08] <dael> plinss: Are we ready for scroll snap followup?
# [14:08] * astearns the gavel!
# [14:08] <dael> TabAtkins: We decided we need to talk about this more.
# [14:08] <dael> Topic: Pagination
# [14:08] * tantek "talk" : http://w3cmemes.tumblr.com/post/127627542697/the-jets-tab-atkins-has-a-counterproposal-for-the
# [14:09] <dael> dauwhe: [reads us all a wonderful story]
# [14:09] <dael> dauwhe: I'm going to talk about pagination and what we need to do.
# [14:10] * Joins: hyojin (~hyojin@public.cloak)
# [14:10] <dael> dauwhe: As we know there's lots of specs that touch on this and there have been various attempts to work on them
# [14:10] * Joins: johanneswilm (~johannes@public.cloak)
# [14:10] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [14:10] * Joins: ChrisLilley (clilley@public.cloak)
# [14:10] <dael> dauwhe: This is a major priority of the digital publishing community. We publish content and it's better in a paginated form.
# [14:11] <dael> dauwhe: We think this is a good thing for users and we'd like to reduce the dissidence between ebook and web reading. We'd like to have a spec so people can polyfill it.
# [14:12] <dael> dauwhe: What is the path forward, what do we need to work on, who is interested, how much of this is CSS and how much is Houdini, what do we need to do to keep this going forward and getting worked on? The whole digital community is interested.
# [14:12] <dael> astearns: One of your topics is what is CSS and what is houdini. There shouldn't be that much distinction
# [14:12] <dael> hober: houdini is a wholely owned subsidiary
# [14:12] <dauwhe> https://www.w3.org/dpub/IG/wiki/Pagination_Requirements
# [14:13] <leaverou> s/wholely/wholly/
# [14:13] <dael> astearns: The houdini part is the APIs that we need to provide for when a paginated view happens. When things get fragmented there need to be APIs for where your content went, how many pages you have. That's the only houdini part.
# [14:13] <dael> dauwhe: And dpub has written requirements docs fot those APIs
# [14:13] <dael> astearns: That's my take on it. Does anyone else have a different idea
# [14:14] * Joins: Florian (~Florian@public.cloak)
# [14:14] <dael> SteveZ: One of the major questions in pagination is templates and how do they get spec. Is it declaritive which is CSS or is it houdini?
# [14:14] <dael> SteveZ: There's an observation that runs through things where sometimes you don't know how to stanardize because you don't have enough experience. Houdini lets people experiment and that might be where we are with template.
# [14:15] <leaverou> since when is houdini only about JS?
# [14:15] <dael> SteveZ: Trying to do that piece declaritively seems to be a lot harder to do. The rule for picking which page template you use is hard in a decalrative PoV. That would be one example where I houdini interface gave you a set of content and you can explore that content and pick a page template.
# [14:16] <dael> dauwhe: One triggering pagination, do we all agree that's in that section of the overflow spec?
# [14:16] * Quits: Florian_ (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [14:16] <dael> ChrisL: Yeah, that seems right. Can you think of anywhere else?
# [14:16] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [14:16] <dael> astearns: named flows and regions can do the same thing with non-declaritive bits.
# [14:16] <dael> liam: Does it have to be non-declaritive?
# [14:16] <dael> astearns: The script you need to add or remove regions is the non-declaritive.
# [14:17] <dael> liam: Yes. I can imagine a world where one does not need JS for that.
# [14:17] <dael> liam: So the question isn't just what do we have, but where should we go.
# [14:17] <dael> ChrisLilley: I would clarify to say it's the primary place, but other things could trigger as well.
# [14:18] <dael> SteveZ: I'm not sure I subscribe to that in the sense that it seems to be pagination is something you do, not so much a result of overflow. That distinguishes the thing that begins and follows from I want to put this content into a set of pages. I don't have to overflow anything.
# [14:18] * hober waves to jdaggett
# [14:18] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [14:18] <dael> astearns: I can see the similarity between overflow paged and scroll. You're putting your content in a large virtual contained. In both cases you're auto-gen a place and providing some UI to get through the content.
# [14:19] <dael> SteveZ: Destinction is in scrolling you have one template that you're extending. IN pagination you have many templates. The other piece of pagination is the breaking issue and deviding it into pages.
# [14:20] <dael> Florian: Since I because a co-editor of overflow to work on things related to this, i think this is something to look into. Sometimes you want multiple flows going into a page. There can be an existance of a page more than the amount of content that's overflowing it.
# [14:20] <SimonSapin> jdaggett, how is the audio?
# [14:20] <jdaggett> SimonSapin: audio is good
# [14:21] <dael> johanneswilm: So you provide some JS foundations and you hope someone will try and make examples and you build the spec based off of those experiences? There's not that many, there was one impl in 2012 and that was me. There is now viviostyle. Is that all?
# [14:21] <jdaggett> SimonSapin: but szilles talks too quietly!!!
# [14:21] <dael> astearns: FT has their own. NYT used to use one.
# [14:21] <dael> johanneswilm: Are we getting the feedback back?
# [14:21] <dael> dauwhe: Also all the ebook reading systems. iBooks. I get the sense these aren't the most elegent constructs.
# [14:21] <dael> astearns: When we were creating regions I was soliciting feedback.
# [14:22] <dael> dauwhe: And we have formaters that say if there's an @page rule that triggers the pagination.
# [14:23] <dael> Bert: I thinkt he overflow is a secondary way of getting pagination. The primary is based on the templates like SteveZ said. The last template might be scrolling. The primary region for pagination is do I have another region to go into and in the last one you might want a scroll bar.
# [14:23] <dael> Florian: That's what the overflow is doing. It's triggered by overflowing. Do I want more pages or do I want to scroll once I reach this one. Once you have these pages and going ahead and creating additional containers is the point. That doesn't general the page.
# [14:23] * astearns sees that John can see himself looming over the tables here
# [14:24] <dael> SteveZ: A key distinction is the page is a container sep from the content. The template says what the container should look like. There is a pouring notion. The way we've done multi-col is you can take an element and turn it into multiple columns, but that takes away from you the ability to have the first page be one column.
# [14:24] <Bert> s/primary region/primary reason/
# [14:25] * jdaggett is enjoying being larger than life...
# [14:25] <dael> Florian: With pagination you could do this. The first element/page/thing gets filled, content overflows, you select the second with a pseudo, and that one you apply hte multi-col. What it doesn't do is if you have two flows, one engligh one chinese and they're supposed to run paralell
# [14:25] <dael> dauwhe: Or it's a signal we don't have the conceptual model.
# [14:26] <dael> SteveZ: Another issue is the page floats. for high quality output you want to order them. You have two page wide floats and two half page floats, you want to stick those two half page floats next to each other and that's not easy to do in a specified way. I don't think we have the ability to deal with that.
# [14:27] <dael> Florian: I think that's a problem, but a different problem. We have a certain set of page floats, but if it's not layout smart enough you can go over it in Java.
# [14:27] <dael> dauwhe: And to have that impl experience, it would be nice to have content.
# [14:28] <dael> liam: Sometimes you hvae to be careful to look at the complex and the simple. SteveZ I sent a mail to the list with examples of page floats including the exact example you mentioned. But that's not specific to pagination. THat happens in floats.
# [14:28] <dael> liam: There's motivations to fix that beyond pagination, I think it's sep.
# [14:29] <dael> dbaron: Slightly different issue, a lot of CSS is very clear about how UA and user and author pref interact. once of the problems with things like @page is that become less clear. It's clear how @page is intended if you're using CSS asa typesetting. You and the publisher and the printed and you know all the sizes. It's less clear when you have a dev and you have someone on the other side of the worl.
# [14:30] <dael> liam: ChrisLilley asked why this doesn't exist for screens. One issue is @page you hard wire the page size and you don't really know it.
# [14:30] <dael> fantasai: You just say @page size auto and it works.
# [14:30] <dael> liam: It's been in the spec, the impl have improved. The other thing that mitigates it is the calc function. Even if you say page size auto you have a problem.
# [14:30] <dael> fantasai: We have margin prop
# [14:31] <dael> liam: I'm oversimplifying, but the things calc was intro for are thing in printing.
# [14:31] <dael> dauwhe: I'd see huge problems if we have this in the browser and I could set margin boxes with something flexible enough that it would work in different screen sizes.
# [14:31] * MaRakow player 2 has entered the game
# [14:31] <jdaggett> somebody mute!!!
# [14:32] <dael> johanneswilm: If you want to make it really great it will take a lot of time to render. I don't think browsers will render that. If there's an expectations browsers will want to put it in this needs to be considered, but if it's not sufficently complex we won't have good books.
# [14:32] <dael> dauwhe: What's the next step we can do. It seems like there's not consensus on overflow triggering pagination
# [14:32] <jdaggett> SimonSapin: can we mute whoever just joined? lots of noise...
# [14:33] <dael> fantasai: We've got paged media spec, it exists for all its faults. We got the fragmentation stuff. We have overflow:page from opera which at a basic level is straight forward. You will want thing to style.
# [14:33] <dael> astearns: Before that we need an API.
# [14:33] <dael> fantasai: That's a paralel.
# [14:33] <dael> plinss: We need a model for what boxes will be built before the API.
# [14:34] <dael> Florian: And if regular pagination is explained by fragmentation.
# [14:34] <dael> fantasai: The way I see it is that when you're in a paged media mode you're generating pages. yOu page rather than scroll and you're generating paged boxes, as many as nec. Rather than switch pages you pick the next paper.
# [14:35] <dael> Florian: Than how do you explain it for pages generated by not overflowing the root. Like the crop marks and blled area when they're in the middle.
# [14:35] <dael> fantasai: I imagine overflow: page being a stack of boxes. We prob want a different mech for asigning styles to that. We need a different element to be the paginator.
# [14:35] <SimonSapin> Whoever joined from a cell phone, you’re muted on this side. Let me know if you want to speak.
# [14:35] <dael> Florian: The first part I agree.
# [14:36] <dael> fantasai: If it's a stack of boxes it's a scroller and if the bleed marks are outside that you don't see them unless we add a prop later.
# [14:36] <dael> johanneswilm: Isn't this the diff between having all the content to how many pages you need or the one where you have a page, put your content, and add another page and put your content. They're slightly different models.
# [14:37] <dael> fantasai: The model we're going with so far is you generated as many page boxes as nec.
# [14:37] <dael> dauwhe: Even for page loyout programs, I don't see having CSS do something where you hide your content by default.
# [14:38] <dael> fantasai: If you really want to do that, there's a way, but it shouldn't be the default model. It shouldn't be the default for overflow page.
# [14:38] <fantasai> s/there's a way/I make a div and give it 500% height, which makes it 5 pages tall, and give it overflow hidden so that's all I get/
# [14:38] <dael> dauwhe: How much needs to be done to get this box model? WE kind of have it in the intro to CSS display. I hear from dpub is the box tre 6 months or 6 years?
# [14:38] <dael> plinss: It has to fall out from the working group to houdini.
# [14:39] <dael> Florian: If this is a long topic, we need to make time for it. It's not going to run itself. I think there's consensus we need progress, but we've had difficulties setting aside enough time.
# [14:39] <dael> astearns: And we've had difficulties getting browsers to express impl interest. We've had overflow draft for a while. If that's the mech we should have more interest.
# [14:40] <dael> Florian: I'm partly guilty because what's in overflow isn't sufficently spec yet.
# [14:40] <dael> astearns: I don't think the main problem is time for theorizing and spec. I think it is lack of interest in spendingtime on impl even though we've known pagination is something CSS should get to. Even though dpub is breathing down our neck for it.
# [14:41] <dael> Florian: I think it's both becuase...the problem you desc is real, but smaller groups of JS and polyfillers that want to experiment don't quite have enough.
# [14:41] <dael> plinss: Anything polyfills has been DOM hacks, not layout.
# [14:41] <dael> tantek: Whatabout howcome prototypes?
# [14:42] <dael> jdaggett: I'm sort of hearing this and seeing sim things in the next doc. I don't see if there's a place in the room to talk priorities of impl, we have to focus on priorities of specs and not getting tangled in the prioritization for individual browsers.
# [14:42] <dael> dauwhe: I'll have more comment when we're on the priorities doc
# [14:43] <dael> Florian: What's the point of if browsers won't do it, they're not the only CSS consumers. If we spend a reasonable time and flesh out the model it would be good.
# [14:43] <dael> ojan: Calling an ereader a browser is fine.
# [14:43] <dael> Florian: Desktop browsers haven't shown much interest, but there are ebook readers that are interested.
# [14:43] <dael> dauwhe: Pagination with CSS is prob a billion dollar industry. They're stuck doing this in non-standard.
# [14:44] <dauwhe> https://lists.w3.org/Archives/Public/www-style/2015Aug/0179.html
# [14:44] <dael> plinss: I'd like to see the ability for the user to opt-in to pagination. Either I'm scrolling or I want to be in ebook mode.
# [14:44] <dauwhe> sorry, wrong link; should be http://www.clickhole.com/blogpost/time-i-spent-commercial-whaling-ship-totally-chang-768
# [14:44] <dael> plinss: We need to make sure the model is set up. Sometimes the author only want paginated, but it should be the also the flip side.
# [14:45] <dael> plinss: It would be nice if the user could select that mode.
# [14:45] * Quits: gregwhitworth (~gregwhitworth@public.cloak) (Ping timeout: 180 seconds)
# [14:45] <dael> plinss: Some browsrs are having reader mode.
# [14:45] <dael> SteveZ: Does that say overflow page is not the right way to go?
# [14:45] <dael> plinss: It's a way to go.
# [14:45] <dael> Florian: It can do both, but I don't know if it's the best way.
# [14:45] <dael> SteveZ: Overflow: page seems like a deadend route. It doesn't seem the obvious way for what plinss
# [14:46] <dael> hober: It is. It's the equivellent. It doesn't do everything, it's a long way though.
# [14:46] <dael> SteveZ: But I'm concerned about getting the whole way
# [14:46] <dael> hober: Let's get somewhere.
# [14:46] <dael> SteveZ: You can get somewhere but you can't get the rest.
# [14:47] <dael> liam: When howcome showed his footnote draft the problem was you can't extend to multiple levels of footnote which is common. That kind of review requires looking at the more complex picture.
# [14:47] <dael> fantasai: What are we trying to solve with overflow:page that we can't
# [14:47] <dael> SteveZ: Multiple inputs.
# [14:47] <dael> dauwhe: I think we could extend overflow with giving a name to a slot.
# [14:48] <dael> plinss: I think that's a bit of a red herring. There's always been a missing component. There's the box tree and outside that is the viewport. The route mapping has always been this fuzzy area. We've never defined that space, especially when there's krimping the viewport starts acting really strange. We don't have a coherent model and we need to define that.
# [14:49] <dael> plinss: Once we have that pagination overflow may make perfect sense living in that gray space. They'll be in a coherent interop manner.
# [14:49] <dael> dauwhe: I agree 100% as I was reading through spec trying to find the def of canvas and viewport and it's not there.
# [14:49] <dael> dauwhe: What is the relationship between canvas containing block, viewport etc.
# [14:49] <dael> plinss: And I'll bet every impl is different.
# [14:50] <dael> Florian: Back to the problem with example of two par. content, we haven't solved it in non-paginated either. Once we have a way to do that, then we can pour that in. We don't have a model, but once we do it may work. We don't have that piece.
# [14:51] <dael> dauwhe: What plinss said I saw the models of scrolling and pagination as different parts of the same.
# [14:51] * Joins: plh (plehegar@public.cloak)
# [14:51] <dael> Rossen: There's two repeated concepts. One is being able to fragment content through multiples of fragmente containers.
# [14:51] <dael> Rossen: We've convinced outsives there's multi was to do this
# [14:53] <dael> Rossen: We're also trying to define an application model to which browsers may have to adhere. It's this paginated view. I want to flip or whatever. It's a lot hard to expect when can set the same requirements for the browser. This is going back to the times astearns and I were fighting for regions, it's give enough primitives in the platform, so that if people want to do paginated...
# [14:53] <dael> Rossen: It's not my job as an impl to do it, I'm giving you all the tools.
# [14:53] <dael> Rossen: We're going a step further with houdini, we're saying we want to pull out even more. We are giving you the box tree and all that and you can solve it.
# [14:54] <dael> Rossen: I think the distinction needs to be made that we can trigger fragmentation in multiple ways. Not nec. the browser level.
# [14:54] <dael> Rossen: The print preview, that's what we do. the huge amount of JS to impl this is really 3 lines to see if there's overflow and if we want to go to that next page.
# [14:54] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [14:55] <dael> Rossen: Going back to how do we trigger pagination, my reservation here is when you say pagination you're saying I want to put the browser into some app mode that the browser isn't built to be.
# [14:56] <dael> johanneswilm: I think I agree with a lot of that. If I want to read NYT in a paginated form I assume they will have a paginated form. I don't see the advantage of the browser doing that. The JS polyfills may be the end product. It still should be spec'ed. That's why i was asking, are we the only ones trying or are there other JS apps out there that are trying to consume content.
# [14:56] <dael> johanneswilm: We're a small start up, but you said it was a billion dollar industry so I'm sure someone is interested.
# [14:57] <dael> plinss: If the NYT want to give someone paginated on their site, they can build something. The problem is that is then completely disconnected between what's going on on the viewport and canvas, if I hit print I'm only going to get one page. I can't take their app experience and express that in a paginated viewport. I've built two things and there's no mapping in between them.
# [14:58] <dael> plinss: I'd like to give them something to build that can map between them.
# [14:58] <dael> johanneswilm: There are ways to get around that.
# [14:58] <fantasai> s/build something/build a paginated view, and then inside that have a little paginated box that users can flip through. But then when I print that, I only get one page./
# [14:58] <fantasai> plinss++
# [14:58] <dael> plinss: Sure. But I don't want them to have to design for that. There are UA that will go in the viewport. They've disconnected their paging experience from the ebooks. I'd like a coherent model.
# [14:59] <dael> SteveZ: When dauwhe brought this up he wanted to know what terms he can use in pagination. I jsut heard Rossen say fragments, plinss say regions. If the regions are chaned is sep, but the concept of a container that has things poured in is there. What pieces go in what direction. Also what the container can do to how the content is presented.
# [15:00] <dael> SteveZ: We're at a point that fragemnets and regions are basic building blocks.
# [15:00] <dael> SteveZ: Is that a consitant enough model or what more do you want.
# [15:01] <jdaggett> um, are we reaching anything concrete here...?
# [15:01] <dael> plinss: The regions are giving us the tools, but we don't have the overall explination of the model. Once we have that I want it expressed in all these tools. I want to be using the same CSS tools everywhere. I want to give the author the ability to play outside the doc and the viewport. If that's through declaritive CSS or whathaveyou, I want it to be there.
# [15:01] <jdaggett> this sounds like a good dinner conversation...
# [15:01] <dael> Florian: Isn't that tired to using the fragmenation overflow to what is out there?
# [15:01] <jdaggett> red wine for enhancement...
# [15:01] <dael> plinss: It's not chaning the root box mapped to the dom, it's the viewport out there.
# [15:01] <dael> plinss: @page is trying to desc something in that region that's not defined.
# [15:02] <dael> Rossen: I can't only speak for our impl, but internally the thing between the viewport and the document or whatever is there, we also always have a root element that's private to the platform. It's a div with a style and it is extremely easy because in our case it's a div with an overflow and a scrollpage.
# [15:02] <dael> Rossen: If you want pagination we can make multi box.
# [15:03] <dael> plinss: Are you making new divs
# [15:03] <dael> Rossen: New roots....no
# [15:03] <dael> Florian: In that model it's coherent that rather than having that on the route you do pagination and overflow.
# [15:03] <dael> Rossen: We re-use our regions impl.
# [15:04] <dael> plinss: It sounds like you're doing what I have in mine for specing. That you're doing it with a div instead of box is impl detail. I want to spec that and give the author the ability to apply styles.
# [15:04] <dael> Rossen: We are giving them that ability by prop BG color.
# [15:04] <dael> Florian: Explaining the model so that we know the reaon @page works is it's applying to that thing. That makes sense to me overall. The details need writing.
# [15:04] <dael> astearns: Who will write them.
# [15:05] <dael> Florian: That's what I signed up for by accident.
# [15:05] <dael> SteveZ: Is writing that the first step?
# [15:05] <dael> plinss: Sounds like.
# [15:05] <dael> plinss: Is this a new spec or an outgrowth of an existing one.
# [15:05] <dael> SteveZ: It's easier to do sep.
# [15:05] <dael> dauwhe: Sounds like intro to CSS display.
# [15:05] <dael> SteveZ: I don't think it is.
# [15:06] <dael> SteveZ: It's kind of hidden a bit in 2.1 but we've never extracted that piece.
# [15:06] <dael> Florian: and @page is kind of dealing with it.
# [15:06] <dael> plinss: I think we can make it a new doc
# [15:06] <dael> dauwhe: This is starting the make sense. Is this where we talk about viewport.
# [15:07] * liam asked dave et al to go back to talking to the room
# [15:07] <dael> dauwhe: This doc could maybe talk about the parts of 2.1 that mention viewport and canvas and would include whatever is hosting the elment.
# [15:07] <dael> astearns: It looks like there's 2 sentences in 2.1
# [15:07] <dael> dauwhe: Yes.
# [15:07] <dael> Florian: And a bunch of things trying to hook into it.
# [15:07] <dael> plinss: Do people agree this is a new spec?
# [15:07] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [15:08] <dael> Rossen: Can we start it as an existing and fork if needed? It sounds like display module is a good start for this work.
# [15:08] <dael> plinss: I don't know if what exists there now makes sense.
# [15:08] <dael> Florian: If that thing explanes pagination, how do we tie it with overflow that is also explaining pagination
# [15:08] <dael> SteveZ: When we have a model it should be clear how to answer that.
# [15:08] <dael> Florian: I'm trying to figure out dependancy.
# [15:08] <dael> hober: That needs to be written down.
# [15:09] <dael> dauwhe: I think we're looking for something that will be the parent of overflow and @page.
# [15:09] <dael> dauwhe: I think hopefully if we start down this path it will provide a way to say how we talk about this unicorn.
# [15:10] <dael> Florian: Either this unicorn object is a fundimental and it has a bunch or content or what fantasai said earlier that pagination on overflow explained how that thing worked. Which explains the other.
# [15:10] <dael> SteveZ: My model which I may be wrong is this model desc how it gets to an extenal place.
# [15:10] <dael> flackr: Okay, and overflow hooks into that to explain how to overflow.
# [15:10] <dael> SteveZ: It tells you what you can find out about the external structure.
# [15:11] <dael> Bert: In the model I have is close to SteveZ. I think there are things like regions that are independant of elements. Those regions have their own prop and define how things overflow and pagination. @page is a kind of region. All of those are this external structure. And they have their own prop including content and overflow.
# [15:12] * astearns ur-box
# [15:12] <dael> plinss: So do we have agreement to start a new doc?
# [15:12] <dael> Florian: I think we do, but who is going to write?
# [15:12] <dael> plinss: I'm willing to edit.
# [15:12] <dael> Florian: I'm interested, but don't know if I have the resources.
# [15:12] <dael> dauwhe: Interest without knowledge
# [15:12] <dael> Rossen: I can contribute.
# [15:12] <dael> SteveZ: I'm happy to read.
# [15:13] * dauwhe astearns: LOL
# [15:13] <dael> Florian: This needs to be tied into the devide adaptation doc. I spent a bunch of time review that with ppk and he pointed out the same problem.
# [15:14] <dael> Rossen: I think we'll end up splitting it into different specs and tying in the termonology.
# [15:14] <dael> dbaron: It's a bit disterbing to have the viewport spec and a viewport def elsewhere.
# [15:14] <dael> hober: Why don't we defer the name to the editors?
# [15:15] <dael> RESOLVED: Create a new module describing connection between viewport and doc tree and explaining page boxes with name TBA- plinss Florian Rossen as editors.
# [15:15] <dael> plinss: Is that a close on pages?
# [15:15] <dael> dauwhe: Yes, that feels like progress.
# [15:16] <dael> <break=15min>
# [15:17] * liam notes, no microphone on this side of the room
# [15:19] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [15:22] * Rossen is now known as Rossen_away
# [15:32] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [15:36] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [15:42] * Quits: ChrisLilley (clilley@public.cloak) (Ping timeout: 180 seconds)
# [15:44] * jdaggett break time, good for enjoying w3c memes...
# [15:44] <jdaggett> http://w3cmemes.tumblr.com/post/126038434512/what-its-saturday-maybe-where-you-are-buddy
# [15:49] * Joins: johanneswilm (~johannes@public.cloak)
# [15:49] * Joins: ChrisL (clilley@public.cloak)
# [15:53] <fantasai> hm, that was a long 15min
# [15:53] <dauwhe> http://epubzero.blogspot.fr/2015/08/the-genesis-of-pagination.html
# [15:54] <hober> fantasai: it was 15 css minutes, which are not 1:1 with SI minutes
# [15:55] * hober sorry, should have emoted that
# [15:55] <dael> Topic: CSS priorities from digipub
# [15:56] <plinss> http://www.w3.org/TR/2015/WD-dpub-css-priorities-20150820/
# [15:56] * Joins: gregwhitworth (~gregwhitworth@public.cloak)
# [15:56] <dael> Bert: The dpub IG started this doc with important things for the pub indutry that have a relation to CSS. At the same time this is only a first WD so it's not the last word, nor does everything in the def have to do with CSS. It would be good for us to see through the list and see if they have the right model in mind.
# [15:57] <dauwhe> Prefer the editor's draft, which is already updated: http://w3c.github.io/dpub-pagination/priorities.html
# [15:57] <dael> Bert: I hope this is the first round of the conversation that leads to a decision of what we should do. There's three tables in the spec, so it would be easiest to go through them and make a comment on it.
# [15:57] <dael> Bert: You dauwhe are the editor.
# [15:58] <dael> dauwhe: Thank you for putting this on the agenda. I think the dpub IG is chartered to provide a forum to discuss the requirements of dpub.
# [15:58] * jdaggett perfect!
# [15:58] <dael> dauwhe: And possibly to communicate with other WG if the open web platform isn't meeting some of our needs.
# [15:59] * Rossen_away is now known as Rossen
# [15:59] <dael> dauwhe: This doc is an early draft. a list of what are we missing in our day to day work. If we could change something to allow us to pub more and better, what would it be.
# [15:59] * Quits: tkonno (~chatzilla@public.cloak) ("ChatZilla 0.9.92 [Firefox 40.0.2/20150812163655]")
# [16:00] <dael> dauwhe: The list is 3 categories. The first is features that are well spec, mature, and impl in most broswers, but not everywhere which prevents us from using it. Fill in these pieces and our life is better. It's not the responsibility of the WG to force impl, but the impl are in the group so we thought a polite reminder would be good for this forum.
# [16:00] <dael> dauwhe: Next category is things where the spec seems mature but it's not widely impl yet. Third is things where there needs to be fundimental design decisions.
# [16:01] <dael> jdaggett: Looking at some of the things in 2.1, I'm sort of wondering where there are coming from. Are we going down the list, are you giving an intro or?
# [16:02] <dael> dauwhe: I don't have a method. Bert wanted to go through the list to see if these things are in scope and if the WG can do these things. Some of 2.1 the WG can't do anything. One of the functions of this doc is to say we find these things important.
# [16:02] <dael> jdaggett: OpenType Math Tables seems over the moon.
# [16:02] <dael> dauwhe: We have an interesting process. This comes from Peter Krauzberger and he's looking for anything that can help him.
# [16:02] <dael> astearns: It's not just Peter. He's a spokesperson for all the pub that want to product good math types.
# [16:03] <dael> jdaggett: That's a low level feature. I think you want to be more specific instead of just create a laundry list.
# [16:03] <dael> ChrisL: I agree with about that. All the other are CSS, this one is a little known feature.
# [16:03] <dael> dauwhe: That's valid and useful feedback I can take to dpub. Perhaps find another context or flush it out.
# [16:04] <dael> jdaggett: One other comment, font feature settings is listed and I think it should be font varient. It's already impl in FF and the Safari is underway as we speak.
# [16:04] <dael> ChrisL: But those are two different things.
# [16:04] <dael> ChrisL: I understand you're making the point that people should use font varient, but these are orthogonal. I don't see they should remove it.
# [16:05] <dael> jdaggett: If they're going to impl, the should emphazize font varient instead of font feature settings because if you have font varient the need for font feature settings go away.
# [16:05] <ChrisL> s/little known feature/low-level feature/
# [16:05] <dael> dauwhe: This seemed like the smallest step that would give us power.
# [16:06] <dael> Florian: So that entry could read as if you can get us just that we can survive, even if getting the other thing would remove most of the need.
# [16:06] <dael> dauwhe: We're starving and will take crumbs.
# [16:06] <dael> fantasai: You don't want people to use font feature settings. It's not a good interface and we would much rather people advocated for font varient.
# [16:06] <ChrisL> well, not go away, but be much reduced for common cases. Its not clear whether they were concerned with the common cases or the edge cases when adding this to their document
# [16:06] <dael> dauwhe: That's useful information for us.
# [16:07] <leaverou> s/font varient/font-variant/g
# [16:07] <fantasai> font-feature-settings has bad cascading behavior, uses font-specific syntax (is not cross-platform or cross-font).
# [16:07] <dael> Florian: There's hyphens in your list with high priority. On the call not too long ago we were talking about features around hyphen. I was wondering if that discussion is to be read in a new light in view of this proposal.
# [16:07] <dael> dauwhe: Having the ability to allow text to hyphenate at all is this. The conversation was to detect if it hyphenated and make design choices.
# [16:08] * astearns howls into the void for ubiquitous hyphenation
# [16:08] <dael> Florian: Yes. Givin that no browser will support every language knowing if they hyphenate is good.
# [16:08] <dael> dauwhe: Our needs are more modest. most of us only pub in one or two languages. Just having the raw prop itself would be a big step forward for the status quo
# [16:09] <dael> fantasai: Particular localizations will have the dictionary. If the browser doesn't ship with all the languages it will probably suppor tit.
# [16:09] <dael> dauwhe: Or prospective isn't similar in that we don't worry about the edge cases much.
# [16:09] <dael> Florian: Or the author and user and UA being independant.
# [16:09] <dael> dauwhe: Correct.
# [16:09] <fantasai> s/suppor tit/support it in the localizations of that region, if the dictionary is at all available to them/
# [16:10] * fantasai TabAtkins, can I action you to pester that guy who was unhappy with all the hyphenation properties to send email expressing his unhappiness?
# [16:10] <dael> astearns: Did you want to go further down the list or open for questions?
# [16:10] <dael> dauwhe: I'm fine for general questions unless Bert did you want to go through the list?
# [16:10] * TabAtkins Yeah, I just need to find who it was.
# [16:11] * TabAtkins Maybe it was Emil?
# [16:11] <dael> Bert: My initial idea was go top to bottom, but many of them are related. So maybe, I don't know.
# [16:11] <fantasai> ACTION TabAtkins Find unhappy dude at Google who dislikes hyphenation properties and have him send email explaining his unhappiness to www-style
# [16:11] * trackbot is creating a new ACTION.
# [16:11] <trackbot> Created ACTION-715 - Find unhappy dude at google who dislikes hyphenation properties and have him send email explaining his unhappiness to www-style [on Tab Atkins Jr. - due 2015-09-02].
# [16:11] * fantasai no idea, doesn't remember the name
# [16:11] <dael> Bert: Some of these are specific and some are generic so it could be better distinguished.
# [16:11] <dael> Bert: The third table is what I find most interesting.
# [16:11] <dael> Florian: On the second table, content property on elements, what's our stance?
# [16:12] <dael> tantek: It exists?
# [16:12] <dael> Bert: We have an old spec and I want to revive it.
# [16:12] <dael> Florian: Is it web compat?
# [16:12] <dael> Bert: Why not?
# [16:12] <dael> Florian: It's all over the place with people applying it and does nothing. We'll have paragraphs replaced by dots by people who didn't do cleanup.
# [16:12] <dael> gregwhitworth: I thought this was possible.
# [16:13] <leaverou> re:hyphenation properties, I don't see anything about maximum length of whitespace. We had huge issues with that and Antennahouse, I thought something was planned?
# [16:13] <dael> dauwhe: It's contentious for a11y. My feelings on this are changing quickly. I got used to it because it's supported in Prince and its been kicking around the web for a while. Some of my use cases involve not having a content property. I'm agnostic about this.
# [16:13] * Joins: bkardell_ (~uid10373@public.cloak)
# [16:14] <dael> Florian: My imporession is that in addition to this it's also not web compat. So should we decide that a11y concerns aren't that bad on this feature, can we do this without breaking the web?
# [16:14] <Florian> s/cleanup/clear fix correctly/
# [16:14] <dael> liam: They're two sep. questions. The a11y we have content and pseudo elements. It's a problem, but not a new problem. Then the question is there legacy code in style sheets that would start working and therefore break.
# [16:15] <dael> Florian: My impression is there was so much it would break.
# [16:15] <dael> astearns: There are ways working around it.
# [16:15] <dael> liam: how do we find out.
# [16:15] <dael> zcorpan: I recall that we tried and had to take it out. I'll look it up.
# [16:15] <dael> gregwhitworth: I have bugs on this and I thought Chrome did this. FF is inserting the sum of them. Let me try and through one up.
# [16:16] <dael> Bert: Most of the cases where content prop would be used is things like margin boxes and regions, but it would be useful to be completely generic.
# [16:16] <dael> Florian: I think that's why opera added and it broke.
# [16:16] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [16:16] <dael> SteveZ: So if we do define content to container map and we allow it to be defined, you could get the same functionality.
# [16:17] <dael> Bert: It still requires the content prop to get defined.
# [16:17] <dael> SteveZ: The container is not an element.
# [16:17] <dael> dauwhe: We're planning to do work on generated content spec. fantasai and I were supposed to work on it and ran out of time. We started the long process of cleaning.
# [16:17] <dael> Florian: The feedback could b that content prop is unlikely to be applied to elements as-is.
# [16:18] <dael> fantasai: For the a11y issue we could have slightly different syntax when applying to an element. THe stuff causing a problem wouldn't be valid on elements. We could do that with a keyword or required fallback. We have options.
# [16:18] <dael> Florian: But just waiting for this won't happen.
# [16:18] <dael> gregwhitworth: So Chrome did this in 2012. They've since changed.
# [16:19] <dael> esprehn: Can you explain the container you're talking about? I'm not sure I follow what you want to add content to.
# [16:19] <gregwhitworth> So in 2011: Opera, FF passed this test IE/Chrome did not: http://jsbin.com/wefocufige/edit?html,css,output
# [16:19] * Joins: dholbert (~dholbert@public.cloak)
# [16:19] <dael> dauwhe: It the doc we have essentially bok content, where we may want to replace the content, say we tagged a chapter number, we may want to replace what was in the manuscript with a counter. We may want to change the structure there to do all kinds of designs. We sometimes replce the content of semi-decorative elements with single characters.
# [16:20] <dael> dauwhe: We're making design changes, but we need to apply some specific font or character to an element. dpub can work on more use cases given what we need.
# [16:20] <dael> esprehn: Shadow DOM supports replacing visual content and we've been adovcating for that to replace content. We've got questions about multiple levels of outer and inner and that should be the dom
# [16:21] <dael> Bert: But that's not tied to the stylesheet. I can only have on DOM even if I have multiple stylesheets. My user stylesheet can override the content prop.
# [16:21] <dael> esprehn: I question replacing sections of the page witht he stylesheet.
# [16:22] <dael> Bert: The example is there's a chapter number and I want to replace it with some image. I say okay, replace it by the counter that is defined in the stylesheet. If I have to use some HTML fragement, where is that define. It's not in the stylesheet.
# [16:22] <dael> Florian: Shouldn't this be solved by the transformation lang from glazou.
# [16:22] <dael> TabAtkins: Or JS.
# [16:22] <dael> Florian: It's not very declaritive.
# [16:23] <dael> dauwhe: It sounds like where I should go and work on use cases with dpub.
# [16:23] <dael> esprehn: That would be great.
# [16:23] <dael> jdaggett: Mathematical layout is difficult. It would be good to pull that out and get at what you really want to try and achieve.
# [16:23] <dael> dauwhe: I think even since we've been working over the last few weeks there have been intense discussions about the future of math on the web platform. We're trying to figure out what's the best way forward.
# [16:24] * fantasai wonders idly if we should define 'break-before: always' to mean "give me a column or page break, whichever is available, but don't break the region"
# [16:24] * fantasai suspects this would be somewhat useful
# [16:24] * tantek misread fantasai's text as 'break-down: always'
# [16:24] <dael> jdaggett: When you're doing math layout you're doing per glyph layouts and you would have to really go whole hog to achieve something that would be sane for any normal person to use.
# [16:24] <dael> esprehn: On Chrome we support addint the primitives so you can add it yourself.
# [16:25] <dael> jdaggett: In practice this is one area where you will spend many years trying to accomplish it.
# [16:25] <dael> astearns: So we'll start.
# [16:25] <dael> jdaggett: Keep in mind that ?? recently pushed his shaping engine to 1.0 and he started it 10 years ago.
# [16:25] <jdaggett> s/??/behdad/
# [16:26] <dael> dauwhe: Moving on to the third category, we put pagination here but we've talked about that today. A lot of the things here are related to hyphenation. There's the font metrics API thing that will be useful for various reasons.
# [16:27] <dael> Bert: In the case of hyphenation and line lengths, they're presented as independant prop. I'd like to see something where these and some others are tied together so I don't have to say I want three letters before the hyphen and I can be more subtile where try to make this last line 75% long or try and do something better if that doesn't work.
# [16:27] <dael> dauwhe: I've been on the losing end of that a few times.
# [16:28] <dael> liam: There's a couple of difficulties. Politically there are org that have style rules that are reflected in properties like this and if you have an automatic thing it's hard. The design things have dials that let you fill in these things for those reasons. Because a design agency has a specification and it's hard to automate something that works well.
# [16:28] <dael> liam: Tech does a bad job. It does an error message if you do something bad and the assumption is there's an author to fix it.
# [16:28] <dael> Bert: It gives errors when it can't resolve, but it has an alog before.
# [16:29] <jdaggett> s/Tech/TeX/
# [16:29] <dael> liam: But it has very bad worst cases. Maybe it's not as optimal as TeX, but it's necessary.
# [16:29] <dael> Bert: And you say the programs are made that way because the style guides. It's a chicken and egg thing.
# [16:29] <dael> dauwhe: Much of our progress comes from waiting on the old guard who insists on these things to retire.
# [16:30] <dael> tantek: Do you have a screenshot of the error messages?
# [16:30] <dael> dbaron: Find a file for an achedemic file in TeX and you'll find a lot of them.
# [16:30] <leaverou> s/achedemic/academic/
# [16:30] <dael> liam: I've seen it have two words in an entire line because that works out less bad.
# [16:31] <dael> dauwhe: Any other comments on this before we move on? I know there's a lot of work to do.
# [16:31] <dael> dbaron: There's a lot of material in the pagination section.
# [16:31] <dael> dauwhe: Yes there is.
# [16:31] * Ms2ger wonders how widely supported MathML is nowadays
# [16:31] <dael> tantek: It's a good summary. Each line is deep.
# [16:32] <leaverou> Ms2ger: http://caniuse.com/#feat=mathml and all print formatters AFAIK
# [16:32] <Ms2ger> How about for authoring?
# [16:32] <dael> jdaggett: One other comment. You have text-align character based. I sort of pushed back on this feature. I think you need to maybe think about how you can come up with a way to have alignment that's not based on having the text align prop.
# [16:32] <dael> dauwhe: We need the result, we don't have an attachment to how. Since it has existed and existed in css 4 text, we aren't aware of alt designs.
# [16:33] <dael> jdaggett: Maybe a feature in grid that says align with this grid line, for example.
# [16:33] <dael> dauwhe: That's useful. I sort of don't have that info in dpub isolation.
# [16:33] * Bert actually uses those underful-box messages in TeX on purpose, because as a side effect they show where the hyphenation opportunities are (in languages that wasn't taught at school).
# [16:33] <dael> TabAtkins: I have a small question. I've never seen merge sequential page numbers. How is that to work?
# [16:34] <dael> dauwhe: FO has this and there are extensions in AH when you're generating indexes.
# [16:34] <dael> TabAtkins: The example is clear. Is this operating on text and assuming it's comma sep numbers?
# [16:34] <dael> dauwhe: Yes.
# [16:34] <dael> tantek: Is that english spec. or have you seen across multi lang?
# [16:34] <dael> SteveZ: I don't remember.
# [16:35] <dael> liam: I sent a prop a few weeks ago to handle this in indexing. How common is it, you'll find it in almost every text book in the west.
# [16:35] <dael> TabAtkins: The display is clear and obvious.
# [16:36] <dael> liam: How it comes from markup, each of these numbers will have a number in HTML that'spointing to the definitnion or the discussion or a figure. Typically you have definitions, references, and illiustrations. References are the ones you cut out. If you have references and illustrations they'll be repeated. So you collapse based on classes.
# [16:36] <dael> TabAtkins: It sounds like this is an aspect of a higher level index generating feature. So by itself it doesn't make any sense.
# [16:36] <dael> dauwhe: Yes.
# [16:36] <dael> TabAtkins: The spec just have propdef and an example.
# [16:37] * Joins: darktears (~darktears@public.cloak)
# [16:37] <dael> liam: I have a detailed prop I can send. I need to review it.
# [16:37] <dael> dauwhe: I'll re-write there's a sense of generating content and there are a lot of pieces to that. I have the weeds, but not the trees and houses right now.
# [16:37] <leaverou> Ms2ger: Not sure what you mean, but at O'Reilly, we use LaTeX that is compiled to MathML. No-one writes MathML by hand.
# [16:37] <dael> tantek: How adaptive or responsive are the pieces of pub content. Across different screens and such.
# [16:38] <Ms2ger> leaverou, is the compiler public?
# [16:38] <dael> dauwhe: The industrury as a whole is moving to the point. Digital reading is moving across a variety of screen sizes. The industry is moving in a direction where we need to design content for a wide range of situations.
# [16:38] <leaverou> Ms2ger: I think so, but not sure what its name is
# [16:39] <dael> tantek: I'm concerned about the amount of detail in the page being in CSS it seems that once you enter a publication on one device you're expected to finish there where more and more people are reading across multiple places. If all your pagination is done magically from CSS you lose that.
# [16:39] <dael> SteveZ: Character number works fine. You're absolutely correct that people are reading more in different places and where you were is kept in the cloud.
# [16:39] <dael> tantek: That's what we use URLs for.
# [16:40] <dael> SteveZ: There's a place not on either device.
# [16:40] <dael> tantek: That's a bias to centralization.
# [16:40] <Ms2ger> leaverou, would be interested in a link if you ever stumble upon one
# [16:40] <dael> johanneswilm: It's got to be something people can remember. People used to remember a page number, but a paragraph number is too much but also going to their offline device we can't do a URL.
# [16:40] <dael> tantek: Page numbers are broken.
# [16:40] <dael> johanneswilm: But unit can some person use.
# [16:41] <dael> Florian: Paragraph numbers should work across.
# [16:41] <dael> johanneswilm: But can they remember. Someone needs to experiement.
# [16:41] <dael> dauwhe: And there's independant location numbers. It sounds like we're starting to talk about annotations with some kind of bookmark.
# [16:42] * leaverou Ms2ger I looked into it, but it doesn't say and I don't have access to the backend. Are you @Ms2ger on twitter? I can find out & let you know
# [16:42] * Bert to Ms2ger: MathJax can read LaTeX (well, ASCIIMath) and make MathML, too.
# [16:42] <dael> liam: And web annoations is working on that. The example doesn't make clear, but the page numbers won't be in the document, they come from following the link and what page number did this occur on in this rendering by following the link. That's a sep. issue to annotation.
# [16:42] <SimonSapin> Ms2ger, leaverou: "latex to mathml" on google search has multiple results that seem relevant
# [16:43] <dael> tantek: I think it's the same issue, it's part of the reading expereince. And second that layer is something that people are trying to figure out. If we try and solve all these pagnation problems we might put outselves into a corner. Without figuring that out you won't get presentation right.
# [16:43] * leaverou Bert: Yeah, I think Ms2ger was looking for something server-side, like the one O'Reilly uses.
# [16:43] <dael> Florian: What it's going toward is these number schemes are logical not physical. Chracter offset doesn't work, but you can do one tick mark every 1000 unicode characters.
# [16:43] <dael> tantek: There's great ideas, no one is shipping them.
# [16:44] <dael> liam: Vertually all people are remembering page numbers.
# [16:44] * Ms2ger was mostly interested in something that's used by professionals :)
# [16:44] * Bert has heard of Node.js-based MathML to do that. Don't know if that is easy to set up.
# [16:44] <dael> astearns: Some devices it's taking it portriat to landscape.
# [16:44] * dauwhe let's genetically engineer kids to remember EPUB CFI: epubcfi(/6/4[chap01ref]!/4[body01]/10[para05]/3:10)
# [16:44] <dael> SteveZ: There's a different problem between people remembering and machines remembering. Machines can remember in a different way. Are you trying to give a reference for the people or the machines. Machines remember fine.
# [16:44] <dael> tantek: Not across impl.
# [16:45] <jdaggett> ew, what the heck is that?!?
# [16:45] <dael> SteveZ: True, there is no standard, but in principal it's easier to solve.
# [16:45] * dauwhe jdaggett: it's beyond horrible, isn't it!
# [16:45] * jdaggett truly!
# [16:45] * Bert "Node.js-based MathJax" is what I meant.
# [16:45] <dael> tantek: People share urls allt he time. I don't see the distinction.
# [16:45] <dael> SteveZ: That's not a problem we need to solve.
# [16:45] * hober i think my favorite part of cfi is the even/odd hack
# [16:45] * dauwhe jdaggett: read the spec and despair for humanity: http://www.idpf.org/epub/linking/cfi/epub-cfi.html
# [16:46] * leaverou Ms2ger Oh MathJax is definitely used by lots of professionals, even if not by O'Reilly
# [16:46] <dael> tantek: Not this WG. But without that being figured out to come degree, the deep dive on pagination may produce seomthing broken.
# [16:46] <dael> SteveZ: You don't want to use the presentational based for the human or the machine.
# [16:46] * TabAtkins I'd be interested in someone explaining to me wtf Nook is doing with page numbers in the first place - I can usually hit "next page" 3 or 4 times before the page number actually changes.
# [16:46] <dael> SteveZ: Is epub talking about standizing bookmarks.
# [16:46] <dael> hober: We've been joking about it, the syntax is horrible.
# [16:47] <tantek> OH: I'm considering the Semantic Web a long troll
# [16:47] <dael> dauwhe: We have lots to do here and lots ot consider so let's move on.
# [16:47] <dael> Topic: writing modes
# [16:47] <SimonSapin> TabAtkins, same on a Kobo
# [16:47] * dael TabAtkins I think nook tries to match some print version of page numbers
# [16:48] * TabAtkins Yeah, I assume that's true, I just don't know what it's doing.
# [16:48] <TabAtkins> s/OH/Tab/
# [16:48] <hober> s/hober: We've been joking about it, the syntax is horrible./hober: yes, it's called epub cfi./
# [16:48] <fantasai> https://drafts.csswg.org/css-writing-modes/issues-cr-2014
# [16:48] * MaRakow there's a nook viewport that needs to be defined probably
# [16:48] <dael> jdaggett: Can we do inline?
# [16:48] <dael> Topic: CSS inline
# [16:48] <fantasai> https://drafts.csswg.org/css-inline/
# [16:49] <dael> fantasai: We updated the draft. Things that are different: we filled out a bit of the first chapter which defines verital align. We defined dominant baseline prop. The two long hands are there because SVG needed them defined.
# [16:50] <dael> fantasai: That's roughly that. The definitions and straightforward. The dominant baseline has several values. [lists them] If any should be dropped, let us know We have to have alphabetic and central and we need auto
# [16:51] <dael> jdaggett: You need clear definition of the fallback. There are fonts that could have hanging baseline, but in the real world there almost never are. Impl fall back to baseline all the time.
# [16:51] <dael> astearns: So we should omit hanging baseline?
# [16:51] <dael> jdaggett: Hanging and maybe mathematical are not widely supported.
# [16:52] <dael> jdaggett: Type designers design their type so it lines up with other glyphs the way the want it to. When you're using multi fonts, how will they line up it's not always good. The information I think the spec needs isn't there. We need to define the fallback clearly.
# [16:52] <dael> SteveZ: First is, hanging baseline alignment is not uncommon in the parts of india that use the hanging baseline. How they acieve it I don't know.
# [16:52] <dael> jdaggett: That's my point.
# [16:53] <zcorpan> https://gist.github.com/zcorpan/2c2b3114ddd636515b95 <- httparchive results for 'content' without :before/:after (1877 matches out of.... 1,182,701 text/css files)
# [16:53] <dael> SteveZ: The second point is it seems to me we ought to be focused on what the user wants rather than what hte font provide. I would rather a fallback way of calc the hanging baseline, ie fiddle with it until it fits, rather than drop.
# [16:53] <dael> jdaggett: We have text top and if you look at the open type table for baselines andthe hanging baseline is desc for what's used in tibetan. Are we talking about hte hanging baseline or are we talking about text top?
# [16:54] <dauwhe> John Hudson: " The BASE table specification also gives examples of a ‘hanging baseline’ setting for Devanagari script, but I’ve yet to see this implemented in either fonts or software, and I believe it is based on a mistaken notion. "
# [16:54] <dael> jdaggett: In the open type definition of the baseline table there is a hanging baseline defined, but it's desc as the baseline used for tibetan. What is it you're really wanting to use this for? Perhaps it's some other baseline?
# [16:54] <fantasai> Is it a mistaken notion because nobody implemented it, or a mistaken notion because nobody wants it?
# [16:55] <ChrisL> Baseline table spec - http://www.microsoft.com/typography/otspec/base.htm
# [16:55] <dael> SteveZ: I want to use it for Bengali, [list of scripts]. I understand hanging baseline was intended for those, but it wasn't defined. For all of those I have examples of alingment.
# [16:55] <dael> jdaggett: So what are the mechanics of that?
# [16:55] <dael> dauwhe: Do you have ex of digital content that does this?
# [16:56] <dael> SteveZ: Printed doc. Newspapers. It's an every day occurance. It's what people want to do. When you say what are the mechanics, I don't know what hte newspapers are doing. What I would do is the hanging baseline is pretty obvious if I look at the bitmap of the character. That woul dbe my fallback.
# [16:56] <dael> jdaggett: You want to infer the metrics from analyzing the bitmaps?
# [16:56] * tantek feels like this is a rathole discussion that deserves documentation in an issues
# [16:56] <dael> jdaggett: That feature will never work.
# [16:56] <fantasai> s/will never work/will never be implemented/
# [16:57] <dael> SteveZ: People do it all the time and this is particularly IDable. When metrics are missing you need some method to fill it in.
# [16:57] <dael> tantek: Do you have an open issue on when metrics are missing?
# [16:57] <dael> SteveZ: Yeah.
# [16:57] * tantek was hoping for an issue # or a, gasp, a URL
# [16:57] <dael> ChrisL: You can put a base foot tag in for any language you want so I don't see why that would be impossible.
# [16:58] <dael> jdaggett: My question is, I don't see fonts supporting this. You clearly need a fallback and i don't think analyzing bitmaps is a good solution.
# [16:58] <dael> SteveZ: We can record the issue and move offline.
# [16:58] <ChrisL> s/base foot tag/BaseScriptTag/
# [16:58] * Joins: nvdbleek3 (~nvdbleek@public.cloak)
# [16:58] <dael> dauwhe: And we can record the alphabetic font line.
# [16:58] <ChrisL> eg “devn” BaseScriptTag for Devanagari script
# [16:58] * Quits: nvdbleek (~nvdbleek@public.cloak) (Ping timeout: 180 seconds)
# [16:58] * nvdbleek3 is now known as nvdbleek
# [16:59] <dael> SteveZ: There's some subtile points like witht he hanging base line where the line is bigger on the initial cap then the body text and there's an issue as to where you align to, but htat's a subtilty. People do align to the hanging line.
# [16:59] <dael> SteveZ: I think the eq. of the news magazines do this on a regular basis.
# [16:59] <dael> fantasai: Question is do we keep all the values, or do we drop? auto central and alphabetic have to stay.
# [16:59] <dael> SteveZ: And ID and graphic.
# [16:59] <dael> fantasai: I don't have that in spec.
# [16:59] <fantasai> s/ID and graphic/ideographic/
# [17:00] <dbaron> Steve's list of scripts was Devanagari, Bengali, Gujarati, and Gurmukhi.
# [17:00] <dael> SteveZ: It's used in fonts. IN alignment in Japanese it's equally likely to be horizontal. Text bottom kind of works in that case.
# [17:00] <dael> fantasai: I think text bottom isn't what you want.
# [17:00] <dael> SteveZ: You're right.
# [17:00] <dael> fantasai: I wonder if text top and bottom are needed.
# [17:01] <dael> ChrisL: I'd like to understand, the fonts don't currently have this table but they're used anyway. Are existing fonts going to be changed to add these things in or are these features that no body uses?
# [17:01] <dael> SteveZ: Some font vendors supply the tables, relatively few supply them because the way their production tools don't make it easy for them to produce the tables and no body was using them anyway. They were finding other methods.
# [17:02] <dael> SteveZ: Because we're trying to do it automatically we need to be more hospitapl to the requirements people have.
# [17:02] <jdaggett> baseline table data: under OSX 10.8, 810 fonts, 41 with BASE table (all CJK fonts)
# [17:02] * Joins: r12a (rishida@public.cloak)
# [17:03] <dael> liam: In particular some of the countries with hanging baseline have been slow to join the standardization efforts. If you look at some scripts, they're not even supported by unicode. They're using old bitmap or postscrip fonts, but it's changing fast.
# [17:03] * r12a waves
# [17:03] * fantasai waves back
# [17:03] <jdaggett> there's no harm omitting values for which we *can't* support properly at this point
# [17:03] <fantasai> we're discussing baseline tables
# [17:03] <fantasai> https://drafts.csswg.org/css-inline/#dominant-baseline%20property
# [17:03] <dael> ChrisL: It's changing fast and they're moving to unicode, so it seems like a bad time for the WG to remove baselines that they might us. We can't pretent they are using them so we have to explain how thye're used. Presumably the spaing engine in the browser knows. If it knows get it to tell you.
# [17:04] <dael> jdaggett: Why does it have to know where the hanging baseline is?
# [17:04] <fantasai> r12a, question atm from me is, which baseline values do we need atm?
# [17:04] <dael> SteveZ: Same font, but not same size.
# [17:04] <fantasai> r12a, thought you might know
# [17:04] <dael> jdaggett: We don't have data here to establish this. Coming up with ways to wing it isn't good for this group.
# [17:04] <Bert> -> https://www.microsoft.com/typography/otspec/baselinetags.htm OpenType tag registry for "hang", which says "The hanging baseline. This is the horizontal line from which syllables seem to hang in Tibetan script."
# [17:04] <dael> ChrisL: The rendering engine is winging it so we use that.
# [17:05] <dael> jdaggett: It's not winging it. They're laying out on a baseline to look right.
# [17:05] <dael> ChrisL: Within a single font
# [17:05] <dael> jdaggett: Precisely.
# [17:05] <jdaggett> there's no magic here guys, if the font isn't providing these metrics the shaping engine is not creating it
# [17:05] <r12a> i've never really done the research i should wrt baselines - i heard some interesting comments from John Hudson recently hinting at some myths surrounding use of hanging baselines, but it's only rumour really until i/we investigate further
# [17:06] <dael> fantasai: Anyway, I need a list of what values need to go into this spec. I'm hearing conflicting information. 1 is support the hanging baseline because people need it and if it's not provide fallback and that we support it will encourage people to use it. THe other side is don't put it in there because people don't use this.
# [17:06] <dael> tantek: It's a signaling method.
# [17:06] <r12a> i suggest we discuss in email and include people like John
# [17:06] <dael> jdaggett: It's not, it's a sign that it needs to be simulated.
# [17:06] <dael> fantasai: What about the mathematical baseline? Text bottom, text top? I put everything in the spec.
# [17:06] <dael> SteveZ: Text bottom and top have been in since CSS 1.
# [17:06] <dael> dbaron: You can't turn vertical align.
# [17:07] <dael> fantasai: This is the dominant baseline.
# [17:07] <r12a> the comment from John i referred to came up in the discussion about first-letter
# [17:07] <dael> fantasai: I'll keep all the values until i get an actual answer.
# [17:07] <dael> tantek: Capture the issues on the ones where people are complaining.
# [17:07] <jdaggett> sure
# [17:07] <dael> SteveZ: One hanging baseline the fonts don't provide the data, what do we do?
# [17:07] <dael> dauwhe: And we can contact the indic layout group through Richard.
# [17:08] <dael> tantek: I think this document is early enough that we can capture each issue inline.
# [17:08] <jdaggett> counter example - small-caps glyphs have existed in fonts for 20 years
# [17:08] <jdaggett> but up until a couple years ago, no browser used them for 'font-variant: small-caps'
# [17:08] <dbaron> dominant-baseline in SVG is http://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty
# [17:08] <dael> fantasai: Next is vertical align which takes baseline shift or align baseline. alignment baseline is take same values as dominat baseline and takes bottom top and cetner as well as middle because that was in CSS 2.1 Center is new, I think.
# [17:09] <dael> fantasai: Baseline-shift is you do a line to the baseline and you shift.
# [17:09] <dael> SteveZ: So you need to clarify the text that you compute the baseline alignment first and shift it second.
# [17:09] <dael> fantasai: I think it's fairly clear.
# [17:10] <dael> jdaggett: I think the spec needs to talk about use cases. What's the use here for setting dominant baseline and adjusting the baseline.
# [17:10] <dael> dbaron: My memory of SVG is dominant baseline gets used for something additional in SVG which is not in CSS. With SVG text when you say place at this x and y coodrinate, the dominant baseline says what you align to that point.
# [17:10] <dael> ChrisL: That's correct.
# [17:10] <jdaggett> not hearing chris L
# [17:11] <dael> SteveZ: Traditional answer is in the open type spec there are multi baseline tables and it depends on which baseline is dominant. If you're doing Japanese in and English context it's a different table than English in a Japanese context.
# [17:11] <dael> fantasai: That seems different.
# [17:11] <dbaron> (my comment about SVG explains why text-before-edge and text-after-edge are important)
# [17:11] <dael> fantasai: The dominant baseline is the baseline you use to align the boxes. It has no effect if the font doens't change.
# [17:12] <dael> SteveZ: There are different tables for different dominnat baselines. In the open type spec there is a baseline table for each dominant baseline. One of the reasons to have a dominant baseline is to say which set of tables you're using.
# [17:13] <dael> jdaggett: That establishes the position. It would be nice to see a use case in the spec.
# [17:13] <dael> fantasai: According to the spec right now, you have a baseline table it has multiple basleinges, alphabetic, top, central, etc. The position of these baselines is determined by the font size
# [17:14] <dael> SteveZ: A font can have multi tables and the dominant chooses which one. Each table has a set of baseline offsets.
# [17:14] <dael> fantasai: So if there are four baselines it would have four offsets.
# [17:14] * Quits: BogdanBrinza (~bbrinza@public.cloak) (Ping timeout: 180 seconds)
# [17:14] <dbaron> s/it would/each of four tables would/
# [17:14] <jdaggett> there's *one* BASE table which contains information for multiple baseline definitions
# [17:15] <jdaggett> a font doesn't have multiple BASE tables...
# [17:15] <dael> fantasai: If I have a font that's got 0 coord as the alphabetic baseline, above it there's 800 units which gets me text top and -200 units which is text bottom. This gives me four baselines There's a central at 300.
# [17:15] <dael> fantasai: You're saying that's one baseline table and the font may have an additional table that has a different alphabetic.
# [17:16] <jdaggett> spec needs an example that explains how dominant-baseline and vertical-align define where text is placed along a line
# [17:16] <dael> SteveZ: You don't need a baseline table for your example. That's not the way baseline tables are done. They have values for these things in the table. In this case the position of the Japanese text in an english lang context it might be -100 instead od -200.
# [17:16] <dael> SteveZ: The English tends to be centered in the Japanese space, but Japanese in English puts the Japanese higher.
# [17:17] <dael> astearns: We started this with thinking there should be justification for this section of the document. We're in the weeds. Let's just put some pictures in the document and have a note that we need those and move on.
# [17:17] <dael> SteveZ: I sent a note to the WG about how it's calculated.
# [17:18] <dael> fantasai: There's one thing I'm confused about. There's a single font in a single size. You're saying depending on the baseline the glyphs switch up and down?
# [17:18] <dael> SteveZ: because you switched which is dominant.
# [17:18] <dael> fantasai: What controls that?
# [17:18] <dael> SteveZ: Baseline table.
# [17:18] <dael> fantasai: And it's coorolated with different glyphs in the font?
# [17:19] <dael> SteveZ: No. Where the are relative to the dominant baseline can differ. Let's take this offline and I can produce and example.
# [17:19] <dael> plinss: Let's take it offline and move on.
# [17:19] <dael> SteveZ: I agree with jdaggett that we need and example and I think I can come up with one.
# [17:19] <dael> fantasai: The examples in the spec I wrote if the dominant baseline is alphabetic and you have two different fonts, you will find the alphabetic baseline on each and you will align those.
# [17:20] <dael> SteveZ: That's the default.
# [17:20] <dael> fantasai: That's for alphabetic. If you're using central baseline as dominant you align those two points.
# [17:21] <Bert> -> https://www.microsoft.com/typography/otspec/BASE.htm OpenType explanation of Dominant Baseline
# [17:21] * Quits: estellevw (~estellevw@public.cloak) ("Snuggling with the puppies")
# [17:21] <dael> fantasai: The clear use case is in Japanese vertical text you have a central baseline, you don't want alphabetic. For english text you would want alphabetic baseline within that context. Automatically in veritcal we use central and the horx we use alpha, but you may want to switch that.
# [17:21] <fantasai> s/baseline on each/on each glyph/
# [17:22] <dael> plinss: Anything else?
# [17:22] <dael> fantasai: There's an issue here were we have top bottom and center keywords. I shoved them into alignment baseline prop because I didn't want to make a longhand.
# [17:22] <jdaggett> fantasai: can you speak up a tad?
# [17:23] * fantasai can try
# [17:23] <dael> SteveZ: I sent you a prop a couple hours ago that said I think it makes sense to do them as a sep longhand and make it exclusive with the other two. It's either or because they're in sub trees. You couldn't shift a centered subtree. It doesn't seem to me it would be a big thing.
# [17:23] <dael> fantasai: Having two prop in CSS trying to control the same thing is you can't say which one wins.
# [17:23] <dael> SteveZ: One short hand
# [17:23] <dael> fantasai: The shorthand doesn't matter.
# [17:24] <dael> SteveZ: The default for the third prop is auto which is the other one wins. You have to put in a value for it to take effect and if you do you can't use the other value.
# [17:24] <dael> fantasai: I don't like that kind of conflict model.
# [17:24] <dael> SteveZ: It's consistant with existing vertical align.
# [17:24] <dael> fantasai: We can also put those in the alignment baseline prop.
# [17:24] <dael> SteveZ: It seems it's easier to have syntatic conflict.
# [17:25] <dael> fantasai: But then you have authors that set something to not auto and they're wondering why the alignment baseline didn't take effect and it's become someone else sent it to not auto. Conflict resolution for CSS is cascading and it's better to avoid doing these one preperty always wins and hopefully it didn't change when you didn't mean it to.
# [17:26] * dauwhe my kingdom for an example
# [17:26] <dael> SteveZ: But nothing you said is fixed for your solution. Right now, baseline alignment can take either a bseline or subtree alignment. If I set a subtree it wipes out baseline
# [17:26] <dael> fantasai: You can't do both.
# [17:26] <dael> SteveZ: So you wiped it out.
# [17:27] <dael> fantasai: If I have a rule on this stylesheet here and I have another rule over here then the second overrides the first because it's later in the cascade.
# [17:27] <dael> SteveZ: I understand.
# [17:27] <dael> fantasai: That's why they're all in one thing even though it's not really a baseline.
# [17:27] <dael> fantasai: That's it for the top.
# [17:28] <dbaron> http://www.w3.org/TR/2002/WD-css3-linebox-20020515/#baseline has some pictures, for what it's worth
# [17:28] <dael> SteveZ: The last comment I made is you don't have the alignment point prop and that was in there to spec alignment points for replaced items which don't have a baseline associated with them that you want to be able to align still.
# [17:28] <dael> SteveZ: You want that for things like initial caps which are images such as the kind of things that were done in medieval texts. You want ot spec where the alignment point it.
# [17:29] <dael> fantasai: It was alignment baseline?
# [17:29] <dael> SteveZ: Alignment point
# [17:29] <dael> Florian: You spec that on the replaced element? And that matches that point on the dominant baseline?
# [17:29] <dael> SteveZ: If you spec alignment baseline, it alines to that.
# [17:29] <dael> SteveZ: You align to whichever baseline it is aligned to.
# [17:30] <dael> fantasai: I don't see this in the XSL spec.
# [17:30] <leaverou> Ms2ger: The TeX→MathML script that O'Reilly uses is http://www-sop.inria.fr/marelle/tralics/
# [17:30] <dael> jdaggett: Florian point gets to the point i"m not clear on. THe placement of glyphs on the page gets set to from which set of stats.
# [17:30] <Ms2ger> leaverou, thanks
# [17:30] <jdaggett> um, implementations need precise details in this case
# [17:31] <jdaggett> "roughly" is a word I don't like...
# [17:31] <dael> fantasai: The model is roughly, I don't know the steps, but the results should be I go ask the font, give me the glyph, where is the alignment point, where is my dominnat baseline, let's put the point there. I go get another glyph and I match up the points. If I have a vertical align shift I layout hte points and I shift the box.
# [17:31] <dael> Florian: I think we need to talk this offline.
# [17:31] <dael> plinss: We have 3 more topics for today.
# [17:31] <dael> SteveZ: Did that work for you jdaggett?
# [17:32] <dael> SteveZ: fantasai I'm willing to work with you.
# [17:33] <dael> fantasai: The way we handle inline images is that we synthesize a baseline for the boxes. The text bottom and alphabetic are assumer the bottom text top is the top. If you need to adjust that you can do it with margins. It didn't seem urgent to spec another prop. If we did I would like to tie it to a specific baseline.
# [17:33] <dael> fantasai: To get it to work correctly I think you need to specify a lot of the information, but most of the time you can synth from just a few rules.
# [17:33] <dael> SteveZ: That's not my memory. replaced elements are aligned to their bottom edge and that's it.
# [17:34] <dael> fantasai: We added the synth rules in writing modes because that gets you the correct by default.
# [17:34] * dauwhe let's wrap every image in SVG for a11y, and then turn into a font to get baseline tables
# [17:34] <dael> SteveZ: That's not nec correct.
# [17:34] <dael> fantasai: It's better for alphabetic in general.
# [17:35] <dael> SteveZ: We should record an issue for the handling of replaced elements because I think different place elements don't include the margin.
# [17:35] <dael> fantasai: I thinkt he ones that don't contain text use the margin box.
# [17:35] <dael> SteveZ: I just remmeber it's different for different categories.
# [17:35] <dael> fantasai: If you think you need this thing, show me the use cases, but I think we can do this without another property.
# [17:35] <dael> dauwhe: We want examples of all this stuff.
# [17:35] <dael> fantasai: That's that section.
# [17:36] <dael> fantasai: Do you want to go over initial text?
# [17:36] <dael> dauwhe: We went and made the edits based on the sydney F2F and then added a new section on wrapping around initial letters.
# [17:36] <jdaggett> good summary: http://w3cmemes.tumblr.com/post/127640612412/the-most-interesting-steve-zilles-in-the-world
# [17:36] <dael> fantasai: We also changed the initial letter align prop.
# [17:36] <fantasai> https://drafts.csswg.org/css-inline/#initial-letter-wrapping
# [17:36] <dael> dauwhe: There has been some discussion about wrapping being at risk.
# [17:37] <dael> TabAtkins: Talking to our inline person, figuring our glyph boundries we think will be fairly expensive and complicated for something that's a relatively minor improvement.
# [17:37] <dael> fantasai: We're fine with that. The WG asked us to spec how it would work.
# [17:37] <dael> tantek: We were doing glyph rending in 2000 so I don't by the perf arguement.
# [17:38] <dael> TabAtkins: We can do it. It's code we'd have to write fresh and it's complex for a small improvement.
# [17:38] <dael> jdaggett: I'm not sure that's true.
# [17:38] <dael> TabAtkins: The person who writes our font stuff says it's hard so I believe him.
# [17:38] <dael> jdaggett: There's code for canvas to do outline.
# [17:38] <dael> TabAtkins: We don't want to paint a glyph onto a temp canvas and do pixal counting.
# [17:39] <jdaggett> this feature requires extracting an outline
# [17:39] <dael> shane: Wihout tech details, we don't think it's a priority so we want to mark it as at-risk. Is that okay?
# [17:39] * ChrisL yeah some company beginning with G defined a whole new colour bitmap format I believe
# [17:39] <jdaggett> glyph ==> path, no painting involved
# [17:39] <dael> Florian: They're not saying the code wouldn't perform well, they're saying the don't want to write it.
# [17:39] <dael> tantek: How is this harder than exclusions.
# [17:39] <dael> Florian: They're saying they don't want to
# [17:40] <dael> SteveZ: If you're doing shaping you can break it into the piece that you need to shape.
# [17:40] <dael> TabAtkins: The shaping engine is a differnet part of the engine.
# [17:40] <dael> jdaggett: That's wrong. You do and you get the outline data from the glyphs.
# [17:40] * Joins: BogdanBrinza (~bbrinza@public.cloak)
# [17:41] <dael> TabAtkins: With appologies the Emil didn't come to Paris, but until you can convince us with Emil here, that will be our official opinion. I cannot argue the point beyond giving you the explination that I have given for you.
# [17:41] <jdaggett> tabatkins: please ask behdad, he'll give you a better answer I think
# [17:41] <dael> liam: Clarification question. I think you're saying that you're not wanting to impl at least part of the initial letter.
# [17:41] <dael> TabAtkins: Initial letter wrap.
# [17:42] <dael> liam: There's two aspects of that. One was wrapping exactly around the glyph around the character and the other..
# [17:42] <dael> TabAtkins: They're eq in difficulty.
# [17:42] <dael> liam: Is there a possible compromise for the first line? You would have user supplied move closer value. You could achieve the same effect for the first line only.
# [17:42] <jdaggett> liam's effect -100000000000000000
# [17:43] <dael> TabAtkins: I see nothing wrong with that if the editors are there. It's text intent.
# [17:43] * dauwhe jdaggett: you forgot some zeros
# [17:43] <dael> liam: Text indent doesn't work in the polyfill
# [17:43] <ChrisL> s/intent/indent/
# [17:43] <liam> jdaggett, well, I prefer it as spec'd too
# [17:43] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [17:43] <dael> Florian: You say the previous feedback was integrated. On the initial letter line prop, maybe I'm missing something but I don't see where it says how to align when the initial letter and the text aren't in the same script.
# [17:43] <dael> fantasai: I think you need to keep reading.
# [17:44] <dael> Florian: Is it border-box I should be reading?
# [17:44] <dael> Florian: If I want to align the ideographic and the text around it, how do you do that?
# [17:44] <dael> fantasai: Read the note at the bottom. YOu have two values, we just dropped a bunch and leaving it as auto made more sense.
# [17:44] <fantasai> https://drafts.csswg.org/css-inline/#aligning-initial-letter
# [17:45] <dael> dauwhe: You just use the appropriate values on each half.
# [17:45] <tantek> As someone who has spent a lot of time both implementing/shipping fancy first-letter effects 15 years ago, and continues to publish content with CSS that uses them (e.g. http://tantek.com/2015/224/b1/alphabet-indieweb ) I'm very happy with the improvements in this working draft since the previous version and would like to see it published as an updated public working draft.
# [17:46] <dael> fantasai: The initial things we were told to solve was deal witht he alignment of diff script.s We can up with two values, alignment point of letter and of line of text. The values are auto for the letter and alphabetic, ideographic, and hebrew value that we think needs to exist.
# [17:46] <ChrisL> +1 to publishing
# [17:46] * Quits: BogdanBrinza (~bbrinza@public.cloak) ("")
# [17:47] <dael> fantasai: You need to pick from the letter and the line of text lists. The initial value of letter is auto.
# [17:47] <dael> fantasai: We think the auto value doesn't need to be set explicitly. It's just the first letter if you can't tell what that is you have a problem.
# [17:47] <dael> Florian: That's not true.
# [17:47] <dael> SteveZ: Punctuation
# [17:47] <dael> fantasai: That's not a first letter.
# [17:48] <dael> fantasai: We can go and do all the values if you want, but we thought we had all these things and we don't need an auto. We can just have border-box? and you can decide on that and thenyou pick which part of the text you're aligning to.
# [17:48] <dael> SteveZ: Hanging?
# [17:48] <astearns> +1 to publishing
# [17:48] <dael> fantasai: It uses the cap height.
# [17:49] <dael> fantasai: The cap height corrisponded to the hanging baseline point in most of the fonts we checked so that seemed reasonable.
# [17:49] <dael> SteveZ: The problem with the indic is the top aligns.
# [17:49] <dael> fantasai: You use alphabetic as the default.
# [17:49] <dael> SteveZ: I have ex where that doesn't work.
# [17:50] <dael> fantasai: Alpha baseline worked in most cases.
# [17:50] <dael> SteveZ: I have an example on my screen where it doesn't.
# [17:50] <dael> dauwhe: Do you have the fonts?
# [17:50] * Quits: kwkbtr (~kwkbtr@public.cloak) ("")
# [17:50] <dael> SteveZ: no.
# [17:50] <dael> dauwhe: I love the initial idea for this to do something simple that covers everything.
# [17:50] <dael> SteveZ: I'm hearing you people say that the indic fonts don't matter.
# [17:51] <dael> dauwhe: I thinkthat's not true. I've spent 50 hours looking at these fonts. Everywhere I can look at the font and look athe the font metrics and where I see being a good alignment can work off of these metrics.
# [17:53] <tantek> content request for CSS Inline Layout: I think it should specify which properties apply to ::first-letter, that is, incorporate these properties: https://drafts.csswg.org/css-pseudo-4/#first-letter-styling
# [17:53] <dael> Florian: I see aligning glyph to glyph is different han border box. As to glyph to glyph I wonder if we can do auto and that does the right thing. Spec auto might not be easy but give the text in the lines it's not necessairly the case. I don't htink expanding the number of controls to say I have multiple letters and I have multiple scripts, that's too many switches. Can we do auto or border-box and that covers a lot of cases.
# [17:53] <tantek> or rather that list of properties
# [17:53] <tantek> and I propose adding width and height to that list
# [17:53] <dael> fantasai: The first letter it's easy to auto detect, but when you have a lot of letters it becomes a lot less reliable. You'll have a sentence that begins with IBM and the rest is Japanese.
# [17:53] <tantek> use-case: styling a bunch of different first-letters all the same width and height
# [17:53] <tantek> like that post I linked to above
# [17:53] <dael> Florian: But you can detect that the M is english and the random word in the middle is english.
# [17:53] * Quits: johanneswilm (~johannes@public.cloak) (Ping timeout: 180 seconds)
# [17:53] <dael> fantasai: We don't care about that random word. Maybe if we have text that's alternating language than you might want to have a switch, but that's a weird case so I don't think we should care.
# [17:54] <dael> Florian: It's sure a weird case we shouldn't have a switch, but we need to say what happens.
# [17:55] <dael> fantasai: We can give the user control over borderbox or not and alphabetic vs ideographic because we can't infer that ourselves. For the first letter we don't do script based analysis. The reason I'm comfortable making an exception for first letter there's really only one graphime cluster or a sentence.
# [17:55] <dael> Florian: There's a company that's mixed script what do you do?
# [17:55] <dael> fantasai: It picks the first letter.
# [17:55] <dael> Florian: The first draft didn't say what happens now we have controls over what happens.
# [17:56] <dael> fantasai: We bias against latin is the set of ruels we're using. [reads the spec]
# [17:56] * Quits: MaRakow (~MaRakow@public.cloak) (Ping timeout: 180 seconds)
# [17:56] <dael> Florian: Generally speaking on the initial letter you were doing auto and that's right, but on the text around I was wondering if you could do auto
# [17:56] <dael> fantasai: You can do auto with rialibility on initial letter because it's short, but we don't get good results from heuristics on longer pieces of text. We're making an exception for initial letter.
# [17:56] <dael> Florian: Okay.
# [17:57] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [17:57] <dael> liam: In the case where your random word in another scrip happens to be on the third line, you could have several places where you have that script and you want it to appear the same so it would be a mistake to make it special.
# [17:58] <dael> SteveZ: So create a line grid with the dominant baseline prop and align to the lines of that linegrid irrespective of where the lines come out.
# [17:58] <dael> fantasai: We agreed to that in the last meeting.
# [17:58] <dael> SteveZ: That's the only way you get consistant size.
# [17:58] <dael> liam: In the majority case where everything is the same language it works out. If you have something with an accent on the first line it works out. It's much simplier to implement.
# [17:59] <dael> liam: You can end up in a look if you don't spec this way.
# [17:59] <dael> fantasai: Anything else you want to go over?
# [17:59] <dael> tantek: About initial letters?
# [17:59] <liam> s/look/loop/
# [17:59] <dael> tantek: Yes. First, I read the draft and this is a huge improvement. I'd like to see an updated public draft based on this even if you don't make and changes.
# [18:00] <dael> tantek: My one request is I would like the list of what prop apply to first letter, I think that's appropriate for this draft.
# [18:00] <tantek> https://drafts.csswg.org/css-pseudo-4/#first-letter-styling
# [18:00] <dael> tantek: I think there's so many effects in this draft that I think it belongs here more than CSS pseudo. I'd like the list copied or moved.
# [18:01] <tantek> http://tantek.com/2015/224/b1/alphabet-indieweb
# [18:01] <dael> tantek: I'd like to prop adding to the list weidth and height to the first letter. I havea use case. When you want to style multiple paragraphs os the same first letter all witht he same width and height. I tried to do it in a blog post and I couldn't. I can put the blog post where I tried in the notes.
# [18:01] <dael> tantek: Those blocks where you can scroll down and see what I achieved.
# [18:02] <dael> tantek: I wanted them aligned as blocks.
# [18:02] <dael> tantek: That was my only request. Nice work, I'd like to see an updated draft published.
# [18:02] <dael> fantasai: I'd like people to summerize what issues they want in the draft.
# [18:03] <dael> Florian: I'm happy to publish with or without issues.
# [18:03] <dael> fantasai: Anybody else have opinion on what needs to be in the draft before we publish.
# [18:03] <dael> tantek: Mine are all would like to not need to.
# [18:03] <dael> SteveZ: Let me review the note I sent to the list.
# [18:03] <dael> fantasai: jdaggett?
# [18:03] <jdaggett> publishing fine
# [18:04] <jdaggett> i'll post issues at some point
# [18:04] <dael> plinss: Do we want to resolve on publishing?
# [18:04] <dael> fantasai: SteveZ needs more time
# [18:05] <dael> fantasai: Issues so far are what happens when baseline not in font, add width and height to prop for initial letter. Add a complete list of things that can be applied to initial letter. And the question of which baseline keywrods do we need to keep.
# [18:05] <dael> fantasai: Anything else I forgot?
# [18:05] <dael> liam: You got TabAtkins feature as at risk?
# [18:05] <dael> fantasai: Mark initial letter wrap as at risk.
# [18:06] <dael> TabAtkins: I talked about text indent...Is that sufficent to do this?
# [18:06] <dael> fantasai: I applies to the first letter.
# [18:06] <dael> TabAtkins: Unless we define it to not.
# [18:06] <dael> fantasai: I think we want it to.
# [18:06] <dael> dbaron: I feel like the initial letter being indented is the more common.
# [18:07] <dael> fantasai: You can do it with the margin prop in theory so we don't have to use text indent, but what do you want to be the fallback if you don't get the styling.
# [18:07] * dauwhe Just use the initial-letter-fudge-inline-progression-direction property.
# [18:07] <dael> liam: If you don't get it, that doesn't work because it's a three line cap. You want to pusht he three lines out and move it in. But maybe that's the difference between text indent on the first letter.
# [18:07] <dael> fantasai: Text indent is only the paragraph.
# [18:08] <dbaron> One other issue: https://drafts.csswg.org/css-inline/#valdef-alignment-baseline-before-edge -- text-before-edge and text-after-edge are in SVG, but where do before-edge and after-edge come from? They don't appear needed to me.
# [18:08] <dael> TabAtkins: If we kept it and only had a first length value as manditory and in absense of length it uses glyph bounds.
# [18:08] <dbaron> it's not in http://www.w3.org/TR/SVG11/text.html#DominantBaselineProperty or http://www.w3.org/TR/SVG2/text.html#DominantBaselineProperty
# [18:08] <dael> liam: Where there was a sub it could be off by a few px but it would be a heck of a lot better. You could read the text corectly.
# [18:08] <dael> TabAtkins: That seems fine.
# [18:09] <dael> liam: If we can do it in such a way that it doesn't get in the way of glyph outline would be great.
# [18:09] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:09] <dael> fantasai: Having it as a value in the initial wrap would work. You would throw it out or honor it if you support it.
# [18:09] <dael> fantasai: Is that generally a good idea?
# [18:10] <dael> Bert: Is that a positive or a negative value?
# [18:10] <heycam> text-before-edge comes from XSL
# [18:10] <dael> TabAtkins: I'd match text semantics
# [18:10] <heycam> sorry, misread; before-edge isn't even in XSL
# [18:10] <dael> RESOLVED: adda lenght value to initial-letter-wrap
# [18:10] * Joins: bcampbell (~chatzilla@public.cloak)
# [18:11] <dael> fantasai: The bounding box of the initial letter is the side barings so that handles some cases.
# [18:11] <dael> plinss: So resolve to publish?
# [18:11] <dael> plinss: opposed?
# [18:11] <dael> dbaron: I put one other issue in IRC that I don't know is worth discussion. The spec lists 4 compat values for SVG, but I think only 2 exist.
# [18:11] <dael> RESOLVED: publish an updated WD
# [18:12] <dael> plinss: What do we do with css linebox.
# [18:12] <dael> fantasai: We should replace that.
# [18:12] <dael> plinss: We have inline on TR.
# [18:12] <dael> fantasai: They forgot to merge it when we did public.
# [18:12] <dael> tantek: This superceeds?
# [18:12] <Florian> http://florian.rivoal.net/csswg/cn-en_raised-cap_shed.jpg
# [18:12] <dael> fantasai: Yeah. It says it in the header. Well, we need to do that when we pub.
# [18:12] <Florian> http://florian.rivoal.net/csswg/mixed_script_initial.jpg
# [18:12] <liam> [text-before-edge is in XSL-FO, e.g. http://www.w3.org/TR/xslfo20/#font-model ]
# [18:13] <ChrisL> @dbaron see FX agenda https://wiki.csswg.org/planning/paris-2015#proposed-agenda-topics-fx Old writing-mode values (FX)
# [18:13] <dael> Florian: I pasted into IRC two cases of initials with mix scripts.
# [18:13] <TabAtkins> s/text semantics/text-indent semantics/
# [18:13] <dael> plinss: So on that we're done for the day.
# [18:14] <skk`> good night!!
# [18:14] <jet> https://www.facebook.com/pages/Le-Zinc-des-Cavistes/186239554726854?sk=info&tab=overview
# [18:14] * Quits: hyojin (~hyojin@public.cloak) ("Page closed")
# [18:14] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [18:14] <jet> ^^ Le-Zinc-des-Cavistes
# [18:14] <SimonSapin> dinner: Le Zinc des Cavistes, 5 Rue du Faubourg Montmartre
# [18:15] * Quits: dholbert (~dholbert@public.cloak) (Ping timeout: 180 seconds)
# [18:16] * Quits: tantek (~tantek@public.cloak) (tantek)
# [18:17] * Joins: dholbert (~dholbert@public.cloak)
# [18:17] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [18:18] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [18:19] * Quits: gregwhitworth (~gregwhitworth@public.cloak) ("Page closed")
# [18:20] * Rossen is now known as Rossen_away
# [18:21] * Quits: skk_web_ (~skk_web_@public.cloak) (Ping timeout: 180 seconds)
# [18:21] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [18:22] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [18:22] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [18:23] * Quits: jihye (~jihye@public.cloak) (Ping timeout: 180 seconds)
# [18:23] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [18:23] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:24] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:24] * Quits: dael (~dael@public.cloak) (Ping timeout: 180 seconds)
# [18:30] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [18:31] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:38] * Quits: ChrisL (clilley@public.cloak) (Ping timeout: 180 seconds)
# [18:40] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [18:42] * Joins: adenilson (~anonymous@public.cloak)
# [18:44] * heycam is now known as heycam|away
# [18:44] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [18:47] * Parts: r12a (rishida@public.cloak) (Leaving...)
# [18:48] * Quits: dauwhe (~dauwhe@public.cloak) (Client closed connection)
# [18:49] * Joins: dauwhe (~dauwhe@public.cloak)
# [18:49] * Quits: dauwhe (~dauwhe@public.cloak) ("")
# [18:49] * Quits: SteveZ (~SteveZ@public.cloak) (Ping timeout: 180 seconds)
# [18:51] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [18:52] * leaverou is now known as leaverou_away
# [18:55] * Quits: ed_paris (~ed@public.cloak) (Ping timeout: 180 seconds)
# [18:57] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [19:00] * Quits: projector_ (~projector@public.cloak) (Ping timeout: 180 seconds)
# [19:03] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [19:14] * Joins: joone (~joone@public.cloak)
# [19:28] <ato> Can someone explain what an ‘actual viewport’ is in practical terms?
# [19:29] <ato> (https://drafts.csswg.org/css-device-adapt/#the-viewport)
# [19:44] * Quits: Ms2ger (~Ms2ger@public.cloak) (Ping timeout: 180 seconds)
# [19:46] * Joins: tantek (~tantek@public.cloak)
# [19:54] * Quits: tantek (~tantek@public.cloak) (Ping timeout: 180 seconds)
# [20:09] * Quits: bkardell_ (~uid10373@public.cloak) ("Connection closed for inactivity")
# [20:45] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [21:02] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [21:06] * Joins: bcampbell (~chatzilla@public.cloak)
# [21:20] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:30] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [21:37] * Joins: Florian (~Florian@public.cloak)
# [21:45] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [21:58] * Joins: lajava (~javi@public.cloak)
# [22:09] * Quits: bcampbell (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [22:33] * Joins: skk (~skk@public.cloak)
# [22:40] * Joins: bcampbell (~chatzilla@public.cloak)
# [22:40] * Quits: bcampbell (~chatzilla@public.cloak) ("ChatZilla 0.9.92 [Firefox 38.2.0/20150806103657]")
# [22:43] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [22:45] * Joins: skk_ (~skk@public.cloak)
# [22:48] * Quits: skk (~skk@public.cloak) (Ping timeout: 180 seconds)
# [22:52] * Joins: myles (~Adium@public.cloak)
# [22:57] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [22:58] * Quits: rachelandrew (~rachelandrew@public.cloak) (Ping timeout: 180 seconds)
# [23:00] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [23:04] * Joins: antonp (~Thunderbird@public.cloak)
# [23:06] * Quits: antonp (~Thunderbird@public.cloak) (antonp)
# [23:06] * Joins: myles (~Adium@public.cloak)
# [23:07] * Quits: myles (~Adium@public.cloak) ("Leaving.")
# [23:09] * Joins: myles (~Adium@public.cloak)
# [23:16] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [23:17] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [23:22] * Joins: Florian (~Florian@public.cloak)
# [23:24] * Quits: rachelandrew (~rachelandrew@public.cloak) (Ping timeout: 180 seconds)
# [23:25] * Joins: liam (liam@public.cloak)
# [23:26] * Joins: skk (~skk@public.cloak)
# [23:28] * Quits: lajava (~javi@public.cloak) (Ping timeout: 180 seconds)
# [23:31] * Quits: skk_ (~skk@public.cloak) (Ping timeout: 180 seconds)
# [23:33] * Joins: johanneswilm (~johannes@public.cloak)
# [23:37] * Joins: liam_ (liam@public.cloak)
# [23:40] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [23:46] * Quits: Florian (~Florian@public.cloak) (Client closed connection)
# [23:46] * Joins: Florian (~Florian@public.cloak)
# [23:48] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [23:52] * Quits: rachelandrew (~rachelandrew@public.cloak) (Client closed connection)
# [23:52] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [23:53] * Joins: rachelandrew (~rachelandrew@public.cloak)
# [23:53] * Joins: Florian_ (~Florian@public.cloak)
# [23:53] * Quits: Florian (~Florian@public.cloak) (Ping timeout: 180 seconds)
# [23:56] * Quits: adenilson (~anonymous@public.cloak) (adenilson)
# [23:58] * Joins: estellevw (~estellevw@public.cloak)
# Session Close: Thu Aug 27 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn