- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 19:30:48 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Sticky Positioning
------------------
hober showed a demo of 'position: sticky'. Everyone agrees it's cool.
Animations
----------
- RESOLVED: Animations override all normal rules, but are overridden by
all !important rules.
- RESOLVED: Transitions happen last in the cascade
- RESOLVED: Remove initAnimationEvent method
- RESOLVED: Publish updated WD with those edits
Scientific Notation
-------------------
- RESOLVED: add scinot to CSS <number> using SVG syntax
====== Full minutes below ======
Sticky Positioning
------------------
hober: I posted to www-style a proposal for adding a new position value
hober: called 'sticky'
hober: similar to relpos
fantasai: It's like a combination of relpos and fixedpos that actually
works
hober: It's in-flow like relpos
hober: but the calculation of the offset is based on the intersection
of the veiwport and the containing block
hober: common use cases are, e.g. sidebar in a web page
hober demonstrates
* smfr perks up
hober: This sort of thing is really common on the Web, using scroll
events to emulate with JS
hober: All just a single new position value
hober: footer and header of table are always visible in viewport
hober shows address book that works like iPhone address book headers
plinss asks about a case of header and footer overlap
hober: So I think it might be worth, in the longer term, adding a
property for handling collisions
hober: complicated if doing in multiple dimensions
hober: by default would overlap
hober: Looking for resolution to pursue the feature
szilles: How does it behave for print?
fantasai: would be same as relpos
<dbaron> [5 conversations at once]
glazou: I think it's not that easy to specify
hober: I'll take an action to write a description
szilles: If I don't have scrolling it doesn't move
plinss: why not print on every page
fantasai: Then you have the overlapping problem you have with fixed pos
-- end up with tons of overlap. If you want this effect when
printing you need to make space for it.
fantasai: That would be a different feature.
glazou: If I can describe it this was included in the P language
* fantasai thinks everything was in P language
glazou: mechanism similar to pseudo-elements, you could select any
element, such as viewport
glazou: then had an element, and on that you could say "min-y: 0" inside
the viewport
glazou: meant element was always visible or invisible
hober: Common design pattern, ppl emulate a lot with JS
hober: But scrolling has gotten strange as time has gone on, so
increasingly problematic
<arronei> sticky, real world use case:
http://store.apple.com/us/configure/MD102LL/A?=
<smfr> arronei: news.google.com sidebar
Rossen: One question I have, new value is that the behavior is not
applicable or useful for position: absolute
hober: yes
hober: Of all cases I've seen, makes more sense for in-flow positioning
than out-of-flow. You want to leave space in flow for the item
plinss: Suggest considering abspos version of this
* smfr has never seen an abspos equivalent in the wild
Bert: Seems you might want sticky differently in horizontal and vertical
dimensions
hober: Suppose you had a wide table, not so tall
hober: you might want the column headers to stick the viewport, but if
you scroll the table horizontally itself, you might want the row
headers to stick within the viewport but not the scrolly
hober: is it the nearest scrollable ancestor that you stick to?
hober: do you have same decision in both dimensions?
hober: worth thinking about
plinss: Think proposal is for hober to write something up for css3-positioning
plinss: would you co-edit?
hober: either way
<arronei> hober: add the proposal to http://wiki.csswg.org/spec/css3-positioning
<Rossen> smfr, an example is running shopping cart totals positioned
to left/right of forms
glazou: Suppose green is the viewport
glazou draws a big green box, left half has three black boxes stacked on
top. Another black box below that, followed by red box, followed
by blue box
glazou: with collision could you get them to stack?
overlap by default
hober: I think overlapping by default is the right behavior here, could
reuse collision later
hober: also question of percentage values, at what distance do you start
sticking
<smfr> stacking gets hard; you end up with a float-like algorithm
<dbaron> I'm not convinced that reusing this same collision avoidance
mechanism is the right thing.
* fantasai notes yelp search results also uses stickypos
Animations
----------
<sylvaing> https://docs.google.com/spreadsheet/ccc?key=0Akz3Ts2PEQF2dE1fTHhJMlJBbnp6UmZNY2dzVHpEVGc
sylvaing: This describes list of issues we had at last F2F
sylvaing: some things fixed already
sylvaing: hopefully reach LC at TPAC or before
sylvaing: couple left over from Hamburg
sylvaing: where in cascade do animations go?
sylvaing: I believe dbaron described what Gecko was doing
sylvaing: The emerging consensus was that transitions would happen
at the very end
sylvaing: you would go from current animation value to the transition end,
but never really resolved on it
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
<sylvaing> http://lists.w3.org/Archives/Public/public-fx/2012AprJun/0107.html
sylvaing: we discussed this part
sylvaing: here's gecko's cascade
sylvaing: we never resolved that
sylvaing: I haven't checked recent webkit, but they used to have .. at
the bottom
sylvaing: in Gecko transitions are more important than animations
dbaron: Except we would start a transition during an animation?
<smfr> webkit still applies animations after everything else
dbaron: starting a transition happens when we detect a computed value
change that was not caused by an animation
dbaron: the restyling operation..
dbaron: The before and after styles are different in the no-animation case
sylvaing: I'm trying to remember what's the difference...
sylvaing: Other implementations don't let user !important and UA !important
override animations. I think we do want that
dbaron: I think we do want that.
dbaron: Question is whether we want them under the other !important rules
sylvaing: so any opinions?
Florian: I remember having an opinion, but don't remember what it was
fantasai: What are the options?
sylvaing: Option A, animations are higher than UA and author !important rules
sylvaing: Gecko allows them to override
dbaron: Another option would be to put animations here, between author
normal and author override
fantasai: Where would scoped style fit in with that?
dbaron: Author override and scoped would be a group
dbaron: Question would be whether animations would go before the !important
rules, or after them
fantasai: So either animations would come right before all the !importants,
or it would come right after all the author styles (including
!importants)
fantasai: I think having animations override user/UA !important rules
is not a good idea
glazou: I'm using them in BlueGryffon to prevent animations to run
dbaron: Use case: user wants to override colors, but is fine with animations
causing movement
glazou: yes I think both User and Author !important should override
animations
RESOLVED: Animations are below user !important rules, not above them.
[still discussing whether below or above author !important]
dbaron explains why having transitions at the end of the cascade makes
sense: the UA/user !important rules would prevent computed value
changes that could trigger transitions
sylvaing: so user rules could start them, but that's just about it
RESOLVED: Transitions happen last in the cascade
fantasai: So remaining question is whether author !important override
animations or not
RESOLVED: Animations override all normal rules, but are overridden by
all !important rules.
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14713
sylvaing: snapshotting of values at the start of animation, action on
smfr and dbaron on which properties snapshot or not
sylvaing: talk about that yet?
dbaron: not yet, no
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15338
sylvaing: Raised by ...
sylvaing: afaict not used
dbaron: Yes, let's remove them
RESOLVED: Remove initAnimationEvent method
sylvaing: need to define a constructor
<sylvaing> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14781
sylvaing: Spec doesn't specify starting frame / ending frame, spec
defines generating them but doesn't define when ...
dbaron: I believe we update it dynamically
sylvaing: at some point you have your first frame, and others follow.
dbaron: You're animating from that to some other point
dbaron: if there's a style change that changes here, you're following
this line instead of this line
Florian: You put a transition for the adjustment being smooth?
dbaron: Yes, maybe?
sylvaing: I think we do it static at the moment. Think Webkit does too
hober: Should be snapshotting after delay
sylvaing: but compute first frame, last frame
sylvaing: we didn't have a use case for dynamic case
dbaron: My worry about dynamic case is mostly style changes that are
nearly sequential
dbaron: Because it'll expose when browsers coalesce things or not
dbaron: Would like to minimize how much that's exposed
sylvaing: Is that related to issue of which properties to snapshot?
dbaron: testcases with a 5s delay are annoying
dbaron: If I move the mouse into it while animating, it jumps to other
position while animating
sylvaing: Shouldn't this relate to general snapshotting issue?
sylvaing: ok, think it's the same bug
<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15850
sylvaing: I don't understand how you get an invalid rule here
sylvaing: Have a few more edits, then ask for new WD
RESOLVED: Publish updated WD with those edits
sylvaing: Aiming for LC at TPAC or before
Scientific Notation
-------------------
TabAtkins: Required for SVG.
dbaron: Unitless lengths and scientific notation are allowed in SVG attributes.
* fantasai asks about CSS escapes in SVG
TabAtkins: One use is to align with SVG
TabAtkins: Other is it's useful in transformation matrices
TabAtkins: Syntax spec already defines parsing for it, just have a
flag for it to turn it on or off. So no additional work
on the spec side.
<dbaron> 8.574e-21parsec == 1px
Florian: I will not object to scinot, but I'm not interested in it
plinss: Any objections to adding scientific notation?
Bert: Yes.
Bert: I'm not happy with what we add, we don't have anything left for
normal people.
hober: Tab has two use cases
hober: I don't consider them incredibly important, but they're reasonable.
fantasai: I defer to dbaron.
dbaron: I'm against it, but I'm not going to object.
fantasai: That's my opinion.
szilles: I'm not opposed, I'm not for
alan: I think rationalizing things with SVG seems reasonable to do
szilles: Useful, but not critical.
Florian: which definition of scinot is this?
Tab: Same as SVG. Number e integer
Florian: How does this interact with minimum you're supposed to support
TabAtkins: Turns into equivalent number
dbaron: scinot is not valid in integers, only valid in numbers
dbaron: Don't want to deal with scinot in integers
TabAtkins quotes his spec text
dbaron and TabAtkins discuss parsing problems and floats
hober: Just force it to be a number
* jdaggett maybe now is the right time to talk about priorities again...
....
dbaron: Things that are integer are things we will represent using an
integer rather than a floating type. Really don't want to
encourage people to do exponents
Florian: Since you don't care either way, when we're specifying precision
of support, shouldn't require ... cancel out
TabAtkins: So you're allowed to do truncation as you're parsing
dbaron: SVG's integer type does not accept scinot
<dbaron> http://www.w3.org/TR/SVG11/types.html#BasicDataTypes says
<integer> doesn't take scientific notation and <number> does
proposal: scinot for <number>, allow range-checking based on parse
time as well as interpretation-time limits
straw poll -> no consensus
Straw poll again, more formally
glazou: yes
bert: no
koji: abstain
szilles: yes
jdaggett: no
glenn: yes
hober: abstain abstain
alan: yes
fantasai: defer to dbaron
tantek: defer to dbaron
dbaron: no, but not objecting
Tab: yes
<smfr> yes
Florian: abstain
leif: why not, yes
plinss: yes
"Simon says"
<smfr> :D
Bert: Not really fair to ask every F2F until not enough around who disagree
5 no, 8 yes
RESOLVED: add scinot to CSS
text-size-adjust
----------------
dbaron: Don't know what there is to discuss...
tantek: Question is about going to FPWD
dbaron: Think I'd rather not.
<dbaron> with the ED as is
Meeting closed.
Received on Thursday, 30 August 2012 02:31:16 UTC