W3C home > Mailing lists > Public > www-style@w3.org > May 2018

Minutes Berlin F2F 2018-04-11 Part II: CSSOM, CSS UI 4, CSS Timing [cssom] [css-ui-4] [css-timing]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 17 May 2018 03:31:58 -0400
Message-ID: <CADhPm3vYwhLZithE27tTJH8ER+kogkB=KkfhapjXx717g797pw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Thursday, 17 May 2018 07:32:59 UTC