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

[CSSWG] Minutes Lyon F2F 2018-10-22 Part I: Accessibility, CSS Fragmentation, CSS Box Model [Accessibility] [css-display] [css-break] [css-align]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 12 Nov 2018 19:21:34 -0500
Message-ID: <CADhPm3thNRbcyiFLtuEiuCid-LbDWpyiNwnEApvfhPf=cQ+yuQ@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.
=========================================


Accessibility
-------------

  - Issue #2355 (Is the 'display' value supposed to affect the
      semantics exposed to screen readers?) brought up a broader need
      to map between the accessibility tree and CSS.
  - The accessibility tree seemed to vary by browser so there was some
      interest in that getting a more standardized definition.
  - The CSS AAM needs more volunteers to help ensure that there are
      not accessibility issues going forward. CSS AAM page:
      https://www.w3.org/WAI/APA/task-forces/css-a11y/

CSS Fragmentation
-----------------

  - RESOLVED: Add margin-break to break L4 (Issue #253)
  - RESOLVED: margin-break controls not just margins at fragmentation
              breaks, but also at the beginning and end of the
              fragmentation chain

CSS Box Model
-------------

  - RESOLVED: Add the margin-trim property with values [ none |
              in-flow | all ] to css-box-3 (Issue #3068)

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

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

Present:
  Rachel Andrew, Invited Expert
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Emil A Eklund, Google
  Elika Etemad, Invited Expert
  Javier Fernandez, Igalia
  Simon Fraser, Apple
  Daniel Glazman, Privowny
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation
  Ian Kilpatrick, Google
  Vladimir Levantovsky, Monotype
  Vladimir Levn, Google
  Rune Lillesveen Google
  Myles C. Maxfield, Apple
  Cameron McCormack, Mozilla
  Manuel Rego, Igalia
  François REMY, Microsoft
  Melanie Richards, Microsoft
  Florian Rivoal, Invited Expert
  Dominik Röttsches, Google
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Dirk Schulze, Adobe
  Jen Simmons, Mozilla
  Markus Stange, Mozilla
  Surma, Google
  Alan Stearns, Adobe
  Philip Walton, Google
  Greg Whitworth, Microsoft
  Eric Willigers, Google

Scribe: gregwhitworth


Accessibility
=============

Accessibility API Mappings
--------------------------
  Link: https://w3c.github.io/html-aam/

  <rachelandrew> description of display: contents issue here

https://hiddedevries.nl/en/blog/2018-04-21-more-accessible-markup-with-display-contents
  aboxhall: This topic is due to a bug from display: contents
  aboxhall: The issue is that nodes with display: contents don't get a
            css box but the a11y tree is based on the layout tree
  aboxhall: Everyone expected that this will just work but that isn't
            the case

  aboxhall: TabAtkins asked me to explain the a11y tree
  aboxhall: Who here is a bit confused about the a11y tree?
  aboxhall: When we say the a11y tree, it is not completely specified
            but there is an HTML-AAM spec but the tree is not
            specifically specified
  aboxhall: It is a tree of semantic nodes that are exposed to screen
            readers and other ATs
  aboxhall: You'll need to know the role, the label and the other
            properties that are necessary to provide the user the
            relevant context for the element they're actively on
  aboxhall: What we do is map, indirectly from the DOM tree to this
            tree

  emilio: In Mozilla we hang it off the frame tree which is similar,
          but it allows us to gather everything from shadow and
          display contents, not quite clear to him what edge cases
          exist
  emilio: It would be good if we can come up with a model that also
          works with shadow DOM

  Rossen: For Edge, it's slightly different
  Rossen: This tree that we're all referring to is actually ill
          defined, which I believe was aboxhall's point
  Rossen: We base it off the DOM tree and use the box tree only where
          necessary - they're not tightly related
  Rossen: I can see why display: contents would be an issue

  <Chris_Lilley> hearing that the accessibility tree is vaguely
                 defined is concerning. Is that because no-one could
                 agree on a tighter specification?
  florian: It seems the Edge scenario is closer to the intent as DOM
           traversal is what is what should be kept

  futhark: When you say DOM tree, do you mean flat tree?
  aboxhall: To me it makes the most sense to base it off of the flat
            tree
  aboxhall: It does mean that we do need a normative tree, if you are
            working on something that touches the accessibility tree
            to please discuss it with us
  aboxhall: It doesn't just impact the a11y tree but it impacts focus
            - people have assumptions with how it should work

  florian: I do think we do need a normative spec
  florian: but we should avoid notes in the spec
  florian: It makes an assumption and that is what is incorrect
  TabAtkins: It covers it if it's not based on the box tree
  TabAtkins: It has no normative meaning - it's just a note
  florian: Basically the problem comes down to no normative spec for
           the tree

  jensimmons: Are Google and Safari going to be able to fix this issue?
  aboxhall: Well, I'm working on it - for the past month
  aboxhall: We're going to base it off of the flat tree

  gregwhitworth: Is there a proposed solution?
  aboxhall: I don't have one right now
  aboxhall: If there are people that want to work on a normative spec
            for the a11y tree - maybe it's a good discussion for the
            plenary day with OS, Browser Vendors and ATs

  Rossen: I would be very supportive of this
  Rossen: regardless of where the work happens
  Rossen: I want to use this as an opportunity to blend the CSS AAM
          task force going forward?
  Rossen: because we want to avoid these types of issues
  Rossen: I for one, am going to acknowledge that this isn't as good
          as it should have been and there are too many assumptions
          that were made
  Rossen: The root cause needs to be addressed, let's not try to solve
          it here. You're on point that we need to be more diligent on
          getting ahead of this issue
  TabAtkins: I like the idea of getting a plenary day session for this
             - if you have the technical acumen for this topic

  aboxhall: I want to pick up on things - I think you're referring to
            the computed tree AOM
  aboxhall: We have the notion of a programmatic spec for the computed
            value, and in order to do that we need to have an idea of
            the tree, so synchronizes those efforts
  florian: I think we all intended for that specific feature the node
           should still exist in the tree

  <jensimmons> what’s that issue number?
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/2355

  fremy: The text in the spec states that it should only be impacting
         visual layout
  fremy: It is more clear to me, so that should mean that this
         shouldn't impact the a11y tree
  aboxhall: It is a bit of a tangent but that means it wouldn't affect
            focus as well
  fantasai: That's covered in the spec as well
  florian: For that case, it is a bug then
  TabAtkins: We need to get the right technical answer to resolve this

  Rossen: I want to get back to - do we need to amend the display:
          contents spec in any way?
  Rossen: Are you looking for any particular change to the current
          spec?
  <Rossen> https://www.w3.org/WAI/APA/task-forces/css-a11y/
  aboxhall: I can't answer that right now, I'll need to look at the
            orange box that people are talking about - I'll take that
            offline
  <fantasai> aboxhall,
https://www.w3.org/TR/css-display-3/#the-display-properties
  <fantasai> “The display property has no effect on an element’s
             semantics: these are defined by the document language and
             are not affected by CSS. Aside from the none value, which
             also affects the aural/speech output [CSS-SPEECH-1] and
             interactivity of an element and its descendants, the
             display property only affects visual layout: its purpose
             is to allow designers freedom to change the layout
             behavior of an element without affecting the underlying
             document semantics.”

  <Chris_Lilley> aboxhall, the text is in <div class="advisement">
                 which happens to be styled orange
  <aboxhall> In what spec, could you link? @chris_lilley
  <Chris_Lilley> the one fantasai linked to
  <Chris_Lilley> https://www.w3.org/TR/css-display-3/#the-display-properties
  <aboxhall> @chris_lilley thanks!

  futhark: Do we need to take into account anonymous table boxes for
           example
  Rossen: That was why we brought up the CSS AAM which is to deal with
          that situation specifically
  Rossen: table fixup, deals with that situation specifically
  Rossen: I want to draw attention and try to this task force and
          request help
  Rossen: This is a great issue that we should look into
  Rossen: Now that we have the issues in there we need to work on them
  TabAtkins: It feels like one of the display editors should be in that
  fantasai: I'm not volunteering to edit in any other specs
  rachelandrew: I'm interested
  <astearns> https://www.w3.org/WAI/APA/task-forces/css-a11y/
  Rossen: To avoid yays or nays, if you're interested - go get signed
          up - the link is in IRC [above]
  Rossen: Go ahead and +1 if you're interested in IRC
  <rachelandrew> +1 would be interested in being part of the a11y TF
  * emilio is interested on the topic, though not sure how much time
           I'd be able to commit
  <astearns> emilio I'd suggest signing up to at least read through
             updates and issues as they arise

  Rossen: Having said that, aboxhall is there anything else you'd like
          to talk about?
  aboxhall: I agree with TabAtkins to see the display editors, it
            would be nice to see things not ship until a11y issues are
            resolved
  Rossen: How things have occurred - fantasai was on all of the calls
          that we had, flex ordering for example
  Rossen: This lead to definitive text in the spec but is flexible
          that allows people to innovate
  Rossen: What I'm trying to say, is that these issues aren't lost on
          us and aren't an after thought - we can always do better
          though

CSS Fragmentation
=================

Control space before element depending on page position
-------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/253

  fantasai: The suggestion was to add a margin break property which
            controls how margin behaves at page breaks
  fantasai: If you have to start a new fragmentation then the margin
            after it is preserved, for example a new margin heading
  fantasai: If you're at an unforced break then it isn't preserved -
            this makes sense because margins are there to create space
            between things
  fantasai: So this would allow you to keep or discard
  fantasai: auto, keep, discard are proposed keywords in fragmentation
            L4
  fantasai: This would be the only feature in that level

  florian: This property exists in the antenna house formatter
  <florian> https://www.antennahouse.com/product/ahf60/docs/ahf-ext.html#axf.margin-break

  Rossen: Is there any discrepancy on the type (columns, page, etc)
  fantasai: No they all behave the same

  jensimmons: I believe this fixes one of the things that bugs me with
              multicolumn
  fantasai: We would have to be clear that it would occur with the
            different fragmentainers
  fantasai: There are different set of issues that are dealing with
            margins that aren't fragmented
  <jensimmons> rachelandrew: what’s the number of that bug?
  <rachelandrew> 1939

  TabAtkins: Would this apply to general BFC?
  fantasai: No
  TabAtkins: To me that sounds like the thing that Jen just asked for
  <jensimmons> This is the bug we need fixed.
https://github.com/w3c/csswg-drafts/issues/1939
  fantasai: We need to determine if it works with the first
            fragmentainer or not
  gregwhitworth: And it's the same 1:1 scenario?
  florian: Yes
  TabAtkins: I'm curious why they only allow an optional 'keep' for
             after margin
  fantasai: Because the only option is keeping it because currently
            it's always truncated
  <emilio> So, is `auto keep` a valid value? That sounds wrong

  Rossen: This property, if we bring it forward to fragmentation 4...
  fantasai: We could also put it in css-box-3 or 4, etc
  fantasai: There's little requested for Fragmentation L4, this is
            currently the only thing

  Rossen: Any other opinions about margin-break?
  emilio: Does it allow the auto keep value to be correct, because
          that's kind of weird
  florian: I recommend we open an issue on that
  emilio: Sure

  jensimmons: I don't want to bikeshed the name, but is margin-break
              the right name?
  fantasai: We have box-decoration-break as well so this carries
            that pattern forward
  <TabAtkins> AH behavior:
https://github.com/w3c/csswg-drafts/issues/253#issuecomment-229367559

  iank: This only applies to forced breaks?
  fantasai: This is expected to work on anything that has a margin
            adjoining a break
  Rossen: ok, I'm hearing people are in favor for break L4
  <TabAtkins> auto=discard on unforced breaks, keep on forced or
              start-of-container; discard=discard on all breaks;
              keep=keep on all breaks
  <TabAtkins> end-side break is always discard right now, regardless
              of break type; option to specify "keep" for those too.

  Rossen: People can open issues against the proposal
  Rossen: Objections?

  RESOLVED: Add margin-break to break L4

<br dur=20min>

CSS Box Model
=============
Scribe: heycam

Gap properties for block layout
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3068
      and https://github.com/w3c/csswg-drafts/issues/2848

  fantasai: Basically the request from authors is to get rid of the
            child margins at the very top and bottom of an element
  fantasai: so top before the first element, and bottom of the last
            element
  fantasai: Suggestion in one is to have a different box-sizing value
            of some kind
  fantasai: Other suggestion was to reuse gaps to do this, adding gaps
            to block layout

  fantasai: I don't think I want to add gaps to block layout
  fantasai: Margin collapsing is its own special thing, fairly
            complicated
  fantasai: but we can solve the problem by having a property that
            gets rid of the margins at the interior edges of a
            container
  fantasai: I think tables do this automatically in quirks mode
  fantasai: So the proposal is to add a property that would do this,
            and have an on/off switch, or do it for all items, or only
            in flow items, or something
  fantasai: I want to see what people think about this, and whether to
            add it to the css-box-3 spec

  TabAtkins: We already have a use case for it in css specs themselves
  TabAtkins: notes, examples, etc. have a :first-child { margin-top:
             0 } rule, which works unless you start the element with
             raw text, followed by a block-level element, which then
             loses its margin because it's the first element even
             though it's not the first content
  TabAtkins: so the necessity of making this actually robust seems
             fairly clear to me
  <fantasai> https://github.com/w3c/csswg-drafts/issues/3068#issuecomment-417486499
  fantasai: there's a rough proposal in this comment ^
  <fantasai> margin-trim: none | in-flow | all
  fantasai: Up for suggestions, bikeshedding, etc., but that's the
            starting point proposal

  florian: That would work on elements that establish a BFC?
  fantasai: Yes, also reasonable to do on flex containers
  TabAtkins: Does it work on blocks that don't establish a BFC?
  fantasai: Yes

  iank_: Is this the same thing as the -webkit-margin-collapse?
  TabAtkins: I don't know what those are
  fantasai: It doesn't control collapsing, it switches to discarding
  TabAtkins: Might just be a terminology issue
  TabAtkins: I don't know what those properties do
  iank_: I believe one of the values nukes the whole margin collapsing
         result
  iank_: and just makes it go to 0
  fantasai: This is different in that it keeps the margin of the
            element itself, but it kills the margin of its first child
  TabAtkins: The reason why this is important, rather than putting
             prop on first child, is when the first child is a text
             node
  TabAtkins: If there's an element right after that you want to keep
             the margin
  TabAtkins: either that or have the ability to target text node,
             which I would rather avoid
  iank_: Is there an example of that in an issue somewhere?
  TabAtkins: I'll find one
  <smfr> -webkit-margin-collapse was added via
         https://trac.webkit.org/changeset/7362/ in 2004
  florian: Also, if you select the first child with a selector, it
           might be 'display: none', so it would do the wrong thing

  eae: Sounds like a good idea
  eae: Would like to see an example
  <fantasai> Example:
             <div>
                 some text
                 <p>more text</p>
             </div>
             <div>
                 <p>some text</p>
                 <p>more text</p>
             </div>
  fantasai: In this example, in either case, you don't want margins at
            the top and bottom of the the div
  fantasai: You just want the margin to go away because you've
            specified how much space you want between the <div> border
            which is visible, and the text which is also visible, as
            'padding'
  fantasai: If you were trying to rely on the :first-child selector,
            you could not do this correctly
  fantasai: since it would select the <p>
  fantasai: which is after some amount of text
  fantasai: This is the example Tab pulled from the specs
  TabAtkins: It ends up failing rarely in our specs, since it relies on
             the first text child not having links in it, which is rare

  Rossen: What spec is this going in?
  fantasai: I would suggest css-box-3, which has no new features right
            now
  fantasai: it's just what's in CSS 2 with updated terminology
  <fantasai> https://www.w3.org/TR/css-box-3/
  TabAtkins: I agree
  Rossen: Would margin-break go there too?
  fantasai: There, or Fragmentation Level 4
  fantasai: which is where box-decoration-break is
  fantasai: Should cross reference from here for sure
  Rossen: Proposal is to add margin-trim with the values as above

  TabAtkins: Does the 'all' value affect all floats touching the start
             edge of the container?
  TabAtkins: want to make sure that's a reasonable thing to do
  iank_: I'll have to check
  Rossen: Should be straightforward
  Rossen: You're positioning your floats in the beginning of your
          container, and at that time you can decide to trim the margin
  Rossen: You're not going to affect anything below you at this point
  Rossen: The thing that will be a bit iffy is when you start pushing
          margins to the next line
  Rossen: Want to make sure you're not losing the margins, but these
          are impl details

  fremy: Does the all value also affect the margin at the bottom of a
         float?
  fremy: That seems more problematic
  fremy: You don't know when you place the float if you're going to be
         at the bottom of the element
  fantasai: If you get to the bottom and the float is what it's
            causing it to be taller, you can back up to the border edge
  fantasai: but you're right that is a trickier situation than the top
  florian: If the margin of the float is pushing the bottom edge, and
           you can just remove it by changing the rest of the layout,
           it's fine
  florian: but if removing it entirely, some lines could intrude where
           they couldn't before
  florian: Trim only the amount of the margin that is extending

  iank_: Does this eat just the first and last margin of the first
         element? or eat the whole collapsing margin?
  fantasai: The whole collapsed margin
  florian: The element, its first child, etc., as long as they're
           collapsing
  Rossen: Just to be sure, when we talk about the first float, we're
          talking about floats that are at the beginning? two or many
          adjacent?
  florian: Yes because your goal is to get visual alignment
  Rossen: Just want to be explicit since we keep talking about "the
          first"
  Rossen: but with float you can have many
  TabAtkins: All margins touching the start edge

  RESOLVED: Add the margin-trim property with values [ none | in-flow
            | all ] to css-box-3

  <TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6305
              ^an example of the "zero out the margins of first/last
              child" strategy giving bad results
  <TabAtkins> iank_ ^^^

CSS Fragmentation (cont.)
=========================

  florian: Now that we have this and the thing we resolved on before
           the break, discarding margins around fragment breaks, if we
           go back to Jen's use case
  florian: The first paragraph of first multicol column, we can
           address it with the thing we just created
  florian: Maybe we should also address it with the margin-break thing
           we were discussing
  fantasai: I think I would lean towards having both of those
            properties controlling this particular break

  florian: In the fragmentation context, you probably want the same
           behavior after the first forced break, and at the beginning
  florian: because there's no desire for the second chapter to look
           different from the first chapter
  florian: The summary is that margin-break:discard, the value that
           causes the margin to be discarded causes it to be discarded
           not only after breaks, but also at the beginning of the
           first fragmentainer
  florian: when you explicitly opt in to discarding things, not only
           discard around breaks, but also at the start
  florian: effectively you count the start as a forced break
  <jensimmons> and at the end?

  fantasai: Proposed resolution is that margin-break controls not just
            margins at fragmentation breaks, but also at the beginning
            and end of the fragmentation chain
  Rossen: And this will be an additional requirement on margin-break?
  fantasai: Yes
  Rossen: And this also applies at the end, not just the start.

  RESOLVED: margin-break controls not just margins at fragmentation
            breaks, but also at the beginning and end of the
            fragmentation chain

  <gregwhitworth> florian & fantasai: is there a reason that we NEED
                  two separate properties that are doing the same
                  thing, just in two different contexts?
  <fantasai> gregwhitworth, yes, you want to control behavior at
             breaks and behavior of a container separately
  <fantasai> gregwhitworth, also one applies to the element's own
             margins and one applies to its contents :)
  <gregwhitworth> fantasai: we should chat during a break
  <fantasai> kk :)
Received on Tuesday, 13 November 2018 00:22:27 UTC

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