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

Minutes Telecon 2016-08-10 [css-pseudo] [css-device-adapt] [css-display] [css-overflow]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 10 Aug 2016 21:35:08 -0400
Message-ID: <CADhPm3s76k6n7Pa5mCP7iwycTLnqDY8_mhgsaEyiCx24wNjrDg@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 Pseudo Elements & CSSOM items

  - RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom)
              from the current level 4 draft and move the work to
  - Rossen was actioned to open an issue on Box 3 for Houdini

Should Device Adaptation include a normative definition of <meta>

  - RESOLVED: Change the <meta> viewport text to normative and add
              two issues. One to test if the description matches
              reality. Second is while we spec with the same
              mechanism there may be differences as we tease out

box-suppress name and shorthanding relationship to 'display'

  - RESOLVED: Make display into a short hand and add an issue on
              naming for the long hands.

Overflow: Consider support for overlay scrollbars

  - Florian brought his proposal to create
      overflow-style: auto|auto-hide|overlay to allow authors more
      control over scrollbars while balancing out the desires of
      implementors to control their scrollbars.
  - There was a feeling that this was still too problematic and
      auto-hide and overlay should be merged into one value that
      behaves depending on the platform behavior.
  - The group was heading in the direction of creating value that
      reserves the same amount of space whether the scrollbar is
      shown or not in order to solve the re-layout problem, but ran
      out of time so conversation will continue on github.

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

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Dave Cramer
  Simon Fraser
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Michael Miller
  Anton Prowse
  Florian Rivoal
  Jen Simmons
  Alan Stearns
  Liam Quin
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Tantek Çelik
  Daniel Glazman
  Chris Lilley

Scribe: dael

CSS Pseudo Elements & CSSOM items

  <astearns> https://drafts.csswg.org/css-pseudo/#cssom
  astearns: Let's get started.
  astearns: Does anyone have anything extra to add to the agenda?

  astearns: This is a hold over from last week as to if we should
            drop the CSSOM part.
  Florian: Should move to next level.
  astearns: There isn't one. My preference would be if we drop we
            start a new level so that it has some place to go. We
            know we need to work on it.

  fantasai: Given that the whole section is a bunch of issues
            including design level issues I would prefer to leave it
            as an open issue on the issues list and link it to
            whatever proposals we have. This is on the TR page. We
            can have it as an open issue on github.
  fantasai: If someone wants to go through it and create a real
            proposal I'm happy to keep it or have it in 5, but if no
            one is going to work on it I'm inclined to that.
  astearns: There's working on the API and working on implementing
            any portion.
  fantasai: If the API is close I'm happy to hang on to it, but
            based on the issues it seems like a random proposal that
            as the spec author I'm not sure is a good idea. It may
            lead people wrong or in a specific direction when we
            don't have one.

  Florian: If this is so vague how is it under TR?
  fantasai: It was somewhere else and when I drafted pseudo elements
            it got scooped in.
  astearns: I think it was always in pseudo elements and we removed
            other even more unlikely things before TR, but this was
  fantasai: If someone wants to work on it or has reviewed it and
            think this is a good general approach I'm fine.
  Florian: If we move entirely off the spec to an issue in github...
           it's not one big issues it's a set of things. If we
           collapse that to one thing it stifles the lower level
  fantasai: I think to address the lower level we need to do the
            higher level of is this even what we want. Picking the
            paint before you decide you want a house instead of a
            school is a bad idea.
  Florian: Or you can flesh it out and see if it makes sense.

  astearns: The issue about not sure on direction I wanted someone
            besides me to look and see if it's the right direction
            and that hasn't happened. Is anyone besides me
            interested in working on this section?
  * TabAtkins has too much stuff on his plate, tho he's interested.

  Florian: Theoretically...I haven't reviewed it...but there's
           another bit of OM stuff which is how pseudo elements and
           the selections OM work together. Does it have anything
           about that?
  fantasai: No. For selections a lot of that is covered in other OM
  Florian: Currently just it's not possible. But that's a problem.
  astearns: The current bits of the OM are about accessing the
            pseudo element. It's a first step.

  Rossen: I joined a bit late, but did you discuss moving it to
          Houdini? This is fairly applicable type of functionality
          we're doing there. Like exposing boxes and stuff not
          backed by DOM elements?
  astearns: Perfect timing. I was going to bring that up.
  Rossen: I'm interested in working on it, but that's my preferred
  fantasai: I'm fine with that.

  Florian: As to interested, to the extent this allows selections on
           pseudos I'm interested.

  astearns: Let's resolve on removing this from the current level 4
            draft and moving the work to Houdini. Objections?

  RESOLVED: Remove this section (https://drafts.csswg.org/css-pseudo/#cssom)
            from the current level 4 draft and move the work to

  <dbaron> Is it going to move to an actual document in houdini?
  <TabAtkins> Well, I think it'll move into a new WICG repo with the
              intention of it "maturing" into Houdini.

  Florian: Does Houdini inherent the context of relationships with
           other groups from CSSWG?
  astearns: My assumption is inherit from CSS relationships.
  Florian: So we can talk to everyone.

  astearns: Which Houdini doc does this move to, as dbaron asked?
  Rossen: I would assume this is the Box 3 spec that doesn't have
          anything actionable. But bringing in something like this
          would make it actionable. So I think Box 3 spec.
  astearns: Could I action you to open an issue on the Box 3 spec?

  ACTION Rossen open an issue on Box 3 spec to include the pseudo

Should Device Adaptation include a normative definition of <meta>

  Florian: Background: There's 2 theories on setting the viewport
           size. The widely deployed <meta> viewport and CSS's
           @viewport. <meta> came first, @viewport was a response.
  Florian: <meta> viewport doesn't have a normative spec. There's an
           informative section in @viewport with a fairly detailed
  Florian: The first point is I think there should be a normative
           description for <meta> viewport. Second item is, is this
           the right place to do it? To say that you have to
           understand the spec. It describes a concrete CSS syntax
           for @viewport and a separate section called constraining
           procedure that says once we have values how does it
           effect the @viewport. And another section for if you have
           <meta> viewport how does it translate.
  Florian: How @viewport was defined it's a bit short of <meta>
  Florian: First I'd like to hear if people want a normative
           description. If yes, should we take the small extension
           to the abstract and include it in the main. Turn the
           informative section into a normative section with a
           disclaimer that if there's discrepancies they should talk
           to us.
  Florian: I have other things, but I'll let others express thoughts

  <fantasai> I'm in favor of having a spec for this thing somewhere,
             and this seems the best place.
  dbaron: I think...I couldn't quit hear... <meta> viewport has
          quirks that may or may not be copied to @viewport. We
          should make explicit decisions on that instead of assuming
          one thing or the other.
  Florian: I think this is a fair point. It's possible the
           description is out of date and there also may be quirks.
           We should put an issue there. Anyone can dive in and try
           to ID which parts are good, which is odd, what's
           universal. There's a fair amount of testing in the wild,
           but not our format. The knowledge should be out there.

  Florian: I'm saying we flip from informative to normative and add
           prominent issues.
  astearns: This seems like the right place to put this info, so I'm
            in favor of Florian's proposal.
  <fremy> Florian: +1

  Florian: Two other things. There have been some discussions as to
           if the @viewport syntax isn't pre-loader friendly. Also
           maybe that it's needlessly expressive. This isn't in
           contradiction of what we've said now...this isn't about
           the mechanism behind it. We may change the @viewport rule
           syntax later. But since syntax and how it works is spec
           separately it shouldn't effect our discussion, but it's
           worth pointing out.

  bradk: Can the <meta> be normative and deprecated? It's there for
         compat but we want @viewport to take over for authors.
  <astearns> probably a bit premature to deprecate anything
  Florian: Maybe. The concerns about <meta> being preloader friendly
           and @viewport isn't so I don't think there's universal
           opinion to phase out <meta> viewport. Eventually, but the
           time isn't right.

  bradk: It's odd we're specing HTML.
  Florian: Yes, but what that thing does is about layout and
  bradk: But we don't spec font tags.
  Florian: No one specs this. There's already a description in the
           spec for parsing.
  TabAtkins: We're specing a <meta> tag that's an extension tag.
             It's reasonable for us to spec a given <meta> tag.
  bradk: You're saying it's not HTML specific.
  TabAtkins: The meaning of the <meta> values is mostly defined by
             other specs that are using it as a generic transfer
  Florian: So we have two ways to deal with the viewport, one of
           which is CSS specific and one is a micro syntax.
  Florian: Meta is all over the place in terms of deployment.
  bradk: I understand the need for compat. I have no objection - it
         just seems weird and backwards looking.

  astearns: Other opinions?
  smfr: I'm okay with making it normative. The spec needs to say
        what happens if meta and @viewport are present.
  Florian: It does.
  smfr: The preload problem is serious so I don't think we at webkit
        would be interested in dropping <meta> until that's resolved.
  Florian: That doesn't surprise me.
  smfr: Definitely there's a lot of compat issues with <meta>
        viewport tag so we have to be careful.
  Florian: There is a detailed and careful language, but I'm sure
           the problem space is thorny enough we're missing things.
           We need to start testing and find where the
           implementations disagree. I think you should have a quick
           look, it's fairly decently detailed. I don't think we can
           get further without poking.
  Florian: We do have pokers, though.
  smfr: The parsing algorithm looks like it was reverse engineered.
        That should be exposed in webkit now.
  Florian: Fair enough. I don't know if everyone parses the same way.
  Florian: By saying it's normative I don't expect the definition to
           be final.

  astearns: Proposal: add normative text describing the <meta> tag
  Florian: Not adding. Change the text from informative to normative.
  astearns: Okay. With two issues. One to test if the description
            matches reality. Second is while we spec with the same
            mechanism there may be differences as we tease out
            compat. Is that correct?
  Florian: Not exactly what I was thinking for the issue, but a good
           alternative. Let's go with that.
  astearns: Objections?

  RESOLVED: Change the <meta> text to normative and add two issues.
            One to test if the description matches reality. Second
            is while we spec with the same mechanism there may be
            differences as we tease out compat.

box-suppress name and shorthanding relationship to 'display'

  <astearns> https://github.com/w3c/csswg-drafts/issues/343#issuecomment-235961589
  fantasai: There has been an open issue on renaming box-suppress
            property. One discussion that came up was that the
            reason for having the display-or-not property be
            independent of display was to put a rule for hidden in
            the UA stylesheet and this would have an effect despite
            authors having display property in their stylesheet.
  fantasai: That's probably not something we can do at this point.
            Hidden is implemented as display: none and authors have
            adapted to override hidden using something like opacity.
            So main reason for separation is no longer valid.
  fantasai: Proposal is to make display-or-not a sub-property of
  fantasai: Other reason for splitting was to make authors not say
            display inside and display outside separately. We can
            solve that by having display-as property. So we'd have
            display with display-type and display-as and display-box
            or whatever we call that.
  fantasai: The advantage is we don't have display:none as its own
            thing that doesn't interact with display or not.
  fantasai: The disadvantage is authors currently using display
            won't be able to auto switch unless their selector for
            that declaration is more specific.
  fantasai: I think this would be an appropriate use of !important
            would be to set something like hidden attribute
            display-or-not: none
  fantasai: So 1) redo short handing relationship. 2 & 3) name

  Florian: One place I'm not clear. Why do we want to merge display
           inside and outside?
  fantasai: Authors want to set them at the same time. Right now
            display sets inside and outside together which is what
            you want. display-or-not is a separate property. If we
            merge it back then any time you say display: table or
            whatever it resets none to its initial value.
  Florian: Got you.
  Florian: Generally makes sense to me. The cascading with
           !important makes me a little skeptical, but it might be
  fantasai: It fits together better. It's mainly historical thing.
            We didn't have that independent not-none switch.
  Florian: Okay. I like it.

  <fremy> @fantasai @astearns: why not extend visibility:collapse,
          in case this is closer from what we want?
  astearns: fantasai, did you see fremy comment?
  fantasai: Partly that's sometimes what you want. This is effecting
            all media. display: none takes the box from the box
            tree. Sometimes we want visibility: flat. There's a
            proposal for hide that keeps the element in the box
            tree, but not effect layout in any way. The main
            advantage is it tells you this will be a dynamic thing.
  fantasai: Another advantage is it keeps track of animation timers.
            So if you hide and show you haven't lost your timer. It
            keeps counters in place as well.
  fantasai: That's just a proposal right now. It would make sense to
            have that in the display property.

  astearns: I think this proposal makes sense. As a way to design
            all these interaction this is the way to go.
  astearns: I'm wary because we're talking about legacy with display
            and display property is used EVERYWHERE.
  fantasai: Existing style sheets won't be effected. If you decide
            to start using display-or-not property you have to know
            that rule is more specific. Which you'd have to do
  Florian: Or you need to stop using the shorthand and use the
  fantasai: Right. The current solution is the make sure your
            noneness is specific or you use the longhands and
            shorthands we're introducing here.
  <fremy> @fantasai People will use libraries which are not
          compatible, and this will make it harder than it should

  Florian: I like it. I don't have a good name.

  <jensimmons> I assume this is all to get us to a place where we
               have a CSS property to let everyone write one line of
               CSS to accomplish what the industry does now with a
               hack — .element-invisible { position: absolute
               !important; height: 1px; width: 1px; overflow:
               hidden; clip: rect(1px 1px 1px 1px); } — yes?
  <fantasai> jensimmons: yes, exactly :)
  <jensimmons> visually hidden
  <jensimmons> element invisible
  <jensimmons> visual display

  fantasai: We don't have a great name. display-box was suggested. I
            think there were some others. Anyone with a suggestion
            please put it in IRC.
  astearns: display as a short hand...display-or-not is available ^-^
  fantasai: This is true. :)
  * jensimmons thinks ‘box’ is odd. Most people don’t think of these
               items as boxes, even if technically they are

  astearns: Objections or concerns about going in this direction?
  Florian: One question. Where does display: content go in terms of
           the long hand?
  fantasai: I believe it's display-outside. It used to be a property
            on display-or-not, but it's more of a display type then
            hiding or showing. It wasn't an intuitive decision, but
            we thought about it for a bit.
  Florian: Makes sense. Then we could actually use display-or-not
           even though it was a joke.
  fantasai: The values on this property have to be about display
            this box or not. Anything more complex has to go
            elsewhere. I think about it as display-or-not for that
  Florian: Do we have other properties that take a boolean?
  fantasai: This isn't necessarily a boolean.

  astearns: Proposal: Make display into a short hand and add an
            issue on naming for the long hands.
  astearns: Objections?
  Florian: Ship it.

  RESOLVED: Make display into a short hand and add an issue on
            naming for the long hands.

Overflow: Consider support for overlay scrollbars

  <astearns> https://github.com/w3c/csswg-drafts/issues/92
  <fantasai> https://github.com/w3c/csswg-drafts/issues/92#issuecomment-236550745
  Florian: That's me. We've been discussing overlay scrollbar and
           having control. Different OSes do it differently. There's
           when it always takes space, it's when they disappear when
           they're not used. There's desire from authors to control
           that and desire from vendors to not allow that because
           you get bad behavior.
  Florian: There's a third dimension where the author doesn't care
           on looks, but when you're in an overflow auto situation
           don't display the scrollbar if not used, but give it
  Florian: The proposal is linked above.
  Florian: Recycle the overflow-style property with values
           auto|auto-hide|overlay. Auto is the initial which is
           follow the style. Overlay requires the scrollbars to not
           take up space.
  Florian: Windows has an overlay scrollbar, just not as the default.
  Florian: auto-hide if you're overflow auto it's the same as
           overlay. For overflow scroll it does a few things. The
           space for the scrollbar must be reserved. You take the
           space for the scrollbar and if the element isn't
           scrollable you don't display the scrollbar.
  Florian: Why it's on overflow-style is that these things should
           cascade separately. The style you want is different than
           where you want them.

  Florian: Yea/nay/questions?
  <dbaron> the 'auto-hide' value seems weird
  smfr: I think this is still treading on platform conventions. If
        you have a mouse with a scroll wheel you get space reserving
        scrollbars. It's also a setting in preferences.
  Florian: Yes...
  smfr: I think we discussed in Sydney and this still allows authors
        to override users scrollbar choices which I don't agree with.
  Florian: I've tried to minimize that tension. I'm not sure how to
           provide the things authors want without completely
           getting in the way of consistency for vendors.
  astearns: Authors want to be able to say reserve space for the
            scrollbars so I don't get re-layout. Is that right?
  Florian: It's one aspect.
  astearns: There are authors that want to control the scrollbars.
            Is there a way to give them control without overriding
            the users?
  TabAtkins: I think that's what auto-hide does. And I agree with
             your characterizations. That's what our impl want too,
             to never have to worry about scrollbars.
  Rossen: With auto you still have that problem. We had that in
          older IE where we had the area for the scrollbar reserved
          for the top scroller. It's weird but I can see why people
          want it.
  * jensimmons uses a wacom tablet — in Safari, the scrollbars are
               the same as when I don’t have it plugged in. In
               Firefox, it switches to oldschool scrollbars that
               reserve space all the time & show the scrollbar all
               the time. Just FYI. (We tripped over this when making
               a tool for Grid in Firefox, unexpected scrollbars.)

  Florian: I'm hearing that the way out is to merge overlay and
           auto-hide and that depends on platform. So it'll either
           overlay or be space consuming and not appear when not
           needed. But either way it won't consume the layout
  TabAtkins: It seems odd. I'd like to pursue getting the width of
             the scrollbars which is something else people want. But
             if you can't predict having it you can't control
             spacing. Having a plain auto-hide that reserves space
             and we have the other that always shows. So we can
             guarantee no re-layout and when possible takes no space
             but we have the always takes space value.
  Florian: I could see that.
  <liam> +1 to TabAtkins
  Florian: smfr would that work?
  smfr: Let me reword...If the scrollbar is a normal scrollbar,
        always visible, do nothing. If overlay allows the author to
        reserve the width of the scrollbar space.
  TabAtkins: Slightly different. auto-hide value from Florian where
             you always reserve space for the scrollbar even if it's
             not drawn.
  Rossen: So this is like overflow: scroll but up to the platform if
          you show the scrollbar
  Florian: It has two differences. On OSs that have overlay
           scrollbars, they don't consume space. This requires they
  Rossen: No. The size of the overlay scrollbar in layout is 0. You
          can consume 0.
  TabAtkins: We're saying you consume the normal width for a
             non-overlay scrollbar.
  <bradk> It would require reserved space even when no scrolling is
  Rossen: Okay. Now I agree it's weird.

  TabAtkins: We want to give authors a predictable width that
             doesn't change due to content or user preference. They
             have a predictable and usable geometry to work with
             without something shrinking outside their control
  * liam wonders whether overlay scrollbars and "traditional" ones
         are always the same width, and how you know which side
         they'll be on
  <bradk> Sounds horrible
  <dbaron> trying to make something that doesn't change based on
           user preference is silly when it changes as a function of
           OS and OS version
  <fantasai> Why don't we just make this the default behavior of
             `overflow: scroll`: Don't paint the scrollbar unless
             it's active.
  Florian: This could work when the space is 0 and you could reserve
           that on both sides. Even when it's 0 it visually takes
  Rossen: They only get rendered...in layout they only have render
          size while you're manipulating the content...while you're
          scrolling. So it's visible when you have a pointer down.
          The rest of the time they're not visible.
  Rossen: But why would you mess up layout for the rest of the time?
  <fantasai> + MAY make it invisible or semitransparent at other
  Florian: You don't mess up the layout, you always reserve.
  Rossen: I get your point. You want to reserve the space on both
          sides so when the scrollbar is visible it's not overlaying
          any of the content. My pushback is for overlay scrollbars
          they're only visible when you're scrolling and when you're
          scrolling your not reading
  TabAtkins: That's why I said a second value is to merge with
             overlay where it can go to 0 if your platform uses
             overlay. So that way you have one that's always
             consistent and one that takes up as much space as it
             can, but it's predictable so that when scrollbars show
             up it won't jiggle.
  Rossen: I got your point. For layout...for scrollbars that do take
          up layout space this feature makes sense.
  * fantasai thinks this needs to be written up
  TabAtkins: I think the first is important; I know a requested use
             case is for authors to turn on overlay and then reserve
             the space so that no content is ever covered. So making
             that easy seems worthwhile.
  TabAtkins: We can bikeshed over the names to make sure it's clear
             and they point you in the right direction. But I feel
             strongly from the use cases I've seen we want both.

  Rossen: I suggest that instead of a unit we look into something
          like gutters that we can do by box. Because people will
          start depending on this.
  astearns: There's lots of details. We're over time. People want to
            work on this to allow control of layout, but not
  Florian: There's two points against the proposal. Overlay needs to
           change definition which I can do. Second is what we were
           just talking about.

  astearns: I think we should continue discussion in the issue. You
            can propose changes there. We're a bit overtime now.
  astearns: Thanks everyone. We're done.

  <liam> padding-left: max(1em, --ui-scrollbar-width)
  <TabAtkins> liam: My plan is to push for either a `scrollbar`
              keyword, or better, a `scrollbar` <length> unit.
  <liam> sounds good
  * Bert thinks liam may have an interesting way out
  <jensimmons> yes, let’s not get into giving people the ability to
               ‘style’ the scrollbars. People want that. People used
               Flash just to get that. It was a usability nightmare.
  <TabAtkins> liam: Assuming we get a max(), yeah, like
              `max(1em, 1scrollbar)` or something.
  <astearns> liam - please add a comment to the issue
  <liam> of course, there's likely a user preference or locale
         setting for whether scrollbars are on left right, top or
  <liam> ok
Received on Thursday, 11 August 2016 01:36:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:04 UTC