- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 11 Jul 2019 18:50:32 -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 Grid
--------
- RESOLVED: Add Oriol as an editor
CSS Fonts
---------
- Dynamic text size (Issue #3708) is a proposal to respect user's
font sizes without arbitrarily overriding website styles and is
based partly on -apple-system-font
- Generally there was support to keep investigating this proposal
and refine the recommendations
- The biggest concern was that this setting may not be used much and
therefore sites won't test against it, however no one at the
meeting had usage data to either validate or resolve this
concern.
- Another concern is that this is just adding another way to do font
sizing when there are already so many guides, some of which are
outdated but still referenced. The hope is that this change
would be a new way to level set font sizing rather than piling
on just another setting.
- Work will continue on investigating and improving this proposal
before the group is asked for a resolution.
SVG
---
- RESOLVED: SVG spec says that <foreignObject> creates a containing
block for fixpos and abspos children (FXTF Issue #307)
- The group felt issue #245 (Disabling masks/clip paths when
display:none) likely is not worth special casing. Additionally,
new browser interop testing needed to be done.
- Issue #249 (Clarify how userSpaceOnUse and objectBoundingBox apply
to non-SVG elements) needs additional review to decide between
multiple proposals.
Media Queries & CSS Sizing
--------------------------
- RESOLVED: Change <integer> to <number> in the aspect-ratio (Issue
#3757: Support <number> (and therefore calc) as a
<ratio>)
- RESOLVED: Allow <number> and <number>/<number> both for
<aspect-ratio> (Issue #3757)
- There's still not interest to implement the else conditional, but
the proposal originally drafted will be linked into the draft to
continue discussion
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/toronto-2019
Scribe: TabAtkins
Scribe's Scribe: dbaron
CSS Grid
========
Add Oriol as Grid editor
------------------------
RESOLVED: YES
CSS Fonts
=========
Dynamic text size
-----------------
github: https://github.com/w3c/csswg-drafts/issues/3708
AmeliaBR: Want to be able to respect user's font sizes, especially
on mobile, without arbitrarily overriding website styles
in ways that break pages
AmeliaBR: Want good pages to be able to opt into user's prefs at the
OS level.
AmeliaBR: I brought it up because in the issue's long discussion
there were some straightforward proposals.
AmeliaBR: One was a new "system-font" keyword (for 'font' shorthand)
AmeliaBR: WebKit has a keyword for that
AmeliaBR: Suggestion is to standardize that after agreeing on the
shorthand keyword
AmeliaBR: Already have font-family keyword that is system-ui,
waiting for FF impl, but in two browsers and in spec
AmeliaBR: Different for 'font' keyword is you'd also get default
sizing
AmeliaBR: Second, trickier aspect is what if an author wants to opt
into the user's font size without getting the system font.
AmeliaBR: My argument is that's what "medium" was supposed to be.
AmeliaBR: Might get messy, maybe we can talk about that.
myles: Some context:
myles: Browsers have 11k ways to adjust text sizes
myles: All area balance between making text readable and trying to
not break layout
myles: Having a website opt in and say "I know this part of the page
will respond well" won't fix every site, but will at least
let us resize that part more freely.
myles: General request is really important for a11y.
myles: (and just people like to change their font size)
myles: Every OS has this, ebook readers too.
myles: So I'm just hoping for some way for a website to say "for
this part of the page, go hogwild"
myles: We have a non-standard prefixed mechanism for this
myles: Would be cool to resolve on that, but we're not married to it
myles: Another idea is to use env()
myles: Interesting on iOS which lets you change both size *and*
weight
myles: I don't wanna prescribe any specific solutions, but would be
cool to come up with something for this.
myles: Our existing solution is a 'font' keyword
myles: You can say "font: -apple-system-body"
myles: It'll resolve to a specific size, so if you want your page to
react fluidly as the user slides their font-size slider, you
put that value on the root element and let the inherited
style work correctly
<AmeliaBR> Proposal is to add a `system-body` keyword for the font
shorthand. Sets the font-family and size together.
koji: I don't have a preference for solution, but I'm hearing the
request for -apple-system-body in Blink
koji: Would be great to standardize
dbaron: Presumably there's some default size for this keyword.
dbaron: What percentage of users have it at this default size?
dbaron: My concern is that if it's over, say, 75% or more, pages
will likely still not work if it changes.
myles: Dunno
AmeliaBR: The whole point of this is to not change anything by
default
AmeliaBR: Webpages have to opt into it
AmeliaBR: So your concern is that they might opt in thinking they're
getting a standard default, and not realize it's
adjustable?
dbaron: My concern is that things that don't get tested get broken.
If it's only true for a small percentage, it won't get
tested, and even if original design got it right, someone
will come along later and make it break for a non-default
size.
dbaron: Just like before we made px be a 96:1 ratio with in. Users
with a different ratio, only in Firefox and IE, saw broken
websites.
myles: Can't answer directly, but can offer some info
myles: In our experience, this isn't just a11y. Many users change
just because they like bigger text sizes
TabAtkins: It sounds like from your suggestion from using
-apple-system-body on the root and then using rems or
inheritance
TabAtkins: does address Amelia's request to just get the font size
people want?
myles: Yes
TabAtkins: It sounds like from your response to david that there's a
decent percentage changing to a non-default value?
myles: Yes
jensimmons: Is what's being proposed only affecting font-size? Or is
there an easy way to cascade that measurement into
layout?
jensimmons: Is it different from just using 'em's, etc?
myles: This should be a way of setting font-size like any other way
of doing so. Does that answer your question?
jensimmons: There are many websites that don't do things right, we
have to consider them because they're majority. But this
is an issue been incredibly important to front-end
designers/teachers: make a webpage work when people
choose their font size.
jensimmons: These days the only thing left to understand is how to
zoom on desktop
jensimmons: Best practice has changed many times over the years.
jensimmons: A bit of tail-chasing, browsers trying to chase
badly-written sites, and good sites chasing browsers,
and round and round.
jensimmons: And because info about best practice ages, people don't
realize it's old; like people still say "set font-size
on root to 10px and use 'rem'"
jensimmons: So this comes down to, have an easy way to let users
change font size and have an easy way to adapt to it.
jensimmons: So I just want this to fit into that evolutionary
conversation.
jensimmons: Rather than YetAnotherWayToDoIt
myles: Agree 100%
myles: My intention isn't to make a new blessed way to design
responsive websites
myles: More allow authors to annotate their source with some info we
don't already have, and that annotation is "this part of the
page works well when font-size changes"
florian: I think this new proposal has a chance of breaking the
cycle, precisely because this setting is used by a large
number of people. It's always existed, but tended to be
used by few.
florian: Like dbaron said, when too few people use it, things break.
florian: But because this is used by many, there's a chance it'll
stay viable, rather than being poisoned by maintenance.
jensimmons: The idea we should take the preference setting and give
it to webdevs to use, I'm definitely for it.
chris: I noticed in the thread that someone suggested there should
be a property that is system-font-size * browser font scale
chris: I'm not opposed to a new generic font family, but if people
are using that purely to get at the size, that seems more
robust to me.
<chris> "the property in question should be SYSTEM_FONT_SIZE *
BROWSER_FONT_SCALE. On iOS and Android, BROWSER_FONT_SIZE
would likely always be 100% with SYSTEM_FONT_SIZE being
variable. But on Mac OS X, it would be the opposite. Windows
would likely support both. "
chris: To get the size directly, rather than using the whole font
just to get the size
AmeliaBR: There's content out now that's UA-dependent, trying to
recreate the system body font.
AmeliaBR: (which I find annoying, as I don't like Window's system
font...)
AmeliaBR: But a keyword would be smarter than the website trying to
*guess* that I want Seguo UI.
AmeliaBR: So I think there's a demand for combined, but we should
also do apart. But Tab did say that if we have the font
keyword on root, we can just use 'rem's.
AmeliaBR: But I would prefer "font-size: medium" to do actually
that, but...
chris: You ran some tests; we saw that browser didn't do that.
myles: We've tried to make "medium" reflect preferred size. It
breaks too much, can't do it.
astearns: Why is this a keyword on 'font' rather than a keyword for
font-size?
myles: There's a collection of 'font' keywords.
myles: This one means "this is the size that best fits apple body
text"
myles: Now that we have system-ui generic font family distinct from
that, I think the use-case is [...?]
astearns: So system-ui is on font-family, not 'font'?
myles: Yes.
<chris> so I guess it sets the line spacing too
heycam: You answered "Why is this just not the default". What
specifically did you try? Did you try switching "medium" and
leaving the initial font-size to 16px, did you try changing
initial and leaving "medium", or?
myles: The latter
heycam: What actual font-family is set by this? Same initial value
that kinda depends on lang and so on? Or always serif?
myles: The system font, "San Francisco" on Apple
TabAtkins: So it's the system-ui font?
myles: Yes
AmeliaBR: system-ui is a new generic, an alternative to 'serif' or
'sans-serif'
jensimmons: If your CSS you use to react to different preferences is
different on mobile than desktop, that's bad. Is it?
myles: Android and iOS both have this setting, windows desktop has
this setting. Don't think it would differ.
jensimmons: [missed]
jensimmons: If this is something you're supposed to use, but it only
works in some browsers, that's a problem.
AmeliaBR: So your concern is that browsers with an in-browser
font-size option, the system font being pulled from
outside the browser wouldn't match?
myles: Does "work" mean that it draws from the OS? That can be done
on every platform. Or does it mean some devices on a platform
will have one value and other devices on that platform will
have others?
AmeliaBR: So should the value come from browser, or browser+OS, or
what?
<heycam> preferred-font-size:no-preference
TabAtkins: I don't think there's any reasonable use-case for "OS
size" different from "browser-provided default size"
chris: I wasn't suggesting two vars, I was suggesting a single thing
from multiplying those together.
myles: So I think we have consensus for a font-size env()?
myles: Also, since we expose weight, do we want an env() for weight?
<AmeliaBR> So, to get the effect of the -apple-system-body keyword
would be `font: env(preferred-font-size) system-ui;`
TabAtkins: Sounds okay, but slightly concerned due to dbaron's
concern about small usage.
emilio: Firefox's font settings are per-lang, so I'm not sure how to
distill that to an env() value
emilio: And to get the opposite would be `font: -apple-system-body;
font-family: foo;`
astearns: I don't like the default weight; the page would lose the
the distinction between bold and not.
myles: Yeah, they're asking for that.
astearns: They're asking for it in system UI, which doesn't use much
bold. Not necessarily in web content.
TabAtkins: Does Apple system ui tend to use bold to distinguish
stuff, such that the default weight would lose
information?
myles: There's some, but it's rare, so not much info is lost.
astearns: So emilio, if you had an env(), you'd have to pick which
size to use based on lang, etc.
astearns: But you have to make the same decision for the keyword,
right?
emilio: Different. You'd have the element language, you'd apply the
generic family.
TabAtkins: So you're saying that the font keyword, being resolved on
the element, can be different per-element based on lang?
But the env(), which should be global, can't do that?
emilio: Yes.
AmeliaBR: "medium" on Chrome and Firefox currently resolves to user
font size.
emilio: Right, so I guess an env() font-size for that would be okay.
koji: I'm confused. This is about exposing system font size setting
not user's setting in browsers, right?
koji: But windows/mac/etc all expose only a single value
emilio: That makes sense.
AmeliaBR: The idea is that the exposed variable is the setting in
the browser, if they capture that, or OS otherwise
fantasai: A problem with "medium" is that it can't reflect user
setting
TabAtkins: Myles did tests for the *initial value* being user's
setting, and that broke stuff. But Chrome/Firefox reflect
"medium" being the user's setting.
AmeliaBR: But that's the same thing, as "medium" is the initial
value.
myles: So I think this topic is an investigation, we're not going to
finish right now.
astearns: But I think the room has a general intent that this is a
good idea.
AmeliaBR: If people have data for what percentage of users change
their default font size, or how much breakage is observed
when things change, this would be useful info in the issue.
SVG
===
SVG container elements
----------------------
github: https://github.com/w3c/fxtf-drafts/issues/307
AmeliaBR: Filters create a containing block for abspos/fixpos
AmeliaBR: When specified nobody thought about SVG, because it
doesn't have abspos.
AmeliaBR: But you can do a foreignContent with html that uses abpos.
dbaron wondered what happens there.
AmeliaBR: Looking at browsers, they're non-interop.
AmeliaBR: In discussion, consensus seems to be that the
foreignObject is a containing block for abspos/fixpos, so
you don't have to worry about whether an ancestor svg
element has a filter or not.
AmeliaBR: That's what Chrome does
AmeliaBR: So we need to specify foreignObject better in general
about how it provides a containing block for css content
inside of it, and making this dfn makes things simpler,
but it does add a new place where we're trapping fixpos
elements.
astearns: chrishtr says that the SVG spec already defines that
foreignObject defines a fixpos containing block
AmeliaBR: Maybe
<bkardell> is this totally related?
https://github.com/mathml-refresh/mathml/issues/48
mstange: I think all browsers already agree on this
mstange: The difference Amelia found might be an old version of
chrome; I think browsers now agree
mstange: I think having foreignObject be a containing block for
everything makes a lot of sense
AmeliaBR: Weird ones that don't match are Safari: <foreignObject>
contains fixedpos but not abspos. stickypos is a big
untested mess too
mstange: We may want to add something about sticky to the spec, then?
iank: Maybe better as a separate issue
dbaron: I don't think anything special needs to happen with sticky,
because I don't think it escapes very far
AmeliaBR: I think the definition of what happens with it will fall
out of defining it as a containing block
emilio: sticky is about scroll containers, not containing block
astearns: So what needs to be done here?
dbaron: Larger answer is that we need a spec to centralize a bunch
of this
dbaron: Part of reason for all these questions about CBs and
stacking contexts, etc are such a mess is that there are
multiple specs amending dfns that don't actually exist.
dbaron: So someone needs to write a spec that defines these terms.
dbaron: So opacity/mix-blend-mode/etc can all hook that instead of
defining ad-hoc
dbaron: Simple thing is to resolve that <foreignObject> establishes
a containing block for abpos and fixpos
flackr: I think sticky says it moves according to the nearest
ancestor with non-visible overflow
dbaron: Can <foreignObject> overflow...?
AmeliaBR: Haven't tested
AmeliaBR: I think it overflows, I've done it to get a <label>.
astearns: Let's resolve on abpos/fixpos and do sticky separately?
chris: Rossen wanted it to be an ICB...?
hober: Without him explaining why, I'm loathe to define that
iank: Yeah, ICB has a lot of other implications.
AmeliaBR: I can take action on edits
TabAtkins: Ping me and fantasai for review
astearns: proposed resolution: svg spec says that <foreignObject>
creates a containing block for fixpos and abspos children
RESOLVED: svg spec says that <foreignObject> creates a containing
block for fixpos and abspos children
Disabling masks/clip paths when display:none
--------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/245
AmeliaBR: I don't expect a resolution here. SVG call discussed it,
we decided we needed detailed testing for browser interop
AmeliaBR: What browsers are doing doesn't match long-standing SVG
text tho
AmeliaBR: This is about SVG elements that are never rendered:
<*gradient>, <pattern>, <symbol>, etc
AmeliaBR: In SVG1, these all had an opaque paragraph that said
"display doesn't apply to these elements, no matter what
you say it won't be rendered, and no matter what you say
they'll always be usable"
AmeliaBR: For SVG2, I was working on trying to make <use>-element
shadow DOM make more sense
AmeliaBR: To make <symbol> not work directly, but work if you render
it in which case 'display' does apply
AmeliaBR: Figured I could replace that prose with a UA stylesheet
using !important to mean authors can't change 'display'.
AmeliaBR: So say "display:none; except for <symbol> that is a direct
child of a <use> shadow tree"
AmeliaBR: But turns out that in browsers, display:none *does* do
something
AmeliaBR: In most browsers, if you set <mask style=display:none>, it
has no effect on elements using it as a mask
AmeliaBR: This isn't in specs but happens in multiple browsers.
dbaron: Interesting is whether the element has display:none *and*
whether ancestor has it
dbaron: Tied to "is the thing that makes these work the presence of
their DOM node, or the presence of boxes they create"
dbaron: For many browsers, these live in the box tree, and using
them links to the box tree, and display:none means no boxes
are generated and they fail
dbaron: So question is if that's what we want to do
dbaron: So in general display:none and ancestor display:none are not
distinguishable
dbaron: So using a non-none !important value doesn't work, as it
doesn't solve the ancestor problem
hober: Do we need to special-case these at all? In HTML <style>
defaults to display:none, but you can display:block it to
render it.
hober: So who cares?
dbaron: I think at this point that's not backwards compatible
chris: Used to be that you couldn't display <title> no matter what
you did. But now you can.
AmeliaBR: I don't know how much will break, I didn't know that
browsers were doing it anyway.
AmeliaBR: I suppose it could be useful sometimes to disable a
clip-path by setting one thing on the <clipPath> rather
than changing all the uses...
AmeliaBR: Practical case it breaks. Lots of inline SVGs using a
gradient, so you have an inline SVG somewhere that defines
those gradients. You don't want it to draw, so can you
tell that SVG display:none?
AmeliaBR: Some browsers you can, some you can't, because of what
dbaron mentioned earlier.
AmeliaBR: So instead you throw a pile of styles at it to make it
visually hidden but not display:none
* bkardell still thinks there should just be a visually-hidden class
or even just attr with that class in the UA sheet
emilio: Is part of the reason it depends on the box tree-- we have a
special thing for SVG that says "this frame is non-display"
that doesn't do anything on its own
emilio: What that gets you is that a lot of elements don't generate
a box at all when they're invalid markup - not in an SVG
parent or whatever.
emilio: You need to make all those checks in two places now
AmeliaBR: So if anyone wants to help us build up that
interop-testing table, that would be very helpful.
astearns: So I think you can take that back to the SVGWG with our
notion that it's probably not worth special-casing, and
maybe impossible.
<dbaron> Is there going to be some attempt to drive towards interop?
Clarify userSpaceOnUse and objectBoundingBox on non-SVG elements
----------------------------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/249
AmeliaBR: Mega issue that affects everything in SVG graphical
effects that we support applying to CSS boxes
AmeliaBR: SVG effects (gradients, patterns, clips) have a switch for
how they're scaled and positioned
AmeliaBR: So when you apply it to a rect, it can either be scaled to
that rect, or to the svg as a whole so a gradient spreads
smoothly across multiple rects, etc.
AmeliaBR: When we added the specs for applying masks/clip-paths/
filters to CSS boxes, it was never defined how they map to
CSS coordinate spaces
AmeliaBR: Actual impls are inconsistent
AmeliaBR: I periodically get bug reports about how this is supposed
to work
TabAtkins: Roc had a proposal
TabAtkins: Both anchor position according to CSS coordinate space,
(and some other stuff)
TabAtkins: You at least get consistent sizing, but don't have the
ability to have multiple boxes with views into the same
gradient
AmeliaBR: Yes, that's the simplest approach that still has sensible
results
AmeliaBR: So boxes are always the size of the css box
AmeliaBR: And OBB, which assumes the effect is scaled 0->1 gets
that, and USOU gets normal px measurements
AmeliaBR: Other possibility is that you map USOU to the ICB (or
nearest CB). Firefox does one of these, don't remember
which CB.
AmeliaBR: This doesn't match roc's proposal.
AmeliaBR: So can we get more eyeballs on this? It prevents us from
getting a reasonable spec on several of our fxtf specs.
Media Queries & CSS Sizing
==========================
Scribe: fremy
Support <number> (and therefore calc) as a <ratio>
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3757
AmeliaBR: Currently for the aspect-ratio media query we define a
ratio type (integer slash integer)
AmeliaBR: we are thinking about using the same type for the
aspect-ratio property
AmeliaBR: I think we should support decimal in addition to the
fraction
AmeliaBR: so <int>/<int> or <number>
jensimmons: I can see how this looks like a fraction, but I don't
think of it this way
jensimmons: Interested people can look at the history of aspect
ratio in the film industry
jensimmons: There is both 16/9 or 16:9 or 1.77
jensimmons: I don't see us wanting to have 1.77:1
jensimmons: That is confusing
<chris> its a rational number, not a fraction
<chris> https://www.mathsisfun.com/rational-numbers.html
myles: Is it bad that when you actually divide these numbers you get
non-round numbers?
AmeliaBR: yes, this is why we prefer the "fraction-looking"
expression
myles: So we don't want to convert to a number, right?
jensimmons: No, we would keep the other representation
myles: I don't want to have a 1px gap because of people's mental
rounding errors
AmeliaBR: But when authors have numbers they computed themselves in
some other way, we don't want to force them to use a
fraction
heycam: So, if you want to use css variables, you would want to use
calc() right?
myles: Native APIs often expose numerator and denominator as
distinct in those cases
* leaverou wonders why we can't do both? There's no syntactical
ambiguity. <number> | <number>/<number>
<astearns> we are talking about doing both, I think
chris: Come on folks, are we really discussing this?
chris: This is a rational number, we can allow that and other forms
of numbers, this is very common outside of CSS
<chris> The ancient greek mathematician Pythagoras believed that all
numbers were rational, but one of his students Hippasus
proved (using geometry, it is thought) that you could not
write the square root of 2 as a fraction, and so it was
irrational.
<chris> But followers of Pythagoras could not accept the existence
of irrational numbers, and it is said that Hippasus was
drowned at sea as a punishment from the gods
TabAtkins: I think I agree that accepting all <number>s is
reasonable, for the calc() cases
TabAtkins: but I don't think we need to add just plain <number>
because it's nice to have a single consistent syntax
pattern
<dbaron> Tab's proposal (do just change <integer>/<integer> to
<number>/<number>) sounds good to me
leaverou: I don't understand why we can't do both. There is no
syntactical ambiguity.
leaverou: Can't we do both? Why do we want to pick one?
TabAtkins: ok, there is no ambiguity, but it makes the syntax more
complex, I appreciate consistent things
TabAtkins: but you are are right that it's not ambiguous
AmeliaBR: We can wait until we have more authors using this, and
then see if get questions anyway, some will wonder why you
have to write 1.5/1 instead of just 1.5 but ok that's
doable
jensimmons: calc() and variables, can someone explain how that would
work now and with the proposals?
TabAtkins: Today, if you use calc, it would get weird results,
because we only allow integers, so they would be rounded
TabAtkins: so it works in theory, but it's not very practical
TabAtkins: The proposal would allow to have any number, so you can
compute using a ratio of two variables
jensimmons: That sounds reasonable, but there is a very common case
with just a number, I don't see why not adding that as
well
astearns: And that seems common, so I'd plus on that
TabAtkins: I would prefer not to add syntax when it doesn't add
much, but if there is strong demand for this, I could get
convinced
astearns: So, can we resolve to change <int> to <number> for aspect
ratio values?
RESOLVED: change <integer> to <number> in the aspect-ratio
TabAtkins: For the second part, what do implementers think?
dbaron: I think that I cross-multiplied to avoid rounding, but I'm
not sure
dbaron: I considered it because otherwise it's a bit scary if people
might try an equality and rounding is risky then
dbaron: but code has been rewritten since then anyway
dbaron: so I don't know
<chris> people comparing two floats for equality need to learn why
that is never a good idea
* flackr wonders if people would be confused by having to specify
aspect-ratio: calc(16/9)/1 if the /1 is required
astearns: I think we should try to keep the syntax simple, and
revisit if we get requests
<emilio> https://searchfox.org/mozilla-central/rev/153172de0c5bfca31ef861bd8fc0995f44cada6a/servo/components/style/media_queries/media_feature_expression.rs#31
hober: But priority of constituency indicates that we should favor
allowing to drop the slash one
astearns: Also, looking at the example emilio pasted in irc, the
slash one looks dumb, so I changed my mind a bit
jensimmons: Also, I don't buy the complexity of having two syntaxes
<myles> <number> | <number> / <number>
astearns: Ok, so let's try to resolve to allow <number> and
<number>/<number> both
dbaron: Well, that constrains syntax a bit, but I'm fine with it
<jensimmons> this is really good. And it’s good to do it now.
RESOLVED: Allow <number> and <number>/<number> both for
<aspect-ratio>
Media Queries
=============
else conditional
----------------
github: https://github.com/w3c/csswg-drafts/issues/112
TabAtkins: heycam wanted to put this on the agenda, and I'd be
interested to know why he brought this up
heycam: I made a proposal and it never got discussed further
<TabAtkins> http://tabatkins.github.io/specs/css-when-else/
TabAtkins: Yeah, I had limited time so I didn't push forward, but if
there is interest I can reprioritize my work
astearns: So, heycam, are you volunteering to implement that?
heycam: No
TabAtkins: In that case, I'd rather leave this in the status of
proposal
fantasai: Could we maybe cross-link the issue in the draft, so this
discussion is available to readers?
TabAtkins: Okay, sounds reasonable
TabAtkins: It's not right now, but I can do this
ACTION: Tab to cross-link the issue from the draft
heycam: So, shall we table this discussion for now?
florian: Just wanted to note that also unless everybody is doing it,
it's not useful
myles: Sure, but if one does it and authors finds it useful, others
will follow
TabAtkins: But the point is that right now we don't even have one
promise to implement
astearns: Okay, let's try to do easing timing functions, then take a
break
Received on Thursday, 11 July 2019 22:51:30 UTC