W3C home > Mailing lists > Public > www-style@w3.org > July 2018

[CSSWG] Minutes Sydney F2F 2018-07-05 Part II: CSS Box Alignment, CSS Inline Layout [css-align] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 24 Jul 2018 19:51:28 -0400
Message-ID: <CADhPm3s7pVCb+_ot0svzQwPeVLYY_rzQJs19nn-Uw2_-=z3oxQ@mail.gmail.com>
To: www-style@w3.org
=========================================
  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.
=========================================


CSS Box Alignment
-----------------

  - RESOLVED: The static position rectangle is used as the alignment
              rectangle of the statically positioned abspos (Issue
              #1432)
  - RESOLVED: For blocks the static position rectangle is the 0-height
              rectangle between the start and end static position
              offsets as defined in CSS2.1 (Issue #1432)

CSS Inline Layout
-----------------

  - RESOLVED: initial-letter applies to inside markers + clarify spec
              on :first-letter interaction with markers (Issue #2705)
  - RESOLVED: Resolve as "won't fix" (no fixup) and add a note
              explaining what dbaron already mentioned above [if you
              set float then initial-letter won't apply] (Issue #688)
  - RESOLVED: Approve the edit “All properties that apply to an inline
              box also apply to an initial-letter (unless it is an
              atomic inline, in which case the set of properties that
              apply to an atomic inline apply) except for
              vertical-align and its sub-properties, font-size, and
              line-height.” (Issue #2700)
  - RESOLVED: Accept sizing properties for initial-letter
              [edit:
https://github.com/w3c/csswg-drafts/commit/4893b213ff17a4c8deab181c6997b47b93972911
]
              (Issue #863)
  - RESOLVED: The initial-letter will be the first inline that has
              initial-letter not set to normal, (+details in the spec)
              (Issue #2184)
  - RESOLVED: The initial-letters will behave as if was taken/rendered
              outside of its inline ancestors’s boxes (Issue #2184)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule

CSS Box Alignment
=================
Scribe: emilio

align/justify-self on static position of abspos boxes
-----------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1432

  fantasai: We're asked to define precisely how the alignment
            properties interact with static pos.
  fantasai: The remaining one is how align/justify-self interact with
            it
  fantasai: The basic model for abspos and alignment is that you have
            your abspos containing block and your offsets
  fantasai: and that produces a rectangle in which you do your
            alignment
  fantasai: The default behavior comes from CSS21 and depends on
            whether you're replaced or not
  fantasai: That's an inconsistent mess but well defined

  fantasai: Now the question is about what to do when offsets are auto
  fantasai: For flexbox and grid children, the alignment container is
            well defined: it's the flex or grid container’s padding box
  fantasai: For the general case, we propose to make the alignment
            rectangle the static position rectangle, that is, the
            rectangle representing the position of the element if it
            were not abspos

  fantasai: In CSS2.1 you've got your CB, a bunch of content and your
            element which would be abspos and then you calculate the
            offsets that represent this rectangle.
            [that is, both sides exist: static position is not a point]
  fantasai: Depending on the 'direction' property, you ignore one of
            the sides and then do your positioning calculations.
  fantasai: Our proposal is defining the static position rectangle as
            a 0-height rectangle occupying between the left and right
            edges of the static position as defined in CSS2.1.
  fantasai: Which means you can control the alignment of the abspos
            element with respect of its static position containing
            block
  fantasai: Anyone has any comments?

  iank: For orthogonal writing modes, your static pos rectangle may
        change as soon as it's constrained
  iank: If you've got a mismatch between the abspos CB and staticpos
        CB as soon as you constrain it it's going to change the axis
        you align it against right?
  iank: So depending on the CB's writing mode that'll affect whether
        you use align or justify self to get the centering
  fantasai: No
  fantasai: mismatch between writing-mode static pos and abspos CB
            doesn't change which axis the alignment properties affect
  Rossen: Bottom line is alignment happens in the CB
  Rossen: Static pos is calculated in your parent and used in your CB,
          and the wm that applies to it is the one of the CB

  Rossen: I think there was one gotcha here which was if your static
          position is affected by the wm of your parent
  Rossen: Imagine you have two empty elements and an abspos inside
          and the topmost is ltr and the inner one is rtl
  Rossen: one abspos auto-positioned inside the inner one and the CB
          is the outer one
  fantasai: [draws]
  fantasai: So you have an LTR rectangle. Inside that you have an RTL
            box. Inside that you have the abspos
  fantasai: [draws the static pos 0-height rectangle]
  Rossen: So, if I position with `justify-self: start` for the
          abspos...
  fantasai: The direction used is the direction of the abspos CB
  fantasai: If you want to use the abspos’s own writing mode you can
            use `self-start`, but the axes you reference are the axes
            of the abspos CB

  RESOLVED: The static position rectangle is used as the alignment
            rectangle of the statically positioned abspos
  RESOLVED: For blocks the static position rectangle is the 0-height
            rectangle between the start and end static position offsets
            as defined in CSS21

  Rossen: [actually resolves]
  Rossen: Is that everything?
  fantasai: Yes.

CSS Inline Layout: initial-letter
=================================

  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jun/0020.html
  <tantek> again what dauwhe referred to as "Tantek's indieweb thing"
           http://tantek.com/2015/224/b1/alphabet-indieweb
  <florian> thanks for the link

Should 'initial-letter' apply to 'list-style: inside' ::marker?
---------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2705

  fantasai: We're not expecting this to happen immediately, but we want
            to make it apply since they should be laid out as any other
            inline
  fantasai: so proposal is 'yes, should apply'
  eae: We're not opposed to it but it's not something we can implement
       for a while, so as long as you're fine with that...

  dbaron: It doesn't feel different to whether ::first-letter applies
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Aol%2C%20li%20%7B%20list-style-position%3A%20inside%20%7D%0Ali%3A%3Afirst-letter%20%7B%20color%3A%20green%3B%20background%3A%20yellow%20%7D%0A%0A%3C%2Fstyle%3E%0A%3Col%3E%0A%3Cli%3Ehello%0A%3Cli%3Etest%0A%3C%2Fol%3E
  dbaron: I'm seeing interop in the non-desirable behavior so far
  TabAtkins: We agree it should be the same, but our code for that is
             bad
  Rossen: In our case it already applies
  fantasai: Really?
  Rossen: Actually no
  dbaron: So far Gecko / Chrome / Edge all seem to support
          ::first-letter but they support it on the thing after the
          marker
  <dbaron> ... and WebKit

  myles: Why is putting it on the marker better?
  fantasai: Cause it seems reasonable to style your markers / counters
            using initial-letter
  <fantasai> esp for numbered / lettered lists
  TabAtkins: This is common on magazines, with list items being very
             big and such

  heycam: And if they go beyond nine?
  TabAtkins: They don't, but if they do 'ok, there's ten, and it's
             bigger'
  [others]: That's two letters then
  fantasai: We definitely allow multi-letter initial-letters
  fantasai: What is a letter is a very interesting question outside of
            latin
  fantasai: We allow it to apply to the first inline box on a block

  frremy: Is the marker position inline?
  fantasai: Yes, only when list-style-position: inline
  dbaron: It seems reasonable, but I'm concerned because we seem to
          interop on :first-letter
  fantasai: We don't really want to change how :first-letter works
  fantasai: :first-letter should keep doing what it's doing
  dbaron: Ok, I guess I'm fine with that

  koji: When the list marker is a bullet and includes punctuation,
        is the proposal to make initial-letter apply to the bullet
        and the next letter?
  fantasai: No, only for the first inline box, if it happens to be
            a marker good, same for ::before, etc
  xidorn: So if there's an inside marker, initial-letter doesn't
          apply to anything afterwards, right?
  fantasai: Right

  Rossen: Ok, so we're on the same page, are we ready to resolve then?
  Rossen: regardless of if/when it's implemented
  myles: So if you have a list and the first letter of the list is
         'This', how do you style it?
  fantasai: Either an outside marker and initial/first-letter, or an
            inside marker and first-letter
  Rossen: [confirms ^]
  florian: Not sure if I misunderstood
  florian: But using initial-letter you cannot change the color of
           the marker, you'd need to use `::marker` for that
  <fantasai> thanks Florian!
  Rossen: But in any case the first inline after the marker is targeted
          by ::first-letter
  everyone: Yes
  myles: [confused]
  dauwhe: Webkit will apply an initial-letter with li::first-letter,
          which is troubling

    [ fantasai tries to sort out confusion between what :first-letter
    is (it's a pseudo-element) and what an initial-letter is (it's a
    styling that can be applied to certain inline boxes, such as
    the one selected by :first-letter ]

  dbaron: So, to summarize: For list items, `::first-letter` ignores
          the marker
  dbaron: so the initial-letter property applies to `::first-letter`
          pseudos and to inlines at the beginning of block
  dbaron: so the spec doesn't have the exception for when
          `::first-letter` is not at the beginning of the block due
          to an inside marker
  dbaron: and we need to clarify that `initial-letter` doesn't apply
          in that case
  dbaron: Maybe bidi can introduce a similar problem
  fantasai: We need to clarify that, but the spec already mentions bidi
  <fantasai> “If initial-letter is applied to an inline-level box that
             is not positioned at the start of the line due to bidi
             reordering or which is otherwise preceded by other
             inline-level content, its used value is normal, and it is
             not formatted as an initial-letter.”
  dbaron: So, the other piece is that the bit about initial-letter can
          apply to an inline at the beginning of the block, but we need
          to clarify that it includes the inside marker
  florian: The piece fantasai quoted needs to also clarify that it also
           applies to `::first-letter`.

  Rossen: Ok, now that we're on the same page, is there anything else?
  tantek: So the example that dauwhe mentions, it is an ordered list,
          so I was trying to make it work with the markers with
          <ol type=a>, but I could make that to work cross-browser at
          all, so if anyone is trying to define those interactions you
          should experiment with that today
  tantek: I had to use with `list-style: none`
  fantasai: There's only one `initial-letter` impl so far and it's
            pretty buggy
  dauwhe: That's an understatement, but I'm still glad it's there
  Rossen: fantasai, so should we resolve then?
  Rossen: Any objections?

  RESOLVED: initial-letter applies to inside markers + clarify spec
            on :first-letter interaction with markers

initial-letter vs float
=======================
  github: https://github.com/w3c/csswg-drafts/issues/688

  fantasai: So there's an issue of the interaction between `float` and
            `initial-letter`
  fantasai: `float` blockifies an element, and `initial-letter` applies
            to inline boxes only, so per spec right now, there's no
            interaction: you get a floated block.

  fantasai: It was pointed out that you may want to use float as a
            fallback for initial-letter
  fantasai: so we may want to ignore `float` if `initial-letter` is
            specified as well
  dbaron: florian: We should make initial-letter override float
  heycam: You could use @supports
  tantek: That's not enough because when you're actually trying to make
          it work you tweak other properties like font-size but also
          line-height
  fantasai: font-size and line-height are ignored already
  tantek: You also need margin
  fantasai: That's not ignored
  dauwhe: Yeah, tantek is right
  <tantek> from view-source:http://tantek.com/2015/224/b1/alphabet-indieweb
  <tantek> .h-entry li::first-letter
           { float:left; margin:0.04em 1px 0 0; font-size:5.5em;
           text-transform:uppercase; line-height:0.8; }
  florian: So margin is not covered but I think the compromise is
           reasonable if you're not trying to do pixel-perfect drop-cap
           both with and without first-letter
  florian: You'd just not do the margin

  Rossen: Let's get back to the issue at hand
  Rossen: So tantek, you are against overriding float? or just saying
          that there's a bunch more?
  tantek: Not a lot, but just a few properties beyond float
  florian: So for two of the three properties you want to cover it's
           fine already, for the rest you have @supports
  florian: because the margin hack you may do I think it's still useful
           for initial-letter to override floats
  tantek: I don't think you can make the initial-letter look good
          without margin

  fantasai: So you're arguing we shouldn't make the change?
  fantasai: [re-states the proposal]
  fantasai: The current state is that computed value rules for
            'display' cause a element with 'display: inline' with
            'float' not 'none' to turn into 'display: block'.
  fantasai: The proposal afaict is that if 'initial-letter' and 'float'
            are set on a 'display: inline' element, it won't compute
            its 'display' to 'block'. Thus 'initial-letter' would apply
            and 'float' wouldn't.
  emilio: So you'd make an inline with `float: !none`?
  emilio: We want initial-letter to turn float to none, instead.

Scribe: frremy

  emilio: Can we determine if initial-letter applies based on the box
          type only?
  emilio: I think we should make the rule as dumb as possible
  emilio: Even if this is a block, initial-letter turns off float

  TabAtkins: I agree, we should recommend authors use @supports
  tantek: A simpler rule would also make it clear to authors they
          should use @supports
  TabAtkins: We could add a note to the spec
  dbaron: And it's also very likely people will not use initial-letters
          on things where it should not apply
  Rossen: I believe this (?) should be the same rule

  dbaron: I advocated for fixup before
  dbaron: I am fine with no fixup in place
  dbaron: but then I argue for a note that says that if you set float,
          then initial-letter won't apply
  tantek: Simple fixup that forces float to none helps authors to debug
          using devtools
  emilio: Even now the display fixup order is not fully interoperable
  emilio: so I'd prefer no fixup to not muddle fix further
  Rossen: No fixup is better for implementers, I agree
  * tantek would also slightly prefer no fix-up, can live with simple
           fix-up that is reflected in the value for the property shown
           in devtools so that it is more easily debugged by authors

  dauwhe: I don't have a strong opinion, but it would be nice to have
          an example in the spec to make things clear
  Rossen: The only good reasoning for fixup was be compatible with
          existing code, but now we have @supports so authors should
          just that

  Rossen: So, any objection to resolve as "won't fix" for now and
          add a note explaining what dbaron already mentioned above?
  RESOLVED: Resolve as "won't fix" (no fixup) and add a note explaining
            what dbaron already mentioned above

  tantek: Note?
  astearns: Yes, because the confusion dbaron was worried about was
            for implementers
  dbaron: Yes, note is fine

Properties that apply to initial-letter
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2700

  <fantasai> See
https://drafts.csswg.org/css-inline-3/#initial-letter-properties
  <fantasai> “All properties that apply to an inline box also apply
              to an initial-letter (unless it is an atomic inline,
              in which case the set of properties that apply to an
              atomic inline apply) except for vertical-align and its
              sub-properties, font-size, and line-height.”
  <fantasai> for reference, the old section:
             https://www.w3.org/TR/2016/WD-css-inline-3-20160524/#initial-letter-properties
  fantasai: Before was a whitelist, current spec text is more general
  fantasai: All inline props except vertical-align, font-size and
            line-height
  dbaron: So this includes margin/padding/border?
  fantasai: Yes
  dauwhe: Yes
  florian: So we are just resolving to approve the edit?
  fantasai: Yes
  <tantek> is outline in that list?

  TabAtkins: Our only objection is that this is one more list to
             maintain
  TabAtkins: and we already keep forgetting to do this for first-letter
             and first-line
  TabAtkins: Problem happens whether you blacklist or whitelist
  TabAtkins: but the failure mode and the fixed mode of starting from
             an allow list is better
  fantasai: We came to the opposite conclusion because most things
            should apply
  fantasai: We don't expect many new exceptions
  fantasai: but we expect most properties that apply to inlines to be
            useful

  dauwhe: The blacklist is useful because it is short and enables to
          grasp the scope of the feature
  florian: Would like a note that explains the principle, so that new
           properties would be able to be categorized by this rule even
           if we forget to add them
  fantasai: But they wouldn't be able to apply because the algorithms
            don't take them in consideration
  florian: That was just a proposal, but I'm fine as-is

  Rossen: So, can we resolve on the blacklist with three properties
          then?
  TabAtkins: No objection
  dbaron: Sizing properties apply too?
  fantasai: This is the next issue
  dbaron: Ok

  RESOLVED: Approve the edit

  <dbaron> :first-letter is at least 22 years old:
           https://www.w3.org/TR/WD-css1-960220.html

applying width/height to initial-letter
---------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/863
  <fantasai> https://github.com/w3c/csswg-drafts/commit/4893b213ff17a4c8deab181c6997b47b93972911

  fantasai: Request from tantek
  fantasai: seemed reasonable
  fantasai: We would like the group to review the proposal
  <fantasai> https://drafts.csswg.org/css-inline-3/#initial-letter-model
2nd bullet

  dbaron: In case of alignment, what gets aligned into what?
  TabAtkins: The letter aligned inside the box
  dbaron: The alignment properties are not specified to apply?
  fantasai: Well, we use them in the algo, we just forgot to mention it
  fantasai: We can fix this
  dbaron: Why is that useful?
  TabAtkins: It's super useful for width

  dbaron: Seems true, but for height this is more concerning
  dbaron: because now you have to align with the lines and take the
          height into consideration
  <dauwhe> using width and text-align with initial-letter
           https://usercontent.irccloud-cdn.com/file/G7EqH0Jd/tantek.png
  fantasai: You create a box around the glyph
  fantasai: From there, they are locked, and there are two ways to
            align this box
  fantasai: The exclusion however always use the glyph bounding box
  dbaron: Globally, this seems reasonable
  dbaron: It's more complex than the last time I looked, but this still
          looks fine
  fantasai: There was already an similar feature before
  fantasai: (explains why you needed to do this in the past)

  koji: Two days ago, we said the exclusion space is created only for
        the second line
  koji: so if you say margin-top: 30px, how does that work?
  fantasai: It pushes the entire block, including the initial-letter
  fantasai: The first line is positioned with the glyph
  fantasai: Details for how that would work is another issue, which we
            will address later, let's not discuss this now
  fantasai: but since the initial-letter and the first line are locked,
            the initial-letter will never sunk further than the first
            line
  <dauwhe> some discussion:
https://drafts.csswg.org/css-inline/#raised-sunken-caps
  Rossen: So unlike other inline, the initial-letter's margin has an
          effect on layout
  koji: Does that margin collapse?
  fantasai: waaaiiiiiiiiiiiiiiiiiiiiiiiit :)
  fantasai: Let's not discuss this today
  fantasai: Let's push this to TPAC

  Rossen: Ok, so were are we towards getting a resolution
  fantasai: Review and accept the edit allowing width/height/alignment
  dauwhe: And we do have good use cases for this stuff
  Rossen: Any objection?
  (no objection)

  RESOLVED: Accept sizing properties for initial-letter

box tree nesting vs initial-letter
----------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2184#issuecomment-391832514

  fantasai: We didn't define very clearly what we defined as
            "the first inline"
  fantasai: so, it's slightly weird, because adding spans should
            not change result most of the times
  fantasai: but in this specific case, if they are nested, it's
            not clear which one to take
  <dauwhe> https://github.com/w3c/csswg-drafts/commit/412bfeabf53c980babe9845c3a2684904790c2e2
  fantasai: (looking at notes and issues)
  <fantasai> “Specifically, initial-letter also applies to any
              inline-level box that is the first child of its
              parent box and whose ancestors (if any) that are
              descendants of its containing block are all
              first-child inline boxes that have a computed
              initial-letter value of normal.”
  fantasai: (reads pasted in text)

  florian: If you have multiple spans, the outer one does have
           a border, but the nested one has initial-letter
  florian: does the border wraps around the "nested" initial-letter?
  Rossen: I would assume not
  florian: So it becomes out of flow, kinda?
  Rossen: Yes
  florian: There are two options (1) you take the nested span out
            of flow (2) or we can refuse to initial-letter any
            nested span inside something that has a margin, border,
            or padding
  Rossen: The second options is though from the styling point of view
  florian: ok, then let's do 1

  PROPOSED: The initial-letter will be the first inline that has
            initial-letter not set to normal, (+details in the spec)
  Rossen: Any objection?
  RESOLVED: The initial-letter will be the first inline that has
            initial-letter not set to normal, (+details in the spec)

  <dauwhe> see https://github.com/w3c/csswg-drafts/issues/743
  PROPOSED: initial-letter will behave as if was taken outside of
            its inline ancestors
  PROPOSED: The initial-letters will behave as if was taken/rendered
            outside of its inline ancestors

  RESOLVED: The initial-letters will behave as if was taken/rendered
            outside of its inline ancestors
Received on Tuesday, 24 July 2018 23:52:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:11 UTC