- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 5 Oct 2017 21:25:15 +0300
- 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.
=========================================
Flex sum < 1
------------
- RESOLVED: Revert the previous resolution regarding flex sum <1 (as
has already been done) and solicit dholbert's review.
Reconsidering the meaning of 1fr
--------------------------------
- RESOLVED: Specify that custom styling of the underline overrides
the UA-rendered underline (not just adds to it). Details
to be determined in a separate issue.
offset-path strings
-------------------
- RESOLVED: Computed-value normalize case of path commands (to the
absolute version).
- RESOLVED: Figure out details on normalizing similar commands into
more general ones.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0003.html
Present:
David Baron
Brian Birtles
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Daniel Glazman
Jihye Hong
Dean Jackson
Myles Maxfield
Naina Raisinghani
Manuel Rego Casasnovas
François Remy
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Shane Stephens
Greg Whitworth
Eric Willigers
Regrets:
Rachel Andrew
Bert Bos
Benjamin De Cock
Tony Graham
Dael Jackson
Vladimir Levantovsky
Thierry Michel
Michael Miller
Scribe: TabAtkins
Spec rec progress
-----------------
florian: One bug left on UI tests
<florian> Last UI-3 Bug, firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1376718
<florian> Last UI-3 Bug, Edge:
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/13874660/
<florian> Last UI-3 bug, Chrome:
https://bugs.chromium.org/p/chromium/issues/detail?id=737452
<florian> Last UI-3 bug, Safari:
https://bugs.webkit.org/show_bug.cgi?id=173910
<florian> To be clear on UI, there are other bugs in various
browsers, but that's the last thing that doesn't have 2
implementations
Flex sum < 1
------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1735#issuecomment-332671797
astearns: My understanding was that we had a resolution, but we had
to revert it because there was a discontinuity.
fantasai: Yes, we need to be continuous for a given flex item going
from 0=>1, *and* for the flex container when its children
do the same.
fantasai: Previous resolution fixed the flex item, but it created a
discontinuity for the flex container.
fantasai: So our proposal ends up giving non-linear behavior for
flex items when the sum is <1, but it's continuous.
astearns: Has dholbert looked at the revert?
TabAtkins: He hasn't commented yet, so if he's seen it he hasn't
approved it.
astearns: So should we wait until we get feedback?
TabAtkins: I'd prefer to get someone invested to give positive
feedback.
rego: I think we should accept the proposal.
astearns: Have you reviewed the reverted text.
rego: No, haven't checked the new text specifically, but I want
continuity.
astearns: fantasai, what do you want to do?
fantasai: Resolve to revert to the previous text unless dholbert has
opposite ideas.
astearns: Any objections to reverting?
RESOLVED: Revert the previous resolution regarding flex sum <1 (as
has already been done) and solicit dholbert's review.
Styling the ::spelling-error marker
-----------------------------------
GitHub: https://github.com/w3c/csswg-drafts/issues/1828
florian: In Pseudo 4 we have ::spelling-error and ::grammar-error.
The spec doesn't say that the browser is supposed to use
these to put their own markers.
florian: So technically it's valid for your outlines to *add* to the
browser UI, not replace.
florian: So the spec needs to state that...
florian: Maybe do UA stylesheet to mandate what they look like by
default, or just say that the UA one has to use
::spelling-error
<fantasai> +1 to Florian's proposal
<fantasai> to require that UA styles are expressed in this manner
TabAtkins: Don't mandate the UA style, let it do whatever. But
definitely mandate that it replaces.
myles: The existing markers don't necessarily map to something in
CSS, so we can't do it precisely in the UA stylesheet.
myles: For example, the MacOS style is under-dots with a gradient
inside, and we try hard to make sure there's never a partial
dot.
<fantasai> I don't think making sure there's never a partial dot is
incompatible with CSS
<fantasai> CSS doesn't mandate dot spacing, leaves it up to the UA
so that it can do exactly these things
florian: Okay, so how to specify it?
florian: Any property specified, it shuts down the native one?
florian: That seems too much, they might just want to do the color.
myles: Adjusting the color of our dots isn't possible. It should be
just like 'outline'.
TabAtkins: Agreed.
fremy: Yes, it should also have a value that means "native", just
like outline.
tantek: Agreed as well, it's also like borders - the natives might
look more special than you can get with built-in stuff.
tantek: The key aspect here is normative text that says "if you draw
it normally, don't draw it when CSS specifies one".
<dbaron> Tantek was also pointing out to me that what myles
described with the dots sounds like a new underline style
astearns: And we can agree on that text regardless of whether UAs
can specify something today.
florian: So is that sufficient? If you set color, does that count as
"CSS-drawn"?
<fantasai> "Any styling provided by the author must override, not
duplicate, any particular aspect of the UA's default
styling, even if the exact characteristics of that
styling are not expressible in CSS."
myles: That seems like a clear intent that they want a pink error,
should switch to the CSS one.
florian: So what happens then? What style?
TabAtkins: The default one.
florian: The default is "none".
<tantek> "text-decoration-style:system-spelling-error"
fantasai: Can't change the default value - it's 'text-decoration',
used more widely than just ::spelling-error.
* fantasai thinks ppl need to hear tantek's comment
fremy: We can say that the default pixel is "1px wavy red" in the UA
stylesheet, and the browser is free to render whatever way it
wants...
fremy: Say that if you don't override anything you get the UA
rendering, but if you override something you get the other
values defined in the spec.
<tantek> or even just text-decoration: system-spelling-error
<tantek> since it may affect color/style/etc.
<tantek> and there may be no way to decompose the
system-spelling-error "look" into components
<tantek> same with text-decoration: system-grammar-error
<tantek> just thinking off the top of my head
<tantek> please consider these proposals with a grain of salt. or is
that sand. I forget.
florian: Model after outline-style:auto which lets UA do whatever,
or is the same as solid. We could do something similar
here, with text-decoration-style: auto, which can do what
it wants, or fall back to wavy.
florian: Only problem is that then you can use the spelling-error
style on any element.
TabAtkins: Is that a problem?
florian: No, I think it's useful, so you can do your own spelling
marking in JS or something and have it match with native.
<gregwhitworth> this sounds like possibly an option for env()
<gregwhitworth> env(spelling-error)
astearns: So it sounds like we want to add a system-spelling-error
style for text-decoration.
<tantek> haven't through through the connotations for the cascade,
but similar to outline right?
myles: We have a new concern, and have the WK person implementing
this.
Daniel: So are you proposing these for each of the error types?
florian: Just the two.
TabAtkins: We only recognize two with pseudo-elements so far.
* fantasai notes that offset is planned for L4
Daniel: Sounds great to opt into the system-spelling one.
Daniel: What if they want to style the errors and achieve the look
of the system one.
Daniel: So on Mac the spelling errors are always drawn beneath
existing text decorations, so if you have underlines, the
spelling markers are put below them.
Daniel: How do you achieve the same effect?
florian: No problem here, I think. The underline isn't set on the
spelling error, it's set on some parent element. The
spelling error decoration is set on ::spelling-error.
<dbaron> maybe somebody should write up what the proposal is and we
should come back to it once people had a chance to read and
ask questions?
<astearns> +1
Daniel: I specifically mean if you just want, say, a black wavy
underline, but definitely underneath the existing underline.
fantasai: We have a control for that in Text level 4.
florian: text-underline-offset.
<florian> https://drafts.csswg.org/css-text-decor-4/#underline-offset
Daniel: Okay, so that would allow offsetting.
fantasai: Yeah. The "auto" value is different though - "auto" just
means "UA decides on the offset appropriately", and can
use text information or something.
fantasai: Currently can't pay attention to other decorations to
avoid overlapping, we would need another value for that.
astearns: So we're going to resolve that if the ::spelling-error has
t-d styles, we'll use CSS drawing for that, and override
the system-level decoration.
dbaron: I think that might need to be specific to certain properties.
dbaron: Don't want it to happen just if the selector exists, want
specific properties to be specified.
florian: The proposal was to have a text-decoration value of
"system-spelling-error" that gives magic rendering, and if
that gets overridden, it uses CSS rendering instead.
TabAtkins: So back to what dbaron said in the chat, can we get the
actual new proposal in the issue, and resolve on it next
week?
<gregwhitworth> I must have missed this - but who is asking for this?
<gregwhitworth> ^ the feature as a whole
astearns: Yeah, can we resolve to just do the UA overriding?
<tantek> ok with that
RESOLVED: Specify that custom styling of the underline overrides the
UA-rendered underline (not just adds to it). Details to be
determined in a separate issue.
ACTION Florian to propose text to resolve issue 1828
<trackbot> Created ACTION-864
<florian> fantasai: if I propose text to add system-spelling-error
and system-grammar-error to text-decoration, should I do
that as a PR to level 3 or 4?
<florian> fantasai: I'd prefer 3, since level 4 is a semi-empty diff
spec that doesn't even have the relevant properties. But I
am not sure how much you're trying to wrap up level 3
offset-path strings
-------------------
GitHub: https://github.com/w3c/fxtf-drafts/issues/225
ericwilligers: When you animate a path string in SVG using both
upper and lowercase commands, there's no way to read
it back out. But CSS can do so.
ericwilligers: So we have a proposal to normalize the path strings
to a canonical representation during animation.
ericwilligers: Related: You're not allowed to animate between
different commands even if they're very similar, like
H (horizontal line) to L (any-direction line).
ericwilligers: There was a suggestion that we should allow it.
ericwilligers: There was little UA participation of this in SVGWG
tho, so bringing it up here.
shane: I don't think anybody thinks its a *bad* idea, but just low
use-cases for explicit promotion.
ericwilligers: So I'd like to ship offset-path and d, and it's more
useful if you can animate them.
TabAtkins: So three proposals:
TabAtkins: 1) animate path(), affecting motion-path and d (this
already has a resolution on it)
TabAtkins: 2) When animating, normalize abs and rel commands (upper
and lowercase) to a single canonical form (uppercase,
specifically) so you can animate "h" and "H".
TabAtkins: 3) When animating, normalize "families" of similar
commands into a single canonical command, so H/V/L all
become L, etc, because they're just convenience
syntaxes for each other and not significant
differences that should stop animation.
shane: Animation of path() in SVG is pretty underspecified in SVG2
right now.
shane: It says that 2 property values can only be interpolated
smoothly when the paths have the same structure (same number
and type of command).
shane: "type" isn't really specified - could mean individual
commands, or ignoring abs/rel, or in families.
shane: It's hard to say what SVG2 *intends* to specify here for
interpolation.
shane: I think you want normalization to reflect interpolation
behavior.
shane: If we said today that we wanted path() to animate between two
lines, it should promote between any two line types.
shane: Eric suggests shipping the de facto SVG behavior now, iterate
on it later. I'm a little afraid of being able to change that
later.
shane: I think the current behavior is poor for authors. If you
wanna do any animation you have to fall back on tools, and
those tools don't exist today.
dino: I think we need to define an animation between two paths of
any type.
dino: If what we come up with conflicts with what's about to ship,
defined in SVG1, that would be sad, but I don't think it would
be a horrible break.
dino: In general I think we should give authors a better experience.
TabAtkins: I think if we ship current SVG and then upgrade later,
it'll just make things start animating, which is a minor
break and probably fine.
shane: But also would change computed style - we'd want eventually
to normalize eagerly in computed style.
TabAtkins: Ah, that's more of a change than I thought.
<birtles> I think there's precedent for this with `transform` (i.e.
we define rules for animating between different types of
transforms and we also normalize to matrix() in computed
style)
<birtles> normalizing in computed style also makes parsing the value
a lot easier for authors
<birtles> there are a lot of SVG scripts hanging around that only
deal with the subset of path commands the author could be
bothered to deal with, since there are just too many
otherwise
fremy: I'd like to have Bogdan around.
shane: One of Bogdan's concerns was no use-cases; we completely
disagree. As soon as you try to path-animate, you run into
this. It's basically every single use.
shane: He also thought it might prevent them from doing certain
types of OS acceleration.
shane: We've implemented generic path animation before, it's more
expensive, but not something we should consider a concern I
think.
TabAtkins: I think B commands are significant - you get different
animation behavior whether you animate a B or resolve it
away. It seems useful to keep.
shane: I do think we shouldn't add or remove commands, just promote
to the most general.
shane: And then we could maybe have magic for when the number of
commands don't match, like transforms do with matrix().
shane: We have an impl of that, and it works pretty well.
astearns: So should we resolve on the abs/rel normalization today?
RESOLVED: Computed-value normalize case of path commands (to the
absolute version).
astearns: And it sounds like we're interested in normalizing similar
commands, but don't yet have consensus on details.
shane: Should we open something on the CSSWG tracker?
astearns: Yes.
<myles> shane: if you make a new issue, can it include videos for
things like that TabAtkins was talking about with the
bearing commands?
<shane> myles: for sure
<shane> or at least code demos
astearns: Anyone object to the general idea of normalizing similar
commands?
RESOLVED: Figure out details on normalizing similar commands into
more general ones.
Received on Thursday, 5 October 2017 18:26:09 UTC