IRC log of css on 2017-02-15

Timestamps are in UTC.

00:01:41 [jcraig]
jcraig has joined #css
00:04:05 [antonp]
antonp has joined #css
00:17:29 [dauwhe]
dauwhe has joined #css
00:22:50 [TabAtkins]
fantasai: Align is published.
00:34:59 [jcraig]
jcraig has joined #css
00:45:01 [antonp]
antonp has joined #css
00:54:40 [stryx`]
stryx` has joined #css
00:55:03 [antonp]
antonp has joined #css
01:03:28 [antonp]
antonp has joined #css
01:09:53 [antonp]
antonp has joined #css
02:01:07 [zcorpan]
zcorpan has joined #css
03:01:32 [zcorpan]
zcorpan has joined #css
03:56:02 [Florian]
Florian has joined #css
04:02:57 [zcorpan]
zcorpan has joined #css
05:03:22 [zcorpan]
zcorpan has joined #css
05:16:02 [myles]
myles has joined #css
06:41:12 [antonp]
antonp has joined #css
06:49:16 [liam]
liam has joined #css
06:55:19 [zcorpan]
zcorpan has joined #css
07:36:29 [liam]
liam has joined #css
08:32:00 [stryx`]
stryx` has joined #css
08:34:37 [Ms2ger]
Ms2ger has joined #css
09:13:29 [svillar__]
svillar__ has joined #css
09:22:36 [logbot]
logbot has joined #css
09:26:33 [glazou]
glazou has joined #css
09:40:27 [lajava]
lajava has joined #css
09:40:59 [svillar__]
svillar__ has joined #css
10:49:09 [jnurthen]
jnurthen has joined #css
12:58:40 [plh]
plh has joined #css
13:49:51 [Karen]
Karen has joined #css
14:17:04 [jcraig]
jcraig has joined #css
14:26:28 [dauwhe]
dauwhe has joined #css
14:32:03 [zcorpan]
zcorpan has joined #css
14:32:24 [zcorpan]
zcorpan has joined #css
14:42:00 [fantasai]
TabAtkins: Same diff. Implementations are free to use magic to implement it, but it should behave the same. If that set of rules does not yield Web-compatible behavior then we need to fix it so it is, so that the “magic” behavior is defined.
15:47:38 [zcorpan]
zcorpan has joined #css
16:50:17 [antenna]
antenna has joined #css
16:53:34 [tgraham]
tgraham has joined #css
16:55:09 [dael]
dael has joined #css
16:55:28 [ChrisL_]
ChrisL_ has joined #css
16:55:55 [Guest87]
Guest87 has joined #css
16:58:00 [astearns]
trackbot, start meeting
16:58:03 [trackbot]
RRSAgent, make logs public
16:58:03 [Zakim]
Zakim has joined #css
16:58:04 [trackbot]
Zakim, this will be Style_CSS FP
16:58:04 [Zakim]
ok, trackbot
16:58:05 [trackbot]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:58:05 [trackbot]
Date: 15 February 2017
16:58:13 [dael]
present+ dael
16:58:17 [dael]
ScribeNick: dael
16:58:19 [antenna]
16:58:23 [astearns]
16:58:34 [rachelandrew]
present+ rachelandrew
16:58:45 [dauwhe]
present+ dauwhe
16:59:44 [tmichel]
tmichel has joined #css
16:59:45 [smfr]
smfr has joined #css
17:00:12 [tmichel]
17:00:20 [fantasai]
astearns, #5 can probably be done without me
17:00:41 [antonp]
present+ antonp
17:00:48 [Rossen_]
Rossen_ has joined #css
17:01:00 [TabAtkins]
Can someone adjust the topic to point to the current week's agenda?
17:01:05 [zcorpan]
zcorpan has joined #css
17:01:21 [bcampbell]
bcampbell has joined #css
17:01:25 [myles]
myles has joined #css
17:01:33 [gsnedders]
17:01:34 [astearns]
astearns has changed the topic to: agenda for Feb 15th:
17:01:43 [myles]
present+ myles
17:01:44 [Florian]
17:01:47 [tgraham]
17:01:50 [Rossen_]
17:02:10 [TabAtkins]
17:02:14 [Rossen_]
hmm.... that's not where I needed a missed "r" :)
17:02:20 [myles]
astearns: Rossen_: can we do the text decoration one first? i have to drop off early
17:02:23 [smfr]
17:02:26 [Rossen_]
17:02:33 [jensimmons]
jensimmons has joined #css
17:02:35 [dael]
astearns: We'll start in a couple of minutes.
17:02:37 [astearns]
17:02:41 [jensimmons]
17:02:43 [Rossen_]
I'm sure we can - Alan is driving today's call
17:02:44 [Vlad]
Vlad has joined #css
17:02:47 [smfr]
17:03:24 [dbaron]
17:03:28 [Vlad]
17:03:38 [dael]
astearns: We have plenty of people on the call.
17:03:48 [dael]
Topic: A new property for text decorations to skip ink
17:03:53 [astearns]
17:03:56 [alex_antennahouse]
alex_antennahouse has joined #css
17:04:08 [dael]
myles: Is koji on?
17:04:09 [gregwhitworth]
present+ gregwhitworth
17:04:11 [alex_antennahouse]
17:04:17 [dael]
myles: If he's not on we shouldn't discuss.
17:04:25 [dael]
Rossen_: People trickling in.
17:04:33 [dael]
Topic: Request to publish FPWD of CSS Timing Functions
17:04:41 [astearns]
17:04:58 [ChrisL_]
+1 to publication
17:05:03 [dael]
astearns: That is something we had decided to do, but birtles is now ready to prep FPWD. Does anyone have any comment?
17:05:06 [dael]
??: Yes please
17:05:14 [fantasai]
I think it would be good to also get corresponding updates to Animations and Transitions onto /TR
17:05:16 [myles]
r+ r=me
17:05:18 [fantasai]
Otherwise in favor
17:05:18 [dael]
Rossen_: That's the timing functionality that was taken out of web animations?
17:05:25 [dael]
astearns: That and frames
17:05:27 [dael]
Rossen_: Let's do it
17:05:31 [dael]
astearns: Objections?
17:05:37 [fantasai]
Last Transitions draft is from 2013
17:05:47 [dael]
smfr: Does this effect transitions and animations in that it removes text?
17:05:50 [dael]
ChrisL_: I don't think so.
17:05:52 [fantasai]
Last Animations draft is from 2013
17:05:53 [zcorpan]
17:05:58 [fantasai]
These are wayyy out of date :(
17:06:04 [dael]
TabAtkins: In a later pub we should probably remove them, but it doesn't have an immediate effect.
17:06:20 [Rossen_]
fantasai, yup...
17:06:25 [dael]
astearns: And according to birtles it's just frames and he talks about new timings functions, not so much what's in transitions and animations.
17:06:33 [dael]
astearns: again, objections?
17:06:34 [plh]
17:06:44 [dael]
RESOLVED: Publish FPWD of CSS Timing Functions
17:06:57 [dael]
astearns: Should short name be css-timing or css-timing-functions
17:06:58 [Florian]
17:07:01 [dael]
lots: timing please
17:07:06 [ChrisL_]
rrsagent, here
17:07:06 [RRSAgent]
17:07:11 [dael]
astearns: Great. Short names is css-timing
17:07:14 [Rossen_]
ack Florian
17:07:18 [astearns]
ack Florian
17:07:34 [dael]
Florian: When doing fpwd and we resolve on a different short name than the ED what's the proceedure for renaming in the short name?
17:07:49 [dael]
astearns: If it was just on draft server the short name was provisional. It's only fixed on FPWD.
17:07:54 [dael]
Florian: But there are incoming links.
17:07:56 [fantasai]
Florian, yes, inform plinss
17:08:04 [fantasai]
We used to have a .htaccess file
17:08:06 [fantasai]
We don't anymore
17:08:11 [fantasai]
TabAtkins, ^^^^^
17:08:13 [dael]
TabAtkins: We have redirecting if needed in the htaccess file.
17:08:20 [fantasai]
plinss is maintaining redirects in a different system
17:08:24 [dael]
TabAtkins: css-timing hasn't been reffed much but we can set it up
17:08:29 [dael]
astearns: [reads fantasai]
17:08:36 [dael]
TabAtkins: Well, we still have a system.
17:08:40 [dael]
Florian: Okay, thank you!
17:08:51 [fantasai]
TabAtkins, yes, but it doesn't work by editing a file in the csswg-drafts repo...
17:09:01 [dael]
Topic: A new property for text decorations to skip ink
17:09:04 [astearns]
17:09:08 [melanierichards]
17:09:20 [dael]
koji: This is about the resolution to add text-decoration skip ink to L3
17:09:34 [Rossen_]
koji, it is very hard hearing you
17:10:34 [dael]
koji: This is a proposal. 2 discussion points. 1 is property name. is text-decoration-skip-ink appropriate? Since we don't do text underline skipping would be better
17:10:40 [tantek]
tantek has joined #css
17:10:48 [dael]
koji: Other is about values. fantasai said auto|yes|no
17:11:01 [dael]
koji: If this is fine what auto should be is a discussion point.
17:11:15 [fantasai]
No, it also affects overlines
17:11:17 [dael]
astearns: Let's go one at a time. Can we resolve on changing the name?
17:11:36 [fantasai]
Should not be part of shorthand
17:11:37 [tantek]
belated IRC-only regrets for the first part of this meeting
17:11:38 [dael]
Florian: Related is if it should be part of the L4 shorthand. If it is it should start with the same thing. If it's not we can be more creative.
17:11:43 [fantasai]
It should cascade independently
17:11:55 [dael]
koji: I'd prefer not to make short hand because this is styling decoration underlines.
17:11:56 [Rossen_]
17:12:21 [dael]
Rossen_: I'm trying to understand...this proposed behavior is supposed to desc what webkit currently does for text decoration underline?
17:12:26 [dael]
myles: For skip ink yes
17:12:41 [dael]
Rossen_: And you (myles) do this auto for text decoration underline?
17:12:45 [dael]
myles: I don't remember exactly.
17:13:09 [dael]
Rossen_: Let's assume you'r doing it at least for underline. Is it done unconditionally? There's no additional optional values?
17:13:33 [dael]
myles: Conditionally where you can turn it off. THe initial value was changed to ink so users can use a value of off
17:13:41 [dael]
Florian: But if it's on it's always on? auto or yes?
17:13:52 [tantek]
17:14:00 [dael]
myles: We do auto because we have special CJK behaviors were we turn on/off at a glyph level.
17:14:02 [fantasai]
text-decoration-ink: skip | no-skip ?
17:14:03 [tantek]
17:14:05 [RachelNabors]
17:14:17 [dael]
Rossen_: That sounds good.
17:14:21 [dael]
Rossen_: Thank you.
17:14:31 [dael]
Rossen_: Both skip and auto make sense in how you desc them.
17:14:38 [dael]
koji: Ink has same behavior in beta
17:15:00 [dael]
myles: I don't have many preferences. I jsut have that the auto keyword to do what I desc should not go away
17:15:06 [RachelNabors]
Paying my respects to the newborn timing functions spec <3
17:15:11 [dael]
koji: I agree. We're interested in opt out and opt in.
17:15:23 [dael]
Florian: Do we need all three or auto and don't skip?
17:15:34 [dael]
myles: Currently webkit it's impossible to skip on CJK.
17:15:51 [dael]
Rossen_: But you can opt out of the auto with the non-skipping version?
17:15:55 [dael]
myles: Yes, you can opt out
17:16:12 [dael]
Florian: So you have 2 values. Do we want 2 or 3?
17:16:34 [dael]
myles: THe reason we decided to never skip on CJK is because it looks terrible more or less always. But my preference isn't strong.
17:16:42 [dael]
Rossen_: We shouldn't make bad decisions easy.
17:16:47 [ChrisL_]
17:16:48 [dael]
Florian: Adding a value later isn't hard
17:17:03 [dael]
astearns: We can do auto and no for now. If a need appears later to force it we can consider it them
17:17:03 [Rossen_]
17:17:06 [dael]
myles: I think that's a good idea
17:17:34 [dael]
Florian: I thinkt hat helps with naming. In that case having text-docration-skip: auto makes sense because it knows not to do line-through
17:17:44 [fantasai]
Florian, read up
17:17:48 [dael]
Florian: That also depends on koji's point about no short hand. I didn't understand why
17:18:11 [dael]
koji: I think you had an example that most of the other properties apply to a specific element but skip-ink applies to root elements
17:18:15 [dael]
Florian: mmm..okay
17:18:30 [dael]
astearns: And fantasai put in irc that they should cascade sep. I'm not sure the reason.
17:18:46 [dael]
astearns: I'm nto hearing a strong desire to change the name to underline.
17:19:04 [dael]
astearns: I think we should keep the name as text-decoration-skip
17:19:09 [dael]
Florian: Even if not part of the short hand?
17:19:42 [dael]
fantasai: Behavior is a lot more like text underline position. You'll want to set it at a higher level for how you want to behave for the doc. Turning on and off for the underline is seperate. Thus they shouldn't be conflated.
17:19:47 [dael]
Florian: Then they shouldn't have same prefix.
17:20:08 [dael]
fantasai: Yeah, in general we try that but something is closely related will share a prefix and not be in the shorthand
17:20:36 [dael]
astearns: I would prefer the same prefix so you don't have to remember a different word. And it's easy to remember difference because people will be using it differently
17:20:54 [dael]
koji: We have text emphasis where it's not in the short hand. I think if this should be in the short hand can be seperate.
17:21:02 [dael]
Florian: It's intuitive enough
17:21:10 [dael]
Florian: Can I suggest off instead of no
17:21:12 [dael]
myles: None?
17:21:16 [dael]
Florian: That's fine too.
17:21:22 [dael]
Rossen_: Can we summerize?
17:21:37 [dael]
Rossen_: I've heard it's text-decoration-skip: auto|none
17:21:40 [Florian]
text-decoration-skip-ink: none | auto
17:21:45 [dael]
astearns: I think it's text-decoration-skip-ink
17:21:47 [dael]
koji: yes
17:21:57 [myles]
17:22:07 [dael]
astearns: proposal text-decoration-skip-ink:non|auto with auto default
17:22:14 [dael]
Rossen_: Reason to not remove ink?
17:22:25 [fantasai]
I'm provisionally OK with this. Need to think about integration with other text-decoration-skip values.
17:22:32 [dael]
Florian: There's a level 4 that skips in other places. Ink is a sub case that's in level 3.
17:22:39 [astearns]
17:22:40 [dael]
Rossen_: So...I see.
17:22:55 [dael]
Florian: Shouldw e define what auto does?
17:23:07 [dael]
myles: No. :)
17:23:23 [dael]
Florian: There has been discussion on github that auto shifts the baseline. I don't htink it should do that
17:23:28 [dael]
koji: That was a misunderstanding.
17:23:40 [dael]
myles: If we don't define auto UA can tweak.
17:23:50 [dael]
Florian: I'd rather UA not to use skipping for positioning.
17:24:10 [dael]
Rossen_: Asside from bikeshedding I think these are good things to agree on.
17:24:35 [dael]
astearns: Is text-decoration-skip-ink with values as none|auto with auto anyone opposed?
17:24:59 [dael]
fantasai: It's okay to me. I'd like to think about how it integrates with other skipping, but it's fine for now. We should note that it's not in the shorthand.
17:25:09 [dael]
astearns: Yes, and I believe how it works with the rest is for the next level
17:25:30 [dael]
dbaron: So that's saying that impl are expected to turn it on by default upon impl.
17:25:45 [dael]
dbaron: We're saying that there will be no way to opt into more skipping then default
17:25:48 [dael]
Rossen_: As of now, yes
17:26:04 [dael]
astearns: For this level. We're doing the minimum to finish this level of text decoration. We'll add more later.
17:26:06 [dael]
dbaron: Okay.
17:26:29 [dael]
Florian: As part of peopling auto to UI does that make it non-testable? Because then auto could be same as none.
17:26:36 [tobie]
tobie has joined #css
17:26:37 [dbaron]
It feels a little odd to introduce it as a change in behavior rather than opting in to the different behavior
17:26:48 [dael]
astearns: I would prefer having some suggestions that it SHOULD skip ink in roman but not arabic.
17:27:00 [dael]
astearns: I'm not sure that the impl notes should be normative
17:27:09 [BogdanBrinza]
BogdanBrinza has joined #css
17:27:09 [dael]
Florian: If we don't we can go to rec with no impl.
17:27:19 [dael]
Florian: That doesn't sound helpful.
17:27:52 [tantek]
tantek has joined #css
17:27:53 [dael]
myles: If there are non-normative or normative notes they shouldn't list every language. Maybe a couple of examples are valuable. Saying which lang should and shouldn't shouldn't be in spec. I should say script, not lang.
17:28:10 [dael]
dbaron: On the other hand then you're asking impl to figure it out. So 4 teams do it.
17:28:15 [dael]
myles: The teams can talk
17:28:23 [dael]
astearns: I'm not sure any team has an exustive list
17:28:33 [dael]
Florian: We can have a base case and exceptions.
17:28:45 [dael]
myles: We can say it's expected to skip in latin and others are up to UA
17:28:51 [dael]
Florian: Yes. Can that be a must?
17:28:52 [fantasai]
dbaron, in this particular case we apparently have precedent from the ancient browsers if the 1990s :)
17:29:04 [dael]
astearns: Obj to having a normative must on skipping ink in latin cases?
17:29:26 [fantasai]
+1 to ChrisL
17:29:47 [dael]
ChrisL_: It's not an objection, but it comes across that this is the lang we care about. I know that's not the intention but it sounds a bit awk. I don't have abetter suggestion.
17:30:05 [dael]
ChrisL_: I jsut have a slight concern. WE could ask i18n for help
17:31:01 [dael]
fantasai: It would make mroe sense to go the other way and say skip ink for everything except cases wher eyou know you shouldn't. Tihs is mostly on or mostly off. If we want to make an exception for if there's a case where you think it looks bad you can not do it. But it should clearly say if you don't know what to do you should define what to do
17:31:17 [dael]
dbaron: Saying do it is awk for something that will be the default.
17:31:40 [dael]
dbaron: If it were an options dev turn on that's fine. But given that the default is skip ink we need to gather a list where it would look back.
17:31:50 [Rossen_]
17:31:59 [dael]
fantasai: I would prefer on and off and if you want to do it lang dependant you can do it that way
17:32:03 [dael]
Florian: It's glyph based.
17:32:07 [Rossen_]
17:32:16 [dael]
myles: We found it looks terrible in too many cases with untagged docs.
17:33:00 [dbaron]
Like, say, is skip-ink desirable for Kannada?
17:33:07 [dael]
Rossen_: The huge benefit is when it comes online and it just works. When I've seen it on Apple it was cool to see it. No authors had to do anything. I agree we need to do better homework for when to turn it off by default. I don't think we need to decide it this moment.
17:33:32 [dbaron]
or Malayalam?
17:33:32 [dael]
Rossen_: We'll continue wokring on this feature. I thinkw e can wrap up by agreeing to adopt the prop and values and then continue tech details of auto's definition
17:33:59 [dael]
Florian: In general I agree. I want to add a nuance. I'm okay with doing homework later. I don't want ot call it done in L3 without an explination.
17:34:02 [dbaron]
s/look back/look bad/
17:34:40 [fantasai]
dbaron: I think it is desired for South Asian and Southeast Asian scripts. The ones I've investigated use it.
17:34:52 [dael]
astearns: Things are going in circle. I think we should close for now. I do believe we can resolve we're using txt-decoration-skip-ink with at least values of auto and none and it cascade sep from shorthand. We will have some normative text desc how auto works, but we'll figure the details out in the future
17:34:58 [dael]
astearns: Obj to leaving it there?
17:35:18 [dael]
fantasai: The spec is in CR. The goal for me has been to wrap up issues and do a stable CR. Maybe it should go next draft.
17:35:22 [dael]
astearns: That's possible.
17:35:30 [dael]
WOuld there be obj to moving this to next level?
17:35:41 [dael]
Rossen_: Once we accept we can move it back in to L3
17:35:57 [dael]
Florian: I'm okay with L3 or L4. It jsut needs to be with its defined normative behavior
17:36:01 [fantasai]
+1 to Florian
17:36:06 [dael]
astearns: proposed resolution: everything before in L4
17:36:11 [dael]
astearns: obj?
17:36:30 [dael]
koji: Webkit has a seperate behavior we had the ability to opt out and this removes the ability
17:36:55 [dael]
astearns: I think this is process. We're defining it, it's just in a next module level so we can get to the current impl interop things done.
17:37:06 [dbaron]
fantasai, those in particular have different sorts of descenders, which is why they seem interesting (and different from many North Indian scripts)
17:37:07 [dael]
Florian: L4 isn't an ED yet
17:37:13 [dael]
astearns: I'm hearing no objections
17:37:20 [fantasai]
I really object to having "no skipping" and "maybe skipping, not sure if we want this to be mostly skipping or mostly not skipping"
17:37:39 [dael]
RESOLVED: Use text-decoration-skip-ink with at least values of auto and none and it cascade sep from shorthand. We will have some normative text desc how auto works, but we'll figure the details out in the future. Do in L4
17:37:41 [fantasai]
If it's "no skipping" and "skip unless it's really bad"... I could deal with that.
17:37:54 [dael]
Topic: create a display property value for visually hiding an element while making it available for AT
17:38:01 [astearns]
17:38:02 [myles]
17:38:04 [myles]
present- myles
17:38:12 [jensimmons]
jensimmons has joined #css
17:38:18 [Rossen_]
bye myles
17:38:46 [dael]
fantasai: I think we decided not to do anything. THis was really if we wanted to do anything with speak or speak-as. There may be further discussion o nthis draft, but I don't see solid proposals. Maybe repub CSS Speech.
17:38:48 [fantasai]
17:38:52 [dael]
astearns: Anyone have something more to add?
17:39:03 [fantasai]
17:39:07 [dael]
astearns: Shall we resolve to close the issue?
17:39:17 [dael]
fantasai: I would say do we want to republish CSS Speech CR
17:39:23 [dael]
astearns: With what changes
17:39:37 [dael]
fantasai: We renamed some values and def they're effected by visibility
17:39:40 [dael]
astearns: Objections?
17:39:43 [fantasai]
We did that last month
17:39:53 [dael]
RESOLVED: Republish CSS Speech CR
17:40:10 [dael]
ChrisL_: New features, or jsut text? Do I do the non-technical?
17:40:19 [dael]
fantasai: It's non-technical
17:40:22 [dael]
ChrisL_: DoC?
17:40:26 [dael]
fantasai: I can update in 5 minutes.
17:40:32 [dael]
ChrisL_: And a changes section?
17:40:34 [dael]
fantasai: Yep.
17:40:36 [dael]
ChrisL_: Thanks.
17:40:42 [dael]
Topic: Stretching image grid items in both dimensions
17:40:47 [ChrisL_]
rrsagent, here
17:40:47 [RRSAgent]
17:40:47 [dbaron]
s/minutes./minutes; there were only 2 issues./
17:40:51 [astearns]
17:41:46 [dael]
fantasai: The discussion we had in Seattle...mats said it was unclear if we're discutinguishing by if it's replaced or has an aspect ratio. TabAtkins and I thought it should be based on if they have an aspect ratio. Images that don't generally take their size from the container anyways.
17:42:06 [dael]
fantasai: We need to answer what happens to an image that has no aspect ration & no size.
17:42:16 [dael]
fantasai: An SVG with no viewbox, width, or height
17:42:30 [dael]
fantasai: OTher question is what if it just has width.
17:43:11 [dael]
Rossen_: For SVG these things are def in integration spec. The internal sizing algo for all the permutations. I don't think there's anything new that will be added for SVG.
17:43:37 [dael]
Rossen_: You can word it so SVG is treated as non aspect ratio image and it won't effect sizing in SVG. It's just a choice of which to we apply in SVG.
17:44:12 [dael]
fantasai: Only thing that really makes sense if for it to take the size of the fixed size grid container. That's what we do in blocks when we can.
17:44:17 [dael]
Rossen_: I think this is reasonable.
17:44:32 [fremy]
fremy has joined #css
17:45:12 [dael]
Rossen_: From text POV if we tried to make a distinction between what applies with and without intrinisic ratio this isn't the place. IF we want the spec to call out this applies to when it has an intrinisic size and this is when it does and leave out the definition for another spec.
17:45:28 [dael]
fantasai: Right. We don't say when, but we define different behavior for when it has one and when it doesn't.
17:45:39 [dael]
Rossen_: From what I udnerstand Mats pushed back this isn't well defined in grid?
17:46:13 [dael]
fantasai: We had defined it and Mats pushed back it didn't match what was resolve din his understanding that allr eplaced elements have one behavior which is the shrink to fit.
17:46:36 [dael]
Rossen_: I think if we change the wording to refer to replaced elements with an intrinisic ratio it solves both issues.
17:46:52 [dael]
Rossen_: Does that sound right?
17:47:05 [dael]
fantasai: I need to look at the wording.
17:47:33 [dael]
astearns: As much as I'm following, we need a resolution that our previous resolution only applies to replaced elements...
17:47:47 [dael]
Rossen_: The other way. It currently applies to all replaced elements.
17:47:50 [fantasai]
17:47:53 [dael]
fantasai: Here's the comment ^
17:48:01 [dael]
fantasai: [reads]
17:48:18 [dael]
dbaron: Yep.
17:49:08 [dael]
dbaron: I think Mats' point is he wants the WG to resolve something that matches what people put in the issue. Since there have been previous edits where edits and the resolution diverge. He's sensitive that edits and resolutions can diverge and he's pointing those out.
17:49:23 [fantasai]
The two questions we need to resolve are
17:49:27 [dael]
Rossen_: Yes. THat's a valid point. Having a tighter definition of which replaced elements will be good.
17:49:39 [dael]
fantasai: There's two questions we need to resolve [reads]
17:49:51 [dael]
fantasai: First should get stretched.
17:50:14 [dael]
astearns: Before we get to the questions don't we need tor esolve that we meant the previous resolution to only apply to those with an aspect ratio
17:50:25 [dael]
astearns: What is THIS that only applies to things with an aspect ratio
17:50:52 [dael]
Rossen_: Instead os stretch we respect the instrinisic ratio. [looks for exact previous resolution wording]
17:51:14 [fantasai]
Items without an intrinsic ratio use, in both axes, the width calculation rules for non-replaced block boxes as defined in CSS2.1 § 10.3.3. (Meaning, auto values in either axis are effectively sized to fill the remaining space.) However, the box alignment properties have special effects: when align-self/justify-self is neither normal nor stretch, an auto size for the grid item in that axis is treated as fit-content instead of as the stretch-fit size. See [CUT]
17:51:21 [fantasai]
Items with an intrinsic ratio follow the same rules, except that in the case of a normal alignment value, an auto size for the grid item is sized as for align-self: start (consistent with the width calculation rules for block-level replaced elements in CSS2.1 § 10.3.4).
17:51:26 [dael]
fantasai: Current spec text^
17:52:04 [dael]
Rossen_: The resolution says we're keeping the current behavior as-is.
17:52:16 [dael]
astearns: What's the change to satisfy Mats?
17:52:40 [zcorpan_]
zcorpan_ has joined #css
17:52:41 [dael]
TabAtkins: WE talked about replaced elements when we meanth those with aspect ratio. Reoslving that. THen some questions falling out from that.
17:53:05 [dael]
Rossen_: Reading from fantasai text we're talking about [reads] This is talking about intrinisc ratio.
17:53:24 [dael]
fantasai: That's not what was in the minutes so Mats wants confirmation
17:53:48 [dael]
astearns: Proposed resolution is that the sentence pasted above is what was intended from the Seattle resolution and we resolve on that text.
17:53:55 [dael]
astearns: Objections?
17:54:28 [dael]
RESOLVED: The sentence beginning with "Items without an intrinsic ratio use," is what we as a WG wanted to use
17:54:33 [dael]
astearns: Okay, the questions.
17:55:12 [dael]
fantasai: WE didn't really talk abotu the first case. It makes sense to me that the axis with an intrinisic size should follow the second clause. In the dimension without a size it behaves as stretch
17:55:35 [dael]
astearns: So that first sentence would be that items without an intrinisic size in the axis....
17:55:56 [dael]
Rossen_: I'd rather say items with defined size in only one dimension, that dimenstion is start and the other is stretch
17:56:07 [dael]
fantasai: I'm happy to word smith, but if we conclude on the behavior.
17:56:29 [dael]
Rossen_: Proposed: replaced elements with only one intrinisic size are sized as start in that dimension and stretch in the other.
17:56:35 [dael]
ChrisL_: I think that makes sense.
17:56:50 [dael]
astearns: repleaced elements with one intrinisic size and no aspect ratio
17:56:52 [dael]
fantasai: Yes.
17:57:03 [dael]
astearns: Objections to Rossen_ proposal?
17:57:12 [dael]
RESOLVED: replaced elements with only one intrinisic size are sized as start in that dimension and stretch in the other
17:57:22 [dael]
astearns: We'll let the editors get that into the spec text.
17:57:27 [dael]
Rossen_: fantasai you doing this?
17:57:31 [dael]
fantasai: I'll do the edits.
17:57:50 [dael]
Topic: [css-cascade] Path to PR
17:57:55 [astearns]
17:57:58 [dael]
astearns: Main thing is drops coped styles
17:58:12 [dael]
TabAtkins: Which is support. FF might impl, but no one else is planning on them.
17:58:18 [dael]
dbaron: We are keeping our impl for now
17:58:25 [dael]
fantasai: It is also defined in cascade L4
17:58:41 [dael]
astearns: If we drop from level 3 would we also from l4?
17:58:50 [zcorpan]
zcorpan has joined #css
17:58:58 [dael]
fantasai: We can decide on that once we're blocked on PR. Do we have 2 impl of revert keyword?
17:59:07 [dael]
fantasai: THat's the main new thing on L4
17:59:22 [dael]
astearns: Obj to dropping scoped styles from current level of css cascade?
17:59:31 [dael]
RESOLVED: dropscoped styles from current level of css cascade
17:59:43 [dael]
fantasai: We need action items for getting impl test into the repo.
18:00:05 [dael]
fantasai: If no one wants to import tests they can point to where the tests are so someone else can import.
18:00:14 [dael]
fantasai: If we don't have tests we can't go to PR.
18:00:33 [dael]
astearns: ANyone willing to take an action item?
18:00:37 [dael]
TabAtkins: I can find the ones for us
18:00:45 [dael]
ACTION TabAtkins to find cascade tests
18:00:53 [trackbot]
Error creating an ACTION: could not connect to Tracker. Please mail <> with details about what happened.
18:00:57 [tantek]
tantek has joined #css
18:01:12 [dael]
ACTION TabAtkins to find cascade tests
18:01:20 [trackbot]
Error creating an ACTION: could not connect to Tracker. Please mail <> with details about what happened.
18:01:48 [dael]
astearns: I guess we'll see if the blink tests are sufficient. It's like more participation since we don't do enough compiling of test suites. I'd rather volunteers.
18:02:09 [dael]
fantasai: What I can do is I can grab and import the MOzilla tests and they have 2 copies.
18:02:26 [dael]
dbaron: I'm having trouble finding tests. The only tests I know we have are mochi (sp) tests
18:02:32 [dael]
dbaron: You can't import those.
18:02:52 [dael]
fantasai: If you can drop in the URLs we can look to try and convert.
18:03:01 [dael]
fantasai: Then it's more solvable of a problem.
18:03:02 [dbaron]
layout/style/test/test_all_shorthand.html was the one I found
18:03:05 [dbaron]
but it's a mochitest
18:03:11 [dael]
astearns: We're over time. Thanks everyone for calling in.
18:03:26 [jamesn]
jamesn has joined #css
18:03:45 [Florian]
I'd like to take this opportunity to remind people to watch the csswg-test Pull Request queue. There's quite a bit of tests there sitting and waiting.
18:03:55 [astearns]
s/It's like/I'd like/
18:04:08 [Rossen_]
+1 to Florian
18:04:12 [gsnedders]
I'll also point out we still haven't made most of the metadata optional in the tooling so there's still a fair bit of metadata to add to tests if we want them for css-cascade
18:04:31 [fantasai]
dbaron, making sure all of the things Mozilla has tested is also tested in the CSSWG test suite would make me a lot more confident that we've got good test coverage, even if we can't actually import the tests themselves. :)
18:04:45 [gsnedders]
Of course, if we're just starting a new testsuite, we could just try putting them in web-platform-tests and using the tooling everyone else has been using.
18:04:45 [fantasai]
dbaron, Mozilla is good at figuring out which tests need to be written
18:05:16 [fantasai]
s/Mozilla is/Mozilla devs are/
18:05:18 [Florian]
tantek: can you review these:
18:05:39 [Florian]
tantek: if not, who should? (I can't, I wrote them).
18:05:44 [fantasai]
gsnedders: cascade is relatively small, it won't be too difficult to tag them
18:06:58 [gsnedders]
fantasai: I'd like to see if the group actually finds the tooling everyone else has been using acceptable and then we can move away from our custom tooling even sooner
18:07:48 [fantasai]
gsnedders: I'm not familiar with WPT tooling. Can it give me a list of tests applicable to a particular section of a spec?
18:08:33 [dbaron]
fantasai: really, the way to find the Mozilla tests for things is to find the bugs that implemented the features that you want the tests for (including the other fixes in their dependency tree), and figure out where those patches added tests
18:09:06 [gsnedders]
fantasai: insofar as it is encoded in the path of all tests, yes
18:09:14 [fantasai]
dbaron, yeah :/ Would be nice if Mozilla had a better path-based sort
18:09:50 [fantasai]
dbaron, or put Web platform tests into the appropriate export directories by default
18:09:54 [fantasai]
whenever appropriate
18:10:16 [gsnedders]
fantasai: WPT in general has avoided the CSS habit of putting hundreds/thousands of tests in one directory
18:10:38 [gsnedders]
fantasai: and maintained a mapping of directory structure to section, which has as far as anyone can tell sufficed
18:10:55 [fantasai]
gsnedders: That's not going to cover interaction tests, of which we have many
18:11:01 [dbaron]
fantasai: we generally do, but there are a bunch of features that it's easiest to test by putting tests into existing large mochitests
18:11:10 [dbaron]
fantasai: which we should probably have a CSSWG version of, but I haven't gotten to doing that
18:11:26 [dbaron]
fantasai: In particular, I'm thinking of all the tests we have that are based on layout/style/test/property_database.js
18:11:39 [jcraig]
jcraig has joined #css
18:11:41 [fantasai]
dbaron: I recall you importing the CSS2.1 version of that at one point
18:12:01 [dbaron]
fantasai: never finished
18:12:11 [gsnedders]
fantasai: as does WPT; it's not ideal but there's never been anyone willing to add metadata to tests to make such a tool useful
18:12:26 [gsnedders]
fantasai: (for interaction tests, that is)
18:12:32 [gsnedders]
fantasai: either at test authoring time, or in hindsight
18:16:10 [gsnedders]
fantasai: everyone else survives without this tooling despite interaction tests being no more rare; why does it make such a huge difference to the CSS WG?
18:22:20 [astearns]
trackbot, end meeting
18:22:20 [trackbot]
Zakim, list attendees
18:22:20 [Zakim]
As of this point the attendees have been dael, antenna, astearns, rachelandrew, dauwhe, tmichel, antonp, gsnedders, myles, Florian, tgraham, TabAtkins, Rossen_, jensimmons, smfr,
18:22:23 [Zakim]
... dbaron, Vlad, gregwhitworth, alex_antennahouse, zcorpan, plh, melanierichards, RachelNabors, ChrisL_
18:22:28 [trackbot]
RRSAgent, please draft minutes
18:22:28 [RRSAgent]
I have made the request to generate trackbot
18:22:29 [trackbot]
RRSAgent, bye
18:22:29 [RRSAgent]
I see no action items