<zcorpan> Simon Pieters, Opera

<MichaelC> CSS A11Y TF Work Statement

<dauwhe> Dave Cramer, Hachette Livre

<glazou> Daniel Glazman, Disruptive Innovations

<Florian> Florian Rivoal, Vivliostyle

<iank_> Ian Kilpatrick, Google (an Alphabet Company)

<dino> Dean Jackson, Apple

<myles> (Myles C. Maxfield, Apple, Inc.)

<nainar> Naina Raisinghani, Google

<ChrisL> Chris Lilley, W3C

<SimonSapin> Simon Sapin, Mozilla

<leaverou> Lea Verou, Invited Expert

<birtles> Brian Birtles, Mozilla

<Rossen> Rossen Atanassov, Microsoft

<rego> Manuel Rego, Igalia

<MichielBijl> Michiel Bijl, The Paciello Group

<tantek> Tantek Çelik, Mozilla

<tomalec> Tomek Wytrębowicz, Starcounter, Poland

<fantasai> Janina: Idea was that we'd organize our work

<dbaron> L. David Baron, Mozilla

<richardschwerdtfeger> https://www.w3.org/WAI/APA/task-forces/css-a11y/work-statement#main

<skk> Hiroshi Sakakibara, BPS

<fantasai> Janina: Started to see same issue with multiple specs

<fantasai> Janina: Don't want to hold back CSS, but have some real issues wrt accessibility

<fantasai> janina: Wanted to bring together APA and AR? expertise

<fantasai> janina: Don't want to go off on our own andmisinterpret the spec

<fantasai> janina: Togther there are certain things we can do that would help, and ltimately solve issues we've identified

<fantasai> janina: For instance, had good success in ARIA WG with mappings

<fantasai> janina: a11y API mapping specification

<fantasai> janina: Worked through W3C process through REC, tested and implemented and implementable

<fantasai> janina: Test and validate your implementation of a11y

<fantasai> janina: Many things can be handled by CSS-a11y mapping, that's why ARIA is involved

<fantasai> janina: Until a week ago, a11y mappings were owned by ARIA... HTML mappings are their own story

<fantasai> janina: Furthermore, some access among our various members to the various platforms where we are mapping

<fantasai> janina: So if we're missing support on the OS side, have opportunity to do somehting there

<fantasai> janina: Whether that covers everythng, expectation is probably not

<fantasai> janina: May need a Best Practices as well

<fantasai> janina: But after looking at various issues, group that goes to wok on this can decide what gets handled

<fantasai> janina: Another YAM, best practices, and maybe some tweaks to specs

<fantasai> janina: talk about that it coordinated and cohesive manner

<fantasai> janina: Excited about this, overdue collaboration

<MichaelC> CSS AAM stub (will migrate to a new repo soon)

<fantasai> janina: Wrt draft of ?, Michael and I did some work on it

<fantasai> janina: APA approved it, but it's a starting point

<fantasai> janina: Will have a TF, chairs will appoint facilitators

<fantasai> janina: Expecting group will meet on some regular schedule, a lot of async communication, some telecons, etc. usual range of tools for communication

<fantasai> janina: That's organizational perspective we've put forward

<fantasai> janina: Also had a document prepared for us, making argument for why we though TF was really necessary

<fantasai> janina: Prepared by one of our members who suddenly and unexpectedly is no longer part of W3C

<fantasai> janina: Didn't get that email til yesterday...

<fantasai> janina: Was hoping she'd give us a quick overview of the issues

<fantasai> janina: Asked Rich to give an overview

<MichaelC> CSS AAM Potential Features

<fantasai> richardschwerdtfeger: OK, so, how this started is we had found some issues where CSS was injecting content, and we didn't have mapping sacross the browsers for that

<fantasai> richardschwerdtfeger: We'd also found issues with Flexbox, working through that

<fantasai> richardschwerdtfeger: Have been working with HTML and SVG, and all those languages have mapping specs

<fantasai> richardschwerdtfeger: Able to make issues, make sure whatyou put in gets mapped

<fantasai> richardschwerdtfeger: Talked with Rossen about how to go about this.

<fantasai> richardschwerdtfeger: Wanted to make sure a11y issues are addressed early on, bc CSS critical to web

<fantasai> richardschwerdtfeger: So platform was crated

<fantasai> richardschwerdtfeger: Don't need mappings for everything, but those things athat are cirtical

<fantasai> richardschwerdtfeger: TF is members of a11y and CSS, addressing a11y issues

<fantasai> richardschwerdtfeger: Make sure that content and presnetation is addressed by WG as a team

<fantasai> richardschwerdtfeger: We haven't agred on TF work state, next step is how do we populate a group that will work on these issues together

<fantasai> richardschwerdtfeger: Was just told by joni diggs (????) who would like to be an editor, but need more than that. Need members of CSSWG

<fantasai> Rossen: I tink that's a great summary

<fantasai> Rossen: I've been communication g what we've talked about with the CSSWG, we have few telecon time slots to tlak about going forward, how to proceed in terms of participating in TF and what TF isactually going to do

<fantasai> Rossen: Quick summary for benefit of everying, of what mapping spec is

<fantasai> Rossen: They are fairly different from most specs we do in CSS

<fantasai> richardschwerdtfeger: What peopl opften don't think about when creating Web content is that they're congributing to a software application

<fantasai> richardschwerdtfeger: Every OS has a11y services that communicate necessary nfo to assistive technlogy, e.g. text on screen, role is, how it relates to othe rcontent, where th ekeyboard focus is, etc.

<joanie> Example mapping spec: https://rawgit.com/w3c/aria/master/core-aam/core-aam.html

<fantasai> richardschwerdtfeger: That info is mapped to platform API

<fantasai> richardschwerdtfeger: On every single OS

<fantasai> richardschwerdtfeger: So write once, accessible on all platforms

<fantasai> richardschwerdtfeger: as long as you write a11y code

<fantasai> richardschwerdtfeger: In CSS, when oy do things like inject content, want to make sure it maps to those serices

<fantasai> richardschwerdtfeger: For HTML ARIA try to make mappings for that

<fantasai> richardschwerdtfeger: We do ...????

<fantasai> richardschwerdtfeger: Would do same thing here

<fantasai> richardschwerdtfeger: You end up behaving just like accessible software app on that platform

<fantasai> Florian: Since CSS doens't exist in a vacuum but exists on top of HTML

<fantasai> Florian: Mappings we define here, just need to have diff from HTML mapping, right?

<fantasai> richardschwerdtfeger: Yeah fo examppe with content injection in CSS

<fantasai> richardschwerdtfeger: Doens't show up in DOM, there's an OM that shows up.

<fantasai> astearns: Before going into details, ChrisL on the queue

<fantasai> ChrisL: Gone thorugh work statement, in gneral it's fine

<fantasai> ChrisL: One thing that is different from our charter, our charter says that documents ill be co-published

<fantasai> ChrisL: Whereas work statement here is that one group will publish. Sort of uncomfortable

<fantasai> janina: Don't think we meant that, did we ?

<fantasai> ChrisL: Wiling to change?

<fantasai> janina: Yes

<fantasai> ACTION Janina fix charter to co-publish

<trackbot> Error finding 'Janina'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.

<fantasai> Rossen: I'll try to give quck soummary of work that was identified for the TF

<fantasai> Rossen: Problem statemnt here is that CSS affects the a11y layer in 2 major ways

<fantasai> Rossen: First one is when we end up affecting structure like injecting generated content, or in case of table fixup, more elements that ar mapped

<Zakim> ChrisL, you wanted to mention co-publication

<fantasai> Rossen: Second part that we've been having a11y related issues have been when there's visual changes that are drastically different from DOM order, such as flex-order property

<Rossen> https://github.com/w3c/aria/wiki/CSS-AAM-Potential-Features

<fantasai> Rossen: So in order to get things going, Cynthia Shelly who was MS representative for APA and other a11y groups created a quick outline of all of the modueles that might have a11y issues

<fantasai> Rossen: As you can see, breakages the work that will be covered, related to reading/navigation order

<fantasai> Rossen: Flexbox, grid and positioning are called out explicitly

<fantasai> Rossen: There is generated content and ...

<fantasai> Rossen: Documents of existing features that are implemented

<fantasai> Rossen: e.g. Generated content

<fantasai> Rossen: Which is supposted to be accessible, but isn't implemented as such

<fantasai> Rossen: Did some work in Edge recently to address some of these issues. Can attest that this type of work is not all that hard to do, and improves a11y layer a lot

<fantasai> Rossen: Don't want to list all the specs out loud but this is set of work that has been identified

<fantasai> Rossen: Kickstart discussion

<fantasai> Rossen: I have volunteered myself

<fantasai> Rossen: to join the TF and help the work forward

<fantasai> Rossen: Would be very happy to have other CSS members

<fantasai> astearns: Two questions. One is question of editorship -- who is tasked with putting all the info into the document?

<fantasai> astearns: Then further question of just participating in the TF, not necessarily writing specs

<jcraig> +1 to address the generated content comment. Pseudoelements are mapped to the a11y layer in Chrome, Safari, (and possibly Firefox?), constituting a majority.

<fantasai> astearns: Are you also volunteering yourself as an editor

<fantasai> astearns: Anyone else from CSS interested in the TF for participation?

<fantasai> astearns: I am definitely interested

<fantasai> astearns: A couple ppl from MS

<fantasai> dauwhe: I'm interested

<fantasai> jcraig: Me too

<fantasai> iank_: participation wrt Houdini

<fantasai> astearns: Editing?

<fantasai> MichielBijl: I'm interested, from APA

<fantasai> fantasai: I'm willing to help out

<gregwhitworth> s/a couple ppl/Francois & Greg

<fantasai> fantasai: I think one thing that I should be working on is the Best Practices document

<fantasai> astearns: Was at chairs breakfast this morning, talking about wid reivew esp by groups like APA

<fantasai> astearns: One thing that helped me in my writing is not just having a Best Practices document, with cirteria

<fantasai> astearns: But having a list of questions, like the security questionnaire

<fantasai> astearns: Short questionnaire so as ppl stat writing specs, they have something to refer to

<fantasai> astearns: Mayb esme of the work in best practices can be done as a short questionnaire on accessibility gotchas that editors can refer to

<fantasai> Rossen: I think fantasai was referring to .. we committed last TPAC to write best practices for authors of CSS

<fantasai> Rossen: This is something that will go a long way, I think there will be value of having reference directly from CSSWG

<fantasai> Rossen: Can hold this as formal recommended practices from our POV

<fantasai> ?: I'm willign to collaborate on best practices, so that we refer to each others' documents

<fantasai> ?: ARIA authoring practices guide

<aboxhall> Matt King, facebook ^^

<MichielBijl> > http://w3c.github.io/aria-practices/

<Zakim> MichaelC, you wanted to ask permission to set up TF infrastructure etc. and to differentate AAM from APG

<fantasai> MichaelC: We were focused on a11y mapping specification

<fantasai> ttp://fantasai.inkedblade.net/style/talks/best-practices/#title

<fantasai> http://fantasai.inkedblade.net/style/talks/best-practices/#title

<fantasai> MichaelC: Not sure that best practices belong in ARIA best practices

<fantasai> Matt: Want to make sure documents are coordinated

<fantasai> MichaelC: What I do with TFs is to set up an ? in formal W3C infrastructure for participation

<fantasai> MichaelC: Will have to talk about ML, anyone object?

<fantasai> ChrisL: Certainly not objecting. In this WG we're trying to move away from MLs to GitHub

<fantasai> ChrisL: Would encouage TF to work on that

<fantasai> MichaelC: Put in link to ? would move t new github repo

<fantasai> MichaelC: Do you want me not to et up an ML?

<fantasai> ChrisL: No, go ahead, useful for some stuff

<fantasai> MichaelC: Didn't want to do without permission

<Zakim> jcraig, you wanted to address the generated content comment. Pseudoelements are mapped to the a11y layer in Chrome, Safari, (and possibly Firefox?), constituting a majority.

<fantasai> jcraig: Rossen mentioned pseud-elements mapping to a11y layer

<fantasai> jcraig: Generated content mapped in majority of browsers... Chrome and Safari at least... Possibly Firefox (Joanie responded ~"-ish")

<fantasai> jcraig: The issue that Michael just brough that 's interesting is, a separate github repo...

<fantasai> jcraig: I have reservations about accessibility TFs within WGs.

<fantasai> jcraig: It ends up getting groups of ppl siloed, so a11y ppl on one side and CSS ppl not in the TF don't learn about the a11y side

<fantasai> jcraig: My general approach is that this type of work should happen in the main group

<fantasai> jcraig: I feel that works a little bit better

<fantasai> +1

<fantasai> astearns: I share your concerns

<fantasai> jcraig: separate github repo ..

<fantasai> astearns: I think github repo for deliverables is ok

<fantasai> astearns: My epxectation for TF is that it's a coordination function

<fantasai> astearns: CSS folks in TF wouldn't be only ones doing work, would be the ones outlining the work and drawing in each editor as specs need mapping, adjustment, review, etc.

<fantasai> astearns: On CSS side, ppl not directly on TF, don't assume that you have no a11y work that is going to be assigned to you!

<fantasai> astearns: Just TF ppl will be ones coordinating

<fantasai> MichaelC: core stuff about how CSS maps into a11y

<fantasai> MichaelC: Often times a piece of that work will start in that spec, and then needs to move xyz place

<fantasai> MichaelC: I think coordnation role of TF makes that easy to do

<fantasai> MichaelC: TF can set up prefs for access to repo to everyone or just editors or whatever

<bobbytung> s

<fantasai> MichaelC: also want to know if ppl invovled prefer or oppose telecons

<fantasai> Rossen: I'm in favor of starting with light telecon requirements

<fantasai> fantasai: Maybe monthly?

<fantasai> Rossen: Yeah,s omething liek that. Otherwise work on githup issues etc.

<fantasai> MichaelC: Also what level of checking goes thorugh WG?

<fantasai> MichaelC: e.g. sometiems TF will go to parent WG for each thing

<fantasai> fantasai: probably we'll do both

<astearns> fantasai: if an issue is a bug fix, then it just gets written

<astearns> fantasai: if it's a design issue, it will go back to the WG for feedback

<astearns> fantasai: (to make sure people are paying attention)

<astearns> fantasai: issue-by-issue basis

<astearns> janina: I imagine it's going to come up regularly to consult with the APA

<MichielBijl> s/j:/janina:/

<Zakim> jcraig, you wanted to +1 for most (all?) discussions happening on GitHub rather than conf calls, as conf calls are imprecise, and inaccessible in both senses of the word.

<tantek> also +1 technical discussions on GitHub rather than mailing lists.

<MichielBijl> +1

MQ

<fantasai> janina: In APA we regularly go over a spec, assign someone to read about a new spec and report

<fantasai> csswg

<fantasai> Rossen: What I was saying is, let's start with the TF as an issue-generator

<fantasai> Rossen: We often have technical discusisons, magine those that require desgin change wil lhave to do with larger participation

<fantasai> MichaelC: We'll ned to pull in... make sure we have expertise from boths ides fo the border.

<fantasai> astearns: At minimum I'd like to see notification, this is whta's been discussed, here's the minutes

<fantasai> astearns: In Most cases don't need extra step of "did we do OK"

<fantasai> jcraig: Regardling what's discussed, minutes.

<fantasai> jcraig: I have a lot of trouble following minutes

<fantasai> fantasai: Have you tried following CSSWG minutes?

<fantasai> jcraig: Those are different

<fantasai> jcraig: But in general, easier to follow discussions on github

<fantasai> jcraig: More accessible in all ways

<fantasai> jcraig: Can have full, precise discussion at any time

<fantasai> jcraig: So prefer to have discussion in text on the Web, most accessible

<fantasai> MichalC: That said, when disagreements, often easier to sort out in telecons

<fantasai> astearns: In CSSWG, as we discuss things on the phone or in F2F meetings, as opinion coalesces, people update github issues to say what we discussed, what we decided, where are the minutes.

<fantasai> astearns: Think that's a good practice going forward

<fantasai> jcraig: Important to summarize, not just link to minutes

<fantasai> [discussion of what to discuss]

<fantasai> janina: Trying to avoid using the word, cuz lots of controversy over attribute, but trying to get beyond that because requirements....

<fantasai> [jokes about longdesc]

<fantasai> janina: Trying to get beyond that, firstly because we don't like doing things that are opposed by browser makers

<fantasai> janina: Secondly have more general requirements from dpub

<fantasai> janina: Issue is, we want to make it possible for someone who isn't using AT to be aware of e.g. simplified description or braille alternative

<fantasai> janina: We have ways to do this for ppl who use assistive technology

<fantasai> janina: What we're looking for is for ppl who don't use AT to get at that additional information, alternative information.

<fantasai> janina: want them to know that ARIA-details is available

<fantasai> janina: Idea was to make extensions/plugins to experiment

<fantasai> janina: The short-term ask is, can we have an MQ that all it does it says that this element has an extended description

<fantasai> janina: Also looking at extended MQs

<fantasai> Elliott: what is the aria thing you're talking about?

<fantasai> Elliott: What computes an aria...

<jcraig> AT == "assistive technology"

<fantasai> Elliott: You wanted an MQ on aria-details, what computes aria-details

<fantasai> dbaron: I'm also a little confused that you're asking for an MQ that's asking about the state of an element

<fantasai> dbaron: MQs are about the presentation context, not about qualities of a particular element

<fantasai> dbaron: Were you maybe wanting a selector?

<tantek> maybe even a pseudo-class?

<fantasai> jcraig: I think that what we were discusisng is related to new aria property that is a string of text that isn't displayed anywhere

<fantasai> jcraig: More or less the same as details and summary in HTML

<fantasai> jcraig: I believe what janina is asking ofr is a media feature that allows you to detect when the user wants to see additional detals

<fantasai> jcraig: If that's the case, then the design, the CSS should be able ot display addition atext

<fantasai> janina: Close bu tnot quite

<fantasai> richardschwerdtfeger: what digipub wants to do is to show extended escriptions o rdrawings on the page

<fantasai> richardschwerdtfeger: This could be alternative formats, coudl be a whole variety of things

<fantasai> richardschwerdtfeger: Problem with digital publish is that by default, publishers don't want this information rendered on the screen

<fantasai> richardschwerdtfeger: But need ability to know that it's there

<fantasai> richardschwerdtfeger: They want to put the conte tin the pages, and they wnat ot e able thte user able to activate a setting i nthe browser, that would tell the book for example, to expose this detailed information with drawings

<fantasai> richardschwerdtfeger: What they're asking for is the ability write a custom media query

<fantasai> richardschwerdtfeger: Maybe through a plugin in the browser

<fantasai> richardschwerdtfeger: So that they could turn on a feature that activeates CSS to expose that t information on the page

<fantasai> richardschwerdtfeger: No opiino in interface

<fantasai> richardschwerdtfeger: Details attribute in ARIA simply says that that extended description is associated with this other thing

<fantasai> richardschwerdtfeger: But publishers want ot not impact the normal visiblity of the page, because they want topreserve the intent of the publisher

<fantasai> richardschwerdtfeger: But for ppl who need the extended info,want to be able to turn that on

<fantasai> richardschwerdtfeger: MQs are generally about OS/device capabilities

<fantasai> richardschwerdtfeger: But htis is about preferences

<fantasai> astearns: A suer preerence

<fantasai> Florian: co-editor, Media Queries

<fantasai> Florian: dpub was still thinking about this idea yesterday

<fantasai> Florian: If it's just about hte dtails element, then seems too specialized for MQ

<fantasai> Florian: But if it's a general "if there's extended descriptions in the page, user wants to see them"

<fantasai> Florian: This goisn into new area of user preferences

<fantasai> Florian: Related to preferences for inverted colors, high contrast, etc.

<fantasai> Florian: We're exploring this category

<fantasai> Florian: Seems to fall into this category, but for e.g. inverte colors, might be thing wishes to see OR might be thing user wishes to see but might have ben forced by browser

<fantasai> Florian: Wrt details, rowser can't do ti for you, page has to do it itsefl

<fantasai> Florian: Need to epxlore more, but given what we've discussed today

<fantasai> Florian: makes sense to me

<fantasai> Florian: Another thing is custom media queries

<fantasai> Florian: We've also discussed custom MQs, based on whatever JS wants to compute

<fantasai> Florian: I'm not sure how this would work out in this case

<fantasai> Florian: Because in the case of custom Qs, this is the JS in the document talking to CSS in the document viwa MQ

<fantasai> Florian: But for this case, you want the plugin to talk to the page via browser

<fantasai> Florian: It doens't sem to really be custom, seems to be standard

<fantasai> riAlso talked about "I would like to render differen tcontent basedon my preference"

<fantasai> ricManagement systems, working on today, have ability to store personal info about hte user

<fantasai> richI would say that weuite know exactly what those are going to look like

<fantasai> ricThis is why extending MQ is a better solution, experiment and figure out what we really need

<fantasai> Florian_: If it's about protyping, then yes makes sense for extending

<fantasai> Florian_: We had custom MQs in Level4, but are deferring to L5 because less stable than other stuff in L4 atm

<fantasai> Florian_: ATm unclear whether will go into MQ or Houdini spec in the future

<fantasai> Florian_: But definitely on the radar

<Zakim> jcraig, you wanted to ask if custom MQ allows for a defined "taxonomy" of de facto MQ

<fantasai> Florian_: Tab and I will b eworking on it, will either go into a Houdin doc or MQ L5 which we wil be starting soon cuz wrapping p L4 nowish

<fantasai> jcraig: ... oggles value of a media feature, tells web page it's ok to expose this info

<fantasai> jcraig: Mentioned working on custom MQs, siilar to data-* attributes in HTML. Allowed to do anything you want, no consistency across websites

<fantasai> jcraig: Is there an affordance here for a standard taxononmy?

<fantasai> jcraig: We'd be discussing something like -epub-prefers-extended-descriptions

<fantasai> jcraig: If there's a list of standard taxononmies, where would that live

<fantasai> Florian_: From my understanding this would be about prototyping in a limited context where pl have agreed on common semantics

<fantasai> Florian_: Once it's no longer experimental, no longer needs to be a custom MQ, can be a standard MQ

<fantasai> Florian_: No need for prefixing

<fantasai> Florian_: ...

<fantasai> Florian_: Room fof expermination if it's boolean, epxressis ...

<fantasai> Florian_: But once no longer prototyping, should be a standard MQ, not a custom one.

<fantasai> astearns: MOve on to navigation?

<fantasai> [discussion of whether to discuss navigation issue]

<tantek> prototyping sounds like incubation

<tantek> how do we incubate new media features?

<MichaelC_> Specs APA thinks are related to the CSS navigation issue (there are more, still need to tag them)

<fantasai> rich: Ther eare times in Flebox where order is improtant to user of AT

<fantasai> rich: What we had was, felxbo was changing thigns visibly on the screen but it wasn't reflected in how it maps to the a11y services layer

<fantasai> rich: You're looking at things in a sequence

<fantasai> rich: that was first par tof the problem

<fantasai> rich: Second part was that the kyboard navigation idnd't qutie navigation din't follow the visual order on the screen

<fantasai> rich: so someon who is blind and is trying to havigate, didn't make sense

<fantasai> rich: There needs to be a discussion on how that can bee corrected. At hte mapping layers, and also how keyboard navigation is addressed

<fantasai> rich: we had propose d away to deal with ekyboard nviagtion when necessary, but much more work tha needs to go on in the TF

<fantasai> rich: when do we change the order? Should we change the keyboard order when flexbo vies display on the screen? Etc. That needs to be discussed

<fantasai> astearns: Last item

<fantasai> astearns: Grid

<dbaron> fantasai: we're planning to transition grid to CR

<dbaron> fantasai: Emailed you at start of year. I think that's going to happen this week.

<Rossen> fantasai: we emailed you about transitioning Grid to CR, do you have an obj?

<dbaron> fantasai: Wanted to check with you if there's any objections to this transition

<MichaelC_> APA notes on Grid

<fantasai> rich: Wasn't involved in that discussion, and have sene where grid is mapped correctly

<fantasai> rich: sturcutral information in CSS, need sto be mapped into a11y tree fwith rows/columns

<fantasai> rich: More cpaability to do that in ARIA 1.1

<fantasai> rich: Haven't looked at Grid, things nee dto be looked at in terms of accessbiliyt tree

<MichaelC_> q_

<fantasai> Matt: Want to make a statement

<fantasai> Matt: So, rich just said that with grid, when affecting structure, need sto be mapped to a11y serices layer

<fantasai> Matt: want to make statmetn that we should nto make any changes to the a11y tree that are also not reflected in the keyboard focus board

<fantasai> Matt: That's very important, that order of a11y tree matches keyorder order

<fantasai> Matt: THat's really important for combination of touch and keyboard. Do not separte these two orders.

<fantasai> janina: I think maybe we need TF to make sthis a priority

<fantasai> janina: Since you're going to CR, not blocking, ahppy to be on a plath to a solution

<fantasai> janina: Mor tools to offer, prioritizing is important

<fantasai> astearns: Grid is important

<fantasai> jcraig: Navigation index?

<fantasai> janina: Best summary is Cynthia's document

<fantasai> Rossen: Back to grid question for minutes, what I heard from APA there is no current objection to proceeding to CR, will work thorugh issues in TF

<tantek> jcraig: nav-index was dropped long ago

<fantasai> Rossen: If any changes come up, we will take...

<fantasai> janina: THis is chair expressing her opnion

<fantasai> MichaelC_: Wanted to say that we have a wiki page or every spec that we look at, and our notes on grid are that we did, three onths ago, plan to work on this in the TF. So don't think we were epxecting to object to a transition.

<fantasai> Florian_: Don't know if you're aware of it, there is in CSs4 UI nav-up/down/left/right properties for spatial navigation

<fantasai> Florian_: The ordered variant of the same, nav-next/nav-prev, are not specced.

<fantasai> Florian_: If you would like them to exist, let us know. If yo uthink they'd be terrible let us know as well

<fantasai> Florian_: There si something along these lines in CSS3 UI

<fantasai> jcraig: Tantek just posted that they died a long time ago

<fantasai> tantek: We took nav-index out ocmpletely years ago

<fantasai> tantek: Based on feedback from a11y and other feedback

<fantasai> jcraig: up/down is still there?

<fantasai> tantek: Yes, in multiple implementations, referencd from TV specs

<fantasai> ?: I like that fo SVG a lot

<fantasai> astearns: OK, out of time, thanks

<fantasai> janina: thanks CSS

<fantasai> astearns: CSS will be on break for the next 20 minutes

<MichielBijl> Thanks all!

<fantasai> janina: APA in our room at 11!

<fantasai> <br>

<tantek> jcraig note: dropped nav-index citation: https://www.w3.org/TR/css-ui-3/#changes-since-2012

<astearns> webex details for the next segment: https://mit.webex.com/mit/j.php?MTID=m0c1976483287cfcf250bf914633bfe36

<astearns> https://mit.webex.com/mit/j.php?MTID=m0c1976483287cfcf250bf914633bfe36

<behdad> astearns: jdaggett: https://twitter.com/abrax5/status/776708619043762176

<behdad> jdaggett: plus the other two things I demoed at atypi

<jdaggett> right, saw that one too

<behdad> jdaggett: full video here: https://www.youtube.com/watch?v=6kizDePhcFU

<behdad> Demos start at about 1:11:00

<behdad> network is horrible here, so webex would probably have not been realistic anyway.

<jdaggett> github issue for font variations support

<jdaggett> https://github.com/w3c/csswg-drafts/issues/498

<jdaggett> my little pony discussion needs to be minuted...

<jdaggett> John Hudson blog post on variable fonts

<jdaggett> https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369#.u93slo7n5

<ChrisL> cwilsohas joined #css

<TabAtkins> ScribeNick: TabAtkins

behdad: Last week at atypi we announced, with Apple, Google, MS, Adobe, we announced opentype 1.8, the biggest change since it first happened.
... Biggest addition is variation fonts. I'll show a demo, then Myles and John will discuss the implications for CSS.
... Our current fonts are scalable in size. VAriation fonts bring that same scaling to other aspects.

[shows a width varation, then a weight]

behdad: Look at dollar sign, it changes to a difference design based on the weight.

<astearns> (applause)

behdad: Similar demo of Arabic script. The ligature and combining marks just work.
... This isin't new, it's based on Apple tech from the 90s. Adobe multiple masters is very similar as well.
... But for the first time it's in OpenType, and extended to handle OT layout.

<ChrisL> (Apple TrueType GX)

behdad: Designers have already been designing with interpolation, they just export to flat/individual instances. We're bringing it to runtime.
... While we bless the most common interp axises, the tech supports arbitrary axises as well.
... Here's a western font with axises that change several aspects of the font.

[changes the buttons, the joints, the way the serifs look]

<fantasai> [behdad shows example of font with circular holes, the etra axis changes the holes from round circles to squares]

behdad: So in CSS we need to hook up weight, width, and other "standard" axises. Then arbitrary axises.

<jdaggett> Example of a family using different axes

<jdaggett> weight and contrast

<jdaggett> http://typeproject.com/fonts/tpmincho

behdad: And really interesting applications is responsive design. Like adjusting the params to fit text into a space.

myles: Two reasons this is valuable to add to CSS.

<glazou> (applause)

myles: First is you get super-great typography.
... Likely the axises will affect weight and stretch. Currently very common for websites to have the same font in multiple weights/stretches. Now they can just have one font.
... Current thinking for how to plug this into font selection breaks down into three pieces.
... These variations are not OT features - that's something different. They interact, but reusing font-feature-settings would be a mistake.
... These sliders are called axises.
... The current thinking of how to map these to CSS is to break down the sliders into three pieces.
... First is axises that affect font selection - weight, width, stretch.
... These are important because we already have proeprties that affect font selection.

<jdaggett> weight, width, slant

myles: So all three of them dont' have a concept of floating point values.
... So presumably some value would be assigned, so if you say "give me a bold font", a variation font could be selected, and then made bold.
... So an extra stage in font selection.
... Those three are expected to be the most common axises.
... Set 2 is common axises that dont' affect font selection.
... One example is optical sizing.
... No existing properties, we'll likely add new ones with associated syntax.
... Set 3 is low-level arbitrary axises.
... Where author can specify whatever name.
... This is important, because in OT, if you make a font you can respond to any axis, even if it's not registered in a spec.
... So conceptually this is similar to font-feature-settings, but this is meant for variations, and will take a floating-point rather than an int.
... So that's basic thinking for mapping.
... I've written a draft spec which isn't in the repo yet.
... Rather than merging draft text into Fonts 4, there are a fair number of high-level issues to resolve (like how to make @font-face respond to this)
... We'd discuss this in GH in issue trackers, and when it dies down then I'd write some text and start adding it to level 4.
... There's one piece I forgot to mention

<ChrisL> https://github.com/w3c/csswg-drafts/issues/498

myles: Witht he font selection I mentioned - if you're on an old browser that doesn't support variations, and you tell it to use this variation font,
... You'll say "apply bold", the browser doesn't know how to, so you'll get a normal version.

<ChrisL> draft spec (fork of css fonts 3, but intended for fonts 4) https://github.com/litherum/csswg-drafts/commits/variationfonts

myles: So maybe an addition to the format specifier so an older browser doesn't even download them if it doesn't know how to use them.

glazou: First, congrats.
... As I understand, this is going to be useful for responsive design.
... ONe of the thing I'd like to avoid is flickering when the font changes at a boundary in your responsive design.
... ONe way of doing that is to do transitions on the font axises.
... If you can make that property animatable in CSS, that would be really awesome.

myles: Being able to animate is a stated design goal in this.

glazou: Good. I wanted to mention because it has deep implications.

Florian: Also this is great.
... I wanted to clarify - how would font selection work?
... Would youb e able to declare a range of weights to use this font, like 100-600, but for 800 use this old-fashioned one?

myles: There are at least 2 models for how this would work.
... Many different parties with diff ideas.
... Web authors that are font designers, and like TypeKit serving fonts.
... We have not reached consensus, in short.

<dbaron> It doesn't seem to me that responsive design would be a use case for animation. While people like demoing how responsive designs respond to resizing, the point is that it is a good design at any particular static size.

Vlad: Variation fonts would likely have named instances.

<dbaron> (that's a response to glazou's comment)

<gsnedders> dbaron: and indeed things frequently get confusing when resizing due to movement of content

Vlad: In the scale, there will be certain points in the axis with a name assigned. You say "bold", the browser may not know the variation scale, but there will be a value known as "bold".

<dbaron> certainly may be other use cases, though

Vlad: But I'm not sure there's a mechanism to query a font for that.

myles: Axis discovery is related but somewhat distinct.
... Font feaetures are similar. And there's no mechanism for discovering those features.

<glazou> dbaron: imagine a emoji font where the smile/grin mouth is set by a font axis ; transitioning that would be awesome

myles: It might be possible to go down that road. I'd like to consider them as related but separate topics.

Vlad: I think variation is a little bit trickier.

behdad: The CSS shorthand routes into the font, and there is @font-face for the name instances, same as for @font-feature-settings.

Vlad: Question: related to responsive typography.
... You ahve a font with width variation, and idea is that when you resize the window or column, you apply a smooth width variation.
... Reflows can be very objectionable when text jumps.

<eae> I think he meant the font provider's CSS generator generating @font-face rules rather than the CSS shorthand parser.

Vlad: But what I didn't see in the spec is the mechanism that connects window information back to font variations.

ChrisL: I'd like to reiterate that animations/transition will be great for this.
... ONe thing not mentioned yet is that system fonts will ahve variations.
... So you'll set a fallback font and set its width/weight/etc, so less of a "jump" when your downloaded font loads in.

astearns: Doesn't that depend on the system fonts being quite similar?

ChrisL: Right, ti's the same problem as having Arial vs Helvetica.

astearns: Right, wondering if we need a way of seting up system fonts *per system*, so it's known to match.

myles: There's a GH issue for that.

ChrisL: There's a detailed proposal in the GH for that.
... This is just gonna change things so much.

<myles> eae: let me see

<jdaggett> https://github.com/w3c/csswg-drafts/issues/498

ChrisL: Instead of downloading 4 fonts and wishing there wer emore weights, you jsut do one and get 7 weights, etc.
... What we really want is to get approval from the group to move into Fonts 4.

astearns: Proposed resolution is to take what's written and move into CSS4 Fonts.

dbaron: Are there other substantial features in Fonts 4?

fantasai: Yes.

dbaron: How likely is is to progress relative to those?

ChrisL: Similar. Chromatic fonts there right now. Gonna run on similar timescale.

fantasai: Small set of simple features that have been added, then palette colors and whatnot.

astearns: And when we find that things progress slower, we'll move them around.

jdaggett: I think the underlying tech here hasn't been implemented on platforms yet.
... I think it's complex enough that issues will come up in the spec itself. Relative to other Fonts 4 features, this...

<myles> eae: https://github.com/w3c/csswg-drafts/issues/126

ChrisL: I agree it hasn't quite shipped, but at the announcement last week there were OS companies and font foundries saying they were adding it. Adobe added a rasterizer to FreeType.
... Much more ready than one would expect.

behdad: OS 10.12 shipped San Francisco as a variation font.

astearns: Things will shift, but do you think we should keep it out of Fonts 4?

jdaggett: My concern is that the APIs for supporting them ahven't been laid out completely.
... I think there are issues of how impls will be able to support this.
... I think it's fine for Fonts 4, but there could be, it could take longer than other features.

ChrisL: We have things where we want to freeze a particular spec where a delta is hard to read, and this is effectively that.
... Like, Fonts 3 needs to have been shipped yesterday.
... ONly definition of @font-face, and way past due.

astearns: I don't think it slows down Fonts 4?

ChrisL: But then you need to track changes.

myles: I'm willing to do that.

<fantasai> TabAtkins: Given this is a brand new feature under heavy changes, this seems like a great thing to work out in the WICG

<fantasai> TabAtkins: Prefer to move new ideas into WICG instead of putting them into a spc with ther features

<fantasai> TabAtkins: Want to talk it out on a lower-volumen list

<fantasai> astearns: Lower volumen list, but also a different list tha needs for ppl to subscribe to

<fantasai> ChrisL: What's the benefit here? We have the font ppl here, and CSS ppl here.

<fantasai> TabAtkins: Didn't want to mix up this feature with unrelated features like font palettes

<fantasai> TabAtkins: The point here is to have smaller groups that are more focused

<fantasai> leaverou: If everyone in the CSSWG joins WICG group, how is that smaller?

<jdaggett> I think this feature will affect some fairly fundatmental CSS features

<behdad> Side comment I forgot to mention: variation fonts have significant size saving for webfonts.

<fantasai> TabAtkins: Not everybody would join

<fantasai> Rossen: WICG is a separate topic

<jdaggett> font properties and @font-face rule

<fantasai> Rossen: Discussiong FOnts 4

<ChrisL> I mentioned the size savings earlier

<fantasai> Bert: I think good idea to put this into the draft

<Zakim> Bert, you wanted to ask if we should then make css-font-4 a FPWD.

<fantasai> Bert: But should make the draft official draft fo the WG

<fantasai> fantasai: I thought we had an outstanding resolution to publish

<fantasai> Vlad: I'm not concerned about ppl in this room, concerned about ppl who ar not in this room but are subscribed to the list.

<jdaggett> list? www-style?

<fantasai> Vlad: I would be concerned that people would not be following

<fantasai> Vlad: Concerned about independent font dsigners, who have a lot of work on their main jo oto do

<jdaggett> agree with vlad

<fantasai> Vlad: We have a lot of good participation on www-style from John Hudson, etc.

<fantasai> astearns: We would notify the list, obviously.

<jdaggett> how to include type designers is critical

<ChrisL> agree with vlad too

fantasai: Irt whether Fonts 4 or WICG, something we can do for shorter-term features is just... rename the current draft to Fonts 5, merge in the small features to the current Fonts 3, make that Fonts 4.
... Then we can just take like min-font-size, and system-ui font. They can go to CR as soon as editting is done.

ChrisL: I feel that one of the benefits of ahving WOFF going, is having type experts like John Hudson contribute to this.
... I don't want to dilute things by moving off to another group.

<jdaggett> hmm, aren’t we using github issues for discussions?!?

<Rossen> jdaggett, yes we are

<fantasai> TabAtkins: If they want to follow all of CSS--fonts plus non-fonts-- then they should be okay to follow fonts plus non-fonts in split groups

<jdaggett> so what’s the fire hose…

<fantasai> astearns: It's not a new module. It's just adding stuff ot a module we already have, and it's pretty well integrated with the text we have in FOnts L3

<jdaggett> ah, ok

<fantasai> astearns: So keeping it in our module system seems easier for the eidotrs

<fantasai> astearns: And everyone working on it has expressed an interest in keeping it in github

<fantasai> astearns: Tab, you're free to object, but in this case I think we should keep it in house

<fantasai> astearns: As a different argument, we were talking about koji's propsoal for ste-psizing, and takng that to incubation

<fantasai> astearns: I think it would be appropriate there.

<fantasai> astearns: I would like to decide now to keep it in the group, will you object?

<fantasai> TabAtkins: I object

<fantasai> ChrisL: Then we have to recharter

<fantasai> ChrisL: The charter says, that for each new deliverable we have to have consensus to add it. If there is a sustained objection, we're required to recharter.

<fantasai> TabAtkins: I'm not saying it doesn't go into fonts, I'm saying it goes to WICG first, and then we put it into fonts

<fantasai> TabAtkins: I'm not objecting to a new deliverable.

<tantek> I'm going to point to this related proposed break out session for tomorrow: https://www.w3.org/wiki/TPAC2016/SessionIdeas#Incubation_as_the_New_Normal

<fantasai> Florian: Current practice of the WG hasn't been to use the WICG

<fantasai> Florian: If we want to...

<fantasai> Florian: If we want to do this, we should have a discussion about this topic, not about Fonts specifically.

<leaverou> +100 to Florian

<fantasai> Florian: Until we have that discussion, then we should follow the usual process that we have in this group

<fantasai> Florian: If we need to pause everything and have that discussion now, fine.

<fantasai> TabAtkins: I don't think we should take up time during the F2F for this discussion.

<fantasai> astearns: We have no more time to this. We had a proposal. We had an objection. We are going to do nothing.

<fantasai> myles: Nobody likes this. Nobody in the whole world thinks this is a good idea.

<fantasai> leaverou: So Google is stalling progress until we change the process to be the way Google wants

<fantasai> Florian: And moving to a process where consensus doesn't apply

<fantasai> Vlad: So we have a procedural objection, but no substantive objection.

RESOLUTION: We will work on font variations.

<dbaron> I believe Vlad (or someone else) also said something like "there's consensus to work on it, but not consensus on where to work on it"

<jdaggett> who is minuting?

<dbaron> what's the URL of this spec?

jihye: [missed some intro]
... There are two new properties - offset-position and offset-anchor.
... offset-position defines where the path starts in the container

<ericwilligers> https://drafts.fxtf.org/motion-1/

<dbaron> oh, it's https://drafts.fxtf.org/motion-1/

jihye: offset-anchor defines where on the element starts on the path.

<astearns> (shane draws)

jihye: There's a problem when we put these into the shorthand.

<jihye> https://drafts.fxtf.org/motion-1/#offset-shorthand

jihye: The shorthand is now ambiguous.

<shane> https://usercontent.irccloud-cdn.com/file/NnZEDgV4/IMG_20160920_114516.jpg

Zakim: lolwut

zakim: ack

ack https://drafts.fxtf.org/motion-1/#offset-short

jihye: Both offset-rotation and offset-path have an <angle>, and offset-position and offset-anchor have <position>.
... So they're ambiguous.
... Shane proposed to use a ray() function in offset-path.

ray(<angle> && <size>? && contain? )

jihye: With this, it cancels the <angle> ambiguity.

<fantasai> ACTION jihye change offset shorthand to use || instead of &&

<trackbot> Created ACTION-793 - Change offset shorthand to use || instead of && [on Jihye Hong - due 2016-09-27].

jihye: Next is <position> ambiguity.

<dbaron> offset-distance also has conflicts with the position values, no?

jihye: ONe solution is getting rid of offset-position/anchor in the shorthand (it resets, but can't be set).
... Another is use to slashes to separate.

<fantasai> TabAtkins: 1st option is drop -position and -anchor from shorthand, so get reset but can't get set

<fantasai> TabAtkins: Other option is to use slashes

fantasai: There's another issue - the offset property should be resetting top/left/bottom/right.

TabAtkins: This is a name collisions, they're not actually interacting.

shane: offset-path feeds into Transforms.

fantasai: Okay, we might need to rethink the naming of one or both.

shane: We had shipped when it was named motion-path.

<dbaron> https://drafts.csswg.org/css-logical-props/#propdef-offset-block-start is a bit of a naming collision

shane: We just put thru a rename, as early as we thought we could.
... We'd be increasingly concerned about changes to the names.

TabAtkins: While the logical t/r/b/l isn't implemented by anyone.

<fantasai> TabAtkins: I'm in favor of just taking out of the shorthand; most of the time defualts work just fine

shane: I got some impl feedback from Eric Willigers, chrome impl.
... He did some demos. He said most of them, he has to manipulate top/left (because we don't have offset-position implemented yet).
... So that suggests offset-position is frequently used.
... And it suggests the ordering - offset-position first, then offset-anchor?

TabAtkins: Makes sense to me.

astearns: If we're introducing a slash for position, might as well do it for anchor.

TabAtkins: Oh yeah, once we've paid the cost, we should go all the way.

astearns: Any objections?

<tantek> is there a GH issue on this? with history?

dbaron: This is getting to be a complicated microsyntax.

<tantek> I'm having trouble following :/

<tantek> I'd like to see a proposal in a GH issue if possible

<ericwilligers> https://github.com/w3c/fxtf-drafts/issues/24

<tantek> thanks ericwilligers

offset: <offset-path> || <offset-rotation> || <offset-distance> [ / <offset-position> [ / <offset-anchor> ]? ]?
... [ <offset-path> || <offset-rotation> || <offset-distance> ] [ / <offset-position> [ / <offset-anchor> ]? ]?

<shane> tantek: also https://github.com/w3c/fxtf-drafts/issues/42

fantasai: What if you just want to do an offset-position?

TabAtkins: That's the same as just doing a translate.

fantasai: Hmm, that doesn't match my recollection.

<dbaron> shans, you haven't shipped the shorthand, have you?

<tantek> I'm a little concerned about a mixture of spaces and '/'s for separation

<tantek> sounds confusing, like the 'font' shorthand (which I still can't remember reliably enough to use :p)

<jihye> https://drafts.csswg.org/css-fonts-3/#propdef-font

<dbaron> I'm not convinced the syntax that Tab wrote above is even unambiguous

<fantasai> fantasai: From what I recall discussing, if everything else was set to its initial value, offset-position would be setting the absolute position of the box with respect to the containing block.

<fantasai> fantasai: This makes it a useful positioning system, independent of the other values

<fantasai> fantasai: And so the shorthand should be able to accept only a position, to allow for it to be used as such.

<fantasai> TabAtkins: You can't just use translate for that

<dbaron> since offset-path has bits that conflict with the other two (or at least one of them)

<fantasai> fantasai: translate can't reference the size and position of the containing block

<fantasai> fantasai: It's not the same thing at all.

fantasai: We integrated a proposal that could do many things.
... We were expecting to use certain parts together.
... It would be less common that using just path, etc.
... So what we need for the shorthand is look at what people actually want to specify, and make those easy.
... So setting just position looks common.
... And setting a path with distance + rotation.

shane: That will usually require a position, too.
... If the path is an SVG path, you can get similar effect by using a M command. But the other path types can't do that.
... And using the keywords for positioning, you can't be relative to the containing block.

<jihye> https://drafts.fxtf.org/motion-1/#propdef-offset-path

fantasai: So we can use positioning information rather than slashes everywhere.
... So like start with offset-position first. Then path/rotation. Then distance.
... Then after you can have the anchor.

<jihye> offset-path changes to => <url> | ray(<angle> <size>? && contain?) | [ <basic-shape> | <path()> ] ||<geometry-box> | none

shane: You still have anchor, so we can leave it out or use a slash.

fantasai: I guess you'd put a slash before anchor.

shane: jihye could speak to common polar positioning uses.

fantasai: location, direction, distance along the ray.

shane: jihye, how common is it to set anchor in polar positioning cases?

jihye: I think center is the common thing.
... Default value for anchor is "auto". When I described some use-cases, I found center is more useful than "auto".

fantasai: WE made it auto so the position would function the same way as for backgrounds.

jihye: That's useful when path is specified with angle; but when you're using the other value types, like circle(), you have to adjust every element which is on the circle path.

astearns: So this sounds like we do still need anchor with a slash.
... So it sounds like we can put position first, use ray(), then the rest, then / with anchor.

TabAtkins: I might say leave anchor out entirely - it's like transform-origin, and that's a separate property.

<fantasai> fantasai: Yes, but it seems that switching between auto and center would be reasonably common

TabAtkins: That suggests that "auto" can just do the bg-pos thing when path is "none", and otherwise be center. Then you rarely need to touch it at all.

<dbaron> Am I understanding correctly that 'offset-position: auto' is like relative positioning and 'offset-position: <position>' is like absolute positioning?

<fantasai> yes, exactly dbaron

<dbaron> I think that section of the spec could be a bit clearer, then.

shane: Almost all examples use offset-anchor:center. It's by far the most common thing to do when you position on a path, sounds most common when it's polar as well.
... It's okay to make this work okay for positioning as well, but all the rest requires center as the default anchor.

fantasai: So "center" as the initial value? That's fine.

<dbaron> I still don't understand what offset-anchor: auto combined with offset-position: auto does

fantasai: I think switching it when path is none vs other is confusing.
... We can do something like have it default to bg-like when you don't have a path in the shorthand, center otherwise. But not base it on the actual value of path.

TabAtkins: I think we generally dislike magic in the shorthands; we've used it before, but usually want to handle it at the value level.

astearns: Running out of time. Let's fix up resolutions.

RESOLUTION: Switch the polar-positioning part of offset-path to be a ray() function.

<offset-position> ? [ <offset-path> [ <offset-rotation> || <offset-distance> ] [ / <offset-anchor> ]? ]

RESOLUTION: Position before path before distance and anchor

<dbaron> I filed https://github.com/w3c/fxtf-drafts/issues/45 and https://github.com/w3c/fxtf-drafts/issues/46 on my issues.

<frremy> ScriberNick: frremy

<ChrisL> cwilsohas joined #css

CSS Scroll Snaps disposition of comments

<frremy> fantasai: we have one open issue, which is scroll padding

<frremy> Florian and fantasai: deciding who to present

<frremy> Rossen: Matt wanted to be able to join for this issue

<fantasai> https://github.com/w3c/csswg-drafts/issues/156

<frremy> Rossen: let's change the order of topics

<frremy> fantasai: another issue is the event model

<frremy> fantasai: the proposal is to defer this to the next level

<frremy> Rossen: any objection?

<frremy> TabAtkins: I would rather have scrollsnaps as soon as possible

<frremy> Rossen: since there are no objection, let's call this resolved

RESOLUTION: Defer the event model to the next level

<frremy> Florian: If you try to snap to something beyond scrolling reach, what happens

<frremy> fantasai: the snap position is changed so that it becomes in range

<frremy> Florian: my understanding is that is says precisely how you snap

<frremy> Florian: but now whether you should do it

<frremy> Florian: another part seems to indicate you don't

<frremy> Florian: because the "corridor" is not defined

<frremy> fantasai: since you *shift* them inside range, they are

<frremy> Florian: ok, this didnt used to be written this way when I filed the issue

<frremy> Florian: I am convinced by the explaination now

<frremy> Florian: I'll review again and will return if I find anything else, but its ok for now

Media Queries

<frremy> Florian: 4 issues

<Florian> https://drafts.csswg.org/mediaqueries/#issue-d9e3b586

<frremy> Florian: Issue 3 needs to be discussed

<frremy> Rossen: the color one?

<frremy> Florian: yes

<frremy> Florian: should we have a "shitty" color one, when you support colors, but poorly

<frremy> dbaron: we already have grayscale btw

<frremy> Chris: what would you do in that case?

<frremy> dbaron: there is one for srgb

<frremy> ChrisL: still not sure what the author could do with it

<frremy> Florian: I am not arguing in favor, just trying to make sure we considered

<frremy> ChrisL: we want to go up, not down

<frremy> LeaVerou: Devices with small gamuts typically display colors as less saturated

<frremy> LeaVerou: so you might want to adapt

<frremy> dbaron: there are more than just "non-srgb" and "close-to-srgb"

<frremy> LeaVerou: how about a percentage of coverage?

<frremy> Florian: any measure won't be expressive enough

<frremy> LeaVerou: it's not perfect but looks sufficient

<frremy> Florian: how about one point "less srgb but still better than usual"?

<frremy> fantasai: we should have a note

<frremy> fantasai: explaining what matches what

<fantasai> explaining what it means to match not sRGB

<frremy> dean: the issue is also browsers that just do not support the media query

<fantasai> which is implied by the spec, but not clear to readers

<frremy> dean: if you try to detect "not-srgb"

<frremy> Florian: it is a general issue

<frremy> dean: but not makes it worse

<frremy> Rossen: proposed resolution is then to resolve as wont fix

<frremy> Rossen: no objection?

RESOLUTION: do not add a less-than-srgb mq

<frremy> Florian: other issue: script mq

<frremy> Florian: how about engines that run scripts, but only until some point (like printed)

<frremy> Florian: if the MQ doesn't tell you that it is supported, the MQ isn't very useful to depend on

<frremy> Florian: maybe a value would be great

<tantek> is there a link for the proposal / GH issue?

<frremy> Florian: but defining the theshold is tricky

<frremy> Florian: but if we define a threshold might force user agents to lie about it

<frremy> Florian: so we should probably keep it fuzzy

<frremy> Florian: we discussed but we didn't resolve on that last time

<frremy> tantek: any pointer to the old discussion?

<frremy> Florian: nope, sorry

<gregwhitworth> https://drafts.csswg.org/mediaqueries/#scripting

<frremy> Florian: but this summary is about as good as it got

<Florian> https://drafts.csswg.org/mediaqueries/#issue-51d591c9

<frremy> Rossen: your preference?

<frremy> Florian: not changing the spec, keep fuzzy

<frremy> Rossen: fantasai, since it is your issue, what is your call?

<frremy> fantasai: I am fine with a fuzzy boundary, but I want at least one certainty value people can trust

<frremy> Florian: a "onload" threshold could be an issue if there is a timeout

<frremy> Florian: so I don't think it would help anyone

<frremy> Rossen: but would it solve the issue?

<frremy> fantasai: I don't know, you guys know

<frremy> fantasai: but authors want at least some way of knowing that

<frremy> fantasai: if we define a baseline, at least authors can depend on that baseline

<frremy> fantasai: otherwise, people will rely on undocumented heuristics and we won't get interop

<Zakim> tantek, you wanted to request this issue be captured in GH and iterated there and to also ask how many / if any implementations, and suggest at-risk

<frremy> tantek: please capture this in github

<fantasai> fantasai: I know almost no JS, but if I write a script, I want to know if it will be guaranteed to run, interoperably

<frremy> tankek: second question, did anyone prototype this?

<frremy> Florian: not any implementation

<frremy> Florian: that I know of

<frremy> tantek: then lets assume none

<bkardell_> Is it actually useful to detect the opera mini case? because it is an arbitrary cutoff

<frremy> tantek: then let's mark as at-risk

<frremy> Florian: fine by me

<tantek> https://drafts.csswg.org/mediaqueries/#scripting

<tantek> the summary artificially constrains what the feature implies

<frremy> tantek: (pasting what he just read)

<frremy> tantek: that description contraints the use case

<frremy> tantek: it could be used to do more things

<gsnedders> bkardell_: Yes. And it's horribly awkward. See all usage of :root.no-js etc.

<frremy> tantek: so it's misleading

<frremy> Florian: i am fine doing this editorial change

<frremy> dbaron: if you want to figure it out, you need use cases where css needs to be different based on javascript running

<frremy> dbaron: why not just have the script do something

<dino> 100% agree with dbaron

<frremy> dbaron: like removing classes that will trigger the behavior

<frremy> dbaron: assume it won't run

<frremy> dbaron: then cancel the effect

<frremy> TabAtkins: it's cheaper on MQ

<frremy> TabAtkins: so perf might be better

<frremy> tantek: what is this nojs class nonsense, you can just flip the stylesheet to enabled

<frremy> LeaVerou: reality is, all big websites use a nojs class that they remove via JS. They do not toggle stylesheets, because this is easier for maintenance.

<frremy> TabAtkins: also friendlier to bundling

<frremy> Florian: can we just agree on a "something will run, at least"?

<dbaron> that said, I think the main use case is really just "is script enabled"?

<frremy> dino: lets set the print baseline

<frremy> dino: when the rendering finalizes, scripts stop running

<frremy> tantek: ok, then lets call that value "onload"

<frremy> gsnedders: has Opera said if they're going to implement this middle value? has anyone?

<frremy> simonp: Opera Mini is still using Presto and we're not going to implement any new features there

<frremy> gsnedders: so is it theoritical only?

<frremy> LeaVerou: google crawler does run some scripts

<frremy> eliott: google crawlers won't report that

<frremy> eliott: we just act like if we were really loading the page, right?

<frremy> Florian: then we can make the entire mq as at-risk

<frremy> tantek: let's punt the new value to the next level

<frremy> Rossen: would you oppose that?

<frremy> Florian: I don't oppose either way

<frremy> tantek: lack of prototype is a strong signal to punt it

<frremy> Rossen: any objection?

RESOLUTION: the new value will be punted to the next level

<frremy> Rossen: what about the entire MQ?

<frremy> Florian: we should keep, as at-risk

<frremy> Florian: print is a valid use case

<frremy> Rossen: Proposal is to mark it as risk, then. Objections?

<dbaron> ?: what to do with intermediate value?

<dbaron> dbaron: I think it should probably match what people do with nojs classes, which means those implementations should return true

RESOLUTION: keep the script-detecting mq, but mark as at-risk in current level

<frremy> Florian: we now need to make a disposition of comments

<frremy> Florian: but we went through all the known open issues

<frremy> Rossen: ok, anything else on the topic?

<frremy> Florian: no, I'll ask for CR when we are done with these

<frremy> (various +1)

<frremy> tantek: ask for a review after you made those changes, please

<frremy> Florian: ok

RESOLUTION: publish that as a working draft

<fantasai> https://drafts.csswg.org/css-grid/issues-wd-20160519

<frremy> Rossen: there was a grid issue to be discussed?

Grid

<frremy> fantasai: first one is the baseline issue

<frremy> fantasai: we decided to not to block-axis baselines

<frremy> fantasai: but original poster isn't very happy

<frremy> fantasai: proposal is: given lack of review, we should drop the feature for now, but maybe consider for later addition

<frremy> fantasai: for a while, it is not expected you can make it work anywhere anywhere

<frremy> Rossen: anyone objecting to keep the current resolution not to work on block baselines

<tomalec> Could you share the link for webex?

<frremy> jet: I am just wanting to check that is is what we are going to ship

<frremy> fantasai: I can also make it undefined

<frremy> fantasai: the point is not to make it prevent the spec to go to CR

<frremy> jet: wait wait wait

<frremy> jet: let's see if we matches first

<frremy> fantasai: can I get a response today?

<frremy> jet: i hope so

<jet> fantasai: bug 1151204 btw

<frremy> tantek: would it be possible we match others?

<frremy> Rossen: not us, we don't have vertical baselines at all

<frremy> dbaron: why would an author want that?

<frremy> dbaron: they can make the whole grid vertical

<frremy> fantasai: mixed mode

<frremy> dbaron: seems like the case you describe should be described in the other way, and you don't have the problem

<frremy> fantasai: yeah, it's just a convenience

<frremy> Rossen: just a reminder, we want to keep an existing resolution

<fantasai> Discussion was about block-axis baseline alignment, for example by having a column of 5 author bios which are horizontal-tb grids with vertically-written author names in the first column of each bio item

<frremy> Rossen: how about we resolve again, and you reopen if you need

<frremy> jet: looks fine to me

<fantasai> and then you want to align along the block axis the vertical bio names within the column of the parent grid

<frremy> Rossen: anyone else want to object?

<fantasai> dbaron was saying that you could just make the items vertical and make the rest of the content inside them horizontal

<fantasai> and that would sovle the problem

RESOLUTION: block-axis baselines are not supported (confirmed!)

<fantasai> and agred that we should not have block-axis baselines as a feature

<frremy> Rossen: next issue?

<dbaron> but my point was that if you have a grid item where the thing you want to align is vertical, then structurally that grid item is vertical, with some horizontal stuff inside -- and then you don't need block-axis baselines

<gregwhitworth> ScriberNick: gregwhitworth

<gregwhitworth> fantasai: the only other issue is % gaps

<gregwhitworth> .. we resolved to treat them as empty tracks

<gregwhitworth> ... mats disagrees as he thinks they should back resolve the %s

<gregwhitworth> fantasai: I think that Ilgalia has implemented intrinsic % to auto and back computing other ones

<gregwhitworth> Rossen: wait they're not semmetric

<gregwhitworth> fantasai: no, I don't think so

<gregwhitworth> fantasai: this deals with how to deal with % in CSS in generals

<gregwhitworth> fantasai: let's say you have a float and a block inside that with %s and it will overflow

<gregwhitworth> ... we can't change that because of back compat

<fantasai> https://github.com/w3c/csswg-drafts/issues/347

<gregwhitworth> dbaron: we do back tracking for margin/paddings when inside of a shrink wrapped container

<gregwhitworth> fantasai: if we go with the order of importance then we show go with what Gecko does

<gregwhitworth> fantasai: that's what author's want

<gregwhitworth> fantasai: where we don't have a back compat issue do we want to fix them or fallback to auto

<gregwhitworth> Rossen: we've discussed this in the past

<gregwhitworth> Rossen: our experience in the area is that this is very fragile especially when %s go over 100

<gregwhitworth> Rossen: so trying to backcompute the margins becomes really crazy

<leaverou> ScribeNick: gregwhitworth

Florian: what does it mean if it is over 100%

dbaron: I think the answer there is to only deal with it in in maxcontent widths and not mincontent widths
... that way you'll be ok

Rossen: at the very least min and max are supposed to be treated differently

fantasai: I think I have a bunch of related questions, the key one here is gaps
... we figured it'd be nice if the gaps are handled similar to tracks, and that's what Mats has been arguing for
... that's one option
... the other option is to make them compute the same and fallback to auto
... make them compute the same but have them both back compute the %s

Rossen: our opinion is #2
... behave consistently and fallback to auto
... consistency over inconsistency
... and implementation simplicity over complex % back tracking

Florian: as in it's hard for browsers to get them right?

Rossen: yes

especially when you nest them

dbaron: I'm not sure what nesting them has to do with it
... you go level by level resolving the % against that of the intrinsic width

fantasai: I don't have an opinion on this
... it would be good to hear from the Blink folks

ojan: hi

dbaron: it would help if someone explained the issue
... draws a diagram on the board

<fantasai> <div><img src="100x100.png" style="margin-left: 20%"</div>

<fantasai> dbaron: We make the intrinsic size 125px

<fantasai> dbaron: and the whole thing fits

<fantasai> dbaron: Gecko does this for margins and padding in this case, and other impls don't

<fantasai> dbaron: What we're talking about is doing this sort of thing for grid stuff

dbaron: so the alternative here, is if you ignore the % you make the intrinsic width 100px
... you end up with a margin that is 25px and it overflows by 25px

<fantasai> dbaron: If you ignore the percentage, you make the div 100px, and the margin is 20px, and it overflows

<fantasai> Florian: Which doesn't sound like what an author would want

fantasai: I think there are actually two things happening here
... one of them is: if you have a child box of an intrinsicly sized element for grid we would have a track that is in a shrink wrapped grid container
... we can say that % depends on an indefinite size and treat it as auto and we wont' have the overflow problem

dbaron: I don't think that's quite true
... one of the thing this gets you, if you have the image inside of the grid track and says 20% and the image is 100px

and the track needs to be 20% of the parent then this will cause overflow

dbaron: tables do this, nothing overflows

TabAtkins: let's keep that in tables

dbaron: you might have overflow but it depends on the sizing the of the tracks
... if you end up with a 300px grid and then you say, this piece is 20%

floar

Florian: that's not what fantasai is saying, it's ignore

dbaron: for everything or just intrinsic sized items

fantasai: for everything

dbaron: that's ok too

fantasai: I don't want overflow

Rossen: I want to timebox this discussion
... there are two things we need to decide, do we want consistency with gaps and tracks

^ in regards to resolving %s

dbaron: so treating them as a 0 even though you asked for a % there will be nothing there

ojan: that seems fine to me

Rossen: what does

ojan: if you put an % sized gap on an intrinsic sized track that seems fine to 0 them out

fantasai: so mats Palmgren said we should back compute on gaps, not tracks because it's more complex
... so we end up with 3 options

Rossen: so in other words, two of them would be consistent and one of them would not
... would any one object to keeping them consistent?
... let's call it resolved

resolution resolved

Rossen: now on to the other part, if they're consistent are we back computing %s or not?

RESOLUTION: percentage gaps and percentage tracks use same resolution method

Rossen: Does anyone object to not backcomputing %s on tracks?

dbaron: I would like to hear actual author feedback

Rossen: are there any objections

jensimmons: I don't know what you're discussing?

gsnedders: I think asking for author point of view makes a bit of sense, but, I think back track has to be there or it does not make sense

dbaron: what are the use cases for intrinsicly sized grids
... I feel like it's mainly used for top down not bottom up

jensimmons: it's pretty big deal honestly

<rego> a simple example of a percentage gap and how it actually works in both FF and Blink/WK implementations: https://github.com/w3c/csswg-drafts/issues/345#issuecomment-240333816

jensimmons: people will expect the math to add up

<rego> tracks work exactly the same right now, so using: grid: 100px 10% 100px / 200px 10% 200px; behaves consistently

fantasai: let's say you have a grid, it's floated, it's intrinsicly sized

astearns: what if we wait to get more author feedback rather than just getting feedback from the author in the room

ojan: I would like to figure out if we can do what Gecko does

dbaron: the way table column width assignment is very similar to this

ojan: there are two things we can do offline: 1 get author feedback and 2 get desire to implement this from UAs

fantasai: we will keep the resolution and then spec out both and fix this in three months in Seattle
... mark it undefined so we can go to CR

<gsnedders> I'll also note after what was minuted for what I said, Rossen asked if I'd object, and I said "yes" (somewhat apprehensively)

RESOLUTION: %s in intrinsicly sized grids tracks and gaps will either get back computed or not

fantasai: we would like a transition to CR

RESOLUTION: Grid to CR

<ChrisL> (I was just asking fantasai about DoC etc and wide review)

Incubation in the CSSWG

Rossen: since we have a few people from Google in the room
... as you know we recently re-chartered

<ChrisL> https://www.w3.org/Style/2016/css-2016.html

Rossen: the current charter has we are allowing and encouraging incubation of new ideas in the WICG but not requiring it

<astearns> relevant text from the charter: "The CSS WG may incubate speculative new work in the WICG, and may adopt promising CSS work developed in WICG, provided that RF patent commitments are in place for such work."

Rossen: there was a topic today that was incubated elsewhere with a relatively complete spec which was desired to be adopted under fonts L4. There was an objection by TabAtkins
... then a further statement that any new work should go into WICG

TabAtkins: I don't think the spec is defined

8 minutes total time

<Zakim> ChrisL, you wanted to say this is a pretty good spec and of course has issues like all our specs

ChrisL: I will say it's a pretty good spec, I've reviewed it, I've seen far worse specs that have gone to FPWD

dino: the topic is incubation not this particular spec

Rossen: I would like to hear a more formal policy behind this

slightlyoff: as many of you know, we work across many standards organizations. W3C is only one of them, I ended up with the role of ensuring the health of those groups was good
... and it wasn't and most of it looked like design by committee
... the proposals need a lot of momentum and community backing
... this is a very large investment
... this is the wrong place for design, my teams come prepared for resolving issues, not for designs

<ChrisL> I would like to see it minuted that slightlyoff said that this spec *did* have a lot of momentum behind it

slightlyoff: starting with the CLA policy that the CG has in place, is perfect for these proposals
... we've done quite a few things for this already
... intersectionObserver, web payments, resizeObserver
... this is to get the i's dotted and t's crossed
... but it's not just us, Microsoft has been there as well
... allow for iteration where you can bring well formed proposals that can become standards
... I did recommend a blanket proposal for that inside of Blink, thus TabAtkins request

<Zakim> tantek, you wanted to note, incubation good, CSSWG should at least adopt an incubation methodology, whether or not we use WICG per se

tantek: I like the WICG, I think this working group has tended to moving in that direction but haven't formally adopted this process
... it would front load some of those questions that we ask at CR time, it should help us move more efficiently
... it keeps from there being specs that live in limbo for a long period of time
... WICG is one way of doing that, but there are many options
... in general I'm in strong support of adopting an incubation first model

<Zakim> cwilso, you wanted to add more detail on scoping, baking, and the point of incubation.

ChrisL: I'm actually co-char of the WICG and partner in the incubation first, Alex mentioned Microsoft but it actually started at Microsoft from Adrian Batemen
... it enables us to embrace graceful failure

<fantasai> I don't thnk the CSSWG does that... our failures just end up as abandond draffts that we then put big red obsoletion notices. Granted, said notices are not very graceful.

cwilso: we are not saying the WICG is not the only group, it speeds up the need to create a new group, etc

<fantasai> But I don't think styling of the specs was the conern here

cwilso: if you feel the problem needs to be solved and you've scoped it down to what/who needs to be involved and you know what the solution looks like
... that's really rare, but if it is then you don't necessarily need it to incubate

Florian_: during the short charter review I believe you asked for mandatory
... I'm not opposed to incubation, but I'm against to a mandatory
... if Google wants to prove that incubation leads to better results, then do so

<fantasai> +1

Florian_: but the way this was handled was very unpleasant

frremy: I had a very same point to Florian_ I think it helps the community, it's a very good workflow
... they are an external partner that has a sound plan as they already have it designed for Windows/Mac that they'll point to CSS
... in this specific case I don't think it's necessary
... they came to this group to ask us to work with them, and then asked them to go to WICG
... it seems like it's sending the wrong message
... exploring is for the WICG and I think the CSSWG is for refinement

astearns: I'm all in favor in moving things to the WICG when we can, so they can be done in a small tight group
... instead of setting up a subgroup or a TF, I prefer WICG
... for this particular one it feels like a process speed bump, because things are passed the incubation phase, or relatively passed the incubation phase

<Zakim> cwilso, you wanted to ask a question.

<frremy> (seems fair to me)

cwilso: the question I would suggest to the wg is: it's not to be a process speedbump but the new normal is that everything should start in incubation. The wg may want to define what should be in the WICG

<frremy> (reacting to what cwilso just said)

fantasai: Alan gave an example of step sizing

<astearns> I definitely agree we should have agreed-upon guidelines, so we don't rehash this every time new work appears

Florian: but this wasn't the case, it fits in this group

cwilso: that is not the bar, that you may need a new working group

hober: who do you mean by we?

cwilso: um, the WICG. Started with Microsoft, myself, Alex, Google, etc
... the bar for incubation is much higher than starting a new working group for new features, it was to get a decent proposal to save the groups time

dbaron: I think one of the problems incubation solves, the way large groups discuss is not effective
... we have discussions about technical stuff and make decisions around stuff we at times don't even understand
... I think it's best to move the problem solving to the smaller groups so they have the right people that can make the right decisions
... now there is the flip side, that the group chosen to solve that problem are the wrong set of people
... so we can't just assume that a spec that was done in incubation may need to be completely redone

<fantasai> +1

<astearns> wide review needs to happen in incubation as much or more than it does in a WG

dbaron: I would like to ensure that incubation feedback is done earlier enough and high level enough that we aren't stuck with something that was effectively done by one company

<tantek> a?

dino: would round display of something that fits your narrative

dbaron: yes, it did get completely done
... have the high level overview but not argue over syntax of each prop

fantasai: one of the points I wanted to hammer on is it encourages people to go off in a corner and not get a lot of feedback
... one of the benefits of this room is that you get a broad set of ideas

<Rossen> iank_, sorry, I declared the queue closed 8 mins ago

<dbaron> one other sentence: the set of people in this group isn't actually the right set of constituents that need to be talked to

fantasai: there's a tension in standards around parallelizing and fragmentation; one of the advantages of discussing things in the entire WG is getting the broad expertise of a) people with different perspecives and b) people who have experience with many differnet parts of the technology and know how to integrate it and keep it self-consistent

<cwilso> I would note that discussing something in WICG doesn't mean you can't be in the WG, nor that you will not discuss said incubation inside the WG or with other WG members.

fantasai: I think pushing everything into incubation will have another set of problem

<astearns> +1 to cwilso's point

fantasai: and to some extent we've been doing this with individual threads and side meetings

<tantek> cwilso, indeed, I think CSS incubation could occur in the CSS WG itself, as long as the CSS WG formally adopts incubation as part of our work flow

<dino> ----- 2 Minute Warning ----- (isn't this a forced time out?)

SteveZ: I actually agree with one point that Google made, we ought to have criteria that decides what does/doesn't go into the CSSWG

<cwilso> tantek: I'm not sure I agree, but depends on setup that is beyond the next 30 seconds of discussion. :)

SteveZ: we've come up with a bunch of criterion for other things, we should do that for this. We should spend some time on this
... I think it has to do with a number of the things that cwilso mentioned, like what the tech looks like

<tantek> cwilso, sure, it's going to take some very deliberate work (especially on the part of the chairs) to institute, guide, and enforce a policy of incubation in the CSS WG. That's a non-trivial challenge. But doable.

SteveZ: such as regions, provided where we had discussion at a planery session and got feedback

<tantek> cwilso, in addition, I think culturally there's a good chance that CSS WG will come up with a compatible at least in spirit/methodology way of incubating that is more efficient than WICG processes literally.

SteveZ: I think there are things that should be in incubation, but before we make forced decisions let's look at our history and come up with that

Rossen: I hear a lot of sympathy and willingness to incubate
... there were strong preferences to where to incubate
... what are the consequences of not working on it where you prefer

slightlyoff: I would like to see the WG change and move to the incubation, we would have a hard time to follow this group if it doesn't change
... it worked for service worker, I'm less worried about where it happens more on how it happens

Florian: out of principle will Google block us

<fantasai> Florian: To the extent that Google wants to lead by example, that's okay

Rossen: please, let's not do this

<fantasai> Florian: But will Google block any progress that is willingily happening now out of principle?

<ChrisL> ^14,06 Purple rain

<cwilso> Chris/Alex: we don't get to block you; we get the same vote everyone else does.

<leaverou> https://twitter.com/w3cmemes/status/778237649534521345

astearns: I'm willing to work on it

Rossen: that would be great, it would be good to cwilso and slightlyoff thoughts on the matter

astearns: we will have success criteria on when something gets past off to the CSSWG

fantasai: I would like to see it come back to us as well, not just after it's all considered "done" and competed in isolation somewhere else, I don't want silos

Rossen: we will come up with that process
... when it comes to the CSS Font spec we'll discuss this later, I want to close on this issue
... thank you slightlyoff and cwilso

Scroll linked animations

<dino> birtles: Dean sent a proposal years ago, but it wasn't complete. Google and Mozilla have come up with separate new proposals

<dino> birtles: I'll give a 1 minute demo, and list a few issues.

<dino> Mozilla's proposal - https://birtles.github.io/scroll-animations/

<dino> Google's proposal - https://github.com/drufball/generalized-animations

<dino> birtles shows a custom build of Firefox with some scroll-linked demos

<leaverou> scribenick: dino

<ChrisL> %C13,1 dino is scribing

myles: is there any script in this demo?

birtles: yes, it's a mix of both. declarative for easy stuff, script takes over after a while.

birtles shows a demo with a mix of scroll-based and time-based animations. switching between the two.

birtles: we've found three issues
... 1. Transitions
... in many cases you want to represent behaviour with transitions not animations. e.g. if you want something to appear, you need two animations for in and out. transitions is just a state change.

in other cases an animation is fine, since it is a run-once situation

birtles: it was a surprise to us that transitions were the most natural way to author many of these effects. this makes the animation-trigger feature less useful.

<jcraig> Will someone please post the link to the New York Times example and the other scroll jacking example?

birtles: we have drafted something called @trigger that can be used to change style based on scroll position
... so issue 1 is do we need an @ rule or something

<birtles> http://www.nytimes.com/projects/2013/tomato-can-blues/?hp

<birtles> http://cuberto.com/

birtles: 2. Layout cycles
... once you have the idea of triggers that can affect layout, you can possibly have a cycle.
... we have some vague wording in the proposal about freezing the scroll offset for the frame
... this avoids a cycle within a frame, but you can still have flip-flop animations

dino: transitions already has this issue

birtles: 3. Describing the scroll points for triggering animations
... maybe we can use the scroll snap points syntax, but i don't know how to do it

Rossen: you mean scroll-snap events?

birtles: no, about linking a scroll point to an element

birtles describes how he wants something to happen based on the position of an element

fantasai: Scroll snapping lets you specify where a scroll for an element will be, but does not let you reference that from another rule.
... have a new property that is "when the scroll snaps at my scroll point, then something happens"

<fantasai> ?

Rossen: thanks for this introduction, we've been waiting for this for a long time

shane: we need to work out what we are going to do
... i suggest a small group of people in an incubator

Rossen: unlike fonts, this seems like a good example of something that could go to WICG and come back when it is more mature
... please, if you want to participate on this topic, do so!

astearns: doesn't need to be a small group. it should include the type of people who are solving this problems with scripts.
... make it as wide as possible

RESOLUTION: Accept this scroll linked animation work, to be done under the WICG

Writing Modes Level 3 Test Status

koji: The test status is linked from the agenda

<Rossen> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html

<skk> http://kojiishi.github.io/generate-w3c-implementation-report/css-writing-modes-3/status-2016-09.html

<ChrisL> There are 995 tests in the test suite, 118 of that have only 1 or less implementations.

koji: there are 995 tests in the suite. 118 tests do not have 2 passing implementations.
... i've categorized them.
... most of the 118 are related to this group. Only about 28 are not.
... the suite depends on 5 other specs. I excluded them from the 28. Then if I remove the MAY or SHOULD tests.... (form controls, etc)
... this leaves 13 tests that are blocking our exit
... of those 13, four categories...
... 1. synthesized baseline

<fantasai> of atomic inlines in vertical-lr

2. text orientation upright property

affects the used value of direction

there are 0 passing implementations

3. absolute positions

There are ~250 tests in this group, and 3 of them don't have 2 implementations

4. Glyph composition

edge case - text combine has a newline character, there is only one passing implementation

koji: these all seem minor to me, and we've made a lot of progress, i propose that we allow these failures and move to PR

ChrisL: we could make the case that 13 failures is ok.

fantasai: for number 2, were you testing the used or computed value?
... so upright text is in the wrong order?

astearns: could fantasai take a look at those 13 failures

ACTION fantasai to take a look at the 13 failing Writing Mode tests

<trackbot> Created ACTION-794 - Take a look at the 13 failing writing mode tests [on Elika Etemad - due 2016-09-27].

astearns: have you filed browser bugs on these failures

koji: some of them, but since authors have not complained, i don't think they are real world issues

Rossen: you should still file the bugs

jet: We do have Gecko bugs for all these! I see that browsers only have at most 80% complete coverage. Is that enough?

astearns: the criteria is that each test has 2 passing implementations, not that there is interoperability between all tests.

Florian: I've informally looked at changing writing mode on table cells and got weird results. Have we tested this enough?

koji: yes

ACTION koji to file these writing mode test failures on the browsers

<trackbot> Created ACTION-795 - File these writing mode test failures on the browsers [on Koji Ishii - due 2016-09-27].

<fantasai> I think categor 4 failing test is a weird edge case, don't need to worry so much.

Rossen: ChrisL, can we go to PR in this state?

<fantasai> I don't think that's the case for #2. Those should be fixed.

ChrisL: we are dropping all the at-risk features?

astearns: yes

ChrisL: we need to write up a clear rationale for us progressing. e.g. we've filed bugs, they are not show stoppers, etc

Florian: especially for the features that are at-risk, we've already got a +1 spec ready.

<dbaron> FWIW, when I started looking through the Gecko failures, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1244601 (which accounted for quite a few) but then didn't get further on filing additional bugs

ChrisL: that doesn't matter

koji: do you have an example of such a document?

ChrisL: an email to the group is enough

astearns: informed by fantasai's review

fantasai: The category 2 failures need to be fixed.
... that's right to left upright

koji: this is uncommon

fantasai: more common in hebrew than arabic

Rossen: any objections to the at-risk features?

fantasai: i think there are blocking tests. I don't think #2 are an edge case.

astearns: does it help to wait for the tests to pass?
... why not move to a new draft now?

fantasai: i would prefer to wait. implementations might be doing the work now.

astearns: look at the test failures, see if we can address category #2, cut down the draft to features that have passing tests
... what else is necessary?

ChrisL: for any comments we received since we last transitioned, we need to show that we handled them. i.e. we need a new DoC
... it's fine to have the DoC say that it will be address in the new version

(clarification on what the transition process is)

fantasai: from the list of 13 tests, if we have implementors who will fix a few bugs, we should be able to transition

ACTION koji to prepare DoC for writing modes transition

<trackbot> Created ACTION-796 - Prepare doc for writing modes transition [on Koji Ishii - due 2016-09-27].

<ChrisL> scribenick: chrisl

<astearns> for calling in: https://mit.webex.com/mit/j.php?MTID=md599def7295fc6e6be518db089d1afca

<ojan> https://github.com/WICG/interventions/blob/master/scroll-anchoring/explainer.md

Scroll Anchoring

ojan: doing this in WICG at interventions github
... nitigate common experience of an ad loading and pushing content down. adjusts scroll position
... during layout, store scroll position, adjust it back if it changed
... anchor deepest element at top of page. restore to position after layout
... as if user scroll, but browser scrolled
... lots of webcompat issues, ugly hueristics
... like poorly done sticky headers that jump
... walk ancestor chain and any ancestor that modifies layout we don't do scrolling
... they animate padding on body which works poorly, gives scroll loops
... want to add a css property to control this
... on by default, opt-out to current behaviour, or opt in for no hueristics
... move to wicg in next 2 weeks
... ignore fixed position elements
... should we do that for abspos as well

frremy: cN YOU ET INTERVENTION WHN ONLY SPECIFIC THINGS HAPPEN

oops caps sorry

fantasai: aware it is affected by align-content property?

<fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position

Rossen: matt not on call yet

<MaRakow> just got in

<MaRakow> normal call-in number?

no

Meeting number:

<ChrisL> 646 865 453

<ChrisL> Meeting password:

<ChrisL> style

<ChrisL> Meeting link:

<ChrisL> Host key:

<ChrisL> 165017

<ChrisL> Audio connection:

<ChrisL> +1-617-324-0000 US Toll Number

<ChrisL> Access code: 646 865 453

<ChrisL> https://mit.webex.com/mit/j.php?MTID=md599def7295fc6e6be518db089d1afca

Media Feature: “reduce motion” user setting

<MaRakow> on call now

jcraig: exposing user prefs through css media features
... macos has this

<MaRakow> kind of hard to hear though

jcraig: flying animations that fly out
... spinning starfield. chrome example. zooming (demonstrates pages)
... make people ill,painful, vomit etc
... this is called "reduce motion". want to expose to web

<bkardell_> ?+

jcraig: prefers-reduced-motion
... asked 3 years ago
... what do ppl feel about exposing these. fingerprinting obv, outweighed by accessibility benefits
... other ones are harder to do - contrast settings vary by platform
... reduce transparency settings
... (demonstrates a carousel)
... allows page authors to decide how t handle it

Rossen: thanks

gregwhitworth: what about platforms with no motion control. return tru always?

jcraig: they will be asking support for it
... may be a way to do with extensions or custom MQ short term
... prefer to avoid prefixing

dino: trivial to implement, huge benefits

bkardell_: discussion earlier was uer prefs, that we need to invent new ways to set independent of OS
... talking in cognitive acessibility taskforce

jcraig: dpub ig does not want to allow this (?)
... we have had shipping settings for years while their taxonomy is thousands of possibilities

bkardell_: do they overlap

jcraig: maybe

Florian: useful to many, easy, should do
... seems to be aina broader category of similar things
... coor contrast somewhere in between
... not clear how toexpose to web platform
... like to notice patterns before we settle on it

jcraig: did a high contrast text setting for example. microsoft can flip fg./bg. android have txt contrast enhancement
... others related to contrast, reduce transparency to boost contrast

<esprehn> Florian: yo

Florian: whole area of incerted, boosted contrat etc. clear to do somethng but not what.
... expressing a user pref, kind of tempted to put in the same group. but maybe jst do that one

esprehn: like to see spec clarified first. monochrome, safari connects to acessibility setting, we connect to display driver
... no-one on a mac has one
... purpose of the mq was not clear
... need to be clearer why it is

<fantasai> esprehn, I think that wasn't originally its purpose, but it has been effectively repurposed :)

TabAtkins: happy to put notes in, in general it is the output device

esprehn: too vague

fantasai: was originally for monochrome monitors, got trpurposed

jcraig: toggled red square green circle for colorblind. considering collapsing that feature

esprehn: if it is tied tothe acessibility setting say so and then we know

fantasai: agreeing with florian. in context of related stuff. want to see all the requests you have had, ina draft, figure out patterns

Florian: tied to acessibility so privacy

Rossen: already mentioned

Florian: suggested earlier that when a page has that from js, user gets a permission notification

<Rossen> [FYI: we're closing on this topic]

jcraig: screen reader directly exposes a disability. this is some benefit but used by many more people
... next steps?

dino: liting all queries is ok but os already has categories. no need to discuss them again

Florian: different ones have different lists

dino: reduce motion is unfuzz, easy to do. go ahead with that

hober: not let perfect be enemy of good

dino: some are fuzzy, changed between releases

Florian: one on me to update draft

astearns: rather start with this one
... asap

fantasai: easier when we have all of them to look at.. this is brainstorming.

astearns: brainstorming should not go in draft
... we have a process. put in the things we are definite, add a note about vague stuff

fantasai: dont limit ourseles in early drafys

Florian: at least this one and reduced transparency

hober: editorial effort, if editors want to do that then great

Rossen: out of time

scroll snap

CSS Scroll Snap

<Rossen> https://github.com/w3c/csswg-drafts/issues/395

fantasai: scoll snap padding change to more general scroll-padding
... define which part of viewport is in view
... not to see visibility but if it is in comfortable position for viewing
... affects scrolling into view, through scrpt or interaction. page up/down. affects scroll from caret movement
... similar things. no effect on layout or scroll origin except as affects snapping
... declarative replacement for js scroll hacking

<fantasai> to accommodate UI elements floating over the scrollable area.

fantasai: and request for caret operations
... same effect for scroll snapping, but more interactions covered too and better UX

Florian: if we have this, it makes a couple of old proposals obsolete, and no need fr the proposd properties
... simpler way to adress that

MaRakow: objections areound semantics of scroll snap for snapping purposes, usage patterns on scroll padding
... cant use one without affecting the other, see github issue
... do implementors have thoughts

dino: apple has no opinion

jet: hmmm
... will comment on github

fantasai: last blocking issue

Florian: since sydney at least

fantasai: matt argues that keeping things separate, odd because most use cases the valueis the same one on scroll padding so one prop for both
... can separate by making a shorthand later if needed
... mainuse case for attach to viewport is to block oyut things too close to the edge or covered byy UI
... block out for all these scroll ops
... if you do want difference then set scroll paddingbased viewport
... and thenuse scroll-snap-margin on snapping element to giv e adifferent spacing
... so all use cases adressed and common case is easy
... so accept this proposal please and make it easy to do good scrolloing

TabAtkins: agreed
... useful to solve things right now. same for scrolling and snapping, make it generic of overflow control

jet: is this from implementation?
... we have an implementatiom

TabAtkins: no it is super old and crufty

fantasai: filed because of working through spec and seemed the author use cases not solved
... all simply ysolved by widening this property
... to more cases

MaRakow: confirming no other strong ipinions

Rossen: no strong ones but tab leans towards eleika strongly now, as id dino

MaRakow: scroll snapping is specific alignement in the viewport while the functionality is a range in view so
... not gauranteed to be the same as the box that what
... acessible in view box

TabAtkins: all approximately right and when a bit different, scroll-snap-margin handles just fine

MaRakow: could other implementorsread the issue and chime in
... does syntax get overloaded
... others seem to think not

<andrey-rybka> +1 for Elika's proposal

fantasai: if you really want to do it with padding then we can split scroll padding into two longhands down the road. doubt we will
... not seeing the mismatch you think exists
... theoretical purity that should not overide author ease of use

<jensimmons> +1 to that — one property that does many things. Not multiple properties that are similar.

MaRakow: not objecting strongly, want other opinions
... on the githb issue

Rossen: so as this is the last issue holding us from CR and to move forard, call for consensus on current issue as stated by elika. so no sustained objection?

<andrey-rybka> just a data point but what Elika proposed actually solves many use cases for Bloomberg

Rossen: you want implementors to give a full read before making up their mind

astearns: more support of elikas proposal

dino: lets decie and adjust in CR if implementors findissues

Rossen: ok with that ?

astearns: this is the last open issue

MaRakow: no there are still some

fantasai: two renaming but no proposal so rejected. one editorial, conciseness. one resolved already
... so just this one issue

Rossen: so appart from editorial ones, no outstanding design issues. matt, agreed?

MaRakow: offscreen mapping is one

fantasai: sitting with proposed text since june, at least
... accepted previously the text was not good
... don't know what you are objecting to

Rossen: almost out of time
... call for consensus
... any objections

(none heard)

resolved accept elika's proposal

fantasai: rename anything? no actual proposal
... so leave as it

Rossen: can we live with mandatory and proximity

(no objections)

fantasai: scroll-snap-stop normal and always, rename normal

(no objections to keeping those names)

fantasai: wording in section on scroll snap on top edge, if it is over here and i dont click this should not care that it happends to align top to top

(we film the interpretative dance)

(literally)

fantasai: if horizontally scrolled then down, do not trigger snap. that is what the section is about
... honestly dont know what the diaagreement is so can't fix it

Rossen: matt?

<fantasai> https://drafts.csswg.org/css-scroll-snap/#snap-scope

MaRakow: point of snapping is to point to snap totheings out of view currently and is this coridoor scrolling the feature only w=starts scrolling through the animation of the scroll
... understand intention
... outside x direction of the viewport is not contributing, not strictly true

Rossen: proposed text?

Florian: I think this is the same issue as what I raised earlier about the wording problem regarding the corridor, for which I got convinced that it was fine

fantasai: different topic

MaRakow: might proposed something last time but not sure. path scroll would take .... considered for snapping

Rossen: ok fair if the spec does not say what exactly is considered outside, needs to be better defined

fantasai: depends on whic snap ositions you consider to land.this however is not that
... this positionis not a snapped position
... like the illustration in the spec, offset in the wrong axis so not snapped
... whe looking for snap positions but can't snap to it unless also brought into view
... so not taking coridoor into consideration. is it snapped? no it is not

MaRakow: have to choose one and need to know which are valid. scoped through custom scroll, intersection on x axis

fantasai: see the section on choosing snbnap positions
... this cannot be chosen, it is not snapped
... even if author anually aligns them there, ua is not snapped there

Rossen: this is in a different section

<fantasai> https://drafts.csswg.org/css-scroll-snap/#choosing

fantasai: section 6.2. this one is saying it is not in a snapped state

Rossen: just ended up there by chance anyway, still not considered snapped

<fantasai> Section in question - https://drafts.csswg.org/css-scroll-snap/#snap-scope

Rossen: make sense?

MaRakow: think so

Rossen: so this adresses your issue

MaRakow: think so yes

Rossen: minor editorial clarifications in CR, lets resolve to do so
... any objections to moving to CR?

fantasai: lets go to CR

(no objections)

<andrey-rybka> +1 for CR

resolved, css scroll snap to go to CR

resolved to accept the text just discussed

<fantasai> ScribeNick: fantasai

Timing functions

birtles: Can we please start another spec
... Wanted to define timing functions for both transitions and animations and web animations in one place
... Currently in Transitions, it's kindof awkward
... Talked about having a frame timing function
... Apple has spring timing function
... Also talked about things like script-defined timing functions
... Multi-segment timing functions
... all these things need to have a home
... So proposal is we make another spec for timing functions
... and take it out of CSS Transitions and put all that stuff there

[general agreement]

fantasai: I think it's a great idea
... I would like to see that if it's pulled out of Transitions Level 1
... We have two levels of this spec
... one with the interop stuff that should go tCR like 2 years ago
... And one with with all the new stuff

dino: Do we need an incubator? Can we just go

<ChrisL> Rossen: this is work in progress in the current charter, just splitting. no need for incubation here

Rossen: This is existing work, just splitting work that's in one spec into another spec
... Continuing existing work
... Don't see any reason to incubate, nothing new there.
... Would ask Tab, would you agree with this statement or not

TabAtkins: Wasn't listening, so yeah sure

shane: I want to answer for Tab, answer is it depends
... Aple's spring timing funciton fundamentally breaks timing function model
... Would rather not see it in a timing function spec
... Think we could accommodate it with the same syntax Apple proposes declaratively in the scrolling animations spec, if we generatlize that

sam: Which aspect of it fundamentally breaks the timing model?

shane: Previously, timing functions couldn't alter the duration of the animation

TabAtkins: More specifically, none of the timing functions had an opinion on what the duration is
... Have to do the math on spring, then set duration accordingly
... Otherwise looks stupid

dino: Ony looks stupid if you pick a stupid duration value

shane: I thought the way t works was to change duration

[confusion]

Rossen: Seems like agreement on continuing working on this
... Let's go back to request for splitting work so we can continue working on it

<nainar> yup that is Sam Weinig

Rossen: Then we can decide on what stays and how it stays
... Do you agree with this, Shane?

shane: If the timing functions you want to consider require...

birtles: ....

shane: I'm fine with that

Rossen: Any objections?

<birtles> birtles: we can decide on where spring() lives later

RESOLUTION: Split out timing functions into own module, Level 1 to include functions that have been implemented for awhile, Level 2 to include newer functions/proposals

RESOLUTION: birtles shane dino MaRakow to edit

Viewport API

rbyers: ...
... Got some compete pictures and stuff, but short summary
... Trying to incubate a new API that will finely explain pinch zoom
... Not trying to make all browsers beahve the same
... Not trying to fully space
... But incremental step to expose a simple API that lets you reason separately about the space that the page is laid out into and the space that the viewer sees
... So, basically relative geometry and position of the layout and visual viewports
... Worked with websites, bunch of bugs
... Sites are broken because make assumptions about this

<rbyers> https://docs.google.com/presentation/d/1VxLlMTgrq11Q-ltPXyg5_7YuDAo00sbdElsRe752sQg/edit#slide=id.g861a184b2_2_237

rbyers: Think simple API can be used to address these cases

<nainar> Needs access

rbyers: Demo/presentation
... Get a sense of the behavior

<rbyers> https://github.com/WICG/ViewportAPI

rbyers: Talking a lot with MaRakow , he's given a lot of feedback on the API
... Here's the repo
... Trying to get barebones simple bit, incubate and iterate
... Experimental implementation of this in Chrome now if you turn on experimental features

Florian: Looked over, seems good to me. Happy to keep in WICG
... I think the terms visual viewport and layout viewport should go into device-adaptation because more than just you is depending on these terms
... Please file issues against me on specific things you need

rbyers: Most CSS specs need to be updated to say which viewport for every place they say viewpot
... And no two browsers agree on which one for these things

astearns: Florian, will you join the WICG group?

Florian: Yeah

Rossen: Wanted to revisit the font variations discussion
... My proposal is to continue this work in Fonts Level 4. Any objections?
... I really don't want this to be the precedent for the chair override feature...

hober: I support this proposal

TabAtkins: I'll tell you later, for now proceed

RESOLUTION: font variance is part of Fonts Level 4

Rossen: Going back to the agenda, we have 10 minutes left

<astearns> https://github.com/w3c/csswg-drafts/issues/319

Florian: Have a thing selected, and then click something with user-select:none
... Should it unselect? Should it?? or ???
... I was tasked to ask the editing task force
... multiple ppl said doing things inside user-select:none shouldn't affect selection
... Think we should resolve on that.

hober: I think it should match platform convention

Florian: What is native behavior of clicking "user-select: none"

hober: Behavior of clicking on an non-selectable areaof the UI

Florian: Safari already doesn't match wat Mac OS does

johannes: ... when you cannot select them, you should not lose your exiting selection

esprehn: user-select:none causes us to unselect things, and we want to change that behavior

Florian: I think that's a eparate issue. No interop, chrome and edge said they'd match Firefox, and editing TF agreed
... If you click or click and drag in select:none doens't affect existing selection

Rossen: Any objections?

<andrey-rybka> +1 to resolve

RESOLUTION: If you click or click and drag in user-select:none area, doens't affect any existing selection

dino: There should be an escape clause for platform convention
... There are definitely parts of UI that are non-selectable in the platform.

Florian: The fact that different browsers behave differently was confusing JS users, so request was to harmonize browsers.
... Safari would have to change, but after change would match its own platform better. So what's the problem?

<astearns> https://github.com/w3c/csswg-drafts/issues/423

Florian: outline-color has two color values. One is 'invert', which is initial value. If can't 'invert', defined to fall back to initial color.
... There are two implementations, one relevant (Edge), two irrelevant (IE, Opera). No process block
... Browsers are allowed to not do that if impractical.
... Don't see any value in removing the value. But ppl have asked to remove the value.
... Use case that justifies this value is real, and we have a relevant current implementation. Would rather not drop it.
... Fact that Edge/IE have this feature and want to continue having it, I think we should keep it.
... If they want to drop it, then we should of course drop it.

fantasai: So proposed rsolution: keep invert unless Edge decides to drop, n which case we drop

RESOLUTION: Keep outline-color: invert unless Edge decides to drop, in which case we drop.

fantasai: wrt text-underline thickness/position, has to be separate property from the existing -possition property, because that one is lang-dependent and intended to inherit through independently fromother props
... probably want an -offset property for position control

Meeting adjourned.

<bobbytung> -offset +1

<Rossen> trackbot, end meeting

<dbaron> hmmm, you're requiring that clicking someplace else *not* clear an existing selection?

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

FAILED: s/a couple ppl/Francois & Greg/
Succeeded: s/MichaelC_/MichielBijl/
Succeeded: s/intersted/interested/
Succeeded: s/??/as a short questionnaire on accessibility gotchas that editors can refer to/
Succeeded: s/??/MichaelC/
Succeeded: s/??/MichaelC/
Succeeded: s/Not true in most browsers... Firefox/Generated content mapped in majority of browsers... Chrome and Safari at least... Possibly Firefox (Joanie responded ~"-ish")/
Succeeded: s/j:/janina:/
FAILED: s/j:/janina:/
Succeeded: s/Meida/Media/
Succeeded: s/cuzwrpaping/cuz wrapping/
Succeeded: s/board/order/
Succeeded: s/8/1.8/
Succeeded: s/hting/thing/
Succeeded: s/stalling process/stalling progress/
Succeeded: s/complicated syntax/to be a complicated microsyntax/
Succeeded: s/size/size and position/
Succeeded: s/when/but when/
Succeeded: s/distane/distance/
Succeeded: s/RESOVED/RESOLVED/
Succeeded: s/contrast ratio could be different/Devices with small gamuts typically display colors as less saturated/
Succeeded: s/makes bundling faster/friendlier to bundling/
Succeeded: s/people don't like to toggle the stylesheet because it is easier/reality is, all big websites use a nojs class that they remove via JS. They do not toggle stylesheets, because this is easier for maintenance./
Succeeded: s/you could even flip the stylesheet, or a nojs class/what is this nojs class nonsense, you can just flip the stylesheet to enabled/
Succeeded: s/???/gsnedders/
Succeeded: s/??/gsnedders/
Succeeded: s/opera didn't state if they want to implement it/has Opera said if they're going to implement this middle value? has anyone?/
Succeeded: s/not in blink/Opera Mini is still using Presto and we're not going to implement any new features there/
Succeeded: s/this/complex % back tracking/
Succeeded: s/margin/margin-left/
Succeeded: s/<ig/<img/
Succeeded: s/ChrisL /cwilso/
Succeeded: s/ChrisL /cwilso/
Succeeded: s/telecons/individual threads/
Succeeded: s/fragmentation/fragmentation; one of the advantages of discussing things in the entire WG is getting the broad expertise of a) people with different perspecives and b) people who have experience with many differnet parts of the technology and know how to integrate it and keep it self-consistent/
Succeeded: s/as well/as well, not just after it's all considered "done" and competed in isolation somewhere else/
Succeeded: s/New Yorker example/New York Times example/
Succeeded: s/would/could/
Succeeded: s/discussion/clarification/
Succeeded: s/end view/in view/
Succeeded: s/MaRakow/fantasai/
Succeeded: s/convinced this is not an issue/I think this is the same issue as what I raised earlier about the wording problem regarding the corridor, for which I got convinced that it was fine/
Succeeded: s/leys/lets/
Succeeded: s/??/sam/
Found ScribeNick: TabAtkins
Found ScribeNick: gregwhitworth
Found ScribeNick: dino
Found ScribeNick: chrisl
Found ScribeNick: fantasai
Inferring Scribes: TabAtkins, gregwhitworth, dino, chrisl, fantasai
Scribes: TabAtkins, gregwhitworth, dino, chrisl, fantasai
ScribeNicks: TabAtkins, gregwhitworth, dino, chrisl, fantasai
Default Present: tantek, Rossen, dholbert, eae, jihye, gregwhitworth, glazou, dauwhe, bradk, Florian, antonp, myles, dael, Rossen__, dbaron, tgraham, myles_, antenna, astearns, plinss, alex_antennahouse, SteveZ, Bert, hober, iank_, rachelandrew, Rossen_, fantasai, fremy_, TabAtkins, vollick, ChrisL, smfr, zcorpan, antonp[, fremy, plh, SteveZ_, MaRakow, joone, Liam_Quin, bkardell_, gsnedders, jensimmons, leaverou, skk, ++++++++1, Guest, LiamQuin, p, tmichel, AndroUser, btw, liam, arybka, (finally), andrey-rybka, surma, skhrshin, tzviya, Charles_LaPierre, ivan_herman, David, Wood, Vlad, Karen, Leonard, Bill_Kasdorf, Paul_Belfanti, Heather_Flanagan, kuettel, MichielBijl, MichaelC, birtles, SimonSapin, dino, richardschwerdtfeger, Janina, (Francois, REMY, Microsoft), (Emil, Eklund, Google), tomalec, nainar, Shintaro, Sakahara, BPS, Takamasa, Ikeda, Behdad, Esfahbod, Gottfried, Zimmermann, Invited, expert, APA, jcraig, RMurillo
Present: tantek Rossen dholbert eae jihye gregwhitworth glazou dauwhe bradk Florian antonp myles dael Rossen__ dbaron tgraham myles_ antenna astearns plinss alex_antennahouse SteveZ Bert hober iank_ rachelandrew Rossen_ fantasai fremy_ TabAtkins vollick ChrisL smfr zcorpan antonp[ fremy plh SteveZ_ MaRakow joone Liam_Quin bkardell_ gsnedders jensimmons leaverou skk ++++++++1 Guest LiamQuin p tmichel AndroUser btw liam arybka (finally) andrey-rybka surma skhrshin tzviya Charles_LaPierre ivan_herman David Wood Vlad Karen Leonard Bill_Kasdorf Paul_Belfanti Heather_Flanagan kuettel MichielBijl MichaelC birtles SimonSapin dino richardschwerdtfeger Janina (Francois REMY Microsoft) (Emil Eklund Google) tomalec nainar Shintaro Sakahara BPS Takamasa Ikeda Behdad Esfahbod Gottfried Zimmermann Invited expert APA jcraig RMurillo (Francois_REMY (Emil_Eklund Shintaro_Sakahara Takamasa_Ikeda Behdad_Esfahbod Google Gottfried_Zimmermann Invited_expert_APA

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 20 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/20-css-minutes.html
People with action items: 

WARNING: Possible internal error: join/leave lines remaining: 
        <ChrisL> cwilsohas joined #css
        <ChrisL> cwilsohas joined #css



WARNING: Possible internal error: join/leave lines remaining: 
        <ChrisL> cwilsohas joined #css
        <ChrisL> cwilsohas joined #css