W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[CSSWG] Minutes and Resolutions Telecon 2012-01-04

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 04 Jan 2012 16:43:07 -0500
Message-ID: <4F04C7EB.7080806@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - RESOLVED: Move the second f2f this year to Hamburg, same dates as before.
   - RESOLVED: Publish Image Values as LC, LC period ends on Feb 7th
   - RESOLVED: Publish a new WD of Lists, and a FPWD of Counter Styles.
   - RESOLVED: Make the changes to text-overflow:ellipsis outlined in tantek's email
               http://lists.w3.org/Archives/Public/www-style/2012Jan/0000.html
   - RESOLVED: Don't allow !important in animations rules - it's a syntax error.
   - RESOLVED: Allow user !important rules to override animations (exact location
               of animations in the cascade level still undetermined)
   - RESOLVED: Define the override level of specificity somewhere, and decide
               where animations go in relation to it.

====== Full minutes below ======

Present:
   Tab Atkins
   David Baron
   Tantek «elik (late)
   Arron Eicholz (via IRC)
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Arno Gourdol
   Vincent Hardy
   Koji Ishii (late)
   John Jansen
   Brad Kemper
   Peter Linss
   Divya Manian
   Anton Prowse
   Florian Rivoal
   Alan Stearns
   David Storey (via IRC)
   Daniel Weck (via IRC, late)

<RRSAgent> logging to http://www.w3.org/2012/01/04-css-irc

Scribe: TabAtkins

plinss: Happy New Year!

F2F Administrivia
-----------------

   plinss: Let's start gathering agenda items on the wiki
   plinss: Also Daniel needs an accurate attendee list ASAP.
   plinss: At least your name, even if you don't want to put your other info in.
   plinss: He has to set up security and such, so get it in.
   vhardy: Can we decide today on the location for the f2f following that?
   plinss: We can try.  What's the status?
   vhardy: Last time I checked the options seemed to be moving it to Hamburg
           or hosting it with Opera.
   florianr: Where did Opera offer to host it?
   vhardy: I think Hakon offered to host in his form response.
   vhardy: I think it was Stockholm.
   vhardy: Adobe can also host in Hamburg.
   florianr: Stockhold seems surprising; maybe Oslo.
   plinss: So the consensus seems to be to keep the same date?
   sylvaing: I think the dates sync well with an AC meeting in Europe, so
             that's already convenient for several people.
   [several people on the call said the dates were fine]
   <vhardy> https://www.w3.org/2002/09/wbs/32061/css-2012-05/results

   plinss: I'm happy to resolve to keep the same dates. Should we resolve
           on a location?
   vhardy: That would be helpful, so I can start getting things set up
           in Hamburg or whatnot.
   * fantasai is ok with that or Oslo
   plinss: Doe sanyone have any problems with Hamburg?
   TabAtkins: I'm a wanted criminal in Hamburg.
   ???: Did you eat all their hamburgers?
   RESOLVED: Move the second f2f this year to Hamburg, same dates as before.

LC for Image Values
-------------------

   TabAtkins: I'd like to move Images to LC and get final review, so we can
              hopefully get it to CR.
   [no objections]
   <fantasai> We need more examples in the spec
   <dbaron> I expect I'll send a bunch of comments, since I haven't gotten
            through it yet.
   <dbaron> (It seems like you can't hear me.)
   fantasai: It needs more examples, but seems to be mostly editorial.
             We'll need to settle on an LC review period.
   fantasai: I recommend the Thursday before the f2f, so we can do final
             editting before the f2f.
   TabAtkins: That's about 4 weeks.  Is that okay?
   TabAtkins: Do we want the LC period to go through the f2f, so we can
              accept comments from it?
   fantasai: We can accept comments before the deadline, but we should ask
             for them before.
   florianr: I don't think it's that important to collect comments during
             the f2f; theoretically we'll mostly be soliciting comments
             from non-WG people.
   fantasai: The nearest publishing period is next Tuesday, so how about
             we set the period to end on the Tuesday of the f2f?
   fantasai: On the 7th
   fantasai: midnight on the 7th
   RESOLVED: Publish Image Values as LC, LC period ends on Feb 7th
   <fantasai> SVGWG, Media Fragments WG, anyone else?
   Tab: HTMLWG

Lists spec publishing
---------------------

   TabAtkins: I want a WD or LC, whatever it takes to get good review of
              what's left, particularly the positioning stuff.
   fantasai: WD. It's far from ready for LC.
   fantasai: Where's the counter styles?
   TabAtkins: on dev, at css-counter-styles I think
   fantasai: I think we should publish that as well.
   fantasai: I think that the counter styles should be together - the 2.1
             stuff should be with the other counter styles.
   [some unminuted argument about this; but fantasai would rather publish
   and deal with this later]
   plinss: So bottom line, agree to publish Lists and Counter Styles as WD?
   RESOLVED: Publish a new WD of Lists, and a FPWD of Counter Styles.

Transitions from display:none
-----------------------------

+<danielweck>
   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Dec/0353.html
   plinss: leftover from before
   plinss: Was there anything left to discuss?
   plinss: There was an issue raised by Opera?
   sylvaing: We resolved the animation issue, but ōyvind has a good point
             that we don't yet define what happens for transitions.
   sylvaing: If we start from display:none and then transition to a non-none
             value, does the transition happen?  Or not?
   florianr: Right.  I argued that for the same reasons as Animations, the
             transition shouldn't happen.
   TabAtkins: I think I agree.
   smfr: I think it's a common request from authors, but if we define it we'd
         have to define the processing model much more closely, which we've
         avoided doing so far.
   smfr: So I don't object to it.
   RESOLVED: Transitions don't fire when the starting state is display:none,
             similar to animations
   <dbaron> (I'm not quite sure how that's "similar to animations", but also
             not sure it's that important right now...)

inherit in shorthands
---------------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Nov/0420.html
   TabAtkins: We'll deal with that offline, since Anton had some objections.

text-overflow:ellipsis
----------------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Nov/0537.html
   <sylvaing> (agrees with dbaron)
   fantasai: I believe Tantek updated the spec in response to this. There's
             more recent text *and* a more recent issue.
<Zakim> +Tantek
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/0000.html
   fantasai: I encourage people to follow up on this based on the new text.
   smfr: I talked with other WebKit people, and I think we prefer our current
         behavior.
   http://dev.w3.org/csswg/css3-ui/#text-overflow
   * fantasai doesn't think webkit's current behavior makes much sense
   tantek: The current text doesn't reflect what the testcases are showing,
           and so I wanted to ping the group before updating, since we're
           getting down into a lot of detail.
   tantek: The short summary is, from the research I've done (pasted above),
           both Opera and Webkit are internally broken when there's a small
           number of items on a line.  The behavior is simply inconsistent
           as far as I can tell.
   florianr: I don't defend Opera's behavior.
   tantek: Boris's suggestion wasn't quite correct - implementations *do* clip
           the first atomic inline on a line, but later ones aren't treated
           that way.
   tantek: So the purpose of my testcases was to illustrate that and come up
           with a behavior that we can all agree on.
   tantek: So far it looks like IE10's behavior is the most reasonable, and
           I'm wondering if there are any objections to me speccing that.
   florianr: I'm okay with this change, but I'm okay with any reasonable answer.
   dbaron: Has Boris approved of this?
   tantek: Boris hasnt' followed up yet - the discussion in the bug has been
           between me and roc and mats
   <fantasai> screenshot in IE9 - http://lists.w3.org/Archives/Public/www-archive/2012Jan/0002.html
   tantek: [a summary of the bug discussion]
   tantek: Boris made an assertion about atomic inlines that onlyturns out to
           be true for the first atomic inline but not always true for later
           ones
   <tantek> https://bug690187.bugzilla.mozilla.org/attachment.cgi?id=583917
   tantek: For example, the inline image line in the IE results...
   tantek: The first inline image or inline-block is clipped, not ellipsed,
           but the second and third on a line is ellipsed.
   tantek: So I proposed that behavior.
   tantek: Boris counter-proposed a simpler model saying that all atomic inlines
           should be clipped, but that's not what impls do.
   tantek: I think this should be Mozilla's behavior, since it's both sane
           and consistent with existing impls.
   smfr: I'll get Dan Bernstein to take a look at this email and get back.
   tantek: Anyone from MS on the call that can provide some information?
   Rossen: I don't remember doing any specific work in IE10 for ellipses.
   Rossen: So several releases back *should* give the same results.
   <tantek> test case again: https://bug690187.bugzilla.mozilla.org/attachment.cgi?id=583694
   plinss: So we're waiting on feedback from Webkit folks.  Should we
           tentatively resolve, or give a deadline of a week to talk?
   tantek: I'd like to make the change now, since nobody likes the current text.
           Close the issue now, but leave it available for review from webkit
           or else later.
   [sounds good to several people]
   RESOLVED: Make the changes to text-overflow:ellipsis outlined in tantek's email

   tantek: And now I think I'm ready for an LC draft, after I've made these changes.
   plinss: Any objections?
   florianr: I haven't read it yet, so I'd like to review.
   tantek: How about a week for review?
   plinss: Okay, so one week for review, we'll look at LC publishing next week.

Cascading Animations
--------------------

   Topic: Where in the cascade do animations go?
   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Nov/0667.html
   dbaron: I don't remember what the conclusion from the email discussion was.
<Zakim> -bradk
   dbaron: First, is !important allowed in keyframes?  And if it is, what does
           it mean?
   dbaron: And then where do animations go, both for !important and non?
   smfr: webkit applies animation styles at the very end, so they override
         everything else, including user !important.
   dbaron: I don't want them to override user !important.
   <nimbu> i agree too
   smfr: I agree with that too, it's just harder to implement for us.
   TabAtkins: smfr, do you know if we've ever implemented the notion of the
              "override" stylesheet level?
   smfr: Don't know.
   sylvaing: If they don't override user !important rules, what does it mean?
   dbaron: It means if there is a user !important rule, that property doesn't
           animate, since there's a property higher in the cascade that
           overrides it.
   sylvaing: Ok, that's what I'd expect.
   TabAtkins: It sounds like putting animations in the override level is
              agreeable.
   plinss: I don't think the override level is defined anywhere
   TabAtkins: It's defined in http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-DocumentCSS
   dbaron: SVG relies on it for SMIL animations.
   dbaron: I wouldn't want it in the override level - I'd want it between
           override and something else.
   <sylvaing> override sounds a lot like runtimeStyle in IE ?
   dbaron: Because the override level still contains rules with specificity,
           while animations don't have specificity, so they have to either be
           above or below that.
   <dbaron> override is a level that has CSS specificity inside of it
   <sylvaing> ok, check
   plinss: Not exactly like runtimeStyle - it's still a place where actual
           stylesheets can live.
   plinss: So are people generally agreeing that animations should live
           somewhere around here?  Or is it too difficult?
   smfr: Gecko already does it, so that proves it's not impossible.
   plinss: So what about !important in animations?
   TabAtkins: If animations all live above @style, then it doesn't seem like
              it's necessary for animations to support it.
   dbaron: But then is !important a syntax error or just ignored?
   TabAtkins: No strong preference, but if it does nothing, I'd prefer it to
              be a syntax error.
   <oyvind> should be similar to @font-face I assume
   smfr: So what if you have two animations going over the same property,
         would an !important on the first animation override the second
         animation?
   dbaron: Gecko doesn't currently do that.
   sylvaing: What about other at-rules like @font-face?
   TabAtkins: Those aren't properties, they're descriptors.  I'm not sure
              whether it's defined whether or not it's a syntax error, but
              I do know that none of them pay attention to it.
   smfr: I'm not advocating for the !important.
   dbaron: The 2.0 spec grammar allows !important in @font-face, but the
           prose doesn't.  Gecko doesn't allow it.
   <dbaron> css3-fonts prose also doesn't allow it
   sylvaing: Are there any upcoming at-rules that might want !important?
              Would it be confusing for authors?
   sylvaing: Like Regions?
   TabAtkins: The only ones that should want it are honest-to-god rules and
              declarations, with selectors and familiar properties and whatnot.
              The rest of at-rules shouldn't.
   RESOLVED: Don't allow !important in animations rules - it's a syntax error.
   RESOLVED: Allow user !important rules to override animations (exact location
             of animations in the cascade level still undetermined)
   RESOLVED: Define the override level of specificity somewhere, and decide
             where animations go in relation to it.
   vhardy: If there's an issue with how SVG uses the override level, is that
           something to discuss with FXTF?  If it's underspecified, that means
           that how SMIL interacts with CSS is also underdefined.
   vhardy: I'll send an email to the FXTF.
   plinss: Who can write some testcases for the existing at-rules with regards
           to !important?
   TabAtkins: I can. I've been meaning to get practice with writing tests anyway.
   ACTION tab to write testcases for testing !important in at-rules
   <trackbot> Created ACTION-416

Meeting closed.
Received on Thursday, 5 January 2012 15:56:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT