Minutes Sapporo F2F 2015-10-26 Part IV: Logical Properties and Values, Next F2F Meetings [css-logical-props]

Logical Properties and Values

  - fantasai introduced the proposed syntax to add logical keywords
      for background images. The group needed more time to review,
      but had some initial feedback:
      - There were some hesitations about 'start' and 'end' as single
        values, since background-position normally defaults the
        second value to 'center', rather than duplicating it.
      - Since the initial values of the physical and logical
        properties don't match, the logical properties will need to
        not have an initial value.
  - RESOLVED: Make logical coordinates always block, then inline,
              even though physical coordinates in background-
              position are horizontal, vertical.
  - RESOLVED: Properties affecting position of border-box (i.e.
              stuff outside the border edge) cascade by the
              parent's writing mode; stuff affecting inside the
              content-edge of the element keys off of the element's
              own writing mode. border/padding/sizing TBD

Next F2F Meetings

  - Since TPAC is in September in 2016, it was thought that the
      group may only want three F2F meetings in 2016 or, if they do
      a fourth, it would be in December.
  - RESOLVED: 2nd week of May, 9-11 (with possible Houdini 12-13),
              anywhere on US west coast. Host TBD.
  - The chairs plan to arrange for breakout meetings during the F2Fs.
      - Rossen will send out a survey to figure out topic tracks and
          analyze participant overlap.
      - Space may be a limitation for this approach in Sydney, but
          whomever hosts the May meeting should plan on having at
          least two rooms available.
      - There was an expressed desire for any resolutions coming out
          of a breakout to be tentative until they're reported back
          to the whole group and affirmed.


Agenda: https://wiki.csswg.org/planning/tpac-2015#agenda
Scribe: Bert

Logical Properties and Values

Background Position

  <dbaron> https://drafts.csswg.org/css-backgrounds-4/#the-background-position
  fantasai: First one is background-position.
  fantasai: We had requests from I18N WG to add logical keywords for
            background images.
  fantasai: (among other things)
  fantasai: There are longhand properties.
  fantasai: I came up with a syntax [see draft].
  fantasai: You can pick direction within an axis.
  fantasai: [shows examples]
  fantasai: background-position: x-start
  fantasai: background-position: left
  fantasai: background-position: start 10px

  fantasai: People probably need more time to look at this, but
            initial reactions?
  [discussion about physical-logical mix]
  TabAtkins: Florian once asked for 'top x-start'
  stevez: This is mostly to be able to distinguish when used in the
          short hand.

  dbaron: I'm a little hesitant about the one-value syntax with
          'start' or 'end'.
  fantasai: Yes, you default to center for the 2nd value normally,
            but 'start' duplicates itself.
  fantasai: And 'end' too.
  dbaron: Given that center is the default for 2nd in other cases,
          I'd prefer simply not allowing a sole 'start' or 'end'
  TabAtkins: I'd be OK with that...
  fantasai: I'd like to allow them, because I don't see why not. And
            duplicating is a common pattern for CSS properties.
  dbaron: ...except for background.

  johannes: [missed]
  fantasai: This topic is not only about background, also floats, e.g.
  leaverou: It does make sense to mix them.

  dbaron: Back to background:
  dbaron: I see two bigger problems.
  dbaron: One is that before top and [...] were mutually exclusive.
          That seems to be no longer the case.
  dbaron: Maybe not a problem.
  dbaron: Some longhands may not have an equivalent short hand.
  TabAtkins: That happens sometimes.
  fantasai: What case?
  dbaron: If you mix background-position-x and
  TabAtkins: It is fine to have values that cannot be expressed in
  dbaron: Probably it's OK.

  fantasai: We found initial values did not match easily. Unlike for
            margin, e.g., where the initial is 0.
  dbaron: Can say that logical property has no initial value.
  fantasai: Is that possible? In that case OK.
  stevez: need to explain what not applicable means.
  stevez: In general module about properties syntax.

  dbaron: [typing text]

2-Axis Positions vs. 4-Direction Shorthands

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2015Oct/0212.html
  fantasai: TabAtkins and I noticed we could not keep track of which
            came first when using two-value syntax.
  fantasai: Background and border-spacing have horizontal then
  TabAtkins: Logical ones start with block then inline.
  TabAtkins: I always write it wrong.
  TabAtkins: So we have issues and no satisfactory answers.

  fantasai: Grid-area vs grid-template...
  TabAtkins: Options A an B
  [A. Splitting the bucket so that:
      block/inline => grid-area, margin, padding, border, offset,
                      [ other 4-value ]
      inline/block => grid-template, background-position,
                   scroll-snap-align, [ other 2-value ]

   B. Making logical coordinates always block, then inline, even
      though physical coordinates in background-position are
      horizontal, vertical.
      background-position: start end; /* block, inline */
      margin: 1em 2em relative;       /* block, inline */

  stevez: Always block before inline seems easy to remember
  TabAtkins: Some properties have four values and two values.
  fantasai: We should go back in time and tell Hakon and Bert that
            background should be consistent with other properties.
  Florian: With Option B, we don't have a time machine to go fix it,
           but we can travel to a parallel universe where everything
           works correctly.
  Florian: Is this an incentive for people to start using logical

  TabAtkins: Any objection to option b, block before inline?

  RESOLVED: Option B (Make logical coordinates always block, then
            inline, even though physical coordinates in background-
            position are horizontal, vertical.)

  ACTION TabAtkins update grid with this resolution
  <trackbot> Created ACTION-730

Cascade of Physical and Logical Properties

  <astearns> https://drafts.csswg.org/css-logical-props/#property-index
  fantasai: Next issue is cascade of physical and logical properties.
  fantasai: The spec is currently a mess.
  fantasai: The problem is which writing-mode the property is
            relative to.
  fantasai: We discussed this before.
  fantasai: The complexity comes from that there is no perfect answer.
  fantasai: The simplest answer is use writing-mode of elt itself.
  fantasai: Easy to understand mapping,
  fantasai: but many rules reference CB.
  fantasai: E.g., drop margin based on CB,
  fantasai: Float start will float to start of CB,
  fantasai: Alignment follows container instead of grid item itself.

  stevez: writing mode applies to [...]

  Rossen: All the examples you gave make sense to reference CB.
  Rossen: Everything from border inside makes sense to refer to elt
  fantasai: Border itself could be either.
  fantasai: Inside the box, e.g., text-align refers to writing-mode
            of elt itself.

  fantasai: If box has has margin on end but different writing mode
            than CB, then margin may not disappear where it should.
  [ Example was 'float: start' with end padding/border/margin to
    create separation from non-floated content. If the surrounding
    content is LTR and the floated content is RTL, then the end
    padding/border/margin ends up being on the left side of a left
    float. ]
  fantasai: That causes frustration for authors.
  fantasai: In that case you use the parent, because difficult to
            compute layout of CB.
  Rossen: Really it only applies to positioned elements.
  [ Parent is only incorrect if CB skips ancestry with a
    'writing-mode' switch--expect this to be an exceptionally pretty
    rare case. ]

  Rossen: It means static position is still computed to parent.
  fantasai: No, this is about cascading.

  fantasai: Most things that have longhands work better against CB.
  fantasai: Pretty much everything in the draft.
  fantasai: Orthogonal flows are going to be a small percentage of
  Rossen: Block and inline size should be kept in @@@
  TabAtkins: Both seem reasonable: sometimes want to set content
             size, sometimes want all siblings the same size,
             independent of their writing-mode.

  stevez: Example of counting in number of lines.
  johannes: You want images of a certain number of lines?
  stevez: I'm thinking of a table, with one cell in Japanese.
  fantasai: You can always still use the physical properties.
  fantasai: Auto will shrink wrap; explicit size, like 50% keys off
            surrounding size.
  fantasai: Is percentage referring to horizontal or vertical
  fantasai: You want 50% in inline dimension and auto in block
  johannes: If you could specify lines, might want float of 10 lines
  florian: Say you have a magazine layout, with some boxes in
           different direction, but all specified to parent which is
           always in same direction.
  TabAtkins: You can have a keyword 'self' when you want to be refer
             to elt itself.
  koji: I see both cases exist, but not sure which case is more
        common. My instinct is to agree with szilles.
  stevez: I disagree with myself and now agree with TabAtkins.

  fantasai: Say I have simple, one-flow document. I want a block of
            50% and then lay something out inside it.
  Rossen: Say you have a rtl container, inside it a ltr container.
  Rossen: And set 1em padding on the end.
  Rossen: Now you say I end up with 1em on the end.
  Rossen: That makes no sense to me.
  TabAtkins: Browsers have had different default margins and
             paddings, e.g., in lists.
  Rossen: With physical properties you can get away with that.
  florian: When you have float, size and margin refer to CB, agreed?
  Rossen: Yes, but everything inside the border refers to elt itself.
  Florian: If you put some margin between yourself and parent, you
           may want the margin to be on the same side for all elt.

  stevez: Do we agree that everything from border out refers to
  florian: The blue border in our property definitions in the spec
           style should refer to parent.
  stevez: We agree on borders: borders are on outside.
  stevez: And we can discuss about the other pieces.
  r12a: You can have borders on spans, too.
  r12a: Don't you want the border relative to the text?
  TabAtkins: Some properties are arguable both ways.
  TabAtkins: We have a convention for that.

  dbaron: We are over-analyzing the example.
  dbaron: In most cases there will be multiple relatives.
  dbaron: Is the elt with the border the same as the elt with the rl
  dbaron: Many structures will have multiple elts.
  TabAtkins: And sometimes not. e.g., <li> is often just naked text.

  johannes: When we talked half a year go or so we thought it was
            strange margins would go on other side and we thought
            let's just put in a <div>.
  johannes: The extra <div> allows you to change the inner one
            without problem.
  stevez: The issue is can we have a simple rule, while still
          allowing people to set it up the other way.
  stevez: A simple rule that people can remember.
  rossen: In general it seems our implementation follows stevez's
          rule, border and everything out is relative to CB.
  dbaron: But we're talking about parent not CB now.

  fantasai: Look at quotes: they use punctuation of the context
  fantasai: Border is similar.
  stevez: If Arabic text in an English context is broken over two
  stevez: I still want English rules.
  fantasai: All our rules are designed around CB.
  rossen: I'm only talking about the case there is a switch of
          writing-mode, otherwise there's no difference.
  fantasai: In Japanese, writing-mode switch in side notes, caption,
            table headings, is quite common.
  <karl> example of Japanese Typography
  <karl> http://la-grange.net/2007/07/23-japanese-typography
  stevez: We are talking about a general rule. There may still be
          other use cases.

  rossen: Positional properties, such as margins, it makes sense to
          me to be relative to container.
  rossen: Sizes make sense to be relative to elt.
  stevez: That's why I want to agree on the outside case first.
  stevez: But I understand r12a's use case.
  fantasai: everything from border-box out.
  rossen: that includes alignment, float alignment...
  fantasai: inside the content-box belongs to element.

  <fantasai> Seem to have consensus on properties affecting
             positioning of the border box being wrt parent writing
  <fantasai> Seem to have consensus on properties affecting inside
             the content box being wrt element's own writing mode
  stevez: So we have disagreement on border and padding.
  florian: We also disagree on size.
  fantasai: text-indent is inside.

  TabAtkins: Proposed resolution: Everything outside the border-box
             is resolved relative to parent's writing-mode.
  astearns: Let's do whiteboard discussion outside this meeting.
  bert: And that says "parent" not "CB" is that correct?
  TabAtkins: Correct.
  fantasai: Implementers see margins as positioning, different from
            border and padding. Authors see it as similar to padding
            and border.
  leaverou: New authors confuse margin and padding a lot.
  leaverou: Experienced uses see them as margins as separate from
            borders and padding.

  florian: Given margin: auto can affect the size of the element,
           it's weird to treat them differently.
  rossen: Margins never influence the width.
  florian: If margins are outside and relative to parent [...]
  rossen: You want to set what exactly?
  florian: Width to specific value, relative to parent.
  rossen: Don't see that use case.
  johannes: There are rules for how many characters per line and how
            many lines minimum. Then you want all measurements
            relative to outside.
  florian: Character grid rhythm.
  stevez: So it seems we can agree on the proposed resolution.

  RESOLVED: Properties affecting position of border-box (i.e. stuff
            outside the border edge) cascades by the parent's
            writing mode; stuff affecting inside the content-edge of
            the element keys off of the element's own writing mode.
            border/padding/sizing TBD

  fantasai: I think that is it for the major issues. Rest is tons of
            issues to edit.

  astearns: So what topic next?
  fantasai: We have i18n people here, any topics related to that?
  r12a: I have no issues at the moment.
  fantasai: snap points with logical keywords.
  matt: I think all the x/y stuff is gone already.
  Rossen: Snapping is more of a positional property.
  Rossen: Something consistent in the parent scrollable.
  Rossen: Calling it start rather than left makes.
  bert: I want to be able to just say 'left' as well.
  matt: The only thing in spec that implies logical is positioning.
  fantasai: Larger discussion, 1D vs 2D and things.

  Rossen: wrt Bert's issue: If I specify left and than transform,
          where is the snap point now?
  Rossen: Left refers to bounding box.
  matt: I think we don't need to edit anything in the spec for this.
  fantasai: If we split into scroll-snap-area and -align...
  matt: No actual text change.
  fantasai: Either way we'll add logical stuff. That probably solves
            that problem.

Next F2F Meetings

  astearns: TPAC 2016 is in Sep.
  astearns: So no sense in an Aug F2F.
  glazou: There was a suggestion to have a meeting in Sophia-
          Antipolis between Feb. and TPAC.
  glazou: Probably only 3 ftfs next year.
  dbaron: We can also have a meeting in December.
  glazou: But avoid blizzards :-)
  TabAtkins: Holiday travel is problem.
  Florian: TPAC is not on Halloween, so can do ftf on Xmas :-)

  skk: Can host at Keio around June.
  dbaron: AC meeting is in March in Boston.
  john: June is not so good for Mozilla.
  dbaron: Whole of Mozilla will be in London June 10 to June ?
  dbaron: Adjacent weeks may work, depending on location
  <dbaron> Moz folks will be in London June 13-17.

  dino: Apple can host early May in Bay Area, or after mid June.
  dino: May is not guaranteed.
  fantasai: So many companies are in the Bay Area, if Apple can't we
            can find another.

  dbaron: The mid point between Feb and September would be end of
          May begin of June.
  dino: That would not work for Apple, Apple conference.
  rossen: Besides Apple, other organizations with constraints on
          that time?
  <dbaron> There's actually not an exact midpoint -- the midpoint
           between the February and September meetings is halfway
           between meeting the week of May 23-27 and the week of May
           30 - June 3.
  dino: If you pick a day, I can see if I can host. And if not, we
        can definitely still send someone to the F2F.
  TabAtkins: Late May is probably Google IO - bad for hotels in Bay
  astearns: Sounds like 9-11 May
  dino: Should we have a Houdini meeting, too?
  glazou: Then take whole week.

  Rossen: Last time, San Diego was wonderful
  astearns: So 2nd week of May, and we'll find out who can host.
  [1st week is Golden Week in Japan]
  dbaron: So going *to* Japan at the end of that week could be
  Rossen: Proposal is 2nd week of May, 9-11 (with possible Houdini
          12-13), anywhere on US west coast.
  Rossen: Host TBD

  RESOLVED: 2nd week of May, 9-11 (with possible Houdini 12-13),
            anywhere on US west coast. Host TBD.

  Rossen: We talked about short meetings. In parallel, one joint
          meeting the 2nd day.
  fantasai: People prepare topics for the F2F. Let's do those topics
            first, then split into parallel for the rest.
  Florian: 3 days is not long. 7 days is long.
  Florian: There's no need to shorten a 3 day meeting. We can have
           Houdini in parallel with some CSS topic.
  TabAtkins: With few exceptions (fantasai :-) ), half of room tunes
             out for some topics.
  Rossen: We can try maybe already in Sydney.
  johannes: page-related stuff can also be split out in parallel.

  dino: So that means we need multiple rooms.
  TabAtkins: One big room and some small.
  shane: I can't guarantee extra rooms in Sydney.
  johannes: There may also be even "smaller" topics, say footnotes.

  rossen: I will send out a mail, list the topics, and ask people
          what they want to work on.
  rossen: Be honest: if you don't care about X, that's OK
  astearns: You mean break-outs will never resolve on anything?
  rossen: They will resolve, but report.
  rossen: We have two chairs, we can have two parallel sessions.
  stevez: I think fantasai's point is that there are resolutions,
          but people not there can come back to them.
  florian: Better to call it a tentative resolution.
  florian: Then you can reopen, even if you bring no new arguments.
  rossen: OK, we'll try to start this method in Sydney, if we can
          get rooms.
  shane: We can't get rooms on Monday, maybe on other days.
  rossen: That'll work.
  fantasai: If we split ourselves too much, CSS gests inconsistent,
  fantasai: I'm in favor of coming to resolution, but indeed call it
            tentative. Want to encourage everyone to be engaged in
            the topics even if they weren't present in the breakout.

  [Adjourned until tomorrow]

Received on Thursday, 19 November 2015 01:39:38 UTC