- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Oct 2019 18:35:12 -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.
=========================================
Web Animations
--------------
- RESOLVED: Pseudo elements are targeted via a parent plus a pseudo
selector (Issue #4301: Dependency on CSSPseudoElement)
CSS Sizing
----------
- RESOLVED: intrinsic-size is the name of the new property and value
set is 'auto', 'legacy' and a length (Issue #4229:
Proposal: content-size CSS property)
- RESOLVED: We are redefining the size property in @page to be
called page-size. Also defining that size in the page
context parses into page-size. The size property is a
shorthand for width and height (Issue #820: Adding a
'size' shorthand for 'width'/'height')
Grid 2
------
- There is ongoing discussion on github for how to resolve issue
#4411 with several proposed solutions. The proposals are:
1) Define that a subgrid subsets its parent grid’s template
based on what part of it is covered, and ensures that its
edges provide the requisite -start/-end lines at its edges.
2) Define that the grid-*-start property searches the implicit
lines before the first line instead of the lines after the
last line if a specified line name is missing, similar to how
span foo searches in opposite directions based on whether its
a grid-*-start or grid-*-end value.
3) Define that, while implicit lines have most names in the
infinite space of possible names, only lines before the first
line also have names ending in -start, and only lines after
the last line have names ending in -end.
4) Don't handle template subsetting; the cases you describe will
be a type of error.
- Anyone interested should add their thoughts to the github
issue.
- RESOLVED: Serialize the subgrid template rows and columns to only
include line names defined for the subgrid locally and
not include names that came from the parent grid (Issue
#4362: `grid-template-rows/columns` Computed / Resolved
Values for 'subgrid' values)
CSS Text
--------
- RESOLVED: Space before a line break is removed even if reordered
to the middle of line by bidi reordering (Issue #4308:
Define break at space to remove a space explicitly)
- Florian will get i18n feedback for issue #4283 (Need additional
value of word-break for Korean) to see if the property has use
cases outside of Hangul, but the group was generally inclined to
add a property to support this use case.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0018.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Brian Kardell
Chris Lilley
Myles Maxfield
Stephen McGruer
Peter Linss
Anton Prowse
Florian Rivoal
Jen Simmons
Regrets:
Lea Verou
Scribe: dael
Rossen: Let's get going. We have too much to discuss today so we
should start
Rossen: I will call for agenda changes or additions
Web Animations
==============
Dependency on CSSPseudoElement
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4301
smcgruer: I'm hoping this is a rubber stamp. Hopefully everyone has
read
smcgruer: We have a problem where CSSPseudoElement has a lot of
questions. For animations events and objects want to
specify pseudo element by target being parent element.
Similar to animations and transitions
smcgruer: We expect this is how all will have to for for pseudo
elements. No way to change events that happen today.
smcgruer: Want to make sure makes sense for group
florian: There was another conversation on pseudo events for
highlighting and discussed with editing TF. Opinion of the
Editing TF is it was inadequate so let's be careful how we
use/expose
florian: Not expert, but there was discussion on changing how looks/
works
Rossen: I think the discussion florian referring to for highlight
API were close to what's being proposed. From last I heard
they want to start taking more dependency on this proposed
model. Another was inking input want similar exposure for
various types of actions and states. Want to be able to
target similar eventing model
Rossen: I have read the proposal, I don't think it's controversial.
Want to hear from more people working in this space.
Rossen: Not hearing any.
Rossen: Are you looking for a resolution smcgruer? That accepts the
proposal?
smcgruer: Yeah
fantasai: I wanted to ask if birtles has weighed in and what's his
position
smcgruer: My understanding is he agrees. He was part of the
discussion. But I can't represent him directly
Rossen: I don't believe he was opposed. We can re-open and continue
if it's not complete. It doesn't come across that birtles is
against in the thread.
Rossen: I propose we resolve and if there's additional conversations
we can re-open
fantasai: Okay with that if assumption is correct
AmeliaBR: What's the exact proposal?
smcgruer: Prop: Animations have a target element. We propose for
animations targeting pseudo elements is the target is the
parent and an additional selector that lets you know which
the new element it
Rossen: Pseudo elements are targeted via a parent plus a pseudo
selector
* flackr notes it is equivalent to AnimationEvent here
https://www.w3.org/TR/css-animations-1/#dom-animationeventinit-pseudoelement
AmeliaBR: Has anyone thought about forward compat for a pseudo
element dom object?
smcgruer: Not extensively. That's fair. Problem in general is event
targeting in general will have to solve that
AmeliaBR: True. We have events where event target is the element.
Rossen: Even if go down path of exposing pseudo element as objects
need to have a way to target through selectors. That way
will have to work here. Only change to model is how to get
to event target.
Rossen: If we expand the pseudo family we have to figure out how to
select. Not unique to this proposal
Rossen: Objections?
RESOLVED: Pseudo elements are targeted via a parent plus a pseudo
selector
CSS Sizing 4
============
Proposal: content-size CSS property
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4229
<AmeliaBR> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override
TabAtkins: With fantasai help and later edits after review with impl
we drafted the property the intrinsic size property in L4
TabAtkins: Sets intrinsic size of the content. We thought we could
do it by manipulating contributions, but not workable so
it explicitly sets the intrinsic size. Further discussion
about how to interact with overflow.
TabAtkins: This is what we discussed at TPAC and said it was cool.
It's authored now, review if you're interested
florian: Contribution vs intrinsic summary?
TabAtkins: Are you familiar with difference? Contribution is what a
child element will tell parent its size is when parent
defines size. If the child has width 50px it will say
that regardless of content
Rossen: Important to know it's border box size of the child. Content
is content size which is content-box. That trips a lot of
people
TabAtkins: Reason why we couldn't go with contribution is because it
doesn't have effect on sizing of element itself. It only
effects parent's size. As defined before this property
contribution is how it wants to be sized normally. Had to
switch to the intrinsic size so when it tries to size
itself it uses those contribution
AmeliaBR: I think new name helps clarify. It's using wording we
have. As long as consistent that this new property does
the intrinsic size it might help clear up confusion
TabAtkins: fantasai and I concerned with spelling being tricky, but
it's used throughout the language so we figured it was a
lost cause and should use the same word
AmeliaBR: One point from heycam at end of issue about naming of
keywords. He has a good point that legacy and auto aren't
informative. Before naming something legacy we want to
make sure we're certain only use case is describing stupid
existing behavior
TabAtkins: fantasai and I are convinced this is bad old legacy
behavior and you wouldn't want intrinsic size of a
scroller to report a really wide size. Point of a
scroller is it's scrollable. We believe this is legacy
and we do not want it. Lost opportunity to fix it but we
think it is a straight up mistake and naming reflects that
<fantasai> Issue wrt legacy vs normal
https://github.com/w3c/csswg-drafts/issues/1865
Rossen: Proposal?
TabAtkins: No resolution now. We did resolve at TPAC. This is a
request for review.
AmeliaBR: Resolve to accept the new names?
TabAtkins: Probably? Let's resolve on intrinsic-size as the name
with 'auto' and 'legacy' values
Rossen: Proposal: intrinsic-size is the name of the new property and
value set is 'auto' 'legacy'
emilio: Wasn't there a proposal to set intrinsic size and that's
separate? Seems like it should be a size not a keyword
AmeliaBR: Default is a keyword that is do what we normally do
TabAtkins: And you can specify a length or 2 lengths
Rossen: Objections to intrinsic-size is the name of the new property
and value set is 'auto' 'legacy' and a length?
RESOLVED: intrinsic-size is the name of the new property and value
set is 'auto', 'legacy' and a length
Grid 2
======
Subsetting grid-template-areas in subgrids
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4411
fantasai: Presenting the issue: Mats pointed out don't have way to
have subgrid...if you have a grid area that's named with
template and a subgrid that partially overlaps it will
have only inherited line names. Might have foo-n line in
the middle, but foo-start not inside subgrid
fantasai: If you try and place item in slot foo it can't find the
start line
fantasai: Can we get that to fit within the part of the slot where
it overlaps
fantasai: Multiple ways to impl with proposals in issue. One is
template areas are handled specially and generate extra
line as necessary in order to have both edges represented
within the subgrid.
fantasai: Disadvantage is if you created grid area using lines it
doesn't behave the same as with template.
fantasai: Another proposal was define that if we can't find and
foo-start lines or any foo lines in subgrid as searching
grid-column-start instead of going to the nth edge of the
subgrid we search into previous area
fantasai: Problem with this is it's a slight change to general way
grids work; could be web compat
fantasai: Another is change search direction only for line names
that start with 'start'. Again a behavior change
fantasai: Last is don't handle template subsetting and you have the
case where n line exists but start doesn't
fantasai: Active discussion in issue, I don't think there's a clear
right answer. Easiest is we pull the line names and you
get weird results if using name from parent template grid.
AmeliaBR: I don't think anyone will have strong opinions without
looking in great details. Are you just letting us know?
fantasai: Wanted to collect opinions. If no one has anything to add
we can come back later
Rossen: I think we should continue on GH on this one
AmeliaBR: Isn't this a bit of a rush b/c FF is shipping?
fantasai: Yeah, we should aim to figure out in the next week
Rossen: Once we have a proposed solution we can add it.
`grid-template-rows/columns` Computed / Resolved Values for 'subgrid'
values
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4362
fantasai: Have a WG resolution, noted there is a minor point
that...we took resolved value as used value similar to
regular grid. What we didn't consider is we unroll repeat
values and truncate line names list to number we have.
Didn't consider if adopt parent names active on sub grid.
Mats prefers to leave then out of resolved value
TabAtkins: And we're fine either way
AmeliaBR: Debate is return extra information about the computation
rather keep simplest computed style?
Rossen: In case of one line name in subgrid and that name comes from
parent grid it will serialize to nothing. Is that proposal?
TabAtkins: Yes, if subgrid didn't get line names it will resolve to
enough empty line name sets to give number of lines. You
won't see parents line name
Rossen: This makes sense from model point of view. Trying to think
through scenarios where you need awareness of names
TabAtkins: If you're trying to do some modeling on your own based on
line names you might want full set. You can walk up grid,
but it is more work. I suspect that's a low value case.
Given not reflecting them down is easier for impl I'm
fine leaving off
Rossen: Also I think it is a better model. We can later on if
there's use cases we can add with a different serializer
Rossen: It's a good clarification to the previous resolution
oriol: I think current wording is confusing it says excluding those
defined in parent grid. What if they define same name, do we
want to include? I think you're trying to say only include
the one locally
TabAtkins: Yes, it's local names, not local names minus parent. We
can reword to make it clear
Rossen: Anything else?
Rossen: Proposal: Serialize the subgrid template rows and columns to
only include line names defined for the subgrid locally and
not include names that came from the parent grid
RESOLVED: Serialize the subgrid template rows and columns to only
include line names defined for the subgrid locally and not
include names that came from the parent grid
CSS Text
========
Define break at space to remove a space explicitly
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4308
florian: Turns out that it isn't exactly defined or interoperably
implemented what happens with interaction of dropping
collapsible whitespace and bidi. If something would have
been at the end and bidi moves it do you still drop it?
Fuzzily defined. Chrome and FF do one thing, Safari and
Edge HTML is different. I think Chrome/Firefox makes more
sense. Screenshots in the issue
florian: I propose we adopt Chrome/Firefox behavior and task editors
to define it
myles: Webkit would be willing to change
Rossen: Edge HTML this could be considered. It's reasonable behavior
florian: Proposal: Adopt the Chrome/Firefox behavior and action the
editors to spec it
Rossen: Can you be more specific?
fantasai: Space before a line break is removed even if reorder to
middle of line by bidi reordering
RESOLVED: Space before a line break is removed even if reordered to
the middle of line by bidi reordering
CSS Sizing
==========
Adding a 'size' shorthand for 'width'/'height'
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/820
TabAtkins: Discussed in past. Useful because size often set
together. @page rule has a size declaration and we can't
collide names.
TabAtkins: fantasai had a great suggestion to unblock. Rename @page
declaration to page-size. Define @page has a parse time
alias of size turning into page-size and that frees up
size.
TabAtkins: Any existing pages using size will work. Anyone using
CSSOM to page @page will see a page-size property. I
suspect that's almost 0 since @page is only useful in
printing. Printing doesn't have much JS support. Almost
no possible breakage and this will let us do the size
thing we've wanted to do for at least a decade.
TabAtkins: Clever way to get what we want.
florian: I think you're slightly overstating lack of JS support, but
I agree with the argument
Rossen: It's a cool proposal. I'm in favor. Other opinions?
dauwhe: I'll try and contact Prince about this
dauwhe: They're a PDF formatter that uses @page and supports JS
Rossen: Should we wait?
dauwhe: No, go ahead
Rossen: Thanks for the reach out
florian: Since this is new aliasing should we be explicit about how
it can be used?
fantasai: It's defined at parse time and you never see the other
name.
florian: Of CSS file?
AmeliaBR: Does become a question. If you use cssom method to pass a
string that's parsed that is also parse time. Need defined
somewhere. Need to define it somewhere for explaining
relationship of MS prefixed force-colors vs new force-color
florian: We have general aliasing, but this alias is weird
TabAtkins: Normal is shorthanding based. Property then does show up
in all contexts. This would be not that. Does need
clarification. Happy to work to see exactly what to
clarify.
emilio: If can put width and height in @page this would be quirky
because size means one thing in @page
emilio: Can set width and height in @page rule. Means size does
something different in @page then everywhere else.
TabAtkins: That's why we can't overlap. Because size is not a
shorthand in @page
fantasai: Confusion from naming property anything other than 'size'
is higher then size in @page not being width and height
florian: Dev tools should be warning about this. If page-width
exists and you try and use size you should be warned.
TabAtkins: I don't think any browser respects @page size declaration
florian: Chrome does
TabAtkins: Okay. Cool. I think spec should clarify that it's
page-size and it's required to do this parsing. And I'll
file a bug on our dev tools that we should have a maybe
use something else
Rossen: Proposal: Add size as a shorthand for width and height for
everywhere by @page?
fantasai: Several things. 1) We are redefining the size property in
@page to be called page-size.
Rossen: Let's resolve there first
fantasai: Also defining that size in the page context parses into
page-size
fantasai: Once that's resolved, then the size property is a
shorthand for width and height
Rossen: Objections to these three steps?
RESOLVED: We are redefining the size property in @page to be called
page-size. Also defining that size in the page context
parses into page-size. The size property is a shorthand
for width and height
<AmeliaBR> (To clarify my earlier comment, the similarity to forced
color was that any rule inside the `@media
(-ms-high-contrast)` would include an implicit
`forced-color-adjust: none` declaration added at parse
time. But doesn't look like that got included in the
spec, it was just a suggestion of how MS could handle
internally.)
CSS Text
========
Need additional value of word-break for Korean
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4285
florian: Reminding people: Korean traditionally written like
Japanese without spaces. Now use spaces, but line-breaking
has not changed where you can break like Japanese
florian: Some typographers agree in many contexts it's nice to
line-break Korean like English. Not everyone agrees with
that. Discussion in GH shows that.
florian: We need another value because the existing 'keep-all' only
works if you can lang-tag. Do we care about allowing this
behavior for Korean that can't be language tagged? I think
we do.
florian: If you're writing Korean in a text editor or from a
database where you don't have language tags it's tricky to
tag on the fly. Amount of magic you have to do is really
obnoxious.
florian: Either we say when editing this behavior is impossible or
we say for the Korean alphabet you get the normal or we add
keep-all-hangul
myles: Putting Hangul in the value doesn't make sense when you use
lang tag
florian: But you can't put lang on contentEditable section because
you don't know what will go in there. If they do a mix of
languages you can't language tag. Adding spans on the fly
depending on what user types is performance-wise terrible.
myles: Seems wrong level of abstraction. Wish it could be
generalized. Worried eventually have 100 different lang
specific values.
florian: Possibly. It's really that there are two normal behaviors
so normal can't do the right thing. We need two normals. I
don't think there are that many languages that need two
normals
AmeliaBR: That's my concern too. Before settling on language
specific keyword do more research to see if more languages
have this issue. How much input have you had from general
i18n experts beyond Korean use case
florian: Have not heard of any language. People who would probably
know have been involved
fantasai: I think if there were other languages they would need a
separate keyword. It's separating Hangul from Chinese and
Japanese. Most other writing systems don't mix in the name
way and not that many that break everywhere like this. I'm
not aware of any others that alternate in the same way as
Korean
jensimmons: I like what florian is proposing. I understand concern
on break from purity, but I feel like one thing web
didn't do well was support international languages. This
is a way web can keep up with evolving graphic design
changes. Feels like a way to make sure web supports a
culture and its ability to evolve instead of saying it's
complicated and we don't know where it's going to go
chris: Good idea as long as clearly defined what this value does
when don't meet Korean text. I think it's a thing we need. If
web started in Korea we would have had this from the start
florian: If you're not in Hangul you do the same as keep-all
tantek: I want to re-raise something from AmeliaBR. AmeliaBR asked
how much input we had from general i18n experts. I want to
raise that and propose before we resolve we file and issue
on i18n discuss ( https://github.com/w3c/i18n-discuss/issues )
to get input from broader experts.
tantek: florian saying you haven't heard of other languages isn't
quite sufficient
florian: Reaching out to i18n, yes. But to have a modern language
that has the exact same behavior so we can name the keyword
something else we need a language who by defaults breaks
between every language and want to move away from that and
there aren't that many.
tantek: I'm saying it shouldn't be dependent on just your expertise.
You may be correct, but worth getting that group to take a
look.
myles: Wanted to ask if any thought given on how to impl? Like are
there line breaking libraries that impl this behavior?
florian: This would need to be impl in ICU. ICU seems amenable to
this but if we expand ICU would have to expand as well.
Rossen: I hear requests to get more from i18n. florian are you okay
to do that this week? To get traction or a checkmark to say
it's good?
florian: Yes, I can look into this
Rossen: That's it for today, have a great rest of your week.
Received on Wednesday, 16 October 2019 22:35:53 UTC