[CSSWG] Minutes TPAC F2F 2017-11-07 Part III: 3D Transforms, Scrollbars, Selectors, Color Spaces [css-transforms][css-scrollbars][selectors][css-color]

=========================================
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.
=========================================

CSS Transforms
--------------

   - Consensus seems to be that an overflow clipping element should be
       forced to transform-style flat but not a stacking context, and
       should allow perspective to be specified on itself
   - Discussed whether transform-style: flat should create a stacking
       context and what it would mean if it does / does not.
   - Issue #1944: 3D Context Penetration needs examples and test cases
       written into the issue to help reach a conclusion.
   - The description in the ED for transform-style: flat needs to be
       improved (Issue #1950), but will require looking into what
       current behavior is and choosing the most-compatible approach.
   - Defining an interoperable epsilon for coplanarity (Issue #1953)
       is problematic because of floating point precision; authors
       should avoid relying on it. Whatever spec ends up defining
       will need testing to ensure web compat.
   - RESOLVED: Add trchen as editor of Transforms 2


Scrollbar Colors/Scrollbars Spec
--------------------------------

   - tantek wrote a specification for the older properties to control
       scrollbars so that they can be formally defined an implemented.
   - There was sentiment that not all of the properties were really
       needed.
   - Exposed controls shouldn't override default browser behavior, just
       offer some basic controls authors have been looking for.
   - RESOLVED: Adopt css-scrollbars as ED

Selectors
---------

   - RESOLVED: Add a functional pseudo-class with 0 specificity to
               selectors level 4 with a TBD name.
   - RESOLVED: Add :target-within to selectors 4.

Color
-----

   - ChrisL will continue working with experts to define the working
       color space proposal (Issue #300) so it can be added to the spec.

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

Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda


CSS Transforms
==============
Scribe: chrishtr

   [This session was concurrent with the Accessibility Joint Meeting]

3D context penetration
----------------------
   github: https://github.com/w3c/csswg-drafts/issues/1944

   <smfr> Explainer doc: https://docs.google.com/document/d/1FIQW9qVPbZxn0pifFOXWWK0-7fXrjlSeYeZN7wHmIHo/edit
   trchen: How should overflow clip interact with 3d?
   trchen: ED spec requires overflow clips to force flattening and a
           stacking context
   trchen: making overflow clip a stacking context would break legacy
           content.
   trchen: It seems most implementations flatten children of overflow
           clips but do not induce a stacking context.
   dbaron: There was not an intent to make overflow clips a stacking
           context, does it have to?
   trchen: Thought the reason was to avoid parallax
   trchen: but 3d content has a separate texture backing in Chrome/
           Safari anyway
   smfr: Clipping has to happen in 2D if it's going to happen, so that
         means you have to flatten if you are going to apply it
   smfr: Transform-style: flat currently forces a stacking context in
         the ED spec, maybe that has to change?
   trchen: Grouping properties for a stacking context, there is no way
           to avoid that
   trchen: but overflow clip needs to force transform-style flat, but
           not be fully grouping.

   trchen: Next question: how should non-stacking overflow clip behave?
           in particular how does the flattened result stack against
           other elements in the containing stacking context?
   smfr: Should lie on the z=0 plane
   trchen: How to sort against other z=0 children?
   smfr: Do 3d children depth sort before flattening?
   trchen: Mozilla, blink, edge follow TR generally, safari somewhere
           between TR and ED

   smfr: One use case of overflow scrolling + 3d is parallax
   smfr: If overflow other than visible forces non-stacking flattening,
         how are transform matrices accumulated? does it kill parallax?
   matt woodrow: Does not kill parallax
   matt woodrow: Edge forces a stacking context with overflow clip +
                 transform-style: preserve-3d
   chrishtr: Chrome also forces a stacking context in this case
   trchen: In edge overflow clip with transform-style preserve-3d
           behaves like a 3d context root, but still inherits non-3d
           matrices across it
   trchen: Unsure what chromium does, we can implement edge behavior if
           needed.
   trchen: Maybe we should force flattening but sort children
   smfr: Wouldn't that kill parallax?
   trchen: Perspective on the overflow hidden element will still apply
           as expected for parallax
   smfr: Agree that this should work
   trchen: Adding perspective on the overflow clipping element will
           also cause it to be stacking, which is a nice property
   smfr: Perspective is a way to apply an additional matrix to
         descendants
   smfr: preserve-3d is a way to define 3d rendering contexts of sets
         of elements/a space into which subtree elements will 3D sort
   smfr: Convenient to think about hoisting the children up to the 3d
         rendering context root
   smfr: preserve-3d prevents flattening, you should not apply it to
         the root, should apply to intermediate elements between root
         and 3d descendants. Perspective should be on the root (note:
         all this is info from smfr on the ED way of thinking)
   chrishtr: Consensus seems to be that an overflow clipping element
             should be forced to transform-style flat but not a
             stacking context, and should allow perspective to be
             specified on itself

   trchen: Still need to resolve z-index sorting
   smfr: Comment about z-index above is not specific to overflow clip,
         it's a general thing
   marakow: is there a github issue?
   <chrishtr> https://github.com/w3c/csswg-drafts/issues/1944
   chrishtr: The above link is for the explainer.
   marakow: We need all these examples and testcases written down.
   chrishtr: trchen will take this action item.
   trchen: Overflow clip is special for z-index because we need to do
           "premature" flattening
   smfr: ED currently says that transform-style: flat is a stacking
         context
   trchen: Prefer to remove that clause from ED
   <dbaron> The whiteboard drawings are:
   https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0006/IMG_20171107_115421.jpg

transform-stye: flat
--------------------
   topic: https://github.com/w3c/csswg-drafts/issues/1950

   smfr: New issue to discuss: how is transform-style flat specified if
         changed? more generally, how does this affect how 3d contexts
         are defined?
   trchen: [showing example of isolation:isolate parent with two 3d
           children with different z coordinate]
   smfr: ED spec says that if the parent has content in its plane, then:
   smfr: in the same way that negative z-index children paint in front
         of the stacking context's background, but behind its foreground
   smfr: a natural extension to 3D is that the background of the parent
         is painted, then the "Foreground" content is a plane which is
         intersected with 3D child planes before flattening
   smfr: All content with any z-index is drawn together into the same
         plane
   smfr: All content without any 3D, that is
   trchen: Then an element with preserve-3d will extend the 3d context
           to the parent
   smfr: It's common for sites to have a "card flip animation" effect
         in their UX. It looks wrong if that card intersects the
         background of the container, and maybe also the foreground
   smfr: so the proposal here might have compat problems
   smfr: Alternate possibility is that the depth component is simply
         dropped and transforms become a "paint effect" that changes
         the output of its content
   trchen: Chromium currently does the paint effect thing
   marakow: Not sure about edge behavior with an example. card-flip
            cases had compat issue in the past
   smfr: We need to do testing and choose based on compat concerns
   smfr: If you really want sorting of any kind with 3D transforms, use
         preserve-3d, otherwise we need to do something reasonable for
         compat

   trchen: Flattening is really very related to stacking context, so
           it's hard to define things
   trchen: All elements have a screen transform matrix of some kind
   smfr: Isolation implies flattening, so 3D children should be
         flattened into its plane
   trchen: But then how is the rendering matrix for those 3D children
           defined, since the containing block is above the isolation
           element?
   smfr: Doesn't seem necessary to compute the root-relative matrix.
         Can compute relative to its 3d context root only

   chrishtr: Can we make the isolation element a containing block for
             3d children?
   various: What about filters, opacity, etc?
   chrishtr: Filter is already a containing block for all children in
             Mozilla
   <dbaron> mozilla filter containing block changes were in
            https://bugzil.la/1125767 and https://bugzil.la/1187851
   smfr: Should be able to compute the geometry one way or another

   gregwitworth: What are we trying to solve here?
   chrishr: ED spec is ill-defined, need to define somehow
   dbaron: Spec should be clear. Should keep things aligned with compat
           and developer expectations as much as possible
   smfr: Web compat in this area may be bad enough that we can make
         what decision seems best
   ericwilligers: Is it too late to make containing block and stacking
                  context agree?
   trchen: Too late to fix this.
   smfr: Containing block is for geometry, stacking context is for
         rendering
   marakow: These things may be corner cases, but web developers may be
            depending on them accidentally
   trchen: But they will get divergent behavior across browsers if they
           don't agree on compat
   marakow: testcases are critical

   <smfr> i filed https://github.com/w3c/csswg-drafts/issues/1951
   <smfr> i filed https://github.com/w3c/csswg-drafts/issues/1952 on
          the no-op div issue

   trchen: Back to discussion about how to do overflow clip flattening
           without stacking context
   trchen: How should flattened result of 3d children sort against
           other children?
   mwoodrow: In Mozilla in these cases, the overflow hidden element
             does not have preserve-3d on it
   mwoodrow: so it does not sort anything
   mwoodrow: In mozilla, the 3d child flattens itself
   mwoodrow: Mozilla looks at the DOM parent to determine whether to
             avoid flattening
   trchen: Chromium flattens if the parent has positioning, is a
           stacking context or has clips, but not otherwise. this is a
           consequence of the implementation more than anything else
   smfr: Making no-op parents flatten seems to be a breaking change
   mwoodrow: Maybe not? Not aware of issues against Mozilla due to this
             behavior
   trchen: Perhaps we can change transform-style to apply only if it's
           a stacking context

Handling of coplanar elements
-----------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1953

   trchen: Fourth topic: coplanar planes is a computationally
           intractable issue
   trchen: because of floating-point accuracy issues
   ericwilligers: Found the animation example here compelling: don't
                  want one frame of an animation where "coplanar"
                  returns true
   trchen: Doesn't make sense to specify the epsilon for coplanarity,
           because of implementation difficulty
   <dbaron> drawing #4 on the flipchart is 
https://lists.w3.org/Archives/Public/www-archive/2017Nov/att-0007/IMG_20171107_123911.jpg

   marakow: Is the recommendation to say the behavior is undefined?
   trchen: Yes
   marakow: Should be able to define an epsilon
   trchen: Two planes that are extremely close to the epsilon threshold
           may result in floating-point accuracy issues
   marakow: Unspecified behavior does not achieve compat

   trchen: The ED spec has a TODO item to define subtree planes
   trchen: Webkit and blink create a plane if there is any 3D transform.
   trchen: Mozilla looks at the final matrix to see if there is 3D
   dbaron: Thought the spec already said this?
   dbaron: Seems good to match webkit/blink behavior for defining planes

   smfr: On coplanar: a good example of making things coplanar on
         purpose is a flipping card
   smfr: One way to implement is two elements, one of which flips
         relative to the other
   smfr: This will result in coplanarity numerical issues
   smfr: Another way to do it is to put the transform on the container
         instead and flip it
   marakow: Hit bugs where authors failed to specify
            backface-visibility:hidden and ended up with fighting/
            coplanar problems
   trchen: Coplanar is not even what developers would want because it
           results in one thing always being on top
   trchen: I think we should make it undefined, and advise developers
           to not draw plans within these epsilons
   gregwhitworth: Need to make things as specified as possible
   marakow: Still think this should be specified, but ok to have a note
            in the spec that it's not a good idea to depend on exact
            behavior
   marakow: All of the items in the explainer are real and good to fix.
            but we need to do a lot more discussion based on testing
            and additional research to resolve them

Editorship
----------

   smfr: I would like to propose adding trchen as an author for
         css-transforms-2
   Rossen: Any objections?
   RESOLVED: trchen added as editor of Transforms 2


Scrollbar Colors/Scrollbars Spec
================================
   Scribe: fantasai
   topic: https://bugzilla.mozilla.org/show_bug.cgi?id=77790
   github: https://github.com/w3c/csswg-drafts/issues/1955

   tantek: Background for the discussion is this is a 17-yr-old set of
           properties introduced by winIE5.5
   tantek: We've resisted standardizing, but FF has discovered some
           compat problems
   tantek: Trying to capture 80/20 of use cases, which is scrollbar
           properties
   tantek: Linking to bugzilla issue of first request
   tantek: links to more issues and sites
   tantek: many sites wanting/using this.

   tantek: There are sites saying “don't use Firefox because they don't
           support colored scrollbars”
   fantasai: ?????????!
   <tantek> https://github.com/tantek/css-scrollbar-style
   tantek: These are the properties that shipped unprefixed IE5.5-IE8
   tantek: IE9 has -ms- prefix
   tantek: All authoring guidelines suggest using without prefix
   tantek: We can spec as published, which is essentially what I've
           tried to do.
   tantek: asking wg if can adopt as ED
   <Chris> https://stackoverflow.com/questions/25480565/how-can-i-create-custom-scrollbar-for-mozilla-firefox-with-css
   <leaverou> https://tantek.github.io/css-scrollbar-style/Overview.html
   <leaverou> to see it with normal CSS paste this in the console:
              document.querySelector("link").href='https://drafts.csswg.org/default.css'

   Rossen: So asking for feedback on adopting this in CSSWG?
   tantek: Yes.
   <gsnedders> I am strongly, strongly, strongly in favour of having a
               CSS spec for this.
   Chris: Any indication that ff will adopt and webkit will drop
          -webkit- and do this instead?
   tantek: Yes, at Mozilla we intend to intend this, and having a spec
           is precondition, which is why I'm spending time on it.
   TabAtkins: We would like to drop as much of our weird -webkit- stuff
              as possible.

   TabAtkins: Beyond color which is important, other use case we found
              important to address is scrollbar sizing.
   TabAtkins: Most Google properties using custom scrollbars are doing
              it to get skinnier scrollbars.
   TabAtkins: So I think we need to add that, but other than those two,
              don't think we need anything else.
   tantek: For our analysis 80/20 was color, sizing far behind, but
           good feedback that Google thinks sizing is critical.

   smfr: We're interested only in very limited customization of
         scrollbars. Would like to get rid of -webkit- scrollbar pseudo
         stuff.
   smfr: we're only interested in coloring, and hiding scrollbars.
   smfr: Currently ppl use hack of setting display: none on scrollbar
         thumb in order to hide the scrollbar.
   smfr: Really really don't want
         scrollbar-color-3d-face-something-something.
   <leaverou> +100 to smfr
   smfr: I won't implement it.
   smfr: Historically, I think mistake to put OS-specific color things
         into CSS specifications.
   smfr: This has assumptions that there are these things you can apply
         these colors to.
   smfr: e.g. on mac we don't have scrollbar arrows
   <tantek> these are the properties in the spec that have been adopted
            by sites: scrollbar-3dlight-color, scrollbar-arrow-color,
            scrollbar-base-color, scrollbar-darkshadow-color,
            scrollbar-face-color, scrollbar-highlight-color,
            scrollbar-track-color, scrollbar-shadow-color
   tantek: Some of these properties affect others, details below
   tantek: so authors can omit specific pieces.
   tantek: Maybe don't need to specify those specific pieces
   tantek: so open to dropping some properties if superfluous.
   tantek: Wanted to start with exact set that have been on the Web
           since 2000 and use compat as the argument to start draft.
   tantek: If we can make simplier, all for that.
   tantek: I am pro reducing the set if that helps the concern.
   <Chris> "Implementations may ignore any scrollbar part color
           properties for scrollbar parts that do not exist on the
           underlying platform."
   smfr: Want to avoid properties that flip the scrollbar from looking
         platform-native to something different
   smfr: so I support allowing customization of the appearance of
         scrollbar in terms of applying colors, but not looking
         completely different.
   <fantasai> +1 to smfr
   bradk: In Gmail it looks completely different. Square, visible all
          the time.

   leaverou: Agree with smfr, strongly support styling scrollbars but
             OS-specific low-level control doesn't belong in CSS
   leaverou: Even if it does, can add it later as longhands for a
             shorthand.
   leaverou: Just to give a color that dominates, would go very far.
   leaverou: These are very repetitive. Although Tantek said some set
             by others, seems like you have to repeat the same color
             and do many calculations to cal lighter/darker variations.
   leaverou: Authors shouldn't have to do this.
   leaverou: All we need to start is a scrollbar-color and
             scrollbar-width.
   tantek: Existing examples, typically two colors
   tantek: Then they copy/paste those into pieces they want to style in
           that fashion
   tantek: some might be superfuous.
   tantek: But general pattern is a light color and a dark color that
           matches their theme
   tantek: hard to do just one color.

   tantek: The other comment I'll make is to smfr wrt rendering
           flattened look.
   tantek: Some sites doing this, that's exactly their goal.
   tantek: Want a scrollbar that doesn't stand out at all compared to
           the rest of their visual design
   tantek: ...
   tantek: At this point Web devs are clamoring for that level of
           control, and having gotten used to that level of control in
           native apps their expectations have changed from the past.

   <leaverou> btw a classic example where authors need scrollbar
              styling: http://dabblet.com/gist/b639cbdd5c7b3e48e9d1e0a5af188869

   xidorn: Question to Tab, is there any use case that wanting to widen
           the scrollbar
   xidorn: or just make it thinner?
   xidorn: So we want maximum width of scrollbar rather than just the
           width.
   melanierichards: Not always, sometimes want to have a chunky
                    scrollbar
   melanierichards: to make it more prominent.
   Rossen: For ease of touch, there are apps who will restyle and add
           larger UI in general to make the hit areas larger;
           scrollbars are one of them.
   Rossen: Other cases hide scrollbars for panning
   Rossen: So might want to change width in either direction
   xidorn: I raise this because concerned about specifying exact width
           of scrollbar, that may be narrower than native scrollbar on
           windows but not on Mac.
   xidorn: Which may make the visual effect odd on some platforms.

   Rossen: Hearing a bunch of interest.
   Rossen: Some things here
   Rossen: Still need to resolve on adopting this
   Rossen: as a WD
   Rossen: or ED.
   Rossen: Guessing one reason to keep it out of css-ui-4 is to make
           this a very quick spec to REC?
   tantek: Yes.
   fantasai: Yes, if the concern is getting it to REC faster, then can
             just have it part of UI, and then when you want to
             transition to CR, drop the other parts of UI to L5.
   tantek: Different because don't want to invent a bunch of new stuff,
           want to just get compat with minimal work, very different
           than what UI 4 is scoped for.
   tantek: So semantically deserves its own draft.
   fantasai: Might be helpful to your work, but not helpful to people
             using the specs if related features aren't together.
   Rossen: Let's see how it goes first.
   Rossen: Objections to adopting as ED?

   RESOLVED: Adopt css-scrollbars as ED

Selectors
=========

   Scribe: eae

Functional pseudo-class like :matches() with 0 specificity
----------------------------------------------------------
   github: https://github.com/w3c/csswg-drafts/issues/1170

   leaverou: As we all know specificity tries to infer importance from
             selectors. Resulting specificity might not always be
             logical.
   leaverou: My favorite example of specificity not being a good
             heuristic is using the not pseudo class.
   <leaverou> div:not(#foo):not(#bar):not(#baz)
   leaverou: ^^^
   leaverou: In this example we want to target all divs except three,
             yet gets very high specificity.
   leaverou: Especially for libraries, when trying to be specific, it
             is hard to override.
   leaverou: Uses something called BEM- encodes selector in class name
             and uses js to apply it.
   <bradk> http://getbem.com/introduction/
   leaverou: Authors are willing to not use selectors at all, to bypass
             specificity.
   leaverou: One way to fix this would be to define selectors with a
             known specificity of one, would allow last selector win
             and make it easier to override.
   leaverou: I.e. put all nots in a single pseudo class. Easy solution
             vs other ones like per origin.
   leaverou: Lets one be very specific with regardless to specificity,
             can be selected per selector and solves most of the known
             problems.
   leaverou: Something that could be done as a pre-processor.
   leaverou: Many names have been proposed, we can bikeshed that.

   fantasai: Seems like a reasonable idea to me. The fact that authors
             can chose which parts of the selector applies to
             specificity sounds good to me.
   fantasai: Lower priority for an entire style sheet, library author
             might want to allow the entire stylesheet to be allowed to
             be overridden by author rules. [could be a different feature]
   leaverou: Example: in mavo there is a toolbar that has a class of
             mv-bar, also class of mv-ui that means apply default
             style. Want author to be able to overrule using just
             mv-bar but I don't want their "div" rules to override.
   bkardell: I don't think they are mutually exclusive. May be that you
             can do an awful lot for a whole bunch of things and we
             know we can do that easily.
   bkardell: For a number of polyfills that I have worked on this would
             have been really useful.
   bkardell: There are things like headings that need to take aria
             roles into account that make them have very high
             specificity which makes it hard to override.

   bradk: Seems to me like we could solve this without taking
          specificity all the way down to zero.
   bradk: Specificity only matters when there is a tie.
   bradk: If there is a tie when it comes to ID or class, if the ID
          selector inside the function was more specific then outside
          the function that would solve the same problem while still
          allowing specificity.
   leaverou: As discussed in issue, if we have fractions of specificity
             that introduces new levels of specificity and no one is
             suggestion that the entire thing doesn't have specificity.
             All the classes and IDs outside of it still applies. It
             allows the specificity to be controlled. To have it count
             as a class you would just add it to the end, a bit hacky.
   bradk: No use case for specifying it for the entire selector?
   leaverou: Yes but usually not. You would only want to put some
             criteria in the pseudo class. Like all the :not()s in
             the first example.
   leaverou: Makes it less predictable. Now we know that we can count
             the number of IDs, number of classes, tags etc. If it is
             always zero it is very obvious, if not it makes it much
             more complicated to compute it.

   TabAtkins: I agree in general with what leaverou is saying. Authors
              can often do just fine when specificity is in order.
              Opting out or in-order seems to match what users want.
   TabAtkins: As for chrome, we're happy with this, and would like to
              implement the stronger version of matches. This is
              easier, we might do this first.
   TabAtkins: We're supportive.

   florian: Let's put this in level 4 for now, we don't have a five.
   fantasai: [missed]
   Rossen: Let's add it to four.
   fantasai: Very simple feature, as long as we're happy with the name.
   ericwillgers: What about web platform tests?
   fantasai: Not in CR yet, not needed.
   <laughter>

   dbaron: One comment: I think it is worth noting that it is not clear
           how easy it would be to implement matches. This has most of
           the same risk.
   dbaron: One of the things with selectors, they're heavily optimized.
           Implementing without optimizations not very useful. With
           optimizations is quite a bit of work and not clear how
           quickly that can happen.
   fantasai: Start with implemented subset.
   TabAtkins: WebKit goes beyond spec, also has support for pseudo
              elements.
   dbaron: Caution in that it's being tied to a feature which has an
           uncertain future.
   fantasai: De-risk by having certain things in level 4 vs 5.
   dbaron: Other alternatives that solves leaverou use cases.
   leaverou: I don't want to reduce *all* of it to zero but only a part.
   dbaron: I don't have a syntax proposal at this time but would avoid
           tie to branching combinators.
   TabAtkins: Earliest version didn't support that, does now.
   fantasai: Making up a completely new unrelated syntax seems silly
             and doesn't make sense. Cut down on the syntax instead.
   dbaron: What doesn't make sense to me is spec moving so far ahead of
           what implementors are willing to do. Implementor buy-in was
           not a factor.
   fantasai: [mis-transcribed, therefore elided]
   <fantasai> that's not what I said
   <fantasai> at all
   dbaron: You're acting like we can only do everything or nothing.
   dbaron: I'm fine with the proposal but I do not think it's the only
           one.
   <fantasai> There shouldn't be anything in Selectors that didn't have
              a WG resolution to add.
   <fantasai> If there is, the editors made a mistake.
   <fantasai> If there was a resolution and you didn't like it you
              should have objected.
   <fantasai> Being angry about it now is neither helpful nor fair.
   ...
   <fantasai> Minutes where we resolved to allow combinators in
              :matches(), *at dbaron's request* -
              https://lists.w3.org/Archives/Public/www-style/2014Jan/0607.html

   leaverou: If implementors aren't willing to to implement a part of
             :matches() at the moment shouldn't we discuss that?
   dbaron: I think I bought this up when we went to CR.
   fantasai: Selectors are not in CR yet.
   dbaron: But people are going ahead to implement it.
   dbaron: This is the problem with sticking things in editors draft.
   Rossen: Would you prefer to see this go in in another way? If not
           can we try to settle on a resolution and go on.
   dbaron: Fine with matches without combinators under a different name.

   leaverou: I'm fine with that (adding combinators later)
   TabAtkins: The no combinators version is the one that desugars
              effectively. Start with simple version.
   leaverou: Still supports commas, right?
   TabAtkins: Yes.
   bkardell: Is there a suggestion to take combinators out of matches
             level 4 as well?
   TabAtkins: Yes.
   Rossen: Are you OK with that?
   leaverou: Yes, can we have a resolution?
   Proposed resolution: Add to selectors level 4 with a TBD name

   RESOLVED: Add to selectors level 4 with a TBD name.

   fantasai: Do we have a list of candidate names?
   leaverou: is, when, and filter
   Rossen: Any particular favorite we can resolve on right now?
   ericwilingers: I like filter
   Rossen: filter has the most plusses on github?
   * fantasai thinks is/when are a bit awkward
   leaverou: No, I think it was either is or when.
   <dbaron> filter is also the name of a property
   Rossen: You all work it out.
   Rossen: Let's move on.
   <fantasai> they're grammatical function words, not content words
   <bradk> i think "filter()" vs. "filter:" would lead to confusion
   * bkardell thinks it it weird if the capabilities of these two
              things (:is/:matches) aren't the same in what we agree to
              and we should have resolved on the capability of both at
              the same time

:target-within?
---------------
   github: https://github.com/w3c/csswg-drafts/issues/457

   leaverou: This is probably best explained with an example. Imagine a
             photo gallery, clicking a photo enlarges it, often done
             with pseudo and having an anchor with a hash url. Every
             time you click an image it becomes the target.
   leaverou: You also want to apply a style to the entire gallery
             without a selection, also done with target.
   leaverou: No way to target the state where there is no hash.
   leaverou: Suggested this on github but got no comments. Think it is
             useful and not terrible difficult to implement.
   TabAtkins: I see the use case and see similar uses, I'm supportive
              of the use case.
   dholbert: What if you have a photo gallery that also has some
             sections that aren't images that are still targetable by a
             hash?
   leaverou: Another use case for target-within as it allows you to use
             it on the image, which will apply both when the image is
             target or when it contains a target.

   Rossen: Any objections to target within?
   <tantek> +1

   RESOLVED: Add :target-within to selectors 4.


Color
=====

Working Color Space
-------------------
   github: https://github.com/w3c/csswg-drafts/issues/300

   Chris: This issue is about making computations on color boundaries.
   Chris: If used in a gradient, transitions, animations, etc.
   Chris: Right now, by default, given that we've never had anything
          outside of sRGB, is that it happens in sRGB which is
          unfortunate. You'll end up with the wrong color due to the
          gamma curve.
   Chris: We've had several resolutions where we don't have the right
          color space.
   Chris: In April we discussed this and someone suggested a linear 16
          bit color space.
   Chris: That would allow colors outside of the sRGB gamut to be
          expressed. Another option would be to have it be unbounded.
   Chris: I'd like to push this forward to have spec text about this.
   Chris: There will be people here at 3:30 that are experts in this
          and will have an in-depth discussion about it.
   Chris: One of the reasons I started this community group is to get
          expert input - should help the spec move forward.
   Chris: I don't have a better proposal yet. Does anyone have any
          thoughts on this?

   pkerr: You need to do you calculations in a linear space. Whether it
          is sRGB or float-16 that gives you the same flexibility but
          with better math.
   pkerr: Gives an infinite space between 0 and 1.
   Chris: The movie industry likes having absolute values defined.
   pkerr: Linear pixels is the way to go.

   dbaron: One comment: I'm fine with putting stuff in spec that isn't
           quite sure yet but please stick a note on it to explain that.

   smfr: You can't change the color space to be linear without breaking
         stuff. A lot of pages have assumptions that would break.
         Authors needs to opt in.
   pkerr: When I said use linear I meant use it for the math and then
          convert back, not necessarily switching everything to linear.

   RESOLVED: Chris to do more work :)

Received on Saturday, 23 December 2017 15:02:01 UTC