profile
viewpoint
Martin Balfanz martinbalfanz Mozilla Berlin, Germany http://martinbalfanz.com Product Manager @Mozilla

martinbalfanz/emacs-config 5

My emacs configuration.

martinbalfanz/grid-ng 2

simple grid system based on less.js

martinbalfanz/grunt 1

Grunt: a task-based command line build tool for JavaScript projects.

martinbalfanz/homebrew 1

The missing package manager for OS X.

martinbalfanz/html5-boilerplate 1

starting html/css template. so much goodness baked in by default

martinbalfanz/less.js 1

Leaner CSS, in your browser.

martinbalfanz/martinbalfanz.com 1

my personal site

martinbalfanz/bedrock 0

Making mozilla.org awesome, one pebble at a time

issue commentw3c/csswg-drafts

[css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color?

The change that would make in WebKit is that instead of serializing lab(), lch() and color(lab ...) as lab(), we would serialize it as color(lab ...).

I can see the logic of that. It would be a change to the spec too, but one I am certainly willing to make. Adding to the agenda this week to get more input.

samweinig

comment created time in an hour

startedEugeny/terminus

started time in 6 hours

issue commentw3c/csswg-drafts

[css-values-4] inherit() function: like var() for parent value, for any property

I just came across this issue again looking for something else.

@tabatkins wrote

Discussion with @dbaron suggested that the effect would be that you basically just sub in the serialization of the computed value (probably per the well-specified serialization in Typed OM).

If the property you're subbing in doesn't work for the property you're subbing into, it would follow the same rules as var(), and make it invalid at computed-value time.

So it sounds like there is a clear implementation path, but the discussion just stalled 2 years ago. Can we move it forwards?

I promised in the first post that if this is feasible, I could try and collect a list of use cases. Here are a few:

  • Many use cases for getting inherited custom property values #1962 [tweet by @plinss]
  • Font-weight values relative to parent (#2690, #2764) — and any other numerical typographic metric that can be specified in CSS, e.g. font-stretch, font-style (for variable fonts) etc
  • Many of the use cases for currentBackgroundColor (#5292) can be resolved with this
  • Child border-radius set to parent border-radius minus padding + border [source]
  • Swap foreground and background colors on certain descendant components 1 2 3
  • Decorative pseudo-elements that need access to the parent's background-color [source]
  • Child margin-left set to calc(-1 * inherit(padding-left)) 1 2
  • Store inherited property values in custom property to propagate to descendants [source]
  • Lots more cases, as answers to my tweet

In terms of how it should behave, a few more thoughts:

  • Does it return the parent value regardless of what it is, or walk up ancestors until it finds a value or hit the root? This is especially relevant for non inherited properties. It seems like it could be more useful if it returned the closest non-initial value, rather than the direct parent, but then there are no guarantees about what element you're actually getting a value from. E.g. consider the "swap background and text colors in children" above. What if the parent ends up not having a color set at all, and inherit(background-color) ends up walking up the ancestors and returning e.g. the page's background? OTOH, that might actually be the background you're seeing...
  • It should probably have a fallback, just like var(). The fallback would apply when the returned value is initial.
  • As @upsuper and @tabatkins pointed out above, if after subbing the value, the resulting declaration doesn't make sense, the whole thing just becomes IACVT.
  • Can shorthands be referenced? If so, what do they return? If they cannot be referenced, this means that when we turn a property into a shorthand, code starts breaking (this was already a risk, it was just limited to JS). Also this would mean that even fairly "obvious" use cases would become complicated (e.g. inherit(border-color) cannot be used).
  • Some potential names: inherit(), inherited(), parent(), ancestor(), closest()
LeaVerou

comment created time in 12 hours

issue commentw3c/csswg-drafts

[css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color?

No need to apologize, thanks for looking into it.

Not that this should play much all too much into how this plays out, but in WebKit, what we do right now is:

For rgb(), rgba(), hsl(), hsla(), any named color or color using the hex notation:

  • we store the color internally as sRGB-8888
  • we serialize as either rgba() or rgb() if alpha is 255

For color(srgb ...)

  • we store the color internally as sRGB-FFFF
  • we serialize as color(srgb ...)

For color(display-p3 ...)

  • we store the color internally as DisplayP3-FFFF
  • we serialize as color(display-p3 ...)

For lab(), lch() and color(lab ...)

  • we store the color internally as Lab-FFFF
  • we serialize as lab(...)

I've included the internal storage here because that is what we currently use to indicate to serialization what form it should use, but that is something that we can change if needed (we could, for instance store extra information about what style to serialize to, as we have some extra bits to spare in our color type).

Looking at this set, the thing that pops out to me as perhaps making the most sense would be to serialize all "new" (e.g. not those grandfathered into the 1rgba()orrgb()serializations) colors using thecolor(... )notation, and think of the other syntaxes as sugar in the same way thathsla()is sugar forrgba(). The change that would make in WebKit is that instead of serializinglab(),lch()andcolor(lab ...)aslab(), we would serialize it ascolor(lab ...)`.

samweinig

comment created time in 17 hours

startedhmans/three-elements

started time in 17 hours

issue commentw3c/csswg-drafts

"Can't be displayed" is undefined

Okay, this is now expressed as a three-stage process. First we look for a color that can be displayed (is valid, and is in-gamut for the display device). Failing that, we pick the first valid color, and gamut map that. Last resort, if all the colors are invalid, you get transparent black.

        The first choice for the value of  the ''color()'' function
	is that it represents the color
	specified by the first of its arguments that 
	<dfn export>can be displayed</dfn>,
	(that is, the first argument that isn't an [=invalid color=]
	and isn't [=out of gamut=]).

	If all of its arguments [=can't be displayed=]],
	second choice  for the value of the ''color()'' function
	is that it represents the color
	specified by the first of its arguments that represent
	a [=valid color=], which will then be
	<a>gamut-mapped</a> for display.

	If all of its arguments are [=invalid color=]s,
	the third choice for the value of the ''color()'' function
	is that it represents <a>opaque black</a>.
svgeesus

comment created time in 18 hours

push eventw3c/csswg-drafts

Chris Lilley

commit sha 8667845a752ad8d845c6f6619368be3e0310252b

[css-color-4] Three-stage process for color function. Fix #5046

view details

push time in 18 hours

issue closedw3c/csswg-drafts

"Can't be displayed" is undefined

Originally posted over here.

In section the color function

The color function takes one or more comma-separated arguments, with each argument specifying a color, and later colors acting as "fallback" if an earlier color can’t be displayed (for example, if the colorspace it specifies hasn’t been loaded yet).

can't be displayed is undefined except for an illustrative, parenthetical example.

closed time in 18 hours

svgeesus

push eventw3c/csswg-drafts

Chris Lilley

commit sha 1e7d5e5ea0d5b7f98f3783eb5000b8a111ef97ba

[css-color-4] clarify opacity prperty vs. opacity as part of color, for overlapping text

view details

push time in 19 hours

fork quicklisp/access

A common lisp library to unify access to common dictionary-like data-structures

fork in 19 hours

push eventw3c/csswg-drafts

Chris Lilley

commit sha 5dc1198ddae9e108ccee8e83d1218c88edd4fef7

[css-color-4] typo

view details

Chris Lilley

commit sha a4472c1002fb76579b2c3d4aab86b6080e5c1f62

[css-color-4] update sRGB tranfer functions to reflect below zero

view details

push time in 19 hours

issue commentw3c/csswg-drafts

[css-env] device body colour

We used to have this in CSS Color 3, flavor which dated to the time when iMacs had brightly colored cases. It was dropped for lack of implementor interest.

(Not an argument against this proposal, just a point of reference)

Oh wow thanks! This is interesting, and you're right, I remember it well - the majority of web-capable devices were beige or iMac G3s then. I poured over every possibly-related discussion I could find, but obviously didn't encounter this 'flavor' system colour

electric-skeptic

comment created time in 19 hours

startedemeryberger/scalene

started time in 20 hours

push eventw3c/csswg-drafts

Chris Lilley

commit sha a7073af03d6d2eaee20de506b54a53e280eae0db

[css-color-4] typos

view details

Chris Lilley

commit sha 63dcf2c3b1c57ba200fe572425787fbb42b95230

[css-color-4] add sample code for deltaE2000

view details

push time in 20 hours

issue commentw3c/csswg-drafts

[css-variables] define custom property based on parent's (inherited) value

I have definitely needed this too. I'd support a parent-var() (or similar) function, though it's possible to have a more general form that works for any property (see #2864).

dubrowsky

comment created time in 20 hours

issue commentw3c/csswg-drafts

[css-color-4][css-color-adjust-1] Shielding system colors to avoid fingerprinting?

<dael> Rossen_: As a group are we comfortable with option 1? Objections to say no change on this and we'll document the fingerprinting exposure?
<dael> smfr: I need to talk to privacy people before I agree
<dael> Rossen_: In that case we'll leave it open as is. In both cases we need more data before we resolve
<dael> Rossen_: smfr can you follow up and we bring it back next week?
<dael> smfr: Sure.
<dael> Rossen_: Let's do that. We'll give the Apple folks a week and depending on how things go we may pick option 1

I know there was the seasonal festivities break but it has been more than a week so yes, lets get this resolved. The fingerprinting exposure is already mentioned in Security and Privacy Considerations. I'm therefore fine with option 1.

fantasai

comment created time in a day

issue closedw3c/csswg-drafts

[css-color-4] colorspace profiles, hexadecimal roundoff and round-tripping

A reminder to myself to ensure that the predefined colorspaces take into account the issues on precise whitepoint, adapted and unadapted primaries and TRC resulting from hexadecimal roundoff and consequent impaired round tripping.

Survey of Free and Open Source ICC RGB Working Space Profiles

In Quest of Well Behaved Working Spaces

Elle Stone's Well-Behaved ICC Profiles and Code

  • [ ] sRGB
  • [ ] display-p3
  • [ ] a98-rgb
  • [ ] prophoto-rgb
  • [ ] rec2020

closed time in a day

svgeesus

issue commentw3c/csswg-drafts

[css-color-4] colorspace profiles, hexadecimal roundoff and round-tripping

At the moment we don't have any normatively-referenced ICC profiles, so I'm closing this one as question answered

svgeesus

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] Custom color palettes

For a single color, taking part of your proposed syntax and expressing it with what we already have,

 --my-green: color(a98-rgb98% 1% 1%); /* custom color name */

Your proposal should probably explain why the existing CSS Custom Properties are not sufficient.

Crissov

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] Custom color palettes

This looks cleaner:

@color-profile a98-rgb {
  src: url("adobe.icc"); /* invalid for predefined color profiles */
  green: 96% 2% 2%; /* specify existing CSS color names as descriptors */
  --my-green: 98% 1% 1%; /* custom color name */
}
foo {
  color: color(a98-rgb green);
  background: color(a98-rgb --my-green);
}

It really doesn't look cleaner. It redefines an existing predefined space, linking to a color profile that is unavailable due to trademark and redistribution-licensing constraints, just to avoid using the already-existing color(a98-rgb 96% 2% 2%) syntax and to be able to stuff it into @color-profile even though it is not defining a new color space.

I don't like that syntax at all.

If the default color profile could be set by an inherited property, this would look even cleaner:

:root {
  color-profile: a98-rgb; /* overrides `srgb` default */
}
foo {
  color: color(green); /* or just `green`? */
  background: color(--my-green); /* different from `var(--my-green)` */
}

Overriding all existing colors that have been there since CSS1, with new meanings. A wonderful boon to readability.

If you want to propose a way to define a palette of named colors (and then use those names), please propose a different at-rule like @color-palette and don't try to overload colorspace definitions.

Also, as CSS Color 4 is undergoing stabilization prior to going to CR, please propose it for a later spec such as CSS Color 5 or a new css-color-palettes spec.

Crissov

comment created time in a day

issue commentmozilla/standards-positions

CSS Cascade Layers

Yeah, agreed. Generally the specification is still in early stages, but the goal seems worth pursuing.

lilles

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] device body colour

I agree it makes sense as part of env()

electric-skeptic

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] device body colour

This is entirely unrelated to environment blending, by the way.

electric-skeptic

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] device body colour

We used to have this in CSS Color 3, flavor which dated to the time when iMacs had brightly colored cases. It was dropped for lack of implementor interest.

(Not an argument against this proposal, just a point of reference)

electric-skeptic

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] Custom color palettes

We used to have this in CSS Color 3, flavor which dated to the time when iMacs had brightly colored cases. It was dropped for lack of implementor interest.

(Not an argument against this proposal, just a point of reference)

Crissov

comment created time in a day

issue commentw3c/csswg-drafts

[css-color] predefined-00*.html tests reference value is incorrect (or rather can't match the tests).

@samweinig please review, https://github.com/web-platform-tests/wpt/pull/27209

samweinig

comment created time in a day

issue commentw3c/csswg-drafts

[css-color-4] What serialization should be used when using color(lab ...) syntax to specify a lab color?

Ok, good catch! We already have 4.7.3. Serializing Lab and LCH values but that spec text is specific to lab() and lch(). And we have 4.7.4. Serializing values of the color() function which applies to all of the color() function.

In general, the color serialization tries to preserve a color as specified.

Now, it it was just color(lab l a b) I could argue it either way, but we also have (partly from prompting by @smfr and partly from other feedback that we need to expose CIE XYZ) the form color(xyz x y z) and this is _only_ available oncolor()`.

So I would suggest that color(lab l a b) serializes as itself, rather than being converted to lab(l a b) form.

Same argument for color(srgb r g b) - if someone goes to the trouble of using that new form, then that is what they should get back on serialization. Remember that there are multiple differences between this and the legacy rgb(%, %, %) and rgb(n, n, n) forms - removal of commas, use of / as alpha separator, addition of real rather than integer values in the non-percent form (but still 0..255 rather than 0..1) for backwards compat. So if an author wants to express sRGB in a 0..1 rather than 0% .. 100% or 0 .. 255 form, color(srgb n n n) is the only way to do that and they should get back what they specified.

Apologies for not noticing this issue, first week back after a long seasonal break.

samweinig

comment created time in a day

push eventw3c/csswg-drafts

Chris Lilley

commit sha 1521f5ad3c7569e67aeba3b3aa50e9a85741905f

[cssom-1] redirect serializing color to CSS Color 4 per CSSWG resolution

view details

push time in a day

startedtypeofweb/schema

started time in a day

startedTheStonedTurtle/runelite-shields

started time in a day

more