- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Dec 2019 18:16:35 -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.
=========================================
CSS Text & CSS Sizing
---------------------
- RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
CSS Fonts (Continued)
---------------------
- RESOLVED: Add them with the `ui-` prefix and make them not match
if they're not available (Issue #4107: system-ui fonts)
MathML
------
- The MathML spec is almost complete and includes its CSS
integration: https://mathml-refresh.github.io/mathml-core/
- Anyone with issues should open them against the spec now.
ScrollTimeline
--------------
- RESOLVED: Move scroll-timeline (
https://github.com/WICG/scroll-animations/issues/51 )
into csswg-drafts
CSS Text
--------
- Florian presented the current state of the word space insertion
proposals; there were some concerns about CSS doing the automatic
insertion feature (due to complexity of linguistic analysis,
etc.)
- There wasn't a decision on issue #4297 (Hanging spaces cannot be
scrollable overflow) because there's a desire to avoid magic
when explaining how the browser allows access to these spaces.
Transforms
----------
- RESOLVED: Publish CR of css-transforms
CSS Tables
----------
- RESOLVED: Any math expression of a complex type is treated as
auto. Simple typed things continue to work as today.
(Issue #94: calc for table layout)
===== FULL MINUTESS BELOW =======
Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda
Scribe: emilio
Scribe's Scribe: heycam
CSS Text & CSS Sizing
=====================
When to/not to include preserved trailing spaces
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
fantasai: [summarizes situation]
fantasai: proposal is to accept the proposal in
https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
fantasai: I think we should resolve on that
florian: I think koji is ok with it now
Rossen: Objections?
RESOLVED: Accept the proposal in
https://github.com/w3c/csswg-drafts/issues/3440#issuecomment-530702998
CSS Fonts
=========
system-ui fonts
---------------
GitHub: https://github.com/w3c/csswg-drafts/issues/4107
<fantasai> This is my position:
https://github.com/w3c/csswg-drafts/issues/4107#issuecomment-525824422
myles: Should we expose these like any other font like "Times new
roman" or as a keyword like a generic font family, which
other browsers would also implement and whose behavior would
change across OSes... ?
myles: I'd prefer the later
fantasai: (explains her position above)
fantasai: tldr it makes sense to have system-ui keywords, but they
should be exposed also behind an actual font name
myles: It's impossible for us to determine whether people want them
because the fonts are nice or because they're systemy
Rossen: How are you going to determine it?
Rossen: Expose it with a proprietary name and you're done
koji: I think regardless of exposing them via the name I think
there's use case for the keywords
florian: I think they should be exposed by name, and if after that
there's still users asking for that then we're done
florian: but just font families is not the only thing for emulating
the system
myles: But it's a required part of matching the system, regardless
of the rest of the design
florian: It doesn't seem helpful to use system-ui vs. named, if you
can just ua-sniff and set the font name
dino: It may help authors in other systems too
koji: We learned from system-ui that authors don't want the exact
same font as the system
koji: On windows server a bunch of big pages didn't want the system
font which was tahoma, they wanted segoe instead
Rossen: That's why when we released segoe we did it as a font with
a real font name, not as a special keyword
florian: That's interesting, so this is appropriate in the sense
that people wants ui fonts, but not necessarily the system's
ui font
myles: So ui-serif rather than system-ui-serif?
florian: If that's the use case that sounds fine
nmccully: Having a shorthand seems useful to guarantee that the font
is current, is there, and not have to worry about the list
of system fonts
myles: So it seems we're coalescing to add `ui-rounded`, `ui-serif`,
`ui-monospace`, ...
florian: I'd also also encourage apple to expose them by name
nmccully: That seems useful
myles: ok, we'll do both
florian: Less sure about *-rounded
fantasai: What do we do for `ui-rounded` if there's no rounded font?
fantasai: Maybe you have only arial and times?
fantasai: What do you fall back to?
florian: I'd propose just for it not to match so it falls back to
the next of the list
leaverou: If we need more granularity to system ui fonts why mapping
them to apple?
leaverou: why not system-ui-titletext?
myles: When a platform has a different font for titletext we can
consider that
RESOLVED: Add them with the `ui-` prefix and make them not match if
they're not available
MathML
======
<bkardell> https://mathml-refresh.github.io/mathml-core/
bkardell: Just letting everybody know that the spec considerably
complete, and so is our initial implementation
bkardell: Lots of wpt, lots of answers in the spec
bkardell: total css proposals amount to four:
bkardell: one of them is `display: math`
bkardell: other three is to display the information that you need to
extend mathml
bkardell: We intend to send an intent to implement in October to
upstream it so please open your issues and ask your
questions and help us make that successful
iank: mathml cg has decided on some of the mathml / css integration,
it'd be great to take a look at those
ScrollTimeline
==============
github: https://github.com/WICG/scroll-animations/issues/51
majidvp: Last f2f I explained the 2 big issues that remained, the
css syntax and the problem that the spec only accepts
concrete scroll offsets and such and most use cases rely on
viewport offsets and such
majidvp: so we got lots of feedback from devs that it's hard to
compute the right offsets
<fantasai> basically, same problem as scroll-snap had in the
beginning...
majidvp: So we want to propose some changes to scroll timeline to
make the scroll offsets not specified but match
intersection of boxes or such
majidvp: flackr has done a polyfill for that and the api
majidvp: What we're proposing here is specifying offsets in terms of
intersection observer semantics
majidvp: which is start and end of animation as intersection
observer offsets
majidvp: Just one-dimensional rather than two-dimensional
majidvp: [goes through the proposal in
https://github.com/WICG/scroll-animations/issues/51 ]
majidvp: We're also proposing a function-like syntax
majidvp: but let me show demos
majidvp: [goes through
https://flackr.github.io/scroll-timeline/demo/parallax/ ]
majidvp: [goes back to the proposed css syntax]
majidvp: There are some open questions like how to fix the
circularity in the case layout moves the element while
animation
majidvp: Proposal is to freeze the offset when the animation starts
majidvp: also how intersections are computed and such
majidvp: These are open questions that we're trying to work through
majidvp: Not proposing concrete solution
majidvp: happy to answer questions / feedback / concerns
smfr: I like the way it generally looks, and I like the
IntersectionObserver thing
smfr: seems much more natural
smfr: Can you do something like a spinner that stops as soon as soon
as you scroll away?
majidvp: ScrollTimeline should not solve that, you need a trigger
for that...
majidvp: I don't wanted to fix that use case here, but maybe a
`:visible` pseudo-class or a CSS intersection observer like
syntax
iank: You can polyfill that already with intersection observer, I
think it's nice to keep it focused
dino: I think this would be a simple addition now that we have the
range to address this use case
smfr: There's also the case where you stop the animation but let it
run to complete a cycle
smfr: so that it comes back into the viewport in a good position
majidvp: May be addressable with the range
smfr: Another piece of feedback is that it seems that the css api is
getting a bit out of control
smfr: I'd be fine with just a JS api
majidvp: That's the opposite of the last F2F discussion, but it's
fine for me...
heycam: The small additions to the Intersection Observer model, they
should just be added to Intersection Observer itself
majidvp: I think they should be added to the spec even if they're
not web-exposed.
heycam: It'd be nice especially if you don't solve the time-based
viewport-triggered animation
majidvp: I _think_ you can compute that with the current
IntersectionObserver given it provides the intersection area
Rossen: Looks awesome, what are you asking from us?
majidvp: Confirmation of general direction would be great
majidvp: May be nice to bring into csswg-drafts, though may not be
that important
Rossen: I think we could do that
smfr: Where does web-animations live?
birtles: CSS
RESOLVED: Move scroll-timeline into csswg-drafts
CSS Text
========
Update on word space expansion
------------------------------
<florian> https://drafts.csswg.org/css-text-4/#word-boundaries
florian: At the last f2f I presented a proposal to expand zero width
spaces into ideographic spaces
florian: I got spec text after the group discussion
florian: Another request was to automatically insert them into the
markup
florian: Got review from fantasai and (less) i18n
florian: i18n was working on line-breaking of Thai text, which needs
some analysis on the text, which is not right all of the
time
florian: since you can use Thai alphabet to write non-Thai languages
florian: So the group wanted to be more explicit about line-breaking
in Thai, which is similar to the word boundary injection
feature we discussed
florian: That's all in text-4, it'd be nice for you to review it
florian: Will start to write text soon, may tweak naming
florian: fantasai was a bit skeptic about the automatic insertion
florian: about whether browsers will implement language-dependent
analysis
florian: I think kindle did that, though kindle does have a bounded
number of languages unlike browsers
glenn: I'm with fantasai, don't do it, many business do this
Transforms
==========
Republishing transforms CR
--------------------------
<Rossen> https://drafts.csswg.org/css-transforms/#CR20190214
krit: We got some editorial changes
krit: I don't expect a lot more changes to the spec
krit: so I expect to be the last CR before the next step
RESOLVED: Publish CR of css-transforms
CSS Tables
==========
Calc for table layout
---------------------
Github: https://github.com/w3c/csswg-drafts/issues/94
xiaochengh: So the issue is what to do with percentages and calc
xiaochengh: Spec says a bunch of stuff may be treated as auto
<fremy> "Given the complexities of width and height calculations on
table cells and table elements, math expressions involving
percentages for widths and heights on table columns, table
column groups, table rows, table row groups, and table cells
in both auto and fixed layout tables MAY be treated as if
auto had been specified."
xiaochengh: I'm proposing changing the MAY into MUST
xiaochengh: It's pretty complicated if we don't treat it as auto
xiaochengh: Second reason is that this is creating friction when
implementing min() / max()
xiaochengh: calc() is complicated, but min() / max() make it a
pretty hardly solvable problem
xiaochengh: so I propose to make this a MUST
TabAtkins: This is what dbaron noted back in the day
TabAtkins: and we punted min and max because of that
heycam: Implementation status?
fremy: All browsers match the spec
fremy: for normal table layout
fremy: The algorithm just doesn't make it possible
fremy: In fixed table layout there's one browser that supports
percentages based on the size of the table
fremy: As to the question of whether we should remove the behavior
for normal table layout is fine
fremy: for fixed layout it'd be nice to also remove it, but Chrome
and Safari
fremy: Do respect it so it'd be nice to remove that
fremy: or add to the spec that it is respected in fixed table layout
and how, which should be straight-forward
emilio: There's also the question of whether we should in presence
of min and max...
emilio: Firefox used to treat calc(%) as auto
emilio: We no longer do that
emilio: but it raises the question of how min and max behave with
only percentages
emilio: I guess that's fine to resolve?
TabAtkins: I don't want to special case min and max on type
TabAtkins: That's awkward
TabAtkins: Having min and max work in some case if you have certain
shapes of expression inside of it
emilio: I think given the way we behave, all browsers treat calc
with percentages as a percentage, we should do the same for
min and max
fremy: That sounds reasonable to me
fremy: If there is a sum of % and px, after you've computed, then
you decide not to do anything, follow the MUST
fremy: If you have min(10%, 20%), the computed value will be 10%, so
you don't have the problem
fremy: I would be in favor of that wording
emilio: What about calc(10% + 0)?
emilio: That's simplifies to 10% in all browsers
Rossen: Yes we've resolved that previously
fremy: So what about fixed mode
fremy: I assume it's probably fine to apply this rule to both?
RESOLVED: Any math expression of a complex type is treated as auto.
Simple typed things continue to work as today.
TabAtkins: https://github.com/w3c/csswg-drafts/issues/3482#issuecomment-451590359
<TabAtkins> calc(0% + 0px) is, per spec and Typed OM, absolutely a
{length: 1, percentage:1} type.
zoe: no objections
CSS Text
========
Hanging spaces cannot be scrollable overflow
--------------------------------------------
Github: https://github.com/w3c/csswg-drafts/issues/4297
florian: fantasai points out that if we treat hanging spaces as
scrollable overflow there's a bunch of cases where we got
scrollbars where we don't want
florian: but on editable stuff you want to create scrollable overflow
florian: blink and webkit agree with me, gecko always treats it as
ink overflow, edge always layout overflow
florian: Proposed resolution is treat hanging spaces as ink overflow
in general but layout overflow in editable context
fremy: How did you test for editable context
fremy: You may be testing a different `white-space` due to UA rules
emilio: It feels weird to special case layout based on editable
context, whatever that is
Rossen: Why?
emilio: There's no good reason for the layout engine to know the
editable state of the DOM
emilio: In Gecko this all works via UA sheets
emilio: We change a bunch of stuff when something becomes editable,
but it's explained through CSS properties
emilio: Specifying something like this seems quite awkward
florian: Make it specific to contenteditable only, and not other
kinds of editable, would be weird
florian: but if it's all kinds of editable, and good old fashioned
textarea, ....
<leaverou> But it can be detected with CSS selectors
emilio: If you do that, I would prefer to have some kind of CSS
value that causes this effect
emilio: and specify in HTML or wherever that contenteditable and
textarea input have this in the UA sheet
florian: If you are editing the content, you never want to not reach
the content
florian: If you are trying to edit/delete them, if the cursor moves
where you can't see it, that's not desirable
emilio: Then the UA sheet can have an !important rule
florian: If we define this how is it magical?
emilio: What if it's something slotted into a contenteditable
element?
fantasai: The main thing that's happening here, if spaces are
overflowing in the document, you don't want to create
scrollbars for them
fantasai: When you're editing text, it's nice to be able to see the
text
fantasai: I don't think authors care. Don't think adding a CSS
property, increasing the number of things authors could
learn, is a benefit here
emilio: Sure
fantasai: It makes sense to allow the UA to make it scrollable
overflow when that piece of text is editable
fantasai: How you got to that state, doesn't really matter
emilio: Why only when it's editable, and not selectable?
emilio: The caret movement is pretty much the same
emilio: Don't know why those would be different
fantasai: The characters are still there, you can select if you go
from one line to the next
fantasai: but there's a higher priority on not introducing scrollbars
emilio: Can we confirm Chrome is doing what you claim it is?
florian: Elika pointed out, if this is awkward to do on the C++
thing, you can have the dedicated CSS value, and make it
!Important, and not accessible to users
emilio: I know how to implement it, just don't want it defined in a
magical way
-- end --
Received on Tuesday, 3 December 2019 23:17:29 UTC