- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 18 Nov 2008 16:40:54 -0800
- To: www-style@w3.org
Summary:
- Discussed margin collapsing. Agreement that min-height/max-height should
not prevent margins from collapsing in order to preserve continuity
(current behavior causes jumps in content when you cross the min/max
threshold). General agreement that we won't introduce partial collapsing
because it would be new, complicated, and not of significant benefit.
Will discuss later once we have a detailed wording proposal.
- RESOLVED: For CSS2.1 Issue 84 (word-spacing)
http://wiki.csswg.org/spec/css2.1#issue-84
add proposed text from
http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
with sentences reversed.
- Discussed @font-face and duplication: whether various source URLs should
override each other or become fallbacks for each other. Conversation
deferred to mailing list.
- Discussed CSS2.1 Issue 85 (backslash before newline in an identifier),
but came to no conclusion. Browser behavior is inconsistent, open question
is whether to be consistent with strings (newline gets dropped) or spaces
(newline is escaped and is part of the identifier).
- Peter reminds WG that we have been asked to make last call comments on the
Selectors API.
====== Full minutes below ======
Attendees:
David Baron
Bert Bos
Giorgi
Elika Etemad
Sylvain Galineau
Daniel Glazman
Melinda Grant
Peter Linss
Hakon Wium Lie
Saloni Mira Rai
Jason Cranford Teague
Jeff Willson
ScribeNick: sylvaing
agenda: +f2f dates
:enabled/:disabled
------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0295.html
fantasai: spec does not do a good job defined :enabled and :disabled
fantasai: need to change spec to make definition more vague/less
dependent on user interaction
<sylvaing> if we make it more vague, how do we converge on interop ?
<fantasai> "— which the user can select or activate in some fashion
(e.g. clicking on a button with a mouse)"
<fantasai> I would suggest removing that
glazou: not sure this solves the issue
<dbaron> How about something more like "represents an element whose
element type can be enabled by the user but cannot currently
be activated by the user due to the semantics of the markup"?
<fantasai> s/whose element type//
dbaron: definition of enabled/disabled should not depend on CSS but
semantics of the markup and object model
<dbaron> not sure if "element type" is the right thing, but it is precise
fantasai: we already have implementations that match type=hidden.
<glazou> what happens for :enabled { display: none } ?
fantasai: html5 should define enabled/disabled
fantasai: I personally think type=hidden should be able to accept
:enabled/:disabled because that distinction exists
fantasai: but that should be left up to HTML5, we should not define
that here
plinss: there was discussion to use CSS to determine whether something
was editable i.e. its state
dbaron: IIRC we decided that was a bad idea
<Hixie> http://lists.w3.org/Archives/Public/www-style/2008Oct/0161.html
is relevant here
<Hixie> I prefer the first mechanism proposed
ACTION fantasai: write rewording proposal for section CSS3 Selectors 6.6.4
::selection
-----------
<glazou> http://lists.w3.org/Archives/Public/www-style/2008Oct/0268.html
dbaron: two issues 1) 3 proposals for ::selection 2) have not looked at
existing impls and tests
fantasai: unclear what Hixie's test assumes/expects
glazou: discussion postponed to next week
fantasai: When I looked at Hixie's tests, it looked like he set properties
on everything, so it was not possible to see how values
inherited/cascaded through the tree
Ideographic Space
-----------------
<glazou> http://wiki.csswg.org/spec/css2.1#issue-84
no objection
<glazou> change accepted
<fantasai> RESOLVED: proposal accepted for issue 84
border-parts
------------
hakon wonders whether repeat() should be kept in GCPM border-part
melinda: agree it will be hard to preserve
melinda: combinations can get very complex
melinda: should we ask designers ?
melinda: agree that border parts are generally useful
discussion of what designers want
jason: Control over spacing of dashes is a standard tool designers use
fantasai: feature set for 3 is good and should get locked down for
impl.; new proposal for dotted/dashed lines can go in
borders & backgrounds 4
CSS2.1 Publication
------------------
glazou: bert sent email today about CSS21 publication plan
bert: SVG Tiny 1.2 depends on CSS2 since they need to depend on a REC
bert: people cannot use CSS21 for their specs
glazou: yes we do need to deliver this spec
bert: we give the appearance to move backwards; we could avoid
publishing anything until we have a PR
fantasai: we said we'd do that in Cambridge
fantasai: we can't go to PR without the test suite
fantasai: and implementations that pass
bert: should we give up on implementations ?
fantasai: conflicts with the process document
melinda: should we see where we are wrt test coverage and estimate
time left
plinss: we have not spent enough time on the test suite yet to decide
today whether we should change the exit criteria to fasttrack REC
bert: we seem to never get out of issues
fantasai: we'll never be out of them; but once in REC we address them
in errata
bert: we should not wait for implementations to complete the spec
plinss: we're waiting for the test suite, without which we don't know
whether we have implementations
bert: do we have estimates for how long it will take to complete the
test suite and have test reports ?
melinda mentions msft's coming test suite
fantasai: once we have their test suite, reviewing them is the next item
dbaron: are we designing a system to allow us to review tests or are we
going to do something simpler
fantasai: right now, simple system. wiki and mailing list
dbaron: is there a wiki linking to tests needing review
dbaron: in one place
melinda: agree.
dbaron: we should not gate progress on building a complex review system
dbaron: I just want a list of what needs to be done.
dbaron: otherwise it is hard to get involved and help
<fantasai> http://wiki.csswg.org/test/css2.1/pending-review
fantasai: record of which tests have been reviewed is not centralized
glazou: should we move tests that need work, that have been reviewed,
pending review etc be in different places in the repository ?
fantasai: will look for a solution that does not involve moving things
around all the time since moving files can lose versioning
history if you don't do it right
plinss: individual contributors should not do this, only reviewers
glazou: expose a web frontend to do this so the backend does it right
in subversion
F2F Planning
------------
glazou: moving on to Tokyo f2f meeting
plinss: can we lock dates within the first two weeks of march
fantasai: is february a possibility ?
arguing dates around sxsw
glazou: we stick to the first week of March; 4, 5 and 6
Attendees:
Bert Bos
David Baron
Giorgi Chavchanidze
Elika Etemad
Melinda Grant
Molly Holzschlag (via IRC)
Howcome Wium Lie
Peter Linss
Saloni Mira Rai
David Singer
Jason Cranford Teague
<RRSAgent> logging to http://www.w3.org/2008/11/12-css-irc
<Molly> hi, not on phone today, just IRC
* Bert has to run after the call, prefers not to scribe today...
Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2008OctDec/0065.html
ScribeNick: fantasai
Margin Collapsing
-----------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2008Nov/0109.html
Sylvain: At the F2F we discussed min-height and margin collapsing and
how it creates discontinuities
Sylvain: We left the max-height clause in there, which also creates
discontinuities.
Peter: Did we get a resolution on whether we should adopt the partial
collapsing?
Sylvain: I don't think we did, but I also don't think we want to get
into that now for 2.1
Peter: Right. We should be consistent with min-height and max-height,
though
Sylvain: If we want to avoid discontinuities then we need to either
drop both clauses or define partial collapsing
Melinda: Is there a description of partial collapsing?
Sylvain: See thread for Alex's proposal
Peter: The issue here is that you have a parent and a child. Parent
is now bigger than it needs to be due to min-height. Does
parent and child margins collapse?
Peter: The question is how to deal with the child's bottom margin
being large enough to extend past the parent's bottom margin
Peter: Can we at least agree that min-height and max-height should
have the same behavior?
Bert: Yes, I agree with that. Also I like Alex's text in that second email
Bert: Not the partial collapsing, I mean the other part
Bert: The part that makes min-height and max-height
David: I assume we're talking about negative margins. I agree min-height
and max-height should behave the same
* glazou is here only for ten minutes, between two meetings ; hi everyone
<dbaron> No, I said I assume the case where there's a discontinuity for
max-height is a negative margin case
<dbaron> I'm ok with what we were discussing at the F2F, where margin
collapsing is not changed by min/max-height even if they do
change the size of the box.
Peter: opinions on partial collapsing?
Peter: Can we add it later?
Bert, Elika: Don't think we can add it later.
Bert: I don't mind adding it now /if/ it can be implemented quickly
Alex: It didn't seem like any of the implementors were particularly
excited about implementing partial collapsing.
Alex: It's a really new concept, and I'm not sure there's a lot of
benefit to adding that to the spec.
Alex: We would do something like that if we have to, I'm not sure why.
Alex: Are we getting to agreement that we can remove min-height and
max-height from that paragraph and that would be the only change
we would make?
fantasai: I think you might need to make some other changes.
<fantasai> http://www.w3.org/TR/CSS21/visudet.html#min-max-widths
fantasai: There aren't any specific mentions of margin collapsing there,
but there are rules for how they apply.
<fantasai> "If the resulting width is smaller than 'min-width', the
rules above are applied again, but this time using the
value of 'min-width' as the computed value for 'width'. "
<fantasai> 10.7 points to that with s/width/height/.
dbaron: Basically it needs to say that the new computed height does
not affect margin collapsing.
Melinda: I think this gets into the concern I was trying to raise.
Melinda: We have an auto-height box which starts behaving like a
fixed-size box, where we have overflow and margin collapsing
issues
Peter: max-height has to trigger overflow, the point is to constrain
the height
Peter: min-height won't trigger overflow because it'll be at least
big enough for its contents.
fantasai: only the margins will spill out for min-height, and they
don't trigger overflow
ACTION: Alex propose min/max-height text for 10.7
* glazou has to go, meeting pending
* glazou bye people
word-spacing issue
------------------
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-84
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0082.html
David: Why are we leaving things undefined?
fantasai: there are other characters we aren't sure about, or others
that we don't know about/haven't been added to Unicode yet
fantasai: This needs more research. Hopefully get some clarification for
CSS3 Text as well. But shouldn't disallow implementations from
doing this correctly if they are more knowledgeable than the
CSS2.1 spec.
Sylvain: Our concern is CSS2.1 and testing conformance there
fantasai: CSS3 Text is likely to add at least one or two characters to
this list
fantasai: If people are uncomfortable with this being explicitly undefined,
we could make it implicitly undefined but leave the "don't apply
to these characters" sentence.
David: I'm ok with the concept. How about reversing the order of the
sentences.
Sylvain, fantasai: ok
RESOLVED: Add proposed text for CSS2.1 Issue 84 with sentences reversed.
@font-face and duplication
--------------------------
fantasai: Might want to wait for John Daggett
dbaron: Might want to wait for more feedback
Howcome: I sent my comments in. I think we have agreement on the first
issue. The other two are difficult
dbaron: I'm interested in what Michael Day's use cases are.
Howcome: I quoted from Prince's user style sheets. They use @font-face
to implement generic font families
Howcome: They list several src()s to make sure you get enough glyphs.
Howcome: You could perhaps have another src descriptor that has the
fallback behavior.
Howcome: both behaviors are useful
dbaron: if we go with one option for 2 and one option for 3 then you
get both
Howcome: if you go for A -- taking the first font that you find -- how
would you solve Michael's use case?
dbaron: You'd duplicate the rule with the same font family but a different
src
Howcome: Doesn't that conflict.. I guess that depends on 3
dbaron: If you choose 2 goes one way and 3 goes the other way
dbaron: Authors can do either, because they have 2 different mechanisms
that do 2 different things.
Howcome: I'm ok to hear from Apple on that, maybe if we poke them.
dsinger: I'll pass the poke onto Mr. Hyatt
Howcome: I don't think this is a contentious issue. If we can find a way
to describe both use cases, which it seems like we can.
Peter: So if you have multiple values in a single declaration you combine
those in a fallback chain, and if you have multiple @font-face
rules you overwrite each
dbaron: No, the other way around.
fantasai: Peter's way seems more consistent
dbaron: But it wouldn't work well to combine with the addition of new
descriptors over time.
dbaron: For example the unicode-range descriptor.
dbaron: could be used to split up a font into multiple segments, you only
download the one you need
dbaron: but an implementation that doesn't support it would download just
the last one
dbaron: if you did it that way
dbaron: and would therefore only get a partial font
Peter: I'm a little concerned because I'm wondering if a designer would
want a way to override an @font-face declaration
dbaron: They could just use a different name
dbaron: also the last @font-face declaration wins
dbaron: other people have other opinions here
Peter: I think John Daggett is mainly concerned to give designers both
options
CSS2.1 Issue 85
---------------
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-85
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0039.html
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/0078.html
<fantasai> Proposal is to remove \r\n\f from escape token class
fantasai explains how spec prose implies one thing, and escape token forbids
it while being inconsistent between spaces and newlines
Sylvain: what do other browsers do?
<fantasai> http://lists.w3.org/Archives/Public/www-style/2008Nov/att-0039/escape-newline-in-css-identifier.html
Sylvain: I don't expect this to affect authors, but we should define
something
Sylvain: Can we agree that space and newline should be handled the same way?
dbaron: It matters more to me which way they're handled than that they're
consistent
dbaron: I'm more concerned about consistency between strings and identifiers
than between spaces and newlines
Selectors API
-------------
Peter: Reminder that we have been asked to make last call comments on the
Selectors API
Received on Wednesday, 19 November 2008 00:41:37 UTC