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

[CSSWG] Minutes Telecon 2018-08-15 [css-overflow-3] [css-display] [css-grid-2] [css-cascade-3] [css-color] [css-ruby] [css-text-decor-4] [css-align] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Aug 2018 17:46:01 -0400
Message-ID: <CADhPm3vUJqrDLZ3LgDp09_EaXG8BvZt7r=B2QZbKO+uEC9JzTw@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 Overflow 3
--------------

  - Though the group resolved on issue #2988 ('overflow' 2-value
      syntax is in wrong order) last week, the resolution is raising
      concerns and questions on github. Anyone interested should
      comment there.

CSS Grid 2
----------

  - Interested members were requested to review the proposed changes
      to resolving line names in subgrids.
      Github: https://github.com/w3c/csswg-drafts/issues/2564

CSS Cascade
-----------

  - The security and privacy index edits (Issue #620) are completed so
      CSS Cascade will be published based on the resolution made
      during the Sydney F2F:
https://lists.w3.org/Archives/Public/www-style/2018Jul/0018.html

CSS Color
---------

  - RESOLVED: Cross-fade blends images in premultiplied space
              (Issue #2722)

CSS Ruby & CSS Text Decor
-------------------------

  - Instead of adding new properties to Ruby and Text Decor to handle
      TTML's use case in issue #2998
(https://github.com/w3c/csswg-drafts/issues/2998 )
      the group thought it might be possible to handle using a special
      case for ::first-line. This proposal will be added to the github
      issue to see if this covers the entirety of the use case or if
      there's more nuance that would still require additional
      properties.

CSS Display
-----------

  - RESOLVED: Close this issue (#2947: Reconsider if 'inline-block' and
              'inline flow-root' should be syntactically equivalent)
              no change.
  - RESOLVED: Request CR transition for CSS Display

CSS Align
---------

  - Issue #3006 (Mixing baseline self-alignment with random content
      alignments) needs a better example before it can be discussed.
      Anyone with examples is invited to add them to the github issue.
  - TabAtkins completed the proposal for issue #1425: Fully specify
      the "Overflow and Scroll Positions" section
      (https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-411930443 )
      and those interested will review so a resolution can be reached.

Selectors
---------

  - The proposal in issue #3012 is to change :visited to remove all
      special casing and limit the use cases such that it stops being
      able to leak private information. This proposal would remove
      some current use cases for :visited so several working group
      members needed to discuss with their teams. Additionally, there
      were concerns about it violating the GDPR regulations so before
      resolving members will also consult with their legal teams.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0015.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Garrett Berg
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Theresa O'Connor
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Sean Voisen
  Greg Whitworth
  Jeff Xu
  Fuqiao Xue

Regrets:
  Chris Lilley
  Thierry Michel
  Lea Verou

Scribe: dael

CSS Overflow 3
==============

'overflow' 2-value syntax is in wrong order
-------------------------------------------

  astearns: Does anyone have any extra items to add to the agenda?

  florian: Not fully adding, but we discussed last week and there was
           confusion on a resolution. I'd invite people to look at
           #2988.
  <florian> https://github.com/w3c/csswg-drafts/issues/2988
  fantasai: It's block then inline.
  florian: Yes, but that's not was implemented
  emilio: We're changing the shorthands the property expands to?
  emilio: Like, the longhands. It's way more risky then a tweak to
          shorthand. If you access via CSSOM it may break.
  florian: Not sure, but not sure we should hijack agenda.

  fantasai: I see the problem. For a one value value of overflow
            shorthand it has to be assigned to physical longhand. For
            two value it has to be assigned to logical. That would not
            break anything other then the last 4 months of work.
  emilio: Right, but that is not how any other shorthand works
  fantasai: We're intending the syntax change to happen, but haven't
            decided on it. For margin/border/padding there is intent
            to have a switch for if assigning to physical or logical.
            background-position is aligned to do this.
  fantasai: There are 2 types of values for background position. One
            set will assign to physical and the other to logical
  <fantasai> https://drafts.csswg.org/css-backgrounds-4/#the-background-position

  florian: Why does it make a difference to physical or logical in
           case where assigning to long hand?
  emilio: Because you can read longhand in CSSOM
  emilio: If you read element/style you don't resolve the properties
          there
  TabAtkins: You don't resolve any...oh, you do shorthands. never mind
  florian: I suggest we hash that out on github.
  astearns: I'm not sure there's anything we can resolve on. florian
            can you take this bit of IRC and put it in github?
  florian: Yes. I will do that.

  astearns: fantasai and TabAtkins do we do #1 or wait for Oriol?
  TabAtkins: Wait.

CSS Grid 2
==========

Resolving line names in subgrids
--------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2564

  fantasai: Just a request for...
  TabAtkins: For review from WG
  fantasai: The way we resolved these questions there was
            clarifications. Line names are passed down and the rest of
            the behavior falls out from that. We could add additional
            logic to change behavior a little but we felt this was
            straightforward.
  fantasai: Asking for a look, don't need to discuss unless anyone has
            a comment or question.
  astearns: Are the possible additions documented?
  fantasai: I think in the comments
  astearns: Sounds good.
  astearns: Take this as a call to look at these changes.
  rachelandrew: Read through it and it seemed to make sense to me and
                be explainable.
  astearns: Thanks
  astearns: Anything else?

CSS Cascade
===========

Add Security & Privacy appendix
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/620

  TabAtkins: Request for review. Finally wrote one. We're happy with
             it.
  astearns: Looks like chris looked and thought it was good.
  Rossen: We haven't been able to review, but will happily do it.

  astearns: Are we at point of publishing?
  TabAtkins: I think we are.
  fantasai: Yeah, were going to but realized we needed one thing. We
            wanted to ask WG to review this one thing before publish.
  astearns: Rossen would you rather we wait on publish for you to
            review?
  fantasai: It's CR for both.
  fantasai: CR update.
  Rossen: I wouldn't block. We should publish. If we need to make
          changes we can republish
  <fantasai> resolution to publish from Sydney F2F:
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0018.html
  astearns: Have previous resolution. Would you want an updated?
  fantasai: No, I think previous is fine.

CSS Color
=========

"transparent" keyword being a special color value, which resolves to
    rgba(0,0,0,0) by default?
--------------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2722

  TabAtkins: dbaron thought their libraries did blending already. I
             checked, same is true for us.
  <TabAtkins> https://drafts.csswg.org/css-images-4/#cross-fade-painting
  TabAtkins: Given that, I edited the spec ^
  TabAtkins: Spec blending of cross-fade is done premultiplied space
             so transparent parts of images work as expected
  TabAtkins: Any further opinions let me know else this is what I'm
             going with.
  <smfr> seems fine
  TabAtkins: And I'm most of the way through cross-fade edits from
             last F2F
  astearns: smfr says seems fine. Other opinions?

  astearns: TabAtkins want a resolution? Or publish and get feedback?
  TabAtkins: Get resolution to end thread. Cross-fade blends images in
             premultiplied space
  astearns: Objections?

  RESOLVED: Cross-fade blends images in premultiplied space

FXTF
====

Filter should be defined to establish a containing block for fixed
    and absolutely positioned elements
------------------------------------------------------------------
  github: https://github.com/w3c/fxtf-drafts/issues/11

  astearns: chrishtr added this to agenda. Is chrishtr on?
  [silence]
  TabAtkins: I'll make sure he's on next week

CSS Ruby & CSS Text Decor
=========================

Add over-most-under-last value to ruby-position &
    text-emphasis-position for captioning
-------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2998

  astearns: fantasai added to agenda, updates by Nigel
  fantasai: The overall question was to add new value to ruby position
            property to handle ttml behavior. First line has ruby on
            top, second on bottom. 3+ lines they're all on bottom.
            Question from WG is do we add it. There's details on how
            to segment text, block, line breaks, etc?
  astearns: Is there a use case for changing behavior based on forced
            line break?
  fantasai: Use case is for captions, don't know what markup looks
            like. Guessing not on forced line breaks.
  dbaron: I can see why it's useful for captions, but feels hard to
          implement for general case. What's previously local now
          needs bigger area.

  florian: Solve by special case first line and having first line be
           over and rest under?
  florian: Since use case is for 2 line what we do for not 2 lines is
           error driven by use case so might as well do simple thing
  florian: Then again why can't use first-line pseudo
  astearns: First-line pseudo is interesting idea. Gets functionality
            for block. Do first lines deal with blocks?
  fantasai: Only with first line of not anonymous block
  astearns: Then first line gives us what ttml looking for
  fantasai: I think so. Don't know nuances of what they're looking for
  astearns: Leave it as a question in the issue? Ask if we can let
            them do this using first line
  fantasai: Alright.

  florian: Need to make it explicit that this applies in first-line
           pseudo.
  fantasai: Have to check pseudo spec. And we can add example in ruby
            module to show this behavior.
  fantasai: I think we need to call it out, not really clear. Have to
            add it explicitly.
  astearns: Possibly ttml people considered this and rejected so good
            to get their feedback on idea
  fantasai: Proposed resolution: add ruby position to properties
            applying to first line, respond to ttml suggesting we use
            first line for this behavior and check if it's a problem
  astearns: It just came up, could get shot down as soon as it's on
            the github issue. Not looking for resolution at this point.
  fantasai: We have a proposed resolution and asking for feedback.
  astearns: We can come back next week.

CSS Display
===========

Reconsider if 'inline-block' and 'inline flow-root' should be
    syntactically equivalent
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/2947

  <dbaron> is Oriol on the call or just on IRC?
  <Oriol> Just IRC
  astearns: Thanks Oriol
  astearns: Hopefully he can follow along in IRC and we can resolve
            this
  fantasai: The question was...this was raised by Oriol. We had
            discussed in the past that we should have inlineblock and
            inline-block have same behavior
  fantasai: I don't remember subtleties. TabAtkins? If you blockify an
            inline-block it turns into display:block it's an inline
            flow-root.
  <AmeliaBR> From issue: However, in #2673 it was resolved that
             blockifications and establishing FC are independent. This
             means that a future feature which only blockifies would
             make inline flow-root and run-in flow-root end up
             generating a block container with no BFC.
  fantasai: If you remove inline and swap with block you get bfc. When
            you blockify inline-block it's not a bfc due to compat.
  fantasai: We made inline flow-root blockify same as inline-block
            because we wanted them to compute to same. But when you
            blockify either you lose block flow-root ness. Oriol
            suggested revert and make them distinct where they're same
            but when blockfiy inline flow-root it's different
  <Oriol> Exactly

  florian: Clarify. When we invoke blockification we'd also invoke
           flow-root so it's not observable except in terms of OM?
  fantasai: If you blockify...
  TabAtkins: Only exception is subgrid so far. That's not relevant
             here. When we blockify something that can be inline we
             flow-root it as well.
  TabAtkins: Not that inline flow-root is implemented yet so that's
             not observable.
  <Oriol> But can become observable in the future, and then it will be
          too late to change CSS Display
  florian: I was initially tempted by Oriol's proposal because cleaner
           theoretical architecture. Seems to me now it's adding more
           complexity then needed.
  florian: To clarify a bit more, request is to have the behavior we
           want on inline flow-root and therefore force undesirable on
           inline-block.  We can't have both due to compat.
           Theoretical nice design is overshadowed by the creation of
           2 distinct behavior despite no use case for the difference.
  <TabAtkins> Florian's statement is a concise statement of my own
              position
  <dbaron> There was another reason this came up, but I've forgotten
           what it was...

  astearns: Other opinions?
  dbaron: This came up in another discussion. Trying to remember what
          that was.
  astearns: subgrid?
  dbaron: Don't think so. I'm  okay with it
  dbaron: Something else where I wanted it the other way.
  <fantasai> dbaron, were you thinking of the earlier discussion
             triggered by
https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-313211986
?
  astearns: fantasai has a possibility
  dbaron: Don't remember if that was it
  astearns: As I understand trade off is keeping simple for now vs not
            being able to use flow-root nature distinct from
            inline-block for some future thing not yet known
  astearns: So may be painting into a corner
  florian: Goal is not to have distinction, goal is to not have
           inline-block constraint. We'd rather have the other
           behavior but we can't have just that so the proposal is to
           have both.

  astearns: Proposed resolution: close no change
  astearns: We've done that before.
  florian: Used to side with Oriol but no longer. Prefer no change.
  astearns: Oriol are you okay with the proposed resolution?
  <fantasai> or have anything to add?
  <Oriol> I guess it's OK for now, but once multivalue display is
          added it will be too late to change in case later in the
          future a feature that blockifies without BC is added
  astearns: Does anyone have reservations based on Oriol's comment?
  florian: Inline-block is odd in that it's a flow-root that doesn't
           show in OM. We can do it later in terms of layout even if
           not in OM. Will not have perfect correspondence. Given that
           is lost and we do want 2 FC we can later since it's not
           observable right now. We could revert it later.
  astearns: Other comments?
  astearns: Objections to close this issue no change?

  RESOLVED: Close this issue no change.

Publication
-----------

  <fantasai> https://drafts.csswg.org/css-display-3/issues-wd-2017
  fantasai: That's last issue in DoC.
  fantasai: Do we want to take to CR?
  <florian> YES! CR CR CR :)
  <fantasai> lol
  astearns: Objections to requesting CR transition for CSS Display?
  <tantek> +1
  <TabAtkins> Nice 👌

  RESOLVED: Request CR transition for CSS Display

  fantasai: I'll work with chris for publish

CSS Align
=========

Mixing baseline self-alignment with random content alignments
-------------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3006

  TabAtkins: I just commented in issue. I think maybe just confused.
             How can you mix baseline self alignment with any other.
             Baseline cares about your height. Seems odd how it
             interacted. Now that I thought about it you have to do
             layout before self align so it's not a problem to do
             content alignment first and if you do center baseline is
             in center of element.
  TabAtkins: So I think this is close invalid.

  florian: Is there no risk of a dependency between sizing and placing
           things? When you align on baseline can that cause things to
           grow? Or does that problem not exist?
  TabAtkins: Good question. I should consider that further.
  florian: If that's okay, we're okay. If not we have a problem
  fantasai: What you say makes sense if item itself has a size. You
            can align and then baseline align. Trickier thing what if
            it's sized as auto and that auto size is not purely shrink
            wrapping around content.
  fantasai: Where that box is positioned can change size of alignment
            container and then change alignment of content.

  TabAtkins: Can we table for a full example? Example in issue isn't
             complex enough to show problem.
  astearns: Okay, we'll come back with a more complex example
  fantasai: And anyone with examples, let us know.

Fully specify the "Overflow and Scroll Positions" section
---------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/1425#issuecomment-411930443

  astearns: Edits have been made.
  fantasai: Wanted to call attention to things trying to fix
  <fantasai> https://drafts.csswg.org/css-align/#overflow-scroll-position
  fantasai: This section is about when you have a scroll container and
            it has align content so you center all the content in the
            box in the box. When you have a scroll container we
            decided that rather than ignore alignment or align content
            to the end and overflow to the top we wanted to make it so
            you could read the content and be able to scroll to it.
            That meant moving content down and show as if end aligned
  TabAtkins: Almost same as aligning scroll thumb in scroll track. Not
             quite same. Some content alignments because way some
             browsers discard padding means it would normally be
             impossible to achieve same layout wither if
             overflow:scroll or not.
  TabAtkins: Have a bit about mandating you provide enough padding to
             match. Also helps solve issue that people want block-end
             and inline padding. We say if you use content alignment
             you get the padding. That makes all padding work as
             expected.
  florian: Does that solve the legacy or do we have too many legacy
           behaviors?
  TabAtkins: Still not sure what legacy should be. Lets us have the
             good behavior so we can solve legacy separately.
  florian: Fair enough.

  astearns: dbaron, you've been in this issue, have you looked at
            latest edits?
  dbaron: I don't think so
  astearns: Leave this as please everyone take a look and we come back
            next week to resolve?
  TabAtkins: Yeah.

Selectors
=========

Solve :visited once and for all
-------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3012

  TabAtkins: Over weekend there was a new attack on :visited using
             houdini api for timing channel attacks. Apparently
             chromium is mitigating by disallowing paint on links.
             This isn't great. dbaron had proposals to reduce
             bandwidth of channels. I think we should solve this.
  TabAtkins: This is leaking history information. I suggest we limit
             what is exposed to the page to things it can have
             observed and then we can make :visited an ordinary pseudo
             class
  TabAtkins: Same origin pages visited are visible. Links that have
             navigated into your origin so that could be exposed.
             Finally any links that are visited from your origin are
             observable through a number of channels. That's the basis
             of the entire ad industry.  That's reasonable to expose
  TabAtkins: I think that gives you all the usefulness of :visited but
             limits privacy to things where we've already lost the
             battle. Only thing we're losing is things like "cool
             links of the week" pages won't be able to tell you've
             visited it before. Most cases are links you've visited in
             the same origin or in search. That's preserved
  TabAtkins: Concerns by Mats that the sort of tracking from the 3rd
             case with outbound links may violate GDPR. I can't
             comment on legal issues. I've reached out to our lawyers.
             In the meantimes, does this seem reasonable? It this
             promising area to push, turning :visited back into a
             normal pseudo class?
  <AmeliaBR> One addition to Tab's comment: All of this
             origin-specific history data would need to be tied into
             the ability of users to clear their cookies etc.
  dbaron: I think Mats wants both sets of restrictions. Adding what
          you propose without removing existing restrictions.
  TabAtkins: That would add a lot of complexity and not give people
             anything useful. Reduces information leakage, but I'd
             like to get all the way over the finish line

  <smfr> I think we’ll need to talk about this internally at Apple
         before we can give an OK to breaking link coloring for “links
         of the week” pages; that seems like a serious usability
         regression

  <fantasai> What are the new restrictions?
  <fantasai> I can't tell from the minutes
  astearns: New restrictions. I think it's that :visited only applies
            to a certain subset of links that follow the restrictions
            TabAtkins said
  TabAtkins: Any same origin is visible. Page navigate into origin or
             pages navigate from origin and out to. That's all
             observable already
  fantasai: So when a browser records if something is in history it
            also needs to see where you clock...you visited w3c and
            you have to record everywhere that I came in from as well.
            All the ways I clicked to it from would all be recorded
            together.
  dbaron: Simpler way to think about it. What you're doing is you're
          keeping separate history for each origin.
  TabAtkins: It's per origin not per page. Yes. Separate history
             database, basically

  astearns: smfr responded on IRC [reads]
  TabAtkins: It would eliminate that use case, yes. That's the major
             casualty.
  astearns: He says they'd have to talk internally before giving an
            opinion.
  TabAtkins: Okay.
  astearns: Other objections or reservations?

  astearns: I'm not convinced, personally, but don't have an objection
            to investigating.
  TabAtkins: Anyone reviewing with teams, when weighing please do so
             against the current status quo where you can basically
             just do link coloring. And there will always be timing
             channel hacks in the current but this would stop that
             entirely. Benefits of killing status quo are reasonable.
             Make sure you weigh that against losing particular use
             cases
  dbaron: I think always going to be timing channel attacks is a bit
          strong. I think there are fixes
  TabAtkins: So we can make repaint always observable?
  dbaron: No, you always repaint no matter if you visited
  TabAtkins: Doesn't stop user interaction based
  dbaron: Other trade off is some browsers double key the cache. They
          may have different trade offs
  astearns: We're at the hour. Sounds like people are interested in
            discussing so let's continue in the issue.

  astearns: We still have a bunch of agenda F2F issue. Some have been
            around for a while. I'm planning on going through that
            list and pinging for update before put on weekly agenda.
  astearns: Thanks everyone for calling in, we'll talk next week.
Received on Wednesday, 15 August 2018 21:46:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 15 August 2018 21:46:59 UTC