- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Jan 2012 16:43:07 -0500
- 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 UTC