W3C home > Mailing lists > Public > public-houdini@w3.org > February 2016

[Houdini] Minutes Sydney F2F 2016-01-30 Part IV: Typed OM

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 21 Feb 2016 14:50:56 -0500
Message-ID: <CADhPm3vMZfbP3oYZUaeemfh=0P7jp9JVGe0H_qCumX7GujJmog@mail.gmail.com>
To: public-houdini@w3.org
Cc: www-style@w3.org
=======================================================
  These are the official Houdini Task Force minutes.

         Unless you're correcting the minutes,
        please respond by starting a new thread
           with an appropriate subject line.
=======================================================


Typed OM
--------

  - shane asked for the group's input on what should remain in V1 of
      Typed OM and what should move to later versions.
  - One suggestion that received some support was to only include
      items that were needed for Properties and Values. shane will
      go through and make sure all of Properties and Values is
      included in the spec.
  - There was concern that something would be missing from V1 and
      there should be language addressing if you attempt to get
      something that is not supported. Consensus seemed to gather
      around returning something like UnsupportedStyleValue.
  - Several people expressed a desire to minimize the linguistic
      differences between the old and new OM in order to minimize
      author confusion. However, the spec should work to clarify
      places where confusion already exists, such as where
      getComputedStyle flushes layout.
  - The spec needs to address if shorthands are included in V1 and
      also address what happens when a longhand becomes a shorthand.

===== FULL MINUTES BELOW ======

Agenda: https://github.com/w3c/css-houdini-drafts/wiki/Sydney-F2F-January-2016

Scribe: heycam

Typed OM
--------

  <dbaron> https://drafts.css-houdini.org/css-typed-om/
  shane: I mentioned before, I'm finding working on this spec a bit
         weird.
  shane: We know that there are bits of it we need, to address use
         cases for paint and properties & values.
  shane: And we know that having the full Typed OM is going to be a
         performance benefit for JS authors.
  shane: But I'm finding it hard to figure out how much to put in
         now, which we can cut off at v1, or if we need to consider
         all different types.
  shane: So the first question: what should be in Level 1?
  ojan: I haven't thought about the spec in 6 months.
  shane: I'll show you what's in there right now.

  shane: There's a StylePropertyMap, which lets you get and set
         properties but instead of giving back strings it gives
         StyleValues or subclasses
  shane: Eventually there will be this giant list of StyleValue
         subclasses that correspond to all different CSS types
  shane: For example KeywordValue, NumberValue, LengthValue (which
         also includes %s), TransformValue,
  shane: and we'll have a bunch more.

  ojan: In terms of API surface, there's StylePropertyMap, and a
        bunch of StyleValue subclasses. anything else?
  shane: Only places where StyleValues should be exposed.
  shane: So where inline, specified and computed styles are exposed.
  shane: So getComputedStyleMap on document, styleMap on
         CSSStyleRule and styleMap on Element.
  shane: One thing we could do for V1 is, support exactly everything
         that's exposed by Properties & Values, and nothing more.
  gregwhitworth: I think that would be awesome.
  ojan: But you're asking which StyleValue subclasses to support?
  shane: We also need to know what to do with ones that aren't
         supported.
  ojan: Pragmatically, we can't get all the browser vendors to
        implement the whole space of everything before shipping.
  ojan: So we need to take a subset that we care about to start with.

  gregwhitworth: What do we care about? From the Houdini
                 perspective? Or using this API by itself?
  ojan: Are those different?
  ojan: I think covering the same things that Properties & Values
        supports is reasonable.
  gregwhitworth: I would love to have this for everything that's in
                 the CSSOM, though.
  gregwhitworth: I think this could stand alone without Custom Paint
                 as a dependency.
  ojan: I agree, I'm just trying to think pragmatically about
        shipping.
  gregwhitworth: If I were to wager, a lot of the simple properties
                 and values seem good for V1, and once we get into
                 gradients, transforms, etc.... what would we return?
  shane: When things get hard for properties, we can return property
         bags with no structure.
  shane: But transforms have good structure.
  shane: So I've got TransformValues that you can iterate over to
         get the components, and you can get them as a Matrix,
  shane: with Stylevalue subclasses for each type of component.

  gregwhitworth: How about color?
  shane: I removed color.
  shane: See LengthValue for example, it's got
         add/subtract/multiply/divide methods on it,
  shane: and that's an abstract interface.
  shane: Then there's SimpleLength and CalcLength concrete classes.
  gregwhitworth: This is a step further than what I was envisaging.
  shane: Dealing with mostly simple lengths but sometimes calc
         lengths is a pain,
  shane: so we wanted to make that easy.
  ojan: voice-family has this <voice-value> type -- how would we
        return that?
  shane: Anything that just takes a set of keywords becomes a
         KeywordValue.
  shane: A lot of properties will be supported pretty easily.

  shane: So should we go through to make sure we have complete
         coverage, or does that not matter?
  heycam: So every CSS property?
  shane: Yes or every type of value that is supported by properties.
  heycam: We should get a sense of what's being missed out if we do
          a subset.
  shane: We'll get there in the long run, no doubt,
  shane: but this is about what would be in V1.

  ojan: What do we do if we don't have complete coverage, and you
        attempt to get something that is not supported? Should
        nothing be returned?
  surma: Is there anything wrong about falling back to string repr?
  gregwhitworth: I think then you should use the regular CSSOM for
                 those.
  ojan: So don't make it available in the typed OM?
  gregwhitworth: If it's not supported.
  gregwhitworth: I wouldn't use a fallback string
  ojan: But in the string based OM you get it, but not in the typed
        OM?
  gregwhitworth: Right, I wouldn't build in the performance issues
                 and annoyances of the original OM into this.

  shane: background-image is a bit gnarly
  astearns: Font shorthand?
  esprehn: What about some syntaxes with slashes in the middle etc.?
  shane: Take background-position:
  shane: You're allowed to specify [reads out grammar]
  shane: It's quite complex,
  shane: but it falls back down to two things: a %/length offset
         from top and left.
  shane: So we just expose that.
  heycam: Is that good enough for exposing specified style?
  shane: I don't think there's value in exposing those more specific
         values.
  shane: It's more pain for the author to handle.
  shane: If you really need to know it was "center" you could fall
         back to the old OM.
  [some discussion about grid properties]

  zcorpan: There are lots of interface names that may conflict with
           names that authors use.
  zcorpan: like Translation, Scale, etc.
  zcorpan: The other thing is that we already have DOMMatrix.
  zcorpan: Why is there a new Matrix?
  esprehn: Just use a "CSS" prefix.
  shane: They can live off the CSS object as well.
  shane: Once we nail down the set of interfaces we can discuss that.

  shane: For Matrix, we can't make DOMMatrix inherit from StyleValue.
  esprehn: You can make it have a DOMMatrix as a member.
  zcorpan: If you have a reference to a Matrix object, that has a
           member called asMatrix, that returns itself...
  shane: We could make asMatrix return a DOMMatrix.
  heycam: Would that DOMMatrix be live?
  shane: No, I've been leaning towards immutability.

  dbaron: There are a bunch of other things in this area which have
          been design mistakes.
  dbaron: It's worth thinking about which things need fixing, which
          are worth being consistent with,
  dbaron: e.g. getComputedStyle on Window rather than Element.
  dbaron: Accessors for slightly different stages of value
          computation.
  <tantek> here you go: https://wiki.csswg.org/ideas/mistakes
  <tantek> ^^^ dozens there
  shane: We should be thinking about these things
  shane: and biasing towards fixing these things, since we probably
         won't have another chance.
  ojan: I feel like we should minimize the differences, having
        inconsistencies is another layer of complexity.
  ojan: When it's in the typed OM you do it this way, but string OM
        you do it another way,
  ojan: but the getComputedStyle example is a good one -- let's not
        put the new one on Window.
  ojan: Things in the list like "white-space: nowrap" not having a
        dash.
  ojan: That's one I wouldn't change.
  ojan: Actually returning computed style I would do, though
        (compared to getComputedStyle).
  shane: We shouldn't be making changes that would cause confusion
         on a value by value basis.
  plinss: Changing the CSS language isn't the goal of this.
  ojan: Authors could well be confused between getComputedStyle vs
        the Typed OM, used vs computed values.
  shane: I'm not sure what's best for that.
  esprehn: I'm inclined to say return what getComputedStyle returns.
  gregwhitworth: I lean towards designing it toward the goal of
                 deprecating the old OM at some point.
  gregwhitworth: So while yes while trying to make it consistent,
                 have it called "used style".

  esprehn: If you ask for the width, it'll return 75%, then it's
           your responsibility to resolve that.
  shane: Most of the time it will return auto?
  esprehn: Yes.
  esprehn: That seems reasonable to me as an implementor, it's less
           complicated, but it's less intuitive.
  plinss: One thing we wanted to fix with Houdini was APIs that
          conflate style and layout, and we should fix that.
  plinss: A style API should return style, I accept people want to
          return width, but give them a proper API for that.
  esprehn: [discussing logical properties and forcing the author to
           compute things based on writing mode]
  plinss: This is why we'd have the Box Tree API, if they want box
          geometry use that API.
  shane: Anybody who tries the new APIs and they don't work for
         them, they've got APIs to fall back on.
  plinss: The fact that getComputedStyle flushes layout is a bug,
          the new Typed OM API shouldn't.
  shane: We could negate the confusion somewhat by having new names,
         not similar to getComputedStyle.
  shane: We could also not support width/height in the new API.
  plinss: You should get the specified or computed values of the
          properties, not the layout width/height.
  plinss: We're trying to make a clear separation of layers here.

  astearns: I had a question about value types we don't yet have in
            the OM.
  astearns: Are all of the functional value types going to have to
            look like the transforms do now, with various subclasses
            for the different functions you can pass as a value?
  shane: That's a good question.
  shane: I think so.
  shane: Taking background-image for example, the <image> type will
         need to make a distinction between image sources, SVG
         resources, but also these cases we could maybe provide
         limited APIs such as only width/height on an image.
  shane: But fundamentally I'm not sure what the right thing to do
         here is.
  heycam: I don't think the actual image data, or an opaque
          reference to it, is the primary thing to expose on image
          values.
  heycam: To me it seems like it should just be the URL.
  heycam: But sure you can have a method that turns that into an
          opaque reference to an image you could then pass on to a
          canvas.

  astearns: The question is how much do we need to do now. It would
            be nice to have everything, but we're going have to add
            things incrementally as the CSSWG invents new types
            anyway.
  heycam: What about properties where some values are representable
          using the types but some aren't?
  shane: What would happen if we added new types to an existing
         property?
  heycam: Right, if we returned nothing all the time, then we'd
          prevent ourselves from adding new types to a property.
  shane: So off the top of my head, we could throw an exception if
         the property has an unsupported value type.
  shane: Which is a bit nasty.
  shane: We could roll the value up into an UnsupportedValue type.
  shane: I'd worry people would rely on that though.
  shane: But if it only exposes the CSS text that might be OK.
  astearns: So an UnsupportedValue that has a CSS string, and when
            we eventually support it, you get the new class.
  astearns: And the old code that used the CSS string would still
            work.

  heycam: Let's call it cssText instead of cssString.
  astearns: If we did this, we should go through the entirety of the
            CSS property set, and see what's covered in current
            StyleValue objects, and what would have to return an
            UnsupportedStyleValue.
  astearns: See if we've got sufficient coverage.
  shane: Another option is to take the Properties & Values API, and
         ensure it supports those.
  shane: So start with the P&V set, then check that we aren't
         missing something obvious that we really need in V1.
  shane: What do implementors think?

  smfr: We have to start somewhere.
  Rossen: It's better than throwing exceptions everywhere.
  dbaron: If it's clear what the partial set is, and it's
          interoperable...
  ojan: That's not going to happen, what happens when we want to add
        a new chunk of stuff?
  shane: So level by level, you'd be interoperable.
  shane: Sounds like there's a reasonable level of consensus for this.
  shane: A bounded set of things to look at.

  shane: One important question: do we want shorthands in V1 or not?
  Rossen: Can we get around without supporting them?
  ojan: In the spirit of shipping things, leave it out.
  shane: The only question I have, on specified style if you specify
         a shorthand should you be able to read the longhands out of
         it?
  dbaron: If you set a shorthand you can read the longhands.
  heycam: I worry about if we don't support shorthands in this API,
          what happens when you split up a longhand into multiple,
          and that original longhand is now a shorthand?
  dbaron: That's a similar issue to getComputedStyle.
  dbaron: The WG has frequently converted longhands into shorthands,
          and continues to do so.
  dbaron: It needs to be clear what happens for compatibility when
          that happens.
  shane: We could perhaps answer just that question in the spec.

  shane: Big picture things: we need the UnsupportedStyleValue
         added, a description of partial support, go through all the
         P&V types, do an audit of all CSS 3-ish properties and make
         sure there are no major omissions, and answer this
         shorthand question
  shane: Any other Typed OM issues that need discussing?

  heycam: I'm wondering why parse() returns either StyleValue or
          sequence<StyleValue>, unlike get/getAll separate methods
  zcorpan: Should these objects have stringifiers?
  heycam: People are using the APIs for their typed values, not sure
          how useful it is.
Received on Sunday, 21 February 2016 19:51:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:53:26 UTC