Minutes Paris F2F 2015-08-25 Part II: CSSOM 2


  - shane presented the basic proposal for a CSSOM 2 which included
       a typed replacement of CSSOM that exposes types of CSS to
       JavaScript and handling of lengths and numbers.
      - It introduced several new properties including 'get',
          'get-all', and append for lists.
      - Validation of numbers was an unsolved concern, but there was
          an indication that clipping should be done at validation
          time to address junk strings.
      - There was concern that the property names and handling of
          value objects were just too long.
      - It was thought that TabAtkins' proposal for handling value
          objects was in general better, but his proposal needs to
          wait for JavaScript to support value objects and therefore
          this was needed as a stop-gap for the next few years.
      - Several people expressed an opinion that since this spec is
          transitional until value objects are available, it should
          focus on making basic tasks simpler and therefore be worth
          the implementation cost.
      - The spec should also be designed keeping in mind that value
          objects are coming and this version should be explicitly
          designed to ensure that they will work with this API.
      - There was also a lot of people interested in making
          ergonomic improvements in this spec.
  - RESOLVED: ED for CSS-Typed-OM with gregwhitworth, esprehn,
              TabAtkins, and shane as editors.


  scribe: dael


  Rossen: Let's resume
  shane: We re-ordered to get more concrete topics first.

  <shane> https://lists.w3.org/Archives/Public/public-houdini/2015Aug/0004.html

  shane: This one is CSSOM 2. A pretty way to describe it is a typed
         CSSOM replacement a way to expose types of CSS to JS. We'd
         like to do this because in the explorations we've found to
         softest part of any custom pullout is converting the
         strings out of CSS into typed representations and stuffing
         them back in the element.
  shane: This e-mail is a rough API and I wanted to go over it.
  shane: The StylePropertyMap. The first to notice is this is almost
         map-like. There's 'get' that gives you a start value and
         'get-all' that gives you all the values.
  shane: The CSS WG has a tendency to promote properties to list
         value and we don't want to do that. If we give you a 'get'
         you can find out about just one property.

  <leaverou> Personally, I think TabAtkins’ proposal from a while
             ago is more elegant http://www.xanthir.com/b4UD0 though
             less complete, presumably
  <TabAtkins> Mine *is* more elegant, but it's also impossible right
              now. This is a stopgap, rather than waiting for, in my
              estimation, 3+ years.
  <leaverou> TabAtkins: the parts of it that don't depend on value
             objects are also more elegant
  <TabAtkins> leaverou: I'm much more in favor of a Map interface;
              it actually works with custom properties, for example.
  <leaverou> I really like this re:list values, much better than
             handling everything like a collection and requiring [0]
             to get the first value!
  <TabAtkins> leaverou: And it extends to MultiMap easily; my
              proposal did handle this problem, but in an imo
              clumsier way (the .l property)

  SimonSapin: Do we do that for properties that were already lists?
  shane: Yes. This would be anything.
  dbaron: So when something is a list value you will only get the
          first with 'get'?
  shane: Correct.
  shane: That's convenient because background is a list value, but
         90% of the cases it's a single value.

  Florian: Thinking back to the editing TF, the presence of an API
           that can only give you the first value indicates that
           people don't care about getting more so the idea is give
           me an iterator so there's an idea of there's more to come.
  shane: That's not a bad idea. We should think over that. That's a
         good alternative to fix this.

  shane: 'append' puts the new rule sequence at the end of the
  shane: This gets complicated because it repeats both style rules
         and computed value so this appends to the end of the start
  dbaron: For computed style?
  shane: It possibly does the same thing as 'set'.
  shane: Sorry, for inline style. Computed style it does nothing.
  shane: The e-mail I sent had computed and spec style separated,
         but we talked about rolling some of that up, but it may may
         sense to keep it.

  SimonSapin: Does 'append' append a new value to a list value
  shane: Yes.
  shane: No.
  TabAtkins: Yes. When you append one, it puts it at the end of the
             property. This is the multi-map interface that DOM has
             forged for coring parameters. We have one weirdness
             with set taking a sequential value and I'm not sure how
             to address that best.
  shane: Do want to make get return an iterator?
  TabAtkins: I'd like to keep it to a map.
  SimonSapin: What about properties that aren't list?
  TabAtkins: No option or throws. Going throwing to useful and no
             option then useful is both doable.
  florian: I prefer throw.

  heycam: So do you have to specify 'append' a comma?
  esprehn: All list is using a comma, so doing an 'append' adds a
  dbaron: We do have list values that don't have commas.
  shane: The list abstraction handles that for you. They're
         internally lists.

  shane: Another consideration is we can't just replace the existing
         access so we need a new attr to getting
         ComputedStylePropertyMap and a new on CSS style. This is a
         bit unfortunate having to have them side by side, but we
         can't think of a better way to do it.
  smfr: Are there contexts where StylePropertyMap will be redone?
  shane: Yep. We'll factor those into a sub class.
  TabAtkins: For the map-like interface...
  esprehn: Instead of having one StylePropertyMap it will go away
           and specify invokes a read/write. They're two traits.
  <esprehn> MultiMapReadOnly and MultiMap I think

  <ChrisL> did I hear that right? Element.style.margin ->
           Element.styleMap.getMargin ?
  <ojan> Element.styleMap.get('margin')
  <ChrisL> thanks

  Florian: Does the object reflect the change or do you get a new
  shane: The StylePropertyMap itself maybe.
  shane: Every value that comes back is a subclass of start value so
         we can have the basic values everything.
  zcorpan: In CSSOM we introduced attributes for getting cascade
           style and raw computed with is the real computed value,
           but they're CSS to CSS values. I don't think these are
           implementable. Would it make more sense to specify these
           as the map?
  TabAtkins: I think so.
  esprehn: In favor of this approach...it doesn't require object
           stability. Get style may be analogues. When you touch the
           style property we have to keep the element.

  leaverou: Why use get('margin')?
  TabAtkins: It looks like a map. The dashed camel case we use only
             works for CSS properties.
  leaverou: We can have trees that are anything.
  TabAtkins: It's not nice to force two different access patterns.
  leaverou: I think everybody does .foo because they're taught that.
            It's better if they can do it like they do it in CSS.
  TabAtkins: Maps in general are nice to pass in JS, but object
             value maps are clumsy in general.
  leaverou: Could we use ES6 proxies to handle properties that don't
  TabAtkins: Technically we can, but that's not good. These make it
             confusing when you mix map keys and methods. .get()
             gets you the dictionary keys and it's easy.
  shane: We can't be a multi map if we expose in the other way.

  leaverou: Having to type this over and over is tedious. Will there
            be helpers to set multiple properties?
  TabAtkins: I suspect they will evolve.
  shane: And you can continue using the old string map.
  leaverou: Ideally this shouldn't be promoting both.
  esprehn: Authors should use this.
  TabAtkins: The use of maps will get more idiomatic and easy with
  leaverou: If we use 'get' and 'set' we should be able to call .set
            with an objective multi property.
  TabAtkins: I'd rather let the ecosystem evolve and we can see how
             the usage plays out.

  shane: So this is the base stuff. I've sketched out a number of sub
         classes. This is for properties like z-index. We know from
         animation use cases you need to be able set opacities that
         are not valid.
  ChrisL: So you're going for late, rather than early, bounding and
  shane: I think I could prefer that.

  <leaverou> btw not sure if it's too early for bikeshedding, but I
             think element.styleMap is too verbose. Why not
  <TabAtkins> leaverou: Yeah, .css is nice. Tho, I kinda want to
              reserve that for the eventual Value Object version. ^_^
  <leaverou> TabAtkins: it's better to design this API in a way that
             can accept value objects in the future than change it
             again to an entirely different one. This is ridiculous.
             From .style to .styleMap to .css?!

  shane: So it's the question of where we do validation and do we
         want a separate type.
  Florian: What do you prefer?
  shane: I'd prefer a single node of value and to in general reduce
         the number of types exposed and do late validation.
  shane: I'd say for numbers and maybe all types should clip. We
         should be consistent everywhere.
  iank: And these objects aren't live, it can get the validated
        version back.
  smfr: It will make it hard to developer tools to warn when the
        author put in garbage.
  ojan: You can't set with the wrong type.
  smfr: But you can pass in a junk string.
  shane: When you pass in a junk string, you don't get warned. You
         might find out if you read it back. I'd like to do better.
         Especially if those are used in a restricted environment.

  Florian: So why do you prefer clipping?
  shane: There are other use cases where you don't want to clip. It
         will depend on...if you're setting an opacity that is a
         negative, that could be fine.
  Florian: But once assigned it has to be valid.
  shane: That's the point we should clip, when you apply.
  shane: The other one we sketched our was lengths.

  jet: Do we want percentage?
  TabAtkins: You can't not express percentage because the authors
             use them in the style sheets.
  TabAtkins: Often percentage is related to layout. We don't want to
             do weird layer crossing. We must return a percentage if
             the length is a percentage.
  Florian: Percentage isn't a sub type of length.
  TabAtkins: It is a sub type.
  shane: Maybe we have separate types or we try and keep those
         together. These are all details.

  heycam: This is similar to stuff we just worked out in SVG. One
          open issue that led us to remove it is what to do with
  shane: Let me take you through it.
  shane: This interface represents any kind of length. There's
         simple lengths, a single value, length keywords, and calc
         expressions. If you go at this level you can work with any
         of the three. They will do the appropriate things. They'll
         throw if you try and use them on a length such as auto.
  franremy: The length interface isn't enough for the values in the
            stylesheet. You cannot use variables inside.
  shane: Variables go higher.
  TabAtkins: When you're using a variable, we don't even know you
             are in a calc.
  <TabAtkins> Elaboration on "we don't know you're in a calc":
  <TabAtkins> width: calc(1 + var(--two) + 3);
  <TabAtkins> Oh shoot, never mind, you can't do that - vars require
              the parens to be balanced.
  franremy: So we can't use disappearing?
  TabAtkins: We need a different object type.
  franremy: So disappear is for the output?
  TabAtkins: If you use l.StyleMap.SetWidth you can set it to a
             length or a token string.
  franremy: Then you can't mix and match
  TabAtkins: As much as you can do anything. It couldn't be
             different than a property with two types.

  SimonSapin: The keywords accepted for length depend on property.
              How will this work in snap path?
  shane: It's something we need to decide.
  TabAtkins: We should validate values on setting.
  SimonSapin: You have em for length and a class hierarchy. How are
              they represented in JS?
  TabAtkins: We need nice pretty constructors.
  shane: The simple length sub class: if you want raw values you
         have to postulate it. That may not be the bes thing to do,
         but then you can read the value directly. Calc is a big
         dictionary of unit to value.

  heycam: Are the objects live?
  shane: No. This is another reason to use map rather than direct
  heycam: That was a main problem with SVG.
  SimonSapin: To explain more, in CSSOM we have this rule interface
              where objects can be more specific and to know which
              there is a type attr. In this case if I do width, how
              do I tell if that's simple or calc?
  shane: When you have a super and sub class relationship, how do
         you query that's it's a sub class?
  TabAtkins: That's a prototype. You can query with .proto
             instanceOf works as well.
  SimonSapin: The type attr in CSSOM aren't needed?
  TabAtkins: Yeah.
  <TabAtkins> (CSSRule.type is one of the old-style "numeric enums"
              identifying what type of rule it is. That's stupid,
              because JS has `rule instanceof CSSFontFaceRule`, etc.)

  <leaverou> This API is way too verbose and reminds me of Java. E.g.
             we’ve turned el.style.foo into el.styleMap.get("foo")
             for reasons that most authors will not quite understand.
             Instead, they will just blame us for being verbose and
             "why can't these native APIs be as short and elegant as
             the libraries I use?"

  shane: That's pretty much all we have. There's lots of details
         missing. There is lots of things to do. If it makes sense
         to provide dictionary-like access? What I hoped to get out
         of presenting this is an indication for if we should do
         this and if this is a good direction. And if it's good I'd
         like an ED inside the Houdini repo.
  Rossen: Do you have all these in a spec?
  shane: I don't, but I will if we want to proceed.

  dbaron: It feels a lot like the existing CSSOM which we all hate.
          I'm not confident it fixes the things we don't like.
  ojan: What don't you like? This fixes the things we don't like.
  TabAtkins: The things we don't like this ignores entirely.
  dbaron: I think there were a few related things. One was that
          whenever we did something new it was hard to map that into
          the existing OM. This probably improves that a bit but not
  Florian: Now that you're baking percentage into length, if we
           later need to do 20hx + 2timbl it wouldn't work.
  TabAtkins: When we add frequency we will bake that in.

  dbaron: The other piece was how verbose it was to deal with the
          value objects. You want to manipulate the px value of the
          background position and it's element.style.get(
          PropertyBackgroundosition).something else and another
          array and a getter and a px value getter.
  <TabAtkins> el.styleMap.set('width', el.styleMap.get('width')
  <TabAtkins> Rather than el.css.get('width') += 5px
  shane: If you're just using 'get' it'll be
         .get.BackgroundPosition.x and that's a value.
  dbaron: TabAtkins had a proposal for value objects that was less
  TabAtkins: Those are insanely optimistically 2 years out.
  TabAtkins: It'll still be some time before value objects and
             string parsing and serialization isn't a major
             performance hit. Even though this is verbose, the hope
             is this is a stop-gap. It's not ideal, I'd love to just
             have value objects, but we know strings are expensive
             and dumb.

  ojan: To give context, in iank's prototype of custom layout we
        hand waved a lot. His initial prototype was like 20x slower
        and the majority of that was parsing screens.
  TabAtkins: Later in his implementation he cheated, exposed the
             numbers directly, and that's when we got to 2x slower.
  TabAtkins: Anything with transform animation is string parsing
             bound and that can be sped up.
  esprehn: Since the objects are not live, you can keep a transform
           value that you keep mutating. You can just put in one
           value and call set again and again.

  leaverou: What if when people use length and calc they're treated
            as px? At least in JS it returns a number that can be
            used in any calc. If people don't call .px and they just
            add 5 to a length can it turn into px?
  TabAtkins: We can't return a number you can add to- we return an
             object. You're saying if we don't call px...
  heycam: One major impediment of this is that there are a couple of
          cases with non-intuitive results like if you use the 'not'
          operator it's always false. There's a couple of cases so
          in SVG we thought it was too confusing.

  leaverou: I agree this API is extremely verbose. Authors will hate
            this. Why can't we design a more concise API or one that
            does the reasonable thing in most cases?
  TabAtkins: We have designed a good API, but it's not available
             until JS adds value objects.
  TabAtkins: I'd be against adding a valueOf and pretend it's px
             because it's not predictable.
  <heycam> The worse example than the ! operator working on objects
           with a valueOf method is that doing a == of two objects
           with valueOf methods will check object identity, not
           compare the values.
  leaverou: In 90% of the cases people will use pixels.
  shane: Is that true?
  leaverou: Offset tall and offset width are px.
  shane: They always do and they're not in this API.
  leaverou: You use those in another API.
  TabAtkins: You want people to write code that assumes you return a
             10 when you get a number and it will throw when you use
             5em. It encourages brittle code. If you do 'auto' it
             can't be pixel. They're the most common, but not
             overwhelmingly common.
  shane: It's true of widths and lengths. The problem we have is
         hidden because computed is returning used.

  Rossen: All the API you listed are only returning used style.
  leaverou: So far it sounds like this will be used in computed
            style. Will we have something else for used style?
  dbaron: And there's property in the CSSOM draft that separates
          computed style and used style better.
  leaverou: If these values are used in computed style where you do
            have pixels you are able to resolve everything, but
            authors have to use .px. If we're going to replace this
            API, we're going to teach authors to use this until
            there's value objects and you'll have to learn something
            again in three years.
  TabAtkins: Yes.
  shane: It's an opt in.
  leaverou: It will be evangelized as the new CSS OM. And if it's
            not good enough to replace .style then...
  <tantek> so we're back to dbaron's point, why bother?

  dbaron: With the value API, we only have getters and not setters.
          If you want to do this, and we need to push this into CSS
          spec, every property needs to specify how it maps to
          values so that we can interoperably implement getting and
  ojan: That sounds good to me.
  dbaron: It substantially increases complexity of implementation.
          Probably it's a good thing.
  ojan: It increases complexity of speccing.
  dbaron: We'll have to implement the setters which is new.
  TabAtkins: Not computed style.

  heycam: I'm worried about author predictability without them
          having to look up the spec. With this talk about in this
          property it 'auto's to a length and so you can set it on a
          length but in this other one it's just a keyword, I don't
          want to have to guess and set these values.
  TabAtkins: You don't have predictability today. Whatever
             complexity this gives you get today in strings.
  heycam: I'm thinking about specific style.
  TabAtkins: That reflects as close as possible to what you put in.
  heycam: Auto on this prop acts like a length.
  shane: You can use auto string
  TabAtkins: We can be more ergonomic about what text values you
             accept so when you pass a length auto we can pass it

  <astearns> while a transitional API is unfortunate, getting a 10x
             performance increase seems to me to be worth the bother

  dbaron: One more thing I don't like, how do you get and change the
          x offset of the text shadow?
  TabAtkins: Complex objects, they will go one by one and figure out
             that it looks like.
  dbaron: So you'll have a JS with a color and x and y?
  TabAtkins: Yes. We do tend to turn previous complex values into
             sub properties. All complex values become almost sub

  leaverou: This might be too far from what we're discussing, but if
            we're going to replace this API eventually, let's think
            of where CSSOM is giving us trouble. It's a pain when
            you're manipulating colors because you have to parse
            yourself, it's a pain dealing with lengths. So since
            this is going to be a transitional PI, would it be
            easier if we just speced the few properties of the
            existing OM so you can have a few properties that just
            return the RGB of colors
  leaverou: So there's something they can use until we get the new
            API. We don't have to give them a complete set of new
  dbaron: The thing you describing is value objects.
  leaverou: They're retuning a dull string in the existing methods.
            I think it can have properties and still return a string
            given that the two strings...
  TabAtkins: It can't. We return primitive strings. People today
             depend on that empty strings are falsy.
  leaverou: Oh, yes.

  gregwhitworth: So is it so bad to spec with the value objects in
                 mind and if people are able to spec with that in
                 mind you can say we'll take the implementation cost
                 of switching over. We should be specing the desired
                 behavior in parallel.
  shane: The only reservation I have is relying on value objects of
         coming is a risk.
  leaverou: Can't we push for it?
  dino: Can't we push this? Why can't we make it happen sooner?
  TabAtkins: We can push for faster, but it's a long push.
  ojan: I think JS has bigger fish to fry like modules. Though that
        push would be good for us it wouldn't be good for the web.
  TabAtkins: There is an ergonomic cliff we fall off here. Value
             objects are a better UX but we can't depend on them
             happening fast enough since as our implementation
             experience shows this sort of thing is required for
             most of our APIs.
  ojan: This isn't just Houdini. This is when people try and do
        transform animations why spend a lot of time parsing and
        unparsing the string.

  shane: I'd like to explore making simple things easier.
  shane: Do you think giving a px number simply and when it can't
         throws, would that be helpful?
  leaverou: That would be terrible.
  shane: We can't give you a px unless it's always a px or we throw.

  Rossen: We're tying to explain the pipeline and one of the things
          is value tied. It has a really good representation of what
          the specified value is. In our implementation that value
          is used until it hits the cascade. We've internally
          computed them and it's a subset of four types: enum for
          auto etc, length in px, percent, and unknown.
  Rossen: If I'm implementing custom layouts and I'm working out of
          a style object that's supposed to be representing the
          computed value, I shouldn't see rem because to resolve
          that I have to do gymnastics.
  shane: At that point rem is meaningless.
  Rossen: If I take it further and start paint all I'm expecting
          after layout is pixel values. There's nothing else. That's
          why what leaverou is talking about, most of the authors
          are used to working out of the back end of the pipeline.
  Rossen: My question is, I definitely like where this is going but
          why are we not trying to expose the rest of the length
          values? Why can't we have specified, computed and used
  shane: We can. Computed we have to send back into used. They need
         to be in the same hierarchy.

  TabAtkins: One ergonomic improvement, in the common case you'll do
             a .get and .set. We can make that more ergonomic and
             make that less terrible, with an update method that
             takes a callback that gets evaluated immediately.
  <dbaron> Tab was describing an update method with a callback
  <zcorpan> TabAtkins can you type in irc the more ergonomic syntax
            you talked about?
  shane: We should keep an eye out for ergonomic improvements.
  TabAtkins: I suspect there's a lot of low hanging fruit.
  TabAtkins: Also, the generic length, that's important. In general
             you won't have to manually construct extra lengths.
             when you .get you can immediately perform some math on
  SimonSapin: If you call add with a string that contains 5px, if
              you do that you get the same problem with strings.
  esprehn: I don't think we want to add that. It should be ugly to
           force the string parsing.
  TabAtkins: We should still add the value. It also handles the I'm
             a calc now.

  SimonSapin: Is it possible that calling a method changes the type?
  TabAtkins: Yes.
  shane: No, it returns a new object.
  heycam: Why is that?
  TabAtkins: You .get, fiddle with it, and send it back in. If you
             want an explicit calc you do it piecemeal.
  <TabAtkins> For the purpose of minutes: we should probably have a
              .update() on the map too, which combines a get/set
              (though .update() is a Python dict method that's
              independently useful).

  shane: dbaron given your reservations, what should we do? Proceed,
         edit and work through, have you sit with us and discuss?
  dbaron: I'd lean toward proceeding, but I'm a little conflicted.
  shane: We can bail later.

  dbaron: I wanted to understand Rossen's comment about computed
          values a little better. Were you describing something
          where you'd get different value types in the leaves of the
          API or something more like what's in CSSOM now where
          there's different getters on the element for the different
  Rossen: I was describing different value types, how the different
          styles work.
  Rossen: ComputedStyle.get(width) would only return type value
          which is computed style. So if you have specific style
          you'll get this. My description was a hybrid of what's in
          CSSOM 1 with the type styles and off of those the values
          are also so you cannot mix and match.
  Rossen: At least that's how we handle it.
  shane: You have to go up to read a specific style. You need upward
  Rossen: You're only sub-setting as you move forward.
  dbaron: I like that, it has a bunch of advantages. It's also more
          complex which makes me hesitant.
  ojan: I'd like to see this in a discussion of where we'd expose
  Rossen: In custom layout I'd want to be working out of a computed
  shane: An API that lets you set rems and what the agent will be

  <leaverou> var w = el.styleMap.get("width"); w.px += 10; // would
             this work, or would it also require a .set()?
  <TabAtkins> el.specifiedStyle.set('width', el.computedStyle.get
              ('width').add(5, 'px')) is terrible, but...
  <TabAtkins> el.specifiedStyle.update('width', x=>x.add(5,'px')) is
  <TabAtkins> Well, there's that computed/specified split, which
              we'll have to work with. Hmmmmmmmmm
  <leaverou> TabAtkins: honestly, both are extremely verbose
  <TabAtkins> leaverou: Oh, sure, but again, *there's no way to fix
              that* until Value Objects.
  <TabAtkins> Eventually: el.specifiedStyle.get('width') += 5px;
  <franremy> TabAtkins: no, that would be el.style.set
             (el.specifiedStyle.get('width') + 5px)
  <TabAtkins> franremy: Nah, += will invoke .set()
  <tantek> Verbosity is the number #1 anti-pattern in the DOM
  <leaverou> Not sure I understand why we can't do el.specifiedStyle
            .get('width').px += 10; without value objects. Are these
            length objects immutable?
  <iank> Also the above example with the current API is:
         el.style.width = parseInt(getComputedStyle(el).width) + 5 +
  <iank> And hope that it is pixels
  <franremy> TabAtkins: I'm doubtful this could work. That would
             mean overriding the ".get(...) =" operator on the map,
             such that it can track an assignement to a value get
             from it; that looks far fetched to me. Did I miss
  <TabAtkins> iank: And that example (for today's code) is only
              *that* "simple" because 'width' is a trivial little
              property. Adding 5px to a shadow blur is no more
              complex in the Object code, but *way* more complex in
              the String code.

  Rossen: Is everyone okay placing this is a draft?
  leaverou: Can someone look at TabAtkins examples in IRC?
  TabAtkins: We know they are verbose. We can't fix it yet.

  tantek: Is this a higher performance API?
  plinss: Higher.
  tantek: In terms of introducing it to developers.
  esprehn: We expect it to be wrapped in libraries.
  tantek: I agree with leaverou's concerns.
  shane: If I choose between verbosity and performance....

  Rossen: There's one more thing that needs to be said, keeping
          focus on what we're trying to expose with Houdini,
          verbosity might be needed here. We want to attract the
          right level of developers who are writing middle term
  tantek: Verbosity makes for more copy/paste.
  TabAtkins: When less verbosity is only payable with large
             performance drops it's not worth it. We're trying, we
             can't do it.
  TabAtkins: We parse as fast as we can today.
  tantek: You can assume that all the browsers have been working to
          improve parsing string performance for 10 years.
  tantek: Another verbose syntax is not without its down side to the
  TabAtkins: This is a stop gap which we're not happy with but that
             we consider necessary to do other things.
  tantek: Then I suggest you advertise as high performance only.
  esprehn: I don't see why JQuery wasn't going to take this. It's
           one like for JQuery.
  tantek: I don't think that framing would stop the JQuery people
          from trying to do that. And the nice thing is they can
          experiment with less verbose.
  astearns: I question the utility of framing something as high
            performance to reduce usage.
  shane: I don't have a problem framing it as high performance.
  ChrisL: And the other branding was this is temporary and good luck
          with that.
  TabAtkins: We'll replace it, but we will have to keep supporting
             it. We'll be paying that cost forever.
  esprehn: It's not clear this will be temporary.
  ojan: We have to do this work for both versions. All of dbaron's
        concerns would apply to value objects, it's just that the
        ergonomics improve.
  tantek: Not just typing, but debugging.
  <tantek> I think part of the key with framing is to point out this
           is API is "higher performance" but wordier (and thus more
           awkward code). Be intentionally upfront about the self-

  ChrisL: I like the approach of using object and numerical values
          rather than messing around with strings. I'm slightly
          concerned about increases in verbosity and I remember
          people hated that about the SVG DOM.
  ChrisL: Another time we didn't stringify there were people that
          found significant improvements and that was on mobile. The
          issue was spending 90% of your time parsing strings. I
          like your idea of maps. Having to say .get and .set,
          people are going to react and say why do we have to say
  shane: If we do .thingIwant people will also react negatively if
         it doesn't work.
  ChrisL: We've got this thing that is a number and unit, so can't
          be treated like a simple number, but we're stuck.

  Florian: I'm concerned about this massive bikeshedding.
  TabAtkins: This will be somebody going through every property to
             write them down. A few things will need to be resolved.

  leaverou: If you had proper properties, if you set it to an number
            it's a pixel.
  shane: Style.color.red +=15 That can't work.
  TabAtkins: Not now.
  leaverou: So why?
  shane: You're not setting on the object back into the interface.
  shane: You can mutate but it doesn't set it in. When you use a map
         objects aren't lone objects.
  TabAtkins: When you pull it's no longer connected.
  leaverou: And that's performance?
  ojan: Performance and implementation complexity.
  shane: And SVG stepped away from that.
  heycam: It has caused security bugs. It's hard when you have 3
          levels of live objects.
  leaverou: Having an API that's performance optimized is great, but
            having one that's good for usability is also great.
  shane: That's a fair point. The performance is the high priority.
  esprehn: I think usability is also subjective.
  leaverou: It is when you're undefined. It's not reactJS developers.
  esprehn: It is. We should give them something they can use.
  leaverou: I thought this was the same target group as CSSOM.
  <tantek> agreed, who is the target group?
  shane: I think this is not for entry level devs. This is for
         people with performance issues using strings.
  leaverou: I think that's the fundamental misunderstanding. This is
            for authors that have the issues with the parsing.
  Florian: This is coming through Houdini and that's for people
           trying to replace grid layout and that's not beginners.
  shane: The best thing for beginners is wait for the the value API.
  tantek: I think we need to be upfront about that framing.
  tantek: As to the usability being subjective, I think we've got
          enough data of people preferring the succinct syntax that
          there's data about simplicity.
  esprehn: The reachJS devs are saying what we designed is wrong.
           Before and after, they want intelligent DOM diffing.
  TabAtkins: Like .closest which is a JQuery idiom.
  dbaron: It sounds like you're arguing because we fixed one
          usability problem and they have a different one the first
          isn't a usability problem.
  TabAtkins: Going too far in let's make this super convenient as
             possible, that's super subjective.
  shane: Usability is undeniably important. I think if we frame this
         appropriately, tantek you're okay going forward?
  tantek: Yeah. I don't see another choice.
  dbaron: I don't want to agree now that we'll have a 3rd CSSOM for
  TabAtkins: In the future it would be an independent decision.
  dbaron: We should worry about usability.

  <esprehn> leaverou: one improvement we can make is CSS.px(10), you
            could do var px = CSS.px; then just write px(10)
  <esprehn> leaverou: lots more sugar can be added

  plinss: My concern...we don't know what value objects will be, but
          can they fit in this API?
  shane: I'd like to investigate fitting them in.
  TabAtkins: Mutation is a problem, other than that it fits well.
             Worst case we'll have a different getter.
  plinss: I want to make sure we take that into account at this
  TabAtkins: Worse case we'll have a third parallel that's very
  shane: I'm happy to explicitly design for that.
  TabAtkins: Designing this with the idea that value objects will
             happen is good.
  Florian: So if we're going to use it for value objects we should
           design with usability in mind, but we should keep the
           performance in mind for this.
  ojan: We came up with the most usable thing, we had all these
        discussions. We recognize it's not wonderful, but we haven't
        come up with anything else.

  Rossen: So I think we still need a resolution as to if we ED this
          or if they work more.
  Rossen: Objections on having this as an ED?
  Florian: I think we have to iterate, but the principle is good.
  tantek: I don't object I, just request that the issues be placed
          in line.
  <tantek> be upfront about why it's verbose as it is
  TabAtkins: It's important to get ahead of the PR on this.
  shane: I'll work with TabAtkins to get this out ASAP.

  Rossen: Title and editors?
  TabAtkins: CSS-Typed-OM

  leaverou: Will there be code examples in ED?
  TabAtkins: Yep.

  Rossen: Editors?
  TabAtkins: Me and shane?
  gregwhitworth: I'd like to stay in the loop.

  RESOLVED: ED for CSS-Typed-OM with gregwhitworth, esprehn,
            TabAtkins, and shane as editors.


Received on Friday, 16 October 2015 23:39:32 UTC