- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 13 Feb 2017 20:18:42 -0500
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
FX Track
++++++++
Transforms
----------
- The references to 4x4 matrices will stay in L1.
- There was agreement that transforms should apply to flex and
grid.
- The spec will clarify that transform-origin's resolved value is used.
- RESOLVED: add transform-origin-x/y/z to transforms levels 1 and
(for z) 2, to address
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29
- Chrome just committed a patch which resolves the issue titled
'transform-origin: 0% not equivalent to 0px is confusing'
(https://github.com/w3c/csswg-drafts/issues/895)
- RESOLVED: Add identity transform function to transforms level 2,
interpolates with anything, to address
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-36
- shane to add use counter to Chrome to collect frequency data on
compatibility of change for
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-37
- The group had three proposed resolution to the transforms
interpolation issue
(https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-38)
a. Run the transitions
b. Define canonicalization and use the general available
transform list and determine if to trigger a transition
c. Similar to 2 but moves it to transitions
- There was originally a leaning to get author feedback to
decide between a and c, but it was discovered that
browsers are interoperable on a.
- Author feedback will still be sought in case there's
overwhelming consensus that c would be the expected
behavior.
- RESOLVED: Resolve issue 38 on option A (run the transitions)
from above.
- RESOLVED: matrix() and matrix3d() should be the same primitive
in https://drafts.csswg.org/css-transforms-1/#transform-primitives
- RESOLVED: Perspective will interpolate to perspective, rather
than to matrix, interpolated by the reciprocals of the
lengths.
- RESOLVED: Follow the spec and match FF which means perspective
with a value of 0 is invalid.
- RESOLVED: UAs must introduce near 0 clamping for perspective.
Whitespace in a custom property in a variable reference
-------------------------------------------------------
- TabAtkins will create an example in the custom props
specification so that everyone is parsing out the whitespace
in a custom property as defined by the syntax specification.
Geometry Interfaces
-------------------
- DomPointReadOnly will stay as-is for now.
- smfr brought up a few questions/ideas around DOM Quads, but
there wasn't time for a real discussion.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/seattle-2017
Present:
Rachel Andrew, Invited Expert
Rossen Atanassov, Microsoft
David Baron, Mozilla
Bert Bos (W3C)
Dave Cramer, Hachette Livre
Emil A Eklund, Google
Elika Etemad, Invited Expert
Simon Fraser, Apple
David Grogan, Google
Koji Ishii, Google
Peter Linss, Invited Expert
Myles C. Maxfield, Apple
Simon Pieters, Opera Software
Naina Raisinghani, Google
Melanie Richards, Microsoft
Hiroshi Sakakibara (BPS, Beyond Perspective Solutions)
Jen Simmons, Mozilla
Geoffrey Sneddon, Invited Expert
Alan Stearns, Adobe
Surma, Google
Jet Villegas, Mozilla
Greg Whitworth, Microsoft
Steve Zilles, Adobe
Note: The group split the morning of the 11 January on two
tracks: FX and Text.
Scribe: dbaron
FX Track
++++++++
Transforms
==========
smfr: There was a decision in Lisbon to move 3d transforms to L2.
smfr: I have changes to do this in a local branch on csswg-drafts.
smfr: I can merge soon, maybe this week.
smfr: Most of it is fairly straightforward. 1 or 2 issues a little
more complex.
smfr: There's some math referencing 4x4 matrices in the draft.
smfr: Not sure to move all references to level 2 or leave them in
level 1
smfr: i.e., not sure whether to purge all 3d math from level 1.
smfr: A little awkward for L2 to insert pieces into the prose
every time there's pieces in matrix math.
shane: Also maybe a consistency argument -- if referencing same
algorithm.
smfr: So arguing to leave 4x4 matrices in l1.
shane: Yes.
smfr: Think the L1 draft is in pretty good shape, but L2 is a mess.
smfr: Copying and pasting chunks into L2.
Rossen: Link to repo?
smfr: Haven't pushed it yet.
smfr: Can I just go ahead and merge in?
Rossen: Absolutely.
Rossen: And we already have resolution from Lisbon.
Rossen: Once you have L1 spec -- is it pretty much ready to go?
Rossen: Belief was that L1 could go to CR-PR-REC quickly.
smfr: Transform, transform-origin, SVG related stuff, 2d transform
functions, stuff about interpolating matrices and mismatched
function lists is still there, but without 3d functions, so
think it's fairly uncontentious.
Rossen: Any open issues?
smfr: Some of this list will be 3d stuff... haven't looked at this
issues list yet
[projecting https://drafts.csswg.org/css-transforms-1/issues-wd-2013 ]
Rossen: Do you need any WG time for any of these issues?
Application of transform to inlines
-----------------------------------
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-7
smfr: One is #7, application of transforms to inlines
dbaron: I think we support transforms on flex and grid.
<dbaron> https://lists.w3.org/Archives/Public/www-style/2014Feb/0382.html
smfr: Is "atomic inline-level elements" enough?
dbaron: We support on everything except non-atomic inline, ruby
base container, ruby text container... and on tables we
support on wrapper
dbaron: and I think the other ruby stuff derives from inline.
dbaron: My main concern is that the definition in the spec seems
to say transforms don't apply to flex and grid
dbaron: and I think they should.
[agreement]
smfr: testcase in the issue is dubious.
Rossen: Do we need a resolution?
dbaron: We should also test table rows, etc.
TabAtkins: Flex and grid count as "block-level", so I think this
is probably right... though specs may not be hooked up
exactly right.
[fantasai's note: flex and grid items are not “block-level”]
Follow-up in https://github.com/w3c/csswg-drafts/issues/908
smfr: There are some SVG-related issues that I'm not sure we have
the right people for (#10, #17).
TabAtkins: and #18
smfr: and #23
smfr: and #25
smfr: we can discuss #27 and #29
Rossen: let's discuss #27
Specs disagree on whether transform-origin's resolved value is used
or computed
-------------------------------------------------------------------
<dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-27
<dbaron> https://github.com/w3c/csswg-drafts/issues/392#issuecomment-238494067
TabAtkins: We're fine with it being used value; just a matter of
lining up wording between om and transforms
TabAtkins: with resolved value being used value.
smfr: Why are there these special properties?
TabAtkins: Originally in CSS2, because definition of computed
value was different and we changed it in 2.1
TabAtkins: and a handful of properties in newer specs are
implemented with bad computed value behavior.
dbaron: Although some value in getComputedStyle being consistent
between properties.
TabAtkins: Like grid-templates use used value.
smfr: So this seems like it's more editorial rather than needing
discussion.
TabAtkins: Yeah, om should specify it can be extended.
TabAtkins: OM's list of properties that use the used value as
resolved value should be specified as extensible by
other specs.
zcorpan: Sure, everything should be extensible by other specs.
ACTION zcorpan to edit CSSOM
Add transform-origin-x/y?
-------------------------
<dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29
TabAtkins: We don't see strong usecase for -x and -y but other
position things have them
TabAtkins: Already in webkit and blink.
smfr: One implication of spec splitting is that transform-origin
takes 2 arguments in level 1 but 3 in level 2.
dbaron: Do webkit and blink implement transform-origin-z?
smfr: I think so... let me check.
shane & Tab: We implement -webkit-transform-origin-x/y/z
smfr: Webkit has it unprefixed.
RESOLVED: add transform-origin-x/y/z to transforms levels 1 and
(for z) 2, to address
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-29
transform-origin: 0% not equivalent to 0px is confusing
-------------------------------------------------------
smfr: Issue 30... SVG one
Rossen: https://github.com/w3c/csswg-drafts/issues/856 was called
out in agenda
gregwhitworth: Chrome just committed a patch to match spec, so
we're fine.
gregwhitworth: It was about single-argument scale()
smfr: Just the scale property, not the function.
shans: Makes sense to extend with 1s rather than repeating because
you don't want to extend the argument to 3d scale.
shans: so better to extend to 2 1 1 than 2 2 1 (which is
confusing).
TabAtkins & smfr: Issue #33 is a 3d transform issue; definition of
SLERP ends up with 0 divisor in one case
Add null transform as placeholder for animations?
-------------------------------------------------
<dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-36
smfr: Issue #36
TabAtkins: To make transforms easier to interpolate
smfr: Spec already talks about neutral transform functions.
shans: Talking about the problem of being somewhat difficult to
match up transform lists when doing complicated animations.
shans: From minutes of Paris F2F looks like we talked about 2
ideas, but viable one was having null transform in the list.
smfr: And UA would expand to identify with ...?
shans: Wouldn't want to expand it, e.g., in a keyframe between 2
others it might match different things on each side.
smfr: The intent is to provide a way to avoid falling back to
matrix interp when you have mismatched function lists. So
author would insert 'null'?
TabAtkins: Yes.
smfr: It's an identity that matches the function type?
shans: Pretty well defined -- if it only matches one function.
[smfr on whiteboard:
@keyframes {
from { transform: rotate(10deg) scale(2) null }
50% { transform: rotate(2deg) null translate(10px, 20px) }
to { transform: null scale(1) translate(0, 0) }
}
]
[smfr on whiteboard:
@keyframes {
from { transform: rotate(10deg) scale(2) id() }
50% { transform: rotate(720deg) id() translate(10px, 20px) }
to { transform: id() id() id() }
}
]
smfr: Should we do in level 1? Not a behavior change for existing
content, but a new feature.
shans: I think it's fine in level 2, esp. now that we have a path
to getting implementations of level 2 out.
RESOLVED: Add identity transform function to transforms level 2,
interpolates with anything, to address
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-36
Smarter interpolation of truncated transform lists
--------------------------------------------------
smfr: May address 37 as well?
TabAtkins: Helps with 37, but not...
shans: Idea of 37 was... say you didn't have this translate():
[shans on whiteboard:
@keyframes {
from { transform: rotate(10deg) scale(2) translate(10px) }
50% { transform: rotate(720deg)
to { transform: id() id() id()
}
]
shans: Issue 37 is saying the 50% line should pad at end with
identity transform in cases where first transform functions
match.
shans: This is just an extension of what happens with none.
smfr: Slightly magical
smfr: behavior change, a little worrisome.
[ somebody mentioned something there about end-matching too ]
shans: One approach we could take which wouldn't be a behavior
change, but a little less useful, saying you have to put
one id() at the end and then it would expand out.
shans: If anything, it's more magical.
Rossen: That's a lot more error prone.
Rossen: If there's magic I'd rather keep it in the engine.
smfr: But you'd be willing to live with behavior change?
TabAtkins: Is the behavior change what people would have intended?
shans: The behavior change is rarely going to be worse.
smfr: People often ship things where they meant one thing, but not
what they looked at or debugged...
shans: A few years ago implementations often differed, but not
sure if that's still the case.
shans: Risk of behavior change would be how many pages it changes
behavior on.
[ some discussion about whether somebody wants to try the behavior
change and see if it breaks things]
ACTION shane to add use counter to Chrome to collect frequency
data on compatibility of change for
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-37
<trackbot> Created ACTION-93
Transform interpolation problem
-------------------------------
scribe: dbaron & gregwhitworth
<dbaron> https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-38
<dbaron> https://lists.w3.org/Archives/Public/www-style/2014Jul/0017.html
[Tab explains issue]
dbaron: I'm suspicious of the section on function equality stuff...
TabAtkins: Still a level 1 issue with translateX() and
translate(x, y)
dbaron: I think this might be ok though before the edits, but
might have been broken after the edits.
<dbaron> not sure though.
smfr: We probably need some concept of equivalence in transitions
and animations.
dbaron: Transforms are the hardest interpolation unit by far.
TabAtkins: We do currently fire transitions for this case.
smfr: Or we could just say it's too bad -- is it bad that you run
a transition that doesn't have visual impact?
dbaron: So there are cases where if you interrupt a transition
midway, you mouse in and mouse out.
dbaron: You want the interpolation result to use transform list
interpolation with the endpoints.
dbaron: I never suggested implementing these gecko because I
thought this would cause these matrices interpolation
issues.
<dbaron> (we're sort of moving into 39 -
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-39)
smfr: Options for #38 are either (a) run transitions anyway or (b)
talk about equivalency.
dbaron: One of the problems that you have with the interpolation
rules is that you have 100% of A and 0% of B you'll have
something that is not A.
TabAtkins: I think we all serialize computed values to a matrix.
smfr: We do too.
Rossen: So do we.
dbaron: matrix3d and perspective don't interpolate between one
another so it causes all sorts of problems.
dbaron: that's my belief that this edit was never fully finished.
shans: I think there's also a third option which is to run
interpolation as part of the transitions spec.
shans: That would be option (c)
Options:
1/a. Run the transitions
2/b. Define canonicalization and use the general available
transform list and determine if to trigger a transition
3/c. Similar to 2 but moves it to transitions
shans/dbaron: (c) is like (b) but piggybacking on the
interpolation rules.
shans: This would say that when you want to see whether to
transition from A to B, you define A' as interpolate(A, B,
0%) and B' as interpolate(A, B, 100%), and then compare A'
and B' to see whether you run a transition.
smfr: I have a concern about compat, because we've definitely see
content break when we don't fire transition events.
smfr: It wouldn't surprise me if people wrote content that tried
to interpolate between translateX() and translate(x, y)
shans: I know we've seen people frustrated about lack of
transition events when they accidentally set the same value
back.
shans: And I could see this feeding into that.
dbaron: Maybe ok to do (a), although I'm a little worried there
might be reversing issues.
shans: We could collect data on the frequency this happens.
gregwhitworth: Is it worth the work to implement?
shans?: [ (a) if nobody uses it because it's not worth doing, or
also (a) because everybody uses it and a compat risk ]
Rossen: What do you think Rachel?
RachelNabors: I think I could go either way, but I'd prefer to
reach out to authors for their opinion.
scribe: gregwhitworth
smfr: But people expect a transition if they change the value.
dbaron: But it's already computed values rather than specified.
TabAtkins: Yeah, it's worth sharing the color example as well (eg:
red -> rgb(255,0,0)).
shane: Color isn't going to change.
TabAtkins: Talking to people just about this issue and transforms
and then also showing them other areas where this also
already occurs, would they want to change.
smfr: It's primarily about the events, because you won't see
anything on the screen - you'll only get an event or not.
RachelNabors: Do we have any test cases?
smfr: No, but we could make them easily.
<smfr> RachelNabors: https://jsfiddle.net/ayn25zgj/ (feel free to
clean up to not alert())
Rossen: So if we had to pick one, it seems everyone likes c, but
from implementation point of view - c is most worrying.
shane: c and b is very similar in terms of risk.
shane: To put it to a vote, you're voting against a or b/c
Rossen: I think we can get rid of b, because it's the same risk
but not as elegant.
Rossen: If we have to do it today, option A or option B.
RachelNabors: My gut is C, but I'd like to ask the community.
Rossen: That would be a great data point.
Rossen: From impl point of view, c is risky.
shane: There all kind of people triggering on events.
Rossen: What I was going to propose if we can get someone to
experiment with it to determine how much risk is actually
there.
shane: Without manual inspection, you're not going to know if
there was a behavior change.
shane: We could figure out how many are firing off of these events
but not if they will break.
dbaron: What you could do, is add a tracker that is looking for
when you wouldn't fire for option C
dbaron: some of this isn't really interoperable
dbaron: so - people may not be using this.
[everyone looks at test, all browsers run the transition]
shane: I don't think we should mess with this.
Rossen: So, I don't disagree that we don't have good interop here
Rossen: It would be a great data point.
Rossen: We would then need to still consider it based on compat
risk
<shane> wait so Rossen does disagree that we do have good interop?
<dbaron> I'm inclined to agree with shane that maybe we do need to
stick with (a)
Rossen: We can resolve on A today and then when we have more data
we could change to take C
shane: Okay
shane: I don't want Rachel/Surma don't to do a bunch of wasted
work.
smfr: Another thing to consider with C is to think about filters.
<RachelNabors> I'll also reach out to the popular animation
library authors and see if they're using A as a
hack.
RESOLVED: Resolve issue 38 on option A from above
Interpolated values don't interpolate well with original start/end
------------------------------------------------------------------
dbaron: Moving on to issue 39
https://drafts.csswg.org/css-transforms-1/issues-wd-2013#issue-39
dbaron: It might be specific to 3d, it's an issue where we're not
interopable.
dbaron: We found out about it due to Gecko not doing what IE/
Chrome did
dbaron: I investigated it and we match the spec, but I don't think
the spec makes some sense.
dbaron: It was interpolating from things you can't mix.
dbaron: In section 20 it says ".... reads spec...."
<dbaron> The transform functions matrix(), matrix3d() and
perspective() get converted into 4x4 matrices first and
interpolated as defined in section Interpolation of
Matrices afterwards.
dbaron: That means when you interrupt the transition in the middle
and reverse it you get matrix interpolation.
smfr: I'm a bit confused.
dbaron: Are you trying to read the spec? Of course you're confused.
smfr: What I would expect is that you would end up with matrix3d
blah to interpolate to matrix3d blah.
TabAtkins: But matrix3d and perspective are not supposed to work
together.
dbaron: You could make them all use the same primitive.
shane: ahhhh, but they don't.
dbaron: You could do this by doing it on the interpolation lists.
TabAtkins: Why is perspective special?
dbaron: Maybe webkit and blink still do this.
dbaron: Maybe dirk made these edits.
smfr: I'm not sure why perspective doesn't just interpolate like
everything else.
dbaron: Going back to the primitive thing, I think that matrix and
matrix3d should be the same primitive.
TabAtkins: Yeah.
Rossen: We could resolve on that.
<dbaron> can we resolve that matrix() and matrix3d() should be the
same primitive in
https://drafts.csswg.org/css-transforms-1/#transform-primitives ?
shane: Maybe there is something with linearly interpolating the
length.
TabAtkins: The null value could be infinite.
TabAtkins: If I recall there are actually problems with that in
the spec.
smfr: With this issue, we should see what interop is like, and
define something that aligns with that.
Rossen: dbaron said that there isn't good interop
<dbaron> https://bug977311.bmoattachments.org/attachment.cgi?id=8382580
dbaron: But it seems IE/Webkit do.
dbaron: I don't think it's about the flip, I think the behavior is
subtle - it's about whether it does multiple rotations,
not that it just flips.
shane: I think TabAtkins and I figured out why the way it is,
because there is no null perspective, but now in level two
we plan to have id() or null to do this
[looking at testcase...]
smfr: since this is a level two thing I think we can punt on this.
dbaron: I would really like to get 3d interoperable though.
shane: I think we should look at the math for the interpolation
and then say perspective function does *this*.
dbaron: One way is doing linear interpolation of the reciprocals.
Rossen: So are we ok then punting on this for now?
dbaron: Do we want to resolve on matrix and matrix3d should be
equivalent primitives?
shane: We don't get perspective until we get id()
Rossen: With these two it will fix dbaron issue entirely.
dbaron: Yeah I think that's fine.
RESOLVED: matrix() and matrix3d() should be the same primitive in
https://drafts.csswg.org/css-transforms-1/#transform-primitives
dbaron: We would need a resolution that perspective interpolates
to a perspective rather than a matrix.
smfr: [Explains how webkit does it]
smfr: This probably why Dirk wrote the spec the way that he did.
smfr: In that case - are you ok with that resolution that
perspective interpolates to perspective.
smfr: It's certainty true that we don't convert the perspective
function to a matrix.
RESOLVED: Perspective will interpolate to perspective, rather than
to matrix, interpolated by the reciprocals of the
lengths.
<break>
perspective(0)
--------------
TabAtkins: Can we deal with perspective(0)?
TabAtkins: The perspective function is defined to expect a
positive number.
TabAtkins: It allows 0.
TabAtkins: This allows a 0 divisor allowing infinite warping which
is not good.
TabAtkins: All UAs do perspective infinity which is the largest
discontinuity in CSS.
TabAtkins: There are also some odd NAN issues.
TabAtkins: The standard way we deal with these types of exploding
issues is we decide on a floor.
TabAtkins: It would be nice to have a defined way.
Rossen: The proposal is to have UA defined clamping near 0.
jet: I think we already do that because we've had bugs similar to
this.
TabAtkins: So we should clamp the perspective length to close to 0
rather than blowing up to infinity and then doing
whatever.
smfr: I think people expect perspective 0 should be like scale 0.
TabAtkins: Maybe that's why it is the way it is, it's not
mathematically incorrect and the transitions are
stupid, and a few other things.
TabAtkins: The perspective property doesn't allow you to
transition for you to transition from none to something
else
TabAtkins: So we could have 0 be like none
<TabAtkins> 1. Spec what currently exists - 0 has inf behavior,
but interpolable.
<TabAtkins> 2. Spec that perspective(0) == perspective(inf), but
not interpolable (like perspective:none doesn't
interpolate with numeric values).
<TabAtkins> 3. Clamp the perspective value to a UA-defined >0
minimum.
[everyone begins building testcases]
<smfr> https://jsfiddle.net/qs17okua/5/
<gregwhitworth> https://jsfiddle.net/qs17okua/6/show/
<smfr> https://jsfiddle.net/qs17okua/10/
smfr: I think FF throws the perspective away if it's below a
threshold.
smfr: If we all change to perspective(0) what happens?
TabAtkins: [discusses what he thinks FF is doing]
smfr: So what do we do?
Rossen: So if we clamp .05 down to 0 - this will get rid of the
weirdness.
smfr: What do you do for perspective(0)?
smfr: That doesn't solve the discontinuity issue.
Rossen: thoughts?
Rossen: Shane what would you all think?
shane: I don't like the discontinuity but I don't think there is a
better option.
smfr: Have you seen this issue?
TabAtkins: Even if they are, it's going to be a screwed up issue.
Rossen: Let's say you're transitioning between 5 -> 0 [does
interpretation of animation with hands]
shane: If you transition that same thing, you'll be transition
from 5 -> infinity
<smfr> https://jsfiddle.net/qs17okua/11/
shane: That behavior smfr we already do.
TabAtkins: We're going to need to special case it.
TabAtkins: Currently we all differ, so let's define a good
behavior.
Rossen: If we throw 0 away how do you transition.
TabAtkins: Negative values are already not allowed.
TabAtkins: My preferred option is still the clamping because we
have a closed range.
Rossen: When does FF actually clamp?
TabAtkins: With actual 0.
TabAtkins: You may hit it if you put in like 400 0s you'll hit
their clamp.
Rossen: So Tab's proposal is to introduce the clamping that is
near 0 becomes none.
smfr: When you say none, you mean the identity matrix.
Rossen: Yes.
TabAtkins: So we stop interpolating when it's none.
smfr: So do we stop interpolating completely for others.
TabAtkins: No, you can do a 50% flip.
shane: That is a major change.
smfr: We can do what FF does or what the other browsers do, it
does have discontinuity but we haven't seen that issue in
the wild.
surma: If we don't treat 0 as infinity, is there anything bad with
that?
TabAtkins: I would rather add an inf keyword than keep that.
shane: What we're saying is that FF is more correct, but we should
match what other browsers do.
Rossen: So, we've been spending a bit of time on this topic, let's
close on it.
Rossen: It doesn't sound like we're ready to resolve on it.
jet: Our behavior is to not let it happen, there is one to clamp
it.
Rossen: There is one, but we'll probably reject that, but the one
is you get the bizarro issue but it's one probably not hit
in the wild.
smfr: A couple of things, the spec says that anything below 0
should be rejected - so FF is doing that. Maybe we should
match FF.
zcorpan: Even with calc?
TabAtkins: Yeah, let's match FF - then define that there is a UA
defined minimum.
Rossen: Again, that makes in FF case it not interporable.
TabAtkins: Only in the case that you don't have an end point to
interpolate to.
RESOLVED: Follow the spec and match FF which means perspective
with a value of 0 is invalid.
RESOLVED: UAs must introduce near 0 clamping for perspective.
Whitespace in a custom property in a variable reference
=======================================================
<smfr> https://github.com/w3c/csswg-drafts/issues/881
jet: [explains the issue, we should probably define this so that
this works]
TabAtkins: This should be defined at the syntax level.
jet: Maybe something that prettifies it.
surma: When does the whitespace actually matter.
TabAtkins: Never.
zcorpan: So if you were round-tripping in CSSOM and the
serialization adds the space after the colon, for each
round trip you'll get an extra space - correct?
zcorpan: The current CSSOM spec adds in a space.
shane: I would really like for us to adopt FF behaviour so that
whatever you put in is what we get out.
Rossen: I'm sympathetic with that as well.
Rossen: So we just kept it.
Rossen: I remember chatting with Tab on this and he wasn't too
worried about this.
Rossen: So would you be ok with this?
TabAtkins: [reads out as a parser the text on the screen]
Rossen: Do we need to make any change to this?
shane: I'd like to make a note in the spec to make it clear.
Rossen: Sure.
TabAtkins: The syntax spec covers this.
Rossen: Do not make changes to syntax spec but add an example and
make sure implementors follow syntax.
ACTION TabAtkins make an example in the custom props so everyone
knows how to do this
<trackbot> Created ACTION-94
ACTION TabAtkins create an example in the custom props
specification so that everyone is parsing out the
whitespace in a custom property as defined by the syntax
specification
<trackbot> Created ACTION-95
Geometry Interfaces
===================
<smfr> https://www.w3.org/TR/geometry-1/#DOMPoint
<smfr> https://www.w3.org/TR/geometry-1/#dom-dompoint-dompoint-point
smfr: L1 of the geometry interfaces has an API that takes a
dictionary and it's weird that it's not on DOMPoint ReadOnly.
zcorpan: It hasn't been shipped in Chrome it's behind a flag.
<zcorpan> https://bugzilla.mozilla.org/show_bug.cgi?id=1186265#c3
smfr: I'm curious if the removal of this is web compatible.
zcorpan: In httparchive I couldn't find any instances.
<zcorpan> https://bugzilla.mozilla.org/show_bug.cgi?id=1186265#c3
Rossen: The non read only version?
zcorpan: The non-read only.
zcorpan: It's not shipped in Edge nor Chrome.
jet: Did you look for webkit-point?
zcorpan: I don't think webkit takes a dictionary.
smfr: I think this is useful for authors.
zcorpan: There is from point?
zcorpan: This can produce confusing results.
zcorpan: Especially due to overloads, like DOMMatrix.
zcorpan: This seemed like a saner design.
smfr: I'm fine keeping this in the editors draft if this seems
like the better future forward approach.
zcorpan: And I think that with the web compat, we should try and
ship the editors draft and see what happens.
Rossen: Do we need a resolution?
smfr: I don't think so.
smfr: My second issue is with DOM Quads
<smfr> https://drafts.fxtf.org/geometry/#DOMQuad
smfr: I suspect I'm going to get shut down.
smfr: It's written in such a way that authors can get a point in
the dom quad
<smfr> var quad = fromQuad(…..)
<smfr> var p = quad.p1;
<smfr> dosomething(p);
<smfr> p.x = 100
smfr: If dosomething() were to change that point, the rest of quad
would be modified as well.
smfr: A couple questions, DOMQuad doesn't have readonly versions.
smfr: We could make the points more explicit by making the points
assignable.
surma: Currently DOMQuad are marked as readonly.
smfr: Yes, but they return a mutable point.
smfr: One proposal here would be to have the attr of DOMQuad not
be readonly but the points of them readonly.
zcorpan: So you can assign.
smfr: Yes.
TabAtkins: I still stand by this is how JS works, the larger
object sees the mutation.
surma: Inversely if we change it - people may be confused that
they can't modify it.
zcorpan: So if you want to pass on those points over to someone
else you need to make a copy yourself.
<break type=lunch><div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br />
<table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 13px;"><a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon"
target="_blank"><img
src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif"
width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 12px; color: #41424e;
font-size: 13px; font-family: Arial, Helvetica, sans-serif;
line-height: 18px;">Virus-free. <a
href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link"
target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1"
height="1"></a></div>
Received on Tuesday, 14 February 2017 01:19:48 UTC