- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Apr 2012 14:43:15 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Move text-size-adjust to ED.
- Selector fragment ID CG is looking for help
http://www.w3.org/community/cssselfrags/
- RESOLVED: proposal #2 (require backgrounds and border-radius, allow
border-image, disallow CSS2.1 border properties) accepted
for ::first-line; box-shadow allowed but not required.
- RESOLVED: Move Background and borders to CR
- RESOLVED: For CSS2.1 bug 16049
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16049
replace the sentence about min-height with
"For example, margin collapsing is not affected because
it is based on computed values and not used values."
- RESOLVED: For CSS2.1 bug 16036
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16036
accept proposal in Anton's email
http://lists.w3.org/Archives/Public/www-style/2012Mar/0052.html
- Discussed proposal for bandwidth queries. It's unclear how exactly to
implement the suggested functionality.
====== Full minutes below ======
Present:
Glenn Adams (via IRC)
David Baron
Bert Bos
Tantek Çelik (via IRC)
Arron Eicholz
Katie Ellison
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Vincent Hardy
Molly Holzschlag
Koji Ishii
John Jansen
Brad Kemper
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
Dirk Schulze
Haili Zhang (Intel)
<RRSAgent> logging to http://www.w3.org/2012/04/04-css-irc
<glazou> regrets: dstorey, chrisl (potential), plinss (potential), szilles
Scribe: Vincent
Administrative
--------------
glazou: any extra agenda items?
molly: I have one for later.
glazou: we need to start collecting items for the Hamburg F2F
<dbaron> http://wiki.csswg.org/planning/hamburg-2012
glazou: all, please add your requests to the meeting.
text-size-adjust
----------------
glazou: text-size adjust proposal by dbaron and tantek
glazou: we have a request to move to an editor draft
dbaron: I sent a draft.
dbaron: it is a small draft. I'd like it to stay self contained.
dbaron: I'd like to keep it as one document to advance it quickly
glazou: we decided to move this as fast as possible if we start to
work on it. Makes sense to keep it like this.
glazou: my only problem is Issue #4 about % as values. This is undefined.
dbaron: I don't know what they do. Someone needs to tell us.
florian: I think we should drop percentages, but do not think there is a
problem with publishing with that issue ope.
florian: if we publish this draft, it is a good starting point.
florian: it is a weird feature. It does not describe the layout as such,
but only when used with certain browser features.
florian: we do not have anything else like this.
dbaron: we have features that are specific to implementations that scroll
with scrollbars. We have screen v.s., print. This is a feature
specific to implementations that do the text-size-adjust in a
certain way. Not all mobile browsers, but some.
glazou: any objection to move to an ED of the group?
fantasai: When would we publish FPWD?
glazou: Issue #4 needs more work before we publish.
dbaron: and maybe other thing need more work before we publish FPWD
<tantek> thank you glazou
<tantek> agree with dbaron
RESOLVED: Move text-size-adjust to ED.
Fragment Identifiers CG
-----------------------
molly: I wanted to report on the community group liaison. Including what
Simon and Erik were working on, fragment identifiers.
molly: people are looking for more people to help.
glazou: no action required at this point?
molly: no. But if you have interns or other people who would like to
participate, send them to me.
CSS3 Backgrounds and Borders
----------------------------
glazou: backgrounds and borders.
glazou: one last issue requested and then request to move to CR.
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0032.html
fantasai: the issue is a request to clarify what properties apply to
::first-line and :first-letter. We will clarify that they all
apply to first-letter.
fantasai: For first-line, CSS allows background, but not borders. There
are some discussions about how to extend CSS2.1 logic to CSS3.
It seems CSS2.1 excludes borders because they affect the box
model; we don't have a box model for applying borders/margins/
padding to line boxes.
fantasai: There is several different ways to handle the situation.
fantasai: First proposal: first line takes all the background properties,
may support the border properties-* and must not support the other
ones. (This is in the email.)
fantasai: there is a variation to put box shadow in the must not category.
fantasai: But I do not think there is a good reason to forbid it because it
does not affect layout.
fantasai: the second proposal is to include border-radius in the must support
category, since it is not so much a border property and isn't reset
by the 'border' shorthand.
fantasai: Third, there is a proposal to add border-image into the must support
category, because it technically does not affect layout either, only
decorates what's there. But it is reset by the 'border' shorthand.
fantasai: nobody participating feels strongly about requiring support for
border-image.
fantasai: there was concerns about allowing box-shadow because it is not
supported in IE 9 because it was forbidden before.
fantasai: My preference is to put box-shadow in the may category, since I
don't see a reason to forbid it.
florian: agree on box-shadow and no strong feeling on others, but ok between 1
or 2.
<smfr> webkit already supports box-shadow on ::first-letter
<fantasai> we're talking about ::first-line
<smfr> webkit supports on ::first-line also
brad: prefer 3. Like to allow implementations to have border-image and box-shadow
and border-image on the first line.
fantasai: all proposals would allow these properties. 3 requires them.
brad: I prefer requiring.
glazou: others?
sgalineau: 1 and 2 are my preference. No strong preference, leaning towards 2.
dbaron: no strong opinion.
glazou: seems like 2 is the easiest way for the time being?
fantasai: that's my favorite.
glazou: 2 acceptable compromise?
brad: 2 allows border image but does not require it?
fantasai: yes.
brad: box-shadow allowed but not required.
fantasai: yes, I think that should be the case. Does MSFT have an objection
to that?
sylvaing: no.
RESOLVED: proposal #2 accepted for properties on ::first-line, box-shadow
allowed but not required.
fantasai: with these two edits, I think the last two comments will turn
green.
bert: I think you are right. Checking the disposition of comments...
<Bert> -> http://dev.w3.org/csswg/css3-background/issues-lc-2012 DoC
glazou: John you sent a message about testing background and borders.
john: I have not got an answer to my questions. My tests are still in the
incoming and submitted folders. I do not yet know which parts are
covered. Still work needed for the test suite.
dbaron: the Mozilla tests are detailed tests of small sections of the spec.
dbaron: e..g., tests on sizing vector images.
fantasai: don't we have tests on other things?
dbaron: there may be more we could contribute.
glazou: this is an effort we should start now.
glazou: bert you pasted a link to disposition of comments. I still see
orange.
bert: orange means we are waiting for acknowledgment from the commenters.
glazou: I also see 3 open issues.
bert: I think they should be green or orange.
bert: we should mark that as accepted.
fantasai: we clarified the section that was confusing.
glazou: issue #7 is opened and should be changed. 18 and 22?
fantasai: we just resolved and I'll make the change.
glazou: we can make the transition request to move to CR. objections?
(silence)
sylvain: Go for it!
RESOLVED: Move Background and borders to CR
ACTION: fantasai and Bert, finish edits and update DoC
<trackbot> Created ACTION-456
CSS2.1 Margin Collapsing
------------------------
anton: we are looking at the CSS 2.1 errata items.
anton: the idea is to propose some solutions, seek feedback and then fix
by bits and then sign off.
anton: the ones we are going to look at right now have to do with margin
collapsing and related to the issues discussed during the Paris F2F.
anton: there are 2 links in the agenda. Let's concentrate on the second one.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Mar/0618.html
antonp: the 3 issues in that link were discussed in Paris. The proposals
were discussed with Arron. I am hoping we can get agreement.
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Mar/0052.html
anton: the specific proposals are on the link
anton: First issue: there was a strange note on 10.7 on the effects of
min/max height. I am proposing a simplification of this note.
anton: the proposal is to delete the second sentence of the note.
<dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16049#c1
antonp: the second sentence is not necessary and it is confusing.
glazou: I suggest we resolve this one first before moving on.
florian: what was the sentence attempting to do?
fantasai: it was trying to clarify that these steps do not affect margin
collapsing. Removing the sentence removes the clarification.
We should reword in a less confusing way.
fantasai: could be "for example, margin collapsing is not affected because
based on computed values and not used values"
glazou: the sentences are in a note?
anton: yes.
anton: I think that whatever we say raises more questions than it helps.
fantasai: any problem with my suggested rewording?
antonp: yes.
anton: the majority of layout is in the same position. When we tried to
reword, it seemed odd to attract attention to a particular part
of layout. I still don't think it is necessary.
arronei: I think it raises questions. I understand we say 'for example'
and it still raises questions. It is loosely related, but it
should be taken as two separate pieces.
arronei: if it is clear that 8.3.1 only works with computed values, let it
say that.
fantasai: for people who are not familiar with the spec, it helps
understand the difference.
fantasai: and how the distinction can affect the computations.
glazou: it seems to me that the two sentences shouldn't be glued together
in the same note. We could have one for anton and arronei's issue
and the one for fantasai's point.
florian: I have a mild preference for fantasai's proposal.
molly: I think that if someone comes against used/computed for the first
time, clarification as an example is useful.
molly: leaning towards that.
glazou: is fantasai's proposal a compromise you can live with?
arronei: I think that what fantasai proposes is fine, with 'for example'
prefix. May need some rewording.
* fantasai wonders if dbaron is on the call
RESOLVED: replace the sentence with Fantasai's proposal
.
glazou: next one?
<fantasai> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16036
antonp: we discussed in some details in Paris. margins collapse all the
way through an element that had a non-zero min-height. We decided
we would prevent some aspects of the margin collapse to avoid the
case described in the bug.
antonp: the proposal is to add a new bullet to the section describing
which adjoining margins collapse.
<glazou> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16036
<antonp> Proposal: http://lists.w3.org/Archives/Public/www-style/2012Mar/0052.html
glazou: Proposal is not in the bug.
antonp: I will do that as the outcome of this call.
florian: is that identical to the F2F discussion?
antonp: yes, it is identical.
florian: I agree with the F2F conclusion and still agree.
arronei: we did not want to change the f2f discussion, just make sure the
changes are happening in the right places.
glazou: any objections?
fantasai: the suggestion in the bug and email is different.
fantasai: why the differences.
antonp: there is a long history, emails on the mailing list. Negotiating
the cleanest way to specify what we now say. Editorial differences.
fantasai: I see.
antonp: in the bug report, we were trying to tweak the definition of what
was adjacent. The current proposal talks about preventing collapsing
in some cases.
antonp: we decided it was better to focus on the collapsing of the margins
rather than the adjacency of of them.
florian: reading the sentence makes sense and it says the same thing we
discussed at the f2f.
fantasai: I am ok with it.
fantasai: I'd like dbaron's opinion.
antonp: this does not affect adjoining at all.
antonp: this prevents certain margins from collapsing. Are we contradicting
other parts that say that margins collapse?
dbaron: I believe the definition of adjoining is transitive.
antonp: this is the subject of another post on the agenda.
dbaron: I'd rather say they are not adjoining rather than say they do not
collapse.
fantasai: would that be the proposal in the bug report?
antonp: checking.
antonp: this was part of a discussion we had. Arron's preference was to
not make them adjoining as well.
antonp: but, to me, it does not make a whole of conceptual sense. They are
adjoining, but they do not collapse.
arronei: some times, they are adjoining, so it is hard to say they are not
in these cases.
florian: in the layman interpretation of adjoining, they may be or not.
antonp: I do not think there is a problem with the definition of adjoining.
It is supposed to reflect an intuitive understanding.
antonp: if people want to make it not adjoining, I'd like to understand why.
dbaron: the reason we don't want collapsing here, is that in most cases,
the min-height causes the margins to not be next to each other and
should not collapse.
antonp: another aspect, is that this is hard to word.
antonp: you have to specify the conditions. They are very specific.
* sylvaing is starting to suspect the LHC was built to figure out margin collapsing
antonp: on the one hand, I understand the argument that they are not always
next to each other, but it is really hard to word the sentence about
them not being adjoining.
* fantasai thinks we shouldn't have made min-height bottom margins collapse
with their children
florian: If there was an easy way to say they are not adjoining, I would
prefer that, but since there is not I am find with Antonp's proposal.
glazou: dbaron, are you ok?
dbaron: hard to say, I'll go with whatever they say
glazou: objections to the proposal?
RESOLVED: proposal in email 0052 accepted for bug 16036
Bandwidth Queries
-----------------
glazou: only 4mn remaining.
<glazou> http://css-tricks.com/bandwidth-media-queries/
glazou: we have a proposal relayed by leaverou about a new media query.
florian: I have thought about this (about bandwidth). While this could
be interesting, I am not sure how you would use it or make it
work.
glazou: on mobile devices, this would allow you to switch between Wifi,
3G, others...
florian: you could be connected to multiple at the same time. You could
have wifi slower than 3, etc...
<Katie> My concern is about mobile...the fact that speeds vary frequently.
florian: if you switch from one connection type to another while loading,
it is hard to say what should happen.
florian: not sure there is a good way to use that.
glazou: what do others think?
* antonp agrees with Katie
fantasai: I would say that if you have to make a decision at the beginning
and not change that later during the life of the document.
That makes it easier to define and more consistent behavior.
<dbaron> I don't think authors want us to reload to use smaller images
when the bandwidth goes down
fantasai: Such a feature would be useful in other cases, e.g., dial-up
connection.
glazou: enough people have concerns with it and we do not need to work
on it for the next level of media queries.
florian: the proposal needs to be more specific.
ACTION: Florian to respond to Lea's email on the mailing list.
<trackbot> Created ACTION-457
sylvaing: I think use cases are missing.
glazou: yes, that is a good answer.
Meeting closed.
Received on Wednesday, 4 April 2012 21:43:46 UTC