- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 06 Mar 2013 19:01:41 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed Filters spec, esp. custom shaders/shaders.
- RESOLVED: animations reverse timing function when animation-direction
reverses an animation, the timing function goes in reverse
- RESOLVED: krit to continue writing on matrix API in FXTF
- RESOLVED: z-index is *not* optional on margin boxes.
- RESOLVED: page margin box establishes a stacking context.
- Discussed proposal for format() in image() for fallbacks, and where
to register new subtypes.
- Discussed ways to get broader feedback on naming discussions
- Discussed proposal for display-none-ness property:
- making it independent of the 'display' shorthand, so that it is
not accidentally reset by style rules setting the box type
- what to call it?
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Tantek Çelik
Arron Eicholz
Elika Etemad
Simon Fraser
Daniel Glazman
Rebecca Hauck
Koji Ishii
Dael Jackson
Brad Kemper
Philippe Le Hégaret
Peter Linss
Edward O'Connor
Anton Prowse
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Nick Van den Bleeken
<RRSAgent> logging to http://www.w3.org/2013/03/06-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Mar/0110.html
Scribe: Bert
Administrative
--------------
glazou: Extra agenda: dbaron's comments on text deco.
glazou: dbaron wants more time to review, so no dicsussion about CR today.
krit: filter effect
glazou: OK, 5 mins
SimonSapin: my issues?
glazou: Yes, but dirk's first
Filter Effects
--------------
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html
krit: I did edits to clean up doc.
krit: added shader section
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#FilterCSSImageValue
krit: would like new WD
dbaron: custom shaders section?
krit: Yes, discussed it in SVG
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/filters/index.html#custom-filter
krit: Generic filter fx
krit: Custom extended.
krit: @filter with descriptors.
krit: Allows to ref diff extensions
krit: Cleaner syntax, easier.
dbaron: Integration of shaders in CSS is much more experimental than
the rest. Rather not in this draft.
krit: We have resolution to keep it in, from both WGs.
smfr: Tend to agree with dbaron
krit: I'd be nice to publish a draft with what shipped already.
dbaron: I think there was not much discussion of it in CSS.
glazou: decision can be changed.
krit: Should maybe be in next level.
krit: We have an impl, so it is implementable.
dbaron: other implementers say not happy with security implications.
krit: We discussed it in Hamburg.
krit: Issues raised so far were all addressed.
dbaron: How was the security addressed?
krit: In last WD we already said [...]
dbaron: I need my colleagues to review this, can't do it myself now.
glazou: So sounds we need more time.
glazou: So everybody should review. And decision is postponed.
dbaron: One more meta-point:
dbaron: Just because I didn't formally object, doesn't mean I'm happy with it.
dbaron: Not happy that it is fine just because we discussed it.
[missed]
krit: Discuss on mlist?
glazou: Yes.
<stearns> krit's point was not that it's fine because we discussed it,
he was responding to the assertion that it has not been discussed.
Reversed Animation Timing Functions
-----------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/0524.html
smfr: Follow-up to clarify to behavior of 'alternate'
smfr: Didn't read the replies.
dbaron: I think it wasn't about reverse, but about interrupt in the middle.
TabAtkins: No, this particularly is about reverse.
glazou: So if I understand correctly, irt is not what we discussed,
but reverses the timing function.
dbaron: E-mail says animations transitions. But transitions have no reverse.
glazou: The message is about animations, seeing the context of the thread.
smfr: Looks like implementers should look at that thread.
glazou: Last time we discussed that reversing the function was probably
better for the user.
dbaron: For anim, that may well be what we do. Need to check.
glazou: Other implementers?
Rossen: Not sure, but don't object.
glazou: waiting for msg from dbaron.
dbaron: I'm OK with the change.
glazou: OK, then we can resolve: anim reverses timing function.
dbaron: Mention "when..."
<dbaron> proposal: when animation-direction reverses an animation,
the timing function goes in reverse
<oyvind> I believe impls agree on this, including gecko
<dbaron> oyvind, yeah, I just checked
<smfr> oyvind: and IE?
<oyvind> smfr: ah, don't know about that, don't have a working windows
box atm
RESOLVED: animations reverse timing function when animation-direction
reverses an animation, the timing function goes in reverse
<dbaron> the bouncing ball in http://dbaron.org/log/20110419-animations
demonstrates it
Matrix Interface
----------------
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html
<glazou> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
krit: In SVG , there is a 2D matrix interface
krit: SVG asked me to write a 3d interface.
krit: I used proposal from DeanJ
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/default/matrix/index.html#webidl-ref
krit: Useful to have general matrix if for SVG and also for Canvas.
krit: Is it OK for CSS to work on that?
dbaron: Where is this going to be used?
krit: We don't have API for transforms yet, indeed.
krit: For now just a future approach. Cannot be used at the moment.
dbaron: concern about previous API proposals was that the only way they
hooked into CSS was into an API we'd deprecated
krit: Hopefully in the future there'll be a way in CSS
glazou: I reviewed the doc. Would love to use. If only I had a simple
way to generate a matrix from a string.
smfr: Cannot do that in isolation. Need an element, to resolve units.
krit: Always coord system of the element.
glazou: My feeling: we start seeing new applications, handling complex
matrices, complex graphics. This will be very useful for those
apps.
smfr: Yes, we see people using the webkit matrix
smfr: Webkit has funky bahevior converting to string.
smfr: And convert from string, throwing away units.
smfr: Not quite correct, but often good enough.
glazou: Handle this in FXTF?
krit: Yes, that's the plan.
smfr: We should address how matrix interacts with style property.
glazou: Only an ED at this time.
glazou: We have time.
krit: Again, also for SVG.
glazou: Objections?
RESOLVED: krit can continue writing on matrix API in FXTF
Syntax Issues
-------------
SimonSapin: A few issues already addressed.
SimonSapin: Some are only editorial.
glazou: If we don't need time now, we can talk about page instead?
Paged Media Issues
------------------
<SimonSapin> I think we have consensus on this one now, just need a resolution:
<SimonSapin> Making z-index not optional on page-margin boxes
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0652.html
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0008.html
SimonSapin: Last week we discussed it.
glazou: I'm fine with it.
-glenn
SimonSapin: proposal is to make z-index not optional on margin boxes.
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0653.html
RESOLVED: z-index is *not* optional on margin boxes.
SimonSapin: Default stacking order of margin boxes currently undefined.
SImonSapin: I can just pick something arbitrary
glazou: I'm fine with that.
SimonSapin: I proposed start from top left and go clockwise.
tab: Fine with any order.
Bert: +1
<florian> I am fine with this
Anton: +1
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0054.html
RESOLVED: default stacking starts with top left corner and goes clockwise.
<stearns> one stacking context per margin box or one single stacking
context for all of them?
SimonSapin: stacking context is considered atomic, so not other pieces
and go in between.
Bert: Are there any cases where you might want to insert in between?
SimonSapin: I don't think so. Also implementation is easier without that.
<stearns> +1 from me
Bert: no objection
glazou: same
RESOLVED: page margin box establishes a stacking context.
antonp: margin box can have bg?
antonp: So bg can obscure another box.
SimonSapin: Yes
glazou: That's why you have z-index to fix that.
antonp: Is overlap likely to occur?
SimonSapin: Most of the time boxes will not overlap.
SimonSapin: Can't think of a use case for overlap.
glazou: Agree
SimonSapin: Issue about @page rules and media queries, but not enough time now.
format() in image()
-------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Feb/0352.html
TabAtkins: Somebody requested image() to have not only fallback, but
also info about type.
TabAtkins: Right now, UA has to download each image.
TabAtkins: Seems it can be solved similar to @font-face.
TabAtkins: But how exaxtly? MIME type seems not enough.
TabAtkins: E.g., PNG has variants with and without anim, not reflected
in MIME type.
TabAtkins: Thread concluded that MIME type was good start, and then add
CSS-defined keywords
TabAtkins: So keywords for transparency support and animation support.
TabAtkins: I want to add this to level 4.
dbaron: A little worried about complexity.
dbaron: But OK with adding it for now.
dbaron: Seems like some of these things should be registered as MIME-type
parameters if they're important.
TabAtkins: Transitioning to new features from MIME types can be added later.
TabAtkins: Not difficult
glazou: Who maintains the list of values?
<tantek> on the csswg wiki!
TabAtkins: Not sure. Who: Could be us. Where: a spec, or somewhere else?
<tantek> only have :) - w3.org/wiki/CSS is probably better
<glazou> tantek, non normative unfortunately
<tantek> glazou - just need a normative spec that declares it a particular
wiki URL to be normative
<tantek> we've already done this in HTML5
<tantek> which normatively references the microformats wiki page for
existing rel values for the normative set of rel values :)
TabAtkins: Something to point to is fine too.
TabAtkins: Whatever other people think is reasonable.
TabAtkins: Also fine with trying to turn some of the new values into
MIME parameters.
glazou: Afraid of confrontation with IETF.
<tantek> LOL
<tantek> seriously, just put it on the W3C wiki - IETF is too slow.
<tantek> HTMLWG gave up on IETF for rel values for this reason.
plh: I happen to be IETF liaison
plh: Happy to help the CSS WG.
plh: If previous interactions with IETF were not great, I can try to
help with that, too.
TabAtkins: MIME type registration is horrible experience.
<tantek> tabatkins: "everyone I've ever talked to who's tried to register
a mimetype with the IETF has had a horrible time"
plh: Improvements have been made. On W3C side we also need to do so
glazou: plh, would you take the idea to the IETF that we start with a
registry ourselves?
plh: getting MIME type is easy, just a bit of admin work. Most of that
is my time.
plh: Takes about two month to get registered.
glazou: OK, let's revise after we try that.
ACTION Tab: with plh, to coordinate on issue of addition new MIME types
for image types with IETF.
<trackbot> Created ACTION-548
Topic: "bikeshedding"
---------------------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0248.html
<tantek> LOL!
fantasai: We'd like to get more participation on naming issues.
fantasai: Other people might have better ideas than us.
fantasai: But those people unlikely to join www-style. Too high-traffic/
too technical.
fantasai: Another mailing list may help.
<tantek> I'd suggest writing a blog post for each time you want input
on naming
<tantek> rather than a mailing list
<tantek> seriously, the creation of this mailing list will be the laughing stock of the W3C
* plh guesses that rand() was already rejected as a solution to generate
names
* stearns suggests reddit.com/r/css-bikeshedding
glazou: Some people reacted to the proposal, and were opposed.
glazou: I don't think it is a good signal to users.
glazou: It is not disconnected from the tech work.
<BradK> Naming should be done by those most familiar with the topics
discussed: those following the www-style list.
TabAtkins: Idea is that it would be lower traffic.
TabAtkins: If it turns out as high traffic as www-style, that would be a pb.
<tantek> I think such a new mailing list is a bad idea unless the idea
is to embarrass the W3C.
* smfr thinks this is what twitter is for
* fantasai hasn't found twitter to be particularly useful for this :(
glazou: I suggest that people change the subject line to include [naming]
as soon as the topic turns to naming.
glazou: I'm afraid a new mailing list would be a very high-traffic one.
glazou: I see no consensus at the moment.
TabAtkins: OK
<tantek> fantasai - if Twitter doesn't work for this, write CSSWG blog
posts for this.
glazou: tantek menbtioned blog. Maybe we can blog about naming policy.
TabAtkins: Idea to be able to subscribe to certain tags on the mailing
list. Would solve this if do it together with [naming]
<glazou> http://lists.w3.org/Archives/Public/www-style/2013Mar/0095.html
ACTION bert: to ask systeam if subscribing only to certain tags on
www-style is possible
<trackbot> Created ACTION-549
Separate 'display: none' property
---------------------------------
http://lists.w3.org/Archives/Public/www-style/2013Mar/0095.html
TabAtkins: jquery has show & hide methods, but they need to store the
previous display value on hide, to be able to restore it.
TabAtkins: But if it starts out hidden, you have no previous state info.
TabAtkins: The HIDDEN attrib in HTML is anbother issue:
TabAtkins: You can put the CSS rule in UA style or user style
TabAtkins: At important level or not.
TabAtkins: But interferes with ability of author to style it, transition, etc.
TabAtkins: My display draft splits display in half.
TabAtkins: It also adds a third property to set to hidden independently.
TabAtkins: The 'display' shorthand will still override it, so that
doesn't work.
TabAtkins: So it needs to be an independent property, not part of the
display shorthand.
TabAtkins: And what should be its values?
TabAtkins: We're thinking of more values in the future, such as 'content'
TabAtkins We don't know what to call the property.
TabAtkins: the ideas so far don't appeal to me.
<florian> the proposal for "render" made sense to me
<SimonSapin> +1 for render
<glazou> +1 for render too but that's not the major thing here
<stearns> I like 'render'
* fantasai notes a suggestion for 'generate-box'
antonp: The interesting thing is to pull it out of 'display'
TabAtkins: 'display: none' still suppresses th box if 'xyx' is
'normal'
antonp: I'm interested in if this happens elsewhere, such as for font
shorthand. What is the difference?
TabAtkins: This is a brand new longhand, so will take a while to get
picked up.
TabAtkins: But display: none does a fundamentally different thing
than its other values.
TabAtkins: Display type of a box is indep from whether it is currently
displayed.
TabAtkins: Especially useful with HTML HIDDEN attribute.
antonp: Backwards compat story. Interesting point.
SimonSapin: Florian mentions a proposal to call it 'render'
<florian> As for the proposal itself, I am in favor of it
glazou: Name is not the main issue now.
<BradK> Opacity:0; pointer-events:none; would have the same effect,
wouldn't it?
Wrap-up
-------
SimonSapin: Paged media and viewport issue was deferred, but please
contribute on the mlist. I need reactions.
<florian> Simon, I agree with the general direction of your proposals.
Will try to look into the details
fantasai: I much time do people need to review text deco issues?
dbaron: Next week is fine.
dbaron: The current request was just too late for me.
Meeting closed.
Received on Thursday, 7 March 2013 03:02:10 UTC