W3C home > Mailing lists > Public > www-style@w3.org > March 2013

[CSSWG] Minutes Telecon 2013-03-06

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 06 Mar 2013 19:01:41 -0800
Message-ID: <51380315.6060305@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT