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

[CSSWG] Minutes and Resolutions Telecon 2012-05-30

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 30 May 2012 17:21:27 -0400
Message-ID: <4FC68F57.1030906@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - RESOLVED: Support the publishing of Fullscreen provided the edits (in
               minutes) are made.
   - RESOLVED: Switch before/after logical directions to head/foot (globally,
               across all of CSS)
   - RESOLVED: Tab and fantasai to decide on directional keywords for alignment

====== Full minutes below ======

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins
   David Baron
   Ryan Betts
   Bert Bos
   Tantek Çelik
   Phil Cupp
   Katie Ellison
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Koji Ishii
   John Jansen
   Chris Lilley
   Peter Linss
   Alex Mogilevsky
   Edward O'Connor
   Florian Rivoal
   Dirk Schulze
   Alan Stearns
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/05/30-css-irc

Scribe: TabAtkins

plinss: Any last minute agenda additions?

Fullscreen Spec
---------------

   plinss: Webapps wants to publish a FPWD.
   plinss: This is a joint deliverable with CSS, so we need to sign off on
           it as well.
   fantasai: There's a few minor things to fix up, but overall I think it's
             fine.
   ChrisL: I agree with some of the things that Daniel talked about, but
           think it's okay to publish.
   <glazou> http://www.w3.org/mid/4FC630E6.1050406@disruptive-innovations.com
   ChrisL: We should probably triage between things that need to be addressed
           before publishing and what can wait until after.
   glazou: Main comments are #2 and #4.
   glazou: I think the section about ::backdrop is unclear.
   glazou: I think fantasai gave a good explanation of what it represents,
           but it needs a better explanation in the spec.
   glazou: Second thing is the definition of "layer". I think it's pretty
           unclear.
   glazou: For example, I don't know what "Layer 10" is.
   * ChrisL hopes it goes to 11
   fantasai: It's referring to Appendix E, the painting order layer.
   <fantasai> http://www.w3.org/TR/CSS21/zindex.html#painting-order
   glazou: Okay, so it needs refs and hyperlinks.  It's not understandable
           as it is.
   glazou: Provided these clarifications are added, I'm okay with the document
           being published.
   <tantek> I can work with Anne to make the edits happen today
   <fantasai> tantek, see also
              http://lists.w3.org/Archives/Public/www-style/2012May/1131.html
   <ChrisL> tantek, that is very helpful

   florianr: Daniel, I'm surprised you're not calling for the WHATWG ref
             to be fixed.
   glazou: It's important, but it doesn't need to be fixed now, and it's
           outside the scope for the CSSWG comments.
   glazou: We'll make the comment and see if the consortium agrees later.
   [missing some minuting about WHATWG ref]
   TabAtkins: (doesn't see any reason to change the ref besides "We hate the
               WHATWG")
   sylvaing: Is there any reason it needs to point to WHATWG version? If not,
             should point to W3C one.
   <sylvaing> I don't see any reason to link to the WHATWG except 'we hate
              the W3C' :)

   Edits requested by CSSWG:
   1. Update the ref to to W3C spec.
   2. Update the text around ::backdrop to better explain what it's for.
   3. Ref/link the talk about "Layer 10" and similar.
   4. Fix computation of the 'position' property ('center' doesn't exist yet)
      http://lists.w3.org/Archives/Public/www-style/2012May/1131.html
   5. In the SotD, it needs to point to both WGs and say that it's explicitly
      a joint product.
   <tantek> the "Update the text around ::backdrop to better explain what
            it's for" is a bit vague
   <tantek> and seem so to require another review / re-evaluation before
            proceeding
   <glazou> tantek: for the time being, nothing is said about what _it is_
   <TabAtkins> tantek: Suggestions welcome.  That's roughly what Daniel's
               feedback was.
   <glazou> tantek: just say what it represents
   <tantek> would an additional 1-2 sentence description be sufficient?
   <ChrisL> +1 to publish with those edits
   <glazou> what ChrisL  said :)
   RESOLVED: Support the publishing of Fullscreen provided the edits (in
             minutes) are made.

   florianr: What is happening with the future of this spec? Do we just
             count on Tantek remembering to bring it by the WG sometimes?
   <ChrisL> going forward we would expect to be more closely involved in
            creating the actual text
   ChrisL: I think we need closer involvement.
   hober: How is this different than anything else?
   <glenn> i am also a member of both groups
   glazou: I think it's not difficult for tantek to just bring things by
           sometimes.
   plinss: As editor, Tantek has responsibility to bring updates to the WG

   See Appendix A for Tantek's responses.

Alignment/Flexbox/Writing Modes Terminology and Naming
------------------------------------------------------
+tantek
+Rossen
Scribe: fantasai

   fantasai: [discusses switching to head/foot instead of before/after]
   <fantasai> http://wiki.csswg.org/topics/rename-before-after
   fantasai: So far we haven't released any actual syntax using before/after
             as keywords or properties.
   <glenn> -0.9 on change to head/tail; don't believe before/after is confusing
   alexmog: What makes this better?
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012May/1065.html
   TabAtkins: before/after has never been great, and ::before/::after is
              obviously confusing with it.
   <sylvaing> +1 on the confusion with ::before/::after
   szilles: is head/foot culturally sensitive?
   [...]
   fantasai: There's two questions.  We *must* have different keywords for
             the two axes, for things like caption-side.  Then there's the
             question of whether the alignment properties should use those.
   szilles: I think before/after is relatively clear [...]
   <glenn> agree with alex
   Tab: I have no experience with Japanese publishing, so don't know if
        document headings are on the top or the side
   Koji: Footnote appears on the left
   fantasai: And a heading appears on the right side of a section
   <ChrisL> so it is consistent between horizontal and vertical
   alex: We haven't had time to think about this
   alex: Regardless of what we decide here, my vote for Flexbox is to use
         start/end in both dimensions
   plinss: You want Flexbox to use start/end even if everything else switch
           to head/foot?
   TabAtkins: Recall that this is not just for Flexbox, for the alignment
              properties that will be used for all layout models
   discussion of Hamburg resolution to adopt box-alignment across layout models
   dbaron: We didn't decide to use them for block yet.
   Florian: I'm in favor of using the block-axis keywords in that axis,
            regardless of what they are
   Florian: Don't have a strong opinion on which keywords to use, but prefer
            head/foot
   some confusion over orthogonal flows
   TabAtkins: We're only talking naming today, not layout concepts
   szilles: I think you're missing Bert's point, [he's confused about ...]
   szilles: Basically the coordinate system changes at the content edge
   szilles: Outside the content edge, use the parent's coordinate system
   szilles: inside the content edge, use the element's coordinate system
   * fantasai suggests chairs call a straw poll
   * ChrisL lets avoid 'rename all the things'
   Bert: [describing some wording problems with logical terms]
   TabAtkins: So you're saying head/foot is easier to do
   Bert: Should just use A/B/C/D to refer to sides of the box
   TabAtkins: No, that's horrible.
   <glenn> -1
   plinss: Is anyone objecting to switching to head/foot?
   <sylvaing> is not hearing strong objections but is not hearing much of
              a consensus either
   <stearns> fwiw I like head/foot too
   szilles: SVG uses text-before/text-after
   fantasai explains that text-before isn't really the before side anyway,
            it's the "over" side
   ChrisL: SVG is happy to follow CSSWG
   szilles: I can live with head/foot
   * alexmog prefers before/after. not clear at all that head is logically
             before.
   Florian: I might be wrong, but I think it's the first time we use body
            parts in a spec
   <tantek> HTML has THEAD TBODY TFOOT
   fantasai: HTML has <header> and <footer>
   sylvaing: As far as English goes, it's a decent choice, and I think it's
             much clearer.
   RESOLVED: Switch before/after to head/foot
   <tantek> Florian, CSS 2.1 uses table-header-group, table-footer-group
             http://www.w3.org/TR/CSS21/tables.html#table-display

   [See Appendix B for side-conversation]

   http://wiki.csswg.org/topics/start-end-before-after-align
   <glenn> would like different keywords for different axes
   TabAtkins: My major objection to changing to 4 direction is that while
              it makes sense for grid/block, which are writing-mode-relative,
   TabAtkins: For flexbox, this isn't true
   TabAtkins: So IMO using 4D for this particular set of property pairs would
              be worse, and we should use start/end for both dimensions for
              these sets of properties
   TabAtkins: In the actual spec I use main-end/cross-end etc.
   <glenn> but i agree with Tab on this
   TabAtkins: Properties use just start/end because I didn't need to be more
              specific than that.
   [we're discussing the justify and align properties]
   <glenn> can we use 2 keywords for flexbox, and 4 for grid/block?
   Florian: So if we just have Flexbox and Grid, it's just a coin toss which
            spec we're going to make more confusing
   Florian: When it is the bock axis, it's going to be confusing that
            start/end is used in block axis
   fantasai: ... trying to establish start/end/head/foot as a flow-relative
             set of directions, equivalent to top/left/bottom/right as
             physical directions
   fantasai: using start/end in both dimensions is inconsistent with that
   ...
   Florian: These are logical dimensions, logical relative to what can
            depend on layout mode
   <glenn> initial/final?
   TabAtkins: Referring to start side as head would be confusing
   fantasai: Wouldn't referring to head side as start side also be confusing?
   Phil: So, say I set margin-head: 10px; to put margin on head side of a
         column flexbox, what do I set to bunch up the elements towards that
         side of the box?
   TabAtkins: Regardless of what we decide here, it would be
              justify-content: start;

   Straw Poll
   A) use start/end/head/foot as flex-flow-relative instead of writing-mode-relative
   B) use start/end/start/end in both dimensions
   C) something else [TBD]

   fantasai: A
   * fantasai is ok with C as well
   Florian: A
   <florianr> A then C then B, to be specific
   plinss: A
   glenn: C
   JohnJansen: abstain
   Phil: abstain
   smfr: abstain
   rbetts: abstain
   dbaron: abstain, though maybe A, but abstain
   alex: B
   TabAtkins: B
   glazou: A
   sylvaing: abstains
   Katie: abstain
   ChrisL: A
   hober: abstain
   szilles: B
   stearns abstain
   rossen: abstain
   kojiishi: B
   Bert: maybe B
   tantek: abstain, unless consensus amongst editors
   <Liam> [Liam fears head/foot will be confusing with respect to running heads
           and footers, which are usually not writing-mode relative so B or C
           if my vote counts :-) ]

   <tantek> C = unicorns?
   Options for C?
   <glenn> by C I meant use something different for flow-relative
   <rbetts> near/far?
   <Rossen> Is C start/end/before/after
   <fantasai> Rossen, no it's before/after/before/after
   <fantasai> (or some other set of terms)
   Florian: C is to use same terms for both, but not to use the flow-relative
            directions
   Rossen: So it's the same as B, except with different terms
   <ChrisL> don't like the same terms to be used for both directions
   * sylvaing recalls a time when renaming things made me understand them
              better...
   <glenn> I would vote A for grid/block, but don't like confusion that would
           result if start/end also used with flexbox

   <rbetts> if you don't use the same terms for both directions, then you'll
            have to update two properties in concert. i.e.: if I change the
            flex orientation then I'd have to update the justify and align
            keywords, which seems unnecessary?
   <fantasai> no, rbetts, the keywords are tied to the property, not to the
              effective dimension
   <rbetts> ah, ok.

   plinss: Are people happy to use same terms in both dimensions?
   fantasai: yes
   <dbaron> I'll switch from abstain to A. :-)

   Phil: I had resolution that we'd use fantasai's new alignment properties
         for Flexbox
   Phil: But her spec uses different terms in different dimensions
   TabAtkins: This issue is about that spec
   Florian: Because we're defining start/end to be in the inline direction,
            I'm happy for either using head/foot in the other dimension, or
            using a different set of keywords in both dimensions

   fantasai: so where are we at?
   fantasai: Are we going with C, if we can find a set of terms?
   dbaron: I don't think we should have three sets of keywords because people
           will have yet another set to confuse.
   TabAtkins: I'm going to object to naming changes if we don't resolve this soon
   <tantek> +1 to reducing namesmithing/thrashing/bikeshedding
   <sylvaing> +100. bikeshedding at last call is an anti-pattern
   Phil: Can we just prefix the flex alignment properties and fix this later?
   <Ms2ger> That's an awful idea
   fantasai: I don't think that is a good way of fixing the impasse
   sylvaing: I don't like deciding on the API and then renaming the whole
             thing, not an efficient way to work
   <tantek> "rename all the things!" (or was that not to…)
   sylvaing: But if we can just settle it now, let's do it. We can't keep
             going like this.
   florian: So we have all the preferences, but does anyone object to A or B or C?
   apparently not
   dbaron: I might object to C
   <dbaron> The goal is that this stuff apply to more than just flexbox.
   * Bert thinks 'justify-content: start' seems fine, but 'align-content: start'
          is unclear: which side is that? Is that clockwise from the start of
           the flexbox?
   discussion of having fantasai and Tab work it out
   RESOLVED: Tab and fantasai to decide on this issue
   <glenn> i'm ok with fanasai/tab reaching mutual agreement

Meeting closed.

Appendix A:

   <tantek> florianr - what do you mean by "bring it by the WG" ?
   <tantek> you can just follow it on mercurial right?
   <fantasai> tantek, I'm not going to watch your mecurial logs
   <tantek> fantasai - not *my* logs - just the spec
   <glazou> what fantasai said
   <tantek> if you care about a particular spec, watch its mercurial
   <glazou> tantek: no, you as editor, have responsibility to ping us
   <tantek> no need to spam everyone with delta emails
   <glazou> by _email_
   <tantek> glazou , citation?
   <glazou> re. mercurial
   <tantek> is that a request for a mercurial to email bot?
   <fantasai> no
   <tantek> I am not a bot
   <glazou> no, that's request to email us personnally
   <glazou> from you, not bots
   <fantasai> when there is something to discuss or review
   <tantek> denied
   <tantek> I am not going to email mercurial diffs
   <fantasai> nobody is asking you to do that
   glazou: If tantek isn't going to update the WG occasionally as appropriate,
           I object to publishing.
   <ChrisL> sigh, talk about snatching defeat from the jaws of victory
   plinss: We'll take this offline. We won't resolve this with communicating
           over IRC.
   <tantek> are there any technical objections?
   <tantek> or only bureaucratic?
   * glazou urrrghhh
   <florianr> non technical
   <TabAtkins> tantek, you're being ridiculous.  You know quite well that
               we aren't asking for HG diffs on every update, just occasional
               status updates like *every* editor gives for their specs.
   <TabAtkins> Quit arguing badly.
   <glazou> +1
   <tantek> I'm sorry I forgot the cover sheet on my TPS report.
   * ChrisL wants to know if the previous resolution still stands, given the
            tantek 'denied' comment.
   <tantek> ChrisL - I simply denied request for emailing HG diffs to the WG.
   <TabAtkins> tantek: NOBODY ASKED FOR THAT.
   <ChrisL> strawman
   <sylvaing> tantek.mouth.insert(tantek.foot)
   <glazou> tantek: just with ALL editors, we need to be kept posted when
            important changes/additions are made
   * tantek finds a phone
   <tantek> glazou - I don't know how to evaluate what's "important" to
            individuals. from my perspective, "important" changes should/will
            trigger requests to publish an updated working draft, is that
            sufficient?
   <glazou> tantek: no
   <sylvaing> tantek, glazou: can you guys hold on please?

Appendix B:

   <tantek> regarding spec audiences, please see the spec restyling in effort
            that fantasai, Vincent, and myself are working on :
            http://www.w3.org/wiki/Restyle#Audiences
   <sylvaing> tantek, very cool!
   <tantek> Thanks sylvaing! To be clear - input is very much welcome.
   <tantek> Feel free to even directly edit/add to the wiki page itself.
            If we disagree we'll edit it further :)
   <tantek> and likely ask to discuss it here.
   <tantek> If there are disputed priorities/opinions etc., we'll try to
            capture multiple viewpoints on the wiki.
Received on Wednesday, 30 May 2012 21:22:00 GMT

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