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

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 04 Apr 2012 14:43:15 -0700
Message-ID: <4F7CC073.3030400@inkedblade.net>
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 GMT

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