- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Jun 2018 19:42:34 -0400
- 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.
=========================================
Media Queries 5
---------------
- RESOLVED: Add environment-blending to MQ5 (Issue #2723 | PR #2719)
CSS Transforms
--------------
- There was a desire to make the change in Issue #927 (Smarter
interpolation of truncated transform lists) either in level 1 or
not at all so that it maintains interoperability.
- No implementor on the call showed interest in this change, but two
key commenters from the github issue (birtles and TabAtkins)
were not on the telecon so the final decision will be deferred
to the F2F.
CSS Syntax
----------
- After discussion the group came up with five options to address
the request in Issue #2757 (Consider disallowing NULL code
points in stylesheets)
1) drop entire stylesheet
2) drop stylesheet after NULL
3) drop encompassing selector around NULL
4) drop NULLs during pre-parse
5) no change
- Some members of the group were unconvinced of the use case behind
the issue and wanted to have someone with security expertise
validate the vulnerability.
- The group will review again at the F2F and perhaps request review
from TAG.
CSS Display
-----------
- RESOLVED: Compute to none [instead of behaves as none] (Issue
#2755: Use "computes to" instead of "behaves as" for
display: contents on unusual elements)
CSS Sizing
----------
- RESOLVED: Change to "behave as" instead of "compute" (Issue #2708:
Incorrect use of the word "compute" in definition of
intrinsic keyword values)
CSS Text 3
----------
- RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/2465#issuecomment-400171764
(instead of having break-spaces be a || alternative in
overflow-wrap, it will be a | alternative in
white-space.)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jun/0030.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Garrett Berg
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Elika Etemad
Tony Graham
Wenli He
Dael Jackson
Peter Linss
Thierry Michel
Liam Quin
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Dirk Schulze
Geoffrey Sneddon
Alan Stearns
Eric Willigers
Jeff Xu
Regrets:
Fergal Daly
Simon Fraser
Chris Lilley
Jen Simmons
Lea Verou
Scribe: dael
Rossen: Let's get going
Rossen: As usual I wanted to see if there are any additional items
or changes.
cabanier: Could we have a moment to talk about environment-blending?
Rossen: It's the first topic.
cabanier: Oh! Sorry.
Media Queries 5
===============
Add 'environment-blending' keyword
----------------------------------
github: https://github.com/w3c/csswg-drafts/pull/2719
cabanier: Hi everyone! I work for Magic Leap and we do an AR headset
and we're doing a web browser for that. One of the things
in our headset is it's additive. A lot of websites aren't
as pleasing to the eye as can be. Bright white background
with small text is hard to read. People tend to switch
styles. Some people use scripts to change the site and we
want them to use MQ to design pages for display
technologies.
cabanier: Originally we called the property 'reality', but it's for
other technologies too so we came up with
'environment-blending name'. I think fantasai had concerns
about virtual reality. If she could expand.
fantasai: I had a handful of comments on how spec was written, but
aside from that...There was a comment on how opaque vs
additive. Additive was if you're blending with real world
but you could blend the canvas of page with virtual world
as well so I was saying description should be adjusted.
cabanier: So it doesn't need to be real world...real or
virtual...like your desktop event.
fantasai: Yeah
cabanier: Okay. I think we can do that.
florian: In principle I support. Need to explore details. One thing
I was wondering about, if it falls under something
described...something like an overhead projector slide with
a default transparent background.
cabanier: Like an additive display but you could also add darkness.
florian: I guess. Opaque but default transparent
cabanier: Yes. I think maybe could add later. Webpages are defined
opaque by default and you'd have to change that.
florian: I didn't want to dive into details, but in wording of
options and list of options...we'll need to iterate. MQ5 is
fairly speculative so I have no issue adding it there and
working with it.
cabanier: And as I mentioned on PR is you want to see what we're
trying to do we have videos on our home page of the things
we want to do.
cabanier: I'll update wording to say real or another virtual.
Rossen: Sounds good. Sounds like neat feature.
Rossen: I'm hearing support to proceeding forward.
Rossen: Any other questions/opinions to Rik or should we resolve to
continue this in MQ5?
RESOLVED: Add environment-blending to MQ5
CSS Transforms
==============
Smarter interpolation of truncated transform lists
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/927
krit: There's one issue on smart interpolation for transform
functions. You have to interpolate when there's an animation.
Usually they have to have same parameters to map. Every time
those functions do not match there is matrix interpolation.
krit: Previously we allowed the transforms to be of different size.
As long as they map to same size we do the interpolation per
transform function. Concern was this wasn't good enough.
krit: In this issue request is interpolation per transform function
as long as they match with each other. If they do not match we
do matrix interpolate but just for the ones that come after
the non-matching
krit: Support from TabAtkins, request from smfr to defer to L2. I
think we keep what we have b/c it's interop.
krit: I don't think we can defer because it would change animation
in certain situations. Doesn't happen too often that you don't
have 2 matching and an animation.
krit: So do we agree to this proposal? Or do we keep the current
spec text where everything multiplied to a matrix.
krit: Complex, but important for animations.
krit: Questions on what the request is?
fantasai: I agree with making the animations do closer to what
authors expect and making them more powerful in terms of
accurate representation. In favor of the change.
fantasai: Only question I have is we're using the prefix and padding
the end with additional ID transforms. Do we want to
allow...if the end of the transform list matches rather
then the beginning. You don't interpolate ones you don't
have, but if one sequence is a subset allow padding on
either side?
krit: There are requests to make it smarter, but it's complicated.
You have to find the pattern and there might be multiple
patterns so you have to decide.
fantasai: I'm suggesting it has to be exact match. If you have
multiple we pick a rule like match against the first one.
krit: I'm a bit confused. You want them to match on start or end and
only if same length?
fantasai: Different, but only if one is an exact subset of the other.
krit: List 1 is a subset of list 2
fantasai: Yes.
krit: And only beginning or end or also middle?
fantasai: Both. Middle or end.
dbaron: I worry matching in middle will be harder to understand. We
want behavior to be good and understandable and expected.
Matching in the middle feels...oh, it'll randomly search,
but only if you have an exact match of sequence. I think
there's value in doing something simple and explainable.
fantasai: Okay. That's fine. I wanted to know if it was thought
through.
krit: Does the issue in question have support? Everything matches at
the beginning but not end so we do matrix for the things that
do not match at end?
fantasai: Seems fine
krit: Looking for browser impl feedback as that's not impl.
krit: If people need time it's fine, but input at some point would
be great.
Rossen: smfr isn't on the call. We are going to make this change as
a part of transforms L1, right?
krit: Yes, need to for L1 because if we do L2 there will be
unexpected repercussions for Animations.
Rossen: Do people feel they need more time? Can we resolve now and
reopen if needed? Preference?
Rossen: Objections to...krit, wording?
krit: I'm not proposing. I'm in favor of not changing text
Rossen: Proposal: No change to the current specification
krit: Only because it's impl currently.
Rossen: Objections to stay with current impl behavior and not change
transforms L1?
fantasai: We've talked about if we make this change it should be L1.
krit: Correct
Rossen: Yes if we make the change it should be L1.
fantasai: So asking to not change ever?
Rossen: No, we can defer this to L2 but for L1 we can stay with
current impl solution in the spec.
fantasai: If you want to eventually make this change, why not put it
in L1?
krit: Depends on impl interest. If there isn't doesn't make sense to
put it in.
fantasai: I don't think it makes sense to decide if we're putting in
L1. If we do it it should go in L1. We can put it in L1
and mark as at-risk. This is a WD still.
fantasai: The longer that we don't impl, content...this is a change
in an existing deployed feature. If we want a change we
should do it sooner rather than later. Waiting doesn't
seem should do.
Rossen: But I'm not hearing impl step up.
florian: Then we shouldn't have it at all rather than have it in L2.
Rossen: And that's the no change resolution. Don't impl it.
Rossen: Any interest in working on this feature? If not we can
resolve on rejecting it.
fantasai: Note that birtles and TabAtkins aren't here. Can anyone
represent their positions?
Rossen: People from Mozilla or Chrome on?
Rossen: None to represent this issue.
fantasai: I recommend that given they're not here and critical we
resolve on if we do it this is how and then the question
of do we do it waits until next week.
Rossen: We can try and get to this in F2F.
fantasai: You can resolve on how interpolation happens.
Rossen: Prefer not to in absence of the people you mentioned. If
will discuss at F2F let's do it at that time.
CSS Syntax
==========
Consider disallowing NULL code points in stylesheets
----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2757
Rossen: Can anyone handle "Consider disallowing NULL code points in
stylesheets"?
<fantasai> Tab's position:
https://github.com/w3c/csswg-drafts/issues/2757#issuecomment-396337601
florian: The issue is that having a null codepoint in the middle of
stylesheet is not useful in general, but is a potential
security risk. Could single something like a code extract.
Therefore we should kill the stylesheet somehow. How and
how much should be discussed. Possibly reject entire
stylesheet or a milder version
florian: Going further I'm not the right person, but that's high
level.
hober: Is there current interop?
florian: I believe not. Current is that browsers discard, but how
they recover doesn't seem interoperable.
florian: There are mentions of differences in the issue. How
different I'm not sure.
Rossen: I ran through all of these locally. I was seeing interop
between Edge, Chrome, and FF on all the test cases in the
issue.
Rossen: Curious to hear from dbaron and if he's thought about it.
dbaron: Sounds like emilio has but I haven't.
bradk: Any idea how often this is in the wild as possibly a mistake?
Rossen: Not sure we have such data.
Rossen: If you're asking how often people try and spoof browsers
it's quite often and this is a potential attach vector, but
this is more speculative.
florian: Question is how often do we have almost valid style sheets
that were meant to be read.
Rossen: Don't think we can disambiguate between.
bradk: Concern is break working stylesheets.
Rossen: My understanding is you could have actual end user effects.
bradk: Will this break websites?
Rossen: Potentially.
plinss: Tooling injecting null bytes is fairly low unless they'll
already be present
florian: Current possible interop you Rossen observed is it
reasonably safe or interoperably unsafe?
<Rossen> http://jsbin.com/vozudorilu/edit?html,output
Rossen: I won't make statements in terms of this as an attack
vector. From interop, I just re-ran a variation on some test
cases I observe differences here ^
Rossen: In this case you join the null character. This invalidates
in Chrome the entire selector. In FF and Edge we only
invalidate the join part of the last selector and honor the
first part.
Rossen: Result is after joining selector with null Edge and FF get
red and black default in Blink
florian: I get black in FF
Rossen: Well...I don't know version.
florian: 61. Updated today.
Rossen: I'm on 60. Let me take the 61 update
emilio: Nightly shows red to me
Rossen: So there is non-interop
Rossen: FF 61 I still see red
* liam gets red on ff61 here
fremy: I see red in every browser
Rossen: Instead of debating this test case. Let's go back to the
behavior in issue.
florian: Safe proposal is if you see any null discard entire
stylesheet
fantasai: 3 proposals
fremy: I don't see doing that. I don't see why a null byte is a
security issue. I don't see why discard an entire stylesheet.
* emilio agrees with fremy
florian: One null bit not dangerous. There's no known use case but
can be sign of attack.
fremy: Any JS is sign of potential attack.
Rossen: That's not only option. It's *A* option.
fantasai: Others were terminate stylesheet at that point. 3rd option
was auto invalidate any construct with that null according
to normal invalid rules
<fantasai> e.g. invalidate declaration, or style rule, or whatever
construct we would normally invalidate
Rossen: 3rd makes most sense. Finding the closest adjacent or
encompassing rule/select/whatever and discard that is most
intuitive.
<bradk> Option 3 seems most reasonable to me
<gsnedders> I agree with fremy, given we don't do the same in HTML.
Rossen: 2nd is a variation of that and almost as bad as discard
entire stylesheet.
plinss: Another option is ignore null and pretend it's not there.
Rossen you seem to favor terminate existing construct, but
that's most dangerous for security because it means you have
to pass it through. If you ignore the null or terminate or
discard you can do that at pre-parse and then you're safe.
<liam> +1 to plinss
fremy: Still don't understand premise null bit is unsafe.
florian: It may be a telltale sign something else is being
attempted. If someone is dumping content of memory you'll
see null bits.
plinss: Risk is you have some code that takes entire construct with
the null in the middle and others that terminate the string
and you're opening to security vulnerabilities.
<fantasai> plinss, wouldn't handle Tab's concern in 1st paragraph of
https://github.com/w3c/csswg-drafts/issues/927
Rossen: Thinking a bit more I like the 4th option to ignore null
codepoints during pre-parse and curate the stylesheet as if
there were no code points.
florian: If you dump memory without nulls you can still export that
to some server.
gsnedders: As precedent html replaces null with +fffd in some cases
and that's better then drop.
plinss: [missed]
florian: Then not dealing with security problem. If you keep null
bytes you can keep them on server.
fremy: I don't buy it. I think it's pointless. If you're able to
dump memory you can literally do a JS script. The whole
premise makes no sense. I see no reason to not use syntax.
Browsers can impl css syntax and do what it says. I don't see
why do something special because then you create edge cases.
fremy: I think premise of thread is not based on something real. I
haven't seen anyone from security team say it's real. If no
one from security says it's a problem we should fix I don't
think we should make any change to algo. There's no strong
indication of a problem. If we agree to make a change from
security we need someone from security.
florian: How do we handle this? If we say a browser has a known
vulnerability on this how do they discuss it with us?
gsnedders: Member only.
florian: Is that private enough?
liam: There's also a team-only list.
Rossen: We can either postpone to F2F and discuss in person to see
all the concerns and options. Or at least we can record the
preference of the listed options as at least a proposed
resolution
Rossen: 1 drop entire stylesheet. 2 drop stylesheet after null. 3
drop encompassing selector around null. 4 drop null during
pre-parse.
Rossen: That's what's on the table. Only remaining question is do we
want to resolve on any of those?
??: Also option of no change.
Rossen: Yes
fantasai: I would say we've had a good discussion. List the options
in the issue, request TAG review, give people time to
think.
Rossen: Exactly. That's why I wanted to repeat the options.
Rossen: Doesn't sound like we'll resolve. Discussion worth
capturing. Potentially with TAG assistance or at F2F we can
resolve.
CSS Display
===========
Use "computes to" instead of "behaves as" for display: contents on
unusual elements
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2755
fantasai: We had said that display:contents behaves as display:none
on certain elements like some SVG. There's an appendix of
exactly which ones. emilio filed an issue to just say
computes to display:none since that's easier from impl
then handling that at used style time.
fantasai: TabAtkins and I have not much of an opinion. Up to
implementors.
emilio: To be clear everyone that impl computes to none?
Rossen: Any reason to do anything other than that? Sounds like
there's interop.
Rossen: Objections to serialize it out as none?
RESOLVED: compute to none
CSS 2
=====
empty url() behaviour needs errata to match Level 3
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2211
gsnedders: Issue is TabAtkins wanted to review resolution given he
wasn't on call, but we should wait for TabAtkins to be on
a call.
CSS Sizing
==========
Incorrect use of the word "compute" in definition of intrinsic keyword
values
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2708
<fantasai> https://github.com/w3c/csswg-drafts/commit/b603bfb33da70080b83f78e74f41c8af89b9b88b
fantasai: Changes are ^
fantasai: The min-content and max-content keywords and that type are
currently defined to behave as property initial value if
spec in block axis.
fantasai: Spec says they compute to property initial value so auto
on height or none or max-height.
fantasai: Mats would prefer it to say "behaves as" rather then
"computes to"
fantasai: TabAtkins and I have no strong opinion. Up to impl.
fantasai: Example from Mats is if you explicitly inherit height and
gave one of these keywords you should get that keyword.
Makes sense, but can't imagine anyone inheriting height.
dbaron: Issue is impl have to impl what spec says and that can be a
pain to do.
florian: If no real use case and simpler thing to impl, why not?
dbaron: Note one interesting point that request is the opposite of
the request a few issues ago.
fantasai: Yep
dbaron: Maybe figure out underlying principle. Maybe if it's a
property that effects type of boxes.
Rossen: Any reasons to not word it as "behaves as"?
Rossen: I sympathize with Mats and having dependency between
properties when computing the value of others is usually a
thing to avoid. By not being a strict as current wording it
at least doesn't explicitly say this is what it is.
Rossen: We're not fixing issue by changing wording.
Rossen: For current sizing spec, are we okay make the change to
"behave as" instead of "compute".
Rossen: Objections?
fremy: Wasn't change to revert?
Rossen: Revert what?
fantasai: Resolution asked is to accept the change
florian: Reverse is earlier issue
Rossen: I said change to behave as instead of compute.
RESOLVED: Change to "behave as" instead of "compute"
Rossen: What's 2 minutes?
CSS Text 3
==========
Audit details of break-spaces value against use cases
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2465#issuecomment-400171764
florian: Reopening.
florian: We discussed for 3 years having a value called break-space
on the overflow. Chrome and Igalia are mid-impl. Current
syntax is not ideal. Would like to change it. I'm not
enthusiastic, but their proposal is as good as what we've
written and it's to implement so I'm in favor
fantasai: Proposal came from discussion with me and koji where koji
said properties that takes multiple values is harder then
one value. Requested long hands so one can take break-word
and the other break-space. Reason for separate property is
if they need to cascade separately. That does seem to be
the case for these values. I can see why break-spaces and
break-rule would be different
fantasai: Also notices break-spaces is only ever set with pre-wrap
on whitespace. You'll never cascade independently. Makes
sense to move this from overflow-wrap to whitespace prop
and then it would be mutually exclusive keywords
fantasai: That's how got to proposal
fantasai: Improvement to cascade behavior. We're cascade
independently things that can be and not things which
can't. I'm in favor of proposal.
florian: So am I, koji, and Javier
Rossen: Objections?
RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/2465#issuecomment-400171764
<astearns> https://www.eta.immi.gov.au/ETAS3/etas
dbaron: One thing from astearns in IRC. Apply for an ETAS to
Australia if you haven't and need it for immigration.
Rossen: Yes, please make sure you can enter Australia.
Rossen: See you all in a week.
Received on Wednesday, 27 June 2018 23:43:32 UTC