- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 28 Sep 2011 18:18:25 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish updated Working Draft of CSS Fonts Module Level 3
- RESOLVED: Publish Transitions, Animations, Transforms 2D, Transforms 3D,
with merge note at top of Transforms.
- RESOLVED: Future documents need Changes sections before publication.
- Discussed margin collapsing of column-spanning elements
- RESOLVED: Add Animatable: line to property definition tables
- RESOLVED: Adopt :drag-over for CSS4-UI as :valid-drop-target
- Note: CSS Speech Last Call comment period ends in 2 days.
====== Full minutes below ======
Present:
César Acebal
David Baron
Kimberley Blessing
Bert Bos
Cathy Chan
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Vincent Hardy
Koji Ishii
John Jansen
Brad Kemper
Håkon Wium Lie
Chris Lilley
Peter Linss
Alex Mogilevsky
Edward O'Connor
Anton Prowse
Florian Rivoal
David Singer
Alan Stearns
Daniel Weck (via IRC)
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2011/09/28-css-irc
<danielweck> Dear CSS WG, I am only on IRC, no audio link.
<glazou> danielweck: ok
ScribeNick: fantasai
Publishing
----------
glazou: Any other items?
glazou: Ok, publishing CSS3 Fonts
ChrisL: I had asked for a publication a few weeks ago, and jdaggett said
there were a few edits pending.
ChrisL: I agree with publishing
Bert: publish
fantasai: In favor
glazou: Hearing no objection.
RESOLVED: Publish update to css3-fonts
ACTION Chris: prepare publication
<trackbot> Created ACTION-366
glazou: Request from Dean to publish Transitions, Animations, and Transforms
vhardy: Talked with Dean about this, [... merge document ... ]
glazou: Are you saying Transitions and Animations are ok, but Transforms
need more work?
vhardy: Yes
sylvaing: Merging 2D and 3D?
vhardy: Yes. Also, work to make it work for both CSS and SVG
ChrisL: .. FXTF ..
florian: At the F2F we agreed to merge, but didn't agree to block progress
until the merge
ChrisL: But if we agreed to merge, it'd be guiding people in the wrong
direction to publish unmerged
sylvaing: The only one reason to keep it split imo is because we have
interop on a lot of the 2D stuff already
sylvaing: if we want to unprefix
smfr: It means that we snapshot the current [...]
smfr: I'd like to publish 2D and 3D
<dbaron> Whatever you say about publishing being misleading -- the current
draft on the TR page is *more* misleading.
<fantasai> dbaron, say that out loud?
smfr: I see no harm in pushing to WD
vhardy: I don't have a strong feeling about it
dbaron: I think whatever you say about publishing being misleading, the
drafts on the TR page right now are *more* misleading. There are
errors that have been corrected since the last TR draft
Florian: We can publish a draft with a note at the top saying that this
is planned to be merged, so be careful
smfr suggests changelogs
sylvaing: I was looking more for a Disposition of Comments thing, since
there have been many changes
* glazou is happy we don't have hyatt-style cvs log messages :-)
<glazou> "whatever, r=me"
fantasai: You can point to CVS logs if someone wants every detail, but
it's better to summarizing what the significant changes were
sylvaing: Would be good to have, but not sure I'd hold up the publication
for it
sylvaing: There have been a lot of changes since the last publication
glazou: Hearing group prefers to publish before merge, also that we'd
prefer a changes section for all documents
ChrisL: Also a note saying that the merge is happening
<sylvaing> note that i don't necessarily need to see a change log/comment
disposition in the spec; it can be a wiki issue page. As long
as it's in a single spot i'm happy
RESOLVED: Publish Transitions, Animations, Transforms 2D, Transforms 3D,
with merge note at top of Transforms.
fantasai: Are we requiring the changes section here, or is it just a
recommendation for the future?
RESOLVED: Future documents need Changes sections before publication.
column-span and margin-collapsing
---------------------------------
howcome: We're trying to solve some edge cases, not core multicol layout,
but should resolve it anyway
howcome: Tried to write down 3 options we have
<glazou> Tab's WebKit investigation:
http://www.w3.org/mid/CAAWBYDDsU4AbBk=g5bWQKN5aP9DqOHZW80VBbtXsWQsO7QvAOg@mail.gmail.com
// note see update at http://lists.w3.org/Archives/Public/www-style/2011Sep/0491.html
<glazou> Håkon's summary of proposals and implementations:
http://www.w3.org/mid/20099.15290.322422.741716@gargle.gargle.HOWL
------
> Extra input from Håkon:
> http://www.w3.org/mid/20096.43085.472727.657197@gargle.gargle.HOWL
Adding to this, I think we have three possible solutions to this
issue, informally named "fantasai", "MS" and "Opera":
Do spanners create BFCs? MC XF
fantasai no, but consecutive spanners yes yes
with identical column-span value
are wrapped in one anon BFC
MS yes, but the margins of the BFC no no
don't collapse (unlike other BFCs)
Opera Yes, and they collapse as other BFCs yes no
where
MC = margin-collapse between consecutive spanners
XF = cross floats between consecutive spanners
I believe Opera's solution is what the spec currently describes. But,
like I said last week, interoperability is more important than the
exact solution in this case.
------
howcome: One is fantasai's proposal -- spanners create an anonymous BFC,
which allows margin collapsing as well as cross-spanner floats
howcome: One is MS's proposal -- spanners are each BFCs, but their margins
don't collapse
howcome: Opera's behavior is that each is spanner is BFC, but margin
collapsing is allowed between them
alexmog: We're trying to solve a very specific case, and not trying to
create something where colspans behave as a float
alexmog: It's a workaround for ?
alexmog: If what we want to have is that a number of spanners would be
as if it wasn't in multicol, that would make much more sense
alexmog: If you have content that wouldn't look like that in another
browser, it would look like that in this case
alexmog: Something in the middle, I'm really uncomfortable with that
howcome: Have I written up the proposals correctly?
* glazou thinks we should try to avoid discussing stuff sent 20 minutes
before the call...
<fantasai> TabAtkins, you didn't check floats behavior for WebKit, we
need that info
howcome: I would prefer Opera's solution, since it already states that
spanners create BFCs, so it's most consistent.
howcome: Second most consistent with current spec is MS
howcome: fantasai's proposal would require most changes
howcome: I checked WebKit and they do have cross-floats
Florian: We should clarify the spec so we can all do the same thing instead
of all different things
<Bert> (I prefer: 1. fantasai, 2. Op,.... 9. MS.)
fantasai: Mozilla hasn't implemented yet, probably ok with any of these
fantasai: I think we should ask some authors for what they want
fantasai: It's a deeply technical issue to understand, but it has a
significant impact on what they do and how they will use this
feature
fantasai: They care a lot about margins and spacing, if it's a few px off
they're upset. They're going to be dealing with whatever behavior
we decide
howcome: I don't think authors care much about margin-collapsing, my
priority is to make sure we all pass the test suite
bradk: fantasai's proposal is closest to what we get with collapsing when
no support for multicol
alexmog: It's not just margin collapsing, but also cross-float interactions
glazou: Sounds like everyone agrees we need more input
glazou: howcome, you have action to post message to mailing list with
request for help
ACTION howcome: Post to mailing list asking for input on margin-collapsing
col-span issue
<trackbot> Created ACTION-367
ACTION howcome: post testcase
<trackbot> Created ACTION-368
glazou: If we could have the input for the F2F, that would be cool.
* fantasai can post to the WG blog as well, to get a wider audience.
* Bert thinks *everybody* can post to the blog now :-)
<glazou> fantasai: yes please
Tracking Animatable Properties
------------------------------
smfr: This came out of some emails on www-style about property lists for
animatable stuff being incorrect
smfr: The problem is we have one centralized list, it has to track
everything that's changing
smfr: Proposal is to move things into each property definition, whether
it is animatable or not
glazou: Animatable and transitionable, is it the same thing?
smfr: Idea would be adding extra line to table to describe whether it's
animatable and how it interpolates
fantasai: would go in proptable.
fantasai: Anne wanted a line for serialization order -- we can add both
dbaron: The Transitions spec should define how each value type is animated,
so they can link to that
dbaron: Wrt serialization, maybe get further on how we want to define
serialization
dbaron: Transitions spec should list animatable properties for specs
further ahead of it in the Process, e.g. 2.1
RESOLVED: Add Animatable: line to propdef tables
ACTION smfr: Create examples of Animatable: lines so we can put in template
for copy/tweaking
<trackbot> Created ACTION-369
CSS Conditional
---------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0182.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Sep/0468.html
dbaron: I think it's a reasonable proposal, but I'm a little worried of what
the effects are going to be.
dbaron: All of @supports has that worry, but I just worry that this might
tend a bit too much towards accidentally writing something
browser-specific.
dbaron: once you have the thing, you tend to stick stuff in it, and then
you wind up requiring more and more, even though it's not actually
required
fantasai: What about combining that with the !supports proposal from
earlier? That way you'd have to mark what you're actually
requiring, but you don't have to write it twice.
dbaron: Mixed feelings about that syntax, but it doesn't have that problem.
<dbaron> (I think it was !required at the time...)
Florian: I completely see the worries you have about this 'all' thing,
but at the same time from a coding point of view you get problem
of things getting out-of-sync between body and @supports list
fantasai: Don't see us coming up with a solution here, so let's kick back
to mailing list
glazou: So no resolution
New pseudo-class for CSS4-UI :drag-over
---------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2011Sep/0402.html
glazou: Proposal to rename to :valid-drop-zone
dbaron: That doesn't seem to imply there's something being dragged over
it right now
smfr: :valid-drop-target
Florian: :active-drop-zone
<sylvaing> :drop-zone-hover
ChrisL: :active for links implies activation right now, not quite the same
ChrisL: I can imagine things being considered an active drop zone without
there being any mouse activity
ChrisL: Do we want this specifically tied to mouse activity? Or not?
Should be clear what we're targetting.
???: Tied to drag-n-drop
smfr: Might be touch events, not just mouse events
<bradk> :active-drag-target
ChrisL: Right. <gives example>
<sylvaing> bradk, should be drop-target imo...
<ChrisL> :active-dragged
<bradk> syvaing, yes, right. :active-drop-target
fantasai tries to give an example of keyboard control of dragging things,
but this seems not to be an example of drag-n-drop
<bradk> :active-dragged could be the thing you are dragging
<sylvaing> :drop-focus ? The element current has focus for dropping purposes...
<ChrisL> happy with . :active-drop-target too
glazou: Seems we like :active-drop-target, but did not discuss proposal
itself
glazou: Does everyone agree we should have that in CSS4 UI?
RESOLVED: Adopt :drag-over with some better kind of name
fantasai: On the mailing list there was some discussion of having
:drop-zone with :not(:drop-zone) vs :valid-drop-zone and
:invalid-drop-zone with :not(:valid-drop-zone):not(:invalid-drop-zone)
being neither
<ChrisL> :schroedinger-drop
smfr: Thinks its a platform difference, Apple we never show invalid drop
targets, but some platforms might show targets differently if you
can drop to them, but not with the thing you're dragging
smfr: Would prefer to keep it simple and not have :valid vs. :invalid
<sylvaing> :drop-bikeshedding
glazou: In that case we should use :valid-drop-target, to keep that door open
RESOLVED: Adopt as :valid-drop-target
<sylvaing> fwiw, to me :valid-drop-target does not imply the class applies
only when something is dragged over it
<em> and text-emphasis-style
----------------------------
glazou: jdaggett suggested we should wait on this, since we don't have
wide support for that yet
Florian: That's quite reasonable. Italics look wrong in Japanese, but
if half browsers are doing that and half not, that's not going
to be interoperable
glazou: One cool thing, using @supports we can style <em> conditionally
on support for text-emphasis-style
glazou: any other topics?
<sylvaing> tabs vs. spaces ?
CSS Speech LC
-------------
fantasai: CSS Speech closing LC period in 2 days
fantasai: dweck has started a Disposition of Comments on wiki
<fantasai> http://wiki.csswg.org/spec/css3-speech
fantasai: If no other issues come in, let's plan to adopt the DoC next week
smfr: Apple has some comments, need to send them in
glazou: anyone here implementing a voice browser?
fantasai: Opera has some support for CSS Speech
Meeting closed.
Received on Thursday, 29 September 2011 01:19:06 UTC