w3 :: #css

19 Apr 2017
00:09Rossentrackbot, start meeting
00:09* trackbot is preparing a teleconference.
00:09RRSAgentlogging to http://www.w3.org/2017/04/19-css-irc
00:09trackbotRRSAgent, make logs public
00:09RRSAgentI have made the request, trackbot
00:09trackbotZakim, this will be Style_CSS FP
00:09Zakimok, trackbot
00:09trackbotMeeting: Cascading Style Sheets (CSS) Working Group Teleconference
00:09trackbotDate: 19 April 2017
00:11myles_present+ myles
00:12myles_present+ myles_
00:14* shane Florian is _PRENSENT_
00:14iank_scribenick: iank_
00:14fantasaiFor topics, I think Grid, Flexbox, and Alignment would go well together.
00:15* eae smfr: :)
00:15iank_Rossen: Lets start with introductions
00:15fantasaifantasai aka Elika Etemad, Invited Expert
00:15RossenRossen Atanassov, Microsoft
00:15dinoDean Jackson, Apple
00:15jackpresent+ Jack Moffitt, Mozilla
00:15BogdanBrinzaBogdan Brinza, Microsoft
00:15flackrRob Flack, Google
00:16rbyersRick Byers, Google
00:16FlorianFlorian Rivoal, Vivliostyle
00:16astearnsAlan Stearns, Adobe
00:16eaeEmil A Eklund, Google
00:16smfrSimon Fraser, Apple
00:16jetJet Villegas, Mozilla
00:16dbaronL. David Baron, Mozilla
00:16birtlesBrian Birtles, Mozilla
00:16xidornXidorn Quan, Mozilla
00:16iank_Ian Kilpatrick, Google
00:16shaneShane Stephens, Google
00:16murakamiShinyu Murakami, Vivliostyle
00:16VladVladimir Levantovsky, Monotype
00:17iank_Rossen: Thanks for hosting us and the wonderful venue.
00:17skkHiroshi Sakakibara, BPS
00:17fantasaidbaron: I wrote a new IRC bot known as minute-man
00:17fantasaidbaron: It's job is to comment in github when we discuss a github issue
00:17iank_dbaron: I wrote a new irc bot, "minuteman", its job is to comment it github when we comment it github issues.
00:17iank_dbaron: &quot;Github Topic: <github issue url>&quot;
00:18fantasaidbaron: Topic is concluded with new Github Topic line or Topic line.
00:18iank_dbaron: It will log the resolution, and have an expanded irc log.
00:18astearnsan example of a bot comment: https://github.com/w3c/css-houdini-drafts/issues/393#issuecomment-294706386
00:18iank_dbaron: It will also remove the &quot;agenda+&quot; issue if it has write access.
00:19iank_astearns: I think we&#39;ll need to add the bot to the w3c github org.
00:19dbaronminute-man, intro
00:19minute-manMy job is to leave comments in github when the group discusses github issues and takes minutes in IRC.
00:19minute-manI separate discussions by the &quot;Topic:&quot; lines, and I know what github issues to use only by lines of the form &quot;GitHub topic: <url> | none&quot;.
00:19minute-manI&#39;m only allowed to comment on issues in the repositories: dbaron/wgmeeting-github-ircbot w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts.
00:19minute-manMy source code is at https://github.com/dbaron/wgmeeting-github-ircbot and I&#39;m run by dbaron.
00:19iank_all: Much applause.
00:19iank_fantasai: Feature request, link to the irc logs within the github issue.
00:19iank_dbaron: Yes, need to refactor the bot to do that.
00:20iank_Rossen: Thanks dbaron, this is awesome.
00:20iank_Topic: Resolve on dates for F2F meeting in SYD
00:21iank_Rossen: What are we thinking, there are 3 weeks proposed.
00:21iank_shane: I have a hold on all three weeks at the moment, outside those weeks is going to be hard.
00:21SimonSapinpresent+ Simon Sapin, Mozilla
00:21eaeJanuary 22 - January 25
00:21eaeJanuary 29 - February 1
00:21eaeFebruary 5 - February 9
00:21Florianany of these three weeks is equally good for me
00:21iank_Rossen: So, previously we&#39;ve always picked the first week of feb, or around that.
00:21iank_Rossen: What works best for people
00:22dgrogan_cloudpresent+ David Grogan, Google
00:22iank_dbaron: One thing we ran into before, the first week of school in AU, flights were expensive around that time.
00:22iank_dino: 26th Jan is a holiday
00:22iank_shane: It&#39;s a friday.
00:22iank_dino: That will be a long weekend.
00:22iank_dino: I think that is also school holidays there.
00:23iank_dino: The safest to avoid holidays is the Feb week.
00:23nainarA quick flights search shows all flights to be equally expensive. Though it is too early to estimate
00:23iank_shane: Term starts Jan 30th.
00:23* smfr australia school holidays http://www.nswschoolholiday.com.au/index.php/nsw-school-holiday-dates-2017
00:24iank_Rossen: Feb 5-9 would that work?
00:24iank_Rossen: Lets agree on Feb 5-9, shane&dino unless we have more info about school holidays
00:25iank_Rossen: It seems that back of the week has been working better.
00:25iank_fantasai: Last year we had a discussion about 3 vs. 4 meetings per year
00:25iank_fantasai: If we want 3 we should resolve on that first, then resolve on dates.
00:26iank_astearns: We have google for the first meetings, and then the next proposal is April in Berlin near TYPO
00:26iank_astearns: wheather we have 3/4 meetings next year we have 2 meeting slots already
00:26iank_dbaron: Jan/Apr are close
00:26iank_Rossen: When is TPAC?
00:27iank_dbaron: 2nd week of November.
00:27iank_TabAtkins: NovTPAC/Jan/Apr/ are too close together
00:27iank_dbaron: The second meeting by april is too close
00:28iank_TabAtkins: NovTPAC + EarlyJan is way too close.
00:28iank_TabAtkins: THINGS NEED TO MOVE
00:28iank_Rossen: TYPO is set at the moment.
00:28iank_???: It&#39;s going to be April but no firm dates yet.
00:29iank_???: The conf schedule depends on the availability of the venue.
00:29iank_Rossen: When is TPAC 2018?
00:29iank_Rossen: Is it going to be an early TPAC?
00:29iank_dbaron: I&#39;m not aware of it being announced yet.
00:29iank_fantasai: Can we ping bert?
00:29fantasaiBert: Do you know when TPAC is in 2018?
00:30tantek_TPAC 2017 is Nov 6-10 https://www.w3.org/wiki/TPAC/2017
00:30iank_Rossen: SO, assuming that TPAC next year is going to be around Nov... fantasai points out that we need to decide on 3vs.4 meetings, if we want to be near TYPO that places a time constraint, Google hosting in SYD also places a time constraint.
00:31iank_Rossen: April to TPAC Nov is 6 months.
00:31iank_fantasai: If we are limited to April + Nov, we need 4 meetings, or have a 6 month gap.
00:32iank_shane: We could look at Google SYD hosting between Apr, and Nov TPAC.
00:32iank_shane & TabAtkins argue about relative niceness of summers.
00:33iank_dbaron: Mozilla toronto could be a good place as well.
00:33iank_Rossen: TPAC 2018 will probably be asia or EU.
00:34iank_fantasai: <draws a circular calendar on the whiteboard>
00:34iank_Rossen: We need to decide if we want to forfeit the early SYD meeting.
00:35iank_Rossen: As TabAtkins pointed out there is a slow month between Nov & Feb.
00:35iank_fantasai: I might get a lot done.
00:35iank_Rossen: Lets try and wrap up.
00:35iank_Rossen: At this point is the April meeting not an option to move at this point?
00:35iank_Rossen: Can we move that meeting to Jun?
00:36iank_Rossen: I.e. Feb / Jun / Nov
00:36iank_fantasai: Do we don&#39;t 3 vs. 4 meetings? If 3 we can&#39;t do April.
00:37iank_TabAtkins: Disagrees.
00:37iank_Rossen: Lets to a quick straw-poll
00:37iank_Rossen: Based on that we&#39;ll decide dates.
00:38dbaron3 (weakly)
00:38tantek_3 or 4
00:38* TabAtkins 3 weekly meeting for dbaron, check
00:40fantasaiplh, do you know when tpac 2018 is?
00:40astearnsaverage is 3.375
00:40iank_Rossen: So google is pretty strongly in favour of 3
00:41iank_Rossen: If we are going to stick we three. Jan/Feb is out of the question.
00:41iank_eae: We can&#39;t really do Feb and Apr.
00:41iank_Rossen: This discussion is more for shane + google if hosting in SYD
00:42iank_fantasai: Do we peg to typo in april? If not we can do goog in feb/mar, if we do one in (northern) hemisphere summer.
00:42iank_Rossen: I&#39;m personally not aware of the TYPO constraint and being close to it.
00:43iank_Vlad: The motivation that people may want to attend both (CSS & TYPO) lots of people learning about CSS/TYPO
00:44iank_Vlad: Good if CSS participants could attend TYPO
00:45iank_astearns: I have a slight perference for TYPO and then a (northern) hemisphere summer meeting
00:45iank_Rossen: Ok if thats what we want to do, lets decide that and allow shane to release hold of the rooms.
00:45iank_shane: Can we first make sure that everyone can make a timeslot there?
00:46myles_Vlad: where is typo?
00:46iank_fantasai: <please type your constraints in IRC>
00:46astearnsmyles_: Berlin
00:46iank_dbaron: which months?
00:46iank_fantasai: Jun/Jul/Aug
00:46dbaroneverybody from Mozilla likely has a problem with June 11-16, 2018
00:46shanefirst two weeks of July are probably not good for Googlers
00:46rbyersGoogle is out Jul 3 - 14
00:47plinssfirst two weeks of June are problematic for me
00:47smfrearly june is often bad for apple folks
00:47iank_fantasai: Maybe we pull all the constraints now, and decide tomorrow
00:47fantasaifantasai: after interrogating ChrisL
00:48shaneUS summer holidays basically all of July and August?
00:48RossenJune is not good for Microsoft
00:48shaneplus late june if you&#39;re in high school
00:48iank_iank_: June looks out.
00:48iank_Rossen: So Jul/Aug? TPAC in Sept would be bad...
00:49iank_Rossen: Mid-Jul & Aug is what we are looking at in terms of dates.
00:49* shane so we could probably get a cheap meeting room at a university in Hawaii during the summer break
00:49* eae shane++
00:50* astearns you&#39;re offering to host in Hawaii, shane?
00:50iank_Rossen: We&#39;ll figure out when TPAC is, then decide.
00:50* shane sure!
00:50* shane ... maybe
00:50iank_Rossen: Lets end with that.
00:50tantekI think TPAC 2016 worked really well in September. If you thought so as well, please ask your AC representative to tell the W3C Team (and AB) accordingly
00:51iank_ACTION: w3c staff please get back to us about TPAC 2018
00:51* trackbot is creating a new ACTION.
00:51* RRSAgent records action 1
00:51trackbotError finding &#39;w3c&#39;. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
00:52dinoTopic: Conditional Rules
00:52dinodbaron: I was hoping zcorpan would be here, but he&#39;s given regrets. We should delay or take it offline.
00:52myles_ ChrisL_!
00:52dinodbaron: who was driving the issue?
00:52iank_scribenick: dino
00:53dinoRossen: It came from the driving specs to REC. You said we need to resolve some things with zcorpan.
00:53dinodbaron: push it offline.
00:53dbaronTopic: UA-defined variables
00:53ChrisL_scribenick: ChrisL
00:54ChrisL_dino: want to expose values that are UA specific, like the range of text sizes for accessibility
00:54ChrisL_.. nice to expose them as variables but the user can&#39;rt change them but can use them
00:54ChrisL_... no concrete proposal or list
00:55ChrisL_iank_: --safari-- stuff?
00:55ChrisL_dino: no
00:55ChrisL_tab: like a keyword
00:55ChrisL_dino: variables is a nice way to expose them
00:55dbarons/like a keyword/a user-agent variable is otherwise known as a keyword in CSS/
00:55ChrisL_TabAtkins: can be used anywhere which is nice
00:56ChrisL_shane: want to see a const construct, users often have const variables too
00:56ChrisL_dino: conflicts with const in JS
00:56ChrisL_shane: seeing people in the wild use a ton of variables
00:56ChrisL_trabwe special case vars defined on the root
00:57ChrisL_Rossen: seen people want that for colors, fonts
00:57ChrisL_dino: scroll-bar width
00:58ChrisL_TabAtkins: uas can insert this
00:58ChrisL_eae: expose selection color as well
00:59ChrisL_leaverou: existing fallback mechanism on vars would help here
00:59ChrisL_TabAtkins: use a normal keyword for the ua defined ones
00:59TabAtkins(--- is a valid var, try again)
00:59ChrisL_... keep variables for users
00:59Floriantwo em-dashes
01:00TabAtkins(We promised to keep CSS syntax within ASCII.)
01:00ChrisL_dino: don&#39;t want vendor specific ones
01:00ChrisL_leaverou: benefit of variables over keywords?
01:00ChrisL_TabAtkins: messes with the grammar if they are allowed literally anywhere. eg in calc
01:01ChrisL_Florian: var like things but not keywords
01:01Florianor units
01:01ChrisL_dino: if they are -- it gives authors a way to provide default values
01:01eaes/selection color/ui value keywords such as selectioncolor or default fonts/
01:01ChrisL_astearns: especialy for uas that don&#39;t support it yet
01:02TabAtkins`--foo: whatever !const;` <== only allow on a root element (document or shadow tree)?
01:02ChrisL_Florian: parsing of var function, can we define ones without -- but for legacy reasons no
01:02ChrisL_dino@supports can&#39;t be used with var
01:02ChrisL_dbaron: can use @supports display: var(foo)
01:03ChrisL_dino: like to keep the var function and not require the dashes
01:03ChrisL_shane: and allow them tobe marked as const
01:03ChrisL_iank_: a non changing variable
01:04ChrisL_shane: 100+ const-like variables in many stylesheets. if const would be a lot cheaper
01:04ChrisL_dino: okay, but need a sysntax proposal.
01:04ChrisL_... you special-case root?
01:04ChrisL_shane: as a cache, only. they can still change
01:04ChrisL_TabAtkins: anything starting with a ! is open, we could use that
01:05ChrisL_... vars are syntax checked so can set a custom property and give it the value of the var kw which will syntax fail on...
01:05TabAtkins--foo: my-fallback; --foo: var(UA-keyword);
01:05ChrisL_TabAtkins: second one fails at parse time
01:05ChrisL_... so usual fallback mechanism
01:06Florianshould probably do &quot;--foo: my-fallback; --foo: var(UA-keyword, my-fallback);&quot;
01:06ChrisL_xidorn: why does the second one fail
01:06ChrisL_TabAtkins: should invalidate the property at parse time
01:06ChrisL_Florian: also fallback inside the var function
01:07ChrisL_dino: will open a GH issue to bikeshed the syntax
01:07ChrisL_topic: caniuse
01:07TabAtkins(Expanded explanation: syntax is `var( <custom-property-name> )`, where <custom-property-name> is a --name. Thus, per spec, using a non-dashed keyword is syntactically invalid and should be rejected at parse time.
01:07dbaronGithub topic: https://github.com/w3c/csswg-drafts/issues/1219
01:07minute-manOK, I&#39;ll post this discussion to https://github.com/w3c/csswg-drafts/issues/1219
01:07ChrisL_fantasai: we were asked to add these to our specs, bs supports
01:08ChrisL_filed as an issue on individual specs? do it on all or none
01:08ChrisL_Florian: seems useful
01:08ChrisL_fantasai: main reason not ot is that it is unofficial
01:08ChrisL_leaverou: better than nothing and they use tests
01:08dbaronFlorian: editors drafts or TR?
01:09fantasaiChrisL_: There was this thing about using scripts on our own site
01:09fantasaiChrisL_ talks about w3c publishing policy
01:09fantasaiTabAtkins: It&#39;s just the images that aren&#39;t local
01:09fantasaiChrisL_: It&#39;s a static snapshot?
01:09* jensimmons waves
01:09fantasaiTabAtkins: Based on current state of database when you generate it
01:10fantasaiChrisL_: Then it needs to be very careful to be labelled as such
01:10tantekDo any other specs on /TR have it?
01:10fantasaileaverou: Could we make it live?
01:10fantasaiTabAtkins: But then you have more live dependencies
01:10fantasaiTabAtkins: I don&#39;t like having lots of live dependencies
01:10fantasaiChrisL_: We have live dependencies for tests, it&#39;s great
01:10fantasaileaverou: It&#39;s extremely misleading for ppl, especially because we take years to publish a new spec
01:10fantasaiTabAtkins: Which is a reason to keep it for EDs only
01:10fantasaitantek: What&#39;s being asked for?
01:11fantasaiFlorian: Our specs don&#39;t have it, others doo
01:11fantasaitantek: whatwg uses them
01:11ChrisL_tantek: do any s[ecs on /TR have this now?
01:11* astearns waves back to jensimmons
01:11ChrisL_tantek: no-one else at w3c has done this, is that a blocker?
01:11ChrisL_fantasai: want us to have an updated /TR rather than ED and what stops us is the process of publishing
01:12ChrisL_... now we have echidna, no readon why an editor can&#39;t get a resolution and push to /TR
01:12ChrisL_tantek: lots of reasons why thwat doesn&#39;t happen
01:12ChrisL_fantasai: once it is resilved no reason not to push to /TR.. want them to be a s useful as ED so ED can be the scratch space
01:13ChrisL_tantek: agree but out of scope for this issue
01:13ChrisL_fantasai: having useful stuff in ED and not TR stops us publishing
01:13ChrisL_tantek: way out of scope
01:13ChrisL_fantasai: want them to be equivalently useful
01:14ChrisL_tantek: blocking on this is not reasonable
01:14ChrisL_leaverou: idf we add them on ED then we should add on TR as well and live, not stale
01:14* jensimmons reads backscroll. Wonders if minuteman is a man. Sighs deeply, after a trainwreck of a week, watching male supremacists light dumpster fires in the path of her career. Sighs again, goes to switch the laundry and pour a glass of wine.
01:14* Zakim sees no one on the speaker queue
01:15ChrisL_fantasai: even ED can go for a time without being updated, like scroll snap where there are no edits but impl data updates
01:15ChrisL_plinss: (explains multiple pass database regeneration)
01:16ChrisL_astearns: want these to be in /TR and as that is not regwnerated we need it to be live. tab can we do that/
01:16ChrisL_TabAtkins: annoying duplicate paths but can do
01:16* tantek jensimmons saw your note. sympathize and agreed.
01:16ChrisL_astearns: updated from spec
01:16* dauwhe waves at jensimmons while shaking fist at world at large
01:16ChrisL_leaverou: how about bs does it and then a script updates
01:16ChrisL_TabAtkins: sure
01:17ChrisL_... plins wil write it
01:17* fantasai jensimmons, yes minutemen were men https://en.wikipedia.org/wiki/Minutemen
01:17ChrisL_leaverou: what about features behind a flag hides vendor interest
01:18ChrisL_TabAtkins: decided that behind a prefix is hidden because wanting to see what can be used. explaining what is available with what prefixes is ....
01:18* tantek fantasai I&#39;m not sure a historical gendered reference is helpful here.
01:18ChrisL_??: canisue can be updated very slowly
01:18* fantasai pretty sure its the source of the name
01:19ChrisL_rachelandrew: fins caniuse often out of date
01:19ChrisL_Rossen: microsoft updates mdn
01:19ChrisL_till: we could make an api to get that easily from mdn
01:20fantasaiScribeNick: fantasai
01:20fantasairbyers: MDN doesn&#39;t have a nice API like caniuse does
01:21ChrisL_s/we could/Mozilla could
01:21fantasairbyers: We&#39;ve talked with MDN folks about that before
01:21fantasairbyers: For case of developers, they&#39;re already going to caniuse
01:21fantasaitill: If that&#39;s what it takes to get us all to agree on updating this data, then it&#39;s a stron greason to do this
01:21fantasaiFlorian: There&#39;s also no reason for caniuse to not use that data, if it&#39;s available through an API
01:21fantasaileaverou: Even if purpose is not for implementor nterest, but for developers
01:22fantasaileaverou: But it makes a difference between not implemented at all maybe not arriving, or whether it&#39;s implemented behind a flag and coming up
01:22fantasaileaverou: Recently I solved an issue in images 4 where there was a table, everything was gry, no implementations
01:22* tantek wonders if this may be an example of the &quot;better&quot; being the enemy of the &quot;good enough for now&quot;
01:22fantasaileaverou: I clicked thorugh a link, and it was a wall of green. Why trust the tables if discrepency is so big
01:23fantasaiTabAtkins: No guarantee that stuff behind flag or prefix is anything similar to what&#39;s in the spec
01:23fantasairachelandrew: We need to expose things behind a flag so we can get feedback from developers
01:23fantasaiFlorian: Cna we sort of resolve on this and file bugs on Tab and Peter or?
01:23fantasaieae: It&#39;s only really useful if there&#39;s a reasonable expectation that it&#39;s at least somewhat recen tor up to date
01:24fantasairbyers: Devs find caniuse very useful even though not up to date,
01:24fantasaiFlorian: But it&#39;s not 3-4 years out of date
01:24fantasairbyers: If what you really wnat is behind a flagg use case, the only wayt ot get that is an automated system
01:24fantasairbyers: W...
01:25fantasairbyers: We&#39;re going to make a tool available later, called API Confluence Dashboard, similar to Edge API Catalog, but it&#39;s an automated tool that lists all fo the APIs available in every browser and how they&#39;ve changed over time.
01:25fantasairbyers: This is furhter out, but if we want to tackle what things are under development, this might be more practical way to tackle long term. It&#39;ll always be fresh
01:25leaverous/I clicked thorugh a link/I clicked through the caniuse link/
01:25fantasaismfr: geneated by software?
01:25fantasairbyers: Yes, used by walking ? graph
01:25fantasairbyers: Not good for all features, but somethings
01:26fantasairbyers: Depends on browser being available on browser stack
01:26fantasaiChrisL_: Safari Tech Preview, I was using it in browser stack yesterday
01:27Rossenfantasai: sounds like we have lots of ideas but haven&#39;t documented how/where to do it
01:27fantasairbyers: maybe 2 outcomes from this, use Tab&#39;s caniuse for now
01:27fantasairbyers: And have a small group to discuss making btter
01:27fantasaitantek: Yeah, have something that works today, let&#39;s go with that, experiment on ED
01:27fantasaitantek: and then solve in /TR later
01:27fantasaieae: Risk of bad data being propagated
01:27fantasaitantek: Yeah, so try out on EDs
01:27fantasaitantek: Don&#39;t wait for perfect being enemy of the good
01:28fantasaifantasai: So, plan is enable caniuse panels on EDs, and investigate better ways of exposing data and putting on /TR
01:29fantasaiRESOLVED: Add caniuse panels to CSS EDs
01:29fantasaiRossen: Further fallout is to discuss better ways of exposing the data
01:29fantasaiRossen: in useful and more predictable ways
01:29fantasaiRossen: Don&#39;t have to decide on this now.
01:30dbaronfantasai: people who are interested in figuring out how to collect/expose data should have a side discussion
01:30dbarontantek: drop it into a github issue?
01:30smfrs/walking ? graph/walking the object graph/
01:30dbaronfantasai: sure, side discussion while we&#39;re here, but keep things someplace where others can participate
01:30dbaronTopic: break
01:31fantasai<br type=coffee
01:31dbarongithub-bot, intro
01:31github-botMy job is to leave comments in github when the group discusses github issues and takes minutes in IRC.
01:31github-botI separate discussions by the &quot;Topic:&quot; lines, and I know what github issues to use only by lines of the form &quot;GitHub topic: <url> | none&quot;.
01:31github-botI&#39;m only allowed to comment on issues in the repositories: dbaron/wgmeeting-github-ircbot w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts.
01:31github-botMy source code is at https://github.com/dbaron/wgmeeting-github-ircbot and I&#39;m run by dbaron.
01:38* dauwhe waves at github-bot
01:39* tantek jensimmons ^^^ FYI, say hi to github-bot
01:53TabAtkinsScribeNick: TabAtkins
01:53RossenTopic: Writing Modes implementation report
01:54TabAtkinskoji: The current status of WM is tha twe have an impl report.
01:54TabAtkinskoji: In the topic.
01:54TabAtkinskoji: And a DoC update.
01:54* tantek like since the morning, in case we are using trackbot
01:54TabAtkinskoji: One open issue from Boris.
01:54* tantek trackbot, where are we
01:54trackbotSorry, tantek, I don&#39;t understand &#39;trackbot, where are we&#39;. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
01:54* tantek trackbot, pointer
01:54trackbotSorry, tantek, I don&#39;t understand &#39;trackbot, pointer&#39;. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
01:54ChrisL_rrsagent, here
01:54RRSAgentSee http://www.w3.org/2017/04/19-css-irc#T01-54-55
01:55TabAtkinskoji: If there are any comments on the impl report or DoC...
01:55TabAtkinskoji: Hopefully solve the last open issue, and get the resolution to publish
01:55TabAtkinskoji: If anyone has feedback, please let me know
01:55TabAtkinsFlorian: I have on both.
01:55TabAtkinsFlorian: Some detailed feedback, but first...
01:56TabAtkinsFlorian: I think we should indeed go to PR with this module; it&#39;s in a good shape.
01:56TabAtkinsFlorian: The impls are coming along, and there are political reasons to take a stand and say this has made progress.
01:56TabAtkinsFlorian: But we should do it with the understanding that we are stretching a little the dfn of what a REC is.
01:56TabAtkinsFlorian: Our charter says &quot;2 indep.. impls of each feature&quot;, and that&#39;s fuzzy - what&#39;s a feature?
01:57* tantek um, we&#39;ve been doing this long enough to know better in this WG
01:57TabAtkinsFlorian: We don&#39;t need 2 impls of the entire spec as a block; I think we have two impls of each testable statement.
01:57TabAtkinsChrisL_: That&#39;s correct.
01:57* tantek like at least a property is a feature, or a value
01:57TabAtkinsfantasai: For example, WM in table cells. Impls do slightly different things.
01:57TabAtkinsfantasai: It&#39;s a fairly signficant use-case for vertical text, but it flat-out doesn&#39;t work.
01:57TabAtkinsFlorian: So it rotating a table cell is a feature, we ahve it, but we don&#39;t ahve sizing in the same browser.
01:57* tantek this is not sounding like interop to me
01:58TabAtkinsfantasai: So it&#39;s more of a weird way the test got split out.
01:58TabAtkinsFlorian: Haven&#39;t tried this test-case in the latest everything, but recentyl, not a single browser does everything.
01:58TabAtkinsFlorian: Enough browsers pass each aspect that we can pass all the tests, but none pass it meaningfully.
01:58TabAtkinsRossen: What do you think should do?
01:58TabAtkinsFlorian: [details that I missed]
01:59* tantek this is a really bad idea to intrepret 1 test = 1 feature
01:59* fantasai asks tantek to not use /me for comments that are useful for the record :)
01:59TabAtkinsFlorian: With that said, I think we should still go to PR.
01:59* tantek fantasai I don&#39;t know how to phrase it OTR without freaking people out
01:59TabAtkinsFlorian: This is a large enough spec with fingers everywhere; we&#39;ll find issues for years. If we wait for it being 100% complete, we&#39;ll never go to rec.
02:00TabAtkinsFlorian: Just want to make it clear that just having unit tests passing doesn&#39;t mean the job is done.
02:00* fantasai notes that while Dael-formatted minutes will often include useful /me comments, auto-generated logs often omit them
02:00* Zakim sees no one on the speaker queue
02:00TabAtkinskoji: as far as I understand.
02:00* tantek zakim, who is no one?
02:00* Zakim I don&#39;t understand your question, tantek.
02:01fantasaiTabAtkins: Passing all unit testsisn&#39;t enough to say you implement the feature, you do need integration tests
02:01TabAtkinskoji: ...w3c process means you ahve to pass unit tests
02:01TabAtkins(If you can pass all the tests but not implement the feature correctly, there aren&#39;t enough tests.)
02:01TabAtkinsRossen: That&#39;s fine. People will find bugs, they&#39;ll file, we&#39;ll become more interoperable...
02:01TabAtkinsiank_: We&#39;ll be doing a revamp of our table code probably 9-12 months from now.
02:02TabAtkinsiank_: Expect we&#39;ll have more feedback at that time.
02:02TabAtkinsFlorian: To be clear, I didn&#39;t take tables as the sole thing; it&#39;s representative, and I was putting together a talk for the AC.
02:02TabAtkinsFlorian: I was doing some example coding and saw we didn&#39;t have interop.
02:02TabAtkinsdbaron: I&#39;m worried about how this interacts with intrinsic sizes. Much is not in WM, some is in Sizing, some I think is not defined.
02:03TabAtkinsdbaron: I think when you say something &quot;doesn&#39;t work&quot;, it&#39;s because it doesn&#39;t do what you expect, but the obvious way you can fix the spec might not be something we&#39;re willing to do.
02:03TabAtkinsdbaron: So it might take changes to the spec to get to the point where we agree on an intrinsic sizing behavior. Maybe substantial.
02:03TabAtkinsdbaron: So this makes me worried to take this to PR right now.
02:04TabAtkinsFlorian: Agree. I still think PR is useful for political reasons.
02:04TabAtkinsiank_: Intrinsic sizing isn&#39;t well-defined for WM, right?
02:04TabAtkinsfantasai: It is, I think.
02:04TabAtkinsdbaron: I disagree.
02:04tantekThis sounds to me like 1) we don&#39;t have actual interop (use cases), 2) if we don&#39;t know what features are features, we are underspecified CR exit criteria, and need to fix that with a new CR that specifies it, 3) if we have disagreement among browsers on how these features work right now, it is likely we will need normative changes to fix it, which means we need a new CR
02:04TabAtkinsfantasai: It requires doing layout.
02:04TabAtkinsdbaron: Which I don&#39;t ever want to do.
02:04TabAtkinsfantasai: ...which Firefox and Chrome don&#39;t have the architecture for, yes.
02:05* TabAtkins elika, I missed the last part of your statement
02:05* TabAtkins fantasai ^^
02:05fantasaifantasai: but Edge does, IIRC
02:05TabAtkinsFlorian: For this spec, we&#39;ll find issues for a ver long time. I&#39;m not sure it would be a good mov epolitically to delay the spec for 5-10 years.
02:05dbarondbaron: I don&#39;t think that it requires not addressing those use cases
02:05tantek&quot;will find problems a very long time&quot; is just normal maintenance expectations and must not be used as an excuse for any decision
02:05TabAtkinsFlorian: HTML has gone with some holes and vagueness.
02:05TabAtkinsFlorian: We have a fairly comprehensive test suite.
02:06fantasaifantasai^: Solving vertical text in table cells requires doing intrinsic sizing after layout, and I don&#39;t think it&#39;s reasonable to say that we will never solve what is a major use case of vertical text
02:06TabAtkinsTabAtkins: Mentioning HTML in this regard isn&#39;t meaningful.
02:06fantasai(that line goes beore dbaron&#39;s comment)
02:06TabAtkinsFlorian: There&#39;s been substantial push from Japanese gov to get this to a more stable level.
02:06surmapresent+ Surma, Google
02:06TabAtkinsFlorian: As a milestone.
02:07TabAtkinsFlorian: Maybe we wouldn&#39;t ideally want to call it Rec, but that&#39;s the name we have; we can still ahve things to fix.
02:07TabAtkinskoji: Ignoring the JP community, Rec always to me means there can still be work to do.
02:07TabAtkinstantek: That&#39;s false. &quot;There&#39;s always maintenance&quot; is true for everything. But it&#39;s a difference of degrees - there&#39;s a difference between holes and interop.
02:08TabAtkinsfantasai: There&#39;s always going to be interop - CSS2.1 still does. There&#39;s a threshold you can hit.
02:08astearnss/interop/interop issues/
02:08TabAtkinsfantasai: It&#39;s always a judgement call, and a reflection of the issues we have going in.
02:08TabAtkinsfantasai: I think there&#39;s still some issues to edit in, but there&#39;s not much issues coming in for the spec itself, just minor details.
02:09TabAtkinsfantasai: There are a lot of impl bugs - this spec affects *every* layout system - and there will be forever.
02:09TabAtkinstantek: You&#39;re using incoming issues as a metric - Florian, did you file issues for these?
02:09TabAtkinsFlorian: No, because they&#39;re not spec bugs as far as I can see. I could be wrong.
02:09TabAtkinstantek: If you can&#39;t make a judgement call, file an issue.
02:09TabAtkinstantek: So someone else can decide.
02:10TabAtkinsfantasai: A large part of the ocmplexity of the spec is its interaction with all of CSS 2.1.
02:10TabAtkinsfantasai: There&#39;s no error in how the interaction is described, there&#39;s just a lot of details that can get wrong.
02:10TabAtkinstantek: A particular issue that bothered me - behavior in table cells.
02:10fantasais/wrong/wrong in implementations/
02:11TabAtkinstantek: In 2.1, how properteies worked in/out of table cells was one of our biggest sources of interop problems.
02:11TabAtkinstantek: So if we can&#39;t even do that, we have major problems.
02:11SimonSapins/In 2.1/In CSS 1/
02:11TabAtkinsFlorian: I don&#39;t know if it&#39;s a spec problem - my reading isn&#39;t showing a problem - but are impls wrong because they don&#39;t know it&#39;s wrong, or they know it but can&#39;t fix it?
02:11* tantek thanks SimonSapin
02:11TabAtkinsrbyers: That&#39;s waht tests are for.
02:12TabAtkinsFlorian: I don&#39;t have budget for detailed investigation work. I&#39;m just raising the flag.
02:12TabAtkinsFlorian: So being aware of that, do we do that and go to Rec in a year or five, or go to Rec for political reasons and still fix it.
02:12TabAtkinsdbaron: A third possibility is that the impls *are* doing what&#39;s specified... there&#39;s plenty of holes.
02:12* skk koji is going to eat Tuna? (sorry koji)
02:13TabAtkinsfantasai: There&#39;s bits where things are defined &quot;analogously to 2.1&quot; - if you don&#39;t make that translation correctly, you get some bugs.
02:13TabAtkinsfantasai: That&#39;s where most of our issues come from - people not applyign the analogy fully and correctly.
02:13TabAtkinsfantasai: Different from Flexbox or the like, where interop issues are a problem directly in the spec.
02:14TabAtkinstantek: I see that; we had similar with box-sizing, and we had to go into more detail. Maybe that&#39;s the solution.
02:14TabAtkinsfantasai: That means rewriting the 2.1 block/inline layout specs, which isn&#39;t happening right now.
02:14TabAtkinstantek: Sure. But currently our features just don&#39;t pass the interop guidelines.
02:15TabAtkinsRossen: I don&#39;t believe this is true. I agree with fantasai that WM is a horizontal feature that cross-cuts, like intrinsic sizes.
02:15tantekFundamental problem is: do use-cases have interop or not?
02:15TabAtkinsfantasai: Like logical properties; we don&#39;t define each individual property, we just describe the mapping and the names.
02:16TabAtkinsRossen: Counter-example to get away form WM for a second - when we started defining fragmentation, another horizontal feature, we had a choice - start defining how fragmentation works for everything, and put all of this into one single spec, or define the basic rules and what it is and how it&#39;s supposed to be applied, then every other layout module defines
02:16TabAtkinshow it happens.
02:16TabAtkinsRossen: WM is not that different.
02:16TabAtkinsRossen: Going thru the WM spec, the WM part is pretty well-defined.
02:17TabAtkinsRossen: There are interactions with every layout module, there will be integration issues - a flexbox isnide a table inside a grid, all with different WMs, there will be issues that impls have to work thru, and we do.
02:17TabAtkinsRossen: That&#39;s not a WM problem, that&#39;s an integration problem.
02:17TabAtkinsRossen: So for horizontal features, I don&#39;t want us to have to pull all of CSS into the feature and blaming all the buggy integrations on this particular spec.
02:18TabAtkinstantek: I get that, but a bit of a strawman - inside a table cell or not, or inside an abspos or not. Those seem simple circumstances, that an author would expect to work.
02:18TabAtkinstantek: If we don&#39;t ahve tests that demonstrate interop on that, I find it hard to believe we have interop.
02:18TabAtkinskoji: We have those tests, but only some are passed in each browsers.
02:18TabAtkinsFlorian: Worse, each layout mode not only has to work in other WMs, it has to work in orthogonal flows.
02:19TabAtkinsFlorian: We have only 1k tests - it can&#39;t cover everything.
02:19TabAtkinsFlorian: But if we cover everything that exists today, we&#39;ll never finish.
02:20TabAtkinstantek: Still strawman. If tehe simple examples you came up with, just to show something at the AC meeting, that&#39;s stuff we shoudl look into.
02:20TabAtkinstantek: You&#39;re not making a newspaper, just simple examples. If you don&#39;t ahve interop there, something&#39;s broken.
02:20TabAtkinstantek: Maybe spec, maybe impls, but we have to investigate.
02:20TabAtkinstantek: I&quot;m not asking for perfection.
02:20TabAtkinskoji: So what do you say when two impls pass?
02:21fantasaiTabAtkins: He&#39;s saying that we have a theoretical integration test passing, even though unit tests pass
02:21TabAtkinstantek: Not even a complicated one - no deep nesting - just simple &quot;in a table cell&quot;.
02:21TabAtkinsRossen: So there are impls that are behind, and it&#39;s up to them to catch up.
02:21fantasaikoji: Blink and Webkit don&#39;t implement it in table cells, but we plan to implement it
02:22TabAtkinsFlorian: And the two that have it, MS and Moz, behave differently, and neither is good.
02:22TabAtkinsFlorian: Moz doesn&#39;t implement sizing - your table cell will be rotated but sized wrong.
02:22TabAtkinsRossen: So it&#39;s an impl problem, file a bug.
02:22TabAtkinsFlorian: Unless MOz won&#39;t fix it - then it&#39;s a spec problem.
02:23TabAtkinsrbyers: Sounds like we should have a more integration-y test.
02:23fantasaifantasai^: Koji said that Chrome/Blink will fix it though
02:23TabAtkinsRossen: So currently 98% passes in two impls.
02:23TabAtkinsRossen: Which