- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 21 Feb 2016 14:50:56 -0500
- 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:57 UTC