-
Rossen_
Zakim, start meeting
-
Zakim
inviting RRSAgent
-
RRSAgent
-
Zakim
RRSAgent, make logs Public
-
RRSAgent
I have made the request, Zakim
-
Zakim
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
-
Rossen_
present+
-
dael
present+
-
dael
ScribeNick: dael
-
futhark
present+
-
oriol
present+
-
chris
present+
-
rachelandrew
present+
-
florian
present+
-
dholbert
present+
-
antonp
Present+ antonp
-
chrishtr
present+
-
miriam
present+
-
dael
Rossen_: We're going to start in another couple of minutes
-
faceless2
present+
-
dandclark
present+
-
gregwhitworth
present+
-
plinss
present+
-
chrishtr
present+
-
GameMaker
present+
-
alisonmaher
present+
-
dael
Rossen_: It's a couple past the hour
-
TabAtkins
present+
-
dael
Rossen_: Let's get going
-
dael
Rossen_: First, sorry I made a typo in the subject line. The call is indeed today.
-
dael
Rossen_: I must have looked at the MathML call. That is happening tomorrow
-
myles
present+ myles
-
dael
Rossen_: As a reminder part 2 is happening tomorrow starting at 9:15PT
-
» florian today is the 17th as far as I am concerned, so I was fine with the mail
-
dael
Rossen_: Details are sent by astearns to the private list
-
rego
present+
-
Guest60
present+
-
Guest60
present-
-
jensimmons
present+
-
dael
Rossen_: Extra agenda items. One we'll take when we get going but I wanted to hear if there are any other items to discuss before we get going
-
dael
fantasai: Process 2020 is in effect now
-
» gregwhitworth woohoo - congrats fantasai and florian
-
dael
Rossen_: Woo! Congratulations, I know this was a big effort
-
chris
bikeshed already supports it
-
florian
If anyone's not up to date, change section here:
w3.org/2020/Process-20200915/#changes-2019
-
dael
Rossen_: Huge thank you to you and florian from this form for supporting it
-
dael
Topic: Upcoming Joint Meetings
-
dael
Rossen_: If this was a normal time we'd be meeting together for TPAC F2F. That's virtual.
-
dael
Rossen_: As part of this we reached out to some of the more frequent joint meeting WGs.
-
fantasai
-
dael
Rossen_: So far we have joint meeting with i18n group and APA/A11y group
-
dael
Rossen_: One more proposed by gregwhitworth is if interest to have OpenUI. gregwhitworth can you brief us?
-
emilio
present+
-
dael
gregwhitworth: It's a community group. Most things on the list we could do in CSSWG. Goal is we keep talking about form controls and styling and things that the group is talking about in a holistic view.
-
cbiesinger
present+
-
TabAtkins
+1
-
dael
gregwhitworth: I provided items to see if there was interest. Wanted to know if there was interest in getting together to talk about form control styling, possible improvements to built in controls with OpenUI and CSSWG
-
» cbiesinger oops, forgot to present+ earlier
-
dael
Rossen_: Thoughts?
-
» dholbert koji I think we might be getting some background noise from your mic
-
» fantasai happy to participate
-
astearns
+1 to meet with OpenUI
-
miriam
+1
-
dael
gregwhitworth: Seeing stuff on IRC
-
drousso
present+
-
dael
Rossen_: That's what I was expecting for interest
-
jensimmons
+1
-
dandclark
+1
-
dael
Rossen_: Let's call this one that we'll have a joint meeting. You astearns and I will work out details offline
-
smfr
present+
-
dael
Topic: [css-logical] Mapping of logical values in 'resize'
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #3281 ([css-logical] Mapping of logical values in 'resize' ).
-
dael
oriol: The thing is that as css logical spec added logical values for existing properties. For each question of if they should resolve using writing mode of element or its containing block
-
dael
oriol: Some past resolutions on this. text-align we resolved we should use writing mode of element. Float and clear which effect element we use writing mode of containing block.
-
dael
oriol: Question is on resize property
-
dael
oriol: Impl don't agree with this.
-
dael
oriol: FF doesn't obey previous resolutions. For float, clear, and resize they use writing mode of element.
-
dael
oriol: They shipped
-
dael
oriol: In Chromium I used containing block for these three properties but it's behind a flag
-
dael
oriol: In issue fantasai provided some points to consider. resizing can effect size of box but also available space for contents. You can see it both ways and it's not clear which we pick
-
dael
oriol: No strong opinion, just want to decide on something
-
dael
Rossen_: Don't know if folks have read through 3 points from fantasai. Wanted to hear if there are strong opinions
-
dael
florian: Weak opinion to favor element
-
dael
TabAtkins: same
-
dael
smfr: Any version where those are physical?
-
dael
florian: Yeah, you can. Quesiton is when you say inline.
-
dael
Rossen_: Also more inclined to element
-
bkardell_
present+
-
dael
Rossen_: Anyone who prefers to have inline refer to containing block?
-
dael
Rossen_: Some of fantasai points are that layout and resize of element usually effect containing block and might make sense to have this as function of containing block. That's why other option is considered
-
fantasai
I think I have a mild preference to containing block.
-
fantasai
Use cases are things like sidebars and textarea
-
dael
Rossen_: Still hear if we resize based on element's inline for same purpose I think that although this is layout effecting it makes sense to be element itself
-
dael
smfr: Logical versions of overflow-x and -y? I can't find it.
-
dael
florian: I think so.
-
fantasai
-
emilio
q+
-
» Zakim sees emilio on the speaker queue
-
dael
smfr: Was thinking resize should match overflow.
-
dael
oriol: Overflow uses element writing mode
-
dael
smfr: Argument for resize to do same
-
Rossen_
ack emilio
-
» Zakim sees no one on the speaker queue
-
dael
emilio: Did we decide...for float and clear computed value needs to be logical. What FF impl is these logical properties where logical value is computed to phsyical at computed time which doesn't work for containing block. Where we use writing mode of containing block computed value needs to be logical value
-
dael
fantasai: Yeah. Value is always itself and never computes phsyical
-
dael
emilio: Makes sense. Could effect inheritence
-
dael
Rossen_: Obj to have the logical value of resize that of the element itself?
-
dael
RESOLVED: have the logical value of resize that of the element itself
-
fantasai
s/inheritance/inheritance, but most of these don't inherit/
-
dael
Topic: [css-text] Reconsider the resolution on #855
-
-
oriol
emilio: Logical values computing as-is was resolved in
w3c/csswg-drafts #2821#issuecomment-415092595
-
» github-bot Because I don't want to spam github issues unnecessarily, I won't comment in that github issue unless you write "Github: <issue-url> | none" (or "Github issue: ..."/"Github topic: ...").
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #5410 ([css-text] Reconsider the resolution on #855).
-
emilio
oriol: great, just wanted to make sure that there was a resolution on that, thanks!
-
» tantek regrets+
-
emilio
oriol: a bit odd that it behaves differently from logical props but maybe not too much :)
-
bradk
present+
-
» tantek Zakim, who is here?
-
» Zakim Present: Rossen_, dael, futhark, oriol, chris, rachelandrew, florian, dholbert, antonp, chrishtr, miriam, faceless, dandclark, gregwhitworth, plinss, GameMaker, alisonmaher,
-
» Zakim ... TabAtkins, myles, rego, jensimmons, emilio, cbiesinger, drousso, smfr, bkardell_, bradk
-
» Zakim sees on irc: bradk, AmeliaBR, bkardell_, smfr, xiaochengh, drousso, alisonmaher, myles, masonfreed, jensimmons, chris, futhark, vmpstr, dholbert, RRSAgent, Zakim, antonp, Rossen_,
-
» Zakim ... oriol, dael, tantek, rego, dauwhe_, plh, castastrophe, ankh___, sylvaing, shans, Rossen, leaverou, projector, hober, geheimnis`, Karen, zcorpan, dustinm, dino, heycam|away,
-
» Zakim ... CSSWG_LogBot, ondrejko, github-bot, Mek, emilio, slightlyoff, sangwhan, faceless2, achraf, sanketj, dtapuska, dandclark, jcraig, svoisen, spectranaut, logbot, Travis, iank_,
-
» Zakim ... kereliuk
-
fantasai
emilio, it would have been necessary for text-align to actually work as expected :)
-
dael
florian: We resolved control characters are displayed visually. As part of that the CR character, carrage return, is supposed to be the same. Most of the time you can't notice b/c handled by HTML parser. But if you inject it you should see it. No one does it.
-
emilio
fantasai: fair enough :)
-
dael
florian: Mostly can't see, Chrome sometimes replaces with ordinary space. Did testing to see what kind of invisible people do. It's all over the place. Everyone does a weird varient
-
dael
florian: Suggestion is treat as ordinary space. Depending on whitespace property it may be collapsable. Partially matches Chrome. When whitespace is normal Chrome does that. When whitespace is not normal Chrome does different things.
-
dael
florian: Suggestion is from fantasai and I think it's good. This is kind of an error case
-
dael
emilio: filed it b/c wikipedia was complaining. Not sure about nobody uses it
-
dael
florian: Do they want it to do something?
-
dael
emilio: No, Gecko was doing something more weird. I fixed that more weird but when I looked how to handle it was all over the place as you said.
-
dael
florian: So I think you for the opportunity to write fun tests. Now that I've had my fun how about we change to a space and move on
-
dael
s/think/thank
-
dael
emilio: Okay with that but a change for all engines
-
dael
florian: Yeah. In main case it's what Chrome does
-
dael
chrishtr: #2 on yoru option list always?
-
dael
florian: Yes. It behaves as any space on whitespace:pre
-
dael
chrishtr: So Chrome just needs whitespace:pre to change?
-
fantasai
proposed resolution is "treat as U+0020"
-
dael
florian: Yeah, maybe other non-normal. I don't recall.
-
dael
smfr: Makes me a little nervious b/c they're more common in mac.
-
dael
florian: Yeah. Probably not shoing because actual carriage return is handled. It's an explicit escape
-
dael
smfr: Worried files converted to user entities.
-
dael
florian: Could. but what happens now is everybody is different
-
dael
Rossen_: I see soft agreement by koji on issue. Sounds like emilio is fine for Gecko to try.
-
dael
smfr: I won't object. I think we'd have to try it and see what happens
-
dael
Rossen_: Let's try and resolve. If we see a lot more information saying this is causing crazy breaks we'll discuss again
-
dael
florian: I think behavior in safari and FF isn't crazy but i could find so many ways to make something visual that this seemed a lot simpler
-
dael
florian: Prop: Treat CR as an ordinary space
-
dael
florian: I'll be more exact in spec
-
dael
Rossen_: Objections?
-
dael
RESOLVED: Treat CR as an ordinary space
-
dael
Topic: Interoperable font metrics
-
-
dael
-
-
dael
myles: There's this problem. Problem is font files have a bunch of different metrics and many conflict.
-
dael
myles: Most egregious is there are 3 different asc and desc metrics in open type font files. All different numbers. Some browsers use some, others use others.
-
dael
myles: Some use metrics not even in the file. It's the wild west
-
dael
myles: This is an interesting problem b/c all text is rendered with whatever metrics the browser happens to use. Any solution that's browser Y should switch is a pretty scary change. It changes all text on the web. So I think it's nto a good solution
-
dael
myles: Looked for better. A few design principles I wanted to abide by. All text should not be changes. Browsers should not have to parse font files themselves, they should be able to delegate to lower level libraries.
-
dael
myles: Last is that we don't want to have different metrics for some properties than others. If we do that you end up with inconsistent typography and poor design
-
dael
myles: Given those requirements I think best way to solve is for CSS authors in CSS to override metrics inside font file. The mechanism for doing this is a new descriptor or set of descriptors in font-face block. A css author can override the font file metrics and say please instead use 80%em for asc.
-
dael
myles: Satisfies constraints and gives consistency if authors use this. And if browser doesn't understand it falls back to font file.
-
chris
q+ to wonder if Chrome is proposing or arguing against a descriptor
-
xiaochengh
q+
-
» Zakim sees chris on the speaker queue
-
» Zakim sees chris, xiaochengh on the speaker queue
-
dael
myles: For problem at hand I think this is a fairly good design. Interested to hear thoughts.
-
Rossen_
q?
-
» Zakim sees chris, xiaochengh on the speaker queue
-
Rossen_
q+ TabAtkins
-
» Zakim sees chris, xiaochengh, TabAtkins on the speaker queue
-
Rossen_
ack chris
-
Zakim
chris, you wanted to wonder if Chrome is proposing or arguing against a descriptor
-
» Zakim sees xiaochengh, TabAtkins on the speaker queue
-
dael
chris: Reading thread I'm puzzled. I see people from chrome saying they don't want descriptors and existing ones should be removed. See others from chrome proposing descriptors. I appreciate opinions can change but would like to know their current opinion.
-
Rossen_
ack xiaochengh
-
» Zakim sees TabAtkins on the speaker queue
-
dael
xiaochengh: From chrome side we do want descriptors. Earlier comment opposing was mostly from impl side. We've prototyped the descriptors behind a flag so impl isn't an issue.
-
dael
chris: Does that only apply to these descriptors or also to previous descriptors?
-
dael
chrishtr: Which did you have in mind?
-
myles
q+ to talk about descriptors vs properties
-
» Zakim sees TabAtkins, myles on the speaker queue
-
dael
chris: Dominic pointed to other issues saying removed font-varient and would like to remove other overrides. Basically, are you now happy with these or still look at removing?
-
dael
xiaochengh: Others aren't covered, should look independently
-
faceless2
q+
-
» Zakim sees TabAtkins, myles, faceless on the speaker queue
-
dael
chrishtr: In favor of adding the ones xiaochengh mentioned as well as asc one from myles
-
TabAtkins
q-
-
» Zakim sees myles, faceless on the speaker queue
-
Rossen_
ack myles
-
Zakim
myles, you wanted to talk about descriptors vs properties
-
» Zakim sees faceless on the speaker queue
-
fantasai
strong +1 to using descriptors, strong -1 to using properties for this
-
faceless2
q-
-
» Zakim sees no one on the speaker queue
-
una
present+
-
dael
myles: Talk directly about descriptor vs property. Descriptors are a direct natural fit to way metrics are handled by browsers. When you use a font face you have a font associated. Way to impl this is when you pull out metrics remove that and slot in from the rule.
-
chris
I agree that descriptors seem like a good fit here, beter than propoerties as Myles said. I just didn't want a solution tht had been argued against in the past.
-
florian
agreed, descriptors are a much better fit indeed.
-
dael
myles: If we wanted to move to property not against but tricky problems like how does font fallback work if you have nested element with different font family. Multiplier on font size? A bunch of questions. If we can answer that's fine but descriptor approach means we don't have to.
-
dael
chris: Agree they're a better fit
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
TabAtkins
q+
-
» Zakim sees TabAtkins on the speaker queue
-
» fantasai q+
-
» Zakim sees TabAtkins, fantasai on the speaker queue
-
dael
myles: I can also talk about the 2 additional descriptors from xiaochengh. line gap amkes a lot of sense. Advanced override I'm not against but unanswered questions about how interacts with letter-spacing. Letter-spacing is not a simple property.
-
dael
myles: Would be unfortunate if we had 2 ways of effecting letter-spacing and they worked differently. So there's still some design work for that one. line-gap-override makes sense
-
xiaochengh
q+
-
» Zakim sees TabAtkins, fantasai, xiaochengh on the speaker queue
-
dael
TabAtkins: There is 2 separate mechnically things to do that are letter-sapcing like. Advance-override solves making sure monospace isn't screwed up with fallback. You want to effect advance of a letter to make sure they have exact width of primary font.
-
» fantasai q- later
-
» Zakim sees TabAtkins, xiaochengh, fantasai on the speaker queue
-
florian
q+
-
» Zakim sees TabAtkins, xiaochengh, fantasai, florian on the speaker queue
-
» fantasai ack TabAtkins
-
» Zakim sees xiaochengh, fantasai, florian on the speaker queue
-
Rossen_
ack TabAtkins
-
» Zakim sees xiaochengh, fantasai, florian on the speaker queue
-
dael
TabAtkins: Nothing to do with variable width fonts. That wants to be more like letter-spacing so you don't have awkward spaces. Have to be different and separate. advance-override which is make monospace work with fallback is straightforward
-
dael
myles: Yeah, proposal from 8 days ago says it adds additional space. I don't think it satisfies the use case
-
dael
TabAtkins: Would for monospace
-
dael
myles: Not for font fallback
-
dael
TabAtkins: Yes, if you know width of primary and fallback you add the space. Using override is unfortunate name
-
Rossen_
ack xiaochengh
-
» Zakim sees fantasai, florian on the speaker queue
-
dael
xiaochengh: proposal is add a constant to advance of glyph. I agree we should rename the descriptor.
-
dael
xiaochengh: At this moment problem with variable width font is value of this descriptor has to be tried manually. Agree there's a design issue but we do want this descriptor
-
dael
myles: We can open up a few issues
-
dael
fantasai: I strongly want advance-override to be in a separate issue. Needs to be discussed in more detail. Monospace case also has a bunch of considerations. Not sure why adding a fixed value is right because ratio change.s It's a crude fixup.
-
chris
Flashback to 1997 - all the widths in a descriptor
w3.org/TR/WD-font-970721#widths :)
-
myles
+1 to fantasai re:advance-override
-
florian
+1
-
dael
fantasai: On main prop for asc and desc it's fine. Had discussed similar for super and subscript metrics
-
jfkthame
+1 here too
-
fantasai
s/change.s/changes depending on the exact font/
-
fantasai
s/ratio/ratio of advance widths for different letters/
-
dael
chrishtr: Agree we should split advance-override. I think this is appropriate to 2nd use case from xiaochengh more than the original one brought by myles. Split and continue to discuss
-
florian
q-
-
» Zakim sees fantasai on the speaker queue
-
Rossen_
ack florian
-
» Zakim sees fantasai on the speaker queue
-
Rossen_
ack fantasai
-
» Zakim sees no one on the speaker queue
-
dael
Rossen_: Other comments? If not are we coming to resolution?
-
dael
fantasai: Prop: add asc and desc and linegap-ooverride as fontface descriptors
-
dael
myles: and they take %s
-
dael
Rossen_: Objections?
-
» fantasai has a follow-up though
-
dael
chrishtr: sgtm
-
dael
RESOLVED: Add ascent, descent, and lanegap override as fontface descriptors that take %
-
fantasai
s/lanegap/line-gap/
-
dael
fantasai: While we're on topic should we add the super and subscript variants
-
faceless2
+1 from me on @fantasais additions
-
dael
chrishtr: Sound interesting, want to look more
-
» myles fantasai: what about text-decoration-position and text-decoration-thickness? Those properties accept from-font, and this would affect that value
-
dael
fantasai: Briefly, font has metrics on amount to shipt up/down for super/subscript and says what size as function of font size. If font provides a glyph it's supposed to provide ones that match. If you don't have glyph UA can synth by resizing. IN order to get that to match you need metrics and a lot of fonts don't have
-
dael
chrishtr: Is there difference between OS and browsers?
-
dael
fantasai: No, font metrics are frequently wrong
-
fantasai
-
dael
Rossen_: This is very much related but I would prefer we open a new issue where more thought can be given. fantasai can you open that?
-
dael
fantasai: Yep
-
dael
Topic: [css-fonts] Proposal to extend CSS font-optical-sizing
-
-
dael
-
» github-bot OK, I'll post this discussion to
w3c/csswg-drafts #4430 ([css-fonts] Proposal to extend CSS font-optical-sizing).
-
» fantasai myles, yeah I was thinking about that, too
-
dael
Rossen_: A rather large issue
-
dael
myles: This font-optical-sizing property takes 2 values, auto and none
-
Rossen_
q?
-
» Zakim sees no one on the speaker queue
-
dael
myles: Optical sizing is a way for letters to effect shape of outlines. On large sizes letter shapes are more delicate for visual beauty and when small serifs are elongated. Fonts can morph shape
-
dael
myles: Impl with a variable feature. Inside the fonts the variable axis is set to the font size.
-
dael
myles: Webkit sets to css pixel size. I think all browsers do, but not sure.
-
dael
chris: They do not which is the problem
-
dael
myles: Okay
-
dael
myles: Another piece of information is open type spec which defines that axis says that this is supposed to be set to font size in points. Not css points, but points. Relevant to MacOS and iOS.
-
dael
myles: Actual proposal is to extend syntax to not just be none and auto but add a number that's more expressive so authors can say if they want font size to be css pixels, css points, or something else.
-
dael
myles: I have opinions but want to let others speak.
-
dael
myles: I guess I can mention why I think it's bad. There is a right answer which is what open type spec says. On MacOS and iOS the OSs have a coordinate system. Designed such that 72 typographic points = 1 physical pixel.
-
chris
q+
-
» Zakim sees chris on the speaker queue
-
dael
myles: In webkit we want integral sized pixel blanks on physical pixel boundaries. We have 1 css pixel = 1 typographic point. Gives crisp backgrounds. 1 css inch = 4/3 typographic inches.
-
dael
myles: Means if you want length supplied in typographic points the way you get that on webkit is you supply css pixels. That's how we've defined it. It's correct though not intuitive. The spec...no reason to increase flexibility because we're doing it correctly.
-
dael
chris: Backing myles up. He's explained how it comes to correct way. Others have seen that webkit sets in css pixels but don't have the rest so it comes out wrong. It's a problem. Easiest solution is for other browsers to fix it which is as simple has multiplying by 4/3.
-
Rossen_
ack chris
-
» Zakim sees no one on the speaker queue
-
» fantasai wonders if jfkthame is on the call
-
dael
chris: I think the proposal which is on this thread and on opentype list they assume browsers won't change so they need to fix it in the spec. I would prefer the other browsers did it so they get correct size and then we don't need anything else.
-
dael
chris: jfkthame did point out the way the others browser do it. I hope he's on.
-
dael
fantasai: Quesiton. If I write a document in MS word and say font size is 12 pt and have optical sizing enabled, print it. export to HTML. print that. Sizes are 12pt in both cases. Do I get different results?
-
dael
chris: Interesting. Size in both prints and size on screen. I don't know.
-
dael
fantasai: Authors would expect to render the same
-
dael
chris: Yes
-
dael
fantasai: Can we make sure that happens? I'm confused as to what is happening but I think that should be a constraint.
-
faceless2
There is no support in PDF or PostScript for variable fonts. So any optical-sizing axis adjustments are done before the print layer, in the application.
-
chris
q+
-
» Zakim sees chris on the speaker queue
-
dael
myles: Relevant piece here is the scale...on MacOS and iOS we have 1 typographic point = 1 css pixel. When you print that may not be true. COuld come out same even if you see on screen different for OS.
-
dael
fantasai: Suppose I have a doc I'm looking at on screen. Optical sizing axis has significant differences. Will I get different shape text when print? Should I?
-
dael
myles: You could, yes. CSS units to typographic units is different when printing. Could be because we've picked this scale because of screens. When printing don't have that.
-
dael
fantasai: Optical sizing is change in glyph shape. What does it have to do with crispness of glyph?
-
dael
myles: Sorry. We've scaled entire css coordinate system by 1/3. That's b/c in web today authros say 4px for things like border and margins. All over the place. If we made it such that 1 css inch = 1 typo inch the px length would not map to a physical pixel. Solved by scaling hte entire css coordinate system by 1/3 so things lie on pixel boundaries more often.
-
dael
fantasai: ...okay
-
dael
chris: True of original mac. Seems like high dpi devices there are more options. I guess these are micro-pixels?
-
dael
myles: I'd like to not talk retina.
-
dael
chris: I would because they're relevant
-
bradk
Not every iPhone has a Retina display
-
» fantasai q+ to summarize what I think is the problem
-
» Zakim sees chris, fantasai on the speaker queue
-
dael
myles: There's a 3rd system. There's phsyical if you measure crystal size. Not relevant b/c impacts by manufacturing process. More relevant is typographic b/c that's what OS is designed with.
-
dael
myles: If I want something 1 inch big on an app I'll use pixels. Assumption is that because OS is designed with a coord system if you make something a certain number of points in the coord system it'll look close on the phsyical screen.
-
chris
q-
-
» Zakim sees fantasai on the speaker queue
-
dael
Rossen_: At the hour and need to wrap. We're in the middle of the conversation. I see chris and fantasai on the queue so I encourage them to continue discussing on the issue and we can resume next week.
-
dael
fantasai: Summary- What i'm saying is on the OS system level in different apps. Non web borwser 1pt = 1px. Within css 1 pt and 1 px and not same. So 1 css pt is different. When you print the points are equat to each other. We have inconsistent matchups. Issue is that WK choose to go along one set of eq. lines and hte people filing the issue picked a different set.
-
fantasai
s/saying/understanding/
-
dael
Rossen_: Let's resume in issue. myles when you feel it's ready please bring it back
-
dael
topic: end
-
-
dael
Rossen_: Reminder there's a MathML call tomorrow.
-
florian
MathML is same time +15m, right?
-
bkardell_
yes
-
florian
Probably going to miss it. Interesting topic, but 1:15am isn't all that awesome, especially when it's the 3rd one in the same week
-
TabAtkins
go to bed florian
-
astearns
zakim, end meeting
-
Zakim
As of this point the attendees have been Rossen_, dael, futhark, oriol, chris, rachelandrew, florian, dholbert, antonp, chrishtr, miriam, faceless, dandclark, gregwhitworth,
-
Zakim
... plinss, GameMaker, alisonmaher, TabAtkins, myles, rego, Guest, jensimmons, emilio, cbiesinger, drousso, smfr, bkardell_, bradk, una
-
Zakim
RRSAgent, please draft minutes
-
RRSAgent
I have made the request to generate
w3.org/2020/09/16-css-minutes.html Zakim
-
Zakim
I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye
-
» RRSAgent excuses himself; his presence no longer seems to be needed