W3C home > Mailing lists > Public > www-style@w3.org > September 2018

[CSSWG] Minutes Telecon 2018-09-12 [css21] [css-contain] [filter-effects] [cssom] [css-ui-4]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 12 Sep 2018 20:34:54 -0400
Message-ID: <CADhPm3vXcY=rc36dPsKyr+e-37KWzNQ+DGRyUsT110Ln6EYWTQ@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.


  - Group members are asked to begin to populate the topics list for
      the F2F.

Review HTML fieldset/legend spec

  - There were concerns that some portions of the spec were extending
      functionality instead of just defining what is needed for
      compat. This is an ideal topic to address during TPAC where
      conversation can happen with members of the WHATWG. Until then
      conversation will continue on github. (Issue #3094)


  - A separate issue will be created for CSS2.1 to create a term that
      means "things that create a stacking context" and use that in
      the spec where appropriate. Once this is done other specs can
      use this term too. (Issue #2717)

CSS Contain/SVG

  - RESOLVED: Containment should apply to outer SVG but nothing else
              in SVG. (Issue #2987)

Filter Effects

  - Chris Harrelson is added as a co-editor.
  - There needs to be details on blending added to the document about
      the visual effect of filter() on the document element. (Issue
  - The behavior on the root element needs to be considered in
      reference to the current behavior for iframes. (Issue #282)


  - RESOLVED: Disconnected elements don't have stylesheets (Issue
      - There is a use case to be able to set values on a disconnected
          element through different APIs; plinss will investigate
          current work on this use case and, if necessary, file an


  - RESOLVED: Add sentence "Authors should use pointer on links and
              may use on other interactive elements" To UI4. (Issue


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Sep/0010.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Benajmin De Cock
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Dael Jackson
  Brad Kemper
  Chris Lilley
  Peter Linss
  Thierry Michel
  Manuel Rego Casasnovas
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Lea Verou
  Sean Voisen
  Zheng Xu
  Fuqiao Xue

  Tony Graham
  Michael Miller

Scribe: dael

  astearns: Let's start and let people straggle in
  astearns: Any extra agenda items? I saw the break issue from
            fantasai. Anything else?

New co-editor for Filter Effects

  astearns: We had a volunteer. I've talked to current editors.
            They're fine. Chris H. is now a co-editor.
  astearns: He's been active so hopefully will get things done.

FTF topics needed

  <astearns> https://wiki.csswg.org/planning/tpac-2018
  astearns: We need agenda items. It is TPAC so there is less time.
            Right now agenda in repo and in wiki is light. Please add

  fremy: I would love to discuss, you know the color filter proposal
         from Apple, I haven't seen anything but I'd like to discuss.
         I will add to wiki.

Review HTML fieldset/legend spec
  github: https://github.com/w3c/csswg-drafts/issues/3094

  astearns: Looks like fantasai, Mats, and florian have commented in
  astearns: If you were not aware, please take a look at the issue
  astearns: If you have anything to contribute please do.

  fremy: I didn't write anything on the issue and I haven't seen
         fantasai comments. It's an amazing document. One concern is
         in Edge webkit-appearance is cosmetic. We only support none.
         I'm concerned to see it overriding display and other
         essential properties to CSS.
  fremy: If this is how it works in blink maybe, but I get this
         impression this is not a thing it does. If this is not how it
         works in blink I would not make it this way. I have not had a
         chance to verify
  florian: You can I need to be involved in parallel conversation.
           There's a WHATWG standardization of the webkit property
           where they're specing half of it. They're not super happy
           with out proposal so we should talk

  chrishtr: The blink engineers are opposed to adding more
            functionality to prefix properties.
  florian: Good to know, I agree
  tantek: I also agree
  <Rossen> +1
  tantek: I don't think should be adding anything to appearance.
          Adding functionality feels like pointing someone to a giant
  florian: Total agreement, but there are 2 groups of people not
           talking. Our side saying this and another group saying we
           should standardize on webkit-appearance

  Rossen: Upcoming F2F event coming up...good thing to talk about
          there. I propose we keep looking and see if we can reach
          agreement at TPAC
  tantek: Sounds good to me
  astearns: Add to wiki agenda?
  Rossen: Definitely. We'll see if we can pull people from WHATWG

  astearns: Other thing I noticed is there is a lot being discussed.
            Threading is hard to follow. If anything can split to its
            own issue please do
  florian: It's tricky. It's a giant spec. Having 25 issues separate
           is different then one list where everything is bad and
           maybe we should reconsider.
  astearns: Just pointing out as we find separate issues to solve we
            should split

  dbaron: Another point here: interop is bad and this spec is doing a
          lot to improve it. Shouldn't ask for it to be thrown out. We
          should question what is not needed for interop, but a bunch
          of this is needed given web compat
  florian: Taking as dependencies as things not defined and assuming
           they work as they do in chrome. But they're not defined to
           work that way. Until solve dependencies not clear the spec
  <tantek> agreed with specing backcompat interop
  <tantek> but disagreed with extending appearance OR
  <tantek> also disagreed with methodology of "just spec what Chrome

  fremy: Let's put this on TPAC agenda where we can work together and
         talk once everyone has read the spec.
  fantasai: I think 2 things to add. This is fieldset stuff but also
            appearance property.
  Rossen: For appearance property good to summarize the principles as
          to what we'll take. Also making clear position on prefix
          properties. Then go from there
  <tantek> can we counterpropose deprecating FIELDSET and LEGEND?
  <fantasai> tantek, no
  <tantek> they are too much trouble for authors to bother trying to
           use in any compat / interop way
  <fantasai> tantek, they're perfectly fine HTML elements, we just
             need to be able to a) make them not magic b) ideally
             define the magic so it can be controlled and/or reused
  <tantek> lol "perfectly fine HTML elements". ok agree to disagree

  florian: And also people sync internally. Mozilla here and Mozilla
           in compat spec seem to be different to take one example.
           Talking internally would be nice
  florian: Maybe TPAC is the place for that

  astearns: Good for now? This will all go in the issue. Please
            continue there before TPAC.


Anything that creates a stacking context should sort in the positioned
    descendants z-ordering list
  github: https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-416803673

  florian: I ran into this again while writing tests for Contain.
           Summary: place in the spec that defines how things stack is
           in css2.1 That bit of prose assumes only things that can
           create stacking context are positioned elements so it's not
           careful in phrasing. We've introduced other things so we
           need to clarify if they stack same or not.
  astearns: Stacking or painting?
  florian: I'm not the expert on stacking and painting. I just want
           this closed.

  dbaron: I think most of answer in the issue. Someone needs to
          propose edits to css2 with a new term, only one thing in
          css2 uses the term, all other specs use that term.
  chris: Not just css2. Also compositing defines more. I agree we
         need clarity and changes, but all in css2 is not optimum.
  dbaron: Things that should be in compositing, I agree. Term in css2
          is 'thing that creates stacking context'. When css2 refers
          to that term it says 'positioned elements' and it needs a
          term so other specs can say this thing creates stacking
          context so all things css2 says about stacking context
  chris: agree on that

  florian: Given css2 has editors can we assign somebody?
  tantek: File an issue and take it from there

  fantasai: gsnedders is still looking for funding to work on css2 so
            if you want him to be an effective editor give him some

  astearns: I like idea of separate issue for css2 work on this
  florian: Is it separate or just the same?
  tantek: Yes, new issue
  dbaron: There are edits for other specs. Separate issue makes sense
  tantek: Fixing css2 is not signing up for all other specs
  dbaron: And fixing css2 is complicated because you have to find all
          the places to change for the new term
  astearns: tantek can you create issue?
  tantek: Not familiar. I'd ask current issue creator
  dbaron: I'll file an issue

  astearns: Anything more?

CSS Contain/SVG

containment probably shouldn't apply to most SVG elements
  github: https://github.com/w3c/csswg-drafts/issues/2987

  florian: Looking to raise attention and get a consensual answer.
           Last issue on containment.
  florian: Seemed dbaron and AmeliaBR were getting somewhere
  chrishtr: Agree with dbaron on outer svg and nothing else
  florian: Can we say that or need to be more specific?
  dbaron: I think applying to outer SVG is pretty straight forward
  astearns: Don't have AmeliaBR on the call. Shall we resolve on outer
            SVG and ask Amelia?
  chris: I think there's agreement on outer SVG. And it's what's
         outside foreign object. TabAtkins is correct foreign object
         establishes containing block but that's all it does.
  Rossen: Equivalent of iframe basically

  astearns: Proposal: containment should apply to outer SVG but
            nothing else in SVG
  astearns: Objections?
  <chris> +1 to proposed resolution

  RESOLVED: Containment should apply to outer SVG but nothing else in

  astearns: I'll tag AmeliaBR for review

  florian: I expect next call to have spec ready for CR. Thanks to
           Gerard for the test suite

Filter Effects

What is the visual effect of filter() on the document element?
  github: https://github.com/w3c/fxtf-drafts/issues/282#issuecomment-418954332

  <astearns> https://docs.google.com/document/d/1iN0LiaKPF3NZ2PCXD9gdWz1WmruhQIER8fJ_EYMm5YE/edit#
  chrishtr: In previous WG meeting we discussed a couple of issues.
            One was filter is a containing block for all elements
            unless filter is on root. Reason for that is that it's
            important for impl reason and rationality of platform for
            it to be containing block. For root we want fixed to
            behave correct
  chrishtr: Second issue from smfr is that it's unclear what happens
            when you put a filter and what happens to default white
  chrishtr: Discussed and had somewhat resolution similar to my
            proposal, but needed use cases

  chrishtr: There's 3 drawing layers for every doc. UA background
            layer, canvas layer, root element layer. Blended for final
  chrishtr: Want to make sure final is opaque. That's function of UA
  Rossen: Always meaning per discretion of UA right?
  chrishtr: Yes but don't think it's good idea
  Rossen: If a UA wants blending enabled for, say, webview with
          different composition other then opaque they should be
          allowed. Saying background is always opaque is too strong
  chrishtr: Would you agree it's important for dev not to be able to
            cause blending there?
  Rossen: Agree. Trying to distinguish that UA layer is controlled by
          UA only. Opaque or not is per discretion of UA. Rest is

  chrishtr: Canvas layer is second. Purpose is a blending backdrop for
            root element. Root element never has a background, always
            stolen by canvas layer. That's as is. Other cases in HTML
            where body gets its background stolen, but that's not
            valid here
  chrishtr: I want mixed blend mode and filter to apply to canvas
            layer as it mixed blend and filter of root element and
            canvas. Default color of canvas is white. If you don't
            spec a color on html element canvas will be white
  Rossen: Purpose of root element layer?
  chrishtr: Content that's not the background but drawn into stacking
            context. If you have a non-stacking div that's filtered in
  Rossen: Makes sense

  smfr: There was a step to propagate the UA background layer color to
        the canvas. If you make canvas white you prevent UA from
  chrishtr: Default color of the canvas is white. Step 1 in the
            algorithm is paint white into UA. Step 2 is put background
            of root into canvas and if no background put white.
            Guarantee of opaque comes from UA layer, not canvas. UA
            layer forces the opaque, not canvas.

  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%20background%3A%20aqua%20%7D%0A%3C%2Fstyle%3E%0A%3Ciframe%20srcdoc%3D%22%3Cdiv%20style%3Dbackground%3Ablue%3Bheight%3A30px%3E%3C%2Fdiv%3E%22%3E
  dbaron: Question on your assumption. I put a test case in^
  dbaron: Only tested FF, but iframe is transparent. Canvas does not
          always have white background
  chrishtr: I think the demo is in case of iframe...yeah...white
            background is root frame but not sub frames. Right. And
            iframes can be transparent. Right.
  astearns: Should that be added to algorithm?
  chrishtr: Yeah. White color is specific to root document. For
            subframes it's transparent
  chrishtr: Transparent iframe is legitimate
  Rossen: There is no ua background layer in this case
  chrishtr: There is eventually if you go up stacking
  Rossen: Yes, for the frame itself
  chrishtr: Right. And as dbaron said it doesn't draw white by
            default. There is no infinite canvas for an iframe. That
            needs to be thought through

  chrishtr: Another comment on github from earlier today that asked
            about clipping and masking order relative to filter and
            blend. Compositing says filter first and then...there's an
  <chris> yes, filter should be applied first.
  <chris> so there are two separate clip stages?
  chrishtr: Clipping is clip-path. I think it's important to be after
            scrolling and overflow clip. Not masking or clip-path. Not
            sure you can mask or clip-path root. Does anyone know?
  chrishtr: It would apply to iframes but not root document
  Rossen: Question was?
  chrishtr: Masking for css clip to the root
  chrishtr: Any way to cause clip on root element
  chrishtr: Not sure it makes any sense for root of webpage or if UA
            impl. Makes sense for an iframe
  Rossen: Not sure
  Rossen: Assume the use case for iframe I would question why that use
          case doesn't apply to top level root
  chrishtr: Reason would be iframes are in a larger drawing surface.
  Rossen: Yes, unless root is inside an iframe. If use case applies to
          doc in iframe, why when it's not.
  fremy: Also if you're drawing on a glass screen I can imagine
         websites wanting to be transparent and only white background
         when they want it. I don't think there's a reason to think
         iframe use case doesn't apply on root
  chrishtr: Okay. I see.

  Rossen: Where do we go? Your summary in the explainer is decent.
          What's next?
  chrishtr: Need to go into more detail about iframes and clipping/
            masking. Then I think it'll be ready to come back
  Rossen: This is great chrishtr. Thank you for putting this together.


Need to agree on when LinkStyle.sheet gets updated in shadow trees
  github: https://github.com/w3c/csswg-drafts/issues/3096

  emilio: cssom spec- the first spec when an element has a stylesheet
          to html. Html doesn't specify so implementations did
          different things. Gecko loads stylesheets in shadow trees.
          Blink and webkit don't. I'm fine spec webkit and tying
          loading a sheet to connected to a document. Makes shadowroot
          stylesheets useless unless root is connected
  emilio: Overall that makes sense. Example a style element.sheet is
          also useless when style is not in doc.
  astearns: Any concerns?
  astearns: Makes sense to me.
  emilio: Fine for me if we get a resolution I'll make edits

  astearns: Proposal: Specify webkit/blink behavior for disconnected
  emilio: Disconnected elements don't have stylesheets
  astearns: This goes into html?
  emilio: May need to. I'll discuss with html editors who should spec.
          It's right now nowhere
  astearns: Proposal: Disconnected elements don't have stylesheets
  astearns: Objections?

  Rossen: Disconnected elements have no stylesheets. If I make an
          element through OM and make a style element the contents are
  emilio: Not dropped, but they're not associated.
  <chris> what about style elements in the disconnected element? or
          style attributes?
  Rossen: Once I merge into main tree style sheet becomes
  emilio: Yes, it's non-null
  Rossen: There's a temporary style sheet not accessible through OM,
          but it's created and retained for lifetime of subtree
  Rossen: My assertion is there is an actual style sheet not
          accessible through OM until element is merged into main tree
  emilio: In gecko we have no style sheet. We parse when becomes
  Rossen: So you're saying if the stylesheet has external reference
          you won't download until merged into tree
  emilio: Right. That's the only thing HTML specs.
  Rossen: Then I'm fine with the proposal. That answers my question

  plinss: If you're creating a custom element you cannot manipulate
          stylesheet through cssom until connected to document.
  Rossen: That's current
  emilio: You don't want to trigger loads. Rune said he's in
          agreement. You can create stylesheet via inner html but
          can't access via OM
  Rossen: This is also related to our previous discussions about css
          on disconnected trees. We'd give them stock style answers
          was our conclusion so you don't trigger style computation.
          That's why asked if we'd specify so downloads don't occur
          until merge with main
  plinss: If I create web component it cannot be made ready until
          plugged into doc
  Rossen: Correct
  plinss: So I plug it in wait for style to download and parse, get a
          flash of unstyled and then can manipulate.
  Rossen: Not defending, but it is the current
  plinss: Do we want this?
  emilio: For small components you use inline styles and defer parsing
          until you insert it.
  Rossen: plinss perhaps is alluding to a separate issue that perhaps
          we need a trigger that forces download when not connected.
  plinss: At least parse and manipulate
  Rossen: Yeah, this is a fair point.
  <AmeliaBR> Remember, there is always <link rel="preload"
             as="stylesheet" />, which you can add to the main
             document to trigger a download without applying styles
             just yet.
  emilio: I think there are proposals in Google for document.tree to
          allow. Wouldn't work like current style sheets. It's a
          different API. But I think would address that use case
  plinss: This is something I ran into in the last week or two. I want
          to set values of custom property and I can't do it through
          clean APIs. We should allow authors to manipulate style
          sheets before connection
  emilio: I think Google proposal addresses that. I don't think we
          want current style and link to trigger downloads
  plinss: Understood. Not proposing we change legacy. There is a use
          case here.
  emilio: File as a separate issue?
  plinss: Fair enough.
  astearns: plinss do you want to investigate current proposals and
            file an issue if they're not enough?
  plinss: Yes
  <emilio> plinss: https://github.com/w3c/webcomponents/issues/468 is
           what comes to mind

  astearns: Proposal: Disconnected elements don't have stylesheets
  astearns: Objections?

  RESOLVED: Disconnected elements don't have stylesheets


Pointer Cursor wrangling
  github: https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-419616109

  florian: I think we have strong consensus that we do NOT want to
           change UA requirements as to what they should do with
           pointer cursor. But there is a fairly large contingent of
           authors that think this is an author requirement and if you
           do pointer on anything other then link it's invalid.
  florian: Large part of web does things like pointer on button
  florian: Is there room for a note or some wording to say UA do links
           and links only, but authors can put it in other places
  astearns: Last comment in issue TabAtkins suggested the sentence
            "this value SHOULD be used on links, and CAN be used on
            other interactive elements to indicate 'clickability'"
  astearns: Is that sufficient? Acceptable?
  florian: Replace can with may but yes

  fremy: Not thrilled but don't want this thread open for 250000 years
         and this coming back up all the time. Still wrong because
         people have been misusing something and people pointed out
         we're misusing it and now we have to change requirements
         because we pointed that out
  fremy: It doesn't make sense. Either we say it should be used and
         change UA style sheet. Why say can if we don't do it? I have
         mixed feelings. I won't object to a may. It's wrong, but I
         won't object.
  TabAtkins: That browsers can't change their behavior doesn't have
             baring on how a lot of heavy usage leads to the value's
             usage. Legacy constraint on browsers shouldn't constrain
             us here. This is about matching author expectations.
             People expect this to work in a particular way.

  astearns: Objections to adding the proposed sentence "this value
            SHOULD be used on links, and MAY be used on other
            interactive elements to indicate 'clickability'" to UI 4
  astearns: The pointer value SHOULD be used on links, and MAY be used
            on other interactive elements to indicate 'clickability'
  <tantek> +0 sounds ok, still reading issue
  florian: Should this be "authors should use" instead of "should be
  TabAtkins: It's on UAs.
  florian: Do we want to say UA may apply to others?
  TabAtkins: That's why I started with a can
  florian: Is sentence meant for author and UA or just author?
  TabAtkins: Both author and UA. I don't think it's bad if a browser
             changes to pointer on clickable things
  AmeliaBR: We already agreed to UA must apply pointer on hyperlinks
  AmeliaBR: More passive voice this cursor should be used could be
            included without canceling the must.
  florian: I don't object to current. If it's meant as vague I'm okay
           with vague.
  dbaron: Good to be clear who requirement is on
  astearns: Not vague, it applies everywhere
  <tantek> ok with CAN or MAY
  <tantek> though slight preference for MAY
  <tantek> also going to note for the record that no one followed up
           with tests as I requested last year in the issue :P (unless
           I missed something? searched whole issue for "test")
  <tantek> https://github.com/w3c/csswg-drafts/issues/1936#issuecomment-346420266

  AmeliaBR: Have an explicit requirement on UAs. Another sentence
            could be authors should us it on any other element that
            behaves as a link and may use it to indicate clickability
  florian: There's no UAs must not
  AmeliaBR: Exactly. No negative about UAs applying to other elements
  florian: Like that better.
  astearns: Does reduce confusion.
  astearns: Objections to scoping this sentence to just authors?
  astearns: Proposal: Authors should use pointer on links and may use
            on other interactive elements
  astearns: Objections?
  <tantek> no objection

  RESOLVED: Add sentence "Authors should use pointer on links and may
            use on other interactive elements" To UI4.

  astearns: Thanks everyone
Received on Thursday, 13 September 2018 00:36:24 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 September 2018 00:36:25 UTC