- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 21 Nov 2018 19:57:12 -0500
- 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.
=========================================
Transforms
----------
- RESOLVED: Publish WD for Transforms
CSS Exclusions
--------------
- There hasn't been any recent work toward resolving the concerns
that have been already raised about this spec. (Issue #3308)
- Interest from web developers is still high so those interested in
working on it will compile use cases and revisit the open
concerns in light of the use cases.
CSS Break
---------
- RESOLVED: Add 'always' and 'all' to break-before and break-after
where always is on the nearest fragmentainer and all
breaks across all fragmentainers. (Issue #3318)
CSS Selectors
-------------
- RESOLVED: Use media query style invalidation inside pseudo classes
that accept selector lists (Issue #3264)
- RESOLVED: Kick the can down the road and think about this (Issue
#3082: Reconsider removing selector list invalidation)
for Selectors 5
- RESOLVED: Add :defined to selectors L4 (Issue #2258)
- RESOLVED: Publish a new WD of Selectors 4
CSS Inline
----------
- The draft proposal for line-box-contain (Issue #3199,
https://drafts.csswg.org/css-inline-3/#line-sizing-property)
created a lot of interest, but time ran out on the call so those
who wish to discuss further will organize a separate call to
dive deeper into details.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Nov/0022.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Alex Critchfield
Elika Etemad
Javier Fernandez
Simon Fraser
Dael Jackson
Brad Kemper
Chris Lilley
Peter Linss
Myles Maxfield
Thierry Michel
Melanie Richards
Florian Rivoal
Alan Stearns
Lea Verou
Greg Whitworth
Eric Willigers
Regrets:
Tony Graham
Nigel Megitt
Michael Miller
Jen Simmons
Manuel Rego Casasnovas
Scribe: dael
Rossen: It's 9:02. Let's get going
Rossen: I wanted to see if there are any additions or changes to the
agenda
florian: We have issue #3024 on the agenda. Used to be agenda+ for
F2F, was changed to regular. Not sure if it's ready since
the discussion at TPAC.
Rossen: How can we make progress?
florian: Is zcorpan on?
florian: If not we should not discuss
astearns: I believe he's on vacation until next year
Rossen: I'll push to end of agenda. Can you take an action item to
ping him and see if we can get progress?
florian: I think it's mostly you should harass me to respond to his
proposal
Transforms
==========
Publish WD for Transforms
-------------------------
Rossen: We have a CR resolution, but we don't have a current WD.
RESOLVED: Publish WD for Transforms
CSS Exclusions
==============
Status of the exclusions spec
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/3308
rachelandrew: This keeps coming up. Every now and again I get a grid
question that's actually exclusions
rachelandrew: This issue is quite compelling
[audio issues]
rachelandrew: This is something that keeps coming up. The issues I
opened this with, floating things in a grid, I see
people keep asking for.
rachelandrew: I wanted to package this up and see where we are.
Rossen: For exclusions the current version, you've captured the impl
status. We've had some since IE10, carried through to Edge.
Current spec as is defines how an exclusion area works, what
is effected, how propitiate through decedents. How geometry
side works.
Rossen: Lots of push back in past because most people thought this
also defines exclusions as working on abspos only. Not true.
Not dependent on any specific layout scheme
Rossen: As such spec has been held at no progress for those issues.
I'd be happy to engage with anyone interested in progress
and see if can get more traction.
<dbaron> some of my previous concerns about exclusions are at
https://lists.w3.org/Archives/Public/www-style/2012Jul/0683.html
and the thread above
https://twitter.com/fantasai/status/1024736667494535168
florian: There was push back on that, but also on a variant where
they could work on some modes that didn't do collision
avoidance. That you could exclude without collision
avoidance was a problem. I was given an action to try and
define collision avoidance by default, but it's very hard
and not sure that's the way forward. Other option is to
make property have no effect on things such as abspos that
don't include collision avoidance built-in or just let it
be possible
florian: Maybe still pursue if you turn it on with something that
doesn't have collision avoidance you get it. Need someone
to define that. It's possible, but massive.
Rossen: That's my memory as well.
Rossen: I think dbaron posted related threads
Rossen: They had to do with some concerns about cyclic dependencies
Rossen: I don't recall any such issues when I impl exclusions, but
can't speak for other engines.
Rossen: Most of concerns were related to paged media and not as much
visual. This is when most issues would occur
<rachelandrew> I think this is going to keep coming up, I'd be happy
to help work on it, but I think we need something to
solve these use cases
<rachelandrew> now we have grid we'll see more of them
Rossen: This is where we are. Summary captures everything we've
discussed. Be happy to try and make progress and have
exclusions move forward because they are awesome.
Rossen: For those interested let me know and we can try and make
something actionable
Rossen: rachelandrew are you interested?
rachelandrew: Yes, definitely
Rossen: What if we table the discussion until we bring back use
cases and see how they fit in current model.
rachelandrew: sgtm
<fantasai> +1 to dbaron's concerns listed above
<florian> rachelandrew If you're interested, I can send you my notes
/ draft about trying to define collision avoidance by
default from way back. They're not complete, but might
still be of interest.
<rachelandrew> florian: that would be great thanks
CSS Break
=========
Should 'break-before' / 'break-after' have an 'always' value?
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3318
fantasai: As emilio and I looked into these aliases we noticed IE
impl 'always' which is not in spec. In earlier revisions
there was 'always' but not clear. We considered break
through all fragmentation context or in closest one.
fantasai: IE treats as alias to page and only works in paged mode
fantasai: Options: We can define that break-before:always doesn't
exist but it looks like usage is high
fantasai: We define it to exist has 3 options:
fantasai: Alias of Page, Trigger break at inner most fragmentation
context, or Trigger to break through all available
fragmentation contexts
fantasai: Those are our options.
fantasai: My preference is if we have this we should break at inner
most fragmentation context. That way author working on
content can ask for a break at the next thing. That seems
most useful when trying to simulate pages.
<bradk> Innermost seems the most sane to me.
fantasai: Most compatible is define as page break. I'm not sure we
need that level of compat because main difference is if
inside a multi-col. In IE you will not trigger any break
in a multi-col unless you're printing. So if you're using
break in multi-col you'll get really inconsistent results
depending on mode.
florian: I think last time we talked we agreed main use case was
inner most, but also a use case for outermost. We removed
because needed to name both consistently. I think we had any
/all, but not sure.
fantasai: Now we have 'always' which needs to be defined in some way
florian: Always and all and always and any that always pairs best. I
think we should get both, but if we have both which name is
obvious
<bradk> always|all
fantasai: I think inner most is most useful, but interested in
hearing from rachelandrew and dauwhe
dauwhe: In ebook people fake pagination with multi-col all the time.
Inner sounds like would make sense for us
florian: If you're not nesting it doesn't make difference whether
you punch through. If you are nesting I think you'll need
both. Like, you're at a chapter break and want to break all
context. Or smaller break.
fantasai: bradk suggests 'always' and 'all'
florian: I think that's okay
<rachelandrew> always and all sounds good to me
florian: If we're stuck with 'always' it's reasonable
fantasai: Rossen would you be willing to change in Edge?
Rossen: Potentially. Use cases I've heard are compelling and make
sense. From impl PoV it's not super hard. more juggling to
re-order breaks in the right priority and break as much as
needed based on current stack of breaks.
Rossen: Break through all or just current is similar to things we're
doing.
Rossen: Having heavy hammers of those two, it'll be fine. I don't
think from impl PoV this is a huge concern as long as it
fits the bill and addresses enough use cases.
fantasai: I think having 'always' makes it easy for authors. They
don't have to think about context, they just want a break.
If you want a page break, you can say that specifically.
Rossen: Wouldn't disagree.
Rossen: In principle my model for breaking and fragmentation has
been ideally one you can declare your own levels and then
have your own defined break for that level. It could be a
page, a column, and article, and you should expect that's
how it happens
Rossen: Since we're static defining the levels something to punch
through is needed.
Rossen: You'll always have cases where they say punch through
everything except this one. Hoping to not have to discuss
that.
florian: Might need that with region or region-like things. But it's
just a maybe. If we do it's not hard, but hopefully
unneeded complexity
<myles> Rossen: if you have columns inside pages, how do you force a
page break without forcing a column break?
Rossen: I see last proposal was break-before/after: always | any |
first
fantasai: 'always' and 'all', 'always' is nearest
Rossen: 'All' is a superset of 'always'
fantasai: 'always' means you always get the minor-est amount of break
Rossen: 'All' implies 'always' everywhere
fantasai: umhum
Rossen: What do others think?
Rossen: Objections to adding 'always' and 'all' to break-before/
after where always is on the nearest fragmentainer and all
breaks across all fragmentainers
RESOLVED: Add 'always' and 'all' to break-before and break-after
where always is on the nearest fragmentainer and all
breaks across all fragmentainers.
Selectors
=========
Let :matches() have better error-recovery behavior than normal
Selectors
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3264
Rossen: Is TabAtkins on?
fantasai: I can take it
fantasai: When we have a list of selectors :foo, :bar
fantasai: Browser doesn't recognize :foo so the entire style rule is
thrown out
fantasai: That's selectors style invalidation.
fantasai: Other style of invalidation is media queries-like where
you throw out a section. So if you have :foo, screen we
recognize screen
fantasai: Can't do MQ like because it would break the web for
selectors. TabAtkins pointed out we have ability to do it
within the new selectors in L4
fantasai: Issue proposes we adopt MQ-like invalidation inside the
pseudo classes that take selectors.
fantasai: :foo || :bar, [known selector] we'd only do the part we
recognize.
fantasai: Makes a lot of sense to me together with @supports rule we
added. Gives authors much better tools. If they want more
granular they can use something else
Rossen: Sounds reasonable.
Rossen: Opinions?
myles: Thoughts from people that teach this? Seems like could be
confusing
Rossen: leaverou or rachelandrew ?
* tantek agreed with myles, it could be confusing. would definitely
want webdev teacher feedback on this.
<dbaron> Were you suggesting doing different things for :matches()
vs. :is() ?
fantasai: dbaron this was from before we renamed. Title should be
:is. Applies to :is, :not, :has, :nth-child, and maybe
:current
dbaron: One worry is some have been around for a while and might
have compat issues
fantasai: :not with commas isn't widely supported.
fantasai: :not with a single argument that's invalid makes the whole
thing invalid
florian: I think :not with a comma is supported in Safari and
Viviostyle
fantasai: :not is trickier because it's a negation
leaverou: Trying to decide error recovery or syntax?
fantasai: Error recovery
leaverou: Sounds amazing thing to do. It might be a little
confusing, but it's worth it. In talks I only use webkit
version and have to mention verbally it's just webkit. As
an author I would love it
emilio: Doesn't solve unknown pseudo elements issue, right?
fantasai: No, that's separate.
emilio: I think that's biggest issue authors want to solve
fantasai: There's a rule for the webkit
emilio: Want to style a video control for webkit and edge it's not
standard. That's the biggest source of duplication
fantasai: This would solve, put it in all one :is
emilio: Syntax allows pseudo elements inside?
fantasai: This is work for pseudo classes. Elements is next on agenda
<florian> I support this
<bradk> I’m still concerned about :not. Can we find out how much
authors have :-webkit and commas inside not?
Rossen: bradk point about :not and his concern, can we address that
now?
Rossen: Concern is the :not and defining how much authors have
commas inside a :not?
florian: It's safari only
bradk: Safari on iphone is used a lot. :not has been without commas
for a while, but it's used in mobile web a lot. That's my
suggestion, I'd like actual data
florian: This is hard data to get. Need to find usage that would
break the page if it started working in a different way.
That's a judgment call
Rossen: Another way to ask is if any Apple folks have an issue with
this. If they feel comfortable with compat risk we can
resolve
bradk: That solution would be okay
smfr: I don't think we have enough information to know. When we
implemented :not we got compat issues because people using it
in wrong ways
smfr: No feeling for how common comma use is to know if it's risky
Rossen: Would you be okay with current proposal in the absence of
this information?
smfr: I think so
Rossen: Anything else before we try and resolve?
<bradk> No strong objection
Rossen: fantasai can you give the resolution text?
fantasai: Use media query style invalidation inside pseudo classes
that accept selector lists
Rossen: Objections to ^?
emilio: Would like behavior for :not clarified
fantasai: Makes sense.
RESOLVED: Use media query style invalidation inside pseudo classes
that accept selector lists
Rossen: fantasai and TabAtkins will have clarification in spec
Reconsider removing selector list invalidation
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3082
fantasai: Closely related issue
fantasai: We were talking about how invalidation is a problem, can't
change for compat reasons.
fantasai: Suggestion was have a special rule for unknown pseudo
elements to treat as valid, but only for not prefixed
ones. Wanted to ask WG if we should look into this
fantasai: If you don't recognize anything in the selector you
invalidate the whole thing. Can't change whole rule, but
maybe possible to change that rule only for pseudo elements
fantasai: Wanted to ask if anybody has thoughts on if this is
something we should look into
Rossen: Opinions?
florian: I think people rely on it not to work as a form of browser
sniffing
dbaron: Also one where I would ask who would impl first
Rossen: I'm hearing pushback
emilio: Assume proposal you need to work only for unprefixed, right?
fantasai: Yes
florian: Then it's a question of accidentally relying on it not to
work. Possibly less but have no data.
Rossen: I can't figure out if this is something we want to work on
or if just table
Rossen: Still hearing more pushback then interest
florian: If we could make it work it would be great.
fantasai: Want to know if we should a: accept, b: reject, or c: not
now, maybe selectors 5
Rossen: Easiest to agree on is C
<bradk> C
Rossen: Anyone pushing for accept or reject?
Rossen: Objections to kick the can down the road and think about
this for Selectors 5?
RESOLVED: kick the can down the road and think about this for
Selectors 5
florian: Not satisfactory but until someone volunteers to collect
data there's not much we can do.
Rossen: It's reflecting reality, though.
:defined
--------
github: https://github.com/w3c/csswg-drafts/issues/2258
fantasai: HTML defines :defined pseudo class in its spec, in general
we define in selectors and HTML refines. So should
:defined be defined in selectors?
fantasai: Matches all elements that had no problem during
constructions
Rossen: Any reason why it shouldn't be defined in selectors?
fantasai: Very HTML specific currently. That's the only reason I can
think of
Rossen: Not crazy about the name, it's a little too generic
florian: Would it fail to match on custom elements not defined
properly and any element whose semantics are unknown to
browser?
fantasai: Don't know
florian: Reading example that seems to be the case. If using on a
not known element it won't match.
florian: Does make it non-HTML specific even if use cases are HTML
specific
florian: Seems like we should do this, but also study more
fantasai: It's implemented afaict
Rossen: Implemented in blink?
fantasai: Not registering as invalid in test case.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ahtml%3Adefined%2C%20foo%3Adefined%20%7B%20border%3A%20solid%20green%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cfoo%3EThis%20is%20a%20test%3C%2Ffoo%3E
emilio: Implemented in blink, gecko, and webkit
Rossen: If this has implemented in various UA and since it's a
selector makes sense as part of selectors unless we're
against it in the way it's defined. We should accept it and
refine
florian: Sounds good
Rossen: Other comments or objections to adding :defined to selectors
L4?
RESOLVED: Add :defined to selectors L4
Publication of Selectors
------------------------
Rossen: Republish WD?
fantasai: Yeah.
fantasai: Thing we just resolved on I'll mark as open issue
RESOLVED: Publish a new WD of Selectors 4
CSS Inline
==========
Draft line-box-contain proposal
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3199
fantasai: We talked about having a property that does roughly this.
Some control over height of line calc. Been discussed
since before my time. dbaron had interesting proposals for
how to do it
fantasai: Know we need 3 behaviors: now, quirks mode, and consistent
lines people want
fantasai: Drafted rough proposal with behaviors talked about.
<fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property
fantasai: Wanted to ask WG if we want to work on this? Add
something? I think need to add to inline spec, this is a
rough draft.
fantasai: I think we need to add a property that does something
smooth with a syntax
fantasai: Vague, but I wanted a start
myles: Been thinking about this for a while and I don't know right
approach. Need backwards compat, but mode switches are
confusing and multiple ways to solve line-height is extra
maintenance and makes web more complicated. Not sure right
way to do this
florian: Hard time seeing anything but a mode switch here. Not sure
we need that many values, I'd rather 2. One does legacy or
quirk depending on mode and the better behavior. Others
listing leave out until proven
fantasai: The 'better behavior' says "Line boxes are sized, and
content positioned within them, as defined in [CSS2],
except that positive half-leading is not applied to any
box other than the root inline box."
fantasai: It might be possible to slip that in without breaking too
much. Any leading would break, but only eliminating
positive leading might be possible. It's possible that
won't break anything
myles: Not saying mode switch bad. More frustration about where we
got to. Also, want to say this is one of the most requested
features from people that care about text. Great to solve.
We're between a rock and a hard place
dauwhe: I will use it as soon as it exists
Rossen: Where do we work on it?
dbaron: A few comments
dbaron: I think there is an alternative to mode switch is new syntax
to line-height. Mode switch-like, but not as bad in some ways
dbaron: May need >1 new value. bunch of use cases for things like
images in a line and in default you want images to change
line height, but there are cases where images within a line
and do not want a change because images are roughly the size
of the text
fantasai: In terms of new keywords for line-height for ergonomics a
mode switch is better. Line-height you're talking about
quantity of space, not the mechanism by which you want to
measure. It's a separate thought in how you want to do it.
fantasai: You want the good line height calc on the whole page and
forget it. Same way as box sizing is done. I used to think
it was a mistake, but the way we did box sizing was
originally almost always wrong. Webdev would rather set it
once on a style sheet.
<dbaron> I actually disagree about box-sizing, since I think it
depends whether you care about the inside-size or the
outside-size
fantasai: This is similar. You almost never want to switch. You want
to set at the top and you don't want to think anymore. If
you put it in line-height you have to think every time you
change the line height
<tantek> yes it was certainly my intent when I proposed box-sizing
that it was a "just fix it so things work like I expect
across all the things box related"
myles: Would a mode switch change the way line-height is inherited
or how it applies to only block elements and not inlines?
fantasai: Various behaviors proposed. One that would fix most
problems would be to change it so line-height is ignored
on all inline elements. They just have a line-height of 1
effectively.
fantasai: Had to modify so if you set line-height <1 we add negative
leading so your effect is honored
fantasai: Not that it doesn't apply, just only applies if negative
leading. Applies to root and then applied to every line.
As long as you're in that space, if the sizing box fits,
it doesn't increase height of line or move it
myles: Any precedent for that type of behavior?
myles: I mean changing the behavior of a property based on another
property. Not sure how I would impl
Rossen: Sorry to interrupt. We're 4 minutes overtime. I want
conversation to continue, but I want to let everyone else
go. We won't resolve, but conversation should continue
myles: I have to go too.
fantasai: Schedule a separate call about this.
Rossen: Good idea
Rossen: Focused group would be good. I'll send an email to private
list to see if we can get folks.
fantasai: I can send
Rossen: Have a great Thanksgiving for those of you celebrating. Talk
to you next week.
Received on Thursday, 22 November 2018 00:58:09 UTC