/irc-logs / w3c / #css / 2013-06-05 / end

Options:

# Session Start: Wed Jun 05 00:00:00 2013
# Session Ident: #css
# [00:04] * Joins: cabanier (~cabanier@public.cloak)
# [00:05] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [00:09] * Joins: cabanier (~cabanier@public.cloak)
# [00:19] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [00:27] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [00:31] * Joins: dbaron (~dbaron@public.cloak)
# [00:58] * Joins: sgalineau (~sgalineau@public.cloak)
# [01:09] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [01:09] * Joins: sgalineau (~sgalineau@public.cloak)
# [01:11] * Quits: tobie (tobie@public.cloak) (Ping timeout: 180 seconds)
# [01:28] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [01:45] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [01:46] * Joins: zcorpan (~zcorpan@public.cloak)
# [01:53] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [01:53] * Joins: jdaggett (~jdaggett@public.cloak)
# [01:56] * Joins: SimonSapin (~simon@public.cloak)
# [02:03] * heycam|away is now known as heycam
# [02:03] <jdaggett> most folks in the room? starting soon?
# [02:07] <heycam> some folks, feeling like we're waiting ofr a few more though
# [02:07] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [02:07] <jdaggett> cool, thx
# [02:09] * Joins: SimonSapin (~simon@public.cloak)
# [02:09] * Joins: cabanier (~cabanier@public.cloak)
# [02:10] * Joins: lmcliste_ (~lmclister@public.cloak)
# [02:11] * Joins: Rossen (~Rossen@public.cloak)
# [02:11] * Quits: lmclister (~lmclister@public.cloak) (Ping timeout: 180 seconds)
# [02:11] * Joins: birtles (~chatzilla@public.cloak)
# [02:15] * Joins: dbaron (~dbaron@public.cloak)
# [02:15] * Joins: glazou (~glazou@public.cloak)
# [02:16] <dbaron> trackbot, start meeting
# [02:16] * trackbot is preparing a teleconference.
# [02:16] * Joins: RRSAgent (rrsagent@public.cloak)
# [02:16] <RRSAgent> logging to http://www.w3.org/2013/06/05-css-irc
# [02:16] <trackbot> RRSAgent, make logs member
# [02:16] <RRSAgent> I have made the request, trackbot
# [02:16] * Joins: Zakim (zakim@public.cloak)
# [02:16] <trackbot> Zakim, this will be Style_CSS FP
# [02:16] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [02:16] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [02:16] <trackbot> Date: 05 June 2013
# [02:16] <dbaron> RRSAgent, make logs public
# [02:16] <RRSAgent> I have made the request, dbaron
# [02:17] <dbaron> Zakim, remind us in 8 hours to go home
# [02:17] <Zakim> ok, dbaron
# [02:17] <glazou> rrsagent, this meeting spans midnight
# [02:17] <RRSAgent> ok, glazou; I will not start a new log at midnight
# [02:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [02:18] <dbaron> RRSAgent, this meeting does not span midnight
# [02:18] <RRSAgent> I'm logging. I don't understand 'this meeting does not span midnight', dbaron. Try /msg RRSAgent help
# [02:18] * Joins: r12a (rishida@public.cloak)
# [02:18] * jdaggett loves all this sexy machine talk...
# [02:18] * Joins: shans__ (~shans@public.cloak)
# [02:18] <dbaron> RRSAgent, start a new log at midnight
# [02:18] <RRSAgent> ok, dbaron; I will start a new log at midnight
# [02:19] <jdaggett> RRSAgent, you look lovely tonight
# [02:19] <RRSAgent> I'm logging. I don't understand 'you look lovely tonight', jdaggett. Try /msg RRSAgent help
# [02:19] * liam particularly likes <dbaron> Zakim, remind us in 8 hours to go home
# [02:19] * dbaron liam, that's so it doesn't leave after an hour
# [02:19] * dbaron though I should have used 9 hours
# [02:19] * liam ah, cool, good idea!
# [02:19] * jdaggett yeah, 9 is right
# [02:21] * Joins: Kazutaka (~Kazutaka@public.cloak)
# [02:24] * Joins: krit (~krit@public.cloak)
# [02:25] * Joins: myakura (~480ee730@public.cloak)
# [02:25] * Joins: nikos (~Thunderbird@public.cloak)
# [02:26] * Joins: stakagi (~stakagi@public.cloak)
# [02:26] * Joins: jdovey (~jdovey@public.cloak)
# [02:26] <glazou> jdaggett, send us a few meeting tables and power strips, we could use them immediately :-(
# [02:26] <jdaggett> oh dear
# [02:27] <glazou> why do you think we've not started yet ?
# [02:27] <jdaggett> google japan has no power strips?
# [02:28] <jdaggett> is brian birtles there? get him to run back to mozilla japan to fetch some
# [02:28] <jdaggett> he's a good runner!
# [02:31] <dbaron> birtles is here :-)
# [02:32] * birtles jdaggett, thanks! do I get a 'monster' if I run there and back? that's the normal deal
# [02:33] <jdaggett> haha
# [02:33] <jdaggett> i saw a big order come in last week...
# [02:33] <jdaggett> that stuff will kill you... ;)
# [02:33] * birtles yeah, I heard it's also not so good if you plan on having children
# [02:34] <jdaggett> yikes
# [02:39] * krit obviously there is no working cooperation between Apple and Google
# [02:39] * krit or at least Apple TV
# [02:42] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [02:43] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [02:43] * Joins: krit (~krit@public.cloak)
# [02:47] * Joins: jerenkrantz (~jerenkrantz@public.cloak)
# [02:49] * Joins: plh (plehegar@public.cloak)
# [02:49] * Joins: Tav (~tbah@public.cloak)
# [02:49] * Joins: fantasai (~fantasai@public.cloak)
# [02:49] * Joins: jdovey (~jdovey@public.cloak)
# [02:51] <jerenkrantz> Is there an agenda? Or, will we kick off with agenda bashing?
# [02:51] <stearns> the latter, usually
# [02:52] <glazou> jerenkrantz, what stearns said
# [02:52] <jdovey> beanbags & slingshots at the ready…
# [02:52] <dbaron> I took the opportunity to write http://wiki.csswg.org/planning/hosting
# [02:53] <jerenkrantz> Since I am new, do we tend to do intros and is there a scribe for those who can't join here?
# [02:54] <dbaron> ScribeNick: dbaron
# [02:54] <dbaron> Topic: introductions
# [02:54] <liam> dbaron, I added a bullet item to that wiki page, telephone access
# [02:55] * Joins: Cyril (~chatzilla@public.cloak)
# [02:56] * liam goes to other meetings
# [02:56] * Joins: koji (~koji@public.cloak)
# [02:56] * Quits: koji (~koji@public.cloak) ("Leaving...")
# [02:57] <dbaron> Present: Daniel Glazman (Disruptive Innovations), Elika Etemad (Mozilla), Simon Sapin, Philippe Le Hegaret (W3C), David Baron, Tamjong Bah, Rik Cabanier (Adobe), Dirk Schultze (Adobe), Cyril Concolato, Nikos Andronikos, Brian Birtles (Mozilla Japan), Cameron McCormack (Mozilla), Dean Jackson (Apple), ?? (NTT), Satori ??? (KDDI), Masataka Yakura (??), Tab Atkins (Google), Justin Erenkrantz (Bloomberg), Koji Ishii (Rakuten), Jim Dovey (Kobo), Shane Stevens (Googl
# [02:57] <dbaron> e), Alan Stearns (Adobe), Richard Ishida (W3C), Alan Stearns (Adobe), Bert Bos (W3C), Rossen Atanassov (Microsoft), Glenn Adams (Cox), Jet Villegas (Mozilla)
# [02:58] * Joins: Koji (~Koji@public.cloak)
# [02:58] <heycam> http://www.pastebin.mozilla.org/2486303
# [02:58] <dbaron> Topic: Agenda
# [02:58] <dbaron> Peter: There's also an FXTF wiki for agenda items in addition to http://wiki.csswg.org/planning/tokyo-2013#agenda
# [02:58] <dbaron> heycam: The only ordering restriction is doug wants to call in for text wrapping, prefers early
# [02:59] <dbaron> is shepazu available now-ish?
# [02:59] <myakura> s/Satori ???/Satoru Takagi/
# [03:00] <plinss> zakim, room for 3?
# [03:00] <Zakim> ok, plinss; conference Team_(css)01:00Z scheduled with code 26631 (CONF1) for 60 minutes until 0200Z
# [03:00] <heycam> shepazu ^
# [03:00] <Tav> s/Tamjong/Tavmjong/
# [03:00] <dbaron> Present+ Peter Linss (HP)
# [03:01] <Kazutaka> s/?? (NTT)/Kazutaka Yamamoto(NTT)/
# [03:03] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [03:03] <dbaron> Topic: Web Animations
# [03:04] <birtles> spec link: https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html
# [03:08] <dbaron> dialing to Zakim failed, switching back to projector
# [03:09] * glazou should not have taken an espresso this morning, more adrenaline was not needed
# [03:09] * shepazu waves
# [03:09] <glazou> ROFL @ http://w3cmemes.tumblr.com/image/52183066977
# [03:10] * heycam shepazu so brian is going to present on Web Animations first, once we have the projector/phone set up correctly, and then we'll move to the text topic
# [03:10] * shepazu could dial in first, if you like
# [03:10] <heycam> shepazu, yes feel free
# [03:11] * shepazu pings Cyril
# [03:12] * shepazu heycam, what number should I call? or should we use skype?
# [03:12] * dbaron Zakim, code?
# [03:12] * Zakim the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron
# [03:12] <dbaron> birtles: wanted to give overview of web animation; getting close to asking for FPWD.
# [03:12] <Zakim> Team_(css)01:00Z has now started
# [03:12] <dbaron> britles: summary of where the spec has come from and what's in it now, so you know what you're looking at when review
# [03:13] <Zakim> +Doug_Schepers
# [03:13] * plinss shepazu ^
# [03:13] <dbaron> birtles: microsoft asked that there be one model for animations on the web, not separate SVG animations and CSS animations, and suggested there should be an API. Request echoed by others.
# [03:13] * shepazu can wait until after birtles is done, I'll call back in then
# [03:13] * Quits: jerenkrantz (~jerenkrantz@public.cloak) (Client closed connection)
# [03:13] <Zakim> -Doug_Schepers
# [03:13] <Zakim> Team_(css)01:00Z has ended
# [03:13] <Zakim> Attendees were Doug_Schepers
# [03:13] <dbaron> birtles: about 1 year ago, Adobe suggested I start concrete proposal for that; invited Shane (Google) to help, had suggestions about state machines
# [03:13] <dbaron> birtles: presented last year in Hamburg, and FXTF agreed to take it on as a work item
# [03:14] * heycam suspects a new "Zakim room for 3" will be required since the call has finished now
# [03:14] <dbaron> birtles: I've been working with Adobe and Google to produce specification
# [03:14] * shepazu can do that
# [03:14] <birtles> diagram: https://wiki.mozilla.org/images/f/f6/CSS-SVG-Web-Animations.png
# [03:14] <dbaron> birtles: overview of what's in it in this diagram
# [03:14] * Joins: dino (~dino@public.cloak)
# [03:14] * Joins: jerenkrantz (~jerenkrantz@public.cloak)
# [03:14] <dbaron> birtles describes diagram
# [03:14] * heycam https://wiki.mozilla.org/images/f/f6/CSS-SVG-Web-Animations.png
# [03:16] <dbaron> birtles: (part of diagram description) SVG features not in the model mostly are features that generate animations rather than animations themselves
# [03:17] * sgalineau cool diagram
# [03:17] <dbaron> birtles: We've cut a bunch of features recently; deferred integration with media and other features to keep it to a core model that roughly represents what's there already plus just a few extras
# [03:18] <dbaron> birtles: Specification is quite long, because (1) it's the union of existing technologies (2) tries to define a lot of gray areas, particularly with regards to SVG. We've incorporated the features SVG references from SMIL into the model. More explicitly defined. (3) Style of specification; many non-normative explanatory sections.
# [03:18] <dbaron> birtles: Apple's request to split into 2 parts: model first, then script api.
# [03:18] <dbaron> birtles: we're focusing on the model, but the API often generates the most controversy/feedback
# [03:19] <dbaron> birtles: going forwards, both Google and Mozilla have been talking about implementation strategies. Starting by implementing the model and pref-ing off the API, and then enabling the API bit by bit.
# [03:19] <dbaron> birtles: The API is the controversial bit and the bit we really want toget right (hard to change later).
# [03:19] <dbaron> birtles: About ready to ask for First Public Working Draft (FPWD) approval; a few edits we want to make first (drop a few interfaces).
# [03:19] <dbaron> birtles: So what's there is hopefully what we'll be sending out later this week.
# [03:19] <dbaron> birtles: So, just wanted to introduce this and ask if any immediate feedback or questions
# [03:20] <dbaron> dino: slightly concerned that media was dropped. One of the things we considered important from Apple's perspective.
# [03:20] <dbaron> dino: But I think this spec is in better shape before FPWD than most specs are after 5 or 6 WDs.
# [03:20] <dbaron> birtles: Decision to drop media references is very recent; we have spec text around. So if that's a strong request from other vendors then we could look at it.
# [03:20] <dbaron> dino: Nothing to stop a draft. Call out in the draft that it's been removed?
# [03:21] <dbaron> birtles: Also looking to make that a separate module so it doesn't have to wait for v2. If it matures quickly could look at pulling into v1, but anticipate implementation issues that could hold back core model.
# [03:21] <dbaron> stearns: on the other side: is there justification in the draft for the 4 new things in the model?
# [03:21] <dbaron> stearns: rather than just describing the union?
# [03:22] <dbaron> birtles: there isn't extensive justification for each feature
# [03:22] * Quits: jerenkrantz (~jerenkrantz@public.cloak) ("Page closed")
# [03:22] <dbaron> birtles: timing groups quite central to the model, come about with issues with SVG synchronization features. Custom effects could be dropped. iterationstart is a commonly requested feature and very minor addition
# [03:22] * Joins: jerenkrantz (~j@public.cloak)
# [03:22] <dbaron> birtles: no justification per se except for use cases at te start
# [03:23] <dbaron> dino: our feedback a while ago (but don't want to argue against this spec) was that we were concerned about the massive amount of new API to add in one step. Generally Web improvements are more successful when iterative rather than massive new feature (be interesting to know why?).
# [03:23] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [03:23] <dbaron> dino: also suggested that Apple's main interest in this type of work is very much in the form of declarative approaches to animation backed by a strong api.
# [03:24] <dbaron> dino: I think the strength of this spec is that it has a powerful API with a complete JS library.
# [03:24] <dbaron> dino: We're more interested in how a web developer not knowing much about animations mark up their document so that things happen over time in the document
# [03:24] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [03:24] <fantasai> dino: That's why we're interested in media
# [03:24] * Joins: cabanier (~cabanier@public.cloak)
# [03:24] <dbaron> dino: The first way most people add time aspects to their document is video... we didn't necessarily want to have them add JS to do that.
# [03:25] <Zakim> Team_(css)01:00Z has now started
# [03:25] <Zakim> +[IPcaller]
# [03:25] <dbaron> dino: At SVG meeting earlier in this year, we discussed maybe a module to this spec to say that there's a way to apply changes in state over time, exposed e.g. by new CSS selector or class
# [03:25] * heycam Zakim, code?
# [03:25] * Zakim saw 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, heycam
# [03:25] <dbaron> dino: so a developer would approach authoring by saying from 10s-20s, this is the state that applies
# [03:25] <jdaggett> hmm, no zakim conf at 26631
# [03:25] <dbaron> dino: so you could write CSS that applies when that state is ative
# [03:26] <dbaron> dino: so a CSS developer could easily understand this -- no JS. When state applies, apply transitions/animations/styles/whatever.
# [03:26] <dbaron> dino: but adjacent to this spec
# [03:26] <dbaron> dino: more like what we were hoping to use this spec for
# [03:26] <dbaron> birtles: I should emphasize that the API is not fundamental to the model; you can implement the model without the api.
# [03:26] <dbaron> birtles: Those parts which are outside the model but are in CSS or SVG are defined in separate specifications.
# [03:26] <jdaggett> heycam: you guys aren't connected to zakim, i'm the "first participant"
# [03:26] <dbaron> birtles: For the SVG parts, we'd have an SVG specification (my next task).
# [03:27] * shepazu heycam, do you need another telcon bridge set up?
# [03:27] <dbaron> birtles: Likewise CSS animations level 4 could be expressed in terms of that model
# [03:27] * heycam jdaggett what code did you use then?
# [03:27] <dbaron> birtles: in media... doing as a separate model...
# [03:27] <jdaggett> the 26631 one
# [03:27] <dbaron> dino: primary use case readalong books in iBooks -- a kids book that has, say, 3 lines of text on the page
# [03:27] * heycam shepazu do you want to try connecting with 26631?
# [03:27] <dbaron> dino: audio track in page, lines or words highlight along with audio track
# [03:28] * heycam I don't think we are dialled in yet
# [03:28] <dbaron> dino: want to avoid using script
# [03:28] <dbaron> dirk: using SMIL for this?
# [03:28] <dbaron> dino: Ever tried writing that in SMIL? It's crazy.
# [03:28] <Zakim> +Doug_Schepers
# [03:28] * dbaron we couldn't figure out how to dial in from room
# [03:28] <dbaron> birtles: next specification I'll be working on is SVG mapping onto the model
# [03:29] <dbaron> dirk: Your request is to review the spec give feedback, and end up with publishing FPWD.
# [03:29] <dbaron> birtles: yes, will send request later this week
# [03:29] <dbaron> dino: what's the state of your JS shim/polyfill?
# [03:29] <dbaron> birtles: I'm not contributing to that; Google is.
# [03:29] <dbaron> shane: what info do you want?
# [03:30] <dbaron> dino: how complete relative to spec?
# [03:30] <dbaron> shane: more complete than current spec? Up to date other than last 3-4 weeks.
# [03:30] <dbaron> shane: on github, open source license
# [03:30] <dbaron> shane: should be relatively easy for us to sync with last set of changes over a week or so
# [03:30] <dbaron> birtles: have some issues with events marked in spec with "feedback wanted" -- we want more input
# [03:31] <dbaron> glazou: did you want to ask for FPWD now?
# [03:31] * jdovey JS shim is at https://github.com/web-animations/web-animations-js
# [03:31] <dbaron> ?: or give people time to review?
# [03:31] <dbaron> dino: I think it's a high quality spec, I think the question is whether in scope or out of scope.
# [03:32] <Zakim> -[IPcaller]
# [03:32] <Zakim> -Doug_Schepers
# [03:32] <Zakim> Team_(css)01:00Z has ended
# [03:32] <Zakim> Attendees were [IPcaller], Doug_Schepers
# [03:32] <dbaron> glazou: do people want time to review?
# [03:33] <dbaron> [various people happy with publishing]
# [03:33] <dbaron> Bert: no time to review before July anyway, so don't wait for me
# [03:34] <dbaron> RESOLVED: Publish Web Animations as First Public Working Draft (resolved by both CSS and SVG WGs).
# [03:34] * shepazu yay!
# [03:34] * heycam shepazu still phone problems. they're trying alternative arrangements, so we'll keep going with other topics in the meantime. sorry.
# [03:35] * shepazu heycam, ok, jdaggett and I are waiting to hear about the g+ hangout
# [03:35] <dbaron> Topic: reusing stroke and fill properties
# [03:35] <dbaron> heycam: topic added from CSS side
# [03:35] <dbaron> heycam: did someone have a specific proposal
# [03:35] * shepazu wonders if Adobe could provide another phone bridge?
# [03:35] <dbaron> Tab: it was me
# [03:35] <Zakim> Team_(css)01:00Z has now started
# [03:36] <dbaron> fantasai: we've had requests to be able to do fill and stroke on letterforms
# [03:36] <Zakim> + +81.36.384.aaaa
# [03:36] <dbaron> fantasai: webkit has text-stroke property. Might make more sense to reuse existing SVG properties.
# [03:36] * Quits: birtles (~chatzilla@public.cloak) (Client closed connection)
# [03:36] * TabAtkins shepazu wanna call into zakim again? trying to see if this works
# [03:36] <Zakim> +Doug_Schepers
# [03:36] <dbaron> fantasai: Complication is filling with pattern or image of some kind... how to handle line breaks is complicated
# [03:36] * Joins: birtles_ (~chatzilla@public.cloak)
# [03:36] * birtles_ is now known as birtles
# [03:36] <dbaron> fantasai: stroking or filling with color is straightforward
# [03:36] <dbaron> heycam: why do line breaks complicate things?
# [03:37] <dbaron> fantasai: need to find the bounding box
# [03:37] <Zakim> +Vivienne
# [03:37] * heycam Zakim who is on the call?
# [03:37] <dbaron> [pause for Zakim debugging]
# [03:38] * plh wonders how confusing color and fill are going to be for devs
# [03:38] <Zakim> -Vivienne
# [03:38] <dbaron> fantasai: might cut or take bounding box or separately per fragment
# [03:38] <dbaron> http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break
# [03:38] <fantasai> dbaron: we do sort-of have a property for this already
# [03:38] <jdaggett> the webvtt guys have 'text-outline' as part of their spec
# [03:38] <dbaron> dbaron: we do sort of have a property for this already: http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break
# [03:38] <jdaggett> fill/stroke would be a better way of supporting that
# [03:38] <dbaron> fantasai: do we reuse that property or have separate control?
# [03:39] <dbaron> heycam: what does box-decoration-break do? fantasai: determines how it's handled for borders and background
# [03:39] <dbaron> fantasai: That's background, this is about foreground.
# [03:39] <dbaron> heycam: That's one issue. Another is defining how color property and fill/stroke properties work together and whether their initial values allow same behavior for existing things.
# [03:39] <dbaron> dirk: I think the first question is do we want something like that.
# [03:40] <dbaron> dirk: Before we talk about page break or line break or whatever.
# [03:40] <Zakim> - +81.36.384.aaaa
# [03:40] <Zakim> -Doug_Schepers
# [03:40] <Zakim> Team_(css)01:00Z has ended
# [03:40] <Zakim> Attendees were +81.36.384.aaaa, Doug_Schepers, Vivienne
# [03:40] <dbaron> fantasai: simplest are fill-opacity and stroke; fill could deal with later
# [03:40] <dbaron> dirk: I think fill at least as important as stroke
# [03:41] <dbaron> dino: webkit currently has custom property for gradients in text -- -webkit-background-clip -- horrible thing with backgrounds, for filling text. Can't then do background.
# [03:41] <dbaron> dino: want to be able to say fill text with gradient/color/pattern; seems pretty standard for CSS
# [03:41] <dbaron> fantasai: additional complication is that color inherits
# [03:41] <dbaron> fantasai: so each element paints with its own color property
# [03:41] <dbaron> fantasai: if you add more elements nothing changes unless you set properties on those elements
# [03:41] <dbaron> fantasai: you want pattern to be consistent across an entire paragraph
# [03:42] <dbaron> ... with elements inside
# [03:42] * Quits: lmcliste_ (~lmclister@public.cloak) (Client closed connection)
# [03:42] <dbaron> heycam: in SVG, two options (1) define pattern area in coordinate space of elements or (2) define relative to bounding box of element that's using that paint
# [03:42] <dbaron> heycam: but for tspans within a text element we use the bounding box of the text element as a whole
# [03:42] <dbaron> dbaron: don't think (1) works with CSS model
# [03:42] <dbaron> heycam: agree
# [03:43] <dbaron> heycam: so what happens with linear-gradient on a paragraph with multiple spans...
# [03:43] * Joins: MikeSmith (~MikeSmith@public.cloak)
# [03:43] <dbaron> dbaron: background doesn't inherit
# [03:43] <MikeSmith> RRSAgent, make minutes
# [03:43] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/05-css-minutes.html MikeSmith
# [03:44] <dbaron> [not minuting entire discussion here]
# [03:44] <fantasai> dino notes that fill inherits
# [03:44] <dbaron> dino: fill/stroke/color inherit and background doesn't; don't want a new style of fill for every child
# [03:44] <fantasai> fantasai: that would be a problem
# [03:45] <dbaron> heycam: why would fill and color have different inheritance?
# [03:45] <dbaron> fantasai: if you're setting a pattern need to know which element initiated the pattern
# [03:45] <dbaron> heycam: seems odd for fill and color to have difference in whether they inherit, similar actions
# [03:46] <dbaron> heycam: I think we should first see if people think it's a good idea for fill and stroke to work for text... then work out issues if people like it.
# [03:46] <dbaron> dirk: always have option to have different properties
# [03:46] <fantasai> dbaron: I think it is a good idea to use fill/stroke. Would like to see that work
# [03:46] <Zakim> Team_(css)01:00Z has now started
# [03:46] <fantasai> dbaron: We could do it by turning fill/stroke into shorthand that sets both an inherited and non-inherited property
# [03:47] <Zakim> + +81.36.384.aaaa
# [03:47] <fantasai> heycam: ???
# [03:47] <fantasai> dbaron: Say 'fill' is a shorthand for 'fill-pattern' and 'fill-root'
# [03:47] <Zakim> +[IPcaller]
# [03:47] <SimonSapin> heycam: so having text-stroke and text-fill not inherited and shape-stroke and shape-fill (for SVG) inherited
# [03:47] <fantasai> dbaron: latter of which has 'normal' and 'establish' or something
# [03:48] <fantasai> dino: You only want this fill/stroke to apply to text
# [03:48] <dbaron> dino: question is, do you only want this new fill/stroke to apply to text?
# [03:48] <Zakim> +Doug_Schepers
# [03:48] <fantasai> dino: It's text-stroke. Do you ever want to stroke the box?
# [03:48] <dbaron> dino: that's one reason in webkit it's text-stroke
# [03:48] <dbaron> dino: do you ever want to stroke a box?
# [03:48] <fantasai> fantasai: That's what borders are for
# [03:48] <dbaron> fantasai: that's what borders are for
# [03:48] <dbaron> ?: just on text
# [03:48] <shepazu> fantasai: that's what borders are for
# [03:48] <dbaron> dino: then why not just do text-fill and text-stroke
# [03:49] <dbaron> dirk: if you say ... should be a shorthand ... inheritance problem ...
# [03:49] <dbaron> dino: sounds fine to me
# [03:49] <dbaron> fantasai: in SVG stroke just sets color of something ... weird
# [03:49] * shepazu hears a siren...
# [03:49] <dbaron> heycam: might be beneficial for 'stroke' to be shorthand to stroke-paint and stroke-width and ...
# [03:49] <dbaron> fantasai: yes, that would follow pattern of CSS a lot better
# [03:49] <dbaron> dirk: what does stroke-paint stroke-width mean?
# [03:49] <dbaron> heycam: stroke-paint would be what stroke is currently
# [03:50] <dbaron> fantasai: you can set all the stroke-related properties
# [03:50] <dbaron> fantasai: if you just want to touch the color you say stroke-paint
# [03:50] <dbaron> heycam: might be more convenient for SVG anyway
# [03:50] <dbaron> fantasai: possible without breaking the Web?
# [03:50] <dbaron> heycam: yeah, probably
# [03:50] <dbaron> fantasai: depends how often people use it in CSS syntax rather than in SVG file
# [03:50] * shepazu can't hear
# [03:50] <dbaron> fantasai: because stroke-width: ...; stroke: ...; would reset the first
# [03:51] <Zakim> - +81.36.384.aaaa
# [03:51] <shepazu> (what would stroke: blue; do?)
# [03:51] <dbaron> heycam: so I feel like somebody should look at these issues and come up with proposal forintegrating
# [03:51] <dbaron> dirk: problem here is we have the attributes
# [03:51] <dbaron> dirk: [too fast]
# [03:51] <Zakim> -[IPcaller]
# [03:51] <Zakim> -Doug_Schepers
# [03:51] <Zakim> Team_(css)01:00Z has ended
# [03:51] <Zakim> Attendees were +81.36.384.aaaa, [IPcaller], Doug_Schepers
# [03:51] <dbaron> heycam: we already decided to allow font shorthand as presentation attribute
# [03:51] <Zakim> Team_(css)01:00Z has now started
# [03:51] <SimonSapin> shepazu, if it’s a shorthand, set stroke-paint to blue and stroke-width to the initial value
# [03:51] <dbaron> heycam: you take all the presentation attributes in a praticular order
# [03:51] <Zakim> +??P0
# [03:52] <dbaron> dirk :cannot modify this order in te dom
# [03:52] <shepazu> SimonSapin, then it won't break the web
# [03:52] <dbaron> heycam: might not have made this change
# [03:52] <dbaron> fantasai: for surethe stroke attribute would map to stroke-paint... it would have to
# [03:52] <dbaron> fantasai: never mind
# [03:52] <dbaron> heycam: anybody think it's a bad idea to try to allow paints in stroking text?
# [03:52] <dbaron> Bert: principle is good, worried about syntax
# [03:53] * Joins: shans__ (~shans@public.cloak)
# [03:53] <dbaron> fantasai: in SVG, if you stroke a letterform, where does the stroke lie with respect...
# [03:53] <dbaron> dirk: it half overlaps the fill
# [03:53] <jdaggett> seems like we need someone to work on a draft proposal
# [03:53] <dbaron> tav: can change the order now
# [03:53] <dbaron> heycam: does webkit-text-stroke paint on top of fill or beneath?
# [03:53] <dbaron> dirk: same as SVG
# [03:53] <jdaggett> i think you want to have inset/outset control
# [03:53] <jdaggett> look to postscript for a good model
# [03:54] * fantasai agrees with jdaggett
# [03:54] <dbaron> tav: most of the time you want fill on top of stroke
# [03:54] <dbaron> fantasai: if you put fill on top of stroke, looks fine when fill is opaque, otherwise looks dumb
# [03:54] <dbaron> fantasai: would also lead to author confusion about stroke width
# [03:54] <dbaron> fantasai: so I agree with jdaggett, should have control over where stroke is centered
# [03:54] <dbaron> dirk: ???
# [03:55] <jdaggett> also, japan has *lots* of examples of double stroking of text
# [03:55] <dbaron> heycam: we have proposal for that
# [03:55] <dbaron> tav: should we put that in?
# [03:55] <dbaron> dirk; we did
# [03:55] <jdaggett> white stroke surrounded by black stroke
# [03:55] <shepazu> +1 to controlling stroke centering
# [03:55] <dbaron> Bert: if you're doing filling of text you might want text-shadow to have inset keyword
# [03:55] <dbaron> fantasai: inset in plans for text level 4
# [03:56] <Zakim> +[IPcaller]
# [03:56] <dbaron> dirk: stroke and fill don't need to overlap... have a new property so they don't need to
# [03:56] <dbaron> heycam: called stroke-position?
# [03:56] <dbaron> heycam: which we have a proposal for, to go in SVG2
# [03:56] <dbaron> fantasai: I think Tab and I can take an action to draw this one up.
# [03:57] * Joins: glenn (~gadams@public.cloak)
# [03:57] * shepazu TabAtkins, maybe when it's time for the text proposal, you could just do g+ hangout with jdaggett and me on your computer?
# [03:57] <Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position
# [03:57] <dbaron> ACTION fantasai with Tab, draw up proposal for using stroke and fill for CSS text
# [03:57] * trackbot is creating a new ACTION.
# [03:57] <trackbot> Created ACTION-562 - With Tab, draw up proposal for using stroke and fill for CSS text [on Elika Etemad - due 2013-06-12].
# [03:57] <glenn> +Present glenn
# [03:58] <fantasai> shepazu, call in
# [03:58] * TabAtkins shepazu It works!
# [03:59] <dbaron> jdaggett: For text stroke and text fill, parameterization could be complication... would like to work through multiple proposals.
# [03:59] * jdaggett yay!
# [03:59] <dbaron> Zakim, mute jdaggett
# [03:59] <Zakim> sorry, dbaron, I do not know which phone connection belongs to jdaggett
# [03:59] * fantasai zakim, who is noisy
# [03:59] * Zakim I don't understand 'who is noisy', fantasai
# [03:59] * fantasai zakim, who is noisy?
# [03:59] * shepazu conf is restricted
# [03:59] <jdaggett> muted
# [03:59] * Zakim fantasai, listening for 10 seconds I heard sound from the following: ??P0 (60%)
# [03:59] * dbaron Zakim, code?
# [03:59] * Zakim saw 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, dbaron
# [04:00] * dbaron Zakim, who is on the phone?
# [04:00] * Zakim sees on the phone: ??P0, [IPcaller]
# [04:00] <dbaron> Zakim, who is noisy?
# [04:00] * shepazu conf must be over, top of the hour :(
# [04:00] <Zakim> dbaron, listening for 12 seconds I heard sound from the following: ??P0 (20%)
# [04:00] * jdaggett i can still hear ...
# [04:00] <dbaron> Zakim, ??P0 is Meeting_Room
# [04:00] <Zakim> +Meeting_Room; got it
# [04:00] * shepazu jdaggett yeah, but I can't join
# [04:00] <dbaron> Zakim, [IPCaller] is jdaggett
# [04:00] <Zakim> +jdaggett; got it
# [04:01] <Zakim> -jdaggett
# [04:01] <Zakim> -Meeting_Room
# [04:01] <Zakim> Team_(css)01:00Z has ended
# [04:01] <Zakim> Attendees were Meeting_Room, jdaggett
# [04:01] * shepazu Zakim, room for 5?
# [04:01] <Zakim> ok, shepazu; conference Team_(css)02:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0301Z
# [04:02] <Zakim> Team_(css)02:01Z has now started
# [04:02] <Zakim> +Doug_Schepers
# [04:02] <Zakim> -Doug_Schepers
# [04:02] <Zakim> +??P0
# [04:02] <dbaron> Zakim, ??P0 is Meeting_Room
# [04:02] <Zakim> +Meeting_Room; got it
# [04:02] <Zakim> +Doug_Schepers
# [04:03] <TabAtkins> Cool, new meeting is working.
# [04:03] * Cyril waves at shepazu
# [04:03] * shepazu jdaggett, please call in now :)
# [04:03] * shepazu waves at Cyril
# [04:03] <Zakim> +[IPcaller]
# [04:03] <dbaron> Zakim, [IPCaller] is jdaggett
# [04:03] <Zakim> +jdaggett; got it
# [04:03] <jdaggett> yup
# [04:03] <jdaggett> that's me
# [04:04] <jdaggett> there's a tv nearby so i have to mute
# [04:04] * dbaron Zakim, who is on the phone?
# [04:04] * Zakim sees on the phone: Meeting_Room, Doug_Schepers, jdaggett
# [04:04] <dbaron> Topic: text wrapping plans for SVG
# [04:04] <dbaron> heycam: so recently in SVG WG meeting yesterday or the day before we discussed how to satisfy requests for wrapping text in SVG, long wanted
# [04:05] <dbaron> heycam: people may remember the proposal in SVG Tiny 1.2, for <textArea>, with text layout different from CSS... objections because different from CSS
# [04:05] <dbaron> heycam: 2 things we want: (1) to do simple rectangular text and (2) text in shapes, which SVG also had a proposal for long ago
# [04:05] <dbaron> heycam: so we want to follow CSS For text in shapes
# [04:05] <Tav> http://tavmjong.free.fr/SVG/TEXT_FLOW/
# [04:05] <dbaron> heycam: and we've been discussing simple discussion for our current text to wrap text to a particular width
# [04:05] <shepazu> simple: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text and more powerful: http://tavmjong.free.fr/SVG/TEXT_FLOW/
# [04:06] <dbaron> heycam: tav will talk about what we need from arbitrary shapes perspective and doug will talk about simple rectangular wrapping
# [04:06] <dbaron> tav: This describes what's in SVG 1.2 flowed text. Partially implemented by Batik and Inkscape
# [04:07] <dbaron> tav: that didn't take -- was complicated and not consistent with CSS
# [04:07] <dbaron> tav: looked at what we can do to keep consistent with CSS.
# [04:07] <dbaron> tav: propose to use shape-inside, shape-outside, wrap-margin, wrap-padding
# [04:07] <dbaron> tav: here's an example, with a shape in an SVG circle
# [04:07] <dbaron> (showing examples from http://tavmjong.free.fr/SVG/TEXT_FLOW/ )
# [04:08] <dbaron> tav: mocked up flowing between shapes (from 1.2 proposal), though told this conflicts with regions from CSS
# [04:08] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [04:08] <dbaron> tav: and here's one with some exclusions
# [04:08] <dbaron> tav: a couple issues, 1 is CSS region seems overkill for our needs
# [04:08] <dbaron> tav: and not close to being finished
# [04:08] <dbaron> stearns: what you want that's different is a comma-separated list of regions?
# [04:09] <dbaron> dirk: so shape-inside and flow to the next shape at the same time
# [04:09] <dbaron> tav: shows example with text flowing from circle to square
# [04:10] <dbaron> stearns: in regions you'd have a list of selectors selecting ...
# [04:10] <dbaron> dirk: he means shapes... he wants shape-inside to have comma-separated lists
# [04:10] <dbaron> Bert: so why does the text go down one and then down the other?
# [04:10] <dbaron> tav: how to do without using CSS regions... if you don't have CSS support? SVG doesn't rely on having CSS.
# [04:11] <dbaron> Jet: and the rest of the words are just clipped?
# [04:11] <dbaron> fantasai: so what happens if someone increases the text size?
# [04:11] <dbaron> tav: just falls off the end
# [04:11] <dbaron> rossen: ... overflow: hidden... on both ...?
# [04:12] <dbaron> tav: next problem we have is SVG doesn't have <br> and <p>, though could probably rely on 'white-space', though maybe not ideal
# [04:12] <dbaron> tav: question is what's the best way to do line breaks and paragraphs
# [04:13] <dbaron> tav: one thing we could do is position text in tspans by having x and y. We'd keep them, but in flowing text you ignore them. But if it doesn't it can serve as fallback for old renderers.
# [04:13] <dbaron> tav: though if renderer doesn't have right font, might be positioning problems, but would be readable
# [04:13] <dbaron> tav: one thing SVG doesn't have is a wrapping context... doug has a proposal
# [04:13] <shepazu> q
# [04:14] * Joins: jet (~junglecode@public.cloak)
# [04:14] <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text
# [04:14] <dbaron> doug: link to my proposal
# [04:14] <dbaron> doug: there's a width and (optionally) height property on svg:text element
# [04:14] <dbaron> doug: and it basically passes in the position established via x and y
# [04:14] <dbaron> dougt: ... and the width, and optionally the height
# [04:14] <dbaron> dougt: ... as the inner box (rendering area), and has CSS engine do text wrapping
# [04:15] <dbaron> doug: cameron has rough prototype
# [04:15] <dbaron> heycam: in local build
# [04:15] <dbaron> s/dougt/doug/g
# [04:15] <dbaron> doug: Cameron was able to implement in a couple of days.
# [04:15] <dbaron> doug: The idea is to treat SVG text like you would a paragraph or text in a div. If it has a width, it wraps to that width. If has a height, clips to that point.
# [04:16] <dbaron> doug: options are allowing scrolling with overflow:scroll, allowing padding/margins. I don't have a strong feeling about padding/margins either way. I think important part is wrappiyng.
# [04:16] <dbaron> doug: But the basic idea is to use the width property on the existing text element to wrap the text.
# [04:16] <dbaron> doug: Advantage to that is that the natural fallback is that the text still appears but is not wrapped; better than not apperaing at all.
# [04:17] <dbaron> heycam: In SVG, when I get to rewriting text chappter, I plan to define non-wrapping text this way:
# [04:17] <dbaron> heycam: SVG currently has x and y attributes to specify positions for character (not glyph!) positions
# [04:17] <dbaron> heycam: we're treating that as a ... for defining CSS layout of the text
# [04:18] <dbaron> heycam: you set up a block that has indefinite width and treat the text element itself as the block and tspans within that as inline,s perform CSS text layout, and then if any glyph positioning, do that as a layer on top ofthe CSS layout.
# [04:18] <dbaron> heycam: so to handle restricting the text to a width would just mean setting that initial block width to that width rather than being exceptionally wide
# [04:18] * Joins: Rossen (~Rossen@public.cloak)
# [04:18] <dbaron> heycam: so purpose of talking about these 2 topics here was to see if you think we're heading of the rails in any particular way, or have any opinions on how better to integrate with CSS stuff
# [04:19] <dbaron> heycam: so we don't work away for months and then have people say it shouldn't be done this way
# [04:19] <dbaron> fantasai: I think this makes sense
# [04:19] <dbaron> fantasai: I have concern about x and y positions and how that works with line breaking
# [04:19] * Quits: sgalineau (~sgalineau@public.cloak) ("Computer has gone to sleep.")
# [04:19] * Rossen wonders how different this is from foreign object in svg?
# [04:19] <dbaron> fantasai: line breaking determined by layout engine and could vary between engines, e.g., fonts, hyphenation engine
# [04:19] <dbaron> fantasai: those glyph thingies probably assume a certain type of wrapping
# [04:20] <dbaron> heycam: in the past without support for auto-wrapped text, people used x and y to manually wrap
# [04:20] <dbaron> heycam: so as tav was describing for text in shapes, where x and y could be fallback positions, we'd do the same thing here for rectangular text, so in this mode x and y would be ignored when wrapping is supported
# [04:20] <dbaron> heycam: doug, did you have different view?
# [04:20] <dbaron> doug: I think variou soptions we could explore.
# [04:21] <dbaron> doug: Key thing is I want CSS WG to understand we're proposing to treat text in SVG much like text in HTML, and use existing CSS text layout engine that browsers already have to do text wrapping.
# [04:21] <dbaron> doug: I think this is simply solved by using what CSS already has, in SVG.
# [04:22] <dbaron> doug: There may have to be tweaks or bits here and there, say text-alignment, alignment-baseline, for certain effects or other things... we'd have to specify that, but would run by CSS WG.
# [04:22] <dbaron> glazou: Also in Mozilla's XUL have to include HTML inside of XUL.
# [04:22] <dbaron> glazou: not specific to SVG and text
# [04:22] <dbaron> rossen: how is this different than foreignObject?
# [04:23] <dbaron> heycam: Was just about to say that I think there's a real desire to not have to resort to having to use foreignObject -- ugly feature syntactically -- for simple cases like rectangular text layout. But foreignObject would still always be there.
# [04:23] <dbaron> heycam: But for simple cases would be nice not to have to escape into HTML world.
# [04:23] <dbaron> dino: Shouldn't say these are simple cases. If you're going to do a CSS block, it should be a CSS island inside SVG with all the CSS properties.
# [04:24] <dbaron> dino: weird, x,y is bottom corner in SVG top corner in CSS
# [04:24] <dbaron> heycam: In my approach, I switched on whether width was specified, and made x,y be top/left when width was specified
# [04:24] <dbaron> heycam: definitely would want to specify it like that, now you're in CSS mode, read over here
# [04:24] <dbaron> tav: in that case fallback doesn't work
# [04:24] <dbaron> dino: I'm not so worried about fallback
# [04:25] <dbaron> dirk: margin/padding has.. (cutoff)
# [04:25] <dbaron> doug: popular libraries like d3.js where people are doing labels
# [04:25] <dbaron> doug: script library that makes SVG diagrams very easy
# [04:25] * Quits: Koji (~Koji@public.cloak) (Ping timeout: 180 seconds)
# [04:25] <dbaron> doug: I talked to several people using d3, people want wrapping text without having to use HTML
# [04:26] <dbaron> doug: for those cases having fallback to older browsers woud be really nice, fall back to one line
# [04:26] <dbaron> doug: this is why I mentioned alignment-baseline
# [04:26] <dbaron> doug: could say whether origin affects glyph cell or character cell, top/left or baseline
# [04:26] <dbaron> doug: dino, I'm fine with saying "this is a CSS block and behaves like one"
# [04:27] <dbaron> doug: whatever's easiest for implementors and authors... authorswould expect padding/argin
# [04:27] <dbaron> dino: then hyphenation, kerning, etc.
# [04:27] <dbaron> heycam: for nonwrapping case we'll just make all CSS properties work on single-line text too
# [04:28] <dbaron> heycam: at least in Firefox (soon) we'll just do CSS layout underneath for text, so easy to let properties just work
# [04:28] <dbaron> dino: so you're suggesting effectively flatten text content of element
# [04:28] <Bert> s/argin/margin/
# [04:28] <dbaron> dino: basically flatten tspan positioning
# [04:28] <dbaron> dino: if I say text width is 100 and inside tspans with x and y... tspans get thrown out
# [04:28] <dbaron> heycam: tspans are effectively spans even in the single line case
# [04:29] <dbaron> doug: part of my idea was actually that in case where you wanted to have a line break, break element, might use tspan with dx and dy
# [04:29] <dbaron> doug: to allow simple breaking in SVG so you didn't have to pull in HTML to do paragraph
# [04:29] <dbaron> doug: obviously lists etc. out of scope
# [04:29] <dbaron> doug: for simple text breaking thought could use tspans for that
# [04:29] <dbaron> dino: should be a single block
# [04:29] * Joins: Koji (~Koji@public.cloak)
# [04:29] <dbaron> dino: if you want >1 block, use HTML
# [04:30] <dbaron> dirk: why not have new element in SVG for anything from HTML world?
# [04:30] <dbaron> heycam: like foreignObject?
# [04:30] <dbaron> dirk: with no <html><body> etc.
# [04:30] <dbaron> dirk: inside this tag you have HTML world
# [04:30] <shepazu> q+
# [04:30] * Zakim sees shepazu on the speaker queue
# [04:31] <fantasai> dbaron: You don't need <html><body> etc. inside <foreignObject>. Do need namespace
# [04:31] <dbaron> dbaron: how much more violent agreement do we need here?
# [04:31] <dbaron> heycam: Just wanted to make CSS WG aware of what we're doing so we can get course corrections; mail to list fine too.
# [04:31] <dbaron> r12a: when you collapse the tspans, how do you separate the last word in the first tspan and the first in the next?
# [04:31] <dbaron> heycam: don't really collapse
# [04:32] <dbaron> dino: meant just ignore x and y attributes and use them as spans
# [04:32] <dbaron> doug: I think these details can be sorted out in spec... don't need to go into them in this meeting.
# [04:32] <dbaron> doug: What I'd like in this meeting is ...
# [04:32] <dbaron> doug: was some concern in SVG F2F that CSS WG might have some objections
# [04:32] <dbaron> dougt: so we wanted to socialize it with CSS WG
# [04:32] <dbaron> s/dougt/doug/
# [04:33] <dbaron> doug: so we wanted to make sure thought a good path forard
# [04:33] <dbaron> doug: don't know if we need a resolution per se
# [04:33] <dbaron> doug: nice to know if this is a reasonable direction
# [04:33] <dbaron> glazou: I think you have that consensus.
# [04:34] <dbaron> Bert: I'm not going to say what SVG should do... but why not just stick with foreignObject?
# [04:34] <dbaron> Tab: You need to give it a height, you can't just flow an amount of text in.
# [04:34] <dbaron> doug: Bert, the answer I've gotten from people doing it every day, people want 1 element rather than 6.
# [04:34] <dbaron> Bert: soon you'll need hyperlinks, hyphenation
# [04:34] <dbaron> various: already have those
# [04:35] <dbaron> doug: if you need anything more complicated, you can use foreignObject
# [04:35] <dbaron> Bert: fine by me, just seems like double-work for half solution
# [04:35] <dbaron> Bert: but no objection
# [04:36] <jdaggett> google japan cafe is yummy!!
# [04:36] <Zakim> -jdaggett
# [04:36] * heycam is now known as heycam|away
# [04:36] <Zakim> -Doug_Schepers
# [04:37] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [04:37] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [04:37] <dbaron> <br class="lunch" data-endtime="13:00">
# [04:38] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [04:38] * Joins: sgalineau (~sgalineau@public.cloak)
# [04:39] * Joins: shige-o (~AndChat474201@public.cloak)
# [04:41] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [04:42] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [04:42] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [04:43] * Joins: AndChat-474201 (~AndChat474201@public.cloak)
# [04:44] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [04:46] * Joins: shige-o (~AndChat474201@public.cloak)
# [04:46] * Quits: AndChat-474201 (~AndChat474201@public.cloak) (Client closed connection)
# [04:47] * Joins: AndChat-474201 (~AndChat474201@public.cloak)
# [04:48] * Quits: jet (~junglecode@public.cloak) (jet)
# [04:49] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [04:53] * Quits: shige-o (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [04:55] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [04:58] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [05:06] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)02:01Z
# [05:06] <Zakim> Team_(css)02:01Z has ended
# [05:06] <Zakim> Attendees were Doug_Schepers, Meeting_Room, jdaggett
# [05:13] * Quits: glazou (~glazou@public.cloak) (glazou)
# [05:21] * Quits: stakagi (~stakagi@public.cloak) (Ping timeout: 180 seconds)
# [05:26] * Joins: Cyril_ (~chatzilla@public.cloak)
# [05:29] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [05:29] * Cyril_ is now known as Cyril
# [05:32] * heycam|away is now known as heycam
# [05:32] * Cyril lunch was great
# [05:39] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:46] * Joins: krit (~krit@public.cloak)
# [05:48] * Joins: glazou (~glazou@public.cloak)
# [05:49] * Joins: Rossen (~Rossen@public.cloak)
# [05:49] * Quits: AndChat-474201 (~AndChat474201@public.cloak) (Client closed connection)
# [05:49] * Joins: shige-o (~AndChat474201@public.cloak)
# [05:49] * Quits: shige-o (~AndChat474201@public.cloak) ("Bye")
# [05:49] * Joins: shige-o (~AndChat474201@public.cloak)
# [05:51] * Joins: shige (~shige@public.cloak)
# [05:52] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [05:55] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [05:57] * Joins: jet (~junglecode@public.cloak)
# [05:59] * Joins: jdovey (~jdovey@public.cloak)
# [05:59] * Joins: stakagi (~stakagi@public.cloak)
# [06:00] <fantasai> Scribe: fantasai
# [06:00] * Joins: myakura (~480ee730@public.cloak)
# [06:01] <fantasai> cabanier: Compositing and Blending Level 1
# [06:01] <fantasai> cabanier: Last year in Hamburg, made a proposal
# [06:01] * Joins: jdaggett (~jdaggett@public.cloak)
# [06:01] <fantasai> cabanier: Since then trying to simplify the spec, to make sure can be implemented easily in browsers
# [06:01] <fantasai> cabanier: Removed compositing in CSS
# [06:01] <fantasai> cabanier: areas, removed that as well
# [06:01] <jerenkrantz> does someone have the latest link for the ED?
# [06:01] <fantasai> cabanier: also knock-out feature removed, because hard to implement
# [06:01] * jdaggett what's the topic?
# [06:02] <cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
# [06:02] * heycam Compositing and Blending
# [06:02] * jdaggett thx
# [06:02] <fantasai> cabanier: Only 3 properties left in CSS:
# [06:02] <fantasai> mix-blend-mode
# [06:02] <fantasai> isolation
# [06:02] <fantasai> background-blend-mode
# [06:03] <fantasai> cabanier: Change to bg blend-mode, only defines how backgrounds blend with each other. Simpler to implement
# [06:03] <fantasai> cabanier: mix-blend-mode also restricted only to things inside its stackign context
# [06:03] <heycam> i/Compositing and Blending Level/Topic: Compositing and Blending
# [06:03] <fantasai> cabanier: Also specs out canvas
# [06:04] <dbaron> q+ to comment on mix-blend-mode
# [06:04] * Zakim sees dbaron on the speaker queue
# [06:04] <dbaron> q+ to comment on background-blend-mode
# [06:04] * Zakim sees dbaron on the speaker queue
# [06:04] <fantasai> cabanier: different blend modes for canvas
# [06:04] <fantasai> cabanier: implemented in FF, webkit
# [06:04] <fantasai> cabanier: patches
# [06:04] <jerenkrantz> what was the URL for that demo?
# [06:04] <fantasai> cabanier shows off demo of canvas and different blend modes
# [06:05] <fantasai> cabanier: If there's ocntent behind this box, won't affect blending with that content
# [06:05] <fantasai> cabanier: Third feature is blending of elements
# [06:05] <fantasai> cabanier: shows some text over an image, with different blend modes
# [06:06] <fantasai> cabanier: Want to know if people are keen
# [06:06] <fantasai> cabanier: mix-blend-mode creates a stacking context
# [06:06] <fantasai> cabanier: and will blend only with things inside its stacking context
# [06:06] <jerenkrantz> Link appears to be: http://codepen.io/adobe/pen/nmfic
# [06:07] <fantasai> dbaron: Part of what I was proposing was creating a stacking context
# [06:07] <fantasai> dbaron: I would need to think more about blending only with things in its stacking context.
# [06:07] <fantasai> dbaron: It's probably okay
# [06:07] <fantasai> cabanier: Talked to roc and ppl on Chrome compositor team
# [06:08] <fantasai> cabanier: roc def ok with this, Chrome team seemed ok with it
# [06:08] <fantasai> dbaron: Other concern was, are there enough use cases for background-blend-mode to justify a separate property
# [06:08] <fantasai> dbaron: Can certainly make some nice demos with it, but how many real author use cases will it work for?
# [06:09] <fantasai> cabanier: If you want a gradient e.g. that goes over an image, or enhance contrast of an image
# [06:09] <fantasai> dino: Question is, why not use tool offline
# [06:09] <fantasai> cabanier: If you want to animate it, hard to do with a tool
# [06:09] <fantasai> dino: One of my concerns is, seems like background-blend-mode will be easiest to implement, and ppl will use backgrounds as content because they want this effect
# [06:10] <fantasai> krit: ...
# [06:10] <fantasai> krit: text blended with background, very strong use cases
# [06:10] <fantasai> krit: moreso in SVG world, because of different shapes
# [06:10] <fantasai> krit: In HTML itself, text is very strong use case
# [06:10] <fantasai> cabanier: They're talking about backgrounds
# [06:10] <fantasai> krit: oh
# [06:10] <fantasai> cabanier: It could be extended later
# [06:11] <fantasai> cabanier: Some people made proposals wrt adding filters on top of it
# [06:11] <fantasai> cabanier: could come in nicely
# [06:11] <fantasai> krit: Filter has filter image functions
# [06:11] <fantasai> krit: This could also be blended
# [06:11] <fantasai> krit: ... isolation group
# [06:11] <fantasai> krit: If you have different background layer, [...]
# [06:11] <fantasai> krit: Filter effects has a filter() function, which takes CSS image as input
# [06:11] <fantasai> krit: And can be animated
# [06:12] <fantasai> krit: You can have different layers in background, some filtered, and can be blended with other layers
# [06:12] <fantasai> cabanier: background-blend-mode is much lighter
# [06:12] <fantasai> cabanier: using mix-blend-mode for this would create lots of layers
# [06:13] <cabanier> http://codepen.io/seraphzz/pen/houAe
# [06:14] <dbaron> dirk: I think we can agree mix-blend-mode is the most important
# [06:14] <fantasai> dino: ... not as powerful or useful. mix-blend-mode is what we really want to expose, but is very powerful and complicated
# [06:15] <fantasai> krit: As specified, no so complicated
# [06:15] <fantasai> dino: With disadvantage that authors have to understand when a stacking context may or may not appear in their content
# [06:15] <fantasai> dino: Expect that rounds down to 0% of authors.
# [06:15] <fantasai> ...
# [06:16] <fantasai> dino: As soon as you hover over a div, that because its opacity changed, blending mode changed
# [06:17] <dbaron> cabanier: we want to be able to do that later, though. And might be able to use new value of 'isolate' property.
# [06:17] <fantasai> krit: I think we agreed that we wanted to have full backdrop blending. But know it's hard to implement at this point
# [06:17] <fantasai> krit: Saying "these properties create an isolation group", don't have to know about stacking contexts
# [06:17] <fantasai> dino; that's handling it in one way
# [06:17] <fantasai> dino: You specify starting blending
# [06:18] <fantasai> ...
# [06:18] <fantasai> dbaron: Disagree with Rik's comment wrt adding ability to blend with opacity later
# [06:18] <fantasai> dbaron: Once you have CSS properties working a certain way, pages depend on things working that way. can't go back and change it later
# [06:18] <fantasai> heycam: Would add a new value to isolation
# [06:19] <dbaron> dbaron: does the new value go on the element being blended or the one making the stacking context?
# [06:19] <dbaron> ?: new value goes on element making the stacking context
# [06:20] <fantasai> dbaron: Kindof ugly
# [06:20] <fantasai> cabanier: Could wait a few years, or have something useful now
# [06:20] <fantasai> heycam: Is it bad to have this new isolation property value on the element that creates the stacking context?
# [06:20] <jerenkrantz> (the seraphzz pen link doesn't seem to work with FF 21; but the adobe link does w/FF 21.)
# [06:20] <fantasai> heycam: Or would you want to specify that where you're putting the blending operation?
# [06:20] <dbaron> dbaron: no, it makes sense that it goes on the element forming the stacking context
# [06:21] <fantasai> dbaron: Think people will probably put * { isolation: new-value; } and not worry about it
# [06:21] <fantasai> cabanier: Not great for performance
# [06:21] <fantasai> cabanier: So, maybe don't want to do that.
# [06:22] <fantasai> dino: Suppose I've got this complicated document
# [06:22] <fantasai> dino: Copy it to another document that has a video in it, suddenly doesn't work
# [06:22] <fantasai> dino: Have document with 3 children, they blend with each other
# [06:22] <fantasai> dino: I set the opacity on the middle one. What about it's children?
# [06:22] <fantasai> cabanier: That's all fine
# [06:22] <fantasai> cabanier: If your parent has opacity, you won't blend with its parent
# [06:25] <fantasai> ...
# [06:25] <fantasai> dino: so, everything blends in its regular order in the document
# [06:25] <fantasai> krit: ... z-index
# [06:25] <fantasai> dino gives example of child with video descendant
# [06:25] <fantasai> ...
# [06:26] <fantasai> dino: It's easy for Core Animation's compositor, can specify blending of child into its parent
# [06:26] <krit> s/... z-index/z-index creates a stacking context and content can not blend with everything beyond it/
# [06:26] <fantasai> dino: But what looks like parent-child relationship in HTML document isn't necessarily that simple in compositor
# [06:26] <fantasai> dino: Example is 3D transforms
# [06:26] <fantasai> dino: ...
# [06:26] <fantasai> dino: Disconnected form your parent, so can't blend into it
# [06:27] <fantasai> cabanier: At some point the 3D object is composited though
# [06:27] <fantasai> dino: You could hit significant perf problems without knowing why
# [06:27] <fantasai> dino: Have to flatten the 3D world
# [06:27] <fantasai> dino: get those bits, etc.
# [06:27] <fantasai> cabanier: it's the same math
# [06:28] <fantasai> ...
# [06:28] <fantasai> dino: [something about not using compositing for web content]????
# [06:29] <fantasai> dbaron: What do you mean by not using compositing?
# [06:29] * fantasai missed the answer
# [06:29] <fantasai> dino: have to manipulate tree heavily to do things like clipping, overflow, scrolling
# [06:30] <fantasai> dino: Compositing has perf benefits with massive complexity
# [06:30] <fantasai> dino: Makes it harder to add useful things like blending
# [06:30] * fantasai can't hear krit
# [06:30] <fantasai> krit says something
# [06:32] <fantasai> dino: If you don't add the feature, people assume it's not there.
# [06:32] <fantasai> dino: For widows and orphans, couldn't implement initial value of 2 because people assumed there was no widow/orphan control
# [06:32] <fantasai> dbaron: I don't think there's been enough review of this to say "yes this is good right now"
# [06:32] <fantasai> cabanier: I would love more reviews
# [06:33] <fantasai> dbaron: Review isn't magical that ppl can just do, there are problems you don't find until you try to implement
# [06:33] <fantasai> dbaron: and others that you don't find until you have two implementations and realize they're not interoperable
# [06:34] <fantasai> dbaron: I'm concerned also about use cases, and if this is addressing things authors really want t do.
# [06:34] <fantasai> dbaron: But don't know how to find out if that's the case.
# [06:34] <fantasai> cabanier: Designers use it all the time in Adobe products
# [06:34] <fantasai> dbaron: Other thing is, there is a trade-off here. Doing it once in Photoshop uses a lot less energy overall than sending it off to everyone's web browser.
# [06:35] <fantasai> cabanier: Not replacing photoshop
# [06:35] <fantasai> cabanier: But better to keep semantics than rasterizing
# [06:35] <fantasai> dbaron: Anything else to discuss?
# [06:35] <fantasai> cabanier: Don't think so
# [06:35] <fantasai> dbaron: No objections now, but def want more time for ppl to look at this.
# [06:35] <fantasai> cabanier: Testing feature behind flags
# [06:36] <fantasai> fantasai: Do we need a new WD?
# [06:37] <fantasai> RESOLVED: Publish WD
# [06:37] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [06:38] * Joins: cabanier (~cabanier@public.cloak)
# [06:38] <fantasai> Topic: min-zoom/max-zoom
# [06:38] <dbaron> Topic: min-zoom/max-zoom media queries
# [06:39] <fantasai> fantasai: Isn't the point of zoom to magnify things?
# [06:39] <fantasai> heycam: Some people using mapping content using SVG
# [06:39] * Quits: jet (~junglecode@public.cloak) (jet)
# [06:39] <fantasai> heycam: want to do some kind of detail control
# [06:39] <fantasai> heycam: Suggested this would be something to handle via Media Queries
# [06:40] <fantasai> heycam: Situation is some iframes, several levels deep, want to know the zoom level of this map tile
# [06:40] <fantasai> heycam: Came back with proposal where you have min-zoom/max-zoom, which is the resulting scale factor from natural size of the thing
# [06:41] <fantasai> heycam: e.g. have SVG image shown at 50% of intrinsic size
# [06:41] <fantasai> Bert, dbaron: resolution/device-pixel-ratio ?
# [06:42] * Joins: jet (~junglecode@public.cloak)
# [06:42] <fantasai> heycam: Does that tell you that inner view is drawn at 4px per 1px of outer view?
# [06:42] <fantasai> dbaron: Wrt device pixels
# [06:42] <fantasai> heycam: ... See if that's what they need
# [06:43] <fantasai> fantasai: it tells you the resolution
# [06:43] <fantasai> fantasai: in device pixels per 'px', or 'in', or whatever
# [06:44] <fantasai> heycam: asks for clarifications
# [06:45] <fantasai> dbaron: It should work. Whether actually works in current implementations, might be a different
# [06:45] * leaverou is now known as leaverou_away
# [06:45] <dbaron> Need to clarify behavior of 'resolution' media queries under transforms, especially if transforms non-axis-aligned
# [06:45] <fantasai> fantasai: I would say, no, transforms don't affect media queries
# [06:46] <dbaron> ...but does viewBox?
# [06:46] <fantasai> dbaron: But resizing due to change in viewbox would
# [06:46] <fantasai> dbaron: I don't know that the spec is clearly enough defined to answer all these questions. Probably should be.
# [06:47] <fantasai> dbaron: As an implementor, just went with "this is reasonable, sort of agrees with other browsers, good enough for ths week". But probably need to sort out this mess.
# [06:47] <dbaron> ... and how it responds to desktop browser zoom, and mobile browser zoom
# [06:47] <fantasai> dbaron: e.g. how does browser zoom ui work, particularly desktop vs. mobile, which have different concepts of zoom
# [06:47] <fantasai> krit: Designers want to have different details depending on zoom level
# [06:47] <dbaron> heycam: so if 'resolution' doesnt account for intermediate transforms, how amenable would you be to having one that does?
# [06:47] <fantasai> ?: animation
# [06:48] <Cyril> s/?: animation/cabanier: what about animations?/
# [06:48] <fantasai> heycam: If what you want to do is to turn on some detailed element at some zoom level, and you're animating the size of the thing, I imagine that's what you'd want to happen
# [06:48] <fantasai> heycam: So maybe I go back to talk about whether resolution should work or not
# [06:48] <fantasai> glazou: David, you said that resolution, same thing
# [06:49] <fantasai> glazou: I think dealing with resolution will be extremely tricky for some Web designer, and dealing with number for min-zoom /max-zoom, would be much easier
# [06:49] <fantasai> heycam: Yeah, author would want to say "here's how content looks at default size; at twice maginification, looks like this"
# [06:50] <fantasai> glazou: Wrt transforms scaling, ok, you can do that, but in simple case of normal web page where user just pinches, want to show control of whether it's zoomed in or not, don't think resolution provides a good solution
# [06:50] <fantasai> glazou: You can't distinguish between iPad Retina and tablet with zooming
# [06:51] <fantasai> dbaron: Mobile browser zoom doesn't affect media queries, whereas desktop does
# [06:51] <fantasai> dbaron: I agree with everything you said, glazou, but I also want to avoid duplication.
# [06:51] <fantasai> dbaron: Think we need to be clear on all these things before adding more to thiem
# [06:51] <fantasai> s/thiem/them/
# [06:51] * dbaron Zakim, room for 4 for 180 minutes?
# [06:51] <Zakim> ok, dbaron; conference Team_(css)04:51Z scheduled with code 26631 (CONF1) for 180 minutes until 0751Z
# [06:52] <Zakim> Team_(css)04:51Z has now started
# [06:52] <Zakim> +[IPcaller]
# [06:53] <fantasai> fantasai: There are basically two types of scaling, graphical and logical.
# [06:53] <jdaggett> zakim, ipcaller is me
# [06:53] <Zakim> +jdaggett; got it
# [06:53] <fantasai> fantasai: Sometimes you're just wnating to magnify what exists. Certain types of UI zoom, and transforms, fall into this category
# [06:53] <fantasai> fantasai: Other times actually changing parameters of layout
# [06:53] <fantasai> fantasai: Need to be clear on which effects go in which category.
# [06:54] * Joins: liam (liam@public.cloak)
# [06:54] <fantasai> glazou: Zooming by user is a user constraint; zooming by author is an author constraint
# [06:54] <fantasai> glazou: First one makes sense for zoom, second for resolution
# [06:54] <Zakim> +??P1
# [06:55] <fantasai> SimonSapin: What I think you mean is, the ration between the intrinsic size of an image and the used size of the image element in the outer document
# [06:55] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [06:55] * Joins: cabanier (~cabanier@public.cloak)
# [06:55] * jdaggett hmm, someone joined the zakim room but can't hear anything...
# [06:56] <shans__> jdaggett: that was me, just setting things up.
# [06:56] * jdaggett ok, cool
# [06:56] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [06:56] <fantasai> SimonSapin: This does not account for transforms
# [06:56] * Joins: cabanier (~cabanier@public.cloak)
# [06:57] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [06:57] * Joins: cabanier (~cabanier@public.cloak)
# [06:57] * Quits: dino (~dino@public.cloak) (dino)
# [06:57] <fantasai> dbaron: Might need another editor of MQ 4
# [06:57] <fantasai> glazou: Florian is very busy right now, will have more time in a few months
# [06:57] <fantasai> dbaron: Two big categories of changes
# [06:57] <fantasai> dbaron: that need to happen
# [06:57] <fantasai> dbaron: We talked very briefly of doing syntax changes
# [06:58] <fantasai> dbaron: To be closer to @supports
# [06:58] <fantasai> dbaron: Other was adding queries to represent everything in media types, deprecating media types
# [06:58] <fantasai> dbaron: But those ar ebiger things
# [06:58] <krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#the-clip-path
# [06:59] <fantasai> s/ar ebiger/are bigger/
# [06:59] * dbaron Zakim, ??P1 is Meeting_Room
# [06:59] * Zakim +Meeting_Room; got it
# [07:00] <fantasai> krit: Security question wrt basic shape
# [07:00] <fantasai> krit: Can use CSS shapes to define a clipping area
# [07:00] <fantasai> krit: Here's an image, can define a clip path on it.
# [07:00] <fantasai> krit: Can also be animated
# [07:00] <fantasai> krit: Quite easy to apply this clip path
# [07:00] <fantasai> krit: Problem is the following
# [07:00] <fantasai> krit: Usually you have clip-path inline in your style sheet
# [07:01] <fantasai> krit: Can also cross-reference path from a different domain
# [07:01] <fantasai> krit: Suppose, e.g. style sheet on mybank.com
# [07:01] <fantasai> krit: evil.com tries to reference it
# [07:01] <fantasai> krit: question is, can any private data come from this style sheet
# [07:01] <fantasai> krit: ... pointer events
# [07:02] <fantasai> krit: If you cliip to circle, outside that doesn't contribute to clipping area
# [07:02] <fantasai> krit: Suppose one domain uses clip path to show password or something
# [07:02] <fantasai> krit: If you clip anything with this letter here, then the areas outside it don't contribut to hit testing
# [07:02] <fantasai> krit: So could scan the clipping path and reingineer what the clip-path could look like
# [07:03] <fantasai> dbaron: I think anyone using clip-path to use confidential data is doing it wrong.
# [07:03] <fantasai> dbaron: If that's the attack, I'm not that worred about it!
# [07:03] <fantasai> dbaron: I would be more worried about an attack that involved treating other data as pieces of a CSS style sheet
# [07:03] <fantasai> dbaron: e.g. send someone an email message with some CSS in the subject
# [07:04] <fantasai> dbaron: And then closing equivalent to that in another message
# [07:04] <fantasai> dbaron: Could retrieve all the subjects in between by requesting a particular URL from Yahoo.
# [07:04] <fantasai> dbaron: That I'd be worried about
# [07:04] <fantasai> dbaron: But this I'm not worried about
# [07:05] <fantasai> glazou: I'm not that worried...
# [07:05] <fantasai> Alan asks about some other shape image thing
# [07:06] <fantasai> krit: Very weird case. Only one I could come up with as an issue
# [07:06] <fantasai> heycam: What if you had a style sheet that just had content property, did hit testing on content
# [07:06] <fantasai> krit: That would be a bigger security issue.
# [07:07] <fantasai> fantasai: Putting sensitive data in a style sheet's content property also makes no sense at all.
# [07:09] <fantasai> heycam discusses other ways of exposing things in the same way
# [07:09] * Joins: lmclister (~lmclister@public.cloak)
# [07:09] <fantasai> s/ways of/properties/
# [07:09] * Quits: Kazutaka (~Kazutaka@public.cloak) (Ping timeout: 180 seconds)
# [07:09] <fantasai> ...
# [07:10] <fantasai> krit: If we agree this is a security problem, then our options are to remove [...]
# [07:10] <heycam> My point is if you can show that you can already get some information by testing an element styled by a style sheet from another domain -- e.g. the content property -- then it's fine to have shapes in clip-path, since it's not opening the hole any further.
# [07:10] <fantasai> dbaron: I think we pretty much agree that it's not a security problem we want to fix.
# [07:10] <fantasai> dbaron: We could put a note in the spec, that authors shouldn't put sensitive info in clip path
# [07:10] <dbaron> (unless there's a worse case that we haven't heard yet)
# [07:11] <fantasai> Alan, heycam: Don't think this is an issue
# [07:11] <heycam> s/heycam/dino/
# [07:12] <fantasai> Bert: Position div for each pixel of your password
# [07:12] <dbaron> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0012.html
# [07:12] <fantasai> dino: I don't know why we're even discussing this.
# [07:12] <fantasai> Bert: Good to discuss, but I think we can conclude that this is a weird case we don't need to worry about
# [07:12] <fantasai> RESOLVED: We don't care, unless bz can come up with something more convincing
# [07:13] <fantasai> Topic: SVG text-wrapping
# [07:14] <fantasai> tav: Things we would most need from Exclusions and Shapes have been removed from latest drafts
# [07:14] <fantasai> tav: shape-inside
# [07:14] <fantasai> tav: And using SVG paths and shapes
# [07:14] <fantasai> Alan: My plan for that is to have that in next level of CSS Shapes
# [07:14] <fantasai> Alan: I'm trying to constrain first level of spec ot stuff that is most immediately useful to CSS at the moment
# [07:15] <fantasai> Alan: I don't think there's an issue with having your SVG work depend on Shapes level 2 instead of Shapes level 1
# [07:15] <fantasai> glazou: Problem is referencing a non-normative document
# [07:16] * Parts: krit (~krit@public.cloak) (krit)
# [07:16] <fantasai> glazou: Discusison in AC forum, W3C suggested references can only be W3C RECs. Document referencing WD can't go to REC
# [07:16] * Joins: krit (~krit@public.cloak)
# [07:16] <fantasai> plh: But can go to PR. Just can't go to REC.
# [07:16] <fantasai> fantasai: I don't think this will be an issue
# [07:17] <fantasai> plh: For the record, Robin Berjon started a thread on chairs list wrt dependencies
# [07:17] <fantasai> Alan: Noted, haven't created L2 document yet
# [07:17] * Quits: nikos (~Thunderbird@public.cloak) (nikos)
# [07:17] <fantasai> Alan: question of whether to make L2 doc to park these things in
# [07:18] <fantasai> TabAtkins: Make ssense. Just put <details class=obsolete> and note things
# [07:18] <dbaron> So I think Boris's concerns in that thread are actually somewhat different from that contrived bank case.
# [07:18] <fantasai> TabAtkins: Maybe I'll rename the class
# [07:18] <dbaron> maybe more like http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0008.html
# [07:19] <fantasai> Topic: security
# [07:19] <fantasai> dbaron: Involves using clip-path on attacker site over <iframe> to victime site.
# [07:20] <fantasai> dbaron: That's more concerning.
# [07:20] <fantasai> dbaron: But not useful to discuss here.
# [07:20] <fantasai> dino: How is it more of a problem than overflow?
# [07:20] <fantasai> dbaron: Not different.
# [07:20] <dbaron> message from roc: http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html
# [07:20] <fantasai> krit: [stuff]
# [07:21] <fantasai> dbaron: The attack I described wasn't what bz described
# [07:21] <fantasai> dbaron: This is stuff that needs to be thought about longer. We should be fine, I think.
# [07:22] <dbaron> ... since bz was describing something that would be fixed by rejecting clip-path for cross-origin non-CORS style sheets
# [07:22] <fantasai> heycam: been awhile since roc's message. should someone look at that?
# [07:22] <dbaron> which the attack of a site that controls a site's cross-origin style sheet and can simultaneously frame it doesn't cover
# [07:22] <dbaron> s/doesn't cover/isn't fixed by/
# [07:23] <fantasai> Topic: Figuring out the CSSWG agenda
# [07:24] <glazou> http://wiki.csswg.org/planning/tokyo-2013?&#agenda
# [07:24] * Joins: r12a (rishida@public.cloak)
# [07:24] <krit> s/[stuff]/Boris is referencing a mail of roc. The problem that roc's describing has to do with feDisplacementMap that is based on pixel displacement by color value. In combination with the current defintion of 'pointer-events', it can influence hit testing in a way that it can be used to reveal privacy data./
# [07:26] * jdaggett let the minutes record much mubbling
# [07:26] * plh and part of it was french mubbling :)
# [07:27] * Parts: krit (~krit@public.cloak) (krit)
# [07:27] * Joins: krit (~krit@public.cloak)
# [07:29] * heycam would like to be here for Conditional Rules, Cascade, Variables -- so before Thursday afternoon
# [07:34] * Joins: shige_ (~shige@public.cloak)
# [07:36] * jdaggett runs out for a sec to pee...
# [07:36] * jdaggett is now known as jdaggett|pee
# [07:39] * Quits: shige (~shige@public.cloak) (Ping timeout: 180 seconds)
# [07:40] * TabAtkins tmi, jdaggett
# [07:40] * jdaggett|pee is now known as jdaggett
# [07:43] * liam pleased to be able to follow the meeting in so much detail? :-)
# [07:43] <r12a> http://www.w3.org/International/docs/counter-styles/Overview.html
# [07:44] <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/
# [07:44] <dbaron> there's one issue listed in http://dev.w3.org/csswg/css-counter-styles-3/#ethiopic-numeric-counter-style
# [07:45] <dbaron> Topic(a few lines back): Counter Styles
# [07:46] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [07:47] <myakura> r12a, I see some Japanese counter styles in the Hebrew section... http://www.w3.org/International/docs/counter-styles/Overview.html#hebrew-styles
# [07:47] <fantasai> Discussion of whether to publish Counter Styles as LC
# [07:47] <dbaron> want to link to r12a's document, which is to be published as a note
# [07:48] <fantasai> Richard posts the i18n note wrt @counter-style rules for various scripts
# [07:48] <dbaron> glazou: should we give people a few weeks to review
# [07:48] <dbaron> fantasai: we already did that
# [07:48] <dbaron> I'm fine with going to LC, though I'm really not sure how high of an implementation priority this is for anyone.
# [07:49] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0757.html
# [07:49] <dbaron> ... css-counter-styles-3 to Last Call, ask for review from HTML, i18n, ... oh, wait, we resolved to go to LC last week
# [07:50] * fantasai was on break most of last week
# [07:50] <TabAtkins> http://dev.w3.org/csswg/css-cascade/#cascade
# [07:51] <fantasai> ScribeNick: fantasai
# [07:51] <fantasai> TabAtkins: This is in section describing how levels of things are handled
# [07:51] <fantasai> TabAtkins: We inserted Scope in the middle here
# [07:51] <fantasai> TabAtkins: Scoped style sheets always win over unscoped styles
# [07:51] <fantasai> TabAtkins: Scoping something further down in the document overrides coping rules further up i nthe document
# [07:52] <fantasai> TabAtkins: Question is , does this sound sufficient for a spec defining this?
# [07:52] <fantasai> TabAtkins: Think it is correct
# [07:52] <fantasai> fantasai: By default, inner scopes win over outer scopes
# [07:52] <fantasai> fantasai: But for !important rules, order is reversed
# [07:52] * Joins: Rossen (~Rossen@public.cloak)
# [07:53] <fantasai> fantasai: Outer !important rules override inner !important
# [07:54] <fantasai> dbaron: Other alternative is for inner !important to win over outer !important
# [07:54] <fantasai> heycam: I think the current spec is a nice parallel with how origins work
# [07:55] <fantasai> fantasai: I think this gives !important a useful purpose in negotiating rules between inner and outer scopes
# [07:55] <fantasai> fantasai: So somewhat prefer this behavior
# [07:55] <fantasai> TabAtkins: Seems from heycam that the spec is clear enough
# [07:56] <fantasai> Bert: Why have scopes be special, why not have it same as ID selector
# [07:56] <fantasai> glazou: I proposed that several times, was turned down
# [07:56] <fantasai> dbaron: Not the same is because you want rule in inner scope to beat rules in outer scope, and if you treat them as both +ID, they will intermingle
# [07:57] <fantasai> Bert: That's what I expect
# [07:57] <fantasai> dbaron: That's not what authors expect
# [07:57] <fantasai> TabAtkins: Point is that scoped rules apply only to your bit, and can have short, simple selectors
# [07:57] <fantasai> TabAtkins: Lends itself to lower-specificity selectors
# [07:57] <fantasai> TabAtkins: Rules that apply to whole document tend to be more verbose, more specific
# [07:58] <fantasai> TabAtkins: Want the simpler scoped rules to still override document-wide, more-specific rules
# [07:58] <fantasai> Bert: But adding new concept
# [07:58] <fantasai> glazou: It's equivalent to adding a 4th argument to specificity
# [07:59] <fantasai> s/equivalent/similar/
# [07:59] <fantasai> Bert: span.foo { blue } vs. scoped span { green }
# [07:59] <fantasai> Bert: Expect <span.foo> to be blue, not gree.
# [07:59] <fantasai> dbaron: Expect it to be green
# [07:59] <fantasai> s/gree/green/
# [08:00] * dbaron supposes we shouldn't have gotten into this discussion
# [08:00] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [08:00] * TabAtkins Indeed.
# [08:01] <fantasai> glazou: Last time we discussed this, the painful bit was only adding dynamically adding styles [?]
# [08:01] <fantasai> TabAtkins: From author feedback over long period of time, because specifying things defined in HTML for awhile, this was the most intuitive behavior for authors
# [08:01] <fantasai> plh: Not implemented though, so haven't played with it.
# [08:03] <fantasai> RESOLVED: Close issue on how !important interplays with scoped styles
# [08:03] <glazou> <br type="break"/>
# [08:04] * Quits: stakagi (~stakagi@public.cloak) (Client closed connection)
# [08:07] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [08:13] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [08:13] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [08:14] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [08:17] * Cyril noted a typo in the introduction of CSS Cascade level 3 "try to set a the value"
# [08:22] * Joins: tobie (tobie@public.cloak)
# [08:23] <TabAtkins> Cyril: Thanks!
# [08:27] <fantasai> jdaggett, plinss, r12a won't be here tomorrow afternoon, so maybe move charter/font-loading/principles to afternoon, and pull CSS3 Text/Text-Decoration forward into the morning?
# [08:28] <jdaggett> fantasai: i actually don't think we'll be able to deal with fonts/text/text-decoration all in the morning
# [08:28] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [08:28] <jdaggett> fantasai: guess we can try though
# [08:29] <fantasai> TabAtkins: Continuing with 'default' keyword
# [08:29] <jdaggett> reference url?
# [08:30] <jerenkrantz> http://dev.w3.org/csswg/css-cascade/#default
# [08:30] <fantasai> dbaron: I had initially proposed default as something else, as initial/inherit. Still would like that behavior.
# [08:30] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [08:31] <fantasai> TabAtkins: The reason I don't want to do that, doesn't do what authors want
# [08:31] <Zakim> -Meeting_Room
# [08:31] <jdaggett> um, phone dropped
# [08:31] * Joins: myakura (~480ee730@public.cloak)
# [08:32] <jdaggett> shans__: ^
# [08:32] <fantasai> TabAtkins: E.g. want "default" to mean "display: block/inline" depending on whether <p> or <span>
# [08:32] <dbaron> jdaggett, ack
# [08:32] * Quits: birtles (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [08:32] <fantasai> dbaron: Not always. E.g. reset stylesheets want my behavior
# [08:32] <dbaron> jdaggett, apparently it's because shane left
# [08:32] <fantasai> TabAtkins: Don't think we need to cater to reset style sheets
# [08:32] <jdaggett> dbaron: you guys dropped off the call!!
# [08:32] <jdaggett> ah
# [08:32] * Joins: Rossen (~Rossen@public.cloak)
# [08:32] * Joins: nikos (~Thunderbird@public.cloak)
# [08:32] <dbaron> jdaggett, apparently it requires a computer that can get on the corp network, which tab's can't
# [08:32] <fantasai> fantasai: Could add special ability to 'all' shorthand
# [08:32] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'
# [08:33] * TabAtkins jdaggett, just a sec, we need to find Shane again.
# [08:33] * jdaggett heh, that low-security tab...
# [08:33] * jdaggett ok
# [08:33] <fantasai> dbaron: The other issue with this definition of default is that it's a decent amount of work to implement
# [08:33] <fantasai> TabAtkins: Won't disagree with that
# [08:33] <fantasai> SimonSapin: Think it requires keeping around multiple specified values
# [08:34] * Quits: shige_ (~shige@public.cloak) (Ping timeout: 180 seconds)
# [08:34] * Joins: shans___ (~shans@public.cloak)
# [08:34] <fantasai> TabAtkins: Don't have to keep things around, just might need multiple passes, and just for elements it shows up on
# [08:34] <fantasai> SimonSapin: Isn't that similar perf cost with variables?
# [08:34] <shans___> what is the zakim bridge conference id?
# [08:34] <fantasai> dbaron: It can be done without that perf cost
# [08:34] <jdaggett> 26631
# [08:35] * Quits: shige-o (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [08:35] <dbaron> "This passcode is not valid."
# [08:35] <plinss> zakim, code?
# [08:35] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss
# [08:35] <shans___> need a new one
# [08:36] <Zakim> -jdaggett
# [08:36] <Zakim> Team_(css)04:51Z has ended
# [08:36] <Zakim> Attendees were jdaggett, Meeting_Room
# [08:36] <dbaron> Zakim, room for 5 for 150 minutes?
# [08:36] <Zakim> ok, dbaron; conference Team_(css)06:36Z scheduled with code 26632 (CONF2) for 150 minutes until 0906Z
# [08:36] <dbaron> shans___, ^
# [08:36] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [08:36] <Zakim> Team_(css)06:36Z has now started
# [08:37] <Zakim> +[IPcaller]
# [08:37] <jdaggett> zakim, ipcaller is me
# [08:37] <Zakim> +jdaggett; got it
# [08:37] * dbaron Zakim, [IPcaller] is jdaggett
# [08:37] * Zakim sorry, dbaron, I do not recognize a party named '[IPcaller]'
# [08:37] * jdaggett zakim, i do so love your fickle ways
# [08:37] * Zakim I don't understand 'i do so love your fickle ways', jdaggett
# [08:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:37] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:37] <dbaron> "This passcode is not valid."
# [08:38] <Zakim> +??P1
# [08:38] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:38] <dbaron> Zakim, ??P1 is Meeting_Room
# [08:38] <Zakim> +Meeting_Room; got it
# [08:38] <jdaggett> ok, good good
# [08:38] <jdaggett> yes
# [08:38] <jdaggett> default was the topic...?
# [08:39] <jerenkrantz> jdaggett: yes
# [08:39] <fantasai> TabAtkins: I don't really want initial-or-inherit. No use case for it
# [08:39] <glazou> jdaggett, yes
# [08:39] <fantasai> dbaron: Use it internally a lot
# [08:39] <fantasai> dbaron: e.g. Web Components style reset
# [08:39] <fantasai> dbaron: Think that basically is equivalent to all:initial-or-inherit
# [08:40] <fantasai> TabAtkins: Given that those don't have any UA style rules anyway... I think that's equivalent to 'default'
# [08:41] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:41] <fantasai> heycam: want s/continues/repeats/ ?
# [08:41] <fantasai> TabAtkins clarifies what default does
# [08:42] <fantasai> ACTION TabAtkins clarify what default does
# [08:42] * trackbot is creating a new ACTION.
# [08:42] <trackbot> Error finding 'TabAtkins'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
# [08:42] <Zakim> -jdaggett
# [08:43] <fantasai> dbaron: Putting !important and normal together makes it harder to implement
# [08:44] <jdaggett> argh, back in a sec
# [08:44] <fantasai> dbaron: Implementation I would take would do the wrong thing for user !important and ua !important
# [08:45] <fantasai> dbaron: Current spec, user !important rule says go use the author styles
# [08:45] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:45] <fantasai> dbaron: But if no author styles, don't use user styles
# [08:45] <fantasai> TabAtkins: No, no, we only glom together all the author styles.
# [08:45] <fantasai> TabAtkins: You still keep user as an origin level
# [08:46] <Zakim> +[IPcaller]
# [08:46] <jdaggett> zakim, ipcaller is me
# [08:46] <Zakim> +jdaggett; got it
# [08:46] <fantasai> dbaron: Ok, that's fine
# [08:46] <fantasai> dbaron: But make it clearer
# [08:47] <fantasai> fantasai: We could put in a simplified cascade list, just to make it more obvious
# [08:47] <fantasai> fantasai: Any other concerns with default?
# [08:47] <fantasai> fantasai: Do we want an initial-or-inherit keyword?
# [08:48] <fantasai> TabAtkins: I suggest using actually 'initial-or-inherit'. Want to steer authors to 'default', since that's usually the right answer.
# [08:48] * Cyril the sentence "Declaring a shorthand property to be ‘!important’ is equivalent to declaring all of its sub-properties to be "!important"." is duplicated in the current text
# [08:48] <fantasai> dbaron: Would like to see a keyword for that
# [08:48] <fantasai> Bert: Would like to understand better what this is used for
# [08:49] <fantasai> TabAtkins: You use it in most use cases for dbaron's examples, except this is the better answer in most cases
# [08:50] <fantasai> TabAtkins: For a use case, sometimes it's much easier to create positive selectors than :not() selectors, and wipe out what you had before
# [08:50] <fantasai> TabAtkins: Point is to wipe out whatever author has done
# [08:50] <fantasai> TabAtkins: This is better because it respects user styles
# [08:50] <fantasai> TabAtkins: And UA styles
# [08:51] <fantasai> TabAtkins: Most authors don't understand difference between initial value and UA default value
# [08:51] <fantasai> TabAtkins: This lets you not worry about that
# [08:51] * Joins: shige-o (~AndChat474201@public.cloak)
# [08:51] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Client closed connection)
# [08:52] <fantasai> ...
# [08:53] <fantasai> plinss: This removes your rules.
# [08:53] <fantasai> TabAtkins: Not sure whta you're objecting to, what you're asking for is exactly what this does.
# [08:53] <fantasai> Bert: You said it's easy to specify a generic rule, and override a specific case
# [08:54] <fantasai> Bert: span { color: green; } span.foo { color: default; }
# [08:54] <fantasai> Bert: Then I get inherited
# [08:54] <fantasai> TabAtkins: That's what you get, unless user or UA says something
# [08:54] <fantasai> TabAtkins: Let me show different example
# [08:54] <fantasai> TabAtkins: User says wants links are bright blue
# [08:55] <fantasai> TabAtkins: Author styles links purple, except some links with class should use default colors
# [08:55] <fantasai> TabAtkins: If you use 'initial' or 'inherit' to wipe out author rules, the colors will reset to black.
# [08:55] <fantasai> TabAtkins: Doesn't go back to blue.
# [08:55] <fantasai> Bert: Why would I want user's rule
# [08:55] <fantasai> Bert: I don't know what they are
# [08:55] <fantasai> plinss: That's the point
# [08:56] <fantasai> TabAtkins: This goes back to "whatever style would be without my influence"
# [08:56] * Joins: stakagi (~stakagi@public.cloak)
# [08:57] <fantasai> Bert: Think examples would be good
# [08:58] <fantasai> fantasai: Better example would be paragraphs. By default, have 1em margin on top and bottom.
# [08:58] <fantasai> fantasai: If I styling thing, and want to go back to the default styling, would ask for 'default'. Gets ack to 1em margin.
# [08:59] <fantasai> fantasai: If said 'initial', then would set margins to zero.
# [08:59] <fantasai> Bert: i'm not convinced, but if you can get some examples in there, would help
# [08:59] <fantasai> leaverou_away, Can you help here?
# [09:00] <fantasai> RESOLVED: Ok with current definition of 'default', remove issue
# [09:00] <fantasai> but also clarify the spec and add examples
# [09:01] <fantasai> fantasai: Suggest inherit-or-initial
# [09:01] <fantasai> plinss: reset?
# [09:02] <fantasai> TabAtkins: Want it to be long an annoying
# [09:03] <Cyril> q+
# [09:03] * Zakim sees Cyril on the speaker queue
# [09:03] <fantasai> TabAtkins: Using 'default' for this because already reserved, and does more or less what was intended for that value.
# [09:04] * Bert : plinss, glazou, if you're adding the e-book/i18n workshop to the agenda, can it be on Fri PM? Shigeo Okamoto is interested in the topic, but can only come back on Fri PM.
# [09:04] <fantasai> Cyril: Question wrt inheritance
# [09:04] <fantasai> Cyril: First paragraph, 2nd sentence
# [09:05] <glazou> Bert, ok but unsure at this time
# [09:05] <fantasai> [... wordsmithing ...]
# [09:06] <dbaron> "unless the cascade results in a value" -> "when the cascade does not result in a value"
# [09:07] <Cyril> ack
# [09:07] <fantasai> Topic: Cascading of Transitions and Animations
# [09:08] <stearns> http://dev.w3.org/csswg/css-cascade/#cascade
# [09:08] <fantasai> TabAtkins: Order in css3-cascade matches Gecko behavior. Apparently WebKit's behavior can't be explained in terms of cascade
# [09:08] <dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
# [09:08] * Joins: dino (~dino@public.cloak)
# [09:08] * heycam http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html
# [09:08] <fantasai> dbaron: There were pieces of each behavior that was considered crazy and unimplementable
# [09:09] <fantasai> dbaron: Made progress towards acceptable behavior for this during special meeting
# [09:09] <fantasai> dbaron: Wrote up in this message, which I have long since forgotten
# [09:09] <fantasai> dbaron: This message actually has transitions at a different point in the cascade, but agrees with cascade wrt animations
# [09:10] <fantasai> fantasai: Does this mean that you can never transition !important values/
# [09:10] <fantasai> dbaron: It means that if you change something to !important, it will not transition
# [09:10] <fantasai> dbaron: But if you change something from !important, might get a transition
# [09:11] <fantasai> fantasai: What if both are !important?
# [09:11] <fantasai> dbaron: No transition
# [09:11] <fantasai> fantasai: Don't like that.
# [09:12] <fantasai> dbaron: We all agreed that we want animations to override transitions, and that we want !important to override animations, and
# [09:13] <fantasai> dbaron: now proposing that transitions override !important rules
# [09:13] <fantasai> plinss: I think in Lyon we talked about animations not causing transitions
# [09:14] <fantasai> shane: I don't think we're asking that transitions override !important, just that they be able to transition
# [09:14] * leaverou_away is now known as leaverou
# [09:15] <fantasai> fantasai: Think animations win over transitions because the two rules transitioning are lower
# [09:15] <SimonSapin> http://w3cmemes.tumblr.com/post/34634329920/csswg-resolves-to-use-less-magic
# [09:15] <fantasai> dbaron: Could introduce some magic
# [09:15] <jdaggett> oh gawd, dbaron and fantasai and magic....
# [09:15] <fantasai> dbaron: Could say that if you have an animation running, any transition rules for that property don't apply
# [09:15] <fantasai> dbaron: Not sure that works, because we have to consider inheriting properties
# [09:16] <fantasai> dino: I think in our discussion we got to that point and then gave up
# [09:16] <fantasai> dbaron: Gave up on starting transitions
# [09:16] <fantasai> TabAtkins: What is the inheritance problem? I shtat #3?
# [09:16] <fantasai> s/shtat/that/
# [09:16] <fantasai> dbaron: Say you have animations/transitions on color
# [09:17] <fantasai> dbaron: Have a currently running transition on the child, and start an animation on the parent
# [09:17] <fantasai> dbaron: nevermind
# [09:17] <fantasai> dbaron: Nothing in the cascade will help there; you just lose
# [09:17] <fantasai> dbaron: transition will keep running on child, we're ok with that?
# [09:18] <fantasai> TabAtkins: The effects of animations can never cause a transition, including inherited effects of animations
# [09:18] <fantasai> plinss: Could ahve set value of child, that gets unset,
# [09:18] <fantasai> plinss: And then goes back to inherited, but that value is animating
# [09:18] <fantasai> dino: Bad example was parent and child with transition set up for color
# [09:18] <fantasai> dino: But child has color inherit
# [09:19] <fantasai> dino: You transition parent. What happens to child? When does its transition start?
# [09:19] <fantasai> dbaron: What my proposal does for plinss's question...
# [09:19] * Joins: birtles (~chatzilla@public.cloak)
# [09:19] <fantasai> dbaron: What the model I proposed does, if you have an override on the child that you remove such that you now inherit an animating value from the parent
# [09:20] <fantasai> dbaron: This wouldn't produce a great result, would cause transition to go to animating value at the time the transition started, and when completed, would jump to wherever it would be
# [09:21] <fantasai> dbaron: Model I was proposing is that mechanism by which we prevent animations from triggering transitions, when you decide whether to transition you look at animations as they are at the current time
# [09:21] <fantasai> dbaron: So never comparing to animation at a different time
# [09:21] * Joins: r12a (rishida@public.cloak)
# [09:21] <fantasai> dbaron: So when there is a style change that is not animation-triggered, you need to get your animation style up-to-date first, before figuring out whether to start transitions
# [09:21] <fantasai> dbaron: And that was a defined way of describing interaction between the two.
# [09:21] <fantasai> fantasai: Have a question, may or may not make sense.
# [09:22] <fantasai> fantasai: would it work to sovle the things we want
# [09:22] <fantasai> fantasai: if we went with the cascade that's in gecko
# [09:22] <fantasai> fantasai: But said that a transition never starts if the start state or the end state is an animation
# [09:22] <fantasai> TabAtkins: Or is produced by an animation via inheritance.
# [09:22] <fantasai> dbaron: Produced by animation via inheritance, say you have font-size animating, and width in em units
# [09:23] <fantasai> dbaron: Tracking what's caused by an animation is very complex
# [09:23] <jerenkrantz> RRSAgent: make minutes
# [09:23] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/05-css-minutes.html jerenkrantz
# [09:23] <fantasai> plinss: Thing about this that bothers me
# [09:23] <fantasai> plinss: Talking about a lot of edge cases, cause lots of discontiguous jumps when animations/transitions applied
# [09:24] <fantasai> plinss: Understand some implementations may not be able to avoid jumps
# [09:24] <fantasai> plinss: But certainly don't want to require them
# [09:24] <fantasai> plinss: [...?]
# [09:24] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [09:24] <fantasai> dbaron: One concern wrt that kind of thing, we tend to as a group want to gradually narrow possibilities
# [09:24] * Joins: shige-o (~AndChat474201@public.cloak)
# [09:25] <fantasai> dbaron: But some of those gradual changes might trigger a rewrite in certain implementations
# [09:25] <fantasai> plinss: Then get it right the first time
# [09:25] <fantasai> dbaron: Need a description of what the right behavior is
# [09:26] <fantasai> plinss: Transitions should always be smooth
# [09:26] <fantasai> dbaron: start value and end value for transition
# [09:26] <fantasai> dbaron: Are you ok with start value is always static, but end value might be animating
# [09:26] <fantasai> fantasai: ?
# [09:26] <fantasai> TabAtkins: Start state is something specific, end state is inherit
# [09:27] <fantasai> TabAtkins: Parent was running a thing, and now inheriting animated value, so transitioning towards moving target
# [09:27] <fantasai> TabAtkins: Are we ok with tranistioning towards a moving target
# [09:27] <fantasai> dino describes WebKit's behavior, which is bad, which chains transitions together
# [09:29] * fantasai q+ to ask about #5 and em units
# [09:29] * Zakim sees Cyril, fantasai on the speaker queue
# [09:29] <fantasai> [discussion of this bug]
# [09:31] <dbaron> you may recall http://lists.w3.org/Archives/Public/www-archive/2013Jun/att-0030/x2_10c92e9a.jpeg from Tucson
# [09:32] <fantasai> TabAtkins: I think I'd be ok with either dbaron's model where inherited animation or transition values don't kick off new transitions on the child, but do move endpoint of running transition
# [09:33] <fantasai> TabAtkins: Or, I guess proper implementation of Dean's model, where they do continually kick off transitions, but values are only 1 frame apart in transition, so transition end won't be detectable
# [09:33] <fantasai> dbaron: It's detectable due to TransitionEnd events
# [09:33] <fantasai> Rossen: What you see as a user, you'll see color transition from green to blue (looking at point 7) over 2s
# [09:34] <fantasai> Rossen: then detransitioning from blue to green over 10s
# [09:34] <fantasai> ...
# [09:35] <fantasai> Rossen: so proposal was for #a and #b t transition over 2 and 10 s, respectively
# [09:36] * fantasai lost example explanation
# [09:36] <fantasai> plinss: Would argue from user's perspective, bheavior that user expects is that #b will transition from green to blue over 10s
# [09:36] <fantasai> plinss: at the same time #a is transitioning over 2s
# [09:36] <fantasai> dbaron: There's another problem
# [09:37] <fantasai> dbaron: I think user expectation is that whichver time is longer wins
# [09:37] <fantasai> dbaron: If you swap the times, especially when one is unnoticeable
# [09:37] <fantasai> plinss: I think if you swap the times, user will expect #a to transition over 10s and #b over 2s
# [09:37] <fantasai> plinss: IMO #b's behavior should not change based on whether #a has a transition or not
# [09:38] <fantasai> dbaron: Other way to frame problem, don't want a discontinuity between no transition at all vs. very short transition (e.g. 10ms), that lasts longer than 10ms
# [09:39] <fantasai> rossen: Transitioning independently
# [09:39] <fantasai> dbaron: What if you swap times and put longer time outside?
# [09:39] <fantasai> plinss: irrelevant
# [09:39] <fantasai> dbaron: The thing is, default for transition not happening is time is zero
# [09:39] <fantasai> dbaron: The only thing that makes the transition happen is the time
# [09:40] <fantasai> dbaron: If #a has a long transition and you change from #b from 0s to 10ms, that drastically cuts the time of #b's transition
# [09:40] <fantasai> dbaron: Rules could come from different parts of cascade, e.g. box and button iside box, designed to have independent transitions
# [09:41] <fantasai> jdovey: [...]
# [09:41] <fantasai> TabAtkins: I think your model works for this, dbaron
# [09:41] <fantasai> dbaron: No, don't yet know of a model that works for this
# [09:42] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [09:42] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [09:42] <fantasai> TabAtkins: his model is if you inherit a value from your parent, and that value is produced by transition or animation, it will not start transition, but existing transition will still update its endpoint to that value
# [09:42] * Rossen and Peter are arguing that users expect #a:hover, #a:hover > #b { color: blue }
# [09:42] <fantasai> TabAtkins: ... no, won't start. Nevermind
# [09:42] <fantasai> dbaron: When I proposed that, just thought of it for animations, not transitions
# [09:42] <fantasai> dbaron: if you start applying to transitions, too...
# [09:43] <fantasai> TabAtkins: A change from a static value to an animating value, will kick off a transition
# [09:43] <fantasai> dbaron: you don't have that info
# [09:43] <fantasai> ...
# [09:44] <fantasai> plinss: In this example, when you start/stop hovering, both transitions start imultaneously
# [09:44] <fantasai> plinss: The short transition will have end point of blue
# [09:44] <fantasai> plinss: And long transitions endpoint, over first 2s, will transition from green to blue
# [09:44] <fantasai> TabAtkins: In order to say endpoint is changing, have to know that endpoint is coming from transition
# [09:45] <fantasai> TabAtkins: But that's not updating endpoint, it's resetting transition counter
# [09:45] * Joins: rhauck (~Adium@public.cloak)
# [09:45] <fantasai> plinss: Don't need complex data flow analysis. Just tag all the transitions [...]
# [09:46] <fantasai> dbaron: If you're kicking off multiple transitions at the same time, need to recompute style twice for each transition you're kicking off, possibly for entire subtree
# [09:46] <fantasai> plinss: Problem is transitioning for somethign changed via inheritance
# [09:46] <fantasai> plinss: Because you're inheriting result of a transition
# [09:47] <fantasai> dino: Similar problem with width in ems
# [09:47] <fantasai> TabAtkins: Can't just track inheritance
# [09:48] <fantasai> ...
# [09:48] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Client closed connection)
# [09:48] <fantasai> TabAtkins: Think reasonable model is that every single computed value change triggers transition
# [09:48] <fantasai> plinss: So I have clarification ...
# [09:48] * Joins: shige-o (~AndChat474201@public.cloak)
# [09:49] <fantasai> plinss: If in this case, the font-size #b does not have a transition on it
# [09:49] <fantasai> plinss: #c has transition on width.
# [09:49] <fantasai> plinss: Is width going to transition?
# [09:49] <fantasai> dbaron: Yes
# [09:49] <fantasai> plinss: The 10ems didn't change
# [09:49] <fantasai> plinss: the specified value didn't change
# [09:49] <fantasai> fantasai: transitions are based on computed value
# [09:50] <fantasai> dbaron: This is the list of testcases that I proposed we not care about
# [09:50] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [09:50] <Cyril> equivalent example in SVG: http://jsfiddle.net/7WsP2/
# [09:50] <fantasai> dbaron: Meaning, some of these will do weird things, and authors will just get what they deserve
# [09:51] * jdovey thought I said that already…
# [09:51] <fantasai> TabAtkins: ...
# [09:51] <fantasai> TabAtkins: So we have the 3-way override with magic to make it all work
# [09:52] <TabAtkins> s/.../So we go back to the earlier idea: use the cascade origins as defined, but say that a running animation turns off transitions on the affected properties./
# [09:55] * Quits: shige-o (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [09:57] <fantasai> TabAtkins: If you :hover an element, and that starts an animation, and the animations' first value is different from the old value, will trigger a transition
# [09:57] <fantasai> TabAtkins: Which, if it's shorter than the animation, will be hidden by animation (but not otherwise)
# [09:58] <jdaggett> is rossen saying anything important?
# [09:58] <jdaggett> he's ....far.... away from the mic
# [09:58] * TabAtkins it's being minuted. one sec.
# [09:58] <jdaggett> kk
# [09:58] <fantasai> Rossen: In all of these cases, when transition is longer than the animation, the end tail of the transition [...] almost hte same value, so visually in lock-step with animation
# [09:58] * fantasai but not very well :(
# [09:58] * jdaggett heh
# [09:58] <fantasai> dino: Think point B is significant change from WebKit
# [09:58] <fantasai> dbaron: Was just proposing to modify point B with magic
# [09:59] <fantasai> TabAtkins: With animations turns off transitions magic?
# [09:59] <fantasai> dbaron: Sounded like what we're moving towards
# [09:59] <fantasai> dbaron: B would then be what Cascade then has
# [09:59] <fantasai> TabAtkins: If transition is kicked off on different property via computed value linkage, will still trigger transition.
# [09:59] <fantasai> TabAtkins: Something will happen, will be well-defined answer, but we don't care what happens
# [10:00] <fantasai> dino: And authors will be so confused, they won't know what went on
# [10:01] <fantasai> TabAtkins: Proposal is Adopt A, C, E, and D, and use cascade's ordering plus animations turn off corresponding transitions magic
# [10:01] <fantasai> fantasai: I *think* that sounds alright
# [10:01] <fantasai> plinss: That precludes a lot of situations we might want, like transitioning to an animated state
# [10:02] <fantasai> fantasai: We talked about that in Lyon, and I was convinced we don't want to tackle that right now, because we don't have rate-based transitions
# [10:02] <fantasai> fantasai: And getting those kinds of transitions to work well requires more sophisticated tools than just time-based transitions
# [10:03] <fantasai> fantasai: I think that's something we could add later, maybe with an 'animation-transition' property or something. :)
# [10:03] <fantasai> dino: David, when do you think you'll start testing this?
# [10:03] <fantasai> dbaron: No idea
# [10:03] <fantasai> TabAtkins: Shane, you said Blink's changing animation stuff?
# [10:04] <fantasai> TabAtkins: Oh, well why don't you implement this?
# [10:04] <fantasai> shane: I'd say, I'd be surprised if we didn't have something by the next F2F meeting
# [10:04] <fantasai> TabAtkins: So plan for Paris to have feedback from us
# [10:05] <fantasai> shane: Some concern wrt changing behavior, but does seem to be fairly edge cases.
# [10:06] <fantasai> dbaron: A bunch of this requires edits to Transitions, particularly to places where spec is very vague
# [10:06] <fantasai> dbaron: If we resolve on this, I'd make those edits
# [10:06] <fantasai> Proposal: Resolve on those edits, then re-evalueate after implementation experience
# [10:07] <fantasai> RESOLVED: Adopt A, C, D, and E from <http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html>, cascade as specified in css3-cascade, plus magic: animation on an element turns off transitions for the affected properties. Re-evaluate after implementation experience.
# [10:07] <fantasai> dbaron: For Transitions, only one other issue. Tab has had an action to write a demo for last few F2Fs.
# [10:07] <fantasai> TabAtkins: Ok, I will make a demo tonight!
# [10:08] <fantasai> plinss discusses CR strategy
# [10:08] <fantasai> plinss: I'm happy to go to CR with our best guess of what we think will stick. We can bounce back to LC to fix things. Implementation experience is what CR is for.
# [10:08] * leaverou is now known as leaverou_away
# [10:09] <fantasai> dbaron: Would write several screenfuls of At-Risk text
# [10:09] <fantasai> dbaron: But ok
# [10:09] <fantasai> plinss: Would like to leave this F2F with both specs going to LC
# [10:09] <fantasai> TabAtkins: Ok, so this means no change to Cascade.
# [10:09] <fantasai> TabAtkins: Which closes all the issues on Cascade.
# [10:09] <dbaron> I'm happy moving cascade to LC.
# [10:09] <fantasai> TabAtkins: How do people feel about going to LC?
# [10:10] <fantasai> RESOLVED: Take CSS3 Cascade to LC, with edits mentioned in minutes today.
# [10:11] <fantasai> ping HTMLWG especially, also notify WebApps, SVG, WAI
# [10:12] <fantasai> 4 weeks LC period
# [10:14] <fantasai> Cyril notes an inconsistency in the definition of "cascaded value"
# [10:14] <fantasai> which needs to be fixed
# [10:14] <fantasai> Topic: Conditional Rules
# [10:14] <fantasai> dbaron: Issue raised by heycam, discussed multiple times over the last month
# [10:14] <stearns> http://dev.w3.org/csswg/css-conditional/doc-20130404-CR.html
# [10:15] <fantasai> dbaron: Fun end-of-token-stream issue
# [10:15] * leaverou_away is now known as leaverou
# [10:16] <fantasai> dbaron: If this is valid, we'd better put the closing tokens in the stream
# [10:16] <fantasai> SimonSapin: Why wouldn't it be valid?
# [10:16] <fantasai> TabAtkins: Should error-recovery add the additional necessary tokens
# [10:17] <fantasai> plinss: I would say that error-recovery creates the necessary constructs, and serialization writes out the appropriate syntax.
# [10:17] <Zakim> dbaron, you asked to be reminded at this time to go home
# [10:17] <fantasai> SimonSapin: We don't store tokens, we store component values
# [10:17] <fantasai> dbaron: supports rule conditions can store things that aren't valid values in CSS
# [10:17] <fantasai> TabAtkins: Concept of component value he's invoking is from Syntax
# [10:18] <fantasai> TabAtkins: It augments tokens stream into a nested tree of blocks and tokens and ?
# [10:18] <fantasai> TabAtkins: We parse that into a parenthese block containing 4 tokens
# [10:18] <fantasai> dbaron: I'm hesitant to introduce a new concept in how we specify things
# [10:18] <fantasai> dbaron: because that might imply we need to introduce that concept into the implementation
# [10:19] * Quits: birtles (~chatzilla@public.cloak) ("ChatZilla 0.9.90-rdmsoft [XULRunner 1.9.0.17/2009122204]")
# [10:19] <fantasai> dbaron: Chances are you'll write a spec that requires the implementations to add that abstraction layer as a real thing
# [10:20] <fantasai> TabAtkins: If you encouter EOF, assume the additional necessary tokens to assume those constructs, so that you have a well-formed stream
# [10:20] <fantasai> glazou: minimal tokens necessary
# [10:20] <fantasai> SimonSapin: You're not storing tokens, storing constructs
# [10:20] <fantasai> SimonSapin: When you serialize it will create those constructs
# [10:20] <fantasai> SimonSapin: Only in variables or invalid @supports conditions will you store tokens
# [10:21] <fantasai> TabAtkins: So, whether store constructs or tokens treams, identical results
# [10:21] <fantasai> TabAtkins: So, to answer heycam's question, this would parse correctly, and would imply close parens
# [10:21] <fantasai> SimonSapin: I think in this case we don't even need to store the parens
# [10:21] <fantasai> SimonSapin: Just need to store a declaration
# [10:23] <fantasai> RESOLVED: Whenever error-recovery closes open blocks, urls, strings, functions, brackets, etc., it implies the minimal tokens to close those constructs.
# [10:23] <fantasai> heycam: Related issue is \ as last character of the stream. It's valid, but need to add another backslash before appending anything
# [10:24] <fantasai> TabAtkins: The backslash will become a DELIM token containing a backslash, and when you serialize it it will need to be escaped
# [10:24] <fantasai> dbaron: But when you escape it, it becomes an identifier
# [10:24] <fantasai> TabAtkins: Ahh..
# [10:25] <fantasai> The only way to include a literal backslash is to put it as the last character in the stream
# [10:25] <fantasai> TabAtkins: Could just drop that DELIM token
# [10:25] <fantasai> glenn: How about ident?
# [10:25] <fantasai> glenn: In font-family has name idents
# [10:25] <fantasai> ...
# [10:26] <fantasai> dbaron: Another proposal, kindof random, backslash at end of stream converts to U+FFFD
# [10:26] <fantasai> TabAtkins: We do the same thing to nulls
# [10:26] <fantasai> TabAtkins: That's new behavior
# [10:27] <fantasai> fantasai: This is a total edge case, it doesn't matter what we do here.
# [10:28] <fantasai> plinss: Why can't it be a backslash?
# [10:28] <fantasai> dbaron: Because you can't serialize it into any other context
# [10:30] <fantasai> plinss: What if you have open string? Couldn't you just close the string?
# [10:30] <fantasai> plinss: It would normally, at the end of a line, continue the string
# [10:31] <fantasai> dbaron: Do you want to change the rule (/EOF-> U+FFFDEOF) only for strings?
# [10:31] <fantasai> plinss: Yeah
# [10:31] <dbaron> s/\//\\/
# [10:31] <fantasai> plinss: A backslash at the end of a line inside of a string, should not turn into anything.
# [10:31] <fantasai> TabAtkins: I would prefer to handle this case in the escape-handling rules
# [10:32] <fantasai> TabAtkins: Don't want different behavior
# [10:32] <fantasai> dbaron: Escape behavior is already contextual wrt strings, because of \EOL
# [10:32] <fantasai> plinss: Don't see any value to not just ignoring it.
# [10:32] <fantasai> TabAtkins: OK
# [10:33] <fantasai> RESOLVED: \EOF turns into U+FFFD except when inside a string, in which case it just gets dropped.
# [10:33] <TabAtkins> ScribeNick: TabAtkins
# [10:33] <TabAtkins> heycam: If the final token in the stream is a bad-url or bad-string...
# [10:34] <TabAtkins> heycam: Those are bad because you've reached the end of the file...
# [10:34] <TabAtkins> heycam: If you try and fix the lone \ at the end in any way, none of those reserialize to a bad-string or bad-url.
# [10:35] <TabAtkins> dbaron: I think Tab's revisions to Syntax fix that - you never get a bad-string or bad-url from EOF.
# [10:35] <TabAtkins> TabAtkins: Yes, that was Zack's (original author of this stuff in 2.1) intention - it's an accident that 2.1 specifies two contradictory recovery behaviors for unclosed strings and urls.
# [10:36] * jdaggett all quiet...? you guys talking?
# [10:36] * jdaggett ah noise!
# [10:36] * jdaggett kk, good
# [10:36] <TabAtkins> TabAtkins: [explains what results would be produced in various situations]
# [10:36] <fantasai> ScribeNick: fantasai
# [10:37] <fantasai> heycam: conditionText attribute is defined to strip string of white space, but that could change the meaning
# [10:37] <fantasai> heycam: shows example of escaped whitespace
# [10:37] <fantasai> TabAtkins: need to strip whitespace tokens
# [10:37] <fantasai> heycam: That's fine
# [10:38] <fantasai> TabAtkins: That would be an identifier called "a "
# [10:38] <fantasai> RESOLVED: whitespace tokens are stripped, not necessarily actual white space, from conditionText
# [10:38] <fantasai> SimonSapin: Do we want to keep the value of badurl or badstring tokens around to serialize them?
# [10:39] <fantasai> TabAtkins: Syntax right now just puts a token into the token stream, with no other info
# [10:39] <fantasai> s/info/data/
# [10:39] <fantasai> TabAtkins: Can't ever serialize them
# [10:40] <fantasai> TabAtkins: Even variables can't sue them
# [10:40] <fantasai> ...
# [10:40] <fantasai> SimonSapin: In @supports, we have special error-handlign rule that says something invalid evaluates to false
# [10:40] <fantasai> SimonSapin: But the rule is stil valid
# [10:41] <fantasai> SimonSapin: If that invalid thing is a badstring token, how do we serialize it?
# [10:41] <fantasai> TabAtkins: Media queries, when serialized, serializes as a guaranteed false MQ?
# [10:41] <fantasai> TabAtkins: Should do same thing with @supports?
# [10:41] <fantasai> dbaron: I don't think we should do the same with @supports.
# [10:41] <fantasai> dbaron: Don't think so
# [10:42] <fantasai> dbaron: The way spec is written now, if you have badstring or baduri, the rule will get stripped
# [10:42] <fantasai> [because it doesn't match the grammar]
# [10:42] <fantasai> dbaron: Maybe should call that out explicitly
# [10:42] <dbaron> s/the rule will get stripped/the @supports rule will get dropped/
# [10:42] <jdaggett> ah, ok, got it
# [10:43] <fantasai> SimonSapin: Is allowed syntax for unknown things the same as variables?
# [10:43] <fantasai> TabAtkins: More or less
# [10:43] <fantasai> dbaron: We should check that, but not in an F2F
# [10:43] <fantasai> ACTION dbaron to check that variables and @supports have identical allowances
# [10:43] * trackbot is creating a new ACTION.
# [10:43] <trackbot> Created ACTION-563 - Check that variables and @supports have identical allowances [on David Baron - due 2013-06-12].
# [10:43] <fantasai> RESOLVED: Clarify that badstring and baduri make @supports rules invalid
# [10:44] <fantasai> dbaron: Have disagreement between prose and grammar wrt !important, and I think grammar shoudl be fixed
# [10:45] <fantasai> dbaron: Think !important should be allowed there. Might add other things that could go there, so might as well let it be part of testable things.
# [10:45] <fantasai> RESOLVED: !important allowed in @supports
# [10:47] <fantasai> dbaron: Ok, that's all open issues. Will fix in editor's draft
# [10:47] <fantasai> fantasai: I think the issues that require updates to Conditional Rules are all minor enough to be clarifications. Let's fix them and publish a CR in place
# [10:47] <fantasai> RESOLVED: Publish CR with updates for CSS3 Conditional Rules
# [10:47] * Quits: dino (~dino@public.cloak) (dino)
# [10:48] <fantasai> Topic: Variables
# [10:48] <fantasai> TabAtkins: Want to exclude badstring and baduri
# [10:48] <fantasai> dbaron: And mismatched blocks
# [10:51] <fantasai> TabAtkins: List of tokens you can't put in there: unmatched ) ] }, badstring, badurl, top-level ;
# [10:51] <fantasai> TabAtkins: Why is ; only disallowed at top-level, but } anywhere?
# [10:52] <fantasai> plinss: This is error-recovery
# [10:52] * glazou thinks "baduri" sounds like the name of a good sauce
# [10:53] <fantasai> dbaron: Would prefer not to allow unbalanced things
# [10:53] <fantasai> TabAtkins: Would prefer to disallow ; everywhere then
# [10:53] <fantasai> SimonSapin, dbaron: don't see why
# [10:54] <fantasai> dbaron: Consider in the future you want to put a declaration block in there
# [10:54] <fantasai> ...
# [10:54] <fantasai> TabAtkins: Ok, fine, I'm cool with this
# [10:54] <fantasai> RESOLVED: Can't put unmatched ) ] }, badstring, badurl, top-level ; into variables
# [10:55] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html
# [10:56] <fantasai> SimonSapin: Publish all the things!
# [10:56] <fantasai> Meeting closed.
# [10:56] <jdaggett> bye!!
# [10:56] <Zakim> -jdaggett
# [10:56] <glazou> for the day :)
# [10:56] <jerenkrantz> RRSAgent: make minutes
# [10:56] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/05-css-minutes.html jerenkrantz
# [10:56] * Quits: glazou (~glazou@public.cloak) (glazou)
# [10:58] * heycam is now known as heycam|away
# [10:58] * Quits: stakagi (~stakagi@public.cloak) ("TakIRC")
# [10:58] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [10:59] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [11:00] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [11:01] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:02] * Quits: Koji (~Koji@public.cloak) ("Page closed")
# [11:02] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [11:05] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [11:06] * Quits: jet (~junglecode@public.cloak) (jet)
# [11:08] <Zakim> -Meeting_Room
# [11:08] <Zakim> Team_(css)06:36Z has ended
# [11:08] <Zakim> Attendees were jdaggett, Meeting_Room
# [11:08] * Quits: Cyril (~chatzilla@public.cloak) (Ping timeout: 180 seconds)
# [11:08] * Quits: shans___ (~shans@public.cloak) ("Page closed")
# [11:11] * Quits: dbaron (~dbaron@public.cloak) ("8403864 bytes have been tenured, next gc will be global.")
# [11:22] * Joins: cabanier (~cabanier@public.cloak)
# [11:31] <MikeSmith> have you all been meeting at the Google offices in Roppongi Hills?
# [11:31] * Zakim excuses himself; his presence no longer seems to be needed
# [11:31] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [11:31] <MikeSmith> for this CSS f2f, I mean?
# [11:36] <liam> MikeSmith, I wasn't there today but I believe that's where the css f2f is, yes
# [11:36] <liam> http://wiki.csswg.org/planning/tokyo-2013
# [11:37] <MikeSmith> liam: thanks
# [11:45] * Joins: boblet (~uid1921@public.cloak)
# [11:53] * Joins: plh (plehegar@public.cloak)
# [12:06] * Joins: jdaggett_ (~jdaggett@public.cloak)
# [12:07] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [12:07] * jdaggett_ is now known as jdaggett
# [12:17] * Joins: glenn (~gadams@public.cloak)
# [12:28] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [12:35] * Joins: Tav (~tbah@public.cloak)
# [13:24] * Joins: shige-o (~AndChat474201@public.cloak)
# [13:27] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [13:36] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [13:36] * Joins: shige-o (~AndChat474201@public.cloak)
# [13:41] * Joins: dbaron (~dbaron@public.cloak)
# [13:44] * Joins: zcorpan (~zcorpan@public.cloak)
# [13:56] * Joins: jdovey (~jdovey@public.cloak)
# [14:00] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [14:06] * Quits: liam (liam@public.cloak) (Client closed connection)
# [14:22] * Joins: liam (liam@public.cloak)
# [14:37] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [14:53] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [14:53] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [14:55] * Joins: shige-o (~AndChat474201@public.cloak)
# [14:55] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Client closed connection)
# [15:00] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [15:04] * Joins: sylvaing_away (~sylvaing@public.cloak)
# [15:04] * Joins: alexmog_away (~alexmog@public.cloak)
# [15:05] * Joins: shans_away (~shans@public.cloak)
# [15:06] * Joins: csswg- (~csswg@public.cloak)
# [15:06] * Quits: leaverou (~leaverou@public.cloak) (Ping timeout: 180 seconds)
# [15:06] * Joins: leaverou (~leaverou@public.cloak)
# [15:06] * Quits: alexmog (~alexmog@public.cloak) (Ping timeout: 180 seconds)
# [15:06] * Quits: shans (~shans@public.cloak) (Ping timeout: 180 seconds)
# [15:06] * Quits: sylvaing (~sylvaing@public.cloak) (Ping timeout: 180 seconds)
# [15:06] * alexmog_away is now known as alexmog
# [15:06] * shans_away is now known as shans
# [15:06] * sylvaing_away is now known as sylvaing
# [15:08] * Quits: csswg (~csswg@public.cloak) (Ping timeout: 180 seconds)
# [15:08] * csswg- is now known as csswg
# [15:17] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [15:26] * Joins: AndChat|474201 (~AndChat474201@public.cloak)
# [15:26] * Quits: shige-o (~AndChat474201@public.cloak) (Client closed connection)
# [15:29] * Joins: glenn (~gadams@public.cloak)
# [15:40] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [15:42] * Joins: Cyril (~chatzilla@public.cloak)
# [15:48] * Quits: AndChat|474201 (~AndChat474201@public.cloak) (Ping timeout: 180 seconds)
# [15:53] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [15:54] * Joins: zcorpan (~zcorpan@public.cloak)
# [15:57] * Joins: SimonSapin (~simon@public.cloak)
# [15:58] * heycam|away is now known as heycam
# [15:59] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [16:01] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [16:04] * Joins: sgalineau (~sgalineau@public.cloak)
# [16:05] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [16:24] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [16:25] * Quits: Cyril (~chatzilla@public.cloak) ("ChatZilla 0.9.90 [Firefox 24.0a1/20130602031240]")
# [16:34] * heycam is now known as heycam|away
# [16:42] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:51] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [16:52] * Joins: zcorpan (~zcorpan@public.cloak)
# [16:59] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:02] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:03] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:04] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:04] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [17:07] * leaverou is now known as leaverou_away
# [17:08] * leaverou_away is now known as leaverou
# [17:11] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [17:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:36] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [17:36] * Joins: zcorpan (~zcorpan@public.cloak)
# [17:43] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [18:00] * Joins: MaRakow (~MaRakow@public.cloak)
# [18:02] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [18:03] * Joins: arno (~arnog@public.cloak)
# [18:23] * Quits: MaRakow (~MaRakow@public.cloak) ("Page closed")
# [18:45] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [18:45] * Joins: darktears (~darktears@public.cloak)
# [18:47] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:54] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:32] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [19:35] * Joins: arno (~arnog@public.cloak)
# [19:35] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [19:41] * Joins: glenn (~gadams@public.cloak)
# [19:48] * Quits: glenn (~gadams@public.cloak) (Ping timeout: 180 seconds)
# [19:48] * Quits: sgalineau (~sgalineau@public.cloak) (Client closed connection)
# [19:50] * Joins: sgalineau (~sgalineau@public.cloak)
# [20:17] * leaverou is now known as leaverou_away
# [20:21] * leaverou_away is now known as leaverou
# [20:37] * Joins: arno1 (~arnog@public.cloak)
# [20:40] * Quits: arno (~arnog@public.cloak) (Ping timeout: 180 seconds)
# [20:49] * Joins: darktears (~darktears@public.cloak)
# [20:58] * Quits: arno1 (~arnog@public.cloak) ("Leaving.")
# [21:03] * Joins: arno (~arnog@public.cloak)
# [21:25] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [21:37] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:42] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [21:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:45] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [21:50] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [21:52] * Joins: arronei (~arronei@public.cloak)
# [21:56] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:03] * Joins: lmclister (~lmclister@public.cloak)
# [22:05] * Quits: sgalineau (~sgalineau@public.cloak) (Ping timeout: 180 seconds)
# [22:08] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:08] * Joins: arronei_ (~arronei@public.cloak)
# [22:10] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:12] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:13] * Quits: tobie (tobie@public.cloak)
# [22:15] * Joins: arronei (~arronei@public.cloak)
# [22:17] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:18] * Joins: arronei_ (~arronei@public.cloak)
# [22:22] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:22] * Joins: arronei (~arronei@public.cloak)
# [22:25] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:25] * Joins: arronei_ (~arronei@public.cloak)
# [22:29] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:30] * Joins: arronei (~arronei@public.cloak)
# [22:32] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:32] * Joins: arronei_ (~arronei@public.cloak)
# [22:37] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:37] * Joins: arronei (~arronei@public.cloak)
# [22:39] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:39] * Joins: arronei_ (~arronei@public.cloak)
# [22:44] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:45] * Joins: arronei (~arronei@public.cloak)
# [22:46] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:47] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [22:49] * Joins: arronei_ (~arronei@public.cloak)
# [22:50] * Joins: glenn (~gadams@public.cloak)
# [22:52] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:55] * Joins: arronei (~arronei@public.cloak)
# [22:56] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:57] * Quits: arronei (~arronei@public.cloak) ("")
# [22:57] * Joins: arronei (~arronei@public.cloak)
# [23:02] * Quits: arronei (~arronei@public.cloak) ("")
# [23:06] * Joins: arronei (~arronei@public.cloak)
# [23:15] * Joins: jdaggett (~jdaggett@public.cloak)
# [23:37] * Joins: dbaron (~dbaron@public.cloak)
# [23:39] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# Session Close: Thu Jun 06 00:00:00 2013

The end :)