See also: IRC log
<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
<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
<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
<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
<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?
<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)
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
<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
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
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
<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
<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
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
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: 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[End of scribe.perl diagnostic output]