#css IRC Log


IRC Log for 2013-06-04

Timestamps are in PDT.

[00:07] * Koji Quit (Client closed connection)

[00:09] * Koji has joined #css

[00:16] * stearns_ is now known as stearns

[00:33] * rhauck has joined #css

[00:36] * lmclister has joined #css

[00:41] * tobie has joined #css

[00:47] * Koji Quit (Client closed connection)

[00:47] * Koji has joined #css

[01:08] * glazou Quit (glazou)

[01:17] * Koji Quit (Client closed connection)

[01:30] * plh Quit ("Leaving")

[01:47] * Liam-jp Quit (Ping timeout: 180 seconds)

[01:52] * lmclister Quit (lmclister)

[02:16] * nikos Quit (Ping timeout: 180 seconds)

[02:16] * cabanier Quit ("Leaving.")

[02:16] * Koji has joined #css

[02:17] * jun Quit (jun)

[02:21] * heycam is now known as heycam|away

[02:27] * Tav Quit (Ping timeout: 180 seconds)

[02:31] * Koji Quit (Ping timeout: 180 seconds)

[02:32] * dbaron Quit ("8403864 bytes have been tenured, next gc will be global.")

[02:33] * SimonSapin Quit ("Leaving.")

[03:47] * Ms2ger Quit ("bbl")

[04:13] * rhauck Quit ("Leaving.")

[04:24] * lmclister has joined #css

[04:45] * lmclister Quit (lmclister)

[05:01] * fantasai Quit (Ping timeout: 180 seconds)

[05:04] * liam has joined #css

[05:41] * dbaron has joined #css

[06:50] * SimonSapin has joined #css

[06:51] * zcorpan Quit (Client closed connection)

[07:03] * krijnhuman Quit (Client closed connection)

[07:04] * krijnh has joined #css

[07:21] * zcorpan has joined #css

[07:56] * cabanier has joined #css

[08:06] * Ms2ger has joined #css

[08:06] * zcorpan Quit (Ping timeout: 180 seconds)

[08:15] * dbaron Quit (Ping timeout: 180 seconds)

[08:20] * zcorpan has joined #css

[08:23] * SimonSapin Quit ("Leaving.")

[08:23] * zcorpan Quit (Client closed connection)

[08:37] * leaverou is now known as leaverou_away

[09:20] * tantek has joined #css

[09:21] * tantek Quit (Client closed connection)

[09:26] * tantek has joined #css

[09:33] * zcorpan has joined #css

[09:35] * tantek Quit (Client closed connection)

[09:37] * tantek has joined #css

[09:40] * zcorpan Quit (Ping timeout: 180 seconds)

[09:47] * tantek Quit ("Colloquy for iPod touch - http://colloquy.mobi")

[10:43] * zcorpan has joined #css

[11:34] * rhauck has joined #css

[11:57] * leaverou_away is now known as leaverou

[12:01] * lmclister has joined #css

[12:08] * lmclister Quit (lmclister)

[12:08] * lmclister has joined #css

[12:39] * rhauck1 has joined #css

[12:44] * rhauck Quit (Ping timeout: 180 seconds)

[13:42] * arno has joined #css

[13:48] * arno1 Quit (Ping timeout: 180 seconds)

[13:50] * cabanier Quit ("Leaving.")

[13:50] * cabanier has joined #css

[13:59] * Ms2ger Quit ("nn")

[14:04] * lmclister Quit (Ping timeout: 180 seconds)

[14:05] * lmclister has joined #css

[14:13] * lmclister Quit (Client closed connection)

[14:16] * lmclister has joined #css

[14:57] * cabanier Quit ("Leaving.")

[15:04] * cabanier has joined #css

[15:05] * cabanier Quit ("Leaving.")

[15:09] * cabanier has joined #css

[15:19] * cabanier Quit ("Leaving.")

[15:27] * rhauck1 Quit (Client closed connection)

[15:32] * dbaron has joined #css

[15:58] * sgalineau has joined #css

[16:09] * Tav Quit (Ping timeout: 180 seconds)

[16:09] * sgalineau Quit ("Textual IRC Client: www.textualapp.com")

[16:09] * sgalineau has joined #css

[16:11] * tobie Quit (Ping timeout: 180 seconds)

[16:28] * dbaron Quit (Ping timeout: 180 seconds)

[16:46] * zcorpan Quit (Client closed connection)

[16:46] * zcorpan has joined #css

[16:53] * zcorpan Quit (Ping timeout: 180 seconds)

[16:54] * jdaggett has joined #css

[16:56] * SimonSapin has joined #css

[17:03] * heycam|away is now known as heycam

[17:04] <jdaggett> most folks in the room? starting soon?

[17:07] <heycam> some folks, feeling like we're waiting ofr a few more though

[17:07] * SimonSapin Quit ("Leaving.")

[17:07] <jdaggett> cool, thx

[17:09] * SimonSapin has joined #css

[17:09] * cabanier has joined #css

[17:10] * lmcliste_ has joined #css

[17:11] * Rossen has joined #css

[17:11] * lmclister Quit (Ping timeout: 180 seconds)

[17:12] * birtles has joined #css

[17:15] * dbaron has joined #css

[17:15] * glazou has joined #css

[17:16] <dbaron> trackbot, start meeting

[17:16] * trackbot is preparing a teleconference.

[17:16] * RRSAgent has joined #css

[17:16] <RRSAgent> logging to http://www.w3.org/2013/06/05-css-irc

[17:16] <trackbot> RRSAgent, make logs member

[17:16] <RRSAgent> I have made the request, trackbot

[17:16] * Zakim has joined #css

[17:16] <trackbot> Zakim, this will be Style_CSS FP

[17:16] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot

[17:16] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference

[17:16] <trackbot> Date: 05 June 2013

[17:16] <dbaron> RRSAgent, make logs public

[17:16] <RRSAgent> I have made the request, dbaron

[17:17] <dbaron> Zakim, remind us in 8 hours to go home

[17:17] <Zakim> ok, dbaron

[17:17] <glazou> rrsagent, this meeting spans midnight

[17:17] <RRSAgent> ok, glazou; I will not start a new log at midnight

[17:17] * zcorpan has joined #css

[17:18] <dbaron> RRSAgent, this meeting does not span midnight

[17:18] <RRSAgent> I'm logging. I don't understand 'this meeting does not span midnight', dbaron. Try /msg RRSAgent help

[17:18] * r12a has joined #css

[17:18] * jdaggett loves all this sexy machine talk...

[17:19] * shans__ has joined #css

[17:19] <dbaron> RRSAgent, start a new log at midnight

[17:19] <RRSAgent> ok, dbaron; I will start a new log at midnight

[17:19] <jdaggett> RRSAgent, you look lovely tonight

[17:19] <RRSAgent> I'm logging. I don't understand 'you look lovely tonight', jdaggett. Try /msg RRSAgent help

[17:19] * liam particularly likes <dbaron> Zakim, remind us in 8 hours to go home

[17:19] * dbaron liam, that's so it doesn't leave after an hour

[17:20] * dbaron though I should have used 9 hours

[17:20] * liam ah, cool, good idea!

[17:20] * jdaggett yeah, 9 is right

[17:21] * Kazutaka has joined #CSS

[17:24] * krit has joined #css

[17:26] * myakura has joined #css

[17:26] * nikos has joined #css

[17:26] * stakagi has joined #css

[17:26] * jdovey has joined #css

[17:26] <glazou> jdaggett, send us a few meeting tables and power strips, we could use them immediately :-(

[17:27] <jdaggett> oh dear

[17:27] <glazou> why do you think we've not started yet ?

[17:27] <jdaggett> google japan has no power strips?

[17:28] <jdaggett> is brian birtles there? get him to run back to mozilla japan to fetch some

[17:28] <jdaggett> he's a good runner!

[17:31] <dbaron> birtles is here :-)

[17:32] * birtles jdaggett, thanks! do I get a 'monster' if I run there and back? that's the normal deal

[17:33] <jdaggett> haha

[17:33] <jdaggett> i saw a big order come in last week...

[17:33] <jdaggett> that stuff will kill you... ;)

[17:34] * birtles yeah, I heard it's also not so good if you plan on having children

[17:34] <jdaggett> yikes

[17:39] * krit obviously there is no working cooperation between Apple and Google

[17:39] * krit or at least Apple TV

[17:42] * jdovey Quit (jdovey)

[17:43] * krit Quit ("Leaving.")

[17:43] * krit has joined #css

[17:48] * jerenkrantz has joined #css

[17:48] * Tav Quit ("Leaving")

[17:49] * plh has joined #css

[17:49] * Tav has joined #css

[17:49] * fantasai has joined #css

[17:50] * jdovey has joined #css

[17:51] <jerenkrantz> Is there an agenda? Or, will we kick off with agenda bashing?

[17:52] <stearns> the latter, usually

[17:52] <glazou> jerenkrantz, what stearns said

[17:52] <jdovey> beanbags & slingshots at the ready���

[17:53] <dbaron> I took the opportunity to write http://wiki.csswg.org/planning/hosting

[17:53] <jerenkrantz> Since I am new, do we tend to do intros and is there a scribe for those who can't join here?

[17:54] <dbaron> ScribeNick: dbaron

[17:54] <dbaron> Topic: introductions

[17:54] <liam> dbaron, I added a bullet item to that wiki page, telephone access

[17:55] * Cyril has joined #css

[17:56] * liam goes to other meetings

[17:56] * koji has joined #css

[17:57] * koji Quit ("Leaving...")

[17:58] <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

[17:58] <dbaron> e), Alan Stearns (Adobe), Richard Ishida (W3C), Alan Stearns (Adobe), Bert Bos (W3C), Rossen Atanassov (Microsoft), Glenn Adams (Cox), Jet Villegas (Mozilla)

[17:58] * Koji has joined #css

[17:58] <heycam> http://www.pastebin.mozilla.org/2486303

[17:58] <dbaron> Topic: Agenda

[17:58] <dbaron> Peter: There's also an FXTF wiki for agenda items in addition to http://wiki.csswg.org/planning/tokyo-2013#agenda

[17:59] <dbaron> heycam: The only ordering restriction is doug wants to call in for text wrapping, prefers early

[17:59] <dbaron> is shepazu available now-ish?

[17:59] <myakura> s/Satori ???/Satoru Takagi/

[18:00] <plinss> zakim, room for 3?

[18:00] <Zakim> ok, plinss; conference Team_(css)01:00Z scheduled with code 26631 (CONF1) for 60 minutes until 0200Z

[18:00] <heycam> shepazu ^

[18:00] <Tav> s/Tamjong/Tavmjong/

[18:01] <dbaron> Present+ Peter Linss (HP)

[18:01] <Kazutaka> s/?? (NTT)/Kazutaka Yamamoto(NTT)/

[18:03] * liam Quit (Ping timeout: 180 seconds)

[18:03] <dbaron> Topic: Web Animations

[18:04] <birtles> spec link: https://dvcs.w3.org/hg/FXTF/raw-file/default/web-anim/index.html

[18:08] <dbaron> dialing to Zakim failed, switching back to projector

[18:09] * glazou should not have taken an espresso this morning, more adrenaline was not needed

[18:09] * shepazu waves

[18:09] <glazou> ROFL @ http://w3cmemes.tumblr.com/image/52183066977

[18: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

[18:10] * shepazu could dial in first, if you like

[18:11] <heycam> shepazu, yes feel free

[18:11] * shepazu pings Cyril

[18:12] * shepazu heycam, what number should I call? or should we use skype?

[18:12] * dbaron Zakim, code?

[18:12] * Zakim the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), dbaron

[18:12] <dbaron> birtles: wanted to give overview of web animation; getting close to asking for FPWD.

[18:13] <Zakim> Team_(css)01:00Z has now started

[18:13] <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

[18:13] <Zakim> +Doug_Schepers

[18:13] * plinss shepazu ^

[18: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.

[18:13] * shepazu can wait until after birtles is done, I'll call back in then

[18:13] * jerenkrantz Quit (Client closed connection)

[18:13] <Zakim> -Doug_Schepers

[18:13] <Zakim> Team_(css)01:00Z has ended

[18:13] <Zakim> Attendees were Doug_Schepers

[18:14] <dbaron> birtles: about 1 year ago, Adobe suggested I start concrete proposal for that; invited Shane (Google) to help, had suggestions about state machines

[18:14] <dbaron> birtles: presented last year in Hamburg, and FXTF agreed to take it on as a work item

[18:14] * heycam suspects a new "Zakim room for 3" will be required since the call has finished now

[18:14] <dbaron> birtles: I've been working with Adobe and Google to produce specification

[18:14] * shepazu can do that

[18:14] <birtles> diagram: https://wiki.mozilla.org/images/f/f6/CSS-SVG-Web-Animations.png

[18:14] <dbaron> birtles: overview of what's in it in this diagram

[18:14] * dino has joined #css

[18:14] * jerenkrantz has joined #css

[18:14] <dbaron> birtles describes diagram

[18:14] * heycam https://wiki.mozilla.org/images/f/f6/CSS-SVG-Web-Animations.png

[18:16] <dbaron> birtles: (part of diagram description) SVG features not in the model mostly are features that generate animations rather than animations themselves

[18:17] * sgalineau cool diagram

[18: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

[18: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.

[18:18] <dbaron> birtles: Apple's request to split into 2 parts: model first, then script api.

[18:18] <dbaron> birtles: we're focusing on the model, but the API often generates the most controversy/feedback

[18: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.

[18:19] <dbaron> birtles: The API is the controversial bit and the bit we really want toget right (hard to change later).

[18: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).

[18:19] <dbaron> birtles: So what's there is hopefully what we'll be sending out later this week.

[18:20] <dbaron> birtles: So, just wanted to introduce this and ask if any immediate feedback or questions

[18:20] <dbaron> dino: slightly concerned that media was dropped. One of the things we considered important from Apple's perspective.

[18:20] <dbaron> dino: But I think this spec is in better shape before FPWD than most specs are after 5 or 6 WDs.

[18: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.

[18:21] <dbaron> dino: Nothing to stop a draft. Call out in the draft that it's been removed?

[18: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.

[18:22] <dbaron> stearns: on the other side: is there justification in the draft for the 4 new things in the model?

[18:22] <dbaron> stearns: rather than just describing the union?

[18:22] <dbaron> birtles: there isn't extensive justification for each feature

[18:22] * jerenkrantz Quit ("Page closed")

[18: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

[18:22] * jerenkrantz has joined #css

[18:23] <dbaron> birtles: no justification per se except for use cases at te start

[18: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?).

[18:24] * shans__ Quit (Ping timeout: 180 seconds)

[18:24] <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.

[18:24] <dbaron> dino: I think the strength of this spec is that it has a powerful API with a complete JS library.

[18: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

[18:24] * cabanier Quit ("Leaving.")

[18:24] <fantasai> dino: That's why we're interested in media

[18:24] * cabanier has joined #css

[18:25] <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.

[18:25] <Zakim> Team_(css)01:00Z has now started

[18:25] <Zakim> +[IPcaller]

[18: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

[18:25] * heycam Zakim, code?

[18:25] * Zakim saw 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, heycam

[18:25] <dbaron> dino: so a developer would approach authoring by saying from 10s-20s, this is the state that applies

[18:25] <jdaggett> hmm, no zakim conf at 26631

[18:25] <dbaron> dino: so you could write CSS that applies when that state is ative

[18:26] <dbaron> dino: so a CSS developer could easily understand this -- no JS. When state applies, apply transitions/animations/styles/whatever.

[18:26] <dbaron> dino: but adjacent to this spec

[18:26] <dbaron> dino: more like what we were hoping to use this spec for

[18:26] <dbaron> birtles: I should emphasize that the API is not fundamental to the model; you can implement the model without the api.

[18:26] <dbaron> birtles: Those parts which are outside the model but are in CSS or SVG are defined in separate specifications.

[18:27] <jdaggett> heycam: you guys aren't connected to zakim, i'm the "first participant"

[18:27] <dbaron> birtles: For the SVG parts, we'd have an SVG specification (my next task).

[18:27] * shepazu heycam, do you need another telcon bridge set up?

[18:27] <dbaron> birtles: Likewise CSS animations level 4 could be expressed in terms of that model

[18:27] * heycam jdaggett what code did you use then?

[18:27] <dbaron> birtles: in media... doing as a separate model...

[18:27] <jdaggett> the 26631 one

[18:27] <dbaron> dino: primary use case readalong books in iBooks -- a kids book that has, say, 3 lines of text on the page

[18:27] * heycam shepazu do you want to try connecting with 26631?

[18:28] <dbaron> dino: audio track in page, lines or words highlight along with audio track

[18:28] * heycam I don't think we are dialled in yet

[18:28] <dbaron> dino: want to avoid using script

[18:28] <dbaron> dirk: using SMIL for this?

[18:28] <dbaron> dino: Ever tried writing that in SMIL? It's crazy.

[18:28] <Zakim> +Doug_Schepers

[18:28] * dbaron we couldn't figure out how to dial in from room

[18:28] <dbaron> birtles: next specification I'll be working on is SVG mapping onto the model

[18:29] <dbaron> dirk: Your request is to review the spec give feedback, and end up with publishing FPWD.

[18:29] <dbaron> birtles: yes, will send request later this week

[18:29] <dbaron> dino: what's the state of your JS shim/polyfill?

[18:30] <dbaron> birtles: I'm not contributing to that; Google is.

[18:30] <dbaron> shane: what info do you want?

[18:30] <dbaron> dino: how complete relative to spec?

[18:30] <dbaron> shane: more complete than current spec? Up to date other than last 3-4 weeks.

[18:30] <dbaron> shane: on github, open source license

[18:30] <dbaron> shane: should be relatively easy for us to sync with last set of changes over a week or so

[18:31] <dbaron> birtles: have some issues with events marked in spec with "feedback wanted" -- we want more input

[18:31] <dbaron> glazou: did you want to ask for FPWD now?

[18:31] * jdovey JS shim is at https://github.com/web-animations/web-animations-js

[18:31] <dbaron> ?: or give people time to review?

[18:32] <dbaron> dino: I think it's a high quality spec, I think the question is whether in scope or out of scope.

[18:32] <Zakim> -[IPcaller]

[18:32] <Zakim> -Doug_Schepers

[18:32] <Zakim> Team_(css)01:00Z has ended

[18:32] <Zakim> Attendees were [IPcaller], Doug_Schepers

[18:32] <dbaron> glazou: do people want time to review?

[18:33] <dbaron> [various people happy with publishing]

[18:33] <dbaron> Bert: no time to review before July anyway, so don't wait for me

[18:34] <dbaron> RESOLVED: Publish Web Animations as First Public Working Draft (resolved by both CSS and SVG WGs).

[18:34] * shepazu yay!

[18:35] * heycam shepazu still phone problems. they're trying alternative arrangements, so we'll keep going with other topics in the meantime. sorry.

[18:35] * shepazu heycam, ok, jdaggett and I are waiting to hear about the g+ hangout

[18:35] <dbaron> Topic: reusing stroke and fill properties

[18:35] <dbaron> heycam: topic added from CSS side

[18:36] <dbaron> heycam: did someone have a specific proposal

[18:36] * shepazu wonders if Adobe could provide another phone bridge?

[18:36] <dbaron> Tab: it was me

[18:36] <Zakim> Team_(css)01:00Z has now started

[18:36] <dbaron> fantasai: we've had requests to be able to do fill and stroke on letterforms

[18:36] <Zakim> + +81.36.384.aaaa

[18:36] <dbaron> fantasai: webkit has text-stroke property. Might make more sense to reuse existing SVG properties.

[18:36] * birtles Quit (Client closed connection)

[18:36] * TabAtkins shepazu wanna call into zakim again? trying to see if this works

[18:36] <Zakim> +Doug_Schepers

[18:36] <dbaron> fantasai: Complication is filling with pattern or image of some kind... how to handle line breaks is complicated

[18:36] * birtles_ has joined #css

[18:36] * birtles_ is now known as birtles

[18:36] <dbaron> fantasai: stroking or filling with color is straightforward

[18:37] <dbaron> heycam: why do line breaks complicate things?

[18:37] <dbaron> fantasai: need to find the bounding box

[18:37] <Zakim> +Vivienne

[18:37] * heycam Zakim who is on the call?

[18:37] <dbaron> [pause for Zakim debugging]

[18:38] * plh wonders how confusing color and fill are going to be for devs

[18:38] <Zakim> -Vivienne

[18:38] <dbaron> fantasai: might cut or take bounding box or separately per fragment

[18:38] <dbaron> http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break

[18:38] <fantasai> dbaron: we do sort-of have a property for this already

[18:38] <jdaggett> the webvtt guys have 'text-outline' as part of their spec

[18:38] <dbaron> dbaron: we do sort of have a property for this already: http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break

[18:39] <jdaggett> fill/stroke would be a better way of supporting that

[18:39] <dbaron> fantasai: do we reuse that property or have separate control?

[18:39] <dbaron> heycam: what does box-decoration-break do? fantasai: determines how it's handled for borders and background

[18:39] <dbaron> fantasai: That's background, this is about foreground.

[18: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.

[18:40] <dbaron> dirk: I think the first question is do we want something like that.

[18:40] <dbaron> dirk: Before we talk about page break or line break or whatever.

[18:40] <Zakim> - +81.36.384.aaaa

[18:40] <Zakim> -Doug_Schepers

[18:40] <Zakim> Team_(css)01:00Z has ended

[18:40] <Zakim> Attendees were +81.36.384.aaaa, Doug_Schepers, Vivienne

[18:40] <dbaron> fantasai: simplest are fill-opacity and stroke; fill could deal with later

[18:40] <dbaron> dirk: I think fill at least as important as stroke

[18: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.

[18:41] <dbaron> dino: want to be able to say fill text with gradient/color/pattern; seems pretty standard for CSS

[18:41] <dbaron> fantasai: additional complication is that color inherits

[18:41] <dbaron> fantasai: so each element paints with its own color property

[18:41] <dbaron> fantasai: if you add more elements nothing changes unless you set properties on those elements

[18:42] <dbaron> fantasai: you want pattern to be consistent across an entire paragraph

[18:42] <dbaron> ... with elements inside

[18:42] * lmcliste_ Quit (Client closed connection)

[18: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

[18:42] <dbaron> heycam: but for tspans within a text element we use the bounding box of the text element as a whole

[18:43] <dbaron> dbaron: don't think (1) works with CSS model

[18:43] <dbaron> heycam: agree

[18:43] <dbaron> heycam: so what happens with linear-gradient on a paragraph with multiple spans...

[18:43] * MikeSmith has joined #css

[18:44] <dbaron> dbaron: background doesn't inherit

[18:44] <MikeSmith> RRSAgent, make minutes

[18:44] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/05-css-minutes.html MikeSmith

[18:44] <dbaron> [not minuting entire discussion here]

[18:44] <fantasai> dino notes that fill inherits

[18:44] <dbaron> dino: fill/stroke/color inherit and background doesn't; don't want a new style of fill for every child

[18:44] <fantasai> fantasai: that would be a problem

[18:45] <dbaron> heycam: why would fill and color have different inheritance?

[18:45] <dbaron> fantasai: if you're setting a pattern need to know which element initiated the pattern

[18:45] <dbaron> heycam: seems odd for fill and color to have difference in whether they inherit, similar actions

[18: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.

[18:46] <dbaron> dirk: always have option to have different properties

[18:46] <fantasai> dbaron: I think it is a good idea to use fill/stroke. Would like to see that work

[18:47] <Zakim> Team_(css)01:00Z has now started

[18:47] <fantasai> dbaron: We could do it by turning fill/stroke into shorthand that sets both an inherited and non-inherited property

[18:47] <Zakim> + +81.36.384.aaaa

[18:47] <fantasai> heycam: ???

[18:47] <fantasai> dbaron: Say 'fill' is a shorthand for 'fill-pattern' and 'fill-root'

[18:47] <Zakim> +[IPcaller]

[18:47] <SimonSapin> heycam: so having text-stroke and text-fill not inherited and shape-stroke and shape-fill (for SVG) inherited

[18:48] <fantasai> dbaron: latter of which has 'normal' and 'establish' or something

[18:48] <fantasai> dino: You only want this fill/stroke to apply to text

[18:48] <dbaron> dino: question is, do you only want this new fill/stroke to apply to text?

[18:48] <Zakim> +Doug_Schepers

[18:48] <fantasai> dino: It's text-stroke. Do you ever want to stroke the box?

[18:48] <dbaron> dino: that's one reason in webkit it's text-stroke

[18:48] <dbaron> dino: do you ever want to stroke a box?

[18:48] <fantasai> fantasai: That's what borders are for

[18:48] <dbaron> fantasai: that's what borders are for

[18:48] <dbaron> ?: just on text

[18:48] <shepazu> fantasai: that's what borders are for

[18:48] <dbaron> dino: then why not just do text-fill and text-stroke

[18:49] <dbaron> dirk: if you say ... should be a shorthand ... inheritance problem ...

[18:49] <dbaron> dino: sounds fine to me

[18:49] <dbaron> fantasai: in SVG stroke just sets color of something ... weird

[18:49] * shepazu hears a siren...

[18:49] <dbaron> heycam: might be beneficial for 'stroke' to be shorthand to stroke-paint and stroke-width and ...

[18:49] <dbaron> fantasai: yes, that would follow pattern of CSS a lot better

[18:50] <dbaron> dirk: what does stroke-paint stroke-width mean?

[18:50] <dbaron> heycam: stroke-paint would be what stroke is currently

[18:50] <dbaron> fantasai: you can set all the stroke-related properties

[18:50] <dbaron> fantasai: if you just want to touch the color you say stroke-paint

[18:50] <dbaron> heycam: might be more convenient for SVG anyway

[18:50] <dbaron> fantasai: possible without breaking the Web?

[18:50] <dbaron> heycam: yeah, probably

[18:50] <dbaron> fantasai: depends how often people use it in CSS syntax rather than in SVG file

[18:51] * shepazu can't hear

[18:51] <dbaron> fantasai: because stroke-width: ...; stroke: ...; would reset the first

[18:51] <Zakim> - +81.36.384.aaaa

[18:51] <shepazu> (what would stroke: blue; do?)

[18:51] <dbaron> heycam: so I feel like somebody should look at these issues and come up with proposal forintegrating

[18:51] <dbaron> dirk: problem here is we have the attributes

[18:51] <dbaron> dirk: [too fast]

[18:51] <Zakim> -[IPcaller]

[18:51] <Zakim> -Doug_Schepers

[18:51] <Zakim> Team_(css)01:00Z has ended

[18:51] <Zakim> Attendees were +81.36.384.aaaa, [IPcaller], Doug_Schepers

[18:52] <dbaron> heycam: we already decided to allow font shorthand as presentation attribute

[18:52] <Zakim> Team_(css)01:00Z has now started

[18:52] <SimonSapin> shepazu, if it���s a shorthand, set stroke-paint to blue and stroke-width to the initial value

[18:52] <dbaron> heycam: you take all the presentation attributes in a praticular order

[18:52] <Zakim> +??P0

[18:52] <dbaron> dirk :cannot modify this order in te dom

[18:52] <shepazu> SimonSapin, then it won't break the web

[18:52] <dbaron> heycam: might not have made this change

[18:52] <dbaron> fantasai: for surethe stroke attribute would map to stroke-paint... it would have to

[18:52] <dbaron> fantasai: never mind

[18:52] <dbaron> heycam: anybody think it's a bad idea to try to allow paints in stroking text?

[18:53] <dbaron> Bert: principle is good, worried about syntax

[18:53] * shans__ has joined #css

[18:53] <dbaron> fantasai: in SVG, if you stroke a letterform, where does the stroke lie with respect...

[18:53] <dbaron> dirk: it half overlaps the fill

[18:53] <jdaggett> seems like we need someone to work on a draft proposal

[18:53] <dbaron> tav: can change the order now

[18:53] <dbaron> heycam: does webkit-text-stroke paint on top of fill or beneath?

[18:53] <dbaron> dirk: same as SVG

[18:53] <jdaggett> i think you want to have inset/outset control

[18:54] <jdaggett> look to postscript for a good model

[18:54] * fantasai agrees with jdaggett

[18:54] <dbaron> tav: most of the time you want fill on top of stroke

[18:54] <dbaron> fantasai: if you put fill on top of stroke, looks fine when fill is opaque, otherwise looks dumb

[18:54] <dbaron> fantasai: would also lead to author confusion about stroke width

[18:55] <dbaron> fantasai: so I agree with jdaggett, should have control over where stroke is centered

[18:55] <dbaron> dirk: ???

[18:55] <jdaggett> also, japan has *lots* of examples of double stroking of text

[18:55] <dbaron> heycam: we have proposal for that

[18:55] <dbaron> tav: should we put that in?

[18:55] <dbaron> dirk; we did

[18:55] <jdaggett> white stroke surrounded by black stroke

[18:55] <shepazu> +1 to controlling stroke centering

[18:55] <dbaron> Bert: if you're doing filling of text you might want text-shadow to have inset keyword

[18:55] <dbaron> fantasai: inset in plans for text level 4

[18:56] <Zakim> +[IPcaller]

[18:56] <dbaron> dirk: stroke and fill don't need to overlap... have a new property so they don't need to

[18:56] <dbaron> heycam: called stroke-position?

[18:56] <dbaron> heycam: which we have a proposal for, to go in SVG2

[18:57] <dbaron> fantasai: I think Tab and I can take an action to draw this one up.

[18:57] * glenn has joined #css

[18: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?

[18:57] <Cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position

[18:57] <dbaron> ACTION fantasai with Tab, draw up proposal for using stroke and fill for CSS text

[18:57] * trackbot is creating a new ACTION.

[18: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].

[18:57] <glenn> +Present glenn

[18:58] <fantasai> shepazu, call in

[18:58] * TabAtkins shepazu It works!

[18:59] <dbaron> jdaggett: For text stroke and text fill, parameterization could be complication... would like to work through multiple proposals.

[18:59] * jdaggett yay!

[18:59] <dbaron> Zakim, mute jdaggett

[18:59] <Zakim> sorry, dbaron, I do not know which phone connection belongs to jdaggett

[18:59] * fantasai zakim, who is noisy

[18:59] * Zakim I don't understand 'who is noisy', fantasai

[18:59] * fantasai zakim, who is noisy?

[18:59] * shepazu conf is restricted

[18:59] <jdaggett> muted

[19:00] * Zakim fantasai, listening for 10 seconds I heard sound from the following: ??P0 (60%)

[19:00] * dbaron Zakim, code?

[19:00] * Zakim saw 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, dbaron

[19:00] * dbaron Zakim, who is on the phone?

[19:00] * Zakim sees on the phone: ??P0, [IPcaller]

[19:00] <dbaron> Zakim, who is noisy?

[19:00] * shepazu conf must be over, top of the hour :(

[19:00] <Zakim> dbaron, listening for 12 seconds I heard sound from the following: ??P0 (20%)

[19:00] * jdaggett i can still hear ...

[19:00] <dbaron> Zakim, ??P0 is Meeting_Room

[19:00] <Zakim> +Meeting_Room; got it

[19:00] * shepazu jdaggett yeah, but I can't join

[19:01] <dbaron> Zakim, [IPCaller] is jdaggett

[19:01] <Zakim> +jdaggett; got it

[19:01] <Zakim> -jdaggett

[19:01] <Zakim> -Meeting_Room

[19:01] <Zakim> Team_(css)01:00Z has ended

[19:01] <Zakim> Attendees were Meeting_Room, jdaggett

[19:01] * shepazu Zakim, room for 5?

[19:01] <Zakim> ok, shepazu; conference Team_(css)02:01Z scheduled with code 26631 (CONF1) for 60 minutes until 0301Z

[19:02] <Zakim> Team_(css)02:01Z has now started

[19:02] <Zakim> +Doug_Schepers

[19:02] <Zakim> -Doug_Schepers

[19:02] <Zakim> +??P0

[19:02] <dbaron> Zakim, ??P0 is Meeting_Room

[19:02] <Zakim> +Meeting_Room; got it

[19:02] <Zakim> +Doug_Schepers

[19:03] <TabAtkins> Cool, new meeting is working.

[19:03] * Cyril waves at shepazu

[19:03] * shepazu jdaggett, please call in now :)

[19:03] * shepazu waves at Cyril

[19:03] <Zakim> +[IPcaller]

[19:03] <dbaron> Zakim, [IPCaller] is jdaggett

[19:03] <Zakim> +jdaggett; got it

[19:04] <jdaggett> yup

[19:04] <jdaggett> that's me

[19:04] <jdaggett> there's a tv nearby so i have to mute

[19:04] * dbaron Zakim, who is on the phone?

[19:04] * Zakim sees on the phone: Meeting_Room, Doug_Schepers, jdaggett

[19:04] <dbaron> Topic: text wrapping plans for SVG

[19:05] <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

[19: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

[19: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

[19:05] <dbaron> heycam: so we want to follow CSS For text in shapes

[19:06] <Tav> http://tavmjong.free.fr/SVG/TEXT_FLOW/

[19:06] <dbaron> heycam: and we've been discussing simple discussion for our current text to wrap text to a particular width

[19:06] <shepazu> simple: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text and more powerful: http://tavmjong.free.fr/SVG/TEXT_FLOW/

[19:06] <dbaron> heycam: tav will talk about what we need from arbitrary shapes perspective and doug will talk about simple rectangular wrapping

[19:06] <dbaron> tav: This describes what's in SVG 1.2 flowed text. Partially implemented by Batik and Inkscape

[19:07] <dbaron> tav: that didn't take -- was complicated and not consistent with CSS

[19:07] <dbaron> tav: looked at what we can do to keep consistent with CSS.

[19:07] <dbaron> tav: propose to use shape-inside, shape-outside, wrap-margin, wrap-padding

[19:07] <dbaron> tav: here's an example, with a shape in an SVG circle

[19:08] <dbaron> (showing examples from http://tavmjong.free.fr/SVG/TEXT_FLOW/ )

[19:08] <dbaron> tav: mocked up flowing between shapes (from 1.2 proposal), though told this conflicts with regions from CSS

[19:08] * Rossen Quit (Ping timeout: 180 seconds)

[19:08] <dbaron> tav: and here's one with some exclusions

[19:08] <dbaron> tav: a couple issues, 1 is CSS region seems overkill for our needs

[19:08] <dbaron> tav: and not close to being finished

[19:09] <dbaron> stearns: what you want that's different is a comma-separated list of regions?

[19:09] <dbaron> dirk: so shape-inside and flow to the next shape at the same time

[19:09] <dbaron> tav: shows example with text flowing from circle to square

[19:10] <dbaron> stearns: in regions you'd have a list of selectors selecting ...

[19:10] <dbaron> dirk: he means shapes... he wants shape-inside to have comma-separated lists

[19:10] <dbaron> Bert: so why does the text go down one and then down the other?

[19:11] <dbaron> tav: how to do without using CSS regions... if you don't have CSS support? SVG doesn't rely on having CSS.

[19:11] <dbaron> Jet: and the rest of the words are just clipped?

[19:11] <dbaron> fantasai: so what happens if someone increases the text size?

[19:11] <dbaron> tav: just falls off the end

[19:11] <dbaron> rossen: ... overflow: hidden... on both ...?

[19: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

[19:12] <dbaron> tav: question is what's the best way to do line breaks and paragraphs

[19: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.

[19:13] <dbaron> tav: though if renderer doesn't have right font, might be positioning problems, but would be readable

[19:13] <dbaron> tav: one thing SVG doesn't have is a wrapping context... doug has a proposal

[19:14] <shepazu> q

[19:14] * jet has joined #css

[19:14] <shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text

[19:14] <dbaron> doug: link to my proposal

[19:14] <dbaron> doug: there's a width and (optionally) height property on svg:text element

[19:14] <dbaron> doug: and it basically passes in the position established via x and y

[19:14] <dbaron> dougt: ... and the width, and optionally the height

[19:15] <dbaron> dougt: ... as the inner box (rendering area), and has CSS engine do text wrapping

[19:15] <dbaron> doug: cameron has rough prototype

[19:15] <dbaron> heycam: in local build

[19:15] <dbaron> s/dougt/doug/g

[19:15] <dbaron> doug: Cameron was able to implement in a couple of days.

[19:16] <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.

[19: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.

[19:16] <dbaron> doug: But the basic idea is to use the width property on the existing text element to wrap the text.

[19:17] <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.

[19:17] <dbaron> heycam: In SVG, when I get to rewriting text chappter, I plan to define non-wrapping text this way:

[19:17] <dbaron> heycam: SVG currently has x and y attributes to specify positions for character (not glyph!) positions

[19:17] <dbaron> heycam: we're treating that as a ... for defining CSS layout of the text

[19: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.

[19: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

[19:19] * Rossen has joined #css

[19:19] <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

[19:19] <dbaron> heycam: so we don't work away for months and then have people say it shouldn't be done this way

[19:19] <dbaron> fantasai: I think this makes sense

[19:19] <dbaron> fantasai: I have concern about x and y positions and how that works with line breaking

[19:19] * sgalineau Quit ("Computer has gone to sleep.")

[19:19] * Rossen wonders how different this is from foreign object in svg?

[19:19] <dbaron> fantasai: line breaking determined by layout engine and could vary between engines, e.g., fonts, hyphenation engine

[19:20] <dbaron> fantasai: those glyph thingies probably assume a certain type of wrapping

[19:20] <dbaron> heycam: in the past without support for auto-wrapped text, people used x and y to manually wrap

[19: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

[19:20] <dbaron> heycam: doug, did you have different view?

[19:20] <dbaron> doug: I think variou soptions we could explore.

[19: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.

[19:21] <dbaron> doug: I think this is simply solved by using what CSS already has, in SVG.

[19: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.

[19:22] <dbaron> glazou: Also in Mozilla's XUL have to include HTML inside of XUL.

[19:22] <dbaron> glazou: not specific to SVG and text

[19:22] <dbaron> rossen: how is this different than foreignObject?

[19: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.

[19:23] <dbaron> heycam: But for simple cases would be nice not to have to escape into HTML world.

[19:24] <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.

[19:24] <dbaron> dino: weird, x,y is bottom corner in SVG top corner in CSS

[19:24] <dbaron> heycam: In my approach, I switched on whether width was specified, and made x,y be top/left when width was specified

[19:24] <dbaron> heycam: definitely would want to specify it like that, now you're in CSS mode, read over here

[19:25] <dbaron> tav: in that case fallback doesn't work

[19:25] <dbaron> dino: I'm not so worried about fallback

[19:25] <dbaron> dirk: margin/padding has.. (cutoff)

[19:25] <dbaron> doug: popular libraries like d3.js where people are doing labels

[19:25] <dbaron> doug: script library that makes SVG diagrams very easy

[19:25] * Koji Quit (Ping timeout: 180 seconds)

[19:25] <dbaron> doug: I talked to several people using d3, people want wrapping text without having to use HTML

[19:26] <dbaron> doug: for those cases having fallback to older browsers woud be really nice, fall back to one line

[19:26] <dbaron> doug: this is why I mentioned alignment-baseline

[19:26] <dbaron> doug: could say whether origin affects glyph cell or character cell, top/left or baseline

[19:26] <dbaron> doug: dino, I'm fine with saying "this is a CSS block and behaves like one"

[19:27] <dbaron> doug: whatever's easiest for implementors and authors... authorswould expect padding/argin

[19:27] <dbaron> dino: then hyphenation, kerning, etc.

[19:28] <dbaron> heycam: for nonwrapping case we'll just make all CSS properties work on single-line text too

[19:28] <dbaron> heycam: at least in Firefox (soon) we'll just do CSS layout underneath for text, so easy to let properties just work

[19:28] <dbaron> dino: so you're suggesting effectively flatten text content of element

[19:28] <Bert> s/argin/margin/

[19:28] <dbaron> dino: basically flatten tspan positioning

[19:28] <dbaron> dino: if I say text width is 100 and inside tspans with x and y... tspans get thrown out

[19:29] <dbaron> heycam: tspans are effectively spans even in the single line case

[19: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

[19:29] <dbaron> doug: to allow simple breaking in SVG so you didn't have to pull in HTML to do paragraph

[19:29] <dbaron> doug: obviously lists etc. out of scope

[19:30] <dbaron> doug: for simple text breaking thought could use tspans for that

[19:30] <dbaron> dino: should be a single block

[19:30] * Koji has joined #css

[19:30] <dbaron> dino: if you want >1 block, use HTML

[19:30] <dbaron> dirk: why not have new element in SVG for anything from HTML world?

[19:30] <dbaron> heycam: like foreignObject?

[19:30] <dbaron> dirk: with no <html><body> etc.

[19:30] <dbaron> dirk: inside this tag you have HTML world

[19:30] <shepazu> q+

[19:30] * Zakim sees shepazu on the speaker queue

[19:31] <fantasai> dbaron: You don't need <html><body> etc. inside <foreignObject>. Do need namespace

[19:31] <dbaron> dbaron: how much more violent agreement do we need here?

[19: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.

[19:32] <dbaron> r12a: when you collapse the tspans, how do you separate the last word in the first tspan and the first in the next?

[19:32] <dbaron> heycam: don't really collapse

[19:32] <dbaron> dino: meant just ignore x and y attributes and use them as spans

[19:32] <dbaron> doug: I think these details can be sorted out in spec... don't need to go into them in this meeting.

[19:32] <dbaron> doug: What I'd like in this meeting is ...

[19:32] <dbaron> doug: was some concern in SVG F2F that CSS WG might have some objections

[19:33] <dbaron> dougt: so we wanted to socialize it with CSS WG

[19:33] <dbaron> s/dougt/doug/

[19:33] <dbaron> doug: so we wanted to make sure thought a good path forard

[19:33] <dbaron> doug: don't know if we need a resolution per se

[19:33] <dbaron> doug: nice to know if this is a reasonable direction

[19:33] <dbaron> glazou: I think you have that consensus.

[19:34] <dbaron> Bert: I'm not going to say what SVG should do... but why not just stick with foreignObject?

[19:34] <dbaron> Tab: You need to give it a height, you can't just flow an amount of text in.

[19:34] <dbaron> doug: Bert, the answer I've gotten from people doing it every day, people want 1 element rather than 6.

[19:34] <dbaron> Bert: soon you'll need hyperlinks, hyphenation

[19:34] <dbaron> various: already have those

[19:35] <dbaron> doug: if you need anything more complicated, you can use foreignObject

[19:35] <dbaron> Bert: fine by me, just seems like double-work for half solution

[19:35] <dbaron> Bert: but no objection

[19:36] <jdaggett> google japan cafe is yummy!!

[19:37] <Zakim> -jdaggett

[19:37] * heycam is now known as heycam|away

[19:37] <Zakim> -Doug_Schepers

[19:37] * r12a Quit (Client closed connection)

[19:37] * krit Quit ("Leaving.")

[19:37] <dbaron> <br class="lunch" data-endtime="13:00">

[19:38] * jdovey Quit (jdovey)

[19:39] * sgalineau has joined #css

[19:40] * shige-o has joined #css

[19:41] * myakura Quit ("http://www.mibbit.com ajax IRC Client")

[19:42] * AndChat|474201 has joined #css

[19:42] * Rossen Quit (Ping timeout: 180 seconds)

[19:43] * AndChat-474201 has joined #css

[19:44] * shige-o Quit (Client closed connection)

[19:46] * shige-o has joined #css

[19:47] * AndChat-474201 Quit (Client closed connection)

[19:47] * AndChat-474201 has joined #css

[19:48] * jet Quit (jet)

[19:49] * AndChat|474201 Quit (Ping timeout: 180 seconds)

[19:53] * shige-o Quit (Ping timeout: 180 seconds)

[19:56] * sgalineau Quit ("Textual IRC Client: www.textualapp.com")

[19:58] * jdaggett Quit (jdaggett)

[20:06] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)02:01Z

[20:06] <Zakim> Team_(css)02:01Z has ended

[20:06] <Zakim> Attendees were Doug_Schepers, Meeting_Room, jdaggett

[20:13] * glazou Quit (glazou)

[20:22] * stakagi Quit (Ping timeout: 180 seconds)

[20:27] * Cyril_ has joined #css

[20:29] * Cyril Quit (Ping timeout: 180 seconds)

[20:29] * Cyril_ is now known as Cyril

[20:32] * heycam|away is now known as heycam

[20:32] * Cyril lunch was great

[20:39] * jdaggett has joined #css

[20:46] * krit has joined #css

[20:48] * glazou has joined #css

[20:49] * Rossen has joined #css

[20:49] * AndChat-474201 Quit (Client closed connection)

[20:49] * shige-o has joined #css

[20:49] * shige-o Quit ("Bye")

[20:49] * shige-o has joined #css

[20:52] * shige has joined #css

[20:52] * zcorpan Quit (Ping timeout: 180 seconds)

[20:55] * jdaggett Quit (Ping timeout: 180 seconds)

[20:58] * jet has joined #css

[20:59] * jdovey has joined #css

[21:00] * stakagi has joined #css

[21:00] <fantasai> Scribe: fantasai

[21:01] * myakura has joined #css

[21:01] <fantasai> cabanier: Compositing and Blending Level 1

[21:01] <fantasai> cabanier: Last year in Hamburg, made a proposal

[21:01] * jdaggett has joined #css

[21:01] <fantasai> cabanier: Since then trying to simplify the spec, to make sure can be implemented easily in browsers

[21:01] <fantasai> cabanier: Removed compositing in CSS

[21:01] <fantasai> cabanier: areas, removed that as well

[21:01] <jerenkrantz> does someone have the latest link for the ED?

[21:02] <fantasai> cabanier: also knock-out feature removed, because hard to implement

[21:02] * jdaggett what's the topic?

[21:02] <cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html

[21:02] * heycam Compositing and Blending

[21:02] * jdaggett thx

[21:02] <fantasai> cabanier: Only 3 properties left in CSS:

[21:02] <fantasai> mix-blend-mode

[21:02] <fantasai> isolation

[21:02] <fantasai> background-blend-mode

[21:03] <fantasai> cabanier: Change to bg blend-mode, only defines how backgrounds blend with each other. Simpler to implement

[21:03] <fantasai> cabanier: mix-blend-mode also restricted only to things inside its stackign context

[21:03] <heycam> i/Compositing and Blending Level/Topic: Compositing and Blending

[21:04] <fantasai> cabanier: Also specs out canvas

[21:04] <dbaron> q+ to comment on mix-blend-mode

[21:04] * Zakim sees dbaron on the speaker queue

[21:04] <dbaron> q+ to comment on background-blend-mode

[21:04] * Zakim sees dbaron on the speaker queue

[21:04] <fantasai> cabanier: different blend modes for canvas

[21:04] <fantasai> cabanier: implemented in FF, webkit

[21:04] <fantasai> cabanier: patches

[21:04] <jerenkrantz> what was the URL for that demo?

[21:05] <fantasai> cabanier shows off demo of canvas and different blend modes

[21:05] <fantasai> cabanier: If there's ocntent behind this box, won't affect blending with that content

[21:05] <fantasai> cabanier: Third feature is blending of elements

[21:05] <fantasai> cabanier: shows some text over an image, with different blend modes

[21:06] <fantasai> cabanier: Want to know if people are keen

[21:06] <fantasai> cabanier: mix-blend-mode creates a stacking context

[21:06] <fantasai> cabanier: and will blend only with things inside its stacking context

[21:06] <jerenkrantz> Link appears to be: http://codepen.io/adobe/pen/nmfic

[21:07] <fantasai> dbaron: Part of what I was proposing was creating a stacking context

[21:07] <fantasai> dbaron: I would need to think more about blending only with things in its stacking context.

[21:07] <fantasai> dbaron: It's probably okay

[21:08] <fantasai> cabanier: Talked to roc and ppl on Chrome compositor team

[21:08] <fantasai> cabanier: roc def ok with this, Chrome team seemed ok with it

[21:08] <fantasai> dbaron: Other concern was, are there enough use cases for background-blend-mode to justify a separate property

[21:09] <fantasai> dbaron: Can certainly make some nice demos with it, but how many real author use cases will it work for?

[21:09] <fantasai> cabanier: If you want a gradient e.g. that goes over an image, or enhance contrast of an image

[21:09] <fantasai> dino: Question is, why not use tool offline

[21:09] <fantasai> cabanier: If you want to animate it, hard to do with a tool

[21:10] <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

[21:10] <fantasai> krit: ...

[21:10] <fantasai> krit: text blended with background, very strong use cases

[21:10] <fantasai> krit: moreso in SVG world, because of different shapes

[21:10] <fantasai> krit: In HTML itself, text is very strong use case

[21:10] <fantasai> cabanier: They're talking about backgrounds

[21:10] <fantasai> krit: oh

[21:11] <fantasai> cabanier: It could be extended later

[21:11] <fantasai> cabanier: Some people made proposals wrt adding filters on top of it

[21:11] <fantasai> cabanier: could come in nicely

[21:11] <fantasai> krit: Filter has filter image functions

[21:11] <fantasai> krit: This could also be blended

[21:11] <fantasai> krit: ... isolation group

[21:11] <fantasai> krit: If you have different background layer, [...]

[21:12] <fantasai> krit: Filter effects has a filter() function, which takes CSS image as input

[21:12] <fantasai> krit: And can be animated

[21:12] <fantasai> krit: You can have different layers in background, some filtered, and can be blended with other layers

[21:12] <fantasai> cabanier: background-blend-mode is much lighter

[21:13] <fantasai> cabanier: using mix-blend-mode for this would create lots of layers

[21:14] <cabanier> http://codepen.io/seraphzz/pen/houAe

[21:14] <dbaron> dirk: I think we can agree mix-blend-mode is the most important

[21:15] <fantasai> dino: ... not as powerful or useful. mix-blend-mode is what we really want to expose, but is very powerful and complicated

[21:15] <fantasai> krit: As specified, no so complicated

[21:15] <fantasai> dino: With disadvantage that authors have to understand when a stacking context may or may not appear in their content

[21:15] <fantasai> dino: Expect that rounds down to 0% of authors.

[21:16] <fantasai> ...

[21:16] <fantasai> dino: As soon as you hover over a div, that because its opacity changed, blending mode changed

[21:17] <dbaron> cabanier: we want to be able to do that later, though. And might be able to use new value of 'isolate' property.

[21: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

[21:17] <fantasai> krit: Saying "these properties create an isolation group", don't have to know about stacking contexts

[21:17] <fantasai> dino; that's handling it in one way

[21:18] <fantasai> dino: You specify starting blending

[21:18] <fantasai> ...

[21:18] <fantasai> dbaron: Disagree with Rik's comment wrt adding ability to blend with opacity later

[21: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

[21:18] <fantasai> heycam: Would add a new value to isolation

[21:19] <dbaron> dbaron: does the new value go on the element being blended or the one making the stacking context?

[21:19] <dbaron> ?: new value goes on element making the stacking context

[21:20] <fantasai> dbaron: Kindof ugly

[21:20] <fantasai> cabanier: Could wait a few years, or have something useful now

[21:20] <fantasai> heycam: Is it bad to have this new isolation property value on the element that creates the stacking context?

[21:20] <jerenkrantz> (the seraphzz pen link doesn't seem to work with FF 21; but the adobe link does w/FF 21.)

[21:20] <fantasai> heycam: Or would you want to specify that where you're putting the blending operation?

[21:20] <dbaron> dbaron: no, it makes sense that it goes on the element forming the stacking context

[21:21] <fantasai> dbaron: Think people will probably put * { isolation: new-value; } and not worry about it

[21:21] <fantasai> cabanier: Not great for performance

[21:21] <fantasai> cabanier: So, maybe don't want to do that.

[21:22] <fantasai> dino: Suppose I've got this complicated document

[21:22] <fantasai> dino: Copy it to another document that has a video in it, suddenly doesn't work

[21:22] <fantasai> dino: Have document with 3 children, they blend with each other

[21:22] <fantasai> dino: I set the opacity on the middle one. What about it's children?

[21:22] <fantasai> cabanier: That's all fine

[21:23] <fantasai> cabanier: If your parent has opacity, you won't blend with its parent

[21:24] <fantasai> ...

[21:24] <fantasai> dino: so, everything blends in its regular order in the document

[21:24] <fantasai> krit: ... z-index

[21:25] <fantasai> dino gives example of child with video descendant

[21:26] <fantasai> ...

[21:26] <fantasai> dino: It's easy for Core Animation's compositor, can specify blending of child into its parent

[21:26] <krit> s/... z-index/z-index creates a stacking context and content can not blend with everything beyond it/

[21:26] <fantasai> dino: But what looks like parent-child relationship in HTML document isn't necessarily that simple in compositor

[21:26] <fantasai> dino: Example is 3D transforms

[21:26] <fantasai> dino: ...

[21:27] <fantasai> dino: Disconnected form your parent, so can't blend into it

[21:27] <fantasai> cabanier: At some point the 3D object is composited though

[21:27] <fantasai> dino: You could hit significant perf problems without knowing why

[21:27] <fantasai> dino: Have to flatten the 3D world

[21:27] <fantasai> dino: get those bits, etc.

[21:27] <fantasai> cabanier: it's the same math

[21:28] <fantasai> ...

[21:28] <fantasai> dino: [something about not using compositing for web content]????

[21:29] <fantasai> dbaron: What do you mean by not using compositing?

[21:29] * fantasai missed the answer

[21:30] <fantasai> dino: have to manipulate tree heavily to do things like clipping, overflow, scrolling

[21:30] <fantasai> dino: Compositing has perf benefits with massive complexity

[21:30] <fantasai> dino: Makes it harder to add useful things like blending

[21:30] * fantasai can't hear krit

[21:31] <fantasai> krit says something

[21:32] <fantasai> dino: If you don't add the feature, people assume it's not there.

[21:32] <fantasai> dino: For widows and orphans, couldn't implement initial value of 2 because people assumed there was no widow/orphan control

[21:33] <fantasai> dbaron: I don't think there's been enough review of this to say "yes this is good right now"

[21:33] <fantasai> cabanier: I would love more reviews

[21:33] <fantasai> dbaron: Review isn't magical that ppl can just do, there are problems you don't find until you try to implement

[21:34] <fantasai> dbaron: and others that you don't find until you have two implementations and realize they're not interoperable

[21:34] <fantasai> dbaron: I'm concerned also about use cases, and if this is addressing things authors really want t do.

[21:34] <fantasai> dbaron: But don't know how to find out if that's the case.

[21:34] <fantasai> cabanier: Designers use it all the time in Adobe products

[21: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.

[21:35] <fantasai> cabanier: Not replacing photoshop

[21:35] <fantasai> cabanier: But better to keep semantics than rasterizing

[21:35] <fantasai> dbaron: Anything else to discuss?

[21:35] <fantasai> cabanier: Don't think so

[21:35] <fantasai> dbaron: No objections now, but def want more time for ppl to look at this.

[21:36] <fantasai> cabanier: Testing feature behind flags

[21:36] <fantasai> fantasai: Do we need a new WD?

[21:37] <fantasai> RESOLVED: Publish WD

[21:37] * cabanier Quit ("Leaving.")

[21:38] * cabanier has joined #css

[21:38] <fantasai> Topic: min-zoom/max-zoom

[21:39] <dbaron> Topic: min-zoom/max-zoom media queries

[21:39] <fantasai> fantasai: Isn't the point of zoom to magnify things?

[21:39] <fantasai> heycam: Some people using mapping content using SVG

[21:39] * jet Quit (jet)

[21:39] <fantasai> heycam: want to do some kind of detail control

[21:40] <fantasai> heycam: Suggested this would be something to handle via Media Queries

[21:40] <fantasai> heycam: Situation is some iframes, several levels deep, want to know the zoom level of this map tile

[21: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

[21:41] <fantasai> heycam: e.g. have SVG image shown at 50% of intrinsic size

[21:41] <fantasai> Bert, dbaron: resolution/device-pixel-ratio ?

[21:42] * jet has joined #css

[21:42] <fantasai> heycam: Does that tell you that inner view is drawn at 4px per 1px of outer view?

[21:42] <fantasai> dbaron: Wrt device pixels

[21:43] <fantasai> heycam: ... See if that's what they need

[21:43] <fantasai> fantasai: it tells you the resolution

[21:43] <fantasai> fantasai: in device pixels per 'px', or 'in', or whatever

[21:44] <fantasai> heycam: asks for clarifications

[21:45] <fantasai> dbaron: It should work. Whether actually works in current implementations, might be a different

[21:45] * leaverou is now known as leaverou_away

[21:45] <dbaron> Need to clarify behavior of 'resolution' media queries under transforms, especially if transforms non-axis-aligned

[21:46] <fantasai> fantasai: I would say, no, transforms don't affect media queries

[21:46] <dbaron> ...but does viewBox?

[21:46] <fantasai> dbaron: But resizing due to change in viewbox would

[21:46] <fantasai> dbaron: I don't know that the spec is clearly enough defined to answer all these questions. Probably should be.

[21: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.

[21:47] <dbaron> ... and how it responds to desktop browser zoom, and mobile browser zoom

[21:47] <fantasai> dbaron: e.g. how does browser zoom ui work, particularly desktop vs. mobile, which have different concepts of zoom

[21:47] <fantasai> krit: Designers want to have different details depending on zoom level

[21:47] <dbaron> heycam: so if 'resolution' doesnt account for intermediate transforms, how amenable would you be to having one that does?

[21:48] <fantasai> ?: animation

[21:48] <Cyril> s/?: animation/cabanier: what about animations?/

[21: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

[21:48] <fantasai> heycam: So maybe I go back to talk about whether resolution should work or not

[21:49] <fantasai> glazou: David, you said that resolution, same thing

[21: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

[21:49] <fantasai> heycam: Yeah, author would want to say "here's how content looks at default size; at twice maginification, looks like this"

[21: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

[21:50] <fantasai> glazou: You can't distinguish between iPad Retina and tablet with zooming

[21:51] <fantasai> dbaron: Mobile browser zoom doesn't affect media queries, whereas desktop does

[21:51] <fantasai> dbaron: I agree with everything you said, glazou, but I also want to avoid duplication.

[21:51] <fantasai> dbaron: Think we need to be clear on all these things before adding more to thiem

[21:51] <fantasai> s/thiem/them/

[21:52] * dbaron Zakim, room for 4 for 180 minutes?

[21:52] <Zakim> ok, dbaron; conference Team_(css)04:51Z scheduled with code 26631 (CONF1) for 180 minutes until 0751Z

[21:53] <Zakim> Team_(css)04:51Z has now started

[21:53] <Zakim> +[IPcaller]

[21:53] <fantasai> fantasai: There are basically two types of scaling, graphical and logical.

[21:53] <jdaggett> zakim, ipcaller is me

[21:53] <Zakim> +jdaggett; got it

[21:53] <fantasai> fantasai: Sometimes you're just wnating to magnify what exists. Certain types of UI zoom, and transforms, fall into this category

[21:53] <fantasai> fantasai: Other times actually changing parameters of layout

[21:53] <fantasai> fantasai: Need to be clear on which effects go in which category.

[21:54] * liam has joined #css

[21:54] <fantasai> glazou: Zooming by user is a user constraint; zooming by author is an author constraint

[21:54] <fantasai> glazou: First one makes sense for zoom, second for resolution

[21:55] <Zakim> +??P1

[21: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

[21:55] * cabanier Quit ("Leaving.")

[21:55] * cabanier has joined #css

[21:55] * jdaggett hmm, someone joined the zakim room but can't hear anything...

[21:56] <shans__> jdaggett: that was me, just setting things up.

[21:56] * jdaggett ok, cool

[21:56] * cabanier Quit ("Leaving.")

[21:57] <fantasai> SimonSapin: This does not account for transforms

[21:57] * cabanier has joined #css

[21:57] * cabanier Quit ("Leaving.")

[21:57] * cabanier has joined #css

[21:57] * dino Quit (dino)

[21:57] <fantasai> dbaron: Might need another editor of MQ 4

[21:57] <fantasai> glazou: Florian is very busy right now, will have more time in a few months

[21:57] <fantasai> dbaron: Two big categories of changes

[21:58] <fantasai> dbaron: that need to happen

[21:58] <fantasai> dbaron: We talked very briefly of doing syntax changes

[21:58] <fantasai> dbaron: To be closer to @supports

[21:58] <fantasai> dbaron: Other was adding queries to represent everything in media types, deprecating media types

[21:58] <fantasai> dbaron: But those ar ebiger things

[21:58] <krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/masking/index.html#the-clip-path

[21:59] <fantasai> s/ar ebiger/are bigger/

[21:59] * dbaron Zakim, ??P1 is Meeting_Room

[21:59] * Zakim +Meeting_Room; got it

[22:00] <fantasai> krit: Security question wrt basic shape

[22:00] <fantasai> krit: Can use CSS shapes to define a clipping area

[22:00] <fantasai> krit: Here's an image, can define a clip path on it.

[22:00] <fantasai> krit: Can also be animated

[22:00] <fantasai> krit: Quite easy to apply this clip path

[22:00] <fantasai> krit: Problem is the following

[22:01] <fantasai> krit: Usually you have clip-path inline in your style sheet

[22:01] <fantasai> krit: Can also cross-reference path from a different domain

[22:01] <fantasai> krit: Suppose, e.g. style sheet on mybank.com

[22:01] <fantasai> krit: evil.com tries to reference it

[22:01] <fantasai> krit: question is, can any private data come from this style sheet

[22:02] <fantasai> krit: ... pointer events

[22:02] <fantasai> krit: If you cliip to circle, outside that doesn't contribute to clipping area

[22:02] <fantasai> krit: Suppose one domain uses clip path to show password or something

[22:02] <fantasai> krit: If you clip anything with this letter here, then the areas outside it don't contribut to hit testing

[22:02] <fantasai> krit: So could scan the clipping path and reingineer what the clip-path could look like

[22:03] <fantasai> dbaron: I think anyone using clip-path to use confidential data is doing it wrong.

[22:03] <fantasai> dbaron: If that's the attack, I'm not that worred about it!

[22:03] <fantasai> dbaron: I would be more worried about an attack that involved treating other data as pieces of a CSS style sheet

[22:04] <fantasai> dbaron: e.g. send someone an email message with some CSS in the subject

[22:04] <fantasai> dbaron: And then closing equivalent to that in another message

[22:04] <fantasai> dbaron: Could retrieve all the subjects in between by requesting a particular URL from Yahoo.

[22:04] <fantasai> dbaron: That I'd be worried about

[22:04] <fantasai> dbaron: But this I'm not worried about

[22:05] <fantasai> glazou: I'm not that worried...

[22:05] <fantasai> Alan asks about some other shape image thing

[22:06] <fantasai> krit: Very weird case. Only one I could come up with as an issue

[22:06] <fantasai> heycam: What if you had a style sheet that just had content property, did hit testing on content

[22:06] <fantasai> krit: That would be a bigger security issue.

[22:07] <fantasai> fantasai: Putting sensitive data in a style sheet's content property also makes no sense at all.

[22:08] <fantasai> heycam discusses other ways of exposing things in the same way

[22:08] * lmclister has joined #css

[22:08] <fantasai> s/ways of/properties/

[22:09] * Kazutaka Quit (Ping timeout: 180 seconds)

[22:09] <fantasai> ...

[22:10] <fantasai> krit: If we agree this is a security problem, then our options are to remove [...]

[22: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.

[22:10] <fantasai> dbaron: I think we pretty much agree that it's not a security problem we want to fix.

[22:10] <fantasai> dbaron: We could put a note in the spec, that authors shouldn't put sensitive info in clip path

[22:10] <dbaron> (unless there's a worse case that we haven't heard yet)

[22:11] <fantasai> Alan, heycam: Don't think this is an issue

[22:11] <heycam> s/heycam/dino/

[22:12] <fantasai> Bert: Position div for each pixel of your password

[22:12] <dbaron> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0012.html

[22:12] <fantasai> dino: I don't know why we're even discussing this.

[22: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

[22:13] <fantasai> RESOLVED: We don't care, unless bz can come up with something more convincing

[22:14] <fantasai> Topic: SVG text-wrapping

[22:14] <fantasai> tav: Things we would most need from Exclusions and Shapes have been removed from latest drafts

[22:14] <fantasai> tav: shape-inside

[22:14] <fantasai> tav: And using SVG paths and shapes

[22:14] <fantasai> Alan: My plan for that is to have that in next level of CSS Shapes

[22:15] <fantasai> Alan: I'm trying to constrain first level of spec ot stuff that is most immediately useful to CSS at the moment

[22: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

[22:15] <fantasai> glazou: Problem is referencing a non-normative document

[22:16] * krit has left #css

[22:16] <fantasai> glazou: Discusison in AC forum, W3C suggested references can only be W3C RECs. Document referencing WD can't go to REC

[22:16] * krit has joined #css

[22:16] <fantasai> plh: But can go to PR. Just can't go to REC.

[22:17] <fantasai> fantasai: I don't think this will be an issue

[22:17] <fantasai> plh: For the record, Robin Berjon started a thread on chairs list wrt dependencies

[22:17] <fantasai> Alan: Noted, haven't created L2 document yet

[22:17] * nikos Quit (nikos)

[22:18] <fantasai> Alan: question of whether to make L2 doc to park these things in

[22:18] <fantasai> TabAtkins: Make ssense. Just put <details class=obsolete> and note things

[22:18] <dbaron> So I think Boris's concerns in that thread are actually somewhat different from that contrived bank case.

[22:18] <fantasai> TabAtkins: Maybe I'll rename the class

[22:18] <dbaron> maybe more like http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0008.html

[22:19] <fantasai> Topic: security

[22:20] <fantasai> dbaron: Involves using clip-path on attacker site over <iframe> to victime site.

[22:20] <fantasai> dbaron: That's more concerning.

[22:20] <fantasai> dbaron: But not useful to discuss here.

[22:20] <fantasai> dino: How is it more of a problem than overflow?

[22:20] <fantasai> dbaron: Not different.

[22:20] <dbaron> message from roc: http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html

[22:20] <fantasai> krit: [stuff]

[22:21] <fantasai> dbaron: The attack I described wasn't what bz described

[22:22] <fantasai> dbaron: This is stuff that needs to be thought about longer. We should be fine, I think.

[22:22] <dbaron> ... since bz was describing something that would be fixed by rejecting clip-path for cross-origin non-CORS style sheets

[22:22] <fantasai> heycam: been awhile since roc's message. should someone look at that?

[22: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

[22:23] <dbaron> s/doesn't cover/isn't fixed by/

[22:23] <fantasai> Topic: Figuring out the CSSWG agenda

[22:24] <glazou> http://wiki.csswg.org/planning/tokyo-2013?&#agenda

[22:24] * r12a has joined #css

[22: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./

[22:26] * jdaggett let the minutes record much mubbling

[22:27] * plh and part of it was french mubbling :)

[22:27] * krit has left #css

[22:27] * krit has joined #css

[22:29] * heycam would like to be here for Conditional Rules, Cascade, Variables -- so before Thursday afternoon

[22:34] * shige_ has joined #css

[22:37] * jdaggett runs out for a sec to pee...

[22:37] * jdaggett is now known as jdaggett|pee

[22:39] * shige Quit (Ping timeout: 180 seconds)

[22:40] * TabAtkins tmi, jdaggett

[22:41] * jdaggett|pee is now known as jdaggett

[22:42] * liam pleased to be able to follow the meeting in so much detail? :-)

[22:43] <r12a> http://www.w3.org/International/docs/counter-styles/Overview.html

[22:44] <dbaron> http://dev.w3.org/csswg/css-counter-styles-3/

[22:45] <dbaron> there's one issue listed in http://dev.w3.org/csswg/css-counter-styles-3/#ethiopic-numeric-counter-style

[22:45] <dbaron> Topic(a few lines back): Counter Styles

[22:46] * Rossen Quit (Ping timeout: 180 seconds)

[22: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

[22:47] <fantasai> Discussion of whether to publish Counter Styles as LC

[22:48] <dbaron> want to link to r12a's document, which is to be published as a note

[22:48] <fantasai> Richard posts the i18n note wrt @counter-style rules for various scripts

[22:48] <dbaron> glazou: should we give people a few weeks to review

[22:48] <dbaron> fantasai: we already did that

[22:49] <dbaron> I'm fine with going to LC, though I'm really not sure how high of an implementation priority this is for anyone.

[22:49] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0757.html

[22: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

[22:51] * fantasai was on break most of last week

[22:51] <TabAtkins> http://dev.w3.org/csswg/css-cascade/#cascade

[22:51] <fantasai> ScribeNick: fantasai

[22:51] <fantasai> TabAtkins: This is in section describing how levels of things are handled

[22:51] <fantasai> TabAtkins: We inserted Scope in the middle here

[22:51] <fantasai> TabAtkins: Scoped style sheets always win over unscoped styles

[22:52] <fantasai> TabAtkins: Scoping something further down in the document overrides coping rules further up i nthe document

[22:52] <fantasai> TabAtkins: Question is , does this sound sufficient for a spec defining this?

[22:52] <fantasai> TabAtkins: Think it is correct

[22:52] <fantasai> fantasai: By default, inner scopes win over outer scopes

[22:53] <fantasai> fantasai: But for !important rules, order is reversed

[22:53] * Rossen has joined #css

[22:53] <fantasai> fantasai: Outer !important rules override inner !important

[22:54] <fantasai> dbaron: Other alternative is for inner !important to win over outer !important

[22:54] <fantasai> heycam: I think the current spec is a nice parallel with how origins work

[22:55] <fantasai> fantasai: I think this gives !important a useful purpose in negotiating rules between inner and outer scopes

[22:55] <fantasai> fantasai: So somewhat prefer this behavior

[22:55] <fantasai> TabAtkins: Seems from heycam that the spec is clear enough

[22:56] <fantasai> Bert: Why have scopes be special, why not have it same as ID selector

[22:56] <fantasai> glazou: I proposed that several times, was turned down

[22:57] <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

[22:57] <fantasai> Bert: That's what I expect

[22:57] <fantasai> dbaron: That's not what authors expect

[22:57] <fantasai> TabAtkins: Point is that scoped rules apply only to your bit, and can have short, simple selectors

[22:57] <fantasai> TabAtkins: Lends itself to lower-specificity selectors

[22:58] <fantasai> TabAtkins: Rules that apply to whole document tend to be more verbose, more specific

[22:58] <fantasai> TabAtkins: Want the simpler scoped rules to still override document-wide, more-specific rules

[22:58] <fantasai> Bert: But adding new concept

[22:59] <fantasai> glazou: It's equivalent to adding a 4th argument to specificity

[22:59] <fantasai> s/equivalent/similar/

[22:59] <fantasai> Bert: span.foo { blue } vs. scoped span { green }

[23:00] <fantasai> Bert: Expect <span.foo> to be blue, not gree.

[23:00] <fantasai> dbaron: Expect it to be green

[23:00] <fantasai> s/gree/green/

[23:00] * dbaron supposes we shouldn't have gotten into this discussion

[23:00] * myakura Quit ("http://www.mibbit.com ajax IRC Client")

[23:01] * TabAtkins Indeed.

[23:01] <fantasai> glazou: Last time we discussed this, the painful bit was only adding dynamically adding styles [?]

[23: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

[23:01] <fantasai> plh: Not implemented though, so haven't played with it.

[23:03] <fantasai> RESOLVED: Close issue on how !important interplays with scoped styles

[23:03] <glazou> <br type="break"/>

[23:05] * stakagi Quit (Client closed connection)

[23:08] * Rossen Quit (Ping timeout: 180 seconds)

[23:13] * r12a Quit (Client closed connection)

[23:14] * krit Quit ("Leaving.")

[23:14] * cabanier Quit ("Leaving.")

[23:18] * Cyril noted a typo in the introduction of CSS Cascade level 3 "try to set a the value"

[23:22] * tobie has joined #css

[23:23] <TabAtkins> Cyril: Thanks!

[23: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?

[23:28] <jdaggett> fantasai: i actually don't think we'll be able to deal with fonts/text/text-decoration all in the morning

[23:29] * AndChat|474201 has joined #css

[23:29] <jdaggett> fantasai: guess we can try though

[23:29] <fantasai> TabAtkins: Continuing with 'default' keyword

[23:30] <jdaggett> reference url?

[23:30] <jerenkrantz> http://dev.w3.org/csswg/css-cascade/#default

[23:30] <fantasai> dbaron: I had initially proposed default as something else, as initial/inherit. Still would like that behavior.

[23:31] * Tav Quit (Ping timeout: 180 seconds)

[23:31] <fantasai> TabAtkins: The reason I don't want to do that, doesn't do what authors want

[23:31] <Zakim> -Meeting_Room

[23:31] <jdaggett> um, phone dropped

[23:32] * myakura has joined #css

[23:32] <jdaggett> shans__: ^

[23:32] <fantasai> TabAtkins: E.g. want "default" to mean "display: block/inline" depending on whether <p> or <span>

[23:32] <dbaron> jdaggett, ack

[23:32] * birtles Quit (Ping timeout: 180 seconds)

[23:32] <fantasai> dbaron: Not always. E.g. reset stylesheets want my behavior

[23:32] <dbaron> jdaggett, apparently it's because shane left

[23:32] <fantasai> TabAtkins: Don't think we need to cater to reset style sheets

[23:32] <jdaggett> dbaron: you guys dropped off the call!!

[23:32] <jdaggett> ah

[23:32] * Rossen has joined #css

[23:32] * nikos_office is now known as nikos

[23:32] * nikos has joined #css

[23:33] <dbaron> jdaggett, apparently it requires a computer that can get on the corp network, which tab's can't

[23:33] <fantasai> fantasai: Could add special ability to 'all' shorthand

[23:33] * Zakim fantasai, you typed too many words without commas; I suspect you forgot to start with 'to ...'

[23:33] * TabAtkins jdaggett, just a sec, we need to find Shane again.

[23:33] * jdaggett heh, that low-security tab...

[23:33] * jdaggett ok

[23:33] <fantasai> dbaron: The other issue with this definition of default is that it's a decent amount of work to implement

[23:33] <fantasai> TabAtkins: Won't disagree with that

[23:34] <fantasai> SimonSapin: Think it requires keeping around multiple specified values

[23:34] * shige_ Quit (Ping timeout: 180 seconds)

[23:34] * shans___ has joined #css

[23:34] <fantasai> TabAtkins: Don't have to keep things around, just might need multiple passes, and just for elements it shows up on

[23:34] <fantasai> SimonSapin: Isn't that similar perf cost with variables?

[23:34] <shans___> what is the zakim bridge conference id?

[23:34] <fantasai> dbaron: It can be done without that perf cost

[23:34] <jdaggett> 26631

[23:35] * shige-o Quit (Ping timeout: 180 seconds)

[23:35] <dbaron> "This passcode is not valid."

[23:35] <plinss> zakim, code?

[23:35] <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), plinss

[23:36] <shans___> need a new one

[23:36] <Zakim> -jdaggett

[23:36] <Zakim> Team_(css)04:51Z has ended

[23:36] <Zakim> Attendees were jdaggett, Meeting_Room

[23:36] <dbaron> Zakim, room for 5 for 150 minutes?

[23:36] <Zakim> ok, dbaron; conference Team_(css)06:36Z scheduled with code 26632 (CONF2) for 150 minutes until 0906Z

[23:36] <dbaron> shans___, ^

[23:37] * shans__ Quit (Ping timeout: 180 seconds)

[23:37] <Zakim> Team_(css)06:36Z has now started

[23:37] <Zakim> +[IPcaller]

[23:37] <jdaggett> zakim, ipcaller is me

[23:37] <Zakim> +jdaggett; got it

[23:37] * dbaron Zakim, [IPcaller] is jdaggett

[23:37] * Zakim sorry, dbaron, I do not recognize a party named '[IPcaller]'

[23:37] * jdaggett zakim, i do so love your fickle ways

[23:37] * Zakim I don't understand 'i do so love your fickle ways', jdaggett

[23:37] * zcorpan has joined #css

[23:38] * zcorpan Quit (Client closed connection)

[23:38] <dbaron> "This passcode is not valid."

[23:38] <Zakim> +??P1

[23:38] * zcorpan has joined #css

[23:38] <dbaron> Zakim, ??P1 is Meeting_Room

[23:38] <Zakim> +Meeting_Room; got it

[23:38] <jdaggett> ok, good good

[23:38] <jdaggett> yes

[23:38] <jdaggett> default was the topic...?

[23:39] <jerenkrantz> jdaggett: yes

[23:39] <fantasai> TabAtkins: I don't really want initial-or-inherit. No use case for it

[23:39] <glazou> jdaggett, yes

[23:39] <fantasai> dbaron: Use it internally a lot

[23:39] <fantasai> dbaron: e.g. Web Components style reset

[23:39] <fantasai> dbaron: Think that basically is equivalent to all:initial-or-inherit

[23:40] <fantasai> TabAtkins: Given that those don't have any UA style rules anyway... I think that's equivalent to 'default'

[23:41] * Ms2ger has joined #css

[23:41] <fantasai> heycam: want s/continues/repeats/ ?

[23:42] <fantasai> TabAtkins clarifies what default does

[23:42] <fantasai> ACTION TabAtkins clarify what default does

[23:42] * trackbot is creating a new ACTION.

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

[23:42] <Zakim> -jdaggett

[23:43] <fantasai> dbaron: Putting !important and normal together makes it harder to implement

[23:44] <jdaggett> argh, back in a sec

[23:44] <fantasai> dbaron: Implementation I would take would do the wrong thing for user !important and ua !important

[23:45] <fantasai> dbaron: Current spec, user !important rule says go use the author styles

[23:45] * zcorpan Quit (Ping timeout: 180 seconds)

[23:45] <fantasai> dbaron: But if no author styles, don't use user styles

[23:45] <fantasai> TabAtkins: No, no, we only glom together all the author styles.

[23:45] <fantasai> TabAtkins: You still keep user as an origin level

[23:46] <Zakim> +[IPcaller]

[23:46] <jdaggett> zakim, ipcaller is me

[23:46] <Zakim> +jdaggett; got it

[23:46] <fantasai> dbaron: Ok, that's fine

[23:46] <fantasai> dbaron: But make it clearer

[23:47] <fantasai> fantasai: We could put in a simplified cascade list, just to make it more obvious

[23:48] <fantasai> fantasai: Any other concerns with default?

[23:48] <fantasai> fantasai: Do we want an initial-or-inherit keyword?

[23:48] <fantasai> TabAtkins: I suggest using actually 'initial-or-inherit'. Want to steer authors to 'default', since that's usually the right answer.

[23: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

[23:48] <fantasai> dbaron: Would like to see a keyword for that

[23:49] <fantasai> Bert: Would like to understand better what this is used for

[23:49] <fantasai> TabAtkins: You use it in most use cases for dbaron's examples, except this is the better answer in most cases

[23: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

[23:50] <fantasai> TabAtkins: Point is to wipe out whatever author has done

[23:50] <fantasai> TabAtkins: This is better because it respects user styles

[23:51] <fantasai> TabAtkins: And UA styles

[23:51] <fantasai> TabAtkins: Most authors don't understand difference between initial value and UA default value

[23:51] <fantasai> TabAtkins: This lets you not worry about that

[23:51] * shige-o has joined #css

[23:52] * AndChat|474201 Quit (Client closed connection)

[23:52] <fantasai> ...

[23:53] <fantasai> plinss: This removes your rules.

[23:53] <fantasai> TabAtkins: Not sure whta you're objecting to, what you're asking for is exactly what this does.

[23:53] <fantasai> Bert: You said it's easy to specify a generic rule, and override a specific case

[23:54] <fantasai> Bert: span { color: green; } span.foo { color: default; }

[23:54] <fantasai> Bert: Then I get inherited

[23:54] <fantasai> TabAtkins: That's what you get, unless user or UA says something

[23:54] <fantasai> TabAtkins: Let me show different example

[23:55] <fantasai> TabAtkins: User says wants links are bright blue

[23:55] <fantasai> TabAtkins: Author styles links purple, except some links with class should use default colors

[23:55] <fantasai> TabAtkins: If you use 'initial' or 'inherit' to wipe out author rules, the colors will reset to black.

[23:55] <fantasai> TabAtkins: Doesn't go back to blue.

[23:56] <fantasai> Bert: Why would I want user's rule

[23:56] <fantasai> Bert: I don't know what they are

[23:56] <fantasai> plinss: That's the point

[23:56] <fantasai> TabAtkins: This goes back to "whatever style would be without my influence"

[23:57] * stakagi has joined #css

[23:57] <fantasai> Bert: Think examples would be good

[23:58] <fantasai> fantasai: Better example would be paragraphs. By default, have 1em margin on top and bottom.

[23: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.

[23:59] <fantasai> fantasai: If said 'initial', then would set margins to zero.

[23:59] <fantasai> Bert: i'm not convinced, but if you can get some examples in there, would help

These logs were automatically created by CSSWG_LogBot on irc.w3.org using the Java IRC LogBot.