- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 29 May 2018 16:02:48 -0400
- To: "www-style@w3.org" <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 Tables
----------
- RESOLVED: rename “table box” to “table grid box” (Issue #2501)
Text L3
-------
- RESOLVED: Spaces don't hang when break-spaces is specified (Issue
#2465)
CSS Cascade
-----------
- RESOLVED: Define property/value aliasing in CSS Cascade as an
operation on par with case-mapping the identifier.
This affects parsing CSS files, OM arguments, and
.style.propertyName, etc. (Issue #866)
- RESOLVED: We create a new legacy shorthand concept in Cascade L4
for properties which need both aliasing and value mapping;
these are like regular shorthands except are never serialized.
(Issue #866)
- RESOLVED: Everything that's currently defined as an alias needs to
use new alias definition or become a legacy shorthand.
(Issue #866)
Overflow 3
----------
- When discussing Issue #129 (padding-bottom in overflow content)
the group originally thought they could solve the bigger author
pain point (block-end padding) in isolation. However, as
conversation continued it became clear that an entire model that
covered inline padding and the relationship to absolutely
positioned elements was required to address this issue.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
CSS Tables
==========
table box naming
----------------
github: https://github.com/w3c/csswg-drafts/issues/2501
fantasai: Proposal. fremy was complaining about confusion between the
two. At some point the suggesting of table grid box came
up. So request is rename table box to table grid box.
astearns: Obj?
RESOLVED: rename table box to table grid box
Text L3
=======
Audit details of break-spaces value against use cases
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2465
astearns: These are things we're rounding back to.
astearns: This issue needs to be address to unblock something
flackr: Igalia is about to impl and needs this closed.
fantasai: There's several slight details. This is about
break-spaces. Goal is on some property is there's a mode
for editing when you're typing a space it behaves
more predictably for the user.
fantasai: We want caret to move forward, spaces to not overflow (as
long as containing block is more than 1ch wide),
so spaces don't hang.
fantasai: There's currently a break-spaces value on overflow-wrap,
but right now spaces are defined as can hang at end of
line.
fantasai: There's side effects of this. When you have a word at the
end of the line and it fits but the space doesn't, even
though you're breaking spaces it doesn't move to next line
but it does overflow. If you want things to wrap it's a
problem this space overflows.
fantasai: Related issue is that when you're trying to define
intrinsic size of this box if the space is hanging it's
not measured but if you want it visible you want to count
it.
fantasai: Seems to me if we want the space to behave like a normal
visible character, it should also affect size and not be
hanging.
fantasai: This means if the word fits and you type a space if the
word fits it will wrap, and we measure the space when
measuring intrinsic size
fremy: We fixed an issue in Edge when people expect contenteditable
not to wrap at same places because they use it for
underlines. They use it as a rendering of the text.
florian: So rendering should be same either way even if the reason
is because when it's editable you wouldn't want anything
else.
florian: We're not proposing a difference based on editability,
we're proposing both modes are same. But when you're in
editing the new behavior is sane, not almost sane.
fremy: We did the reverse.
fremy: We made it so that when layout not taking space
fantasai: fremy's fix where you made them match that's good and if
they want spaces to show and say break-spaces the spaces
take up space.
florian: But why align editable and not to not take space.
fremy: Most content web is spaces not so we changed to that case.
florian: It's hanging but it's there.
fantasai: Edge behavior is in the spec now as most recommended as I
recall, for the default behavior.
fantasai: Change is that spaces don't hang when 'break-spaces' is
specified.
florian: Rest is consequences of that.
fremy: Sounds good.
astearns: Obj to Spaces don't hang when break-spaces is specified?
RESOLVED: Spaces don't hang when break-spaces is specified
CSS Cascade
===========
Aliasing mechanism
------------------
github: https://github.com/w3c/csswg-drafts/issues/866
fantasai: Couple places in text with an alias like overflow-wrap and
word-wrap and the way they're aliased in the spec is not
how they're implemented.
fantasai: Previously resolved that when we do alias we treat as
shorthand of other properties. Mozilla has different
mechanism. If we're changing I need a resolution on what
to change to.
florian: I think it's not just Mozilla. In general aliasing in a
browser doesn't work as a shorthand.
emilio: How to observe?
florian: By browser engineers complaining. What is the different
behavior?
emilio: [missed]
dbaron: One difference might be when serializing declaration you try
and serialize to a shorthand first and you don't want to do
that here.
dbaron: You want that for real shorthands
<fantasai> dbaron's comment on observable difference -
https://github.com/w3c/csswg-drafts/issues/866#issuecomment-271028230
emilio: But not aliases.
dbaron: Example if you have a declaration that says border:medium on
each direction we'll use border:medium. Same rule is that if
someone declared overflow-wrap:inherit we'd serialize to
word-wrap.
TabAtkins: CSSOM wording has preferred order where shorthands are
above longhands, but prefixed are below all of them.
fantasai: Trickier is page-break aliases. Those ones the page-break
which is old cannot express all the values of the longhand
which is where we're moving to
<fantasai> https://www.w3.org/TR/css-break-3/#page-break-properties
dbaron: There are also things that aren't supposed to work for
shorthands. We might have changed some of those things to
work.
emilio: Spec says generally that getPropertyValue works for
shorthand but in getComputedStyle only properties are actual
long hands but if there's properties for shorthands also
expose them there. getPropertyValue.font is supposed to work.
emilio: Both work in webkit and block, but getComputedStyle.font
isn't supposed to work per spec.
emilio: Edge and FF don't impl any shorthand in getComputedStyle
dbaron: We do some.
emilio: blink and webkit support both.
dbaron: Other question is what is the actual mechanism we use.
dbaron: In old style system at the point we converted a string to an
internal css property ID--where we also did lowercasing and
such--we also did the alias mapping. So every time you had an
input that's a string that was asking something about a
property we would convert it.
emilio: Now I think we preserve a bit longer to control aliases via
prefs. But not much longer. Once they're in the declaration
block.
fremy: We only have "realId"s that are HTML. If we have
-webkit-something and if the same as a prefix it's the same
thing.
astearns: I'm a bit confused. dbaron you started saying it's not
like a shorthand because when you serialize the property
turns into alias.
dbaron: The thing that's not the alias is turned longhand.
emilio: Supposed to serialize the short hand. If you have foo per
spec it should be -webkit-foo.
dbaron: If it's word-wrap and overflow-wrap it's supposed to switch.
TabAtkins: It's alphabetical.
emilio: One is long hand.
TabAtkins: Yes, if they're both shorthands.
florian: If word-wrap is defined to be a shorthand you'll serialize
to the thing that's supposed to be the shorthand
fremy: When you spec the alias it's the same thing.
astearns: Instead of defining alias as a shorthand we define alias
as a separate thing and define what browsers are doing.
myles: If you say .font does what you spoke about work? Would the
alias and the original exist there?
emilio: Yeah.
myles: It's not just turning strings into an ID. You also do this
other thing.
florian: What about properties that take values?
emilio: Same. Whenever you parse a property ID if you receive like
the alias you once you process it it's the same as if you
got the longhand
florian: If you serialize the transition-property property ...
florian: If you serialize the transition-property property which
takes property names you do not preserve the name.
dbaron: In old gecko we did not preserve it.
florian: And a shorthand you do preserve?
dbaron: Yes.
florian: That's one reason I pushed for shorthand originally.
dbaron: We could still spec the other way for alias
florian: Initial reason for shorthands was double. One we looked for
in page-break has a different set of values.
emilio: Parsing rules. That's what we used to have for
box-transform. We impl it as a shorthand and special cased
serialization.
florian: In general I think we can do the simple thing.
fremy: For the transition-property property we keep the ID as it is.
If you can't match to a property in the end it doesn't work
for us.
emilio: We preserve the ID... I agree it's not relevant.
fremy: We're not preserving it as a shorthand.
myles: So mechanism for alias is not shorthands.
florian: I'd like to resolve in general and separately for
page-break and friends.
emilio: Can't change parsing rules?
florian: No.
astearns: Seems to me like we could define what aliases are in
Cascade in general and when we have an alias that needs
mapping we define that in it's own spec.
fremy: Example some -webkit-flex properties are different.
florian: We define separately then? If values are the same we don't
do anything.
emilio: In FF we don't have any special case. I don't have context
for page-break but how is it supposed to work with
page-break:foo and then break:foo
florian: Let me pull spec up.
florian: page-break-before:always maps to break-before:page
[and break-before has additional values]
fremy: They're not aliases.
florian: If we define aliasing mechanism it won't work here.
emilio: Page break properties, how should they work with aliases?
florian: They're supposed to be shorthands.
emilio: Why are we covering?
myles: There are shorthands and aliases and they're different
dbaron: Page-break still needs to be a shorthand.
astearns: But that's not relevant
florian: They're defined as these are aliases and you do them as
shorthands. We have to change that
<fantasai> Another aliasing case is
https://www.w3.org/TR/css-writing-modes-3/#glyph-orientation
astearns: We have to change where we say alias in all our specs
myles: Where values aren't the same.
florian: We had resolved on they're the same.
myles: was a bad resolution.
emilio: What's expected to happen when you serialize
page-break-always? It's defined to map to break-before:page
What's expected serialization of page-break:always in
.style.pagebreak
emilio: Is it break-before:page? break-before:always?
fremy: It's not an alias. Alias is a webkit thing so it's an alias.
florian: Let's delete alias from that paragraph and leave the rest
as is. Let's define alias somewhere.
emilio: If we define this is a shorthand then break-before:left will
be page-break. It's weird because page-break is legacy
myles: Define in other direction?
fantasai: Can't because break-before has values that
page-break-before can't express.
emilio: Page maps to page
florian: Thing on the left are everything you have things on the
right are more values.
emilio: We can special case that.
fremy: Can have concept of legacy property that's serialized at the
bottom.
emilio: Then you have shorthands where you have to create special
cases.
fantasai: You'd have a list of properties where you're looking for a
shorthand and you never look at those.
fantasai: Right now when you try to serialize you have a list of
declarations and if it corresponds to a shorthand you
serialize as the shorthand. And we're saying when you
check, eliminate the legacy shorthands from the list.
astearns: Several things to resolve. First is we should define what
an alias is in CSS Cascade
astearns: Objections?
RESOLVED: We should define what an alias is in CSS Cascade.
astearns: In pure alias cases where we don't want shorthand behavior
we need to change to the definition written in the
previous resolution.
florian: Yes.
astearns: We will use this definition where it's appropriate.
RESOLVED: We will make the required edits for the definition
resolved previously.
astearns: Proposal: We create a new legacy shorthand concept in
Cascade L4 for those things that we have legacy shorthands
that should never be serialized
astearns: Or is this a type of shorthand.
emilio: There's a tricky thing because only place for this kind of
shorthand is when the new thing supersedes the old. Is there
a case where they don't map?
fantasai: glyph-orientation which takes a keyword and a degree and
those map to keywords in text-orientation.
emilio: Okay. That's fine as long as you can map.
astearns: That can be it's own section or subsection.
astearns: Objections?
RESOLVED: We create a new legacy shorthand concept in Cascade L4 for
those things that we have legacy shorthands that should
never be serialized
emilio: Then someone needs to edit.
fantasai: TabAtkins and I can.
florian: Do we need to resolve on a list?
emilio: If they have same syntax you're fine otherwise use legacy.
astearns: Let's do what we resolved and look at the fallout from
that. Better to have them take time and find places it
doesn't work.
florian: Principle stated is if they take same values it's alias
otherwise it's legacy.
emilio: They're different things.
astearns: florian is asking that we resolve to put thing in one
bucket or the other and if we find problems we bring that
to the group.
astearns: Proposal: everything that's currently defined as an alias
needs to use new legacy definition or is a legacy shorthand
RESOLVED: Everything that's currently defined as an alias needs to
use new legacy definition or is a legacy shorthand.
fantasai: If you're using aliasing mechanism what does that
mean...you'll always serialize as the new thing and we
don't have objects in OM rep that?
emilio: We do.
fantasai: We should spec that
myles: If you set the old object you should be able to read that
from the new object.
fantasai: So this also applies to .style.
emilio: Yes.
fantasai: Anywhere name is exposed. Okay.
fantasai: I think that's it.
fantasai: If you type in word-wrap:break-word and re-serialize that
you get overflow-wrap:break-word That's okay?
many: Yes.
Overflow 3
==========
padding-bottom in overflow content
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/129
fantasai: Issue was filed by frustrated devs where if they have an
element with overflow:scroll and it has padding and if the
content overflows, the padding is useless.
TabAtkins: I'm one of these web authors.
fantasai: Chrome includes that padding at the bottom. Request is
everyone matches Chrome.
emilio: On the spec issue there's a reference to an old Mozilla bug.
fantasai: I'm not sure spec is clear on what happens.
TabAtkins: Probably not wrong that Mozilla thinks it's spec
compliant, I just think it's wrong. Everyone does it a
little different.
TabAtkins: There's a difference between block overflow and inline
overflow.
fantasai: I don't think we can solve this all. And I think it'll be
undefined for a while. But biggest pain point is the
padding-bottom on the overflow container. Idea is to fix
that one in a way to make web authors happy.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5907
fantasai: Since Chrome has shipped for a while we can be sure it's
fairly compat. There's a test case ^ You can see Chrome
has padding at the bottom and FF has none.
TabAtkins: Use case: I am a blog post editor and I want the text
editor behavior where I can scroll the bottom text to a
reasonable region to read it.
fremy: Reasonable.
dbaron: Would be nice to spec something simple. Given there's
incompat there's a simple thing that can be close to what
current browsers do.
fantasai: My current proposal is to leave padding and margin undefined
ngeneral but say for padding you have to leave space at the
bottom.
astearns: You're asking for a targeted fix and dbaron wants a
general fix.
TabAtkins: Would it be bad to resolve this and then try and resolve
inline. It's a more complicated space.
dbaron: I'd like to resolve we intend to change inline even though
we don't know how to do it.
fantasai: It's possible for web compat we can't fix inline and even
if that's the case I think it's reasonable to try and fix
this. General usability of CSS we should make this work.
TabAtkins: When we nail down inline padding at least 2 browsers will
have to change.
dbaron: People care more about block because they scroll in that
direction more.
fantasai: And throwing in block axis overflow with scrolling is less
unexpected.
fantasai: I would like to include as much of margins and padding in
the overflow areas but we have the case of “will this
trigger scrollbars where it's not expected”.
fantasai: Since we don't have a web compat constraint with bottom
padding I think we should do that.
astearns: Prop: Require that you leave space in scroll containers
for block-end padding?
TabAtkins: Cool.
astearns: Add a note saying like to enforce for inline padding, but
not sure if we can for web compat.
fantasai: We'll file another issue on that.
astearns: Okay dbaron ?
<fantasai> testcase for inline-end padding
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
<fantasai> Looks like Chrome includes padding-inline-end
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
dbaron: I guess so.
dbaron: I think we used to do that and changed to compat with spec.
Spec is quite clear that's what you do. Nothing to imply you
should move padding.
myles: I talked to hyatt and he said he did it because it was
symmetrical and looked better.
myles: In webkit.
myles: I think webkit.
astearns: Objections?
fantasai: I'd be happy to resolve for inline too; just don't want to
hold up block-end.
myles: I think we should do both.
fantasai: Okay.
astearns: Resolve and then talk inline or block?
myles: no preference
astearns: Resolve for just block. Obj?
RESOLVED: Require that you leave space in scroll containers for
block-end padding in the scrollable area.
astearns: Do we also require space for inline padding because
consistency is nice.
fantasai: There's a test case above in IRC:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
emilio: Is that compat?
TabAtkins: Chrome puts padding on all the sides.
astearns: Same argument applies. If Chrome has been doing it for so
long. Can you see if there are bugs on extra unexpected
scrollbars?
myles: When would the scrollbars not appear?
<rune_>
https://bugs.chromium.org/p/chromium/issues/detail?id=724697&q=padding%20scrollable&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
rune_: Bug report ^
TabAtkins: It's a spec bug.
rune_: Yeah, it's not compat.
myles: Same argument applies.
astearns: And fremy agreed.
astearns: dbaron wanted consistency.
astearns: Objections to use same space saving for inline-padding?
koji: It's a block inline.
fantasai: Padding on scroll container itself. Everything else is undefined.
TabAtkins: From test case in bug, we do apply padding if it's inline content
that overflows, but not if it's a block causing the overflow.
If the block is inline overflowing no padding, but the text you do.
myles: Same as my comment.
TabAtkins: I didn't realize we did that as well.
astearns: Maintain that?
TabAtkins: No.
astearns: Worried if you don't?
fantasai: I have concerns about web compat but I won't block.
dbaron: Apply to content nested arbitrarily deep? You're propagating 2
versions to know if it's block or inline overflow?
myles: I think the answer is no, just children.
TabAtkins: No, it looks as far down as you want to know.
<fantasai> o_O
astearns: Proposal: Preserve space allocated by inline-end padding on the
scroll container.
fantasai: Dunno abspos.
myles: No browser does that. Scary.
TabAtkins: It's close to blink and chrome.
dbaron: Inlines you add the padding and blocks you don't?
myles: yes
TabAtkins: Presumably difficulty of reading text flush with edge was the reason.
dbaron: But then why not blocks?
TabAtkins: Blocks aren't text.
TabAtkins: Clarification. Inline content has to be a direct child.
myles: Toggle looks at just the children.
dbaron: Inline inside a block child you don't apply
dbaron: I think applying all the time is good, but I'd rather leave
as is then keeping the inline vs block.
astearns: You don't want the chrome/webkit current.
dbaron: Right.
fantasai: Clarification to previous resolution - doesn't apply to
abspos. Because that's what impl and it makes more sense.
abspos is positioned with respect to padding edge, so it
doesn't expect to have that extra space anyway.
myles: So it's abspos and you say padding:0 it's now underdefined.
fantasai: Previous resolution the padding is added to inflow
contents.
dbaron: Can you make inside of a scrollable area be abspos or only
outside?
fantasai: If I do absolute something and the scroll container is
relpos I can scroll.
dbaron: Per spec it should be relative to height without scroll but
I'm not sure that's what people implement.
dbaron: Adjusted by size of scrollbars if you have to adjust for
that.
fantasai: Bottom edge of the abspos position container does not
include the overflowing content. If the thing does
overflow then things are weird are drawn below that
boundary.
TabAtkins: In chrome assuming scroll container is abspos and is
right:0 bottom:0 the abspos is in the bottom right.
dbaron: Before you scroll.
dbaron: If it's causing the overflow do you scroll?
fantasai: You only add the padding to the inflow content.
<rego> check chromium behavior in:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5909
dbaron: But if a child of the scroll container is relpos but it has
children that are abspos do you scroll?
??: Do abspos children of relpos contribute to the overflow
characteristics of it's parent?
dbaron: That's how we impl.
TabAtkins: We do not add padding if the abspos is the overflowing.
dbaron: Now for abspos you need to track this deep.
fantasai: When you calc height of box and you scroll to the last
thing that's inflow and you add padding below that thing,
that's your direct child. There may be a deep nested thing,
but we're not looking at that.
dbaron: Gecko used to do that but that's different then what I think
we're saying. The other difference is if you have a scroll
container and has an explicit height container and that
overflows, do you add padding there.
fantasai: Don't think so.
fremy: Made a test case and it's worse then that.
<rego> this is the output of my example before:
https://i.imgur.com/PQZ775X.png (edge behaves like firefox
and webkit like chromium)
fantasai: As an author I don't expect an abspos to respect the
padding but I do expect things in-flow remain inside the
mat that's around it.
dbaron: You're changing the model. I thought model was you have
overflow, add padding around that, and then you overflow.
fantasai: Then we added abspos.
dbaron: But I think my model is simple. You figure out what the
scrollable overflow area of all descendants is and then you
add the padding and that's the area you add the scroll to.
dbaron: Abspos children are relative to the padding as if inside the
viewport and then those are placed in the scrollable area
which is probably on top of where it was before in the
viewport.
dbaron: This is what gecko impl and dev don't like.
myles: In this model some things are inside the viewport.
florian: I'm not disputing this may be nice, but doesn't that cause
overflow where you don't expect it? Spec I believe that
creating scrollbars too often is why chrome only does it in
some cases because it would make scrollbars everywhere
which people hate.
fantasai: dbaron problem with your model is I have a position
relative scroll container I put an abspos in the bottom
right in your model it triggers padding. If the padding is
2em then we add 2em padding and create all this scrolling.
dbaron: I buy that for abspos positioned relative to the scroll
container. I don't for things relative inside the scroll
container.
fantasai: Okay.
dbaron: Did we test that?
florian: Are you not worried that it would create lots of scrollbars?
dbaron: It's worrying. An actual proposal with details would be good
before resolve.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5910
fantasai: test case dbaron proposed ^
dbaron: You can't scroll to the thing at all
astearns: I'm worried you said this is what we used to do and dev
hated.
dbaron: It's because it's not what spec said to do and partly
because dev said it didn't yield expected but it does work
as expected in the other case where we were wrong.
astearns: We need to come up with a proposal for how to deal with
scroll container padding and then evaluate the full
proposal with spec text.
astearns: Amend previous resolution to say we will try to define a
way to make scroll padding work in block and inline for
all cases in a way that breaks the web.
fantasai: If previous is in-flow content I think we're scoped okay.
myles: Not if we're doing investigation. You're doing 1/4 of the
issue.
fantasai: But people want this 1/4 to work and it has web compat.
fremy: If we don't have a model that's clear we'll impl and then
re-impl.
myles: Agree it's wasted work.
astearns: I suggest that we draft the whole model and the portion
that's easy and see if it makes sense to do the easy part
first.
astearns: I think we need spec text first.
florian: Mostly sounds good to me. I thought in previous discussions
someone from blink stated that they're only extending
padding in some cases is because it's not web compat.
TabAtkins: It's not written anywhere to...and I don't remember it,
so I dunno.
<fremy> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5911
<fremy> ^ testcase with abspos in inline relative
fantasai: Some of these cases will be exploratory to figure out
what's web compat.
astearns: Proposal: Undo the previous resolution and continue to
figure out a whole model.
RESOLVED: Undo the previous resolution and continue to figure out a
whole model.
<br type="15min">
Received on Tuesday, 29 May 2018 20:03:43 UTC