- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 10 Apr 2019 19:00:39 -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.
=========================================
CSS Lists
---------
- RESOLVED: unicode-bidi / direction apply to ::marker (Issue #3809)
- RESOLVED: apply counter-set after counter-increment (Issue #3810)
- RESOLVED: implicit list-item counter is not reflected in computed
style (Issue #3769)
Selectors
---------
- RESOLVED: Add :picture-in-picture and :fullscreen to Selectors 4
(Issue #3796)
- The spec for :picture-in-picture needs a permanent location that
Selectors 4 can reference.
Overflow
--------
- RESOLVED: Do not propagate any style from display:none HTML or
Body (Issue #3779)
CSS Values
----------
- RESOLVED: Use calc(1/0) [to serialize infinity] and calc(0/0) [to
serialize NaN] (Issue #3768)
Pseudo Elements
---------------
- RESOLVED: Add ::marker to interface CSSPseudoElement (Issue #3769)
- RESOLVED: The 'content' property should apply to ::marker (Issue
#3499)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Apr/0008.html
Present:
Rachel Andrew
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brian Kardell
Brad Kemper
Peter Linss
Anton Prowse
Manuel Rego Casasnovas
Melanie Richards
Greg Whitworth
Regrets:
Rossen Atanassov
Tab Atkins
Florian Rivoal
Jen Simmons
Alan Stearns
Lea Verou
CSS Lists
=========
Should unicode-bidi / direction apply to ::marker?
--------------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/3809
fantasai: We have a limited set of properties that apply to
::marker. Unicode-bidi/direction weren't listed but seems
it would be helpful. This is a request to add those to
pseudo element spec.
plinss: Objections?
RESOLVED: unicode-bidi / direction apply to ::marker
Apply counter-set after counter-increment
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3810
fantasai: This was an issue around interaction. Property values you
have to set if you're incrementing on every item and want
to set to a particular value. yOu have to set it minus
increment. That's ergonomically awkward
<fremy> (I'm in favor)
fantasai: Suggestion is set counter set after increment so if you
set 'foo 5' it will be 5 no matter the counter increment
fantasai: Generally better cascading behavior. Counter-set wins over
counter increment rather than adding to it.
gregwhitworth: When you set counter-set it starts from that place?
fantasai: Sets an explicit value for the counter
gregwhitworth: And doesn't increment after that?
fantasai: If you have nth-child 5 counter-set: chapter 5 it will
have 5 instead of the increment added to that.
gregwhitworth: Then increment from 5?
fantasai: On other elements, yeah.
fantasai: On a particular element you apply counter-reset then
counter increment then counter set.
plinss: Makes sense to me. Looking at issue Gecko implements but
will change. Any other implementations here?
fantasai: I think they're only ones. They committed the fix a day ago
plinss: Objections?
RESOLVED: Apply counter-set after counter-increment
Selectors
=========
Add :picture-in-picture pseudo-class
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3796
plinss: Anyone want to talk to this?
fantasai: I don't know too much about this, but it's being shipped
by Google imminently. Generally we put all pseudo classes
in selectors so looks like MOz filed an issue to have it
in selectors
fantasai: But I don't know much about what they're about to ship
smfr: Read but was confused about when it applies. I'd like to to
say this applies when showing picture-in-picture mode or
something like that
fantasai: Is picture-in-picture mode defined?
smfr: Spec defines but not readable by humans except the 2 that know
about shadow dom
<emilio> The shadow dom thing is broken in the spec
AmeliaBR: Looking quickly it's confusing about if this is pseudo
class or element. WICG spec describes...seems to describe
a...
fantasai: It's a pseudo class
AmeliaBR: An element that's an active element in the doc. There's
also an extra window object.
AmeliaBR: I agree with smfr the spec needs some work from css people
to make sure it's defined clear on consistent. Logically
makes sense it's a think like fullscreen pseudo class.
AmeliaBR: Someone needs to work on spec
fantasai: Not sure we define :fullscreen either
fantasai: We should add both or neither or have a note about
additional selectors. I guess in section 11
<fantasai> https://drafts.csswg.org/selectors-4/#resource-pseudos
myles: Reason these pseudo elements need to be inside our specs?
fantasai: Generally...for the most part we have all selectors in
selectors so if you're looking for one you can find it.
Detailed description is deferred to the host spec. But we
define it exists and roughly what it means
fantasai: Haven't done for :fullscreen or this
gregwhitworth: I'd like it in selectors spec
fantasai: Currently specs that define selectors or css properties
not in WG should ask CSSWG members to review specs before
shipping, but that's a separate issue
AmeliaBR: Where ever defined needs to be reviewed to be logically
consistent. Easier to do if there's a mention in selectors
that links out.
plinss: Agree this should be in css specs
plinss: Do we know where rest of picture-in-picture will spec? Merge
into HTML? Spec?
<@gregwhitworth>
https://wicg.github.io/picture-in-picture/#htmlvideoelement-extensions
gregwhitworth: I found wicg document but I can ping the person on
our team and find out
AmeliaBR: If following fullscreen pattern it's stand alone in WHATWG
fantasai: And for us to cross reference we need to know where the
spec will permanently live. If it doesn't have a plan
where it should be it needs one. And get buy in from
people besides Google
plinss: That's what I was driving at. Are other implementors on
board with this and whatnot
plinss: Sounds like we agree if this moves forward pseudo class
should be in our specs. Not sure what we should do with this
issue right now
plinss: Other thoughts?
smfr: Webkit supports impl but want a better spec. I think there's
enough to give feedback to authors
fantasai: Whole spec shouldn't be CSS. We should add a section to
selectors for :fullscreen and :picture-in-picture. Someone
should give feedback to the authors. And we should say hey
we need to link to your spec, are you putting it through a
standards process somewhere?
plinss: Resolution to add :picture-in-picture and :fullscreen to
Selectors?
plinss: Or just leave a note that's where they should live and
coordinate?
fantasai: Add in and put an issue in there to link to spec once it's
somewhere
AmeliaBR: 4 or 5? What's the status of when not quite stable things
should be...
fantasai: :fullscreen should definitely be 4. There's no level 5 so
they should go in there. It's being implemented so I'm not
concerned
plinss: Objections?
RESOLVED: add :picture-in-picture and :fullscreen to Selectors 4
Overflow
========
Overflow propagation when the element propagated from is display: none
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3779
plinss: Who wants this one?
fantasai: Was emilio able to join?
emilio: Hey
emilio: This is mostly a little thing and only place where gecko
needs to deep dive into the subtree to render
emilio: I remember Rune at some point complained about it. I was
wondering if people had willingness to change. I don't
deeply care but I think it's a bit saner
* fantasai has no opinion on this
AmeliaBR: You're asking if the HTML or Body element isn't displayed
we don't worry about propagate styles up?
emilio: Yes
plinss: Just get a blank page?
<bkardell> seems fine?
smfr: display:none is common to do?
emilio: I don't think it is. I could get some data and come back
smfr: My only concerns is sites where they do that and browsers
propagate the body background and you get a flash of color
change
emilio: Body background is specified to not propagate if there's
display:none
smfr: I guess Chrome has a bug that it doesn't do that which is
shared by WK
emilio: Def Chrome, I don't know WK
smfr: Probably does. I don't feel too strongly. Seems reasonable
plinss: Curious about usage of display:none body. I can see it
abused for tracking iframes and whatnot on a page. Curious
if that's something people want to do. I guess if they're
putting in iframe they won't put a background on it
<bkardell> but changing -- there isn't interop now -- or is there?
plinss: Proposal: Not propagate any style from display:none HTML or
Body
emilio: Don't propagate the background of the element...basically
whatever definition the background propagation is using I
want to align
plinss: Objections?
RESOLVED: Do not propagate any style from display:none HTML or Body
CSS Lists (continued)
=====================
Is the list-item counter increment for list items reflected in the
computed style?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3769
emilio: There's a magic increment applied to list items that's
defined in terms of display. Element with display styling
you have the magic counter increment depending on if list is
incremented [missed]
emilio: Another possible thing to do is to just do it at used value
time
emilio: I don't feel too strongly either way, maybe other engines
have constraints on when can shuffle elements. As an author
don't know if it's very useful to gCS with this counter. If
you spec counter-increment:none and computed style is not
none
fremy: I think it's not included in counter style
<fremy> ^ (in Edge)
<fremy> ^ (which is good because it probably should not inherit)
AmeliaBR: Clarification. When author says counter-increment:none it
doesn't cancel the list item increment. Based on rule
serialization should be as short as possible if omitting
list item 1 have same effect as spec shouldn't shortest
version be to omit it?
<emilio> Ugh, audio went nuts
plinss: Looks like emilio is having audio issues. Still there emilio?
[silence]
<emilio> on irc yes
plinss: He's IRC only at this point
plinss: Any other thoughts on this?
<emilio> We could also do what AmeliaBR mentions, but that is only
ommittable depending on the display value, so it's a bit
weird to serialize differently depending on other property
values
<emilio> fremy's point about inheritance is a good point
plinss: Should we defer until emilio can be on a call? He's
responding on IRC
gregwhitworth: Let's defer if he's not able to get on
CSS Values
==========
How to serialize infinite values?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3768
AmeliaBR: I can go over quickly
AmeliaBR: Issue is that at serialization stage before computed style
we say divisions are simplified. Sometimes means you have /
0 situation or other situations with infinite or NaN
values. We have that NaN is +infinity but how to serialize.
AmeliaBR: Proposal is serialize it as a calc expression as something/
0 where something is appropriate to dimension you're using
1px, 1deg, 1ms
AmeliaBR: This would only be exposed in serialized values
AmeliaBR: Catching up on issue discussion between oriol and
TabAtkins where NaN should have own unique serialization
different than infinity
AmeliaBR: We want something predicable and consistent but not too
complicated b/c used in a lot of places. Just for
intermediate serialization
fantasai: Seems like the issue converging on infinity is calc(1/0)
and NaN is calc(0/0)
plinss: negative infinity is calc(-1/0)?
fantasai: Yep
AmeliaBR: And all of these would hold on to a unit so it's
calc(1px/0)
fantasai: Makes sense
gregwhitworth: Consider NaN as a keyword?
fantasai: Then we'd need to make it for all CSS and why would you
want that
gregwhitworth: For this reason? Because we're specifying in a weird
way
fantasai: This is better than a global keyword that's a number that
doesn't exist. I don't think it helps anyone
emilio: Probably doesn't work with dimensions
fantasai: That's an important point
plinss: Other alternative is keywords for NaN and infinity for only
in calc. Curious if they have an actual use somewhere else
AmeliaBR: We do have some properties that have an infinity keyword
and that is treated different than a calc expression that
computes to infinity. It's the infinite keyword in
animations. Not sure where else
fantasai: We should go with calc-based serialization. It comes up in
serializing calcs and that way we don't need keywords for
units. It's built into the method
plinss: Objections?
RESOLVED: Use calc(1/0) and calc(0/0)
emilio: How does NaN behave? Like NaNpx body?
AmeliaBR: I assume keep current rule where treated as +infinity and
then clamps per property rules
emilio: Wouldn't be better to keep as computed time for clamping and
not care about serialization?
AmeliaBR: Serialization simplifies multiplication and division so it
has to be simplified. Going down to a standard division
structure
AmeliaBR: If you specify calc(3/3) at serialization you get 1. If
you specify calc(3/0) we're saying at serialization you
get 1/0
plinss: Given our existing rules we have to do this
emilio: calc(1/0) doesn't parse anywhere, right?
AmeliaBR: I don't know. If we have people rejecting at parse or
doing own thing at serialization
emilio: Pretty sure gecko rejects at parse time. When we impl min/
max may have to change
<@fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22background%3A%20red%3B%20background%3A%20calc(1px%2F0)%20calc(1px%2F0)%20green%3B%22%3E
fantasai: Does appear to be the case ^
fantasai: If we enter as keyword still won't parse.
fantasai: Gecko does not parse
AmeliaBR: Same for Chromium
AmeliaBR: But we're extending number of possible divisions
possibilities. Allowing to divide values with units and
some units might be 0 so need robust math rules
emilio: But then how to serialize this is only small part, need to
spec how behave. You're introducing them into layout
AmeliaBR: There is an extended new section on range checking
AmeliaBR: that says any infinite values are clamped to min/max
allowed. emilio is right most properties don't have
explicit min/max value allowed
<AmeliaBR> https://drafts.csswg.org/css-values/#calc-range
AmeliaBR: That part of spec probably still needs to be discussed. I
don't know if need to hold off discussion of serialization
emilio: Generally the spec says clamp and apply transformations as
early as possible. calc(10px) serializes to 10px.
Serialization might not be an issue depending on how spec to
behave
myles: Not sure should spec max for every property. Browsers may
vary. Some browsers might be able to handle a really big
width and some can't
emilio: Agree
myles: Tons of implementors specific limits like nesting depth that
aren't written. These max should be with those
AmeliaBR: Good point. Should lead to not clamp too early. Eventual
clamp will be impl specific so should only happen when it
has to. If we just propagate mathematical infinity it
helps interop and serialization stage
emilio: Reasonable answer
plinss: Anything else?
CSS Lists (continued)
=====================
Is the list-item counter increment for list items reflected in the
computed style?
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3769
emilio: I think fremy's point is good. weird the counter would be
inherited
AmeliaBR: You're agreeing the implicit list item shouldn't show in
computed styles?
emilio: Yes. That's what I proposed. Mats disagreed.
plinss: Wondering if we have right people to resolve this
fantasai: My inclination is leave as a hidden mechanism but I don't
have strong rationale. I'd choose that unless there's a
good reason to reflect in computed style. Putting it in
computed style means it inherits which is a little weird
fremy: Another reason is right now it's a breaking change but if you
don't put in computed style it's not a breaking change.
Unless there's a strong reason for it to be in computed style
it shouldn't be
emilio: I don't think in this case compat is a constraint but I
agree it's nice to keep compat
AmeliaBR: Sounds like call agrees. Resolve it pending a clear
objections from Mats or anyone?
plinss: sgtm
plinss: Objections?
RESOLVED: implicit list-item counter is not reflected in computed
style
Pseudo Elements
===============
Add ::marker to interface CSSPseudoElement
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3763
fantasai: This is straightforward. Have a pseudo element similar to
before/after. Just add it to the pseudo element interface
plinss: Objections?
RESOLVED: Add ::marker to interface CSSPseudoElement
Should Element.pseudo("unknown") be an error or return null?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3603
fantasai: If TabAtkins isn't here and no one else understands should
skip
plinss: Defer for TabAtkins
The 'content' property should apply to ::marker
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3499
fantasai: Mozilla has an implementation of this. TabAtkins and I
cleaned up lists spec so what it needs to do with content
interaction should be well defined. Proposal is to add the
content property back into pseudo elements applying to
::marker
AmeliaBR: Content still set auto based on list property?
fantasai: Yes. Initial value is normal and that takes content from
list style property
AmeliaBR: So an author wouldn't have to set content prop for marker
to be rendered but could override it if want to do
something special
fantasai: Yes
AmeliaBR: Makes sense to me
fantasai: Any objections?
plinss: Objections?
gregwhitworth: Curious about use case. If they're in disc mode
they'd replace with a new disc type?
fantasai: Background and display don't apply to markers. Case is I
have an <ol> and I might want to change to include the
chapter number or I might decide I want outside list
marker styling and turn my headers into list items. You
could do those kind of things
gregwhitworth: How different then increment stuff?
fantasai: You can say I want to use this piece of text. May or may
not include a counter. More flexibility in terms of what
you want in terms of things like punct
AmeliaBR: Lots of use cases <ol> 20-1 but 3 2 1 are bronze/silver/
gold
fantasai: Multi-part listing is one of the biggest use cases. We
should put an example in spec.
plinss: Objections?
RESOLVED: The 'content' property should apply to ::marker
plinss: That's the top of the hour.
plinss: Thanks everyone.
fantasai: Idea for ::marker was to make it more stylable then it is
right now. Because we don't have marker layout defined
we've limited number of properties to those not impacting
layout. But content was in list spec for a while. Cut it
down for pseudo 4 and content was easy enough
gregwhitworth: Thanks for clarification
<AmeliaBR> Example of that gold/silver/bronze idea done with
::before and a custom counter:
https://codepen.io/AmeliaBR/pen/gBKta
<AmeliaBR> (But I agree that a nested list with 2.b.ii as a number
is a more common case.)
<fantasai> We should definitely add it as an example in the spec
Received on Wednesday, 10 April 2019 23:01:34 UTC