- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 24 Jul 2018 19:52:43 -0400
- 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 Multi-Column Layout
-----------------------
- RESOLVED: Column boxes are BFCs
- RESOLVED: Second solution in the issue (spanners are BFCs that
collapse margins).
CSS Text Decoration
-------------------
- RESOLVED: ink-skipping is determined by the decoration originator,
not descendant elements (Issue #2817)
- RESOLVED: underline position is also determined by the decoration
originator, not descendant elements (Issue #2817)
- RESOLVED: underline offset is also determined by the decoration
originator (Issue #2817)
CSS Scrollbar Width
-------------------
- WG discussed feature for controlling scrollbar width.
Conclusion seemed to be to publish FPWD with auto | thin | <length>,
and a prominent warning that <length> was contentious and might be
dropped. FPWD resolution was deferred due to lack of time to discuss
scrollbar colors.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sydney-2018#schedule
Scribe: TabAtkins
CSS Multi-column Layout
=======================
github: https://github.com/w3c/csswg-drafts/issues/2582
florian: I don't remember exactly how I found this problem, but;...
florian: In example 25 of multicol, sentence says the margin between
adjacent spanners collapses together.
florian: I think everyone agrees with this, but it's only stated in
an example
florian: We *could* say that it's already explained by "multicol is
a BFC", but that doesn't explain why things have columns,
so...
<astearns> example 25 in https://drafts.csswg.org/css-multicol-1/#column-span
florian: [reads out from issue]
iank: Why do you want the margins to collapse together?
florian: Not sure I do, spec just says it and implies it's a
consequence already.
florian: Impls already do that
Rossen: This is an issue Håkon and I went back and forth with
Rossen: He argued it should behave as much as possible as block
layout when you have a single column
Rossen: I still disagree and think they shouldn't collapse
* fantasai agrees strongly with Håkon
astearns: [draws example with some spanners next to each other]
florian: Right now you can only span 1 or span all, so not possible
dbaron: I think I filed an issue with this earlier, but...
dbaron: If the columns themselves don't form BFCs, then floats don't
float to the column
florian: They definitely do
dbaron: I don't see that in the spec.
RESOLVED: Column boxes are BFCs
florian: So either the multicol is a "multicol formatting context"
that knows how to place columns and spanners, or we have
some concept of an anonymous box that wraps a column row...
fantasai: I think defining the entire model is a distraction, should
figure that out when we deal with < all spanners.
Let's focus on the issue.
astearns: So you propose we add text that column spanners collapse
margins between each other as if they were in block layout
astearns: Objections?
Rossen: As long as it's only between spanners
Rossen: Are spanners BFCs?
fantasai: Yes
Rossen: So let's collapse margins!
rachelandrew: We do that anyway to support spanners.
fantasai: Let's do a limited version of this. There's a box around
the column row. That box and the column spanners are laid
out as if they were block-level siblings in a block
container.
florian: Yeah, either that, multicol is a BFC laying out the row
boxes and spanners, or there's no row boxes and multicol
just magically knows how to position things.
florian: This might make it more difficult to introduce not-all
spanners.
dbaron: Already hard.
dbaron: Does anyone remember whether position: relative on an
ancestor of the column-span box that is a descendant of the
multicol moves the spanner?
dbaron: That might affect whether you have wrapper boxes around the
spanners.
<dbaron> Florian mentioned somewhere in there that the definition of
adjacency for column-span boxes isn't clear.
florian: And if we just want to reuse the margin-collapse def from
2.1, we may need to revisit the notion of adjacent.
fantasai: We do layout on the box tree, not the element tree.
TabAtkins: adjacency is box-tree, not element tree
dbaron: The rules for whether an empty column row is generated
might need to be made more specific, to give us good
results for adjacency.
dbaron: Like if there was an empty block between the two spanners,
does that create a column row that breaks adjacency?
fantasai and iank: yes
dbaron: Okay, needs to be made clear.
florian: Example - piece of text with two <em> elements following
each other. Both have a border. Both contain a div.
The div is column-span:all. There is a border between the
two divs, but they're taken out-of-flow. Are the spanners
adjacent?
fantasai: No, the em splits into two boxes around the div, so
there are boxes between the divs.
dbaron: So the end of an inline causes the creation of a line box,
you're asserting?
dbaron: Maybe if it has a border...
fantasai: We discussed this earlier, but it matches block-in-inline
splits.
florian: I don't want to deep-dive this, I suggest we keep to the
two issues
dbaron: spanners margin collapsing still needs things defined...
florian: We should just resolve on the collapsing in general.
<dbaron> block-within-inline behavior is that it's a function of
whether there's a border: toggle "xborder" to "border" in
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Aspan%20%7B%20xborder%3A%20thin%20solid%20fuchsia%3B%20%7D%0Aem%20%7B%20display%3A%20block%3B%20border%3A%20medium%20solid%20blue%3B%20padding%3A%203px%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cspan%3Ea%3Cem%3EB%3C%2Fem%3E%3C%2Fspan%3E%3Cspan%3E%3Cem%3EC%3C%2Fem%3E%3C%2Fspan%3E
dbaron: We might have someone reviving our column-span impl
sometime this year, so...
astearns: So are you saying we just add a statement that adjacent
spanners collapse their margins?
florian: For now depending on 2.1's definition of adjacent, and
open an issue to track whether it's sufficient or not.
[discussion about whether column rows should have boxes in the
layout model, or not]
florian: I think that option is easier now. I wonder if it makes
life harder when we do non-all spanners.
fantasai: I don't think so.
fantasai: I think Gecko won't actually create the boxes...
dbaron: In our impl we do, moved nsColumnSetFrame to be the row boxes
wrapped them in a new box.
fantasai: Great, even better.
florian: So that means we're taking the original issue that starts
with "alternatively..."
TabAtkins: So back to original issue?
florian: Original issue is that it seems impls say that spanner
margins collapse, but spec doesn't say how. So this will
solve that.
astearns: So "alternatively..." with extra details, like spanner
boxes are bfcs...
florian: I think we already have that one
astearns: So proposed resolution is second solution in the issue,
in order to define spanner margin collapsing.
astearns: objections?
RESOLVED: Second solution in the issue (spanners are BFCs that
collapse margins).
florian: I'll figure out with Rachel who does these edits.
CSS Text Decoration
===================
How text-decoration-skip/ink interacts with text-decoration
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2817
xidorn: problem here is that text-decoration properties generally
are not inherited, because we want the decoration line
to be one line across a whole element.
xidorn: But text-decoration-skip and text-decoration-skip-ink is
inherited.
xidorn: So it's unclear whether the decoration line on an element
should respect the -skip/-ink on the element, or on the
element that the line originated.
fantasai: Original design of text-decoration-skip had several values,
ink was one of them. Could say you want margin skipped,
etc.
fantasai: Also just "skip me", entirely.
fantasai: That value can't possibly work if it only works on the
element establishing the decoration.
fantasai: Whole point is to set it on an element and have it affect
a line established by an ancestor.
koji: text-underline-position has same issue
fantasai: text-underline-position should be attached when the
decoration is set, otherwise if you're switching languages
it'll switch sides
emilio: In gecko we implement the spec that says text-decoration
properties are reset...
emilio: With multiple decoration, webkit/blink keep track of them
in effect using an inherited property, which you add stuff to
emilio: I wonder what edge does
emilio: In webkit/blink decorations aren't propagated in box-tree,
which is supposed to happen.
emilio: Does edge implement the spec?
emilio: Right now the only ones affected by this operation are Gecko
frremy: edge does one underline for the whole thing, not one per span
myles: how we implement - if you have an outer that's underlined,
inner that's strike-through, you're supposed to add so the
inner gets both
myles: that's what emilio's talking bout
frremy: I think we have a field for underline and one for
strike-through
myles: Sounds like a different mechanism
dbaron: testcase with three different renderings...
<dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%0Au%20%7B%20text-decoration%3A%20underline%3B%20color%3A%20blue%20%7D%0Aem%20%7B%20text-decoration%3A%20underline%20line-through%3B%20color%3A%20green%3B%20vertical-align%3A%200.5em%20%7D%0A%0A%3C%2Fstyle%3E%0AThis%20%3Cu%3Eis%20%3Cem%3Esome%3C%2Fem%3E%20text%3C%2Fu%3E.
Firefox: blue underline stretching across whole thing, green
underline under "some" at its baseline.
Chrome: no blue underline under "some", it has green at its
baseline
Edge: blue underline stretching across whole thing (maybe), green
underline overlapping it (rather than at "some"'s baseline)
dbaron: This is the difference emilio is talking about
Rossen: We align the two underlines
myles: So we have a bunch of impls that are wrong. If you don't
consider impls today, don't consider spec today, what's
best behavior for users?
frremy: I think it depends. I think Firefox is a bit better in this
specific case.
frremy: But in some vertical cases, you want the underlines to align.
fantasai: The spec for underline says if you're gonna collide with
the text, you can move it down.
astearns: We're getting afield
florian: "skip-me" can't possible work unless the skipping applies
based on the descendant element, not the originator.
astearns: And the example in the issue - the div has skip-ink on it,
but a descendant wants no skipping - we want the descendant
to not skip.
dbaron: Another example is hyperlinks.
dbaron: A piece of a11y advice is that if you have multiple
hyperlinks, you should have a space between them, so the
user can tell they're separate links
dbaron: I think text-decoration skipping...
fantasai: We have a feature for that, text-decoration-skip: edges
<fantasai> https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-property
myles: Links with no space between them?
fantasai: That's why there's an "edges" value
dbaron: So some people might want for hyperlinks to *not* have
skipping, so you have continuity of underlines and can more
easily tell it's not multiple links.
dbaron: Where I'm going is that it's an argument for skip:none on the
thing setting the decoration, and having it not overrideable.
fantasai: I can see that for the ink value specifically.
fantasai: I think some of the other values we have that makes less
sense
myles: Any impls of the other values?
fantasai: Don't think so, and I think we resolved to split it apart
into multiple properties anyway, just hasn't been edited in
florian: Yes
myles: So for those other longhand properties we're still in the
design phase and can change them
florian: So we could decide which element it keys off depending on
the property
fantasai: Some of the properties are already bound to the decorating
box
TabAtkins: Once you've established a type of underline wrt
ink-skipping or not, don't want children to set it
differently
heycam: Is this fundamentally an issue with ink-skipping on by
default?
florian: I think we can set ink-skipping to work on the originator,
and others can be on children
fantasai: Fine with me.
fantasai: I do want to point out that if we do this, you can have two
underlines on one element, one that skips ink and one
that doesn't.
myles: You can do art with overlapping underlines!
TabAtkins: Proposed resolution is that text-decoration-skip-ink is
bound to the decoration where the decoration is
specified, and propagates with it
astearns: So resolving only on skip-ink, not skip.
fantasai: yeah
RESOLVED: ink-skipping is determined by the decoration originator,
not descendant elements
RESOLVED: underline position is also determined by the decoration
originator, not descendant elements
heycam: Does this mean they're not inherited?
myles: No, unrelated. It's just determined when you establish the
decoration, regardless of how the property changes on children
koji: I think text-underline-offset should also propagate with the
decoration
RESOLVED: underline offset is also determined by the decoration
originator
plinss: Any properties that *don't* go with the originator?
<fantasai> plinss, text-decoration-skip: objects
TabAtkins: yes, some of the other skipping functionalities, because
the children can say "skip *me*"
Scrollbar Width
===============
github: https://github.com/w3c/csswg-drafts/issues/1958
tantek: We had a rough consensus among people who cared to add a
scrollbar-width property.
tantek: We think it's implementable.
tantek: Wanted to bring it to people's attention in case there are
opinions.
tantek: This is one of the key things I wanted to resolve one way
or the other before FPWD. Other was color properties.
* fantasai notes that
https://lists.w3.org/Archives/Public/www-style/2017Feb/0059.html
probably belongs in this spec fwiw
heycam: This sets the maximum width? Why?
astearns: That was some feedback from Xidorn where the UA might want
to display something smaller sometimes...?
tantek: Right. You might want to limit how wide a scrollbar can be,
but not force platforms that do narrower ones to draw wide.
frremy: scrollbar-max-width?
myles: Worried for two reasons.
myles: First is MacOS scrollbars have two widths, they switch
between.
myles: Such a model can't express that.
myles: Second is that on windows, scrollbar widths will change if
you're using touch or not.
myles: So that also doesn't fit with this property
myles: Also, OS should be the one that sets these complicated models,
not websites.
TabAtkins: A lot of websites have very narrow scrollbars, and that is
exactly the reason why they are using non-native
scrollbars
tantek: You brought up a good reason for the max treatment.
tantek: Platforms can switch between widths *within* the property's
value.
tantek: so like on MacOS it starts small and gets bigger on hover -
you can still do that with max-width.
frremy: When it gets bigger it's overlay, right?
myles: When you're using non-overlay scrollbars, it doesn't change
size on hover.
frremy: So the width should just be the layout size
tantek: Maybe the size is just the initial size, the expanding can
ignore that?
myles: Problem is just that there's already three modes on MacOS.
I worry about letting pages control this.
astearns: Not allowing this property doesn't save users from terrible
scrollbars. Pages will use custom (terrible) scrollbars.
astearns: This just lets them specify a max width, you can still do
nice native scrollbars.
xidorn: I guess myles' point is whether the width should apply to
overlay scrollbars, which I'm not sure.
xidorn: I discussed with tantek before, and thought it should be
applied to overlay as well.
xidorn: But then we have problems - it may restrict the ability to
expand the scrollbar.
myles: One other piece I want to mention is that setting this
property shouldn't force scrollbars to be take up layout
space.
tantek: It doesn't.
xidorn: It might make the layout space *smaller*.
xidorn: Whether this should apply to the appearance of overlay
scrollbars is another issue.
heycam: What is the use-case for allowing a specific width to be
specified, and whether it's sufficient to just request
"thin"?
myles: So if our users select that they want scrollbars to take up
layout space, we don't have a thinner version.
tantek: I think the problem to solve is that users are creating a
totally new scrollbar just to make it thinner. The work
there is suboptimal due to usability.
tantek: Hope is that we can reflect the underlying platform's
behavior better.
myles: I'm sympathetic to the idea that giving authors a way to get
the behavior they want without building it themselves is
better.
myles: I'm not very convinced that this will be the impetus to stop
building things themselves.
Rossen: From xidorn's comment; if i set the max-width, at least we're
going to affect the layout size
Rossen: If that exceeds the width of the scrollbar, that'll be weird.
TabAtkins: That's why it's a max width.
Rossen: So it doesn't go above the visual width of the scrollbar.
With hidey-scrollbars, the width stays at zero.
[something from me]
tantek: Side issue - there are a lot of people discussing on the
issues *demanding* the webkit model. If there was a
canonical link I could point people to, it would be useful.
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Dec/0040.html
<astearns> https://lists.w3.org/Archives/Public/www-style/2017May/0010.html
frremy: I think the more recent proposal was for having a "thin"
keyword sounds good. And if they want "thin", maybe use
overlay for that specific element?
frremy: Request we get often is that people want dark scrollbars,
and people want tinier scrollbars, for things like chat
windows.
frremy: So yeah, maybe rather than a specific size, we just have a
"thin" keyword that opts into the OS's smaller version.
myles: So let's pretend I'm on gtk linux that only has one size...
frremy: Then it's just the one size, that's an OS limitation
myles: So this can't be tested?
TabAtkins: We try to minimize manual tests, but it's not a case o
if it's not possible to machine test it doesn't exist.
myles: So what happens if you test on an OS that only has one
scrollbar size?
tantek: It passes.
myles: So author has to know what all the platforms do...?
TabAtkins: Don't worry about GTK, everyone uses macos, windows,
or chromeos. ^_^
dbaron: And GTK *does* have two widths anyway.
tantek: So if we just add a thin value we can see what feedback we
get.
TabAtkins: I'd accept that in my use-case, yeah.
...
tantek: A lot of what we do is replace JS hacks.
xidorn: I'd like to raise that there was actually another use-case
I'd like to solve with scrollbar-width
xidorn: Some authors just want to make their own scrollbars, and want
to make the native be hidden, but still be scrollable.
xidorn: I think that's a reasonable use-case as well. Even if their
custom is terrible, it's still better than "overflow:hidden".
TabAtkins: Rich Byers had some proposal for having a scroller but
without a visible scrollbar
ScribeNick: fantasai
Rossen: Couple points, the first one is for the length value
Rossen: If we were going to go with a length value as it's currently
specified
Rossen: There has to be some affordances, or at least explain how
scaling works
Rossen: E.g. in Edge we go to a great extent to make sure that the
frame scrollbars never scale as you pinch-zoom, so that your
scrollbar doesn't take over the entire surface of your device
Rossen: At the same time, content will scale
Rossen: So already a discrepency at least in our case
Rossen: between scrollbars attached to the frame and the content in
the frame
tantek: gestures or other other zoom-like zoom property?
Rossen: For browser zooms, we always keep the same scrollbar size as
every other scrollbar in the system
Rossen: Not expecting any action, but it has to be considered
<tabatkins> fwiw, ChromeOS's native scrollbars are space-taking but
tiny, and they overlay-grow on hover.
<tabatkins> I lied, ChromeOS's native scrollbars are purely overlay.
Rossen: The other thing is that scroll spec started off that you
have a lot of interop bugs that were being reported to
you and since the last time we talked about this
Rossen: couple things I realized
Rossen: Firstly, we removed all styling of scrollbars in Edge 4 yrs
ago
Rossen: and we have absolutely no bugs reported to us about styling
scrollbars
Rossen: so curious where we're going with this
frremy: Actually, we keep getting bugs from Outlook complaining to
us about this, so it's not true
...
Rossen: To myles's point, ppl want more control
Rossen: Are we trying to go more towards this model, or try to lock
it down?
Rossen: thin/medium/thick scrollbars and some colors and leave it
there
tantek: The hope is that a small number of properties is enough to
satisfy users
tantek: There are sites that will outright block browsers based on
support for scrollbar styling
myles: New thing won't solve existing problem?
tantek: They're putting effort into trying every possible way to
style the scrollbars, so expect they'll update with new
thing if it's available
myles: Sites are saying that color of the scrollbar is so important
they'd rather people not use their service?
tantek: Yes.
<tantek> https://www.w3.org/wiki/Css-scrollbars#Sites_blocking_browsers
<tantek> https://webcompat.com/uploads/2017/7/96051d95-3863-4285-8b02-245403aeb160-thumb.jpg
xidorn: It's not so much about specific colors, but e.g. they have
a dark interface and they don't want light scrollbars
Rossen: I think the keyword values would be better
Rossen: Either adding or replacing <length>
myles: Scrollbars are a evolving technology
myles: A few years ago MacOS scrollbars had up/down arrows
myles: Then we went to overlay and dropped the arrows
myles: Then went to two different overlay
myles: Windows has similar evolution
myles: You need to consider how this works with all of the complexity
today, and also how it could work in the future
tantek: I agree with that, and been resistent to speccing this in
general
tantek: So trying to figure out with specific use cases
tantek: As much as scrollbars have evolved, some way to control color
has been constantly desired. Same with width
tantek: I would agree with your statement of being mindful of the
future.
tantek: Question is, do folks want a thin keyword?
astearns: Choice is between having width that allows for zero, or
having at least two keywords
astearns: thin/none/auto
Rossen: Can we take the length value out of the picture?
astearns: So do we have <length> or thin | auto | none ?
fantasai: If you wanna get rid of the scrollbar you can put it to 0
or none, same effect.
fantasai: But what do you mean by "thin"? If the author is caring
about the width of the scrollbar, they want it to be
narrower than a particular amount.
astearns: Tab's use-case was fine with "thin".
fantasai: So what if scrollbars are 10px by default, but a thin
version is 5px. They say "thin", because they want the 5px
version. But then later scrollbars default to 5px, and
thin is 2px, it's smaller than they needed!
TabAtkins: If it's 10px and 5px for thin, and author says 6px it's
fine, it'll choose 5px one
TabAtkins: Later OS change such that it's 8px and 3px, it'll go down
to only 3px
frremy: I don't think scrollbars will keep getting smaller, they're
about as small as they'll get.
Rossen: Disagree, we keep changing them as well.
Rossen: Going back to Simon's statement that scrollbars as OS-level,
and we shouldn't mess with them. I don't disagree with this.
Rossen: If the platform offers multiple sizes, maybe we give control
over choosing that, ok. Maybe we want to give a little bit of
color control, okay. But taking over system controls, you
either take it over or you don't.
Rossen: For any other system control, like a button, they take it
over totally. They use an image and script.
myles: So you're saying that authors should have no control, and
should use JS entirely if they want any control.
dbaron: An idea floated around was specifying a size and getting
nearest-available size.
dbaron: Problem with that is people try out sizes and fiddle around
until it looks good.
dbaron: They can end up getting a different size than they ask for,
but it looks okay, and then later changes violate what they
want while still technically respecting what they say.
dbaron: naming the property well can mitigate that risk
frremy: Reason I disagree - if you ask for "thin" on Mac you'll get
overlay, 0 layout size.
frremy: It seems way easier to just say "normal" or "thin", and
they're up to the UA.
myles: On macos, there's layout and overlay scrollbars.
myles: If the author's threshold is larger than layout scrollbars
they get that, if thinner they get overlay. Right?
myles: So the functionality seems to end up being flipping overlay
on and off, which isn't what it's meant for!
tantek: I don't think flipping that layout switch is what was
intended.
myles: But macos has just two scrollbars - 16px and 0px. If your
max-size is 15px, it'll turn on overlay.
myles: This is what I was getting at - we need to think deeply about
how this affects scrollbar models today and in the future.
frremy: Problem is that the longer we wait, the more custom
scrollbars we get.
myles: Authors want to control everything, never satisfied
TabAtkins: What they want and what they'll accept are two different
things
TabAtkins: And we're hoping we can hit their accept threshold with
fairly little stuff.
florian: Re fantasai's point about getting something ridiculously
tiny - maybe in the keywords we can have more than just
auto|thin, we can add |hairline. That's definitely distinct
in intent, while still allowing threshold.
myles: What if the OS's thinnest scrollbar is wider than the desired
length?
TabAtkins: This is why frremy suggests just doing keywords, eliminate
that problem.
florian: Note that scrollbar-gutter can solve some of those problems
too.
<tantek> https://drafts.csswg.org/css-overflow-4/#scollbar-gutter-property
fantasai: And scrollbar-gutter should be in the same spec as this,
if we go to FPWD.
myles: So tantek you don't need resolutions yet, right?
tantek: My normal approach is to put in all the possibilities so we
can discuss it with wider population.
tantek: So my inclination is to add "thin" and keep length for now.
Rossen: I think if we have the keyword and everyone revolts, we can
think about adding lengths back.
TabAtkins: I agree, and I think lengths have a harder time of getting
through the committee anyway.
myles: My preferred solution is still option 3 - none of this
proposal at all.
Rossen: +1
TabAtkins: I strongly disagree, as do our a11y people, but I
understand your position, because it's what Simon has
said every time this has come up.
tantek: So I guess question is - would anyone object to going to FPWD
with the width property at all, and would width with <length>
draw objection?
Rossen: I won't object to keywords. I'd object to length
myles: We don't object to it in either form.
florian: I don't object to any particular, but to me FPWD signals we
have details to figure out, but general agreement on the
approach.
florian: I'm not sure we have agreement on approach yet. Not
objecting, just noting.
myles: In addition to what I just said, which sounded positive, we're
actually reluctant.
[talking about fpwd vs patents]
tantek: I'm hearing the least objection to putting *something* about
length in there.
myles: Two browsers are reluctant.
tantek: If you really objected you'd drop the ::-webkit stuff.
myles: We don't comment on future software releases.
xidorn: Our position is that pushing this would help webkit/blink
drop the pseudo-elements.
xidorn: This is one of the use-cases we've heard.
tantek: Right. We think some of the users currently using
::-webkit stuff will be amenable to switching,
and the -width property will contribute to that.
tantek: So my goal is to put it in for now. We can always decide
in a subsequent draft to drop it.
florian: I'd be happier for FPWD if we agreed on earlier discussion.
fantasai: I think we're clear that this is about the simplest
possible thing we could to control the width
astearns: Rossen objected to "-width:<length>". If there was a scary
warning, would that get through your objection?
Rossen: Yeah.
proposed resolution to add "thin", and a big warning note about
<length>, then go to fpwd.
[discussion about whether keywords, length, or both]
astearns: And you should include a note about disagreement about
the existence of the property itself
[discussion about colors]
astearns: Would you object to fpwd with the colors as stated?
fantasai: I think I would.
fantasai: If a key use case is light/dark, we should have those as
choices
astearns: Then we're out of time and will have to come back to this.
Received on Tuesday, 24 July 2018 23:53:44 UTC