- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 18 Mar 2020 19:35:04 -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 Color Adjust
----------------
- When fantasai was editing in the resolution for issue #4175 she
discovered a complication in how to handle elements which are
not supposed to be forced to CanvasText such as buttons and
inputs. She proposed if the UA stylesheet has a background-color
rule we revert the author level.
- AmeliaBR had a second possible solution which could address the
potential to have a color mismatch when there's an element
inside a button. In her proposal after reverting the rules then
you would go through and then do a pass to figure out the
background.
- To help the group decide some examples will be created and
AmeliaBR will write up spec text for her proposal.
- RESOLVED: Option 3- Rewrite all author rules for affected
properties to specify 'revert' instead (Issue #4020:
User origin !important vs. forced colors mode)
CSS Inline
----------
- RESOLVED: Allow sink of 0 for initial letters (Issue #3698:
initial-letter should allow zero sink?)
CSS Backgrounds
---------------
- RESOLVED: Close as won't fix for lack of ideas on how to properly
fix it. If someone comes up with a workable idea we can
re-open (Issue #2108: 'border' shorthand resets
'border-image' but can't set it)
Resize Observer
---------------
- The request to get the physical size for an image in issue #4005
(physical, rather than logical, dimensions – for images) made
sense to the group, however more fleshed out use case from the
original reporter would help the group figure out how best to
change the spec.
CSSOM View
----------
- The proposal for issue #4541 (Let offsetWidth / offsetHeight
report actual size?) was no change and to keep the Chrome/Safari
behavior, however before the group can decide more test cases
were necessary, including against vendors that do printing such
as Prince.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Mar/0007.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Elika Etemad
Javier Fernandez
Megan Gardner
Chris Harrelson
Daniel holbert
Dael Jackson
Daniel Libby
Peter Linss
Stanton Marcum
Myles Maxfield
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Manuel Rego Casasnovas
Scribe: dael
astearns: Does anyone have any changes to the agenda?
astearns: One thing I wanted to start with is we'll have a virtual
meeting at the end of next month
astearns: Might be good to have a dry run in the next week or two.
Perhaps pick a spec that has issues that need in depth and
schedule an hour that works for people involved and try
out the technology
<jensimmons> good idea astearns
astearns: Think about your specs and one that could use the extra
hour of focus and I'll start a thread on the private list.
Then we can figure out how the virtual meeting will work.
<jensimmons> That will also give us a chance to test our choice of
technology. I was just on a Zoom meeting with 600
people, and it held up really well.
CSS Align & CSS Grid
====================
Do grid items that have "no baseline set" participate in baseline
alignment?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4675
astearns: Is TabAtkins on?
<TabAtkins> ah dang, one sec, totally forgot what day it is because
time isn't real any longer
<TabAtkins> but also: because of that, i once again forgot to dive
into this issue
CSS Color Adjust
================
background-color in forced color modes needs more than a simple unset
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4175
Rossen: I think fantasai has this one to resolve on the edits I
suppose
astearns: lajava put this on the agenda
astearns: Wait, wrong link
astearns: Yes, last comment is fantasai going over actual edits.
<fantasai> https://github.com/w3c/csswg-drafts/issues/4175#issuecomment-595582638
fantasai: We were talking about forcing the colors other than alpha
channel to be canvas text but we don't use canvas for
every item. Example input element.
fantasai: I wasn't clear on that case. I specified if UA stylesheet
has no background color rule then we force everything to
canvas text. If it does have a rule then we revert the
author setting away. Edits here:
<fantasai> https://github.com/w3c/csswg-drafts/commit/cffce2008ce030f4b098aece82b95c109485594f
fantasai: I wanted to check because it's a weird case but I didn't
know what else to do that would work
AmeliaBR: There are 2 things we need to factor in
AmeliaBR: One is if the custom layout and stylesheet of the website
is designed with overlapping content that requires opaque
we need to keep that. If transparent keep that
AmeliaBR: Other is background color in forced color have particular
pairs. Regular canvas and text for main, buttons and
inputs have other pairs
AmeliaBR: I'm not sure whether this would fix both those cases. But
those are the two trying to address
fantasai: If you want to do this 100% right for most elements you
force to canvas but elements inside button you fore to
button background. But that's really tricky. But because
buttons don't have much in them, decided not to worry
about that complication
Rossen: What you described sounds concerning. We can't be dependent
on composition or layout while deciding computed value
fantasai: Right.
Rossen: Which is how I heard you describe
AmeliaBR: I wasn't suggesting browser look at layout. Suggesting
browser respect if author styles have opaque background.
Important because overlapping content
fantasai: What I didn't want to do...what we could do...what is in
the rule handles that for everything except things like
buttons. Force all channels other than alpha. For buttons
and input fields I didn't put that because seemed harder
to calculate what's going one. Easier to revert in those
cases. Because we don't have complex things if button is
semi-transparent not it's opaque
AmeliaBR: Where rule will fail is element inside a button where for
whatever reason it's expected to be opaque but the UA
stylesheet won't have a rule for a SVG inside a button,
just a rule for the button. As written that case would get
canvas background which wouldn't be appropriate because
foreground for the span is the buttons.
AmeliaBR: Instead of making the switch based on if there's a UA rule
could we make this a special background color being a
special keyword that means find opposite of foreground
using system color pairs? We have defined pairs in system
colors, opposite of button-text is button-face. If we
could define that the background color in these cases is
based on look up current color and calculate proper
background from that
fantasai: Only works because reverting color right?
AmeliaBR: Right, after revert so color gets forced color for text of
that element
Rossen: Perhaps this is describing different forced color scenario
then one for windows? Not sure how foreground color is
different from text
fantasai: First go through and do revert rules. As result you've
reverted color so document is canvasText and button is
buttonText. That's done and colors have inherited through.
Span inside a button is also buttonText.
fantasai: Now try and figure out background. Background says we'll
take colors spec and set all non-alpha channels to be the
color that is the background associated with the current
color. If we're in the doc in a span we say what's the
color and color says I am canvasText and so pairing is
canvas and we force to canvas color
fantasai: Button says it's button text to background color forces to
button-color.
fantasai: AmeliaBR is doing an interesting cheat because color is
inherited which color you force to needs to be inherited.
Because color is inherited taking advantage of that.
Rossen: Thank you for explaining.
Rossen: Is this describing a different feature, though? On windows
sets both background and foreground. So can only have colors
chosen by user
fantasai: Yes, that's what happens but doing color calc first and
then do background based on that
Rossen: But background color is also provided so why do we need to
compute?
fantasai: Element inside a button. Span in a button what background
do you use?
dbaron: One other concern with what I think proposal is is while
good practice is to set on same element, might in reality
set colors on a descendant of background. Even though color
inherits setting the background might not be reliable
AmeliaBR: Should be effected by general color property reverting
rules.
AmeliaBR: To address Rossen concern is the difference between this
and MS browsers is wanting to support the situation of
elements in user stylesheet that have opaque but don't
have opaque in UA. That's where complication comes from.
Pop up that's outside borders of button or custom inputs
that do something a little different then UA stylesheet
and you need an opaque background browser needs to know
what opaque bg to give that element
fantasai: I think the concerns is elements in author stylesheet with
opaque
AmeliaBR: Yes, sorry
fantasai: Back to beginning. Base set of rules is instead of
reverting background we wanted to address elements that
have an opaque background in author and you want to make
sure everything is right in forced color. Decided to have
all background match canvas but keep alpha channel. That
doesn't work for things like button or input. So we needed
to do something for those since can't force to canvas-text
fantasai: One proposal is UA needs to know what's not canvas
background and force those to what supposed to be. In
button it forces to button background. Input to field
background.
fantasai: Problem with this is that if you have element inside the
button that has a background that element isn't registered
in UA stylehseet as special background and forced to
canvas. Might not be right when it's on a button. Because
it's opaque we change to canvas which is white and then we
have a button with a white background so it's white text
on white button and unreadable. That's what AmeliaBR tries
to fix
emilio: Looks like FF. For color and background we have revert and
if nothing reverts we set to initial. Don't preserve alpha
but could
fantasai: What I put in spec is assumption that opaque in buttons is
not a thing we want to worry about. For elements with
background in UA stylesheet UA knows that and reverts and
doesn't modify alpha channel. We could decide we don't
want to solve the problem or we can use AmeliaBR trick
AmeliaBR: Would people feel better if we wrote text and came back?
astearns: I was about to suggest that. I think it's getting a bit
circular. Sounds like not talking about reverting but an
additional trick
AmeliaBR: Changing fantasai edits from a week ago
astearns: Modify, not revert
fantasai: Doesn't change behavior of base cases, but changes
mechanism to get behavior
<Rossen> sgtm
astearns: Let's go back to issue. AmeliaBR you can write up your
alternative text and we can come back on another call
after people can take a look and then we can decide if we
want to change
chrishtr: May I ask for examples?
AmeliaBR: Sounds very good
User origin !important vs. forced colors mode
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4020
fantasai: The spec says we add revert !important at user level to
wipe out author level. Also reverts entire user level of
cascade
fantasai: I think intent was leave user styles.
fantasai: If we want to do that correctly need origin between user
and author. Sort of have this which is non-css
presentation layer. It's beginning of author and has no
spec
<dbaron> could these rules just be in the author level (at the top)?
fantasai: We could define there's a new UA control layer called
presentation-hints and importance is between user and
author and then it works as intended. Or we can do
something else. Currently spec doesn't work as intended
AmeliaBR: If we can explain behavior using source order; say this is
inserted at origin before any other rules at origin; I
think that's easier than new cascade origin. If that
doesn't work then define it explicitly
fantasai: emilio says they (Firefox) treat all author level as
revert so we can spec that way.
astearns: Is this something where we have more tools to solve when
we get to custom origins prop?
fantasai: No because need to revert...revert in author needs to
revert non-css presentation hints. So we can create a new
origin or do what emilio says FF is doing
astearns: Set of properties?
fantasai: [missed]
emilio: I don't understand why revert !important wouldn't work at
end of author. Might be easier to spec that way. In practice
I think the observables are same as FF.
fantasai: I'm happy to put in FF behavior
astearns: Any concerns with specify FF behavior?
astearns: Reading emilio comment: Treat author level declarations
with a set of properties as revert
fantasai: 3 solutions:
<fantasai> 1. Create new origin between author / user origins
<fantasai> 2. Insert 'revert !important' rules in author orgin with
highest possible specificity
<fantasai> 3. Rewrite all author rules for affected properties to
specify 'revert' instead
fantasai: I think 3 is what emilio is saying FF does
fantasai: All of those would work. I don't have an opinion between.
astearns: I think 3 is easiest to explain to authors. Just my
personal opinion
fantasai: That's a vote for easy to explain and a vote from FF it's
easy to impl
Rossen: I think #3 makes sense
astearns: AmeliaBR okay to you?
AmeliaBR: Yeah. So long as clearly defined.
astearns: Prop: Option 3- Rewrite all author rules for affected
properties to specify 'revert' instead
astearns: Objections?
RESOLVED: Option 3- Rewrite all author rules for affected properties
to specify 'revert' instead
astearns: Thanks emilio for adding FF behavior
CSS Inline
==========
initial-letter should allow zero sink?
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3698
astearns: Are myles and Dave on?
myles: It seems clearly valuable given examples and impl shouldn't
be hard. Seems good
astearns: Did you see my last comment on details?
myles: I can do that
astearns: Basically we have rules about where things get pushed
below and initial-letter. Just need extra details for this
case. Where line is pushed and size of initial letter. I'm
assuming size for initial is 15 with a 1 line drop which
should be same size as with 0 line drop. Measuring from
line below initial instead of next to
astearns: Accommodations for descenders needs an extra bit to avoid
colliding
fantasai: Have rules about descenders that would continue to apply
astearns: Need to have rules for this spec text
myles: I think I'm with fantasai that both cases size and descenders
are both present when sink is not 0 so we should make the
solution general to apply to all sinks
astearns: In agreement. Just in my reading doesn't seem to cover all
cases so want to make clear consistent sizing and descender
astearns: Objections to allow sink of 0 for initial letters
RESOLVED: Allow sink of 0 for initial letters
CSS Backgrounds
===============
'border' shorthand resets 'border-image' but can't set it
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2108
fantasai: I don't have any idea what we can do about this other then
going back in time to change. I think there's logic behind
behavior and we don't change it now
TabAtkins: Agree. Change would make shorthand unusable. I think it's
won't fix
astearns: I don't think not usable, but not useful addition to the
shorthand
astearns: Prop: Close as won't fix for lack of ideas on how to
properly fix it. If someone comes up with a workable idea
we can re-open
astearns: Concerns about closing won't fix?
RESOLVED: Close as won't fix for lack of ideas on how to properly
fix it. If someone comes up with a workable idea we can
re-open
Resize Observer
===============
physical, rather than logical, dimensions – for images
------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4005
fantasai: Someone posted a strong use case to return physical
dimensions. Proposal is add physical to what
resize-observer can return. Use case makes sense and we
should do this
iank: Use case is? How will they use this?
astearns: By my reading the block and inline size in a flow that is
orthogonal to an image's useful orientation doesn't really
help
astearns: Though in reading this I'm a little confused as to if you
know that's the case why you can't just flip the sizes you
get. Are there cases where you don't know if block
direction is useful?
myles: Specified that canvas rotated in vertical?
fantasai: Not rotated. If he wants width of image he has to switch
based on writing mode so he needs to switch to decide if
he wants inline or block
iank: No objections to adding but it's not explicitly a use case
since it doesn't say how he's going to use information
fantasai: You can ask him for more details
myles: In agreeing with iank another solution solved by this would
be not return logical and only physical. Need some
information to know that both is better than just physical
fantasai: We're already returning inline & block size. It's just
that on image you then need writing mode
astearns: I don't think we can remove inline and block size and
return something else
myles: Not clear to me canvas is used enough that it's a problem to
change behavior
fantasai: Shouldn't return different APIs depending on the element.
astearns: Hearing a little concern about adding something that may
or may not be useful given data. Do we need to go back
with code examples or request more information?
dholbert: Also asking if they want to observe it or have it
returned. From sketch is seems logical size isn't changing
but physical is
AmeliaBR: Wouldn't they change at same or observing from change of
writing mode?
dholbert: When writing mode changes they want notification? Not sure
AmeliaBR: Trickier. Observing size has changed and adding 2 entries
to dictionary is straight forward. Changing what triggers
observation is more complex
astearns: We have some questions and poster offered a more fleshed
out use case so let's ask for more details on these
questions.
CSSOM View
==========
Let offsetWidth / offsetHeight report actual size?
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4541
TabAtkins: I'm confused on this issue. Thanks for digging up issues
fantasai. According to the example script and I verified
Chrome. FF it reports offset of A is 40x40 but that's the
div child. Chrome doesn't and reports 0x0. It has 2 boxes
surrounding the div and because whitespace is collapsed
the boxes are 0x0.
TabAtkins: Haven't done spec diving to see if it allows A to report
div as size. I think Chrome and Webkit is correct here
and we close no change
AmeliaBR: Do you have link to spec that says block inside inline
isn't counted as part of inline dimensions
TabAtkins: You return size of first layout box. A element starts
with inline that has whitespace only
AmeliaBR: Entire A includes div but there's a 0 width
TabAtkins: Not quite. In box tree div is not child of A. A produces
2 siblings but they're children of A parent.
<astearns> spec link:
https://drafts.csswg.org/cssom-view-1/#extensions-to-the-htmlelement-interface
dbaron: I think there are multiple explanations for difference and
worth checking which. Possible it's due to FF treating block
as inside the inline. Another possibility is difference if
there's a box generated for that little piece or not
TabAtkins: Yeah, and couldn't tell that without diving more
dbaron: Could check if there's a difference if you put the letter in
there
TabAtkins: Yeah.
TabAtkins: Letter in there still considers div part of A but the
height is a little higher
TabAtkins: FF makes height a littler higher. In Chrome it's still
0x0. Appears consistent. Chrome generates the empty box,
FF considers it a part
dbaron: Not sure how it's higher because not sure what box it's
dealing with
astearns: Seems like nice to be consistent here
<TabAtkins> With <a>foo<div></div></a>, you get a "foo" with the box
below it, so the height grows in Firefox.
dbaron: Nevermind.
dbaron: Code for getOffsetRect does go through all fragments
TabAtkins: Rather then get first?
dbaron: Yeah. At least Gecko code goes through all
TabAtkins: Sounds like Chrome doesn't
dbaron: Maybe difference is do you go through all fragments
AmeliaBR: Ran quick test using issue example + character before div
and that way we can tell if it's about collapsing
whitespace and in that case if there's a character FF
gives width of div when giving offset of A element. It's
not the first inline, but entire thing. Chrome gives size
of first inline
dbaron: Another test is letter before and after div
<TabAtkins> before and after:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7825
Chrome still reports the height of just one line, so
it's not iterating all the fragments
florian: Another thing confusing is Chrome behavior which is simple
about first. For FF with most all fragments are next to in
this case. But it's not clear all fragments will be next to
each other. If it's multi-col they're not adjacent.
dbaron: I think it's smallest rect that encloses all
florian: So multi-col you get unrelated stuff, but when printing?
dbaron: API doesn't work in printing. Don't have access
iank: I think we had this conversation with client height in
multi-col. Two things you can do, union of all clients or
stack them all. Impl stack. CSS Regions make it funky. Need to
be consistent.
emilio: Chrome does take height in getBoundingClientRect
TabAtkins: It should because div height influences bounding client
rect. But this is just client rect
florian: Not working in printing, saying when we print there is no
script so it's not there? Because that's not true. UAs that
renders to PDF runs scripts so you can ask this question in
an engine that's fragmenting to multiple pieces not next to
each other. Easy for Chrome example, not sure what it does
if try and stick together
astearns: Top of hour. I think way forward is write test cases and
then come to agreement what success for those cases should
be and get that into spec
astearns: Sound okay to everyone?
florian: I would suggest including something like Prince in test
cases to get an engine that prints and runs scripts
astearns: Fair enough.
astearns: Thanks everyone for calling in. Please consider set of
spec issues that deserves a trial for the F2F meeting
<TabAtkins> As far as I can tell, the test cases are all
consistently showing that Chrome returns the dimensions
of the first fragment, and Firefox gives a bounding rect
of all the fragments (including the blocks splitting the
inline).
<dholbert> TabAtkins, RE unioning vs. "first layout box" - note that
Chrome does seem to union for a scenario of an inline
element that's fragmented via explicit breaks:
https://jsfiddle.net/dholbert/hpxo4g2r/
<TabAtkins> dholbert: Yeah, that's all still within one layout box.
<TabAtkins> (we were throwing around "fragment" casually, but the
spec doesn't say fragment, it's about layout boxes)
<dholbert> hmm, https://drafts.csswg.org/cssom-view/#css-layout-box
Issue 1:"The terms CSS layout box and SVG layout box are
not currently defined by CSS or SVG." :D
<dholbert> maybe that's part of the problem
<TabAtkins> lol
<fantasai> "fragment" is a CSS3 term, CSS2 just called them boxes...
<TabAtkins> yeah, css2 mixed "box" and "fragment". But if we read
CSSOM-View literally, as referring to boxes, then that
a-with-breaks is one box, and the a-with-div is three
sibling boxes.
Received on Wednesday, 18 March 2020 23:35:57 UTC