- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Sat, 23 Dec 2017 10:01:22 -0500
- To: "www-style@w3.org" <www-style@w3.org>
- Cc: "public-fx@w3.org" <public-fx@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.
=========================================
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