<trackbot> Date: 05 June 2013

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

<jdaggett> oh dear

<glazou> why do you think we've not started yet ?

<jdaggett> google japan has no power strips?

<jdaggett> is brian birtles there? get him to run back to mozilla japan to fetch some

<jdaggett> he's a good runner!

<dbaron> birtles is here :-)

<jdaggett> haha

<jdaggett> i saw a big order come in last week...

<jdaggett> that stuff will kill you... ;)

<jdaggett> yikes

<jerenkrantz> Is there an agenda? Or, will we kick off with agenda bashing?

<stearns> the latter, usually

<glazou> jerenkrantz, what stearns said

<jdovey> beanbags & slingshots at the ready…

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

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

<dbaron> ScribeNick: dbaron

introductions

<liam> dbaron, I added a bullet item to that wiki page, telephone access

e), Alan Stearns (Adobe), Richard Ishida (W3C), Alan Stearns (Adobe), Bert Bos (W3C), Rossen Atanassov (Microsoft), Glenn Adams (Cox), Jet Villegas (Mozilla)

<heycam> http://www.pastebin.mozilla.org/2486303

Agenda

Peter: There's also an FXTF wiki for agenda items in addition to http://wiki.csswg.org/planning/tokyo-2013#agenda

heycam: The only ordering restriction is doug wants to call in for text wrapping, prefers early

is shepazu available now-ish?

<heycam> shepazu ^

Web Animations

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

dialing to Zakim failed, switching back to projector

<glazou> ROFL @ http://w3cmemes.tumblr.com/image/52183066977

<heycam> shepazu, yes feel free

birtles: wanted to give overview of web animation; getting close to asking for FPWD.

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

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.
... about 1 year ago, Adobe suggested I start concrete proposal for that; invited Shane (Google) to help, had suggestions about state machines
... presented last year in Hamburg, and FXTF agreed to take it on as a work item
... I've been working with Adobe and Google to produce specification

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

birtles: overview of what's in it in this diagram

birtles describes diagram

birtles: (part of diagram description) SVG features not in the model mostly are features that generate animations rather than animations themselves
... 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
... 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.
... Apple's request to split into 2 parts: model first, then script api.
... we're focusing on the model, but the API often generates the most controversy/feedback
... 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.
... The API is the controversial bit and the bit we really want toget right (hard to change later).
... About ready to ask for First Public Working Draft (FPWD) approval; a few edits we want to make first (drop a few interfaces).
... So what's there is hopefully what we'll be sending out later this week.
... So, just wanted to introduce this and ask if any immediate feedback or questions

dino: slightly concerned that media was dropped. One of the things we considered important from Apple's perspective.
... But I think this spec is in better shape before FPWD than most specs are after 5 or 6 WDs.

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.

dino: Nothing to stop a draft. Call out in the draft that it's been removed?

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.

stearns: on the other side: is there justification in the draft for the 4 new things in the model?
... rather than just describing the union?

birtles: there isn't extensive justification for each feature
... 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
... no justification per se except for use cases at te start

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?).
... 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.
... I think the strength of this spec is that it has a powerful API with a complete JS library.
... 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

<fantasai> dino: That's why we're interested in media

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.
... 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
... so a developer would approach authoring by saying from 10s-20s, this is the state that applies

<jdaggett> hmm, no zakim conf at 26631

dino: so you could write CSS that applies when that state is ative
... so a CSS developer could easily understand this -- no JS. When state applies, apply transitions/animations/styles/whatever.
... but adjacent to this spec
... more like what we were hoping to use this spec for

birtles: I should emphasize that the API is not fundamental to the model; you can implement the model without the api.
... Those parts which are outside the model but are in CSS or SVG are defined in separate specifications.

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

birtles: For the SVG parts, we'd have an SVG specification (my next task).
... Likewise CSS animations level 4 could be expressed in terms of that model
... in media... doing as a separate model...

<jdaggett> the 26631 one

dino: primary use case readalong books in iBooks -- a kids book that has, say, 3 lines of text on the page
... audio track in page, lines or words highlight along with audio track
... want to avoid using script

dirk: using SMIL for this?

dino: Ever tried writing that in SMIL? It's crazy.

birtles: next specification I'll be working on is SVG mapping onto the model

dirk: Your request is to review the spec give feedback, and end up with publishing FPWD.

birtles: yes, will send request later this week

dino: what's the state of your JS shim/polyfill?

birtles: I'm not contributing to that; Google is.

shane: what info do you want?

dino: how complete relative to spec?

shane: more complete than current spec? Up to date other than last 3-4 weeks.
... on github, open source license
... should be relatively easy for us to sync with last set of changes over a week or so

birtles: have some issues with events marked in spec with "feedback wanted" -- we want more input

glazou: did you want to ask for FPWD now?

?: or give people time to review?

dino: I think it's a high quality spec, I think the question is whether in scope or out of scope.

glazou: do people want time to review?

[various people happy with publishing]

Bert: no time to review before July anyway, so don't wait for me

RESOLUTION: Publish Web Animations as First Public Working Draft (resolved by both CSS and SVG WGs).

reusing stroke and fill properties

heycam: topic added from CSS side
... did someone have a specific proposal

Tab: it was me

fantasai: we've had requests to be able to do fill and stroke on letterforms
... webkit has text-stroke property. Might make more sense to reuse existing SVG properties.
... Complication is filling with pattern or image of some kind... how to handle line breaks is complicated
... stroking or filling with color is straightforward

heycam: why do line breaks complicate things?

fantasai: need to find the bounding box

[pause for Zakim debugging]

fantasai: might cut or take bounding box or separately per fragment

http://dev.w3.org/csswg/css-backgrounds/#box-decoration-break

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

<jdaggett> the webvtt guys have 'text-outline' as part of their spec

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

<jdaggett> fill/stroke would be a better way of supporting that

fantasai: do we reuse that property or have separate control?

heycam: what does box-decoration-break do? fantasai: determines how it's handled for borders and background

fantasai: That's background, this is about foreground.

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.

dirk: I think the first question is do we want something like that.
... Before we talk about page break or line break or whatever.

fantasai: simplest are fill-opacity and stroke; fill could deal with later

dirk: I think fill at least as important as stroke

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.
... want to be able to say fill text with gradient/color/pattern; seems pretty standard for CSS

fantasai: additional complication is that color inherits
... so each element paints with its own color property
... if you add more elements nothing changes unless you set properties on those elements
... you want pattern to be consistent across an entire paragraph
... with elements inside

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
... but for tspans within a text element we use the bounding box of the text element as a whole

dbaron: don't think (1) works with CSS model

heycam: agree
... so what happens with linear-gradient on a paragraph with multiple spans...

dbaron: background doesn't inherit

[not minuting entire discussion here]

<fantasai> dino notes that fill inherits

dino: fill/stroke/color inherit and background doesn't; don't want a new style of fill for every child

<fantasai> fantasai: that would be a problem

heycam: why would fill and color have different inheritance?

fantasai: if you're setting a pattern need to know which element initiated the pattern

heycam: seems odd for fill and color to have difference in whether they inherit, similar actions
... 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.

dirk: always have option to have different properties

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

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

<fantasai> heycam: ???

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

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

<fantasai> dbaron: latter of which has 'normal' and 'establish' or something

<fantasai> dino: You only want this fill/stroke to apply to text

dino: question is, do you only want this new fill/stroke to apply to text?

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

dino: that's one reason in webkit it's text-stroke
... do you ever want to stroke a box?

<fantasai> fantasai: That's what borders are for

fantasai: that's what borders are for

?: just on text

<shepazu> fantasai: that's what borders are for

dino: then why not just do text-fill and text-stroke

dirk: if you say ... should be a shorthand ... inheritance problem ...

dino: sounds fine to me

fantasai: in SVG stroke just sets color of something ... weird

heycam: might be beneficial for 'stroke' to be shorthand to stroke-paint and stroke-width and ...

fantasai: yes, that would follow pattern of CSS a lot better

dirk: what does stroke-paint stroke-width mean?

heycam: stroke-paint would be what stroke is currently

fantasai: you can set all the stroke-related properties
... if you just want to touch the color you say stroke-paint

heycam: might be more convenient for SVG anyway

fantasai: possible without breaking the Web?

heycam: yeah, probably

fantasai: depends how often people use it in CSS syntax rather than in SVG file
... because stroke-width: ...; stroke: ...; would reset the first

<shepazu> (what would stroke: blue; do?)

heycam: so I feel like somebody should look at these issues and come up with proposal forintegrating

dirk: problem here is we have the attributes
... [too fast]

heycam: we already decided to allow font shorthand as presentation attribute

<SimonSapin> shepazu, if it’s a shorthand, set stroke-paint to blue and stroke-width to the initial value

heycam: you take all the presentation attributes in a praticular order

dirk: cannot modify this order in te dom

<shepazu> SimonSapin, then it won't break the web

heycam: might not have made this change

fantasai: for surethe stroke attribute would map to stroke-paint... it would have to
... never mind

heycam: anybody think it's a bad idea to try to allow paints in stroking text?

Bert: principle is good, worried about syntax

fantasai: in SVG, if you stroke a letterform, where does the stroke lie with respect...

dirk: it half overlaps the fill

<jdaggett> seems like we need someone to work on a draft proposal

tav: can change the order now

heycam: does webkit-text-stroke paint on top of fill or beneath?

dirk: same as SVG

<jdaggett> i think you want to have inset/outset control

<jdaggett> look to postscript for a good model

tav: most of the time you want fill on top of stroke

fantasai: if you put fill on top of stroke, looks fine when fill is opaque, otherwise looks dumb
... would also lead to author confusion about stroke width
... so I agree with jdaggett, should have control over where stroke is centered

dirk: ???

<jdaggett> also, japan has *lots* of examples of double stroking of text

heycam: we have proposal for that

tav: should we put that in?

dirk; we did

<jdaggett> white stroke surrounded by black stroke

<shepazu> +1 to controlling stroke centering

Bert: if you're doing filling of text you might want text-shadow to have inset keyword

fantasai: inset in plans for text level 4

dirk: stroke and fill don't need to overlap... have a new property so they don't need to

heycam: called stroke-position?
... which we have a proposal for, to go in SVG2

fantasai: I think Tab and I can take an action to draw this one up.

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

ACTION fantasai with Tab, draw up proposal for using stroke and fill for CSS text

<trackbot> Created ACTION-562 - With Tab, draw up proposal for using stroke and fill for CSS text [on Elika Etemad - due 2013-06-12].

<glenn> +Present glenn

<fantasai> shepazu, call in

jdaggett: For text stroke and text fill, parameterization could be complication... would like to work through multiple proposals.

<jdaggett> muted

<TabAtkins> Cool, new meeting is working.

<jdaggett> yup

<jdaggett> that's me

<jdaggett> there's a tv nearby so i have to mute

text wrapping plans for SVG

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
... people may remember the proposal in SVG Tiny 1.2, for <textArea>, with text layout different from CSS... objections because different from CSS
... 2 things we want: (1) to do simple rectangular text and (2) text in shapes, which SVG also had a proposal for long ago
... so we want to follow CSS For text in shapes

<Tav> http://tavmjong.free.fr/SVG/TEXT_FLOW/

heycam: and we've been discussing simple discussion for our current text to wrap text to a particular width

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

heycam: tav will talk about what we need from arbitrary shapes perspective and doug will talk about simple rectangular wrapping

tav: This describes what's in SVG 1.2 flowed text. Partially implemented by Batik and Inkscape
... that didn't take -- was complicated and not consistent with CSS
... looked at what we can do to keep consistent with CSS.
... propose to use shape-inside, shape-outside, wrap-margin, wrap-padding
... here's an example, with a shape in an SVG circle

(showing examples from http://tavmjong.free.fr/SVG/TEXT_FLOW/ )

tav: mocked up flowing between shapes (from 1.2 proposal), though told this conflicts with regions from CSS
... and here's one with some exclusions
... a couple issues, 1 is CSS region seems overkill for our needs
... and not close to being finished

stearns: what you want that's different is a comma-separated list of regions?

dirk: so shape-inside and flow to the next shape at the same time

tav: shows example with text flowing from circle to square

stearns: in regions you'd have a list of selectors selecting ...

dirk: he means shapes... he wants shape-inside to have comma-separated lists

Bert: so why does the text go down one and then down the other?

tav: how to do without using CSS regions... if you don't have CSS support? SVG doesn't rely on having CSS.

Jet: and the rest of the words are just clipped?

fantasai: so what happens if someone increases the text size?

tav: just falls off the end

rossen: ... overflow: hidden... on both ...?

tav: next problem we have is SVG doesn't have <br> and <p>, though could probably rely on 'white-space', though maybe not ideal
... question is what's the best way to do line breaks and paragraphs
... 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.
... though if renderer doesn't have right font, might be positioning problems, but would be readable
... one thing SVG doesn't have is a wrapping context... doug has a proposal

<shepazu> q

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

doug: link to my proposal
... there's a width and (optionally) height property on svg:text element
... and it basically passes in the position established via x and y
... ... and the width, and optionally the height
... ... as the inner box (rendering area), and has CSS engine do text wrapping
... cameron has rough prototype

heycam: in local build

doug: Cameron was able to implement in a couple of days.
... 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.
... 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.
... But the basic idea is to use the width property on the existing text element to wrap the text.
... Advantage to that is that the natural fallback is that the text still appears but is not wrapped; better than not apperaing at all.

heycam: In SVG, when I get to rewriting text chappter, I plan to define non-wrapping text this way:
... SVG currently has x and y attributes to specify positions for character (not glyph!) positions
... we're treating that as a ... for defining CSS layout of the text
... 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.
... 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
... 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
... so we don't work away for months and then have people say it shouldn't be done this way

fantasai: I think this makes sense
... I have concern about x and y positions and how that works with line breaking
... line breaking determined by layout engine and could vary between engines, e.g., fonts, hyphenation engine
... those glyph thingies probably assume a certain type of wrapping

heycam: in the past without support for auto-wrapped text, people used x and y to manually wrap
... 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
... doug, did you have different view?

doug: I think variou soptions we could explore.
... 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.
... I think this is simply solved by using what CSS already has, in SVG.
... 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.

glazou: Also in Mozilla's XUL have to include HTML inside of XUL.
... not specific to SVG and text

rossen: how is this different than foreignObject?

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.
... But for simple cases would be nice not to have to escape into HTML world.

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.
... weird, x,y is bottom corner in SVG top corner in CSS

heycam: In my approach, I switched on whether width was specified, and made x,y be top/left when width was specified
... definitely would want to specify it like that, now you're in CSS mode, read over here

tav: in that case fallback doesn't work

dino: I'm not so worried about fallback

dirk: margin/padding has.. (cutoff)

doug: popular libraries like d3.js where people are doing labels
... script library that makes SVG diagrams very easy
... I talked to several people using d3, people want wrapping text without having to use HTML
... for those cases having fallback to older browsers woud be really nice, fall back to one line
... this is why I mentioned alignment-baseline
... could say whether origin affects glyph cell or character cell, top/left or baseline
... dino, I'm fine with saying "this is a CSS block and behaves like one"
... whatever's easiest for implementors and authors... authorswould expect padding/margin

dino: then hyphenation, kerning, etc.

heycam: for nonwrapping case we'll just make all CSS properties work on single-line text too
... at least in Firefox (soon) we'll just do CSS layout underneath for text, so easy to let properties just work

dino: so you're suggesting effectively flatten text content of element
... basically flatten tspan positioning
... if I say text width is 100 and inside tspans with x and y... tspans get thrown out

heycam: tspans are effectively spans even in the single line case

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
... to allow simple breaking in SVG so you didn't have to pull in HTML to do paragraph
... obviously lists etc. out of scope
... for simple text breaking thought could use tspans for that

dino: should be a single block
... if you want >1 block, use HTML

dirk: why not have new element in SVG for anything from HTML world?

heycam: like foreignObject?

dirk: with no <html><body> etc.
... inside this tag you have HTML world

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

dbaron: how much more violent agreement do we need here?

heycam: Just wanted to make CSS WG aware of what we're doing so we can get course corrections; mail to list fine too.

r12a: when you collapse the tspans, how do you separate the last word in the first tspan and the first in the next?

heycam: don't really collapse

dino: meant just ignore x and y attributes and use them as spans

doug: I think these details can be sorted out in spec... don't need to go into them in this meeting.
... What I'd like in this meeting is ...
... was some concern in SVG F2F that CSS WG might have some objections
... so we wanted to socialize it with CSS WG
... so we wanted to make sure thought a good path forard
... don't know if we need a resolution per se
... nice to know if this is a reasonable direction

glazou: I think you have that consensus.

Bert: I'm not going to say what SVG should do... but why not just stick with foreignObject?

Tab: You need to give it a height, you can't just flow an amount of text in.

doug: Bert, the answer I've gotten from people doing it every day, people want 1 element rather than 6.

Bert: soon you'll need hyperlinks, hyphenation

various: already have those

doug: if you need anything more complicated, you can use foreignObject

Bert: fine by me, just seems like double-work for half solution
... but no objection

<jdaggett> google japan cafe is yummy!!

<br class="lunch" data-endtime="13:00">

<fantasai> Scribe: fantasai

Compositing and Blending

cabanier: Compositing and Blending Level 1
... Last year in Hamburg, made a proposal
... Since then trying to simplify the spec, to make sure can be implemented easily in browsers
... Removed compositing in CSS
... areas, removed that as well

<jerenkrantz> does someone have the latest link for the ED?

cabanier: also knock-out feature removed, because hard to implement

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

cabanier: Only 3 properties left in CSS:

mix-blend-mode

isolation

background-blend-mode

cabanier: Change to bg blend-mode, only defines how backgrounds blend with each other. Simpler to implement
... mix-blend-mode also restricted only to things inside its stackign context
... Also specs out canvas
... different blend modes for canvas
... implemented in FF, webkit
... patches

<jerenkrantz> what was the URL for that demo?

cabanier shows off demo of canvas and different blend modes

cabanier: If there's ocntent behind this box, won't affect blending with that content
... Third feature is blending of elements
... shows some text over an image, with different blend modes
... Want to know if people are keen
... mix-blend-mode creates a stacking context
... and will blend only with things inside its stacking context

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

dbaron: Part of what I was proposing was creating a stacking context
... I would need to think more about blending only with things in its stacking context.
... It's probably okay

cabanier: Talked to roc and ppl on Chrome compositor team
... roc def ok with this, Chrome team seemed ok with it

dbaron: Other concern was, are there enough use cases for background-blend-mode to justify a separate property
... Can certainly make some nice demos with it, but how many real author use cases will it work for?

cabanier: If you want a gradient e.g. that goes over an image, or enhance contrast of an image

dino: Question is, why not use tool offline

cabanier: If you want to animate it, hard to do with a tool

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

krit: ...
... text blended with background, very strong use cases
... moreso in SVG world, because of different shapes
... In HTML itself, text is very strong use case

cabanier: They're talking about backgrounds

krit: oh

cabanier: It could be extended later
... Some people made proposals wrt adding filters on top of it
... could come in nicely

krit: Filter has filter image functions
... This could also be blended
... ... isolation group
... If you have different background layer, [...]
... Filter effects has a filter() function, which takes CSS image as input
... And can be animated
... You can have different layers in background, some filtered, and can be blended with other layers

cabanier: background-blend-mode is much lighter
... using mix-blend-mode for this would create lots of layers

<cabanier> http://codepen.io/seraphzz/pen/houAe

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

dino: ... not as powerful or useful. mix-blend-mode is what we really want to expose, but is very powerful and complicated

krit: As specified, no so complicated

dino: With disadvantage that authors have to understand when a stacking context may or may not appear in their content
... Expect that rounds down to 0% of authors.
...
... As soon as you hover over a div, that because its opacity changed, blending mode changed

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

krit: I think we agreed that we wanted to have full backdrop blending. But know it's hard to implement at this point
... Saying "these properties create an isolation group", don't have to know about stacking contexts

dino; that's handling it in one way

dino: You specify starting blending
...

dbaron: Disagree with Rik's comment wrt adding ability to blend with opacity later
... Once you have CSS properties working a certain way, pages depend on things working that way. can't go back and change it later

heycam: Would add a new value to isolation

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

<dbaron> ?: new value goes on element making the stacking context

dbaron: Kindof ugly

cabanier: Could wait a few years, or have something useful now

heycam: Is it bad to have this new isolation property value on the element that creates the stacking context?

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

heycam: Or would you want to specify that where you're putting the blending operation?

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

dbaron: Think people will probably put * { isolation: new-value; } and not worry about it

cabanier: Not great for performance
... So, maybe don't want to do that.

dino: Suppose I've got this complicated document
... Copy it to another document that has a video in it, suddenly doesn't work
... Have document with 3 children, they blend with each other
... I set the opacity on the middle one. What about it's children?

cabanier: That's all fine
... If your parent has opacity, you won't blend with its parent
...

dino: so, everything blends in its regular order in the document

krit: z-index creates a stacking context and content can not blend with everything beyond it

dino gives example of child with video descendant

scribe:

dino: It's easy for Core Animation's compositor, can specify blending of child into its parent
... But what looks like parent-child relationship in HTML document isn't necessarily that simple in compositor
... Example is 3D transforms
... ...
... Disconnected form your parent, so can't blend into it

cabanier: At some point the 3D object is composited though

dino: You could hit significant perf problems without knowing why
... Have to flatten the 3D world
... get those bits, etc.

cabanier: it's the same math
...

dino: [something about not using compositing for web content]????

dbaron: What do you mean by not using compositing?

dino: have to manipulate tree heavily to do things like clipping, overflow, scrolling
... Compositing has perf benefits with massive complexity
... Makes it harder to add useful things like blending

krit says something

dino: If you don't add the feature, people assume it's not there.
... For widows and orphans, couldn't implement initial value of 2 because people assumed there was no widow/orphan control

dbaron: I don't think there's been enough review of this to say "yes this is good right now"

cabanier: I would love more reviews

dbaron: Review isn't magical that ppl can just do, there are problems you don't find until you try to implement
... and others that you don't find until you have two implementations and realize they're not interoperable
... I'm concerned also about use cases, and if this is addressing things authors really want t do.
... But don't know how to find out if that's the case.

cabanier: Designers use it all the time in Adobe products

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.

cabanier: Not replacing photoshop
... But better to keep semantics than rasterizing

dbaron: Anything else to discuss?

cabanier: Don't think so

dbaron: No objections now, but def want more time for ppl to look at this.

cabanier: Testing feature behind flags

fantasai: Do we need a new WD?

RESOLUTION: Publish WD

min-zoom/max-zoom

min-zoom/max-zoom media queries

fantasai: Isn't the point of zoom to magnify things?

heycam: Some people using mapping content using SVG
... want to do some kind of detail control
... Suggested this would be something to handle via Media Queries
... Situation is some iframes, several levels deep, want to know the zoom level of this map tile
... Came back with proposal where you have min-zoom/max-zoom, which is the resulting scale factor from natural size of the thing
... e.g. have SVG image shown at 50% of intrinsic size

Bert, dbaron: resolution/device-pixel-ratio ?

heycam: Does that tell you that inner view is drawn at 4px per 1px of outer view?

dbaron: Wrt device pixels

heycam: ... See if that's what they need

fantasai: it tells you the resolution
... in device pixels per 'px', or 'in', or whatever

heycam: asks for clarifications

dbaron: It should work. Whether actually works in current implementations, might be a different

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

fantasai: I would say, no, transforms don't affect media queries

<dbaron> ...but does viewBox?

dbaron: But resizing due to change in viewbox would
... I don't know that the spec is clearly enough defined to answer all these questions. Probably should be.
... 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.

<dbaron> ... and how it responds to desktop browser zoom, and mobile browser zoom

dbaron: e.g. how does browser zoom ui work, particularly desktop vs. mobile, which have different concepts of zoom

krit: Designers want to have different details depending on zoom level

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

cabanier: what about animations?

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
... So maybe I go back to talk about whether resolution should work or not

glazou: David, you said that resolution, same thing
... 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

heycam: Yeah, author would want to say "here's how content looks at default size; at twice maginification, looks like this"

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
... You can't distinguish between iPad Retina and tablet with zooming

dbaron: Mobile browser zoom doesn't affect media queries, whereas desktop does
... I agree with everything you said, glazou, but I also want to avoid duplication.
... Think we need to be clear on all these things before adding more to them

fantasai: There are basically two types of scaling, graphical and logical.
... Sometimes you're just wnating to magnify what exists. Certain types of UI zoom, and transforms, fall into this category
... Other times actually changing parameters of layout
... Need to be clear on which effects go in which category.

glazou: Zooming by user is a user constraint; zooming by author is an author constraint
... First one makes sense for zoom, second for resolution

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

<shans__> jdaggett: that was me, just setting things up.

SimonSapin: This does not account for transforms

dbaron: Might need another editor of MQ 4

glazou: Florian is very busy right now, will have more time in a few months

dbaron: Two big categories of changes
... that need to happen
... We talked very briefly of doing syntax changes
... To be closer to @supports
... Other was adding queries to represent everything in media types, deprecating media types
... But those are bigger things

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

krit: Security question wrt basic shape
... Can use CSS shapes to define a clipping area
... Here's an image, can define a clip path on it.
... Can also be animated
... Quite easy to apply this clip path
... Problem is the following
... Usually you have clip-path inline in your style sheet
... Can also cross-reference path from a different domain
... Suppose, e.g. style sheet on mybank.com
... evil.com tries to reference it
... question is, can any private data come from this style sheet
... ... pointer events
... If you cliip to circle, outside that doesn't contribute to clipping area
... Suppose one domain uses clip path to show password or something
... If you clip anything with this letter here, then the areas outside it don't contribut to hit testing
... So could scan the clipping path and reingineer what the clip-path could look like

dbaron: I think anyone using clip-path to use confidential data is doing it wrong.
... If that's the attack, I'm not that worred about it!
... I would be more worried about an attack that involved treating other data as pieces of a CSS style sheet
... e.g. send someone an email message with some CSS in the subject
... And then closing equivalent to that in another message
... Could retrieve all the subjects in between by requesting a particular URL from Yahoo.
... That I'd be worried about
... But this I'm not worried about

glazou: I'm not that worried...

Alan asks about some other shape image thing

krit: Very weird case. Only one I could come up with as an issue

heycam: What if you had a style sheet that just had content property, did hit testing on content

krit: That would be a bigger security issue.

fantasai: Putting sensitive data in a style sheet's content property also makes no sense at all.

heycam discusses other properties exposing things in the same way

scribe:

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

<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.

dbaron: I think we pretty much agree that it's not a security problem we want to fix.
... We could put a note in the spec, that authors shouldn't put sensitive info in clip path

<dbaron> (unless there's a worse case that we haven't heard yet)

Alan, dino: Don't think this is an issue

Bert: Position div for each pixel of your password

<dbaron> http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0012.html

dino: I don't know why we're even discussing this.

Bert: Good to discuss, but I think we can conclude that this is a weird case we don't need to worry about

RESOLUTION: We don't care, unless bz can come up with something more convincing

SVG text-wrapping

tav: Things we would most need from Exclusions and Shapes have been removed from latest drafts
... shape-inside
... And using SVG paths and shapes

Alan: My plan for that is to have that in next level of CSS Shapes
... I'm trying to constrain first level of spec ot stuff that is most immediately useful to CSS at the moment
... I don't think there's an issue with having your SVG work depend on Shapes level 2 instead of Shapes level 1

glazou: Problem is referencing a non-normative document
... Discusison in AC forum, W3C suggested references can only be W3C RECs. Document referencing WD can't go to REC

plh: But can go to PR. Just can't go to REC.

fantasai: I don't think this will be an issue

plh: For the record, Robin Berjon started a thread on chairs list wrt dependencies

Alan: Noted, haven't created L2 document yet
... question of whether to make L2 doc to park these things in

TabAtkins: Make ssense. Just put <details class=obsolete> and note things

<dbaron> So I think Boris's concerns in that thread are actually somewhat different from that contrived bank case.

TabAtkins: Maybe I'll rename the class

<dbaron> maybe more like http://lists.w3.org/Archives/Public/public-webappsec/2013Jun/0008.html

security

dbaron: Involves using clip-path on attacker site over <iframe> to victime site.
... That's more concerning.
... But not useful to discuss here.

dino: How is it more of a problem than overflow?

dbaron: Not different.

<dbaron> message from roc: http://lists.w3.org/Archives/Public/www-svg/2008Sep/0112.html

krit: 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.

dbaron: The attack I described wasn't what bz described
... This is stuff that needs to be thought about longer. We should be fine, I think.

<dbaron> ... since bz was describing something that would be fixed by rejecting clip-path for cross-origin non-CORS style sheets

heycam: been awhile since roc's message. should someone look at that?

<dbaron> which the attack of a site that controls a site's cross-origin style sheet and can simultaneously frame it isn't fixed by

Figuring out the CSSWG agenda

<glazou> http://wiki.csswg.org/planning/tokyo-2013?&#agenda

<r12a> http://www.w3.org/International/docs/counter-styles/Overview.html

<dbaron> http://dev.w3.org/csswg/css-counter-styles-3/

<dbaron> there's one issue listed in http://dev.w3.org/csswg/css-counter-styles-3/#ethiopic-numeric-counter-style

<dbaron> Topic(a few lines back): Counter Styles

<myakura> r12a, I see some Japanese counter styles in the Hebrew section... http://www.w3.org/International/docs/counter-styles/Overview.html#hebrew-styles

Discussion of whether to publish Counter Styles as LC

<dbaron> want to link to r12a's document, which is to be published as a note

Richard posts the i18n note wrt @counter-style rules for various scripts

<dbaron> glazou: should we give people a few weeks to review

<dbaron> fantasai: we already did that

<dbaron> I'm fine with going to LC, though I'm really not sure how high of an implementation priority this is for anyone.

http://lists.w3.org/Archives/Public/www-style/2013May/0757.html

<dbaron> ... css-counter-styles-3 to Last Call, ask for review from HTML, i18n, ... oh, wait, we resolved to go to LC last week

<TabAtkins> http://dev.w3.org/csswg/css-cascade/#cascade

<scribe> ScribeNick: fantasai

TabAtkins: This is in section describing how levels of things are handled
... We inserted Scope in the middle here
... Scoped style sheets always win over unscoped styles
... Scoping something further down in the document overrides coping rules further up i nthe document
... Question is , does this sound sufficient for a spec defining this?
... Think it is correct

fantasai: By default, inner scopes win over outer scopes
... But for !important rules, order is reversed
... Outer !important rules override inner !important

dbaron: Other alternative is for inner !important to win over outer !important

heycam: I think the current spec is a nice parallel with how origins work

fantasai: I think this gives !important a useful purpose in negotiating rules between inner and outer scopes
... So somewhat prefer this behavior

TabAtkins: Seems from heycam that the spec is clear enough

Bert: Why have scopes be special, why not have it same as ID selector

glazou: I proposed that several times, was turned down

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

Bert: That's what I expect

dbaron: That's not what authors expect

TabAtkins: Point is that scoped rules apply only to your bit, and can have short, simple selectors
... Lends itself to lower-specificity selectors
... Rules that apply to whole document tend to be more verbose, more specific
... Want the simpler scoped rules to still override document-wide, more-specific rules

Bert: But adding new concept

glazou: It's similar to adding a 4th argument to specificity

Bert: span.foo { blue } vs. scoped span { green }
... Expect <span.foo> to be blue, not gree.

dbaron: Expect it to be greenn

glazou: Last time we discussed this, the painful bit was only adding dynamically adding styles [?]

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

plh: Not implemented though, so haven't played with it.

RESOLUTION: Close issue on how !important interplays with scoped styles

<glazou> <br type="break"/>

<TabAtkins> Cyril: Thanks!

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?

<jdaggett> fantasai: i actually don't think we'll be able to deal with fonts/text/text-decoration all in the morning

<jdaggett> fantasai: guess we can try though

TabAtkins: Continuing with 'default' keyword

<jdaggett> reference url?

<jerenkrantz> http://dev.w3.org/csswg/css-cascade/#default

dbaron: I had initially proposed default as something else, as initial/inherit. Still would like that behavior.

TabAtkins: The reason I don't want to do that, doesn't do what authors want

<jdaggett> um, phone dropped

<jdaggett> shans__: ^

TabAtkins: E.g. want "default" to mean "display: block/inline" depending on whether <p> or <span>

<dbaron> jdaggett, ack

dbaron: Not always. E.g. reset stylesheets want my behavior

<dbaron> jdaggett, apparently it's because shane left

TabAtkins: Don't think we need to cater to reset style sheets

<jdaggett> dbaron: you guys dropped off the call!!

<jdaggett> ah

<dbaron> jdaggett, apparently it requires a computer that can get on the corp network, which tab's can't

fantasai: Could add special ability to 'all' shorthand

dbaron: The other issue with this definition of default is that it's a decent amount of work to implement

TabAtkins: Won't disagree with that

SimonSapin: Think it requires keeping around multiple specified values

TabAtkins: Don't have to keep things around, just might need multiple passes, and just for elements it shows up on

SimonSapin: Isn't that similar perf cost with variables?

<shans___> what is the zakim bridge conference id?

dbaron: It can be done without that perf cost

<jdaggett> 26631

<dbaron> "This passcode is not valid."

<shans___> need a new one

<dbaron> shans___, ^

<dbaron> "This passcode is not valid."

<jdaggett> ok, good good

<jdaggett> yes

<jdaggett> default was the topic...?

<jerenkrantz> jdaggett: yes

TabAtkins: I don't really want initial-or-inherit. No use case for it

<glazou> jdaggett, yes

dbaron: Use it internally a lot
... e.g. Web Components style reset
... Think that basically is equivalent to all:initial-or-inherit

TabAtkins: Given that those don't have any UA style rules anyway... I think that's equivalent to 'default'

heycam: want s/continues/repeats/ ?

TabAtkins clarifies what default does

ACTION TabAtkins clarify what default does

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

dbaron: Putting !important and normal together makes it harder to implement

<jdaggett> argh, back in a sec

dbaron: Implementation I would take would do the wrong thing for user !important and ua !important
... Current spec, user !important rule says go use the author styles
... But if no author styles, don't use user styles

TabAtkins: No, no, we only glom together all the author styles.
... You still keep user as an origin level

dbaron: Ok, that's fine
... But make it clearer

fantasai: We could put in a simplified cascade list, just to make it more obvious
... Any other concerns with default?
... Do we want an initial-or-inherit keyword?

TabAtkins: I suggest using actually 'initial-or-inherit'. Want to steer authors to 'default', since that's usually the right answer.

dbaron: Would like to see a keyword for that

Bert: Would like to understand better what this is used for

TabAtkins: You use it in most use cases for dbaron's examples, except this is the better answer in most cases
... For a use case, sometimes it's much easier to create positive selectors than :not() selectors, and wipe out what you had before
... Point is to wipe out whatever author has done
... This is better because it respects user styles
... And UA styles
... Most authors don't understand difference between initial value and UA default value
... This lets you not worry about that
...

plinss: This removes your rules.

TabAtkins: Not sure whta you're objecting to, what you're asking for is exactly what this does.

Bert: You said it's easy to specify a generic rule, and override a specific case
... span { color: green; } span.foo { color: default; }
... Then I get inherited

TabAtkins: That's what you get, unless user or UA says something
... Let me show different example
... User says wants links are bright blue
... Author styles links purple, except some links with class should use default colors
... If you use 'initial' or 'inherit' to wipe out author rules, the colors will reset to black.
... Doesn't go back to blue.

Bert: Why would I want user's rule
... I don't know what they are

plinss: That's the point

TabAtkins: This goes back to "whatever style would be without my influence"

Bert: Think examples would be good

fantasai: Better example would be paragraphs. By default, have 1em margin on top and bottom.
... If I styling thing, and want to go back to the default styling, would ask for 'default'. Gets ack to 1em margin.
... If said 'initial', then would set margins to zero.

Bert: i'm not convinced, but if you can get some examples in there, would help

leaverou_away, Can you help here?

RESOLUTION: Ok with current definition of 'default', remove issue

but also clarify the spec and add examples

fantasai: Suggest inherit-or-initial

plinss: reset?

TabAtkins: Want it to be long an annoying
... Using 'default' for this because already reserved, and does more or less what was intended for that value.

Cyril: Question wrt inheritance
... First paragraph, 2nd sentence

<glazou> Bert, ok but unsure at this time

[... wordsmithing ...]

<dbaron> "unless the cascade results in a value" -> "when the cascade does not result in a value"

<Cyril> ack

Cascading of Transitions and Animations

<stearns> http://dev.w3.org/csswg/css-cascade/#cascade

TabAtkins: Order in css3-cascade matches Gecko behavior. Apparently WebKit's behavior can't be explained in terms of cascade

<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Mar/0297.html

dbaron: There were pieces of each behavior that was considered crazy and unimplementable
... Made progress towards acceptable behavior for this during special meeting
... Wrote up in this message, which I have long since forgotten
... This message actually has transitions at a different point in the cascade, but agrees with cascade wrt animations

fantasai: Does this mean that you can never transition !important values/

dbaron: It means that if you change something to !important, it will not transition
... But if you change something from !important, might get a transition

fantasai: What if both are !important?

dbaron: No transition

fantasai: Don't like that.

dbaron: We all agreed that we want animations to override transitions, and that we want !important to override animations, and
... now proposing that transitions override !important rules

plinss: I think in Lyon we talked about animations not causing transitions

shane: I don't think we're asking that transitions override !important, just that they be able to transition

fantasai: Think animations win over transitions because the two rules transitioning are lower

<SimonSapin> http://w3cmemes.tumblr.com/post/34634329920/csswg-resolves-to-use-less-magic

dbaron: Could introduce some magic

<jdaggett> oh gawd, dbaron and fantasai and magic....

dbaron: Could say that if you have an animation running, any transition rules for that property don't apply
... Not sure that works, because we have to consider inheriting properties

dino: I think in our discussion we got to that point and then gave up

dbaron: Gave up on starting transitions

TabAtkins: What is the inheritance problem? I that #3?

dbaron: Say you have animations/transitions on color
... Have a currently running transition on the child, and start an animation on the parent
... nevermind
... Nothing in the cascade will help there; you just lose
... transition will keep running on child, we're ok with that?

TabAtkins: The effects of animations can never cause a transition, including inherited effects of animations

plinss: Could ahve set value of child, that gets unset,
... And then goes back to inherited, but that value is animating

dino: Bad example was parent and child with transition set up for color
... But child has color inherit
... You transition parent. What happens to child? When does its transition start?

dbaron: What my proposal does for plinss's question...
... 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
... 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
... 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
... So never comparing to animation at a different time
... 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
... And that was a defined way of describing interaction between the two.

fantasai: Have a question, may or may not make sense.
... would it work to sovle the things we want
... if we went with the cascade that's in gecko
... But said that a transition never starts if the start state or the end state is an animation

TabAtkins: Or is produced by an animation via inheritance.

dbaron: Produced by animation via inheritance, say you have font-size animating, and width in em units
... Tracking what's caused by an animation is very complex

<jerenkrantz> RRSAgent: make minutes

plinss: Thing about this that bothers me
... Talking about a lot of edge cases, cause lots of discontiguous jumps when animations/transitions applied
... Understand some implementations may not be able to avoid jumps
... But certainly don't want to require them
... [...?]

dbaron: One concern wrt that kind of thing, we tend to as a group want to gradually narrow possibilities
... But some of those gradual changes might trigger a rewrite in certain implementations

plinss: Then get it right the first time

dbaron: Need a description of what the right behavior is

plinss: Transitions should always be smooth

dbaron: start value and end value for transition
... Are you ok with start value is always static, but end value might be animating

fantasai: ?

TabAtkins: Start state is something specific, end state is inherit
... Parent was running a thing, and now inheriting animated value, so transitioning towards moving target
... Are we ok with tranistioning towards a moving target

dino describes WebKit's behavior, which is bad, which chains transitions together

[discussion of this bug]

<dbaron> you may recall http://lists.w3.org/Archives/Public/www-archive/2013Jun/att-0030/x2_10c92e9a.jpeg from Tucson

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
... 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

dbaron: It's detectable due to TransitionEnd events

Rossen: What you see as a user, you'll see color transition from green to blue (looking at point 7) over 2s
... then detransitioning from blue to green over 10s
...
... so proposal was for #a and #b t transition over 2 and 10 s, respectively

plinss: Would argue from user's perspective, bheavior that user expects is that #b will transition from green to blue over 10s
... at the same time #a is transitioning over 2s

dbaron: There's another problem
... I think user expectation is that whichver time is longer wins
... If you swap the times, especially when one is unnoticeable

plinss: I think if you swap the times, user will expect #a to transition over 10s and #b over 2s
... IMO #b's behavior should not change based on whether #a has a transition or not

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

rossen: Transitioning independently

dbaron: What if you swap times and put longer time outside?

plinss: irrelevant

dbaron: The thing is, default for transition not happening is time is zero
... The only thing that makes the transition happen is the time
... If #a has a long transition and you change from #b from 0s to 10ms, that drastically cuts the time of #b's transition
... Rules could come from different parts of cascade, e.g. box and button iside box, designed to have independent transitions

jdovey: [...]

TabAtkins: I think your model works for this, dbaron

dbaron: No, don't yet know of a model that works for this

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
... ... no, won't start. Nevermind

dbaron: When I proposed that, just thought of it for animations, not transitions
... if you start applying to transitions, too...

TabAtkins: A change from a static value to an animating value, will kick off a transition

dbaron: you don't have that info
...

plinss: In this example, when you start/stop hovering, both transitions start imultaneously
... The short transition will have end point of blue
... And long transitions endpoint, over first 2s, will transition from green to blue

TabAtkins: In order to say endpoint is changing, have to know that endpoint is coming from transition
... But that's not updating endpoint, it's resetting transition counter

plinss: Don't need complex data flow analysis. Just tag all the transitions [...]

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

plinss: Problem is transitioning for somethign changed via inheritance
... Because you're inheriting result of a transition

dino: Similar problem with width in ems

TabAtkins: Can't just track inheritance
...
... Think reasonable model is that every single computed value change triggers transition

plinss: So I have clarification ...
... If in this case, the font-size #b does not have a transition on it
... #c has transition on width.
... Is width going to transition?

dbaron: Yes

plinss: The 10ems didn't change
... the specified value didn't change

fantasai: transitions are based on computed value

dbaron: This is the list of testcases that I proposed we not care about

<Cyril> equivalent example in SVG: http://jsfiddle.net/7WsP2/

dbaron: Meaning, some of these will do weird things, and authors will just get what they deserve

TabAtkins: 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.
... So we have the 3-way override with magic to make it all work
... 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
... Which, if it's shorter than the animation, will be hidden by animation (but not otherwise)

<jdaggett> is rossen saying anything important?

<jdaggett> he's ....far.... away from the mic

<jdaggett> kk

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

dino: Think point B is significant change from WebKit

dbaron: Was just proposing to modify point B with magic

TabAtkins: With animations turns off transitions magic?

dbaron: Sounded like what we're moving towards
... B would then be what Cascade then has

TabAtkins: If transition is kicked off on different property via computed value linkage, will still trigger transition.
... Something will happen, will be well-defined answer, but we don't care what happens

dino: And authors will be so confused, they won't know what went on

TabAtkins: Proposal is Adopt A, C, E, and D, and use cascade's ordering plus animations turn off corresponding transitions magic

fantasai: I *think* that sounds alright

plinss: That precludes a lot of situations we might want, like transitioning to an animated state

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
... And getting those kinds of transitions to work well requires more sophisticated tools than just time-based transitions
... I think that's something we could add later, maybe with an 'animation-transition' property or something. :)

dino: David, when do you think you'll start testing this?

dbaron: No idea

TabAtkins: Shane, you said Blink's changing animation stuff?
... Oh, well why don't you implement this?

shane: I'd say, I'd be surprised if we didn't have something by the next F2F meeting

TabAtkins: So plan for Paris to have feedback from us

shane: Some concern wrt changing behavior, but does seem to be fairly edge cases.

dbaron: A bunch of this requires edits to Transitions, particularly to places where spec is very vague
... If we resolve on this, I'd make those edits

Proposal: Resolve on those edits, then re-evalueate after implementation experience

RESOLUTION: 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.

dbaron: For Transitions, only one other issue. Tab has had an action to write a demo for last few F2Fs.

TabAtkins: Ok, I will make a demo tonight!

plinss discusses CR strategy

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.

dbaron: Would write several screenfuls of At-Risk text
... But ok

plinss: Would like to leave this F2F with both specs going to LC

TabAtkins: Ok, so this means no change to Cascade.
... Which closes all the issues on Cascade.

<dbaron> I'm happy moving cascade to LC.

TabAtkins: How do people feel about going to LC?

RESOLUTION: Take CSS3 Cascade to LC, with edits mentioned in minutes today.

ping HTMLWG especially, also notify WebApps, SVG, WAI

4 weeks LC period

Cyril notes an inconsistency in the definition of "cascaded value"

which needs to be fixed

Conditional Rules

dbaron: Issue raised by heycam, discussed multiple times over the last month

<stearns> http://dev.w3.org/csswg/css-conditional/doc-20130404-CR.html

dbaron: Fun end-of-token-stream issue
... If this is valid, we'd better put the closing tokens in the stream

SimonSapin: Why wouldn't it be valid?

TabAtkins: Should error-recovery add the additional necessary tokens

plinss: I would say that error-recovery creates the necessary constructs, and serialization writes out the appropriate syntax.

SimonSapin: We don't store tokens, we store component values

dbaron: supports rule conditions can store things that aren't valid values in CSS

TabAtkins: Concept of component value he's invoking is from Syntax
... It augments tokens stream into a nested tree of blocks and tokens and ?
... We parse that into a parenthese block containing 4 tokens

dbaron: I'm hesitant to introduce a new concept in how we specify things
... because that might imply we need to introduce that concept into the implementation
... Chances are you'll write a spec that requires the implementations to add that abstraction layer as a real thing

TabAtkins: If you encouter EOF, assume the additional necessary tokens to assume those constructs, so that you have a well-formed stream

glazou: minimal tokens necessary

SimonSapin: You're not storing tokens, storing constructs
... When you serialize it will create those constructs
... Only in variables or invalid @supports conditions will you store tokens

TabAtkins: So, whether store constructs or tokens treams, identical results
... So, to answer heycam's question, this would parse correctly, and would imply close parens

SimonSapin: I think in this case we don't even need to store the parens
... Just need to store a declaration

RESOLUTION: Whenever error-recovery closes open blocks, urls, strings, functions, brackets, etc., it implies the minimal tokens to close those constructs.

heycam: Related issue is \ as last character of the stream. It's valid, but need to add another backslash before appending anything

TabAtkins: The backslash will become a DELIM token containing a backslash, and when you serialize it it will need to be escaped

dbaron: But when you escape it, it becomes an identifier

TabAtkins: Ahh..

The only way to include a literal backslash is to put it as the last character in the stream

TabAtkins: Could just drop that DELIM token

glenn: How about ident?
... In font-family has name idents
...

dbaron: Another proposal, kindof random, backslash at end of stream converts to U+FFFD

TabAtkins: We do the same thing to nulls
... That's new behavior

fantasai: This is a total edge case, it doesn't matter what we do here.

plinss: Why can't it be a backslash?

dbaron: Because you can't serialize it into any other context

plinss: What if you have open string? Couldn't you just close the string?
... It would normally, at the end of a line, continue the string

dbaron: Do you want to change the rule (/EOF-> U+FFFDEOF) only for strings?

plinss: Yeah

<dbaron> s/\//\\/

plinss: A backslash at the end of a line inside of a string, should not turn into anything.

TabAtkins: I would prefer to handle this case in the escape-handling rules
... Don't want different behavior

dbaron: Escape behavior is already contextual wrt strings, because of \EOL

plinss: Don't see any value to not just ignoring it.

TabAtkins: OK

RESOLUTION: \EOF turns into U+FFFD except when inside a string, in which case it just gets dropped.

<TabAtkins> ScribeNick: TabAtkins

heycam: If the final token in the stream is a bad-url or bad-string...
... Those are bad because you've reached the end of the file...
... If you try and fix the lone \ at the end in any way, none of those reserialize to a bad-string or bad-url.

dbaron: I think Tab's revisions to Syntax fix that - you never get a bad-string or bad-url from EOF.

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.
... [explains what results would be produced in various situations]

<fantasai> ScribeNick: fantasai

heycam: conditionText attribute is defined to strip string of white space, but that could change the meaning
... shows example of escaped whitespace

TabAtkins: need to strip whitespace tokens

heycam: That's fine

TabAtkins: That would be an identifier called "a "

RESOLUTION: whitespace tokens are stripped, not necessarily actual white space, from conditionText

SimonSapin: Do we want to keep the value of badurl or badstring tokens around to serialize them?

TabAtkins: Syntax right now just puts a token into the token stream, with no other data
... Can't ever serialize them
... Even variables can't sue them
...

SimonSapin: In @supports, we have special error-handlign rule that says something invalid evaluates to false
... But the rule is stil valid
... If that invalid thing is a badstring token, how do we serialize it?

TabAtkins: Media queries, when serialized, serializes as a guaranteed false MQ?
... Should do same thing with @supports?

dbaron: I don't think we should do the same with @supports.
... Don't think so
... The way spec is written now, if you have badstring or baduri, the @supports rule will get dropped

[because it doesn't match the grammar]

dbaron: Maybe should call that out explicitly

<jdaggett> ah, ok, got it

SimonSapin: Is allowed syntax for unknown things the same as variables?

TabAtkins: More or less

dbaron: We should check that, but not in an F2F

ACTION dbaron to check that variables and @supports have identical allowances

<trackbot> Created ACTION-563 - Check that variables and @supports have identical allowances [on David Baron - due 2013-06-12].

RESOLUTION: Clarify that badstring and baduri make @supports rules invalid

dbaron: Have disagreement between prose and grammar wrt !important, and I think grammar shoudl be fixed
... 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.

RESOLUTION: !important allowed in @supports

dbaron: Ok, that's all open issues. Will fix in editor's draft

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

RESOLUTION: Publish CR with updates for CSS3 Conditional Rules

Variables

TabAtkins: Want to exclude badstring and baduri

dbaron: And mismatched blocks

TabAtkins: List of tokens you can't put in there: unmatched ) ] }, badstring, badurl, top-level ;
... Why is ; only disallowed at top-level, but } anywhere?

plinss: This is error-recovery

dbaron: Would prefer not to allow unbalanced things

TabAtkins: Would prefer to disallow ; everywhere then

SimonSapin, dbaron: don't see why

dbaron: Consider in the future you want to put a declaration block in there
...

TabAtkins: Ok, fine, I'm cool with this

RESOLUTION: Can't put unmatched ) ] }, badstring, badurl, top-level ; into variables

http://lists.w3.org/Archives/Public/www-style/2013Apr/0246.html

SimonSapin: Publish all the things!

Meeting closed.

<jdaggett> bye!!

<glazou> for the day :)

<jerenkrantz> RRSAgent: make minutes

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Satori ???/Satoru Takagi/
Succeeded: s/Tamjong/Tavmjong/
Succeeded: s/?? (NTT)/Kazutaka Yamamoto(NTT)/
Succeeded: s/dougt/doug/g
Succeeded: s/argin/margin/
Succeeded: s/dougt/doug/
Succeeded: i/Compositing and Blending Level/Topic: Compositing and Blending
Succeeded: s/... z-index/z-index creates a stacking context and content can not blend with everything beyond it/
Succeeded: s/?: animation/cabanier: what about animations?/
Succeeded: s/thiem/them/
Succeeded: s/ar ebiger/are bigger/
Succeeded: s/ways of/properties/
Succeeded: s/heycam/dino/
Succeeded: s/doesn't cover/isn't fixed by/
Succeeded: 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./
Succeeded: s/equivalent/similar/
Succeeded: s/gree/green/
Succeeded: s/shtat/that/
Succeeded: 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./
WARNING: Bad s/// command: s/\//\\/
Succeeded: s/info/data/
Succeeded: s/the rule will get stripped/the @supports rule will get dropped/
Found ScribeNick: dbaron
Found Scribe: fantasai
Inferring ScribeNick: fantasai
Found ScribeNick: fantasai
Found ScribeNick: TabAtkins
Found ScribeNick: fantasai
ScribeNicks: dbaron, fantasai, TabAtkins

WARNING: Replacing list of attendees.
Old list: [IPcaller] Doug_Schepers
New list: +81.36.384.aaaa Doug_Schepers Vivienne


WARNING: Replacing list of attendees.
Old list: +81.36.384.aaaa Doug_Schepers Vivienne
New list: +81.36.384.aaaa [IPcaller] Doug_Schepers


WARNING: Replacing list of attendees.
Old list: +81.36.384.aaaa [IPcaller] Doug_Schepers
New list: Meeting_Room jdaggett


WARNING: Replacing list of attendees.
Old list: Doug_Schepers Meeting_Room jdaggett
New list: jdaggett Meeting_Room

Default Present: jdaggett, Meeting_Room
Present: Daniel_Glazman_(Disruptive_Innovations) Elika_Etemad_(Mozilla) Simon_Sapin Philippe_Le_Hegaret_(W3C) David_Baron Tavmjong_Bah Rik_Cabanier_(Adobe) Dirk_Schultze_(Adobe) Cyril_Concolato Nikos_Andronikos Brian_Birtles_(Mozilla_Japan) Cameron_McCormack_(Mozilla) Dean_Jackson_(Apple) Kazutaka_Yamamoto(NTT) Satoru_Takagi_(KDDI) Masataka_Yakura_(??) Tab_Atkins_(Google) Justin_Erenkrantz_(Bloomberg) Koji_Ishii_(Rakuten) Jim_Dovey_(Kobo) Shane_Stevens_(Googl Peter Linss (HP)

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 05 Jun 2013
Guessing minutes URL: http://www.w3.org/2013/06/05-css-minutes.html
People with action items: