W3C home > Mailing lists > Public > www-style@w3.org > March 2020

[CSSWG] Minutes Telecon 2020-03-18 [css-color-adjust-1] [css-inline] [css-backgrounds] [resize-observer] [cssom-view]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 18 Mar 2020 19:35:04 -0400
Message-ID: <CADhPm3tW7LizVVwb1_x9RyVReffjL2QBxKrxDuirVjwNV2yEAw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 18 March 2020 23:35:57 UTC