15:54:50 <RRSAgent> RRSAgent has joined #css
15:54:50 <RRSAgent> logging to https://www.w3.org/2019/08/14-css-irc
15:54:52 <trackbot> RRSAgent, make logs public
15:54:55 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:54:55 <trackbot> Date: 14 August 2019
15:55:32 <aja> aja has joined #css
15:57:16 <gregwhitworth> present+
15:57:31 <Rossen_> present+
15:58:10 <dauwhe> present+
15:59:58 <myles> myles has joined #css
16:00:06 <rachelandrew> present+
16:00:32 <dael> Present+
16:00:33 <antonp> Present+ antonp
16:00:36 <dael> scribenick: dael
16:00:45 <smfr> smfr has joined #css
16:00:47 <dael> Rossen_: Still waiting for people to join. We'll get going in a couple minutes
16:01:58 <chris> chris has joined #css
16:02:04 <plinss> present+
16:02:22 <myles> present+ myles
16:02:29 <dael> Rossen_: We should get going
16:02:38 <dael> Rossen_: We have a pretty full agenda.
16:02:42 <drousso> present+
16:02:51 <jensimmons> jensimmons has joined #css
16:02:58 <dael> Rossen_: As usual, are there any additional agenda items you want to consider or any changes to current agenda?
16:02:59 <jensimmons> present+
16:03:03 <bradk> bradk has joined #css
16:03:26 <dael> Topic: 2020 Spring f2f dates
16:03:52 <dael> Rossen_: Gentile ping to see where we are with securing space. Ideally if we can lock the week down.
16:04:36 <dbaron> Present+
16:04:36 <stantonm> stantonm has joined #css
16:04:39 <dael> Rossen_: Not adding pressure to organizers, I know it's not easy. Apple folks, do you have any inclination as to if you're able to host? If yes, do you have readiness to commit to a week regardless of location?
16:04:49 <jensimmons> for quick reference: https://wiki.csswg.org/planning#upcoming-meetings
16:05:06 <dael> [we can't hear myles]
16:05:29 <dael> smfr: We need a week to get answers. Willing to host, need to see if availability for dates
16:05:41 <dael> Rossen_: When yous ay dates interested in this is the thing we wanted. What are the dates
16:05:45 <dael> smfr: Thought we had options
16:06:25 <dael> Rossen_: Currently only have constraints, but not an actual agreed week. That's why we're handing it to you to check if there's a better or easier week
16:06:31 <dael> smfr: We can look and come back with options
16:06:40 <jensimmons> the week of April 13 doesn’t work for me, and likely Rachel Andrew
16:06:51 <dael> Rossen_: Let's do that. If you can nudge myles or hober or whoever is handling to look at timing we can go from there
16:06:57 <dael> smfr: Any constraints, please add to wiki
16:07:15 <dael> Rossen_: Definitely. Add constraints now so as Apple looks at availability they can take those into account.
16:07:43 <dael> Rossen_: smfr and team as soon as you have preliminary plans ping us on the private list and we'll make plans. People are trying to arrange travel
16:07:51 <dael> smfr: Do we know normal headcount?
16:08:08 <dael> Rossen_: Usually 30 +/- 5. Location dependent
16:08:29 <dael> dbaron: I'll put in assuming the meeting spacing I'll put where our dates would be from Jan and TPAC.
16:08:55 <dael> Rossen_: We have Spring for Apple and Summer in Kyoto. dbaron if you want to add ideal space between we can go from there
16:09:09 <dael> florian: Kyoto is probably not in summer.
16:09:33 <dael> Rossen_: I think it was Kyoto/Tokyo/France/NYC so there's possibilities
16:09:45 <dael> Rossen_: I'm sure folks will get back to us.
16:09:51 <emilio> present+
16:09:53 <dael> Topic: Limits on text-underline-offset to preserve semantic meaning
16:09:59 <dael> github: https://github.com/w3c/csswg-drafts/issues/4059
16:10:20 <bradk> bradk has joined #css
16:10:28 <bradk> present+
16:10:38 <dael> myles: Apple delegation has done internal soul searching and we're now comfortable with no limit solution. No clamping
16:10:39 <bradk> Yay!
16:10:43 <florian> yay
16:10:48 <dael> Rossen_: Is that only thing we wanted to resolve?
16:10:53 <jensimmons> Excellent!
16:11:04 <dael> myles: I believe that's the only topic of conversation
16:11:32 <dael> fantasai: There's going to be a limit because UA has limit of what it can do. If the spec size is greater then that should underline be clipped or clamped?
16:11:54 <dael> fantasai: Let's say limit is 5 pages long. Author expects underline on 6th page. Is the underline on the 5th page or not rendered?
16:12:02 <dael> myles: Match text shadow which I believe is clipping
16:12:19 <dael> fantasai: Makes sense. If you get > a couple pages clamping gets you unexpected lines
16:12:29 <dael> TabAtkins: I think if it's >a few lines it's confusing so clipping is fine
16:12:44 <dael> fantasai: Prop: no limit. If passed what UA can render it's clipped
16:12:51 <florian> +1
16:12:53 <dael> Rossen_: Okay.
16:12:54 <fantasai> s/passed/past/
16:13:03 <dael> Rossen_: I'm the biggest non-fan but won't object
16:13:18 <dael> Rossen_: Any objections or comments or can we resolve?
16:13:23 <dael> Rossen_: Objections?
16:13:36 <fantasai> s/lines/lines, which might overpaint something unexpected/
16:13:36 <dael> RESOLVED: No limit. If past what the UA can render it's clipped
16:13:48 <dael> Topic: Rename `text-decoration-thickness` to `text-decoration-weight`?
16:13:56 <dael> github: https://github.com/w3c/csswg-drafts/issues/4138
16:14:05 <dael> Rossen_: Last week discussion narrowed to 2 choices.
16:14:30 <dael> Rossen_: Evenly distributed preference. More people voting thickness.
16:14:39 <dael> Rossen_: Are we ready to resolve on thickness?
16:14:40 <fantasai> largely due to the "no change from impl" principle
16:14:44 <dael> bradk: What are the 2?
16:15:41 <dael> rachelandrew: I opened this and didn't intend to re-open thickness vs width. My intention was to say is weight a good solution. I think it's great and makes sense to lots of people. Opposite is that text-decoration0weight doesn't match values. Seems like you guys disregarded weight.
16:15:47 <dael> rachelandrew: I'd rather keep thickness
16:15:54 <fantasai> s/rachelandrew/jensimmons/
16:15:55 <fantasai> s/rachelandrew/jensimmons/
16:15:58 <dael> rachelandrew /j jensimmons
16:16:26 <dael> Rossen_: Did rule out weight. Slight preference, but wanted majority of group to resolve on not change. That way FF can move forward and we can close the issue
16:16:50 <dael> jensimmons: Does look straw poll. Looks to me there was a definite preference for thickness, lots that didn't care. Some people preferred width.
16:17:05 <dael> fantasai: A number were due to not wanting a change. It wasn't so much preference as not change things
16:17:11 <dael> bradk: width is not under consideration?
16:17:26 <dael> Rossen_: Width was last week. We can take a straw poll again.
16:17:27 <fantasai> s/preference/preference for thickness/
16:18:24 <dael> Rossen_: Higher level discussion. We did rule out weight. Going to original issue it was rename thickness to weight and we can say no. In the middle of that width was brought up with some preference for width. Fine spending a few minutes about rename to width. Or just close original issue no change
16:18:25 <florian> abstain
16:18:31 <dael> Rossen_: Anyone want to straw poll?
16:18:55 <florian> s/c) weight/c) width/
16:19:02 <dael> bradk: I'd like width so consistent with other border thicknesses. I think it's unnec. congnative burden to remember which is which
16:19:38 <dael> myles: You're right about the burden. But also burden in calling it something unrelated to what it does. Web seatch to change underline the results say thickness. So people are clearly using that.
16:19:57 <dael> bradk: Boat has sailed. If we change to thickness we shuld have border-thickness and outline-thickness
16:20:06 <dael> myles: We've got 1 shipping impl and 1 non-shipping
16:20:15 <dael> bradk: I meant borders have thickness not width
16:21:21 <dael> jensimmons: Agree with myles . At the heart some people come at this from css prospective and they're looking for internal consistency and things should match. On the other hand there are folks who are looking at the words for what they are and consistency beyond CSS and intuitive for learning CSS. And they say it's okay because it makes sense in the larger world
16:21:48 <chris> Agree with myles and jen
16:21:51 <dael> jensimmons: Every time I see width I think it means the length of the line not the thickness. I totally understand where both prospectives come from. I think we don't share same way of looking at things.
16:22:24 <fantasai> border-width, outline-width, stroke-width
16:22:47 <dael> bradk: To me there's so many terms an author has to learn that having 2 terms for same concept is confusing and makes it harder to learn. New user that learned thickness of a border is border-width or an older user with that ingrained it's harder to remember text-decoration is thickness for the same concept of how wide the line stroke is.
16:23:24 <dael> Rossen_: I don't want to re-do the entire convo. I want us to resolve what is the stroke called. We ruled out weight. I see IRC advocating weight. I prefer to keep this to thickness vs width
16:23:37 <dael> Rossen_: I hear both sides and bradk has a valid case here for width.
16:23:43 <dael> Rossen_: Let's take a straw pool
16:24:34 <dael> jensimmons: I'm disappointed that I proposed weight and it was considered in a meeting where I wasn't there. Normally folks try and make people in the conversation. And now we're relitegating a decision. I'm surprised this happened because tha'ts not usually for the group
16:25:16 <dael> Rossen_: You had asked us to discuss without you here. We don't usually hold off when there's group consensus. Making decisions in that regard is fine and according to what we've been doing. It's also fine to bring the topic back and say you want to rediscuss something.
16:25:59 <florian> Jen did say we could decide without her. But if we are relitigating, I think her option should be included
16:25:59 <dael> Rossen_: We can have a straw poll of thickness vs width. Since you're bringing the point back if you want to reintroduce it let's add weight for completeness. We'll decide based on straw poll. Sound fair?
16:26:08 <fantasai> +1 to Florian
16:26:38 <dael> florian: Can we use fantasai straw poll?
16:26:38 <fantasai> suggestion was a) weight b) thickness c) width d) no change (= thickness)
16:26:45 <dael> Rossen_: Best to use same order as first time.
16:26:55 <dael> Rossen_: Nevermind, first didn't have weight
16:27:34 <dael> Rossen_: a) weight b) thickness c) width d) no change (= thickness)
16:27:37 <bkardell_> bkardell_ has joined #css
16:27:40 <myles> BBBBBBBBBB
16:27:41 <dael> Rossen_: Enter choices in IRC
16:27:43 <bradk> C) -width
16:27:45 <bkardell_> present+
16:27:45 <fantasai> c
16:27:46 <smfr> b
16:27:46 <astearns> d
16:27:47 <jensimmons> Prefers A. Would be ok with B.
16:27:47 <plinss> c
16:27:48 <chris> b
16:27:49 <drousso> b
16:27:49 <stantonm> b
16:27:51 <TabAtkins> b due to compat, c in my heart
16:27:52 <Rossen_> b
16:28:00 <fantasai> TabAtkins, that would be d :)
16:28:11 <TabAtkins> oh so I guess that's D, not B. Then C in my heart.
16:28:17 <dbaron> b or c
16:28:29 <rachelandrew> b
16:28:30 <florian> abstain
16:28:31 <dydz> dydz has joined #css
16:28:43 <drousso> drousso has joined #css
16:28:56 <emilio> b
16:29:07 <dael> Rossen_: Waiting on anyone?
16:29:15 <dauwhe> b
16:29:21 <dael> Rossen_: 10 seconds
16:29:29 <chris> looks like the winner is B
16:29:47 <dael> Rossen_: I think it's clear decision is thickness and no change to current spec
16:30:01 <dael> Rossen_: Resolve on no change to the current spec, thickness
16:30:13 <dael> RESOLVED: No change to the current spec, use thickness
16:30:22 <dael> Rossen_: jensimmons anything else FF engineers waiting on?
16:30:31 <dael> jensimmons: Another issue fantasai was writing text on
16:30:36 <dael> Rossen_: Anythong on the agenda?
16:30:39 <dael> jensimmons: No, thanks
16:30:51 <dael> Topic: Specify fallback behavior when replaced or background image content not available
16:30:59 <dael> github: https://github.com/w3c/csswg-drafts/issues/1984
16:31:13 <jensimmons> there might be clarifications needed about wavy and double lines…. https://github.com/w3c/csswg-drafts/issues/4134 fantasai was tasked with working on the spec.
16:31:32 <TabAtkins> https://github.com/w3c/csswg-drafts/commit/3f884b87c54b38afd7742fb8e123a7d27ddd3ac4
16:31:35 <dael> TabAtkins: When we spoke last time waiting on Apple; myles wanted to review. fantasai committed text for replaced image. Want to ensure spec did not rule out leaving image in place while waiting for new image
16:31:40 <fantasai> jensimmons, for the record, I think what I was actioned to write was that the line thickness, amplitude, and frequency should scale together (not necessarily strictly proportionally, but roughly proportionally), and double simlar to border-width: double in the same way
16:31:49 <dael> TabAtkins: If Apple wants to review that's fine but want to do soonish
16:31:57 <dael> myles: Can I give myself an end of week deadline?
16:32:02 <dael> TabAtkins: Next call is fine.
16:32:18 <dael> Rossen_: Next week's call is fine. TabAtkins anything else on this?
16:32:20 <dael> TabAtkins: It's good
16:32:27 <dael> Topic: Should the values of image-orientation include the <angle> variants?
16:32:33 <dael> github: https://github.com/w3c/csswg-drafts/issues/4164
16:32:56 <dael> smfr: WK is orkging on image-orientation. there's one with angles and one without. ANy other browsers interested in angle variants?
16:33:41 <dael> fantasai: B/c we made from-image default orientation I don't think strong use case for none. If not having web compat problems is this a necessary property? Still need definition b/c css print profile. If defaulting to exif do we nee dproperty at all?
16:33:49 <dbaron> I didn't think the <angle> values were useful...
16:33:50 <dael> TabAtkins: I don't recall affermative use cases for none
16:34:05 <dael> myles: easier to add css to fix a busted image then to rotate
16:34:28 <dael> fantasai: True. Ideally information should be in image or html. If photo is sideways it's data is wrong
16:34:42 <dael> [everyone tlaks]
16:34:45 <emilio> q+
16:34:59 <Rossen_> q?
16:35:18 <dael> fantasai: If you turn off css or in reader mode you want it to be upright. If image is wrong you should fundamentally fix and not patch with css
16:35:19 <emilio> https://groups.google.com/d/msg/mozilla.dev.platform/A1aaENcsR6k/fPB1AvyaCAAJ
16:35:55 <dael> emilio: Gecko impl the angle values and unshipped when spec deprecated it. I don't think it's a lot of work to re-implement them
16:36:07 <dael> dbaron: I also don't think that useful and a weird use of angles
16:36:15 <dael> myles: Under spec b/c don't say which orientation rotated from
16:36:32 <fantasai> rotated from the orientation before applying EXIF
16:36:42 <dael> TabAtkins: q on myles comment. Use case was something where image pixel are correct and exif is busted? Or more broad?
16:36:46 <svoisen> jensimmons: It's Charlie's last week so, while it would be nice to have additional language for clarity on rendering of wavy lines, it's not something we will get to in the very near term.
16:36:59 <dael> myles: Yes. Comment not about nalge value, but presence of property
16:37:13 <fantasai> svoisen, tell Charlie to make it look good :)
16:37:24 <fantasai> svoisen, since that's basically what the spec is going to try to say ;)
16:37:30 <jensimmons> fantasai: that’s what I said…. just make it purtier
16:37:46 <fantasai> s/fantasai:/fantasai,/
16:37:49 <dael> TabAtkins: With regards to angles unspec implication was rotation from none...says 0deg corrisponds to none. Implies you rotate from that. I don't think underspec, but can be tweaked. Hopefully don't need to be impl. They're there b/c print renderers have them.
16:37:55 <myles> TabAtkins: where does it say that 0 means none?
16:37:58 <myles> i don't see it
16:38:01 <svoisen> fantasai: Ha, fair enough :) We will have to save that as a task for someone else.
16:38:26 <dael> smfr: fantasai suggested removing prop. But if Moz has been shipping with from-image removing is tricky. emilio do you have info on how long shipped?
16:38:40 <Rossen_> ack emilio
16:38:45 <dael> emilio: I don't think we have use counters. Could add. Been shipping for a long time if I recall. I'll find a link
16:39:09 <dael> dbaron: If we're going to try and change default I would suspect that any of the things using it are doing so to set from-image not none
16:39:11 <dael> fantasai: +1
16:39:39 <dael> fantasai: Unless using it to set a value other than from-image there's not a change if we remove property. Already resolved to change initial to from-image so might not need property
16:40:09 <dael> smfr: Possible to get photos with bad exif information. If you pic straight down you get an angle. I can imagine trying to fix that. It does fail with things that strip css
16:40:42 <dael> fantasai: My inclination is impl that support this try and switch to from-image as default. Impl that don't change to from or exif. If that works we try and remove property. If it doesn't we keep
16:40:47 <dbaron> What fantasai just said sounds like a good plan to me.
16:40:59 <dael> plinss: If building photo editing software might want to show image naturally as it is and then manually rotate
16:41:08 <dael> TabAtkins: Editing you're parsing photo into a canvas?
16:41:35 <dael> plinss: Maybe. Could parse exif data yourself, but there is utility to keeping. Agree from-image and none ar only prop with from-image as default
16:41:49 <dael> Rossen_: unshipping of moz behavior and resolve on that behavior
16:42:04 <dael> Rossen_: Which way are we leaning?
16:42:21 <dael> TabAtkins: Fine with dropping if impl are okay on supposition we can make switch to from-image
16:42:48 <dael> plinss: Compat risk when I was writing code for this you don't know if browser will rotate and can't tell. Anyone with code that cares about this is already screwed so wouldn't worry about compat.
16:43:06 <dael> plinss: WOuld be nice if you can tell browser rotated but don't know how to tell in css
16:43:20 <dael> fantasai: Query size of box if it's not square and get aspect ratio. Can tell you a bit
16:43:33 <dael> plinss: But then have to parse image and then you might as well parse exif data
16:43:47 <dael> Rossen_: Leaning toward dropping image-orientation
16:44:37 <dael> fantasai: Prop: update note in draft to indicate we might drop the entire property for browsers and keep a definition with the <angle> values for historical reasons and say it's optional. Then remove. Or information this is in css print by not rec for impl
16:45:02 <dael> Rossen_: Prop: Update note saying this is not for implementation and will be dropped
16:45:05 <dael> Rossen_: Objections?
16:45:13 <dael> RESOLVED: Update note saying this is not for implementation and will be dropped
16:45:21 <dael> Topic: Publication
16:45:38 <dael> Rossen_: If we've got 1984 still open we'll push republish until next week
16:45:45 <dael> Topic: Should automatic list-item increment adjust for ol[reversed]?
16:45:53 <dael> github: https://github.com/w3c/csswg-drafts/issues/4181
16:46:10 <dael> TabAtkins: If we can achieve through UA stylesheet or do magic. Magic to host language or in css
16:46:17 <dael> TabAtkins: emilio points out [missed]
16:47:32 <dbaron> q+
16:47:41 <dael> fantasai: We have normal lists, they're great. We have reversed lists where increment is -1. Where you start is sept. Each li decrements counter needs to be implement. Only magic is that it's incremented by 1 on list item box
16:47:53 <fantasai> ol[reversed] > li { counter-increment: list-item -1; }
16:48:41 <dael> fantasai: Put in spec you can do on UA stylesheet. Works in general easy case. HTML spec includes any box with display of list-item in the numbering and excluses non-list-items. If you put a div in the li and give that a display: list-item it increments. THe list relies on the CSS
16:48:53 <dael> fantasai: You can't reflect the current behavior. I can try and share a test case
16:48:56 <TabAtkins> aka the [reversed] behavior is *literally* just "do normal list item numbering, then reverse all the numbers"
16:49:34 <dael> fantasai: 3 things we can do. 1) use UA stylesheet and get impl to do something different that doesn't account for display value of boxes. 2) have magic and host lang can change magic. 3) create css property that says what magic increment is
16:49:55 <fantasai> Behavior of li counting in HTML https://html.spec.whatwg.org/multipage/grouping-content.html#the-li-element
16:50:32 <dael> dbaron: I think there are a bunch of edge cases that suggest modeling this as a decrement is wrong approach. 2 ways to model. starting value is magic, items decremenet, counter goes forward. Other is counter counts from end to beginning. This is different results at times, like if you change counter in the middle
16:50:37 <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A
16:50:56 <dael> dbaron: Tend to think modeling this as magic to get the beginning and then decrements will get wrong result in a bunch of cases
16:51:13 <dael> TabAtkins: You think counting backwards and interacting with counter-set is good?
16:51:35 <dael> dbaron: I'm looking at browser behavior and actual behavior of value attribute with reverse is not sensible or interop
16:51:50 <dael> dbaron: Maybe value is already broken and other way is right
16:52:23 <dael> TabAtkins: Something odd in FF. FF and Chrome agree value effects following things and not proceeding. Differences in what number the very first item starts in. They agree it's count forward
16:52:29 <dael> dbaron: Maybe stuck with wrong model
16:52:41 <dael> TabAtkins: Both models have arguments. Fine with either
16:53:17 <dael> fantasai: Did run a test with decrement as -2 and it starts counting into negative numbers. Start number was no adjusted to account for that
16:53:25 <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Eli%20%7B%20counter-increment%3A%20list-item%20-2%3B%20%7D%3C%2Fstyle%3E%0A%3Col%20reversed%3E%0A%3Cli%20style%3D%22border%3A%20solid%22%3E%20x%3Cdiv%20style%3D%22display%3A%20list-item%22%3ETest%3C%2Fdiv%3E%0A%3Cli%3E%20y%0A%3Cli%3E%20z%0A%3C%2Fol%3E%0A
16:53:28 <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7121
16:53:42 <TabAtkins> Dunno why Firefox starts numbering at 7 even tho there are only six items.
16:53:44 <dael> Rossen_: From the 3 choices at the beginning seems like we're getting to none of them?
16:54:18 <dael> TabAtkins: Aside from that my test shows a weird start number, browsers seem consistent in how they treat things
16:54:56 <dael> TabAtkins: Figure out value of last item that would incremement, use that as the first value. Figure out magic value where if nothing screws with numbering gets you to 1 and then start at that ind do minus 1
16:55:14 <dael> TabAtkins: I'm on side of UA magic so there's interop I don't believe css needs to control on it's own.
16:55:42 <dael> dbaron: html editors might be unhappy. html editors seem unhappy that css claims their stylesheets are doing wrong thing
16:56:09 <dael> TabAtkins: [missed] reverse engineering at the time and we're saying do this with css now. Seeing you got no bugs I think we're fine and we can do this
16:56:23 <dael> fantasai: Still not clear on how reverse is supposed to work.
16:56:56 <dael> fantasai: Would liek to get updated draft published b/c cleaned up counters section substanitally. WE should publish and mark reverse lists as an open issue.
16:57:29 <dael> fantasai: Should we publish draft with previous state or should we publish with the concept of the magic increment? SHould leave issue open, but what to publish with
16:57:54 <dael> fantasai: Inclination is publish no change from previous b/c that's clear we have not solved and update later after we conclude
16:58:18 <dael> Rossen_: Do you want to discuss next before publish?
16:58:40 <fantasai> Topic: counter(name, none) should be invalid
16:58:43 <fantasai> github: https://github.com/w3c/csswg-drafts/issues/4163
16:58:43 <dael> Topic: counter(name, none) should be invalid
16:58:46 <dael> github:  https://github.com/w3c/csswg-drafts/issues/4163
16:59:37 <dael> fantasai: If you say counter(name,counter-style) it represents list using that. There is a none value that's value of list-style-type. Some impl think that's valid as a counter style. CSS 2.1 forbids that. I updated spec to match css2.1
16:59:54 <dael> fantasai: If people disagree and think counter(name, none) should be valid we can reconsider
17:00:07 <dael> TabAtkins: I wrote that near 10 years ago. Can't comment on [missed] so whatever
17:00:18 <TabAtkins> s/[missed]/justification
17:00:20 <bradk> bradk has joined #css
17:00:29 <dael> fantasai: Objections to updating spec to match 2.1?
17:00:36 <TabAtkins> No objection.
17:00:43 <dael> RESOLVED: Update to match 2.1 and make counter(name, none) invalid
17:00:48 <dael> Topic: publication
17:00:55 <bradk> Tab’s words cut off at exactly 10:00
17:01:22 <dael> Prop: Republish css lists 3 with everything changed and open topic on reverse counters and reverse to previous draft state
17:01:43 <TabAtkins> I want ot make sure we're not putting the ol[reversed] rule back in the stylesheet.
17:01:51 <TabAtkins> Because that def doesn't match any implementation whatsoever.
17:01:54 <drousso> drousso has joined #css
17:02:01 <TabAtkins> And never will.
17:02:10 <TabAtkins> Okay so I'm opposed to putting it back in any case.
17:02:23 <dael> fantasai: stylesheet in appendix we hsould put it back and make it clear it's ain interpretation. Also okay not mentioning reverse at all and removing it
17:02:33 <dael> Rossen_: Okay republishing with removing?
17:02:34 <TabAtkins> Yeah, let's remove all official mention, and just have a note that "hey this exists, we'll define hwo it works later"
17:02:40 <dael> fantasai: Yes, if removed and not says it's magic
17:02:41 <fantasai> wfm
17:02:48 <dael> Rossen_: Will republsish with issue open
17:03:07 <dael> Rossen_: Objections to republish lists 3 with open issue on ol[reverse] and reversed counter
17:03:29 <dael> RESOLVED: republish lists 3 with open issue on ol[reversed] and reversed counter
17:03:33 <dael> Topic: end
17:04:32 <dbaron> Also, I updated https://wiki.csswg.org/planning with "evenly spaced" meeting dates, so if people have conflicts in late April or late July, those are particularly important to note.
17:05:07 <Rossen_> trackbot, end meeting
17:05:07 <trackbot> Zakim, list attendees
17:05:07 <Zakim> As of this point the attendees have been gregwhitworth, Rossen_, dauwhe, rachelandrew, dael, antonp, plinss, myles, drousso, jensimmons, dbaron, emilio, bradk, bkardell_
17:05:15 <trackbot> RRSAgent, please draft minutes
17:05:15 <RRSAgent> I have made the request to generate https://www.w3.org/2019/08/14-css-minutes.html trackbot
17:05:16 <trackbot> RRSAgent, bye
17:05:16 <RRSAgent> I see no action items