16:32:31 <RRSAgent> RRSAgent has joined #css
16:32:31 <RRSAgent> logging to http://www.w3.org/2016/05/09-css-irc
16:32:32 <trackbot> RRSAgent, make logs member
16:32:33 <Zakim> Zakim has joined #css
16:32:34 <trackbot> Zakim, this will be Style_CSS FP
16:32:34 <Zakim> ok, trackbot
16:32:35 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:32:36 <trackbot> Date: 09 May 2016
16:32:48 <ChrisL> rrsagent, here
16:32:48 <RRSAgent> See http://www.w3.org/2016/05/09-css-irc#T16-32-48
16:32:51 <gregwhitworth> ScribeNick: gregwhitworth
16:36:50 <Rossen> present+
16:37:14 <gregwhitworth> Topic: Flex
16:37:28 <fantasai> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
16:37:31 <iank_> present+
16:37:41 <gregwhitworth> fantasai: as we mentioned, pretty much everything is fixed
16:37:51 <gregwhitworth> fantasai: we asked for people to review issue 1 and 3
16:38:07 <gregwhitworth> fantasai: we're asking for official resolution of those two, the rest are editorial
16:38:21 <gregwhitworth> fantasai: you're happy to review them. After resolving we would like a CR
16:38:31 <gregwhitworth> fantasai: anyone need more time for issue 3
16:39:28 <gregwhitworth> dbaron: the resolution for issue 3, is it independent of % sizing with intrinsic widths
16:39:33 <gregwhitworth> fantasai: good question
16:39:54 <gregwhitworth> astearns: that is one thing that does not have a time slot, that can be breakout session
16:40:10 <gregwhitworth> dbaron: I just want to make sure that we're not tying this to something that isn't compatible with the web
16:40:23 <gregwhitworth> fantasai: this one I believe is about the intrinsic minimum sizes
16:40:42 <gregwhitworth> florian: is it flex specific
16:40:45 <gregwhitworth> dbaron: no
16:40:57 <gregwhitworth> florian: if there is a side convo please try to include me
16:41:22 <gregwhitworth> hober: if the dependency graph includes the % issue, then we should resolve that first
16:41:39 <gregwhitworth> dbaron: I'm not saying it does, I'm just asking
16:41:55 <gregwhitworth> fantasai: I'm not sure... yeah I think there is somewhat a dependency so we should resolve on those together
16:42:02 <gregwhitworth> fantasai: issue1: a11y wording
16:42:17 <gregwhitworth> Rossen: do we have text for issue 1
16:42:24 <gregwhitworth> fantasai: yes
16:42:42 <fantasai> Note at the bottom of https://drafts.csswg.org/css-flexbox-1/#order-accessibility
16:42:49 <gregwhitworth> dauwhe: are the a11y wg happy with it
16:42:56 <gregwhitworth> fantasai: Cynthia is, she recorded it
16:43:07 <fantasai> s/recorded/reported/
16:46:11 <gregwhitworth> cbiesinger: 2:30 PST we'll talk about % sizing
16:46:20 <gregwhitworth> tabatkins: Greg you had one job
16:46:47 <ekimber> ekimber has joined #css
16:46:54 <gregwhitworth> Rossen: I think the wording is exactly how we decided it, we should be fine. I'll follow up with Cynthia and close the loop with Richard and the rest of the WG
16:47:20 <gregwhitworth> RESOLVED: Issue 1 the text for a11y is accepted
16:47:39 <W3C_> W3C_ has joined #css
16:48:01 <ekimber> ekimber has left #css
16:48:02 <gregwhitworth> Topic: Box Alignment
16:48:22 <gregwhitworth> fantasai: Tab and I went through the spec and updated the baseline alignment stuff to the best of our ability
16:48:31 <gregwhitworth> fantasai: anyone that's interested please take a look at it
16:48:48 <gregwhitworth> fantasai: one issue is whether the justify-content property applies to column boxes
16:48:56 <gregwhitworth> fantasai: the other is the default value of overflow
16:49:14 <gregwhitworth> fantasai: the justify-content in grid it justifies the tracks and in flex it justifies the flex lines
16:49:35 <gregwhitworth> fantasai: gives example of how justify-content works
16:49:50 <gregwhitworth> fantasai: the goal of this spec is to allow alignment to work for all layout models
16:50:09 <gregwhitworth> fantasai: should justify-content apply to the columns or not
16:50:33 <gregwhitworth> tabatkins: no - justify-content can't because it applies to one line of things
16:50:47 <gregwhitworth> florian: it sounds interesting, but do we have any wiggle room
16:50:59 <fantasai> https://drafts.csswg.org/css-align-3/#distribution-block
16:51:01 <gregwhitworth> fantasai: we can say that the normal value is doing what multicol already does
16:51:34 <gregwhitworth> fantasai: for blocks it does nothing for them
16:51:40 <gregwhitworth> florian: it sounds interesting to me
16:51:57 <gregwhitworth> dbaron: It still doesn't make sense to me why it doesn't apply to block
16:52:17 <gregwhitworth> tabatkins: there is only one flow of stuff, so you can't justify it's items - you can justify self
16:52:36 <gregwhitworth> fantasai: if you think in terms of flex, block is like having one flex line
16:52:58 <gregwhitworth> fantasai: there is no line in a block
16:53:11 <gregwhitworth> dbaron: I was confusing justify-content and justify-items
16:54:36 <gregwhitworth> jensimmons: if you specify the width of the col at 200, if we change this would you be able to do this and add the power to keep it at 200 and distribute from that fixed size?
16:54:46 <gregwhitworth> fantasai: yes, this adds power to multi-col
16:54:55 <gregwhitworth> florian: we cover step sizing a little bit later
16:55:05 <gregwhitworth> dauwhe: this makes sense
16:55:21 <gregwhitworth> tabatkins: the mechanics are all there, this just allows you to control those gaps
16:55:31 <gregwhitworth> RESOLVED: Add justify-content to multicol
16:55:44 <gregwhitworth> florian: Now we have column rules in the middle of column gaps
16:55:56 <gregwhitworth> tabatkins: just like grid the things on the side are not gaps
16:56:00 <cbiesinger> fyi justify-content applies to flex items; align-content applies to flex lines
16:56:09 <fantasai> https://drafts.csswg.org/css-align-3/#overflow-values
16:56:11 <gregwhitworth> fantasai: the next issue is the initial handling of overflow alignment
16:56:35 <gregwhitworth> fantasai: we have safe and unsafe keywords, if you say center it will absolutely center it even if that causes it to overflow
16:57:04 <gregwhitworth> fantasai: a lot of times you'll want the centering alignment, but you'll want to keep it inside of the scrollable region
16:57:18 <gregwhitworth> fantasai: the user wants to be able to see the content and they should be able to get to the contnet
16:57:51 <gregwhitworth> fantasai: the initial behavior is to do the unsafe behavior up until you would overflow the unscrollable container and then switch to the safe behavior
16:58:05 <gregwhitworth> dbaron: That is very expensive on the layout engine
16:58:36 <gregwhitworth> dbaron: I would prefer for people to have to ask for the slow path
16:58:57 <gregwhitworth> fantasai: The people that need this won't know they'll need to change this
16:59:10 <gregwhitworth> fantasai: only if you have overflow do you need to relayout this
16:59:21 <gregwhitworth> dbaron: I don't buy that there isn't overflow the majority of cases
16:59:29 <gregwhitworth> dbaron: we can't change the default for block
16:59:41 <gregwhitworth> fantasai: block already does safe alignment
16:59:47 <gregwhitworth> fantasai: this is all new stuff
16:59:58 <gregwhitworth> fantasai: the only legacy is flex box
17:00:05 <MaRakow> MaRakow has joined #CSS
17:00:25 <gregwhitworth> fantasai: once this spec is implemented it will apply to everything and will only work if you set the alignment keywords
17:00:42 <gregwhitworth> esprehn: I want to talk about the feature
17:01:04 <gregwhitworth> esprehn: Someone showed a layout where the content is inaccessible, we need to solve it
17:01:12 <gregwhitworth> dbaron: I prefer safe rather than true for that reason
17:01:27 <gregwhitworth> dbaron: a lot of layout issues deal with how a parent deals with its children
17:01:39 <gregwhitworth> Rossen: once you start nesting you're going to have very bad perf
17:02:00 <gregwhitworth> Rossen: This sounds like a weird position: sticky-ish
17:02:23 <gregwhitworth> tabatkins: This is still scrollable and only goes back if you overflow out of your scrollable bounds
17:02:31 <gregwhitworth> dbaron: I agree with Rossen
17:02:54 <gregwhitworth> Rossen: The benefit of sticky, you can keep it on the compositor and not relayout
17:03:11 <gregwhitworth> shans: This is about the negative bounds, not the scrollable region
17:03:46 <gregwhitworth> Rossen: This is how I understood it, if you begin layout and you center align some items you start overflowing you have to redo layout to fix it
17:03:55 <gregwhitworth> shans: on resize your re-layout anyways
17:04:00 <gregwhitworth> fantasai: draws a diagram
17:04:19 <gregwhitworth> fantasai: explains drawing
17:06:42 <gregwhitworth> fantasai: this is all about the scrollable region, when the shifting occurs and it's outside the scrollable bounds this will change the scrollable bounds to allow the content to be visible
17:07:01 <gregwhitworth> esprehn: the example we had was a video in an iframe and the top was cut off and you could only scroll down
17:07:56 <gregwhitworth> fantasai: if you have a box that is a flexbox and it has a flex item that will have an item that goes into the unscrollable area then you flag it
17:08:08 <gregwhitworth> fantasai: this only occurs when you have overflow in the scrollable direction
17:08:15 <gregwhitworth> florian: is this a third value?
17:08:24 <gregwhitworth> florian: yes it's a third value
17:08:29 <gregwhitworth> tabatkin: it's kind safe
17:08:50 <gregwhitworth> zcorpan_: you want this to happen in any direction right
17:08:53 <gregwhitworth> fantasai: yes
17:09:21 <gregwhitworth> dholbert: this will affect any container with any alignment props set
17:09:33 <gregwhitworth> fantasai: I think you could probably optimize this mostly away
17:09:49 <rniwa> rniwa has joined #css
17:09:50 <gregwhitworth> dbaron: I think in theory that's fine, but it will take 10 years to find all the bugs
17:10:08 <gregwhitworth> fantasai: we would like to put it in the spec and put it at risk, we don't expect it to be implemented soon
17:10:17 <gregwhitworth> fantasai: Our content dependency is with flexbox
17:10:51 <gregwhitworth> fantasai: The change in behavior is bad for the user anyways and may look a little bit worse, but the ones where users can't scroll to see the content will fix this
17:11:24 <gregwhitworth> bradk: Why not just make it so that you can scroll to the content
17:11:33 <gregwhitworth> tabatkins: that's the idea
17:11:58 <gregwhitworth> hober: I don't want an infinite scrollbar because someone positioned something in the infinite direction
17:12:16 <gregwhitworth> dbaron: what UI do you do when the scrollbar position is somewhere random in the middle
17:12:36 <gregwhitworth> bradk: in a non perfect world it seems like a good solution
17:12:47 <hober> s/in the infinite direction/way out on the left for cargo cult a11y reasons/
17:13:03 <gregwhitworth> dbaron: I looked into implementing it about 10 years ago and realized that it was too much of a compat risk
17:13:13 <gregwhitworth> zcorpan_: it would need to be opt in
17:13:26 <gregwhitworth> tabatkins: people use negative margins to hide stuff off the document
17:13:33 <gregwhitworth> fantasai: any other comments
17:13:56 <gregwhitworth> dholbert: maybe an idea to work out later, but relpos/abspos would need to be taken into account
17:14:27 <gregwhitworth> Rossen: the point is you should not start in a positive, safe will take you to the origin of that box, we don't want to move content
17:14:37 <gregwhitworth> fantasai: we'll make you less unsafe until you're safe
17:14:57 <gregwhitworth> florian: if you make this the default and at risk, please be clear in the spec what to do if you're not willing to implement this
17:15:13 <gregwhitworth> tabatkins: we still need a name
17:15:16 <gregwhitworth> Rossen: unsafish
17:15:21 <gregwhitworth> Rossen: scrollport
17:15:34 <gregwhitworth> fantasai: does that sound like a reasonable plan?
17:15:44 <gregwhitworth> tabatkins: default to unsafe and put it at risk
17:15:49 <gregwhitworth> dbaron: what happens to flex
17:16:09 <gregwhitworth> fantasai: it will cause a behavior change where items are aligned that are not within the scrollable area
17:16:16 <gregwhitworth> fantasai: this will probably fix
17:16:21 <gregwhitworth> dbaron: I'm not sure I buy that
17:16:36 <gregwhitworth> fantasai: but it only affects things that are aligning items into unscrollable regions
17:16:56 <gregwhitworth> esprehn: every time we change flex, we get yelled at - let's change and see how loud the yell is
17:17:12 <gregwhitworth> hober: also put a note that if you change and get yelled at let us know
17:17:37 <gregwhitworth> RESOLVED: Put it into the spec, put at risk with a note saying to contact specs if you hear from authors regarding compat
17:17:49 <gregwhitworth> fantasai: we'll publish next week
17:17:55 <gregwhitworth> fantasai: probably
17:18:59 <gregwhitworth> dbaron: How much do we need to add to custom layout to make that work in Houdini
17:19:38 <gregwhitworth> Rossen: not much I think, you would need to add the origin and it's nearest ancestor
17:19:51 <gregwhitworth> Rossen: you're always avoiding the origin for scrolling purposes
17:19:52 <fremy> fremy has joined #css
17:19:59 <gregwhitworth> iank: I'm trying to catch up
17:20:10 <gregwhitworth> dbaron: I think if the nearest scroller is in another writing mode
17:20:15 <gregwhitworth> Rossen: it still has an origin
17:20:19 <gregwhitworth> dbaron: ok you're right
17:20:33 <gregwhitworth> Rossen: it's implementable
17:20:43 <gregwhitworth> Rossen: Now that I understand it, it's not that scary
17:21:27 <glazou> glazou has joined #css
17:21:33 <shane> https://staging.talkgadget.google.com/hangouts/_/google.com/dknox
17:21:40 <shane> ^ hangouts link to "dial in"
17:21:56 <gregwhitworth> Topic: Grid
17:22:40 <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917
17:23:16 <gregwhitworth> Tabatkins: we have a couple things that we need approval first
17:23:43 <gregwhitworth> tabatkins: abspos items in degenerative grids
17:24:33 <gregwhitworth> tabatkins: the question here was what to do when you have a grid with no tracks whatsoever and how to place abspos items as a result, they care where the grid is
17:24:58 <gregwhitworth> tabatkins: there is no grid items, just some abspos and the grid has one grid line but no tracks, where should this line be
17:25:13 <gregwhitworth> tabatkins: the spec says it's against the start edge in both axis
17:25:30 <gregwhitworth> astearns: does anyone have any issues?
17:25:40 <gregwhitworth> astearns: any objections?
17:25:46 <gregwhitworth> hober: what do the implementations do
17:25:52 <gregwhitworth> tabatkins: don't know
17:26:07 <gregwhitworth> RESOLVED: Keep the spec the way it is
17:26:21 <gregwhitworth> tabatkins: the repeat function with auto-fit and auto-fill keywords
17:26:46 <fantasai> astearns, Rossen - should probably add https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-20 to the sizing task force breakout
17:26:55 <gregwhitworth> tabatkins: if you have 1000px to work with and auto-fit with 10tracks it will adjust accordingly, with auto fill and you don't have enough columns it will drop them
17:27:05 <gregwhitworth> tabatkins: which columns should you drop
17:27:21 <gregwhitworth> tabatkins: these columns in the middle are not being used, do you drop them?
17:27:40 <gregwhitworth> tabatkins: we don't have a strong opinion on this, currently it's defined at the end
17:27:58 <gregwhitworth> fantasai: we spec it currently based on what's implemented
17:28:40 <gregwhitworth> jensimmons: correct me if I'm wrong, I want empty columns in the middle and they don't want them to go away
17:28:58 <gregwhitworth> fantasai: no this is for the auto-fill not auto-fit within the repeat() syntax
17:29:31 <gregwhitworth> fantasai: I just want to get what I've defined
17:29:41 <gregwhitworth> s/fantasai/jensimmons
17:29:46 <gregwhitworth> fantasai: we'll do that
17:30:30 <gregwhitworth> fantasai: but sometimes when you want to center columns and that contradicts with the amount of columns available, do you drop the tracks at the end and middle, or just the end
17:30:48 <gregwhitworth> fantasai: can anyone come up with a usecase and behavior that people prefer?
17:31:04 <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-24
17:31:29 <gregwhitworth> tabatkins: unless anyone has any strong opinion, we'll keep it the way the spec is
17:31:41 <gregwhitworth> tabatkins: which is to drop all empty tracks
17:32:11 <gregwhitworth> dholbert: the countintuitive part is you can have something in col1 and col10 and then remove all the empty ones when you wanted them apart
17:32:19 <gregwhitworth> RESOLVED: Keep spec as is
17:32:28 <dholbert> dholbert has joined #css
17:32:33 <fantasai> https://drafts.csswg.org/css-grid-1/issues-wd-20150917#issue-39
17:32:57 <gregwhitworth> tabatkins: the counterintuitive part is why you would ask for auto generated rows and then explicitly set them into cols
17:33:08 <gregwhitworth> fantasai: we need very competent people to take a look at this one
17:33:14 <gregwhitworth> astearns: anyone?
17:33:37 <gregwhitworth> tabatkins: we think the spec is correct, but we would like for someone to take a look
17:33:44 <gregwhitworth> tabatkins: Rossen was voluntold
17:33:55 <gregwhitworth> ACTION Rossen to review issue 39 of the grid spec
17:33:55 <trackbot> Created ACTION-768 - Review issue 39 of the grid spec [on Rossen Atanassov - due 2016-05-16].
17:34:13 <gregwhitworth> Topic: Subgrid
17:34:41 <gregwhitworth> tabatkins: The previous position on subgrid was complex so we removed it, that said there are usecases that can't be done in current grid
17:35:10 <gregwhitworth> tabatkins: so we've put together a much simpler proposal that covers the majority of usecases
17:35:22 <fantasai> http://meyerweb.com/eric/thoughts/2016/01/15/subgrids-considered-essential/
17:35:26 <gregwhitworth> fantasai: here's the feedback we got on subgrid
17:35:29 <fantasai> http://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/
17:35:43 <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Jan/0141.html
17:36:11 <gregwhitworth> fantasai: what are the things we need to address and how simple can we get it
17:36:14 <jensimmons> Rachel Andrew on subgrid, her response: https://rachelandrew.co.uk/archives/2016/04/25/a-revised-subgrid-specification/
17:36:30 <gregwhitworth> fantasai: there were things we could get rid of, the subgrid auto sizing itself based on its contents
17:36:49 <gregwhitworth> fantasai: you can't have any overflow tracks in the subgrid, you can have overflowing content however
17:36:59 <gregwhitworth> fantasai: it won't affect the sizing of the parent grid however
17:37:17 <gregwhitworth> tabatkins: shows example of the subgrid
17:37:27 <fantasai> Current proposal - https://lists.w3.org/Archives/Public/www-style/2016Apr/0254.html
17:38:25 <gregwhitworth> tabatkins: you declare an item to be a subgrid by giving it display: subgrid
17:38:46 <gregwhitworth> tabatkins: this makes it a grid container but grid-template-columns/rows do nothing on it
17:39:01 <gregwhitworth> tabatkins: the children on the subgrid position on the parent's grid
17:39:08 <gregwhitworth> tabatkins: the subgrid still lays out
17:40:58 <W3C_> W3C_ has left #css
17:41:02 <W3C_> W3C_ has joined #css
17:41:27 <gregwhitworth> tabatkins: the margin/padding/border they get applied accordingly magically to apply the declared amount
17:42:01 <gregwhitworth> florian: I assume this does the right thing no matter the writing mode
17:42:05 <gregwhitworth> tabatkins: yes
17:42:14 <gregwhitworth> tabatkins: it works the same way in nested subgrids
17:42:29 <gregwhitworth> tabatkins: You can not get implicit tracks from the subgrid
17:42:43 <gregwhitworth> florian: can you use display: contents
17:43:00 <gregwhitworth> tabatkins: sure, if you don't need a wrapper at all, then use display: contents
17:43:09 <gregwhitworth> tabatkins: you can't set grid gaps on a subgrid
17:43:24 <gregwhitworth> florian: anyone implementing grid not implementing display: contents?
17:43:41 <gregwhitworth> tabatkins: we plan to, FF has an implementation of it, webkit has a proto I think
17:43:49 <gregwhitworth> florian: I'll write a blog post
17:44:05 <gregwhitworth> florian: to convince everyone to implement display: contents
17:44:10 <gregwhitworth> tabatkins: that's the proposal
17:44:33 <nvdbleek> nvdbleek has joined #css
17:44:41 <gregwhitworth> tabatkins: does the WG feel this is a good direction to with
17:44:47 <gregwhitworth> tabatkins: overflow still applies
17:45:05 <gregwhitworth> astearns: you were going to go over the single dimension case that this doesn't support
17:45:07 <gregwhitworth> tabatkins: right
17:45:39 <gregwhitworth> tabatkins: let's say you have a subgrid and your parent is 2x2 square but you don't care about the rows of the parent's grid
17:45:54 <gregwhitworth> tabatkins: and you don't know how many rows itself will have
17:46:28 <gregwhitworth> tabatkins: this particular case is easy to hit with HEADER, CONTENT, FOOTER and then you want to fill in the content with your catalog items
17:46:39 <gregwhitworth> tabatkins: however, this makes it very complicated to handle
17:47:13 <gregwhitworth> tabatkins: the case is relatively small, and you can use a nested grid to allow for this
17:47:26 <gregwhitworth> tabatkins: if people demand a lot of this we may try to address it in the future
17:47:49 <gregwhitworth> Rossen: By current subgrid proposal, this is not possible?
17:47:55 <gregwhitworth> tabatkins: yes, it can't work
17:48:32 <gregwhitworth> Rossen: good, I think this keeps it quite simple and keeps the mental model of the grid in tact
17:48:47 <gregwhitworth> florian: have you heard from the authors
17:49:31 <gregwhitworth> fantasai: yeah, I think this addresses the majority of the issues. But wanting to interleave the subgrid lines with the parents lines is very hard but is not covered here
17:50:00 <gregwhitworth> fantasai: there is an issue we marked, subgrid only takes affect if it is a grid item and the grid-template props are set
17:51:05 <gregwhitworth> fantasai: This gives us an extension point that allows us to use subgrid to ensure that the grid props are set to none which they don't affect and later may affect it in the future it could break it
17:51:27 <gregwhitworth> fantasai: the goal of adding the condition is so that the grid WILL break so that we can improve subgrid later
17:51:57 <gregwhitworth> astearns: what do you do in this case then?
17:52:06 <gregwhitworth> fantasai: maybe just treat it as block
17:52:50 <gregwhitworth> dbaron: you're intentionally make it not work unless things are set for extension later then we need to state it in the spec and then also suggest implementations give console warnings
17:53:10 <gregwhitworth> dholbert: we risk authors being ok with the "broken" behavior
17:53:11 <dbaron> s/we need to state/you should say so/
17:53:59 <gregwhitworth> florian: there's always a risk of that, but grid is so central to your layout that I think if it breaks then we won't have as much compat risk
17:54:13 <W3C_> W3C_ has left #css
17:54:16 <W3C_> W3C_ has joined #css
17:54:24 <Rossen> s/mental model of the grid in tact/mental model of the grid in tact and symmetric/
17:54:29 <gregwhitworth> astearns: if people do depend on it, we would need to come up with another way to solve it
17:54:48 <ekimber> ekimber has joined #css
17:54:53 <gregwhitworth> astearns: we basically heard from all implementors saying subgrid this is crazy, have thoughts changed
17:55:09 <gregwhitworth> tabatkins: Igalia said their opinion on the list
17:55:32 <cabanier> cabanier has joined #css
17:55:50 <gregwhitworth> dholbert: I spoke to Mats, and he feels this is still complex as you need to keep track of overflow for the items
17:56:09 <gregwhitworth> fantasai: we would be ok with computing overflow to visible always if that is a concern
17:56:16 <gregwhitworth> tabatkins: another issue is paint order
17:56:34 <gregwhitworth> fantasai: I expect authors to be able to control z-index from within
17:56:49 <gregwhitworth> dholbert: with that change, it may make it simpler
17:57:02 <gregwhitworth> fantasai: you won't have to keep track of scrollers, etc
17:57:26 <gregwhitworth> dbaron: z-index also applies to all graphical stuff as well, masks, transforms, etc
17:57:50 <gregwhitworth> fantasai: I think everything should just work unless stated otherwise
17:58:01 <gregwhitworth> dbaron: this is odd that it's basically an element that doesn't have a box
17:58:21 <gregwhitworth> dbaron: this is similar to an element that doesn't have a box
17:58:29 <gregwhitworth> tabatkins: we're getting more explicit about the box
17:58:49 <gregwhitworth> dbaron: but does the spec on filters or mask define whether this applies to elements or boxes, thus would impact a subgrid
17:59:17 <gregwhitworth> esprehn: I don't think we should have another table row problem again
17:59:47 <gregwhitworth> fantasai: I agree, it should get a box and we will on purpose exclude stuff from it to ease implementer complexity
17:59:55 <gregwhitworth> dbaron: so it gets a box?
17:59:59 <gregwhitworth> fantasai: yes
18:00:20 <gregwhitworth> dbaron: this is well defined how the positioning/margin/border/padding
18:00:24 <gregwhitworth> tabatkins: yes
18:01:29 <gregwhitworth> jensimmons: I am an author and feel very strongly that subgrid should be included with grid, and I'm hoping that this is simple enough to ship it
18:01:46 <Rossen> plinss, so you're saying that for layout purposes the subgrid is considered empty but has a size independent of its children sizes?
18:02:04 <gregwhitworth> jensimmons: from my experience they're going to be very confused that they can't align everything to the parent grid
18:02:32 <gregwhitworth> jensimmons: I'm not sure this will cover all use cases, mainly because haven't had the time to play with it
18:03:07 <gregwhitworth> jensimmons: in most cases they're going to be thinking about the explicit grid, not the implicit grid and I hope that this is simple enough that vendors will implement this
18:03:25 <gregwhitworth> fantasai: I think we can resolve that overflow is at risk and say it computes to visible
18:03:35 <gregwhitworth> astearns: so an at-risk within the at-risk section
18:03:49 <gregwhitworth> astearns: is there anything more people want to add
18:03:59 <bradk> @risk { @risk{ }  }
18:04:13 <gregwhitworth> RESOLVED: subgrid proposal accepted in the at-risk section
18:04:45 <astearns> 15 minute break
18:12:22 <glazou> glazou has joined #css
18:15:15 <ekimber> ekimber has joined #css
18:15:55 <plh> plh has joined #css
18:29:19 <glazou> glazou has joined #css
18:29:59 <bradk> bradk has joined #css
18:32:18 <shane> ScribeNick: shane
18:33:44 <Florian> Florian has joined #css
18:33:52 <ekimber> ekimber has joined #css
18:34:24 <shane> Topic: counters
18:34:38 <shane> TabAtkins: ran into a fun example, author commented on what he thought was a mistake in list spec
18:34:56 <shane> TabAtkins draws a diagram
18:35:11 <SimonSapin> shane, or someone: can you move the camera?
18:35:24 <fantasai> Tab writes:
18:35:28 <fantasai> <ol>
18:35:29 <SimonSapin> great, thanks
18:35:30 <fantasai>   <li>
18:35:31 <fantasai>   <li>
18:35:32 <fantasai> </ol>
18:35:35 <fantasai> <div>
18:35:37 <fantasai>   <ol>
18:35:39 <fantasai>     <li>
18:35:42 <fantasai>   </ol>
18:35:45 <fantasai> </div>
18:35:53 <shane> TabAtkins: interesting thing is if you manually set up counters
18:36:04 <shane> TabAtkins: ..and use the counters function
18:36:24 <shane> dbaron: You're supposed to counter reset on ol:before, not ol. I think that avoids the bug you're about to describe.
18:36:27 <shane> TabAtkins: IT DOES!
18:36:32 <shane> <the crowd goes wild>
18:36:59 <SimonSapin> dbaron: even if ::before has display: none?
18:37:00 <shane> TabAtkins: So we should just adjust the spec to say ol:before instead of ol
18:37:05 <shane> dbaron: assuming :before exists though
18:37:36 <SimonSapin> or content:none
18:37:50 <shane> TabAtkins: counter established by reset on first ol counts its siblings until the first one that resets
18:38:00 <shane> but the next ol is a cousin, so it nests instead
18:38:06 <shane> s/but/..but/
18:38:09 <ChrisL> ChrisL has joined #css
18:38:24 <shane> TabAtkins: few ways around it. (1) instead counter-reset on first li or on :before. Then scope only covers lis
18:38:45 <shane> ..(2) explicitly resetting a counter when it came from something that wasn't in ancestor chain then reset instead of nesting
18:39:05 <shane> Florian: wouldn't that fail with headings?
18:39:10 <shane> TabAtkins: no?
18:39:13 <shane> dbaron: yes/
18:39:14 <shane> ?
18:40:23 <dbaron> dbaron: the rule is that a later sibling replaces an earlier sibling's counter, but not if it's a descendant of the later sibling
18:41:26 <shane> Florian: if you're using heavy sectioning content then you've got nesting and it'd probably break
18:41:31 <shane> s/Florian/Tab/
18:41:39 <shane> dbaron: with sections you should be fine, as long as sections & headings line up
18:42:32 <shane> dbaron: was another problem, solution was counter-set property
18:42:36 <shane> .. don't remember the probem
18:43:04 <shane> TabAtkins: value attribute on li. Already in spec.
18:43:21 <shane> dbaron: was trying to remember if other problem relates to this one, it doesn't.
18:43:55 <shane> ekimber: Q: what's the use case for having the counter apply to following siblings?
18:44:35 <shane> TabAtkins: headings. You set up one counter at the top of the document and run it right down through the whole thing. If you have a flat document structure where headings are siblings then you can reset H1 and H2 counters, which will operate until next H1, next H2, etc.
18:44:41 <shane> dbaron: you reset your H2 counter *at* your H1
18:44:54 <shane> ekimber: given that, response would be "HTML is broken, so what"
18:44:59 <shane> ekimber: so this is user error.
18:45:15 <shane> ..this is an unavoidable consequence of having to support this flat list
18:45:28 <shane> TabAtkins: not necessarily, only if you want to support *all* of what HTML can do
18:45:53 <shane> TabAtkins: if you have an H1 as a child of body, and a div wrapper around the H2 that sets up a subsection
18:46:05 <shane> .. then that would break with the suggestion I'm making
18:46:13 <astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0364.html
18:46:35 <shane> ekimber: implication seems to be - be consistent, otherwise things will mess up
18:46:46 <shane> Florian: also the header element, can use for header of page OR title w. subtitle
18:46:47 <Zakim> Zakim has left #css
18:46:53 <shane> .. not consistent, so nesting will be varying
18:47:11 <shane> esprehn: this change would be observable, right?
18:47:50 <shane> ..ol resets the counter. If you put the value attribute on an li which lets you explicitly number, then there's a reset there too
18:47:55 <shane> dbaron: that's a set
18:48:00 <shane> TabAtkins: something something bug
18:48:08 <shane> esprehn: does anyone implement?
18:48:27 <shane> ..we support counter but both value and reset are the same. So doing this changes the behaviour
18:48:34 <shane> TabAtkins: but current behaviour is very unexpected
18:48:56 <shane> dbaron: <li><li><li value=5> - counter value inside each one, without set you'd have 1, 2, 2.5
18:49:06 <shane> TabAtkins: so yeah it'll fix it to 1, 2, 5, which is actually good
18:49:16 <shane> Florian: given earlier thing with header, does that rule out solution?
18:49:32 <shane> TabAtkins: makes it less attractive. Another option: add a property to counter-reset or another property that changes scope
18:49:43 <shane> .. to descendants only instead of descendants & siblings
18:49:51 <shane> .. problem with :before is that it may not get created.
18:49:58 <shane> dbaron: I like the new value or property idea
18:50:13 <shane> plinss: putting the :before rule with reset property doesn't trigger :before?
18:50:15 <shane> TabAtkins: nope
18:50:50 <zcorpan_> "This specification does not yet define the CSS-specific rules for rendering li elements, because CSS doesn't yet provide sufficient hooks for this purpose."  https://html.spec.whatwg.org/multipage/rendering.html#lists
18:50:51 <shane> zcorpan_: Q: is it possible with counter spec to specify how <ol> and <li> are supposed to work?
18:51:00 <shane> TabAtkins: you can as long as nesting isn't observable
18:51:10 <shane> ..except for reverse
18:51:25 <shane> ..but if nesting is exposed somehow then the naive mapping is wrong and can't be done in CSS
18:51:40 <shane> zcorpan_: I think we should make the counter spec usable by <ol>, <li>
18:51:42 <shane> TabAtkins: Yup
18:51:44 <shane> fantasai: Yup
18:52:06 <shane> TabAtkins: shall we go with the idea of a new value or property that scopes only to descendants?
18:52:27 <TabAtkins> ol > :first-child
18:52:35 <zcorpan_> including <ol reversed> (ideally)
18:52:42 <shane> Florian: but we can just ol :first-child { counter-reset: blah }
18:53:08 <shane> Tab draws a waaay better diagram
18:53:47 <fantasai> scribenicK: fantasai
18:53:58 <fantasai> Florian: So one proposal was use ::before if it exists, or :first-child of the list
18:54:04 <fantasai> Florian: to reset the counter
18:54:20 <fantasai> TabAtkins: It works for HTML, but it is weird overall, because you have to be concerned with the first child who is being set
18:54:30 <fantasai> TabAtkins: Setting on the container is much cleaner
18:54:42 <fantasai> TabAtkins: So one proposal is to cut counter [...]
18:54:53 <shane> https://usercontent.irccloud-cdn.com/file/HwvTalBE/IMG_20160509_115341.jpg
18:54:57 <fantasai> TabAtkins: Better one from dbaron is we have some syntax for indicating on counter-reset that counter will only scope to its descendants
18:55:09 <fantasai> TabAtkins: The counter would then end its scope at the end of the </ol>
18:55:20 <fantasai> Florian: Seems a lot cleaner, but worried it will be very obscure and nobody would know about it
18:55:36 <fantasai> Florian: Is it better to have a simple system with ::before or a complex system with lots of switches?
18:55:37 <shane> ScribeNick: shane
18:55:51 <shane> TabAtkins: wouldn't have designed counters this way
18:56:20 <shane> fantasai: one use case that should work - sometimes you start a list, then close and want to continue later
18:56:28 <zcorpan_> <ol start>
18:56:38 <shane> dauwhe: this is super important for us
18:57:03 <shane> Florian: can't just use a class?
18:57:10 <shane> TabAtkins: need to establish counter in ancestor
18:57:37 <shane> dbaron: Dave: does it sound OK if browsers implement list numbering using counters, you could do it by having a div higher up that contains all the lists you want to number together
18:57:49 <shane> ..explicitly resetting list counter on that div, then removing on individual lists. Would this work for you?
18:58:01 <shane> dauwhe: that makes sense to me and I think I can explain it OK to people too
18:58:13 <shane> TabAtkins: this is explicitly what we use in the flex algo
18:58:34 <shane> .. multiple OLs crossing sections that number subsequently, put a counter on body and use that one instead
18:58:53 <shane> Florian: either if we have a simple but surprising system, or a complex system, people aren't going to understand and will need to look at stack overflow
18:59:04 <shane> TabAtkins: can put into UA stylesheet and make prominent in spec
18:59:11 <shane> .. if you're doing headings, do it like this, etc.
18:59:21 <shane> Florian: probably cleaner with complex but unsurprising system
18:59:32 <shane> fantasai: if it's a syntactic switch then it'll be in the spec
18:59:47 <shane> .. people who are using counters are going to look it up. It'll be fairly obvious
18:59:52 <shane> .. so add a keyword to counter-reset?
19:00:10 <shane> TabAtkins: can't extend counter-reset. It's multi-valued without commas between each value
19:00:22 <shane> .. can't tell whether a keyword is a second counter or not
19:01:07 <shane> Florian: so multiple counters, might want to scope each one differently. So need a list in the p'lel property too?
19:01:27 <shane> fantasai: can have a second property which does the same as counter-reset but with the other behavior. OR a property that switches the behavior.
19:01:36 <shane> dbaron: want other options too, in particular reversing
19:01:51 <shane> TabAtkins: currently can't be expressed in the counter model
19:02:57 <shane> RESOLVED: add new syntax to control counter scoping and consider reversing too.
19:03:40 <dbaron> (Tab to propose syntax)
19:03:48 <zcorpan_> (This needs to be directly usable by HTML spec's UA stylesheet for <ol>, <ol start>, <li value>, <ol reversed>...)
19:03:50 <teoli> teoli has joined #css
19:04:02 <shane> (discussion about resolutions, resolution reversion, and contradictions)
19:04:34 <dbaron> (and counter-resolutions)
19:04:38 <shane> Topic: values and units
19:05:12 <shane> TabAtkins: say you have a background image 'url(#svgfrag)'
19:05:19 <shane> ..clearly points to something local
19:05:26 <shane> ..once you absolutize(sp?) the url
19:05:38 <shane> ..notice it points to same doc, go find it, everything's cool
19:05:53 <zcorpan_> history.pushState()
19:05:56 <shane> ..but say you do push-state to update the URL, the page changes it's URL
19:06:07 <shane> .. we don't go an re-absolutize the images
19:06:16 <shane> ..(in all browsers, interoperably)
19:06:17 <zcorpan_> or insert a <base href>
19:06:30 <SimonSapin> this is an inline stylesheet, right?
19:06:33 <shane> ..so that's an issue. pushState means the reference is no longer local.
19:06:42 <SimonSapin> <style> not <link>
19:06:53 <shane> dbaron: why didn't that change when the document's URI changes?
19:07:06 <shane> TabAtkins: because everyone absolutizes at parse time and nobody changes it.
19:07:10 <shane> fantasai: can't we fix it?
19:07:15 <shane> TabAtkins: No. It's good behavior.
19:07:45 <shane> .. if the ref is relative to to the slash path then pushState that just changes local position in doc tree would result in local references being probably wrong.
19:07:56 <rniwa> rniwa has joined #css
19:08:03 <shane> ..if you start out at http://example.com and reference foo.svg
19:08:13 <shane> ..then pushState to http://example.com/startMyApp/
19:08:26 <shane> ..then we're now referencing http://example.com/startMyApp/foo.svg, which probably doesn't exist
19:08:31 <shane> ..so don't want to update in this case.
19:09:01 <shane> fantasai: this is super messed up. Could have 2 different refs to same target that point to different things because of statefulness of pushState
19:09:25 <shane> zcorpan_: I think it's too expensive to re-resolve all the urls in the universe when a pushState happens
19:09:43 <shane> plinss: if you pushState to a new URL then you should be able to reload from that URL and get back to exactly the same state
19:09:59 <shane> TabAtkins: in practice doesn't always work, and can use middleware to fix the problem anyway
19:10:17 <shane> plinss: not concerned about case where middleware masks a bug
19:10:29 <shane> TabAtkins: I don't think it's a bug that you should have to rewrite references on pushState
19:10:42 <shane> plinss: but it is a bug that you can't reload a pushState and get back to the same state
19:11:01 <shane> ..I want to see data that we can't fix that bug
19:11:11 <shane> TabAtkins: someone should say we *can* do it frst
19:11:35 <shane> ..it's an HTML problem
19:11:43 <shane> plinss: it's a cross-spec problem really
19:12:07 <shane> zcorpan_: from browser vendor's POV the burden of proof is in other direction. Won't risk breaking pages without data saying it won't break pages.
19:12:22 <shane> plinss: if it was a minor change that's fine. But fundamental architectural issue so different stance.
19:12:59 <shane> hober: would love to see data on compat issue, but given that absent data implementors are unlikely to change, who's volunteering to collect data?
19:13:33 <shane> TabAtkins: want to move on to issue. Not absolutizing is bad for local references that become remote.
19:14:59 <shane> ..so e.g. pushState from http://example.com to http://example.com/foo. #svgFrag no longer resolves as local because the URLs don't match.
19:15:35 <shane> ..my proposal: '#' is a very clear indication that you're doing a local reference. So if a url is JUST a hashref then we store state that indicates the reference is definitely local, and never absolutize.
19:15:48 <shane> ..if we can solve the more general problem then we don't need to do this
19:15:59 <shane> plinss: sounds like a hack on a hack
19:17:34 <shane> (a general rehashing occurs. Rehashing. Hah)
19:18:05 <shane> astearns: if there is a compat issue with fixing this the right way, isn't this going to trigger that too?
19:18:14 <shane> TabAtkins: no. This definitely always wants to be local.
19:18:44 <shane> Florian: but it's not clear for files because you don't know whether they want to be relative or relative relative
19:19:04 <shane> hober: are you proposing that hidden state be exposed to CSSOM? Or via syntax to explicitly opt in? Or via URL object?
19:19:33 <zcorpan_> SGTM
19:19:33 <shane> TabAtkins: currently just if URL string starts with '#'. Can detect by asking for computed value because it should serialize back to just a '#' instead of abs value for round tripping purposes.
19:20:12 <shane> plinss: in general, TAG is facing another issue where we need to assign additional information to a URL to make it useful. Tim hates this. Fundamentally URLs should be standalone, without magic. This is going to <elided> Tim.
19:20:40 <shane> TabAtkins: could introduce new function that is identical to url but only accepts local references.
19:20:51 <shane> .. but that doesn't fix existing pages.
19:21:10 <shane> .. or upon parsing this could computed value to local only function.
19:21:15 <shane> plinss: yuck.
19:21:28 <shane> .. shouldn't make an assumption based on presence or absence of parts of the url
19:21:35 <shane> TabAtkins: couple of options, need to fix it somewhere.
19:21:48 <shane> .. (A) get DOM to fix everything
19:21:53 <shane> .. (B) hidden state on urls
19:22:00 <shane> .. (C) new local-only url function
19:22:17 <shane> fantasai: how is that better than fixing A?
19:22:23 <shane> TabAtkins: because A will break things
19:23:05 <shane> .. e.g. your URL is "foo.svg" and you pushState to something with a different URL segment then your page will break
19:23:12 <shane> plinss: but right now it'll break on reload anyway
19:23:50 <shane> TabAtkins: we should decide on (A) assume DOM will fix everything and make no change or (B) make *some* sort of change
19:24:02 <shane> fantasai: Whatabout (C) try to get (A) to work and in the meantime do (B)
19:24:42 <fantasai> s/(C)/(D)/
19:25:22 <shane> fantasai: I prefer (D)
19:25:34 <shane> astearns: me too, but I don't know how fixing the actual problem is going to happen?
19:25:47 <shane> hober: comes back to: "who's going to provide the data"? Haven't heard any volunteers
19:26:18 <shane> fantasai: if you do it correctly, relative URLs aren't going to change unless you wanted them to change. If you're depending on the broken-ness then it's going to change and you'll need to fix your URLs.
19:26:54 <shane> plinss: I'll file (A) as an issue with the TAG. It's bigger than CSS.
19:27:35 <shane> astearns: does anyone object to pursuing a temporary solution while that happens?
19:28:26 <fantasai> Proposed resolution: Make local fragment URLs magically always relative; file issue against TAG to fix this generally.
19:28:45 <shane> Florian: (B) is a temporary solution that silently disappears if we fix (A) so it's better than (C)
19:28:52 <shane> fantasai: yeah, agreed.
19:29:43 <shane> plinss: I'd rather have a different function - i.e. (C)
19:29:59 <shane> Florian: why would you prefer a different function?
19:30:18 <shane> plinss: so you can say what you mean. getElementByID should be a new thing, not the existing thing.
19:30:37 <shane> .. and the parameter should be an ID, not a URL fragment
19:30:52 <shane> hober: I think Tab's saying that functionally, fragment references currently are getElementByID.
19:31:07 <shane> esprehn: right. It's already live in that we can swap out elements and the reference updates.
19:31:10 <hober> s/Tab's saying/esprehn's saying/
19:32:46 <shane> zcorpan_: special casing URLs with only a fragment already exists. Navigating special-cases fragment changes vs. other changes.
19:33:10 <shane> Florian: in this case we specialize fragment behavior to do the right thing. So fixing behavior in the subcase. i.e. like (B).
19:33:37 <shane> dbaron: one of the other cases for having something that isn't url function is to be able to move styles that reference an ID in a document into an external stylesheet.
19:33:53 <shane> .. we added an element() function as an image value. Is basically this.
19:34:07 <shane> TabAtkins: element() might be a reasonable choice then.
19:34:48 <shane> hober: this is a garbage fire. Browsers screwed up AND authors screwed up. (B) seems reasonable then but both plinss and dbaron have made reasonable arguments for adding (C) *as well*.
19:35:46 <shane> ChrisL: SVG has a concept of a URL that's restricted to the local document. Originally had idref but the TAG told us to stop
19:35:50 <rego> rego has joined #css
19:36:39 <shane> TabAtkins: current proposal. Add hidden state to URL *and* make sure element() can be used to just refer to local references
19:37:00 <shane> hober: little unsure about expanding element beyond existing use as an image source. Probably fine.
19:37:49 <shane> ACTION: Peter Linns to file an issue against the TAG to fix the general pushState / url reference problem
19:37:49 <trackbot> Created ACTION-769 - Linns to file an issue against the tag to fix the general pushstate / url reference problem [on Peter Linss - due 2016-05-16].
19:38:55 <shane> RESOLUTION: Add hidden state to hash-refernce-only URLs so that they can always resolve locally in presence of pushState
19:41:00 <shane> RESOLUTION: Adapt the element() function so that it can be used to refer to always-local references
20:03:32 <astearns> (lunch, resume at 1:40)
20:06:24 <myles2> myles2 has joined #css
20:08:05 <MaRakow> MaRakow has joined #CSS
20:12:43 <ChrisL> ChrisL has joined #css
20:15:28 <MaRakow_> MaRakow_ has joined #CSS
20:17:50 <Florian> Florian has joined #css
20:17:53 <Florian> Florian has joined #css
20:23:23 <bradk> bradk has joined #css
20:25:46 <myles1> myles1 has joined #css
20:27:07 <ekimber> ekimber has joined #css
20:32:37 <zcorpan> zcorpan has joined #css
20:42:23 <dauwhe> scribenick: dauwhe
20:43:10 <astearns> let's resume
20:43:28 <zcorpan> zcorpan has joined #css
20:43:28 <ekimber> ekimber has joined #css
20:43:31 <plh> plh has joined #css
20:43:42 <dauwhe> HEY EVERYONE WE'RE STARTING
20:44:19 <dauwhe> Topic: Media Queries
20:44:34 <dauwhe> astearns: overflow stuff isn't prepared yet, is there anything else?
20:44:48 <Florian> Florian has joined #css
20:44:49 <dauwhe> ... the other topic is flexbox, but we're waiting until 2:30
20:45:44 <dauwhe> Florian: we can try to do MQs
20:46:02 <dauwhe> ... one mq thing is also about colors
20:46:21 <dauwhe> ... light level media query?
20:46:26 <dauwhe> fantasai: we resolved to defer
20:46:39 <dauwhe> Florian: Simon said that he might not like it at all
20:46:53 <dauwhe> ... since it's been in spec for a while, I'd like to hear the objection
20:47:02 <jensimmons> jensimmons has joined #css
20:47:05 <dauwhe> myles: first objection: fingerprinting
20:47:16 <dauwhe> ... a website will know if i'm outside or inside
20:47:22 <dauwhe> ... second is that it's an OS thing
20:47:32 <dauwhe> ... third, OS has night mode that might interfere
20:47:42 <dauwhe> Florian: for the 3rd thing, I don't think it would fight
20:47:56 <dauwhe> ... given the adjustments already made, are we in a mode that needs boosting?
20:48:09 <dauwhe> ... you have to take into account the display and the environment
20:48:18 <dauwhe> ... lcd would be different than e-ink
20:48:18 <fantasai> https://lists.w3.org/Archives/Public/www-style/2016Mar/0356.html
20:48:29 <dauwhe> ... so you can take into account OS stuff then
20:48:31 <fantasai> resolution on deferring light-level ^
20:48:47 <dauwhe> fantasai: here's the resolution... move light level to next level of MQ
20:49:12 <dauwhe> TabAtkins: overlow
20:49:17 <dauwhe> s/overlow/overflow
20:49:26 <dauwhe> fantasai: I had action item for proposal
20:49:29 <dauwhe> ... i'll try on the fly
20:49:46 <dauwhe> ... the questions were
20:49:53 <dauwhe> ... there's a block and inline axis
20:50:01 <dauwhe> ... can be scrolled or clipped
20:50:12 <dauwhe> block can be scrolled, paged, scrolled and paged.
20:50:20 <dauwhe> s/block/...block/
20:50:44 <dauwhe> ... we had overflow inline and overflow block
20:50:54 <dauwhe> ... but you don't care about everything
20:51:07 <dauwhe> ... so you'd have overflow and can just ask about block
20:51:21 <dauwhe> ... or do separate query for inline
20:51:27 <hober> s/expanding element/expanding element()/
20:51:36 <dauwhe> ... so syntax would be superset of keywords
20:51:46 <dauwhe> dbaron: don't know what you mean by overflow-inline
20:52:00 <dauwhe> ... does it have two different values but matches either?
20:52:11 <dauwhe> Florian: it doesn't have a value, it answers yes or no
20:52:17 <dauwhe> dbaron: all the features have a value
20:52:36 <dauwhe> ... just because a spec is written a certain way doesn't mean the concept isn't there
20:52:45 <dauwhe> Florian: if you include undefined, then yes
20:52:54 <dauwhe> ... some MQs always return false
20:53:05 <dauwhe> dbaron: eiether they have a particular value or no value
20:53:16 <dauwhe> ... I'm not totally against, but it's a little weird
20:53:29 <dauwhe> fantasai: can you specify them together?
20:53:42 <dauwhe> ... is the syntax going to be (writes on whiteboard)
20:53:48 <dauwhe> ... <block> | <inline>
20:53:55 <dauwhe> Florian: less risk by having one value
20:53:58 <dauwhe> ... then combine
20:54:01 <dauwhe> fantasai: that works for me
20:54:20 <dauwhe> Florian: scroll pages is the ??? one?
20:54:36 <dauwhe> ... we can spend forever on bikeshedding, but this makes sense
20:55:01 <dauwhe> Rossen: if you want to constrain to match only block
20:55:12 <dauwhe> ... then having it match scroll and not scroll
20:55:23 <dauwhe> fantasai: you can say overlow scroll and overflow clip inline
20:55:50 <dauwhe> Florian: between multival MQ and separate overflow-inline MQ
20:56:01 <dauwhe> ... either way you type the same words,
20:56:10 <dauwhe> ... which one is easier for impl, for extensibility
20:56:18 <dauwhe> fantasai: they're both easily extensible
20:56:38 <dauwhe> Florian: having two properties is less work
20:56:48 <dauwhe> ... mq so far don't have multivalue
20:56:53 <dauwhe> ... you may need to change your code
20:56:55 <dauwhe> Rossen: sure
20:57:26 <dauwhe> fantasai: (writes) overflow: scroll | page | scroll-page | none
20:58:00 <dauwhe> ...  scroll-inline | clip-inline
20:58:10 <dauwhe> ... scroll-block | clip-block
20:58:22 <dauwhe> ... I just want this first set to work because those are the common cases
20:58:27 <dauwhe> Rossen: what is scroll page
20:58:40 <dauwhe> fantasai: you can scroll but get new pages on forced breaks
20:58:50 <dauwhe> Florian: or can break on infinite scroll
20:58:58 <dauwhe> TabAtkins: the presentation case is good
20:59:09 <dauwhe> astearns: do we do the top box on this level, do the rest later?
20:59:12 <dauwhe> fantasai: that's ok
20:59:42 <dauwhe> ???: who has scroll-page?
20:59:45 <dauwhe> fantasai: presto
21:00:06 <astearns> s/???/esprehn/
21:00:21 <dauwhe> esprehn: scroll and page seem obvious, but the others...
21:00:38 <dauwhe> TabAtkins: we had at least one impl that had behaviour of scroll-page
21:00:47 <dauwhe> hober: that impl won't be updated for mq
21:00:56 <dauwhe> TabAtkins: but we know it's been useful to someone
21:01:14 <dauwhe> esprehn: we're trying to spec someone's experience. what about flipboard?
21:01:22 <dauwhe> fantasai: they page
21:01:44 <dauwhe> TabAtkins: the user agent is the one answering these questions. flipboard can do whatever it wants as a web app
21:01:58 <dauwhe> Florian: the inline direction is relevant to our user agent (vivliostyle)
21:02:17 <dauwhe> ... both scroll-inline and clip-inline are used
21:02:28 <dauwhe> esprehn: it seems bad to define all these things here
21:02:38 <dauwhe> fantasai: this is about whether fragmented or not
21:03:10 <dauwhe> esprehn: what if there's an expando triangle at the bottom
21:03:17 <dauwhe> TabAtkins: give us an existence proof
21:03:29 <dauwhe> fantasai: if you can do that on any page, it's effectively scroll
21:03:45 <dauwhe> ... you're not fragmenting
21:03:54 <dauwhe> esprehn: I want clip
21:03:59 <dauwhe> dbaron: that's a scrolling ui
21:04:11 <dauwhe> fantasai: there's a scrollable area and you can view it
21:04:25 <dauwhe> dbaron: you can look at the other part of the layout, but you're not chaning the layout
21:04:42 <dauwhe> fantasai: if you have paging, it changes future layout. that's fragmentation
21:05:10 <dauwhe> Florian: for inline, scrolling and clipping we understand
21:05:25 <dauwhe> ... but we don't have inline fragmentation because we don't understand what it is
21:05:33 <dauwhe> ... the rest are things sensible UA's want to do
21:05:41 <dauwhe> ... why exclude them?
21:05:48 <dbaron> I think some UAs may have had table printing code that did inline-direction fragmentation
21:05:49 <dauwhe> ... if your UA doesn't do them, just say no
21:06:01 <dauwhe> esprehn: I think there's a lot of dead stuff in css
21:06:12 <dauwhe> ... like a monochrome display with only green
21:06:17 <dauwhe> ... there's a matrix one
21:06:25 <dauwhe> TabAtkins: some versions of lynx need that
21:06:38 <dauwhe> Rossen: what is your main objection
21:06:49 <dauwhe> esprehn: every new print person will want more
21:07:01 <dauwhe> ... it's an enumeration of possible user experiences
21:07:17 <dauwhe> dbaron: it's an enumeration of the way the content can be layed out in css
21:07:39 <dauwhe> Florian: the things that are not defined in css are not in this list
21:07:49 <dauwhe> hober: caan we add scroll-page but make it at risk
21:07:54 <dauwhe> fantasai: just say no
21:08:05 <dauwhe> hober: as a reader of the spec, i'd like to know that no UA does this
21:08:17 <dauwhe> fantasai: but there's a decent chance there are some UAs
21:08:25 <dauwhe> ... I don't think at risk makes sense
21:08:38 <dauwhe> Florian: by not implementing it you are implementing it
21:08:45 <dauwhe> hober: just spec as returns false :)
21:08:56 <dauwhe> esprehn: what UA can only display the initial viewport?
21:09:03 <dauwhe> Florian: digital signing
21:09:10 <astearns> s/signing/signage/
21:09:20 <dauwhe> TabAtkins: digital signage is currently bad about this
21:09:34 <dauwhe> Florian: if you know your UA doesn't show overflow, then you need to know this
21:09:53 <dauwhe> shane: how many pages do you expect will show digital signage?
21:10:04 <dauwhe> TabAtkins: there's a news site that's designed for both--web and elevator
21:10:08 <dauwhe> ... content is the same
21:10:21 <dauwhe> ... their content is amenable to MQ
21:10:32 <dauwhe> hober: my understanding of elliot's point is hinging on that
21:10:41 <dauwhe> plinss: if you don't parse it you're ok
21:10:56 <dauwhe> dbaron: MQs are intended to be more speculative than other stuff in the platform
21:11:07 <dauwhe> ... "are you doing this familiar thing, or might you be new"
21:11:21 <dauwhe> esprehn: I wish my toaster supported css
21:11:43 <dauwhe> astearns: this is not sounding productive
21:11:54 <dauwhe> Florian: are we ok with having htis in spec and not implementing?
21:12:08 <dauwhe> esprehn: I object to the fact that the platform has stuff you shouldn't use as an author
21:12:17 <dauwhe> ... I have to wade through a lot of useless stuff
21:12:26 <dauwhe> Florian: we've removed some useless ones already
21:12:36 <dauwhe> TabAtkins: we should do better with examples and education
21:12:44 <dauwhe> ... we can do more than the maximally useful
21:12:53 <dauwhe> astearns: do block overflow now and inline later
21:13:06 <dauwhe> Florian: we know what we want to write, and someone wants to implement, why wait?
21:13:36 <dauwhe> astearns: do we split into levels? or do we put the whole proposal in?
21:13:43 <dauwhe> ... I don't care. Straw poll?
21:14:02 <dauwhe> fantasai: I want to keep scroll-page
21:14:12 <dauwhe> dbaron: should none be called clip?
21:14:21 <dauwhe> fantasai: none triggers falsiness
21:14:26 <dauwhe> TabAtkins: that's how MQs work
21:14:58 <dauwhe> astearns: a straw poll. A: overflow: scroll | page | scroll-page | none
21:15:14 <dauwhe> jensimmons: so we're doing things that no one wants to do now?
21:15:22 <dauwhe> astearns: this allows implementation later
21:15:33 <dauwhe> myles: if it never gets hit, how do you know it works?
21:15:39 <dauwhe> ... that's a recipe for untested code
21:15:52 <dauwhe> dbaron: you write a query that says "do you have the feature"
21:15:57 <dauwhe> ... everyone returns false
21:16:08 <dauwhe> ... later you can use it
21:16:16 <dauwhe> TabAtkins: we woudln't write code today
21:16:27 <dauwhe> ... but if anyone does do it, the ability to discriminate is useful
21:16:35 <dauwhe> ... and we know it's been done in the past or niche
21:16:38 <dauwhe> ... so it's reasonable
21:16:49 <dauwhe> Florian: you can return unknown instead of false
21:17:13 <dauwhe> ... but then there's problems with boolean logic
21:17:23 <dauwhe> ... if you know you're not doing it then say false
21:17:31 <dauwhe> plinss: it doesn't help now
21:17:54 <dauwhe> gsnedders: what happens if you give an unknown keyword?
21:17:59 <dauwhe> TabAtkins: it stays as unknown
21:18:10 <dauwhe> ... if it gets to top level it becomes false
21:18:25 <dauwhe> Florian: overflow (not scroll-page) is the issue
21:18:27 <dauwhe> gsnedders: ah
21:18:47 <dauwhe> jensimmons: you're interested in the inline things?
21:18:49 <dauwhe> Florian: yes
21:18:58 <dauwhe> ... we haven't implemented yet but it's in the plan
21:19:05 <dauwhe> ... we're also thinking about scroll-page
21:19:21 <dauwhe> ... as dbaron says, these are not theoretical UI modes, they are css modes
21:19:25 <dauwhe> ... and we know how they work
21:19:32 <dauwhe> ... this is stuff we do in css today
21:19:38 <dauwhe> ... we know what these things do
21:19:46 <dauwhe> ... not all of them are implemented in mainstream things
21:20:03 <dauwhe> bradk: if we have A, what is purpose of third line?
21:20:10 <dauwhe> Florian: I don't understand it either
21:20:28 <dauwhe> fantasai: third line if you want to explicitly query block axis
21:20:46 <dauwhe> ... if you're scrolling does this query return both axis
21:21:08 <dauwhe> fantasai: there are few question
21:21:17 <dauwhe> ... is it block scroll, or both, or either?
21:21:26 <dauwhe> Florian: didn't used to be a problem
21:21:45 <dauwhe> fantasai: for scroll-page, if you query the media type about scroll, it should proably say yes
21:21:54 <dauwhe> TabAtkins: can always return true for scroll
21:22:07 <dauwhe> fantasai: we do not page
21:22:20 <dauwhe> TabAtkins: requreineng neg query for common cases is not good
21:22:33 <dauwhe> fantasai: scroll page ua would want to fall under scroll
21:22:45 <dauwhe> TabAtkins: let's not over-think. match one thing or another.
21:22:58 <dauwhe> Rossen: back to straw poll?
21:23:10 <dauwhe> astearns: do everytihng at once, or split into levels?
21:23:31 <dauwhe> fantasai: option C: keep spec as-is, with overflow-block and overflow-inline as separate
21:23:38 <dauwhe> Florian: overflow-block is too verbose
21:23:57 <dauwhe> bradk: I like the way it is, it's explicit about which direction
21:24:24 <dauwhe> Florian: people stopped doing @media print, when they were talking about pagination
21:24:39 <dauwhe> fantasai: we're breaking out paginated part of print, like for an ereader
21:24:57 <dauwhe> TabAtkins: webkit and chrome don't want to implment values they won't use in the future
21:25:22 <dauwhe> esprehn: because false and undefined are different, we'd still have to implement
21:25:33 <dauwhe> fantasai: you'd still return false on tactile
21:25:44 <dauwhe> esprehn: so your binary has to contain things you don't support
21:26:03 <dauwhe> Florian: you will always have to do that with MQ
21:26:22 <dauwhe> esprehn: that's why I'm objecting to shipping speculative stuff
21:26:28 <dauwhe> Florian: they're both on my road map
21:26:44 <dauwhe> plinss: if any ui shipped, would you implement the mq?
21:26:51 <MaRakow> MaRakow has joined #CSS
21:27:23 <dauwhe> dbaron: the fact that the new boolean thing isn't right is a problem
21:27:28 <dauwhe> ... it doesn't do what we want to do
21:27:48 <dauwhe> ... we want to make it possible to "if this matches, do stuff, if not do other stuff"
21:27:58 <dauwhe> ... if it's unknown neither block run
21:28:07 <dauwhe> ... people want "or else"
21:28:20 <dauwhe> ... and the old MQs give you that, well it fails at a higher level
21:28:28 <dauwhe> plinss: let's put an else rule in MQ
21:28:33 <dauwhe> ... @else
21:28:43 <dauwhe> hober: in a world where some browsers return unknown
21:28:54 <dauwhe> ... you have to write rule so unknown ends up false
21:29:03 <dauwhe> ... will be in practice indistinguishable
21:29:23 <dauwhe> dbaron: unknown and false behave the same
21:29:33 <dauwhe> ... not unknown and false behave the same
21:29:43 <dauwhe> ... if you're using the not to be else
21:29:58 <dauwhe> ... maybe mq need a syntax for is this thing supported in mq
21:30:17 <dauwhe> gsnedders: often you can make an assumption... more likely scroll than page
21:30:28 <dauwhe> ... it's probably going to be write
21:30:44 <dauwhe> Florian: you write your non-conditional code for what is most probable and then test
21:31:01 <fantasai> +1 to dbaron
21:31:01 <dauwhe> dbaron: having to write non-conditional code and then override is a huge pain
21:31:09 <dauwhe> Florian: the problem with else
21:31:26 <dauwhe> ... we need syntax that makes the else apply in things that don't support it
21:31:35 <dauwhe> TabAtkins: this is something that doesn't transition well
21:31:51 <dauwhe> jensimmons: do we need to allow mq in @support?
21:32:11 <dauwhe> ... if you support foo, then I'll ask some questions about whether foo is supported
21:32:24 <dauwhe> gsnedders: it makes sense to treat MQ separately from @support
21:32:39 <dauwhe> dbaron: it's useful to have is a mq supported so you can used and and or
21:32:50 <dauwhe> ... is it supported AND is it true
21:32:55 <dauwhe> ... you keep the unknown
21:33:10 <dauwhe> jensimmons: what if they don't support the test and the feature?
21:33:14 <dauwhe> dbaron: then it doesn't work
21:33:20 <dauwhe> ... just like @supports
21:33:28 <dauwhe> TabAtkins: we can explore that
21:33:43 <dauwhe> gsnedders: supports is better than @else
21:34:03 <dauwhe> fantasai: we should make it easy to see if this is supported and true, or unsupported and false
21:34:12 <dauwhe> Florian: supported and true is good
21:34:28 <dauwhe> fantasai: you need the opposite of supported and true
21:34:33 <jensimmons> Can you put a media query inside a feature query?
21:34:43 <jensimmons> (currently)
21:34:45 <dauwhe> dbaron: you could have a function that captures the unknowns
21:35:02 <dauwhe> gsnedders: can we call it supports
21:35:03 <zcorpan> @supports(!!(foo))
21:35:32 <dauwhe> Action: TabAtkins to look into supports on mq
21:35:32 <trackbot> Created ACTION-770 - Look into supports on mq [on Tab Atkins Jr. - due 2016-05-16].
21:35:35 <dbaron> The function is, I think, known-and-true()
21:35:47 <dauwhe> topic: flexbox
21:35:58 <dauwhe> astearns: we're talking about percentages
21:36:07 <dauwhe> fantasai: bigger one is filed against grid and abspos
21:36:20 <dauwhe> ... the thing Christian and egalia folks wanted answered
21:36:25 <fantasai> https://lists.w3.org/Archives/Public/www-style/2016May/0050.html
21:36:33 <fantasai> s/egalia/Igalia/
21:36:33 <dauwhe> fantasai: this is what we want to tackle first
21:36:48 <dauwhe> ... everything else depends on this
21:36:59 <dauwhe> TabAtkins: i can summarize
21:37:13 <dauwhe> ... resolving % on children when container size is shrink-wrapped
21:37:24 <dauwhe> ... for float that shrink wrap, if we have child 50%
21:37:38 <dauwhe> ... we will do normal shrink, then child will be 50% against that
21:37:40 <SimonSapin> (Is there something projected? The camera is still on the whiteboard)
21:37:55 <astearns> SimonSapin: not right now
21:38:07 <dauwhe> dbaron: intrinsic width is separate from layout
21:38:16 <dauwhe> ... intrinsic width doesn't know %
21:38:27 <dauwhe> ... in layout you have input width, it takes that
21:38:35 <dauwhe> ... it's interoperable across lots of things
21:38:39 <dauwhe> fantasai: it's undefined in 2.1
21:38:47 <dauwhe> dbaron: shrink-wrap is undefined in 2.1
21:39:04 <dauwhe> TabAtkins: now it says % is never resolved, we want to change
21:39:16 <dauwhe> fantasai: if you do same in height, then % are treated as auto
21:39:26 <dauwhe> cbiesinger: can you repeat that?
21:39:43 <cbiesinger> dauwhe: was just asking fantasai to repeat herself :)
21:39:43 <dauwhe> fantasai: if you have the same situation in heigh axis, that percentage is not resolved, is treated as auto
21:40:03 <dauwhe> fantasai: so we have an inconsistency, how will we resolve?
21:40:19 <liam> liam has joined #css
21:40:26 <dauwhe> ... which parts of flex and grid do we make consistent with 2.1 width
21:40:36 <dauwhe> TabAtkins: these calculations happen separate from layout
21:40:48 <dauwhe> ... you need to run real layout to figute out heigh
21:40:53 <dauwhe> cbiesinger: I like the principle
21:41:02 <dauwhe> ... width calcs should require layout
21:41:10 <SimonSapin> orthogonal flows :(
21:41:11 <dauwhe> ... for intrinsic size calcs
21:41:18 <dauwhe> fantasai: in css 2.1 we didn't run into this
21:41:32 <dauwhe> ... orthogonal flow breaks the assumption of width input height output
21:41:40 <dauwhe> ... then you have to perform layout to find intrinsic size
21:42:00 <dauwhe> ... grid and flex and multicol and writing modes allow switching of the axes
21:42:07 <dauwhe> ... that's the complication
21:42:18 <dauwhe> ... and we've tried to make flex and grid consistent
21:42:30 <dauwhe> ... right now they're not consistent in block layout
21:42:50 <dauwhe> esprehn: to be fair, there are other ways in which flexbox treats height and width differently
21:42:52 <dauwhe> Rossen: not really
21:43:03 <dauwhe> ... if you assume all you have is flexbox
21:43:07 <esprehn> that was ojan not esprehn
21:43:18 <dauwhe> ... can we make make symmetric?
21:43:24 <dauwhe> s/esprehn/ojan/
21:43:44 <dauwhe> Rossen: when you hit it, you are bound to do this measuring
21:44:27 <dauwhe> ... for flexbox and grid, their measuring should be symmetric
21:44:42 <dauwhe> ... how do you deal with block layout when there are flex or grid heights
21:44:56 <dauwhe> ... is there a reason we need to change anything?
21:45:01 <dauwhe> ... I don't think there's a need
21:45:28 <dauwhe> dholbert: this is about percent on something that happens to be in a flex container
21:45:51 <dauwhe> dbaron: some of the issue is taht sizing is attempting to define for block
21:46:03 <dauwhe> TabAtkins: we can special-case as appropriate, but right now they're not correct
21:46:30 <dauwhe> ... if we do adopt this, right now we don't allow intrinsics to be definite
21:46:40 <dauwhe> ... if we correct for float and make a gen principle
21:46:46 <dauwhe> ... than min-sizing are definite
21:46:53 <dauwhe> dbaron: things for floats are true for abspos
21:47:10 <dauwhe> ... you need a mech for when things that were indefinite are definite
21:47:18 <dauwhe> ... percentages inside table cells for example
21:47:44 <dauwhe> TabAtkins: it's not hard to have in spec, in this case this lenght is indefinite
21:47:53 <dauwhe> ... just trying to figure out what default should be
21:48:26 <dauwhe> ... if we define that intrinsic sizes are considered definite by default, then that fixes our issue
21:48:36 <dauwhe> ... we can then simply text in flexbox
21:48:45 <dauwhe> Rossen: what would be a simplle example
21:49:45 <dauwhe> TabAtkins: treast intrinsic sizes as definite when they don't rely on layout, by default
21:50:00 <dauwhe> ... shrink wrapping would be definite for resolving intrinsic sizes on children
21:50:13 <dauwhe> TabAtkins: if you say height: min-content that requires layout, so would be indefinite
21:50:49 <dauwhe> astearns: any objections?
21:50:57 <dauwhe> hober: I have vague fears of this change
21:51:18 <hober> s/hober: I have vague fears of this change//
21:51:29 <dauwhe> Resolved: intrinsic sizes that don't require layout to recalculate are treated as definite
21:52:03 <dauwhe> Topic: flexbox issues
21:52:26 <Rossen> https://drafts.csswg.org/css-flexbox-1/issues-cr-20160301#issue-1
21:52:34 <fantasai> http://drafts.csswg.org/css-flexbox-1/issues-cr-20160301
21:53:12 <dauwhe> TabAtkins: this will be covered by general sizing behaviour
21:53:29 <dauwhe> astearns: are we going to republish?
21:53:42 <tantek> tantek has joined #css
21:53:44 <dauwhe> dholbert: should we reopen percent padding discussion?
21:53:53 <dauwhe> ... would be useful before we republish
21:54:11 <dauwhe> ... we have several more bugs this week
21:54:23 <dauwhe> ... currently spec says browser decides
21:54:31 <dauwhe> TabAtkins: if we want to start on this I have numbers
21:54:50 <dauwhe> ... people using % in margin or padding .35%
21:55:03 <astearns> ./.35/.035/
21:55:05 <dauwhe> ... this is any usage, including usual hacks
21:55:17 <astearns> s/.35/.035/
21:55:39 <dauwhe> dholbert: most people using margin/padding are expecting traditional block behaviour
21:55:53 <dauwhe> TabAtkins: nobody cares and we should do what is consistant
21:56:15 <dauwhe> tantek: different opinions on what is simplest
21:56:41 <dauwhe> dholbert: I want to change
21:56:52 <dauwhe> ... I want to see if Microsoft is still concerned
21:57:16 <dauwhe> jensimmons: if this group that thinks it's a rare use case that people use percentage in margins, you're wrong
21:57:26 <Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/padding-left/
21:57:44 <dauwhe> ... every person using responsive web design uses this
21:57:56 <dauwhe> ... using best practices
21:58:07 <dauwhe> ... every single person is using percents in margins and gutters
21:58:43 <dauwhe> TabAtkins: our calculations were looking for percentage margin on a flex item
21:58:51 <dauwhe> dbaron: a percentage of what
21:59:19 <dauwhe> jensimmons: the relevant is what % of people using flex
21:59:23 <dauwhe> ojan: it's 11%
21:59:34 <dauwhe> ... the most useful thing would be examples
21:59:55 <dauwhe> ... the q is does it resolve against width or height
22:00:14 <dauwhe> tantek: if you were to use flex in responisive design, would you use percentage margin/padding?
22:00:28 <dauwhe> ... if the answer is yes, then I'd ask what your expectations would be
22:01:14 <dauwhe> TabAtkins: beyond bug reports asking for block behavour,
22:01:38 <dauwhe> tantek: there are lots more new authors, and simplifying model for them is more important than maintaining past behaviour
22:02:01 <dauwhe> shane: support for responsive design is separate from backwards compat
22:03:04 <dauwhe> jensimmons: are people going to need to use percent in flex?
22:03:11 <dauwhe> tantek: it's an orthogonal question
22:03:24 <dauwhe> ojan: maybe jen can come back with examples, and we can discuss
22:03:35 <dauwhe> ... and it doesn't sound like MS has changed their behaviour
22:04:08 <dauwhe> astearns: anything else for flex?
22:04:14 <dauwhe> TabAtkins: that's all we needed
22:04:21 <dauwhe> ... there's one more
22:04:31 <dauwhe> ... running layout to compute intrnsic sizes in the width axis
22:04:41 <dauwhe> ... two chrome impl have run into this
22:04:47 <dauwhe> ... have a column multiline flexbox
22:04:58 <dauwhe> ... that youre floating
22:05:05 <dauwhe> ... it has column wrap
22:05:17 <dauwhe> ... to find width of column wrap flexbox you need to do real layout
22:05:20 <dauwhe> ... and that's problematic
22:05:27 <dauwhe> ... edge does this correctly
22:05:47 <dauwhe> ... chrome does not
22:06:06 <dauwhe> ... so things are clearly broken from authoring perspective
22:06:12 <dauwhe> ... but it's performant and consistent
22:06:24 <dauwhe> gregwhitworth: we brought this up two years ago
22:06:35 <dauwhe> ... in some cases you do want to do actual layout
22:07:00 <dauwhe> ... i think it's work taking the effort to do it in performant manner
22:07:15 <dauwhe> TabAtkins: so performant easy stupid one? or the harder one that's correct?
22:07:26 <dauwhe> esprehn: doesn't servo do this in parallel
22:07:35 <dauwhe> ... so they would object
22:07:46 <dauwhe> fantasai: this problem exists for a lot a things in css
22:07:53 <dauwhe> dbaron: only things from the past few years
22:08:04 <dauwhe> fantasai: orthogonal flows..
22:08:36 <dauwhe> TabAtkins: the similar examples that work are multicol
22:08:48 <dauwhe> ... but flex can have different widths in column wrap
22:09:01 <dauwhe> fantasai: but you need to know how many columns in multicol
22:09:06 <dauwhe> iank_: this is if auto-width
22:09:25 <dauwhe> Rossen: where are you going with this?
22:09:37 <dauwhe> ... are you proposing we allow layout-based measuring?
22:09:47 <dauwhe> TabAtkins: yes, otherwise you can't float a multi-col flexbox
22:09:56 <dauwhe> ... if other browsers are not willing to do it...
22:10:11 <SimonSapin> Yes this is all a big problem for Servo and I don’t know what to do about it :(
22:10:39 <dauwhe> plinss: it doesn't matter if you're performant if you're always delivering the wrong answer
22:11:01 <dauwhe> ojan: I feel torn. there's the obviously correct one... in chrome we won't be able to do this anytime soon
22:11:14 <dauwhe> cbiesinger: we are considering a rewrite of our layout engine
22:11:19 <dauwhe> ojan: but this is two years away
22:11:45 <dauwhe> dbaron: a few years ago, intrinsic width was a rather clean concept
22:11:49 <dauwhe> fantasai: that no one understood
22:12:00 <dauwhe> dbaron: there was some architectural sense to it
22:12:10 <dauwhe> ... I'm concerned about what's been happening to it
22:12:20 <dauwhe> ... and how it's tying web tech to current implementations
22:12:38 <dauwhe> ... like how servo has something that works with stuff two years ago, but not current stuff
22:12:58 <dauwhe> ... especially as it aligns with how processors are evolving
22:13:13 <dauwhe> Florian: the number of cores is stagnating
22:13:31 <dauwhe> esprehn: this isn't the right forum to discuss if Servo is the right thing
22:13:41 <dauwhe> Florian: but doing this doesn't invalidate servo
22:13:57 <SimonSapin> astearns: q+
22:14:00 <dauwhe> ... we shouldn't make everyting parallizable even at the expense of author expectations
22:14:12 <dauwhe> dbaron: serve parallizes that breaks up the tree
22:14:22 <dauwhe> ... start at top, pass info to leaves, return other info up
22:14:29 <dauwhe> ... there's a cost to that
22:14:45 <dauwhe> ... pass one moves information
22:14:51 <dauwhe> ... pass two is the layout
22:14:59 <dauwhe> ... more passes are costly
22:15:12 <dauwhe> SimonSapin: what dbaron just said
22:15:29 <dauwhe> ... in some cases we already need to sequentialize layout, like floats and counters
22:15:49 <dauwhe> ... doing intrinsic widh requireing layout is probably not impossible without throwing it all away
22:15:59 <dauwhe> ... I don't know yet how complex this will be
22:16:07 <dauwhe> s/widh/width/
22:16:16 <dauwhe> s/requireing/requiring/
22:16:58 <dauwhe> TabAtkins: we might allow the js plugin for sizing to rely on layout
22:17:03 <dauwhe> iank_: this is a houdini topic
22:17:16 <dauwhe> plinss: there are a lot of other layout problems that css hasn't done yet
22:17:26 <dauwhe> ... and they mostly fall into this category
22:17:38 <dauwhe> ... and if we cut this off now, it's very short-sighted
22:18:02 <dauwhe> TabAtkins: IE is ok, we're torn, servo doesn't like it but can slow-path it
22:18:14 <dauwhe> ... authors 100% have a preferred behaviour
22:18:44 <dauwhe> dauwhe: and w3c has principles to answer this question
22:19:02 <dauwhe> astearns: is there a gecko consideration?
22:19:10 <dauwhe> dholbert: it will take some work
22:19:29 <fantasai> First draft of CSS Writing Modes was published in 2012. It said that logical heights are sized to fit the content.
22:19:38 <dauwhe> plinss: authors will always be able to blow things up
22:19:50 <dauwhe> dbaron: we also want web performance to be predictable
22:20:02 <dauwhe> plinss: I remember 30 seconds to resize nested tables
22:20:09 <fantasai> s/resize/resize 4 levels of/
22:20:14 <TabAtkins> Test case: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4176
22:20:24 <dauwhe> ... if we're not giving authors what they need, what are we doing?
22:20:45 <dauwhe> plinss: the authors expectation is to do the right thing
22:20:48 <dauwhe> shane: yes
22:20:52 <TabAtkins> ^^^ if the dark green expands to fill under both lime boxes, you do layout to calculate intrinsic sizes
22:21:00 <dauwhe> plinss: they're giving a bullshit answer for performance
22:21:35 <dauwhe> gregwhitworth: 99% don't know the predictiblity that you know because you work on the engines
22:21:49 <dauwhe> dbaron: and floats were defined for something other than what people are using them for
22:22:12 <dauwhe> gregwhitworth: had we addressed this two years ago... ie11 layed out floats to get size
22:22:26 <dauwhe> ... I do want to back what plinss said
22:22:40 <dauwhe> In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.
22:23:04 <dauwhe> dbaron: there was no consensus for layout, and there was consensus for doing what we knew how to do
22:23:30 <dauwhe> gregwhitworth: can we start, though? I know there's a burden of work. But for the authors and the platform, we need to do this in performant ways
22:23:43 <dauwhe> fantasai: this is even more clear
22:23:54 <dauwhe> dbaron: I think this is a rewrite the layout engine thing
22:24:03 <dauwhe> dbaron: we don't have the resources to do this
22:24:24 <dauwhe> dbaron: there might be other ways to fix the broken behaviour
22:25:53 <ChrisL> ChrisL has joined #css
22:26:07 <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4177
22:26:09 <dauwhe> (looking at test case link from above)
22:27:49 <shane> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4179 <-- content occlusion
22:28:01 <dauwhe> TabAtkins: the spec mandates edge's behaviour
22:28:17 <dauwhe> ... so do we leave it alone, or do the stupid fast thing?
22:28:51 <dauwhe> dbaron: the way I'd look at describing an instrinsic width mech to do this
22:29:06 <dauwhe> ... a column wrapped flexbox is an orthogonal flow
22:29:29 <dauwhe> ... so if you have one of those tihngs floating, you compute intrinsic heights, then do width as output
22:29:57 <dauwhe> cbiesinger: blink doesn't deal with that, doesn't need height until layout
22:30:04 <dauwhe> dbaron: I think that's looking at it backwards
22:30:20 <dauwhe> dholbert: in the test, there's a set witdth and height on the flex items
22:30:28 <dauwhe> ... if it was text you'd have to do layout
22:30:33 <SimonSapin> (astearns, projecting? the camera is… somewhere)
22:30:41 <dauwhe> dbaron: that depends on what heights or widths are specified
22:30:53 <dauwhe> ... if there are few enough, you're not going to get a sensible layout anyway
22:30:58 <astearns> SimonSapin: not projecting anything
22:30:59 <dauwhe> gregwhitworth: what do you mean
22:31:08 <dauwhe> dbaron: you're not going to like the results
22:31:14 <dauwhe> gregwhitworth: you're assuming everying is auto
22:31:16 <dauwhe> dbaron: right
22:31:34 <dauwhe> ... part of the problem that led us into this is not treating the orthogonal flexbox as orthoganol
22:31:37 <dauwhe> TabAtkins: possibly
22:31:49 <dauwhe> dbaron: I think some of that weird behaviour is from the same problem
22:32:04 <dauwhe> TabAtkins: the weirdest behaviour is to avoid t-shaped documents
22:32:15 <dauwhe> ... like auto height of 100vh for mixed direction things
22:33:00 <dauwhe> ... a column flex box should not have those fix-up things that apply
22:33:04 <dauwhe> ... to text
22:33:20 <dauwhe> ... there might be some stuff from orthogonal flows we could import
22:33:32 <dauwhe> ... but the general case won't give us good results
22:33:38 <dauwhe> dbaron: 'cause that's the way they flow
22:33:50 <dauwhe> ... flexbox today has so many patches to get good results
22:34:05 <dauwhe> fantasai: I don't understand what you mean by act like orthogonal flows
22:34:11 <dauwhe> TabAtkins: they do height first, then width
22:34:25 <dauwhe> cbiesinger: this is different because it's doubly orthogonal
22:34:37 <dauwhe> dbaron: it's two layers of orthogonal nesting
22:34:49 <dauwhe> ... getting orthogonal stuff only makes sense with widths
22:35:10 <dauwhe> fantasai: it won't wrap unless there's a constraint on the container
22:35:26 <dauwhe> ... in the case of writing modes, we impose the 100vh rather than calcing as max content
22:35:36 <dauwhe> ... but column wrap flex uses max content
22:35:43 <dholbert> FWIW, here's a testcase with no specified heights on the items, and with multiple lines of text in each:  http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=4180
22:36:37 <dauwhe> dbaron: the problem is not that you want widht on layout, but you want the auto size calc for column wrapping flexbox in that dimention
22:36:42 <dauwhe> .. rather than in the other way
22:36:51 <dauwhe> gregwhitworth: however you want to solve it is fine
22:37:05 <dauwhe> dbaron: I would really like intrinsic widths to be not dependant on layout
22:37:12 <dauwhe> ... and I think there are good ways to do that
22:37:16 <dauwhe> ... except for floats
22:37:32 <dauwhe> ... except for block formatting contexts that contain floats and texts
22:37:38 <dauwhe> TabAtkins: I'd be happy to defer
22:37:57 <dauwhe> ... until we can prepare some ideas
22:38:15 <dauwhe> ... I don't want to put dbaron on the spot right now
22:38:19 <dauwhe> ... I want more time to think
22:38:35 <dauwhe> dbaron: ok
22:38:53 <dauwhe> astearns: the original question is do we want to do anything before we publish flex
22:39:00 <dauwhe> ... and the answer is no, we publish.
22:39:09 <dauwhe> ... so let's take a break
22:39:34 <dauwhe> ... we do need some topics from tue and wed
22:39:57 <dauwhe> <break duration="NaN"/>
23:00:56 <rniwa_> rniwa_ has joined #css
23:03:24 <Florian> Florian has joined #css
23:04:59 <myles1> myles1 has joined #css
23:07:46 <ekimber> ekimber has joined #css
23:07:50 <BradK> BradK has joined #CSS
23:08:26 <ChrisL> ChrisL has joined #css
23:08:40 <SimonSapin> astearns, gregwhitworth: is Tables still planned for tomorrow? Could it be not too late in the day?
23:09:10 <astearns> will ask
23:10:26 <astearns> will start with tables
23:10:36 <fantasai> ScribeNick: fantasai
23:11:11 <fantasai> Topic: CSS Containment
23:11:23 <fantasai> Florian: Why don't we have a public working draft?
23:11:35 <fantasai> TabAtkins: We were waiting on layout and ?, but I'm cool with that
23:11:37 <fantasai> dbaron: I have an open bug
23:11:41 <fantasai> dbaron: On the title of the spec
23:11:46 <fantasai> dbaron: Should be level 1 rather than level 3
23:12:00 <fantasai> TabAtkins: There's also an open issue about overflow: clip
23:12:27 <fantasai> TabAtkins: Can i publish a WD of css-contain-1?
23:12:44 <dbaron> gregwhitworth, fwiw, we have one bug report on visible control characters, https://bugzilla.mozilla.org/show_bug.cgi?id=1220462
23:13:02 <fantasai> RESOLVED: Publish FPWD of css-contain-1 after edits on overflow dependency
23:13:11 <dbaron> BTW, the reason I noticed the level being 3 rather than 1 was that we submitted *tests* for the spec, and Shepherd complained that they weren't associated with the spec!
23:14:11 <fantasai> Topic: control chars
23:14:17 <fantasai> TabAtkins: So, on control chars.... we lost the data
23:14:37 <fantasai> TabAtkins: It was on ??'s server, but then he shut it down and it's gone.......
23:14:46 <TabAtkins> s/??/Emil/
23:14:48 <tantek> present+
23:14:50 <fantasai> gregwhitworth: {///}
23:14:55 <dbaron> (And that one bug report was based on having it on for nightly & aurora but off for beta & release.)
23:14:58 <fantasai> gregwhitworth: We're not surprised people are running into problems
23:15:15 <fantasai> gregwhitworth: That's why we wanted to announce and do a coordinated PR push
23:15:25 <fantasai> gregwhitworth: And why we want everyone to have it behind a flag, so that we can coordinate a release
23:15:37 <fantasai> Topic: CSS Content
23:15:47 <Florian> a::after { content: target-counter(attr(href, url), page); }
23:15:48 <fantasai> Florian: wrt cross-references
23:15:51 <fantasai> Florian: It looks like this
23:15:56 <fantasai> [pastes example]
23:16:03 <fantasai> Florian: Implemented in Antenna House, Prince, and ?
23:16:10 <fantasai> Florian: Vivliostyle lookinginto implementing
23:16:21 <fantasai> Florian: Major issue right now is that as specified, it could be infinite passes
23:16:29 <fantasai> Florian: If you have something reference at the very end of 109
23:16:41 <fantasai> Florian: You do relayout, and then now it's at page 110
23:16:46 <fantasai> Florian: This goes back to page 109
23:17:03 <fantasai> Florian: In most cases you do N passes and it eventually stabilizes
23:17:08 <fantasai> Florian: But 20 minutes is okay for print
23:17:14 <fantasai> Florian: But 20 minutes is better than infinite minutes
23:17:24 <fantasai> Florian: I've never run into infinite loops in the wild, but multipasses happens
23:17:27 <fantasai> Florian: It's already terrible
23:17:38 <fantasai> Florian: N passes of laying out several hundred pages is a bad idea
23:17:47 <fantasai> dauwhe: If N is 2 it's not too bad
23:17:53 <fantasai> ...
23:18:02 <fantasai> plinss: It's only infinite if you allow the race condition to continue
23:18:11 <fantasai> plinss: There's other fun things in paged layout that can create race conditions
23:18:24 <fantasai> plinss: Can apply a generic solution, detect if you are racing and stop racing
23:18:34 <fantasai> Florian: Detecting a loop and stoping is one way out of the problem
23:18:47 <fantasai> plinss: Do layout, then check if it moved, then it stays there, don't bring it back
23:18:54 <fantasai> Florian: Problem is you end up with incorrect toc numbers
23:19:07 <fantasai> plinss: No, do second page layout. If it ends up on 110, you treat is as a widow
23:19:12 <fantasai> plinss: Leave it out at 110
23:19:15 <ojan> is there a spec for what we're discussing or just the mailing list threads?
23:19:16 <fantasai> plinss: Don't relayout
23:19:37 <fantasai> dbaron: You do one pass, do references, say this has to be on at least this page
23:19:44 <fantasai> dbaron: And shift things to later page
23:19:51 <fantasai> dbaron: but not earlier page
23:19:56 <fantasai> Florian: With a forced break priority
23:20:04 <fantasai> dbaron: Well, might want to do a priority with some ...
23:20:10 <fantasai> Florian: Alternative solution, similar to manual fixups
23:20:15 <fantasai> Florian: On first pass you have a placeholder
23:20:17 <dauwhe> https://drafts.csswg.org/css-content/#cross-references
23:20:29 <fantasai> Florian: First do pass with a placeholder.
23:20:44 <fantasai> Florian: Then do layout, fill in the text
23:20:59 <fantasai> Florian: if it's smaller, do some alignment within the placeholder space
23:21:08 <fantasai> Florian: if it's larger, might have ink overflow
23:21:10 <fantasai> [skeptical]
23:21:22 <fantasai> s/[/fantasai: [/
23:21:23 <fantasai> ...
23:21:34 <fantasai> plinss: This is a generic problem. could have same problem with widows and orphans
23:21:58 <fantasai> plinss: This is a generic problem. Gonnar run into the same problem in all sorts of other ways
23:22:03 <fantasai> plinss: Think we should have a generic solution
23:22:10 <fantasai> plinss: Not have an author-specified placeholder
23:22:30 <fantasai> dbaron: The solution is similar to standard solution to footnotes, which is if you push ...
23:22:40 <fantasai> plinss: If your footnote grows, starts to push marker off, stop growing at that point
23:22:44 <fantasai> plinss: Same principle
23:22:51 <fantasai> plinss: Just before it would create a race condition, you stop
23:22:59 <fantasai> Florian: Okay, I hadn't thought about that one
23:23:09 <fantasai> Florian: We have this on our roadmap, not interested in infinite loop solution
23:23:23 <fantasai> Florian: We also think that having CSS properties that are acceptible for print formatters but not Web, is bad
23:23:31 <fantasai> Florian: Many passes is not good
23:23:37 <fantasai> plinss: There are other problems that require multiple passes
23:23:42 <fantasai> plinss: But most can be done in 2 passes, tops
23:23:56 <fantasai> Florian: So, way you suggested, no need to change syntax
23:24:14 <fantasai> Florian: One side advantage of placeholders, if you have long document and it takes awhile to render, have something to show in the meantime
23:24:32 <fantasai> dauwhe: Could do that as an author
23:24:38 <fantasai> Florian: So most of the time you get 2 passes
23:24:43 <fantasai> plinss: Most of time you can do in 1 pass
23:24:49 <fantasai> plinss: Sometimes have to go back and do it again, then stop
23:24:59 <fantasai> plinss: You might have a rippling effect, but not a looping effect
23:25:15 <fantasai> plinss: Might have to do nlogn
23:25:32 <fantasai> ojan: We won't implement any of this, ever.
23:25:45 <fantasai> ojan: It involves laying out the entire document in order to figure out what page something is on
23:25:50 <fantasai> ojan: Never doing that
23:26:02 <fantasai> elliott: We treat generated content as DOM
23:26:12 <fantasai> elliott: So this is going to be an infinite loop for us
23:26:50 <fantasai> ekimber: Certainly the case that in context of print, potential for infinite lops is unavoidable
23:27:10 <fantasai> ekimber: We might not be doing in this context, but then maybe you move stuff to a different page cuz not enough space, but hat creats enough space, so move it back
23:27:19 <fantasai> ekimber: So only solutin is to have a "stop trying" solution
23:27:33 <fantasai> elliott: In our case, at a fundamental level layout can't affet DOM
23:27:46 <fantasai> elliott: You cant say "do layout, and then set attribute based on layout"
23:28:06 <tantek>  is having trouble connecting the discussion to the spec. Could someone drop a fraglink to the specific feature of the spec that's affected?
23:28:17 <fantasai> plinss: Layout should never affect DOM. But you don't have to implement this as modifying the DOM
23:28:38 <fantasai> ...
23:28:44 <fantasai> plinss: It's not DOM tree, it's layout tree
23:28:49 <fantasai> plinss: You have some situations ,but you deal with it
23:28:53 <fantasai> plinss: But this is implementation details
23:28:56 <fantasai> myles1: We're all agreeinghere
23:29:15 <dauwhe> s/Could do that as an author/Could do that as an author by putting placeholder content in HTML and then replace with generated content in CSS/
23:29:26 <fantasai> plinss: Nobody is saying that layout affets DOM. I'm saying you don't have to implement generated content by affecting the DOM. If you do, can't implement these kinds of features.
23:29:46 <fantasai> gsnedders: If we have 2 impls, we're fine
23:29:49 <fantasai> Florian: We have 3
23:30:12 <fantasai> TabAtkins: How do we deal with things that will not be implemented by browsers, but are implemented interoperably by other engines?
23:30:20 <fantasai> TabAtkins: How do we indicate to authors, that this won't work in browsers?
23:30:25 <fantasai> Florian: Making clear to authors is useful
23:30:41 <fantasai> Florian: But one goals of what we're doing at Vivliostyle is to explicitly stop having CSS for Web and CSS for Print being two different things.
23:30:46 <fantasai> Florian: Want to be integrated
23:30:48 <gsnedders> (sidenote: I was mostly being sarcastic about the fact that no browser will support it and our 2 impl requirement, given minutes don't capture tone)
23:31:10 <fantasai> Florian: We know browsers won't prioritize these features, but want to make sure they are implementable if they become prioritized
23:31:18 <fantasai> ...
23:31:32 <fantasai> hober: Florian wants the solution to be something we could theoretically accept
23:31:49 <fantasai> tantek: We will never implement vs. this is not a priority, those are two very different things.
23:32:07 <fantasai> esprehn: They should just do it in Houdini.
23:32:18 <fantasai> Florian: Risking a longer debate.
23:32:38 <fantasai> TabAtkins: Similar to static vs dynamic profile of Selectors
23:32:47 <fantasai> TabAtkins: We have something that will fundamentally not be done in CSS processing
23:32:55 <fantasai> TabAtkins: But works fine in batch processors and JS
23:33:01 <fantasai> Florian: I'm talking about ebook readers.
23:33:05 <fantasai> Florian: Not batch processors
23:33:25 <fantasai> TabAtkins: We've already made a somewhat principled split between main Web stuff for CSS and other stuff
23:33:29 <fantasai> TabAtkins: Speccing that, and doing it well
23:33:33 <fantasai> TabAtkins: Fine to do that for ebook or whatever
23:33:51 <fantasai> TabAtkins: As long as a) it's clear, as in Selectors, that it's not expected to work in Web pages right now (though could change in future)
23:33:59 <fantasai> TabAtkins: and also b) scope amount of time we spend on this
23:34:20 <fantasai> Florian: Jen has some good talks about this, Web design now be incredibly poor and boring cmp print
23:34:29 <fantasai> Florian: Fantastic design on magazines, not done on Web
23:34:42 <fantasai> Florian: Web designers should look for inspiration elsewhere than the Web
23:34:48 <fantasai> Florian: Mayb pagination isn't part of that
23:34:56 <fantasai> Florian: Maybe mostly print, but haivng on the Web might be fine
23:35:22 <fantasai> esprehn: We should provide primitives, so people can make libraries, and if it's super popular we can backport to the Web
23:35:34 <fantasai> esprehn: Core of Web should be small, and libraries should implement these things.
23:35:44 <fantasai> Florian: That is okay, but saing " this is for print " don't want to do
23:35:49 <fantasai> esprehn: Should say "this is for libraries"
23:36:08 <fantasai> ojan: Being a standard and a spec isn't coupled to whether shipped in Web or print formatters
23:36:17 <fantasai> ojan: Being a spec doesn't say where it gets implmeented. That's a good thing.
23:36:32 <fantasai> ojan: If we treat the whole room as caring about all the issues [??]
23:36:36 <fantasai> plinss: I thin I agree with all of you guys
23:36:45 <fantasai> plinss: What products implemnt what features? Depend son the market
23:36:53 <fantasai> plinss: Doesn't mean we can't standardize how these things shoudl behave
23:37:01 <jensimmons> q+
23:37:10 <fantasai> plinss: Whether implemented in browser vendors or libraries or whatever,
23:37:15 <fantasai> ojan: Why have browsers in the room?
23:37:21 <fantasai> astearns: Because the CSS expertise is in this room.
23:37:34 <fantasai> astearns: We want to avoid the situation like EPUB 3 where they made up stuff for CSS that was badly designed
23:37:40 <fantasai> Florian: Also obvious that brower vendors get priority on topics
23:37:47 <fantasai> Florian: Then again, a whole bunch of ppl here who are not browser vendors
23:37:56 <dauwhe> q+
23:38:02 <dauwhe> q?
23:38:12 <Zakim> Zakim has joined #css
23:38:19 <fantasai> gsnedders: Also worthwhile to point out that a lot of ppl in this room have a good idea what can be performantly impemented within the larger CSS model
23:38:30 <fantasai> gsnedders: regardless of whether implemented in browser or not
23:38:32 <dbaron> q+ jensimmons
23:38:35 <dbaron> q+ dauwhe
23:38:36 <fantasai> gsnedders: And that's a good thing
23:38:44 <dbaron> ack jen
23:39:02 <fantasai> jensimmons: It feels like some of this also is about giant billion dollar companies saying "this isn't in our interest, therefore shouldn't be in wg"
23:39:17 <fantasai> jensimmons: But there are smaller vendors, smaller groups that have other interests
23:39:29 <fantasai> jensimmons: I don't think it's fair to say that if Google will never implement, we shouldn't spend time on it
23:39:34 <bradk_> bradk_ has joined #css
23:39:40 <ojan> q+
23:39:43 <fantasai> jensimmons: There are some things that are super worth our time to make sure specced well
23:39:51 <fantasai> jensimmons: Things that epub and print needs, and a lot of other things
23:40:04 <Florian> q+
23:40:04 <tantek> q?
23:40:05 <fantasai> jensimmons: Tension between reality of who pays us and let's make it the Web. Web is cool
23:40:12 <esprehn> q+
23:40:16 <fantasai> dauwhe: I would just drawing back and looking at question in hand, this spec is about generated cntent in general
23:40:31 <fantasai> dauwhe: Talking about the value of one particular type of counter. But this applies to a lot of idfferent counters, and there are a lot of web stuf fin ths spec
23:40:47 <fantasai> dauwhe: We reach some resolution on the particular issue, might not ened to specify width for plcaholder for page counters in this cirfumstance
23:40:55 <tantek> q+ to ask what's the goal of this discussion? to move the spec forward? split spec levels?
23:40:58 <fantasai> dauwhe: As we gain impl experience ,can perhaps revisit the issue
23:41:06 <fantasai> Florian: plinss suggestion is maybe a more intersting solution to epxlore
23:41:21 <fantasai> Florian: Given obvious priorites of browsers I think it's fair to timebox this type of non-browser discussion
23:41:32 <fantasai> Florian: But definitely don't want it to be on a separate track. That has been a disaster.
23:41:55 <fantasai> Florian: When liam came to us to say that "I'm sorry to shut down XSL:FO, but would be ok if CSSWG takes on our use cases"
23:42:03 <fantasai> ojan: Don't have a problem with CSSWG taking on these specs
23:42:17 <fantasai> ojan: Do have a problem with having this whole room to discuss spec where only 5 ppl are talking
23:42:22 <fantasai> ojan: We need to fix that.
23:42:27 <fantasai> dauwhe: General problem
23:42:35 <fantasai> tantek: That's a scheduling problem
23:42:44 <fantasai> Florian: Also, Tab and fantasai are always in the discussion
23:42:56 <fantasai> ojan: I would feel very differently if this was a javascript library
23:43:05 <fantasai> ojan: Forcing whole page to relayout would be fine for a JS library
23:43:12 <fantasai> ojan: Fine feature, serves user purpose
23:43:21 <fantasai> Florian: Our UA is a giant JavaScript library
23:43:43 <fantasai> ojan: Understand about tracks... but how about splitting such things off into a separate day
23:43:48 <fantasai> ... houdinin ...
23:43:53 <dauwhe> q?
23:43:57 <fantasai> astearns: Houdini topics [...]
23:43:58 <skk> q+
23:44:02 <fantasai> Florian: Some are native implementations, not JS
23:44:09 <fantasai> esprehn: What about the rest of the spec?
23:44:22 <fantasai> esprehn: This spec contains a bunch of stuff. Datetime and document-url, leaders, etc.
23:44:28 <fantasai> esprehn: From our perspective belongs in a library
23:44:38 <fantasai> esprehn: Think it should be in a JS library
23:45:00 <fantasai> esprehn: Be really nice to publish a spec that describes what browsers really do
23:45:02 <fantasai> fantasai: That was 2.1
23:45:06 <fantasai> esprehn: But it didn't
23:45:09 <fantasai> fantasai: What's missing?
23:45:28 <fantasai> Florian: I put this one on the agenda because we want to implement, but not how it's been implemented by the other print formatters
23:45:39 <fantasai> dauwhe: I came into the WG just as Håkon was leaving, and took over editorship of GCPM
23:45:45 <fantasai> dauwhe: Much of it was a .. junkyard
23:45:51 <fantasai> dauwhe: Stuff just collected in GCPM
23:46:01 <fantasai> dauwhe: Over past few years, resolutions to move things into their respective specs
23:46:11 <fantasai> dauwhe: Moved GC features into GC.
23:46:33 <fantasai> dauwhe: Also now a spec hadn't been published in 13 years, full of cool and interesting ideas from Håkon and Ian Hickson
23:46:44 <fantasai> dauwhe: Many things important to the Web, would like to publish
23:46:50 <fantasai> dauwhe: What we have now is an early-stage ED
23:47:02 <fantasai> dauwhe: fantasai and I did some work on this to bring it to state where we can present to WG and publish a new WD
23:47:09 <fantasai> dauwhe: Beyond that it really is WG decides
23:47:14 <Florian> q+
23:47:17 <tantek> ack TabAtkins
23:47:18 <Zakim> tantek, you wanted to ask what's the goal of this discussion? to move the spec forward? split spec levels?
23:47:21 <tantek> ack tantek
23:47:45 <fantasai> tantek: I"m agreeing what Elliott is aying, if we want to publish the WD, need to shrink it
23:48:09 <fantasai> tantek: If we want to publish REC track document, need to have a concerted effor tto split the features that are being actively developed vs. junkyard features into next level
23:49:21 <Rossen> q?
23:49:22 <dauwhe> q+
23:49:22 <Florian> q-
23:49:25 <fantasai> fantasai: This *is* a trimmed down spec, it's just not trimmed down to "browsers only" set of features
23:49:29 <gregwhitworth> fantasai: if the working group is not taking that as being trimmed down then the WG is not browser only
23:49:30 <Rossen> q?
23:49:46 <gregwhitworth> fantasai: we're working towards trimming it to get it to REC
23:49:51 <fantasai> dbaron: We shouldn't look at Ebook things as being separate from brwosers. Ebooks being in a browser is maybe a good thing
23:50:22 <ojan> q+
23:50:25 <fantasai> dauwhe: W3C and IDPF are working towards more integration
23:51:18 <fantasai> ?: We also creating ebub viewer, based on Blink, creating page generation with C++.
23:51:28 <fantasai> ?: I think generated content spec is not for WEb browsers, but for ebook viewers
23:51:29 <dbaron> s/?/skk/
23:51:34 <dbaron> s/?/skk/
23:51:42 <fantasai> ?: But if we have a chance, but we are using blink so we wnat to talk with Google web browser team to generate the page numbers
23:51:49 <fantasai> skk: Page numbers are async generated
23:51:52 <dbaron> s/?/skk/
23:52:06 <fantasai> ask: We already did the impl now, but the collaboration API specified between Blink and us would be very useful
23:52:13 <fantasai> skk: Also Gecko, better if API is specified
23:52:23 <fantasai> skk: Such kind of discussion is productive between Web and Ebook
23:52:31 <fantasai> skk: From ebook viewer implementer perspective
23:52:53 <fantasai> dauwhe: One thing in the spec that hasn't been implemented is trying to design a mechanism to make generated content more accessible
23:52:58 <fantasai> dauwhe: Which is a critical point
23:53:23 <dbaron> fantasai: not about exposing generation content, but about some generated content being symbols or pictures
23:53:46 <fantasai> dauwhe: Our idea was that the content property takes this endless tring of various bits of strings or replaced elements
23:53:58 <fantasai> dauwhe: We're proposing that at the end you can put a slash and then alt text
23:54:14 <dbaron> Tab: previous proposal was an 'alt' property
23:54:19 <fantasai> dauwhe: potentially empty, if the string is decorative (e.g. asterisks)
23:54:21 <dbaron> fantasai: bad because it doesn't cascade together with 'content'
23:54:36 <dbaron> (swap order of Tab and most recent dauwhe line)
23:54:37 <fantasai> dauwhe: This would also allow us to provide alt text for images inserted via content
23:54:47 <fantasai> plinss: Instead of using URL, maybe using image function?
23:54:56 <dbaron> plinss: ... and put alt text inside that function
23:55:08 <dbaron> (Though I wonder if you have decorative characters that you want alt text for!)
23:55:17 <fantasai> (you can, then you don't use an empty string!)
23:55:24 <fantasai> ojan: Ebooks as part of the Web is a good future
23:55:31 <fantasai> ojan: That's why I think sepccing these things is important
23:55:36 <fantasai> ojan: But think of it similar to SVG-CSS day
23:55:41 <fantasai> ojan: Where it's a special cross-functional meeting
23:55:58 <fantasai> ojan: To have an explicit Ebook Track, not necessarily in parallel, but be explicit about that section o the F2F
23:56:01 <teoli> teoli has joined #css
23:56:15 <fantasai> Florian: I thikn that's fine, a bit concerned about the boundary being fuzzy
23:56:31 <fantasai> ojan: I think being explicit about that might change whoat's plausible, practical to implement
23:56:44 <fantasai> ojan: E.g. target-counteR() is great as a feature, but not as a built-in browser feature
23:56:56 <fantasai> TabAtkins: Could have JS api about getting the counter value
23:57:17 <fantasai> Florian: I'm happy about being explicit about scheduling this in sections, less happy about putting it into the spec
23:57:28 <fantasai> TabAtkins: I don't like specs that web authors look at but don't know what to ue
23:57:32 <fantasai> Florian: caniuse.com
23:57:42 <fantasai> TabAtkins: I think authors should know whether such features will ever be useful
23:57:51 <fantasai> plinss: I don't want to be picky about language, but going to be picky about your language
23:58:04 <fantasai> plinss: Have no problem with your fundamental point "this is what's expected to be in browsers today"
23:58:14 <fantasai> plinss: But I have a problem with saying "this is never expected to be on the Web ever"
23:58:30 <fantasai> plinss: Saying up front "We don't ever exect this to work in a browser", that's going to change the future.
23:58:31 <tantek> q+ re: positive framing of implementation types
23:58:39 <fantasai> plinss: That's a bad way to scope the future
23:59:07 <fantasai> astearns: Has to be put in language that the current efforts are going to be in script, but that they may move into the browsers. And we don't have a good set of terms to talk aobut that migration purpose.
23:59:14 <fantasai> Florian: I'm not sure it's bad to get ppls' hopes up
23:59:15 <dauwhe> q+
23:59:26 <fantasai> Florian: If there's a lot of ppl that think people really want it, then it pushes forward
23:59:31 <fantasai> esprehn: GCPM didn't move forward for many years
23:59:37 <fantasai> Florian: Because it was a lousy spec
23:59:41 <fantasai> Florian: I don't want to have that again
23:59:51 <fantasai> Florian: People just didn't pay attention to junky spec "for print"
23:59:54 <fantasai> ...