- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 16 Oct 2015 19:38:34 -0400
- To: public-houdini@w3.org
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.
===== FULL MINUTES BELOW ======
scribe: dael
CSSOM 2
-------
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
previous.
shane: This gets complicated because it repeats both style rules
and computed value so this appends to the end of the start
rule.
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
property?
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
comma.
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
event?
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
exist?
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
time.
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
clipping?
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
element.css?
<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
calc.
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
access.
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
completely.
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')
.add("5px"))
<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
verbose.
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
setting.
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
out.
<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
properties.
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
properties.
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
length?
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
it.
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
things.
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
motion.
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
these.
Rossen: In custom layout I'd want to be working out of a computed
style.
shane: An API that lets you set rems and what the agent will be
required.
<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
better
<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 +
'px';
<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
something?
<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
libraries.
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
platform.
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-
deprecation.
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
that?
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
usability.
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
layer.
TabAtkins: Worse case we'll have a third parallel that's very
close.
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.
<break=lunch>
Received on Friday, 16 October 2015 23:39:32 UTC