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