W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Telecon 2019-07-31 [css-images] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 31 Jul 2019 19:44:36 -0400
Message-ID: <CADhPm3v85FVB8pZE8hhxYKiZj98KW3iNJVUdhPHbB+pQbHDSzA@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.
=========================================


Charter Update
--------------

  - Work is being done on the new charter. The document is available
      here: https://w3c.github.io/charter-drafts/css-2019.html and
      issues are being created in the charter github here:
      https://github.com/w3c/charter-drafts/issues

CSS Images
----------

  - RESOLVED: Accept proposal with an added note current solution is
              experimental and may change (Issue #3799: Consider
              changing initial value of 'image-orientation' to
              from-image)
  - The proposed text for issue #1984 (Specify fallback behavior when
      replaced or background image content not available) will be
      edited to specifically call out the interstitial state between
      image swaps. Myles will have his team review the text and then
      the group will try and resolve on the next call.
  - RESOLVED: Treat fragment only URLs as only elements, never images
              (Issue #383: Ambiguities in handling url())
  - RESOLVED: Change requirements from 'should' to 'must' (Issue #383)
  - RESOLVED: Add the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls
              (Issue #383)
  - After the group resolves on issue #1984 there will be a call to
      republish CSS Images

Can we start ignoring CSSRule.type?
-----------------------------------

  - RESOLVED: Don't invent new .type values for future rules;
              recommend usage of .constructor.name (Issue #4142: Can
              we start ignoring CSSRule.type?)

CSS Overflow
------------

  - RESOLVED: Align scrolling behavior of visibility:hidden with
              visible descendants for overflow:scroll to behave the
              same as overflow:hidden (Issue #4113: Should a
              visibility:hidden overflow:scroll be scrollable?)

===== FULL MINUTES BELOW ======

Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jul/0031.html

Present:
  Rachel Andrew
  Rossen Atanassov
  David Baron
  Amelia Bellamy-Royds
  Christian Biesinger
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Peter Linss
  Myles Maxfield
  Nigel Megitt
  Thierry Michel
  François Remy
  Melanie Richards
  Alan Stearns

Regrets:
  Dave Cramer
  Chris Harrelson
  Florian Rivoal
  Jen Simmons
  Fuqiao Xue

Scribe: dael


Charter Update
==============

  Rossen: Fuqiao sent regrets. He's the contact in charge of the
          process from TPAC. I was hoping for an update.
  <astearns> the draft is here:
https://w3c.github.io/charter-drafts/css-2019.html
  Rossen: He's planning to make timelines in charter itself, though
          admitting most likely will be inaccurate and will need WG
          discussion to correct
  Rossen: There is a thread on the private ML. If you want to
          participate and help please do so
  Rossen: If nothing else we can move on.
  <fantasai> I agree with Florian's comments in
https://github.com/w3c/charter-drafts/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+%22%5Bcsswg%5D%22

  tantek: Is there a reason to keep on private list vs using GH issues?
  astearns: We are using GH issues on the charter and it's appropriate
            to open more
  Rossen: Discussion is on private because it's a fork from my call
          for agenda items
  tantek: Good to know public GH is an option. I would encourage
          people to use that instead of private list unless there's a
          specific reason to use it
  fantasai: I think that's a good point. I don't think it belongs in
            our WG. There is a repo for comments on charters.
  tantek: Public?
  fantasai: Don't know
  AmeliaBR: Yes it's public. florian posted link on IRC
  Rossen: Go ahead and post issues and let's move charter forward

CSS Images
==========

Consider changing initial value of 'image-orientation' to from-image
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3799

  TabAtkins: Some time ago when wrote image-orientation we set initial
             value to none. People requested initial to be from-image
             so it can auto rotate based on what camera captured. Some
             safari versions do and some don't. smfr wants apple stuff
             consistent
  TabAtkins: We did use counter and found numbers reasonable. Lots of
             images have default EXIF value.
  TabAtkins: Less then a millionth have orientation data so will be
             changed. We don't know how many will change for the
             better and which for the worse. From personal experience
             I suspect a lot will be fixed. I see a lot incorrect on
             the web.
  TabAtkins: Given tiny percentage of poss breakage we recommend init
             value is from-image

  <tantek> wow I'm guessing lots of bad invisible EXIF data that's
           been neglected to date is going to start screwing up images
  <tantek> is there a way to query any web image search service for
           the EXIF properties (or even existence thereof) ?
  plinss: A little concerning to me. I wrote code that does EXIF
          determination. How do you make that work in fallback if
          browser won't do that.
  TabAtkins: If you have control over image correct is rotate and fix
             EXIF or remove the EXIF and do the transform on browser
             side. Either works consistently regardless of browser
             initial value

  dbaron: It seems like it would be good if you make change to spec
          you should note it's experimental and might change back if
          there's compat problems.
  TabAtkins: Yep

  smfr: iOS has been this way for many years. I think...there will be
        compat problems but benefits outweigh. Most common images with
        EXIF orientation are those from mobile devices. This benefits
        those images most which is common.
  plinss: Agree it's desired. Just concerned on compat and make sure
          websites can manage if they need to.
  <tantek> +1 to dbaron's suggestion, and what plinss said
  smfr: Can with image-orientation css property
  plinss: Yeah, worst case can change behavior

  dbaron: Is iOS detectable by looking at computed value of image
          orientation?
  smfr: I don't think we support image orientation yet. Just respect
        EXIF. Want to both everywhere at the same time. On iOS I don't
        think it's detectable by web content if image rotated through
        EXIF data

  plinss: I don't remember details. I remember a lot of work to make
          it cross browser. Don't object right now. I'll look at what
          I did and see if it's problematic and if it is I'll bring
          it up.
  Rossen: Sounds like leaning toward accepting proposal with an added
          note current solution is experimental and may change
  <tantek> no objections, but expecting breakage

  RESOLVED: Accept proposal with an added note current solution is
            experimental and may change

Specify fallback behavior when replaced or background image content
    not available
-------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1984
  <fantasai> Changeset
https://github.com/w3c/csswg-drafts/commit/846d21d922fa4a47abea7be3ab57bcf3ebf62395

  TabAtkins: Request for review because change to CR Images 3. Chris
             pointed out invalid counts things not finished loading
             the same as fails. Doing fallback based on invalid images
             would treat them the same and this doesn't seem
             desirable. Shouldn't fallback to a second image if the
             image hasn't finished loading.
  TabAtkins: Separated the concepts and you're allowed to be smarter
             in certain specific ways. Image function will be
             different on how we do fallback
  TabAtkins: Making sure this is okay and wording looks good
  AmeliaBR: Loading image state that includes images that are lazy
            load that hasn't started loading?
  TabAtkins: Yeah
  Rossen: Anything else besides a call to action?
  TabAtkins: We'll need resolution. We can ask next week if want time
             to review. Else can resolve now
  Rossen: Do people feel this is trivial enough to resolve?

  myles: We did a bunch on asynchronous image decoding last year. In
         cases when script involved it changed css and html attributes
         dynamically. As script changes from one image to another the
         interstitial state mattered. This is tricky to get right. I
         should take this to our team and make sure it matches our
         research
  TabAtkins: Okay.
  AmeliaBR: Good point. Might need explicit call out. An image that
            previously loaded an image but is now loading new data
  TabAtkins: You're right. We should call that out. We should call out
             an image being replaced as a sub category of loading
             image.

  smfr: I would like clarification on the loading case; it says may
        trigger fallback rendering in contexts that offer it. Is it a
        may in UA may and what are the contexts?
  TabAtkins: Accidental may. Contexts are none right now. Image
             function will once it's defined.
  fantasai: It isn't. While an image is loading you may trigger
            fallback but you don't have to. You may want a loading
            image icon. Because not broken we wanted to let UA decide
            correct thing, fallback or loading indication. That's why
            next sentence is must
  fantasai: We made a distinction there. One is required, one optional
  TabAtkins: Makes sense
  <tantek> wait am I missing something? I thought some browsers
           rendered the alt text before an image was downloaded
  <tantek> and thought that was specified in the HTML spec
  <fantasai> that's a fallback rendering, technically :)
  <tantek> agreed
  <tantek> however the issue didn't mention alt text so I'm confused
  <fantasai> it says "fallback rendering"
  <fantasai> Because what the fallback is varies, not all images are
             replaced elements
  <fantasai> some of them are in 'content' or 'list-style' or
             'background-image'

  TabAtkins: I think we should take myles's edits and then bring back
             to list. Let myles review and try and resolve next week
  Rossen: Next week we'll review again. Next week is APAC time, a
          reminder.

Ambiguities in handling url()
-----------------------------
  github: https://github.com/w3c/csswg-drafts/issues/383

  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/383#issuecomment-513416574
  TabAtkins: This comment has the questions ^
  TabAtkins: This is handling the cases where like in mask-image a
             url() might be an element in a doc or a doc as an image.
             Defined ambiguous image URL that can be used in this
             situation.
  TabAtkins: Defined from the discussion where conclusion was load
             both ways. Check for an element to be reference and if
             there isn't load it as an image
  TabAtkins: Want to request review of text as written.

  TabAtkins: Specific questions: resolution didn't call out
             fragment-only url()s. Loading those as an image is just
             the same document. I suspect they should always be
             element references.
  TabAtkins: We resolved with should rather then must. I wrote as a
             must because didn't seem to have a good reason to
             diverge. Wanted to confirm if it is a should or a must.
  TabAtkins: Fragment only URL. Does it make sense for it to ever try
             and load as an image? Else will spec they're reference
             only.
  nigel: Strange use case, TTML. Images can be referenced by fragment
         URL. I'm not convinced this is same use case. Words sound
         similar.
  TabAtkins: Same use case. But talking about an SVG pointing to
             itself with a fragment. Not pointing to something else.
  nigel: Is the same where fragment pointing to defines contents of
         image to display
  fremy: But then you're pointing to element in same document with an
         ID. But not loading entire document
  <tantek> right it's an IDREF
  TabAtkins: If pointing to a thing inside it's an element reference.
             Not loading whole file again to render as image.
  AmeliaBR: In that case it is being used as an element reference. The
            only case where you have a hash reference and doing weird
            things with SVG views. I have in SVG an example where I
            call out that if you use a hash only URL in a property
            that only expects full files you will get correct doc as a
            full image file
  TabAtkins: Fine because not ambiguous URL
  AmeliaBR: That's not an ambiguous situation nor a realistic use case
            for ambiguous references
  TabAtkins: That's something that takes an image not an image or
             reference. That's cool and not relevant here

  fantasai: I think nigel's case needs to called out more carefully.
            You are pulling out a reference to an element, but for
            mask image a reference is pointing to an element. nigel
            case you're pulling out the element but then using as an
            image type, not a mask-element type. Treated as an image.
            Element reference we're pulling out of document.
  <tantek> what if the element is a picture element or has multiple
           srcs etc
  TabAtkins: Seems fine. It's reasonable to have element reference for
             an image denoted by elements pointing to. This is
             different then loading whole file as an image
  fantasai: For mask-image an image type you treat as an image and use
            alpha to turn into mask. mask-element is an element.
            referring to an image you can't use as a mask-element
  TabAtkins: Right. mask-element...mask-image defines it must be a
             mask. nigel's use case in TTML would define the reference
             element can be whatever image defining element is. Use
             cases define what's a valid reference element. here's no
             ambiguity there
  AmeliaBR: What talking about now is if element you reference is not
            valid in property making reference what do you do. Always
            relative to context of the reference as to if the element
            is valid
  nigel: If the URL used to point to image but sub-resource in
         document isn't defining an image. In that case what should
         you display. Is that it?
  <tantek> or what if the subresource it points to defines *multiple*
           images?
  TabAtkins: Yes and the text is you just load the whole document as
             an image. Hopefully it's a SVG and it works. If not you
             wrote bad CSS.
  nigel: Will you go around circles forever doing that?
  TabAtkins: Not sure what's circular
  nigel: What I heard was try and load it, try and go there, find it's
         not right, try again
  TabAtkins: Try and load as a document, look and see it's type
             expected, then go back and load the whole thing as an
             image. Different state that does not trigger same
             rendering. And this is why fragment only which refers to
             same document we think should not try and fallback
             because that produces the circularity
  nigel: Okay, I'm with you
  <fantasai> I still think it's wrong. Nigel's case is "in TTML, you
             can refer to an <image> using a fragment URL to an
             element in the TTML document"
  <fantasai> If you wanted to use such an image as a mask-image
  <fantasai> You can't.
  <fantasai> Because we try to load it as a <mask> element, and it
             fails.

  smfr: I don't like the double load. Can we resolve this with a new
        function like URL but lets author state what they'd like.
  fantasai: Have image() for that but no one implemented
  TabAtkins: We did have that, but this is the resolution we came up
             with instead. Works fine with FF. Don't know with the
             rest of stuff.
  Rossen: You're fine with resolution?
  TabAtkins: I am, yeah

  <AmeliaBR> Re TTML maybe wanting to use image references in mask: if
             there is demand for that, we can always add that to
             mask-image as a valid type of element reference.
  <AmeliaBR> The edited text:
https://drafts.csswg.org/css-images-3/#ambiguous-urls
  <nigel> AmeliaBR sorry that's a misunderstanding - TTML does not use
          image references in mask. It doesn't do mask at all.

  Rossen: Any other comments? Or try to resolve
  Rossen: Objections to the proposed resolution?
  Rossen: What's the actual resolution text?
  TabAtkins: Does the text added look fine? Should match previous
             resolution
  Rossen: Do the others hinge on this? If people need to review edits
          might have to move on.
  fantasai: I don't know if the sub issues need extra time. Can
            resolve on those and then edit main text
  Rossen: Let's do sub issues

  TabAtkins: On the assumption that this text is good, do we want to
             treat fragment only URLs as only elements, never images
  Rossen: Objections?

  RESOLVED: Treat fragment only URLs as only elements, never images

  fantasai: Resolved on using should, do we change that to a must? Not
            sure what you would do if disagree with the should
  Rossen: Objections to change from should to must?

  RESOLVED: Change requirements from 'should' to 'must'

  Rossen: Are those the sub issues?
  TabAtkins: That's it
  Rossen: Back to main one. Do people need more time? Fine if you do.
          Otherwise we can resolve
  AmeliaBR: I looked through comments. Once case that doesn't disagree
            but maybe needs callout in spec. When you do have a same
            file hash only URL we're not causing any reload or
            fallback but there is a chance the hash might be invalid
            to start and valid later because DOM is mutated and an ID
            appears
  TabAtkins: That would be general css is stateless and things reflect
             current truth
  AmeliaBR: Okay. Consistent with rest of resolution and no special
            fallbacks in that case
  Rossen: Great.

  Rossen: Do people need more time to review? Otherwise I'll call to
          resolve.
  Rossen: Objection to adding the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls ?

  RESOLVED: Add the edits in
https://drafts.csswg.org/css-images-3/#ambiguous-urls

Image publication
-----------------

  fantasai: Happy to do it as soon as make edits. We're waiting on
            myles for the one issue
  Rossen: We did push on to next week. We can ideally have edits for
          next week and resolve to republish.

Can we start ignoring CSSRule.type?
===================================
  github: https://github.com/w3c/csswg-drafts/issues/4142

  TabAtkins: Was defining @property rule. I remembered we have to
             register .type on the wiki page. It's a terrible pattern
             from the 90s. We just do strings now. Does anyone find it
             valuable to make the change? We deprecate .type and all
             new CSS rules us a placeholder value. Add a new property
             that exposes name of rule as a string
  <fremy> +1
  <dbaron> sounds like a good plan
  <fantasai> maybe .typeName?
  TabAtkins: That's how other things work. SVG now works like this.
             It's easier to work with.
  TabAtkins: Objections? Anyone feel it's worthwhile to do or not and
             we live with current system?

  emilio: Usually when I do CSSOM stuff I do instance of rather then
          checking .type. Is new property really necessary?
  <AmeliaBR> .constructor.name works
  fremy: If you go across iFrames it doesn't work. Have to get
         constructor constrained to a string
  TabAtkins: True
  TabAtkins: Mostly this is just terrible smell and have to keep doing
             it for new rule types. Would like to stop. If we're okay
             with instance of and iFrames are awkward. I'm okay with
             just saying we stop using .type and future rules get a
             placeholder
  <astearns> +1 to stop using .type
  emilio: No strong opinion. I'm happy with string API. fremy point is
          nice

  fantasai: No objections to adding, but do we want everything else to
            have same type or maintain pattern going forward and
            encourage string
  TabAtkins: Biggest encouragement is make int not work
  AmeliaBR: Do we have use counter on how often .type are being
            accessed?
  TabAtkins: No. Pretty certain it's non-0. Removing .type isn't
             needed, just leave as is as a fossil
  AmeliaBR: I support doing what we did with SVG where new things get
            unknown enum and you have to figure it out with some other
            way. Knowing how much current enums are used we'd know how
            many people would lose going forward.
  TabAtkins: They can switch for new values
  myles: Can't you use object.constructor.name and get a string?
  fremy: True. But then you need class for each thing you create
  TabAtkins: We don't right now. Weird thing HTML does. We use a fresh
             class for new rules
  fremy: Reasonable to me. That works for everybody. Create unknown
         and stop increment the counter
  myles: Right now all css rules have own subclasses. Would work.
  TabAtkins: Okay with that. Works across iFrames. Would let us drop
             to tombstone .type and not use in the future

  TabAtkins: Let's ask for resolution on that
  Rossen: Objections?
  * fantasai is a little uneasy with making .type return the same
             value for all future rules, but not gonna object
  RESOLVED: Do not use .type in the future specifications
  myles: Should resolution say use?
  TabAtkins: I'll clarify in the issue
  fantasai: Let's retype the resolution TabAtkins

  RESOLVED: Don't invent new .type values for future rules; recommend
            usage of .constructor.name

  AmeliaBR: Do we want to get more specific and say that any rule type
            that doesn't yet have a declared type value should return
            0 which is the unknown rule from DOM2?
  AmeliaBR: And with that are there any specs that declare a value and
            haven't been impl? Should they be included?
  TabAtkins: The only recent one is feature values. I'm fine with it
             staying how it is. I don't think any new @rules other
             then @property
  fantasai: Might be in future
  TabAtkins: Yeah, but this ask was about new @rules in specs that
             could be changes to match resolution
  TabAtkins: We'll find them

CSSOM View
==========

{element,elements,nodes}FromPoint but without restricting to the
    viewport clip?
----------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4122

  TabAtkins: Still active discussion on list. Prefer to defer
  emilio: sgtm

CSS Overflow
============

Should a visibility:hidden overflow:scroll be scrollable?
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/4113

  smfr: You have overflow:scroll with visibility:hidden but a visible
        descendant. Should you be able to scroll if you interact? If
        programmatic movement should it move things around?
  Rossen: Current behavior?
  smfr: Cannot interactively scroll, but can through programmatic and
        things happening on descendants. I think that's reasonable
  <Rossen> https://codepen.io/anon/pen/NZZvgY
  Rossen: Is ^ the example?
  smfr: Yes, I think so
  emilio: FF behavior is same but we allow scrolling interactively the
          first time which is weird. Would think of it as a bug.
  <smfr> https://codepen.io/smfr/pen/orRLqN
  smfr: Simpler example ^
  [everyone looks at the examples in silence]

  Rossen: Your definition, if I'm getting it correctly, for purposes
          of computing scroll bounds for scroller with
          visibility:hidden descendants are not counted as part of
          scroll bounds for this scroller?
  smfr: Not about scroll bounds. element.scrollHeight is same wither
        or not overflow:Scroll is hidden. It's about if UA allows
        interaction
  TabAtkins: final codepen has a scrollbar, but you can't scroll it
             directly
  TabAtkins: If you were to make it scroll bounds it means can't be
             scrolled by anything. Programmatic and bubbling still
             works
  smfr: Behaves similar to if it's overflow:hidden. Maybe can write in
        same way as overflow:hidden which allows programmatic scrolling
  Rossen: Reasonable. Aligning with overflow:hidden would be similar
          behavior to something people know how to use. People know
          you can select and drag to scroll overflow:hidden scrollers.

  Rossen: Other opinions?
  Rossen: Proposal: Align behavior of visibility:hidden with visible
          descendants for overflow:scroll to behave the same as
          overflow:hidden
  smfr: Also question on if pointer-events:none.
  Rossen: Separate issue?
  smfr: No. Don't know if need separate or lump in.
  <dbaron> seems like pointer-events:none shouldn't effect
           keyboard-based scrolling?
  Rossen: Since we're a minute past let's resolve on this. If want to
          try and lump in lets do that later.
  Rossen: Obj to Align behavior of visibility:hidden with visible
          descendants for overflow:scroll to behave the same as
          overflow:hidden

  RESOLVED: Align scrolling behavior of visibility:hidden with visible
            descendants for overflow:scroll to behave the same as
            overflow:hidden

  <dbaron> I assume this means for scrolling behavior and not for
           layout (e.g., size of scrollbars)
  Rossen: We're are hour. If you want to discuss pointer-events let's
          do that next week or in github
  <dbaron> (was trying to say that but it seemed like my audio didn't
           get through)
  <Rossen> ack dbaron - yes, I was specific in my initial definition
           of the resolution that this behavior is in reference of
           scrolling only, thus, I wouldn't expect any changes to
           layout, invalidation and/or paint apply

  Rossen: Please add yourself for TPAC wiki. We'll chat next week at
          APAC time. Have a great rest of the week.
  <tantek> add yourselves: https://wiki.csswg.org/planning/tpac-2019
Received on Wednesday, 31 July 2019 23:45:54 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 31 July 2019 23:45:55 UTC