- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 17 May 2018 03:31:58 -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.
=========================================
CSSOM
-----
- RESOLVED: For elements not part of a tree or part of a detached
tree they return no computed styles (and by no computed
styles, we mean empty strings). (Issue #1548)
- RESOLVED: Elements not part of a flat tree return no style for
getComputedStyle. (Issue #1548)
- RESOLVED: Regardless of what window you obtain the
getComputedStyle function from the origin of the style
is where ever the element is. (Issue #1548)
- RESOLVED: getComputedStyle returns none for elements part of
non-rendered iframes. (Issue #1548)
- RESOLVED: getComputedStyle for pseudo elements that are not
::slotted (or similar future things) is supported.
(Issue #2139)
- RESOLVED: Throw on invalid pseudo elements. (Issue #2139)
- RESOLVED: Add emilio as an editor of CSSOM.
CSS UI 4
--------
- RESOLVED: Add input-security: auto|none in UI 4 and applies to
input type=password only. (Issue #2495)
- The group decided to restrict only to input type=password for
now, but intentionally picked the name input-security so
that this property can be later extended to other input
types if necessary.
CSS Timing
----------
- RESOLVED: Have keywords be jump-start, jump-end, jump-none,
jump-both (Issue #1680)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule
Scribe: dael
CSSOM
=====
Rossen: Let's resume
window.getComputedStyle() on detached subtrees
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1548
emilio: While I was doing the styling stuff it became unclear and it
became obvious that each browser does something different.
emilio: FF does if you go across document it's sometimes across
document, sometimes the ones attached to that doc. We should
decide how it should work.
Rossen: In your issue it's detached sub trees.
emilio: Spec says whenever you call window.getComputedStyle() on a
document it says you should only get values in that window.
TabAtkins: I'd rather say they don't have a computedStyle.
emilio: Yes, you can't do it on an iframe. If you break that the web
breaks. There's 3 cases. Element outside doc, computedStyle
cross-document.
TabAtkins: Also shadow DOM. If it's detached, no style. If it's in
an iframe that happens to be detached we can discuss. The
others have no style.
TabAtkins: The flat tree case there's nothing to inherit from.
rune: But for not slotted and fallback for slotted?
TabAtkins: Yeah.
rune: I don't know what is a sensible choice.
TabAtkins: String parameter.
fremy: For us it's work. Anything that's not tree I think it's
reasonable to say don't render a style. All the use cases I
have are internal and we don't need the API. For the API, on
elements outside the tree can return no style. Still want it
to work within documents. Spec requests if you call
getComputedStyle from one window to another you have to get
the values from the other window.
TabAtkins: spec bug
fremy: We don't want this. If we try and run this we get the wrong
document. If you call getComputedStyle() you get the values
for the document of the element for which you called.
TabAtkins: Agree.
Rossen: Separate issue, though. Back to this one. What do we return
on elements not part of any document?
Rossen: In Edge we go through pains to try and calc what it should
have been and it's a pain. We'd rather return some stock
style with initial values or not return anything.
emilio: Makes sense. I think we can switch FF for non-iframes
because we have architecture that prevents us from this for
iframes.
TabAtkins: I'd like to know more why you think web compat on iframes.
emilio: Blink returns style of actual document. But you can't say
there's no style.
dbaron: Gecko has had security bugs about getting confused about
styles between doc.
emilio: When we know we're in the mess we're now consistent.
TabAtkins: Boris mentions iframes. What's the next best thing.
emilio: Computing style from the window.
TabAtkins: Returning some styles is required for web compat.
Rossen: But a stock style with initials...
emilio: Might not work.
emilio: Still talking cross document? Detached sub trees returning
no style works.
TabAtkins: Detached element or one in a detached sub tree should
return no computed styles.
rune: Boris mentioned...
Rossen: One at a time.
Rossen: For elements not part of a tree or part of a detached tree
they return no computed styles
Rossen: Objections?
RESOLVED: For elements not part of a tree or part of a detached tree
they return no computed styles.
<astearns> (and by no computed styles, we mean empty strings)
Rossen: next.
TabAtkins: An element not in the flat tree.
emilio: Either return no style or return from the default.
Rossen: Reason to do that?
emilio: We don't ship shadow dom.
rune: Blink does the same.
TabAtkins: Let's do it. No style.
Rossen: Elements not part of a flat tree return no style for
getComputedStyle.
emilio: You sure Blink does that?
rune: Not in the flat tree, you get parent value which is null.
rune: If not we should fix it.
Rossen: Objections?
RESOLVED: Elements not part of a flat tree return no style for
getComputedStyle.
TabAtkins: Calling getComputedStyle from one window on an element
from another document should return the element's normal
styles.
TabAtkins: If we decide later we needed it we can change.
fremy: That's what we do.
TabAtkins: Regardless of what window you obtain the getComputedStyle
function from the origin of the style is whereever the
element is.
Rossen: Objections?
RESOLVED: Regardless of what window you obtain the getComputedStyle
function from the origin of the style is where ever the
element is.
TabAtkins: Next is a display:none or detached iframe or elements
inside of it have a window they can hit and a styling
context, but are not being rendered. In this case we have
to return something, we can return all initial.
Rossen: I think last time we tried this someone...FF or
Blink...returned stock style.
emilio: I suspect returning stock style is not going to be web
compat. jQuery used to create display:none iframe and point
computed style there and it wants to know the default style
for a div.
fremy: I think no change.
emilio: There's a question of how MQ are resolved.
TabAtkins: All MQ are false.
fremy: I don't remember what we do. I don't think it matters for
compat.
smfr: I have this memory that browsers are going up the render tree
for a display:none iframe. Don't ads create them?
emilio: Gecko doesn't do anything like that. I think blink doesn't
create render trees.
smfr: Yeah, we created some optimizations.
eae: We've gone back and forth. We've tried to create it, but we've
gone back and forth.
smfr: getComputed Style may have created a render tree.
eae: We don't do that today and haven't had a reason to revert that
decision.
smfr: I'm not objecting, but I think there's compat. Long term I
think we all agree.
Rossen: We've held the display:none hammer for a long time.
Rossen: If you guys are doing it then it should be web compat.
eae: Too early to tell.
Rossen: If we spec it would be that display:none iframes return
nothing?
eae: Yeah.
emilio: iframes that are not in the document? I guess they have no
style.
Rossen: They shouldn't.
emilio: So display:none iframes and iframes not rendered in the
document.
Rossen: They're elements that are not part of anything. That they're
iframes doesn't make them less of an element.
Rossen: I think what you raised is for the subtrees inside iframes
what do we do.
emilio: FF has an API that we added for jQuery. We tried to remove
it and failed because calling getComputedStyle on an iframe
that's not rendered.
Rossen: So there is a compat issue.
emilio: I suspect it's still the case.
Rossen: Proposal?
emilio: I'd love to say we don't return style but I don't think
that's realistic. I think all browsers return.
Rossen: We do. We go through serious pains to compute styles in all
situations and we want out. If there's a compat reason for
jQuery
emilio: It's an old version of jQuery.
Rossen: Plenty still use older jQuery, though.
emilio: If someone wants to try not returning style on iframes and
see what it does that would be nice.
eae: I don't think we've shipped not returning styles.
Rossen: From behavior PoV returning none makes most sense. We can
try and spec it and based on impl feedback we might come
back and say compat blocks this and we need to revisit.
emilio: And if we do we have to define MQs. If people are willing to
try this works.
Rossen: Prop: getComputedStyle returns no result for elements part
of display:none or detached iframe
emilio: non-rendered type iframes
Rossen: Prop: getComputedStyle returns no result for elements part
of non-rendered iframes
RESOLVED: getComputedStyle returns none for elements part of
non-rendered iframes.
Rossen: Anything else on this issue?
getComputedStyle only supports ::before/::after
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2149
gsnedders: getComputedStyle takes a second argument we could pass a
pseudo element. Spec doesn't agree with implementations.
It only allows some pseudo and impl allow any.
gsnedders: What do we do when it's invalid?
* gsnedders hasn't looked at this issue in a while
TabAtkins: Seems that we should support ::first-letter and
::first-line, but I don't see why not all.
emilio: Except ::slotted.
TabAtkins: Yeah. We do still want some sort of magic thing.
TabAtkins: Slotted is first case of a pseudo being an alias for 1 or
more elements. Aliases wouldn't work from this sort of
example.
TabAtkins: We should probably make a term for things like ::slotted
and things not like ::slotted and say it works for all
things in that category.
Rossen: Currently it should work for non-slotted pseudo elements.
TabAtkins: Yes.
TabAtkins: I need to make it into 2 categories where slotted is only
one in the second currently.
Rossen: Reasonable. Other options or objections?
RESOLVED: getComputedStyle for pseudo elements that are not
::slotted is supported.
gsnedders: What to do given an invalid pseudo element? All browsers
return a css style declaration. FF throws if you try and
access a property, everyone else returns the element
style declaration and ignores the pseudo element.
TabAtkins: Returning element styles is... there's no reason to do
that. Throwing would be best.
gsnedders: Nothing does that. So can it be web compat?
TabAtkins: FF doesn't let you touch it. Unless there's code to
getComputedStyle and not do anything I suspect we can
throw.
fremy: Empty strings?
gsnedders: Reasonable. I'd prefer try throwing.
TabAtkins: At gCS call time.
ewilligers: incl slotted?
TabAtkins: Yeah.
Rossen: Do we throw for non-elements?
emilio: Yes.
Rossen: So this is not different.
TabAtkins: We're trying to say do the same.
Rossen: I'm trying to align whatever we do in that situation we
should do it for this situation.
fremy: If people call getComputedStyle with a placeholder we'll
throw.
emilio: blink claims to support all elements at parse time which is
weird.
fremy: [missed]
emilio: Does gCS webkit get a result now? I guess not.
fremy: They work in Edge and Chrome they return.
emilio: gCS in ::webkit-foo
fremy: I think that's why we return the element style. People do
random things we don't support and since Chrome does
something we do something.
fremy: I'm fine saying we should throw but I won't be first to impl.
Rossen: In terms of defining behavior the most sensible thing is
throw.
Rossen: Objections to that proposal?
RESOLVED: Throw in this case
Editing
-------
astearns: Question is who makes edits. We need editor.
TabAtkins: I could edit this in, but not be an editor.
astearns: Anyone? emilio?
Rossen: Editing the OM spec.
emilio: I could give it a shot, but I haven't done much spec editing.
TabAtkins: Ask me for help.
Rossen: Objections to adding emilio as an editor of CSSOM
RESOLVED: Add emilio as an editor of CSSOM.
CSS UI 4
========
Obscuring text for `<input type=password>` styling
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2495
myles: Currently input type=password has at least 2 different
behaviors. One is password managers use this to do autofill.
Another is the text you see is obscured. We'd like to
separate those things because we've seen content stop using
input type=password because they want to control the obscure.
myles: Means password managers don't work.
myles: We'd like to split this. In the thread suggestion is to use
text-transform so you can have a text-transform to say please
obscure. Seems reasonable way to achieve this.
florian: Alternative was a dedicated property.
TabAtkins: If text-transform is used any existing password-inputs
that have the text-transform applied would become
unobscured.
TabAtkins: Might be small enough to not matter.
myles: I don't think we're married to a solution. But we could
handle that case separately.
florian: Wouldn't that defeat the point, that people want to remove
it so we want to allow people to not apply.
fantasai: You apply in UA stylesheet and text-transform:none turns
it off. This breaks inheritance already.
emilio: Should we say only some kind of elements it applies to?
fantasai: text-transform option it applies to all. A separate
text-security property you can say it's only that.
emilio: I'm not sure how easy it is to input.
tantek: Additional use case in the issue mentions spoilers. We're
seeing that with content warnings. text-security property
might be worth exploring. The cow path here is webkit
introduced a new property for this, it's another data point.
myles: We're interested in a solution we can all agree to.
florian: An earlier point, if we do this through text-transform we
want to allow them to use this value on other and do it on
password fields. But if you accidentally do
text-transform:uppercase to a password field you unobscure.
Is that rare enough it doesn't occur?
<dbaron> I'm glad that <input type="text" style="text-transform:
uppercase"> works today, as shown in
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cinput%20type%3D%22text%22%20style%3D%22text-transform%3A%20uppercase%22%3E
tantek: Even if it's rare the bad side is too high.
myles: Could accept a set.
fantasai: Wouldn't fix the problem.
dbaron: If UA style sheet has obscure on input type=password I think
it's low-ish. Also given how mobile works I don't think it's
horrible if someone messed that up in the past. In mobile
you can kind of see the password.
richr: Interaction we're talking about is some way of showing the
password I just typed in. Strikes me that's a feature that
should be built in by the browser.
fremy: That's what we do.
myles: Impetus for this whole thing.
fremy: We already do it and it's better then if you do JS. We make
sure you can only do it if it's not auto fill. We do it
better then any property could. But I'm not opposed to saying
if you have input type=pin you can't want that level of
security.
florian: Authors are doing it because most browsers don't have this.
myles: We're bringing this up because it is happening today.
fremy: If we're talking about changing browsers it's an option.
It'll stop completely. It gets the feature that people want
and I'm puzzled other browsers don't do that.
fremy: I agree why not spend the time to have this code. Then
authors won't need to do this.
plinss: Raises an issue that there are number of controls where if
people show the password button and if browser gives it we
should be able to remove it.
Rossen: When we originally shipped you can detect if the action is
visible and based on this don't show yours. Or hide ours and
put yours. We do the same for search.
tantek: Supports can detect.
Rossen: In the beginning we had silly cases with two xs. People that
cared either used ours or theirs. In either case nothing
else needed. For what fremy said in the beginning for all
the pre-auto-fill you can't show. So if I come to your
computer and go to facebook I can't see your password.
plinss: For me using extensible web manifesto it would be ideal to
have a mechanism to control and expose these features and
then have css properties to set. Something you can polyfill.
florian: You said some authors hide yours and use theirs for theirs,
having the property would be useful.
plinss: Let's explain native behavior we've had by css properties.
Let's control the hide and pretend it's always on in the UA
stylesheet. Let's build it from what we have.
<rego> it seems text-transform is not inherited in <input>:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5886
myles: Question on Edge impl, one common UI is to show the character
after you type for 100ms. Can you do that?
Rossen: Yeah. Behavior you described we have for mobile when you're
on touch. Idea is you're typing fairly slowly. We don't have
it on by default. Feature is supported.
myles: Desktop?
Rossen: That's not exposed.
tantek: You don't want that responsibility on the website.
Rossen: We're not going to let people fiddle with our settings.
myles: So WG says make better password fields?
plinss: I think we need CSS to make those better out of CSS so other
authors can reason with it.
tantek: We want authors to use input type=password. That hooks into
password managers and such like so authors can impl show me
your password. For authors to turn input type=text into a
password field, I don't want to do that. Because then you
can't hook into password managers.
plinss: I don't think we want type=text to take a password but we
want type=password to be better.
[someone mentions credit card pins]
fantasai: Wanting to obscure input type=number...
you don't want the spinner in this case anyway, you just
want to restrict input to digits and there's ability for
that already. You use type=password and restrict to
numbers.
plinss: Points to a flaw in input where type=password should be
orthogonal to data type. I should be able to put in a number
field that asks like a password.
tantek: And then you end up with a new attribute to the dom.
plinss: I think it should be done, not here.
TabAtkins: Request to have password be manipulatable, given what the
browsers attach it should be a separate text-security
property.
plinss: And you might want an obscure with count of characters in
the future.
<tantek> or obscure WITHOUT count of characters or implied number of
characters (one "dot" • per pw char)
fantasai: Issue with this. If we're giving the author ability to
make password field no longer obscure we run into fremy
problem where you auto-fill a password and that becomes
visible.
TabAtkins: If you have physical access to a computer then you own it.
myles: It's an argument for not text transform so the browser can
say it's a property and it's auto fill so we'll obscure
anyway.
TabAtkins: Text-security
fantasai: No effect on anything other than password.
TabAtkins: Yes. We'll handle spoiler case differently.
myles: We want this only to apply to password related things.
tantek: Related use case.
florian: Spoilers are reasonable for text-transforms.
<tantek> no, spoilers are not reasonable for text-transform
plinss: We can remove restriction later.
myles: inherited I guess.
fantasai: If it's inherited you want it to not ever expand in scope
because people will set at root.
tantek: UA could still override it.
plinss: If someone turns on text-security at the root and expect it
to inherit, if we expand you obscure the whole page.
TabAtkins: This isn't for spoilers. This is to invoke UA password
mechanism. It's for passwords.
smfr: And also not affect placeholder text, just password content.
Rossen: Which we all support.
tantek: We need to spec it's only for password inputs.
all: yes
fantasai: Why aren't people implementing by switching type to text
and back?
tantek: Have you tried?
smfr: Password fields have special behavior, switching may have side
effects.
myles: Not inherited?
TabAtkins: If it's inherited it won't do anything.
myles: Spec?
TabAtkins: UI
fantasai: I would say initial value is what browsers do by default.
Why would UA style sheet set it?
TabAtkins: That's true. We can make it inherit.
florian: I don't think it should be.
TabAtkins: What's cheaper? Not. Make it not inherited.
myles: New property with auto and 'do not obscure'
tantek: Name is text-security
myles: text-security auto|??
florian: none
tantek: Make it obvious.
fantasai: visible and hidden?
myles: Always visible.
tantek: You might want to obscure the number of characters to plinss
point. You can have different variants in the future.
florian: We need to name adequately.
plinss: Auto is a good set up. None is fine for show as if there's
no security.
myles: We're satisfied.
tantek: What's the webkit value?
myles: I'll look.
fremy: If it's only password I'd like it called password-security.
fantasai: Makes sense.
tantek: Intent to broaden later?
<fantasai> password-visibility: visible | hidden
Rossen: It's such a specific feature tied in to so much internal
logic so we want to have the ability to circumvent all
complexity and let authors toggle. I think keeping it
specific makes sense.
myles: Webkit, our implementation accepts disc, circle, square, none.
TabAtkins: That's the 3 bullet styles.
tantek: Why have the 3 styles?
myles: I don't think we should read into the design of this.
tantek: So auto?
<TabAtkins> password-security: auto | none
myles: password-security: auto|none
fantasai: What does none do? Other effects then what it looks like?
<astearns> +1
tantek: It sounds semantic, not visual. It's an argument for
text-prefix.
<leaverou> Would this work on other elements too?
<TabAtkins> leaverou, no, this is just for turning off password
obscuration
<leaverou> TabAtkins: So it would do nothing when applied on
<input />? That seems a bit confusing.
fremy: We want to enable copy and paste.
tantek: You don't want to enable copy/paste
TabAtkins: Why not?
plinss: If you can see it you can copy. What's the harm in control-c
<tantek> that seems like a bad idea from a security perspective
Rossen: password-security:auto|none
plinss: Maybe input-security?
plinss: Passwords, PINs and CVV are commonly secured. Social
Security Number.
leaverou: Bank account.
myles: Treating those as a password is okay
leaverou: Then browser offers to save.
tantek: You don't want password type for CVV.
dbaron: I get asked that a lot.
myles: I think that's a feature.
leaverou: But then it overwrites your password for the site.
myles: Use a better manager.
fantasai: Do you want SSN in auto fill or password manager?
tantek: And now it's something password like again.
plinss: There's policies about not retaining CVV for example. Let's
not get into health and medical laws. Something slightly
broader then password is reasonable.
fantasai: secure-text
myles: We have one proposal and a wish.
plinss: input-security
<leaverou> text-redacted?
Rossen: Say it's only for input type=password only. If we need to
extend it we may.
Rossen: input-security: auto|none
Rossen: Objections?
cbiesinger: non password fields?
Rossen: Only input-type password.
Rossen: Let's re-cap. We are designing a feature which will allow
people to reveal or hide characters in an input
type=password element for now. There have been suggestions
that type=password might not be the only type people want to
hide information on. CVV and credit card numbers are common
input form elements that want to obscure or not. Currently
all browsers obscure input type=password and we want this to
work. That's why we started with password-security
Rossen: Because other applications we wanted a door and say
input-security: auto|none if we want to allow this in the
future on type=text. That's the reasoning behind the naming.
I agree with you for now, and we're going to specify it's
password type only for now and if we change out mind there's
a way out. If we don't the name isn't too terrible. It does
have a bit more meaning.
<tantek> I've also seen bank web UIs obscure *part* of "normal" text
inputs, e.g. only showing first 3 letters of username (
obscuring the rest), only showing last 4 digits of a credit
card number (obscuring the first part)
<tantek> I prefer input-security or text-security over
password-security
<tantek> to allow sensible expansion to other non-pw inputs
myles: Auto is just whatever is normal.
leaverou: Security in the name seems weird for newbies, you're
opening a security hole in the website.
Rossen: That's what you're doing.
myles: Cool.
Rossen: Objections to input-security: auto|none in UI 4 and applies
to input type=password only
RESOLVED: Add input-security: auto|none in UI 4 and applies to input
type=password only.
<TabAtkins> (Well, it will apply to "password inputs", defined by
the host language; HTML only defines <input
type=password> to be that.
CSS Timing
==========
Names for keyword arguments to steps timing function
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1680
TabAtkins: Previous F2F we accepted behavior that if you say 4
frames you get start and and intermediate or just
intermediates. We didn't name them. Last comment in the
thread we have names.
Rossen: We didn't?
TabAtkins: Nope.
TabAtkins: Diagram in the last comment has my suggestion.
TabAtkins: skip-start and skip-end as well as skip-both. We're going
with skip over drop because birtles argued that it seemed
like if you had 10 frames you'd get 9.
birtles: When you use this for backwards fill you don't drop the
initial value for visual effect and you don't skip either.
TabAtkins: Outside bounds of the transition.
birtles: It's in the animation.
TabAtkins: I don't think it's possible to address that without a
short sentence in the function.
birtles: It's prefer inside and outside and have frame areas.
TabAtkins: We decided no separate function at the time. Revisit?
birtles: Thinking further issue is what the number represents.
Flat bits (pauses) or vertical bits (changes)?
TabAtkins: Values across transition.
birtles: Can we have frames represent the bits and steps number
inside and outside and number is jumps.
TabAtkins: If we have frame why more behavior to steps
birtles: I think it's [missed] to switch between the different
modes. You might want to change keyword.
TabAtkins: I'm doubtful. If we keep steps being number of jumps
going from start to inside or outside means the timing of
the things change. When the jumps happen change
completely. That's why I said if we do this we can't
interpret the number as being jumps.
TabAtkins: That was the gist of my argument the last time we
discussed. It was a mathematical way to look but not
human centered.
birtles: I think you're right. Wondering if we can keep steps
meaning number of changes and adding frames.
TabAtkins: We could in theory. If that does something useful. I was
not thinking it was useful enough.
birtles: Little easier to understand.
TabAtkins: If you switch steps to refer to number of values it's the
same meaning across. In diagram at the end value is
number of things you see during the transition.
Rossen: One of the main objections from Amelia and Rachel N. was
when you say steps 3 and get 2 frames.
birtles: When you go one mode to another having to change the number
is confusing. So when you want frames and animation hits
last frame and we end it. The frames approach is step end.
If you want a different effect and you have to change the
number is confusing.
TabAtkins: Can you give details on start and end?
birtles: You've got a countdown 10-0 and you have a image with the
numbers and you shift image along. You've got frames for
each and steps. 10 skip 9. Then when it hits 0 it triggers
something else. So you want steps end.
TabAtkins: Still counting down from 10 you want 10 steps. Your end
value would be 100% where the 0 frame would show up.
birtles: I think that you have to do is change the number past the
steps to get that difference.
TabAtkins: I'd like to see an example. I don't see changing the
number. Still 10 values, but when the transition is done
you end up at a 0 one. If you add a 0 there's now 11
frames so you have to change the number.
Rossen: Can you help us with what we're trying to resolve?
TabAtkins: Based on thread status all we needed to resolve is
deciding on names.
Rossen: We resolved to use steps with int = number of visible
frames. Only thing to resolve are the names for the 4
keywords.
TabAtkins: That was the status as of August last year, but birtles
is revisiting the resolution.
birtles: I'm not sure it was the right decision.
birtles: If we're just deciding names I still have a concern about
skip because you see the first frame.
TabAtkins: Not during the transition. You don't ease the value
outside the transition either.
TabAtkins: I agree drop was misleading. Skip is possibly misleading
but less so.
Rossen: Other suggestions?
<Rossen> jump-start
<Rossen> steps(3, jump-start)
smfr: skip-none is the default?
TabAtkins: skip-end unfortunately.
TabAtkins: Part of the justification for a separate function was
this. We had settled on steps. We can review, but I'm
happy sticking.
birtles: I think it's the case where you want to keep step height
the same?
TabAtkins: Amount of transitions between each frame
birtles: keep height of steps same....
TabAtkins: Andres' example at the bottom, they all have the same
height.
birtles: That was the concern if you want to change between
something that triggers the moment it's the last number vs
waiting until you get the last number. That seems a little
unfortunate.
TabAtkins: That's because only 9 are in the transition.
birtles: When we had the project it's awkward to explain go from 11
to 10.
smfr: I would expect steps to be number of vertical dotted lines.
TabAtkins: But that doesn't match a number of authors understanding.
We had that discussion and resolved a different way. We
can re-discuss. Original remaining item was to name. We
can go as deep as y'all want to do.
birtles: start-skip vs start and end alias
TabAtkins: I'm doing alias for consistent construction. start and
end by themselves are kind of confusing.
Rossen: Anyone coming around on this?
TabAtkins: Do people want to re-litigate? If not let's name.
birtles: Only alternative I'm interested in is aliasing a separate
function so number of steps always means number of vertical
rises and a separate function for number of values. If
you're not interested in that we can resolve.
Rossen: I'm hearing no one is willing to re-litigate.
Rossen: Remaining thing is can we live with those names.
ewilligers: If you're outside the us jump-start makes more sense.
TabAtkins: I'm okay with jump. There's a jump at the start or the
end.
Rossen: So jump-start has become a thing?
TabAtkins: Let's do it.
<TabAtkins> jump-start/end/none/both
Rossen: Proposal: Have keywords be jump-start, jump-end, jump-none,
jump-both
RESOLVED: Have keywords be jump-start, jump-end, jump-none, jump-both
<br type="lunch">
Received on Thursday, 17 May 2018 07:32:59 UTC