- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 12 Nov 2018 19:21:34 -0500
- 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