[CSSWG] Minutes Telecon 2020-03-04 [mediaqueries-5] [css-page-3] [css-values-4] [css-fonts]

  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 should update their Cork F2F travel
      plans/availability on the wiki so that a determination can be
      made on if the F2F will proceed as planned or if there's a need
      to develop a backup plan.

Media Queries

  - RESOLVED: Add three issues to the ED [Draft needs a security and
              privacy section. Add an issue for if there should be
              more than binary values. Add to the draft that this is
              still under discussion and maybe not ready to ship]
              (Issue #2370: Adding prefers-reduced-data as part of MQ5

CSS Paged Media

  - RESOLVED: Name this page-orientation with values rotate-left and
              rotate-right (Issue #4491: Add orientation descriptor)

CSS Values 4

  - RESOLVED: min() and max() get simplified by simple unit values of
              the same unit we reduce to one instance of each. We also
              reorder the arguments in the same way that sums reorder.
              Review math functions for consistency (Issue #4550:
              Specify simplification of min() and max() more

CSS Fonts

  - Originally the group was looking to amend the algorithm for
      selecting first available font to check for the 0 glyph, if not
      there check for .notdef glyph, else use 0.5em (Issue #4796:
      Reconsider the definition of "first available font"). Upon
      discussion it became clear that using 0.5em was problematic for
      looking for a font file so discussion will continue in the issue.


Agenda: https://lists.w3.org/Archives/Public/www-style/2020Mar/0004.html

  Adam Argyle
  Tab Atkins
  Oriol Brufau
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Daniel Holbert
  Dael Jackson
  Dean Jackson
  Sanket Joshi
  Chris Lilley
  Peter Linss
  Cameron McCormack
  Brian Kardell
  Devin Rousso
  Alan Stearns
  Lea Verou

  Rachel Andrew
  Amelia Bellamy-Royds
  Christian Biesinger
  Mike Bremford
  Manuel Rego Casasnovas
  Florian Rivoal
  Christopher Schmitt
  Jen Simmons
  Miriam Suzanne

Scribe: dael

  astearns: We should get started. fantasai noted first item on the
            agenda which I found with a stray agenda+ had been
            resolved so we'll skip
  astearns: Also will skip the 4th because don't have right people
  astearns: Not sure about 2. Is Adam on?
  Adam: There were other people with questions. Should they be present?
  astearns: florian mentioned it for attention but fine without him
  astearns: Any other agenda changes?

  astearns: I'd like to add- I asked on private list. If you know if
            you will/won't make it to Cork please update the wiki
  astearns: At the moment we have 4 or 5 people that may make it and
            the rest on the wiki say they cannot make it. Need to know
            if we should change to tele-presence or cancel. Please
            update wiki with your plans as you know them now

Media Queries 5

Adding prefers-reduced-data as part of MQ5 FPWD
  github: https://github.com/w3c/csswg-drafts/issues/2370
  <fantasai> https://www.w3.org/TR/mediaqueries-5/#prefers-reduced-data

  Adam: Inspired by JS having similar things. Access to information
        about users like data saver on your phone where you can say at
        a high level you want to use less data. Can reduce background
        activities. In JS we can be aware of this just like we can
        reduce motion.
  Adam: If they're in 2G or paying for data or something like that.
        Proposal is a flag in CSS so we can make adjustments. Proposal
        JS is granular but CSS just needs on or off. Do they want to
        reduce or carry on undefined.
  Adam: Good intro?
  astearns: Sure

  fantasai: Good idea to have a MQ for this. Concern there is
            different levels of less data. One is I'm on a slow
            connection, another is I'm paying small data and want
            reduced functionality. I'm wondering if need a couple of
            levels. Reduce data and another to compromise
            functionality if needed
  Adam: Good question. Reminds me of lie-fi which is where it says you
        have wifi but you don't. Frustrating for user because what do
        you do. People can use things like service worker for that.
        CSS I'm not sure if we need more. I like we're mimicking the
        system binary
  Adam: Most questionable part of MQ is around how hard is it to use.
        Examples people put is I have a big BG image and people want
        to do a color but then browser has already loaded your image.
        Lot of potential to not work. CSS because how it loads there's
        potential to not get what you want.
  Adam: Need to have a say where it goes. Maybe needs to be in head.
        MQ often bottom of file
  TabAtkins: I suspect we don't need more levels right now because I
             don't see it being likely you have much you can do
             besides if it's not in data saver I load and if it's in
             mode I load colors. There's not much useful in CSS we can
             do. I suspect we just need the two. Load or don't load
  Adam: Fonts as well. You can load expensive custom fonts. Put behind
        the MQ and only load if they don't have preference
  TabAtkins: Yeah. Yeah. Fonts and images. There isn't a middle
             ground. Either load or not

  smfr: Apple's main concern is this is more fingerprinting. It's
        biased fingerprinting toward low income with limited data.
        We're concerned this could be a targeting vector.
  smfr: iOS does have a settings switch but adds more fingerprinting
        where it remembers you flipped this switch on certain wifi.
        That's a worry.
  smfr: Would like to see security and privacy section added to the
  smfr: Not objecting but we do have concerns. Discussing if we would
  TabAtkins: Are you implementing the header?
  smfr: I think answer is no
  TabAtkins: Okay. You're not doing client hints that's acceptable

  fantasai: MQ aren't just CSS. Can also be accessed in JS and HTML
            attributes to load files. Not just about CSS but also
            controls if you load a JS library.
  fantasai: Also these days not about if it's a BG image people are
            loading lots of videos for decoration and that's data
            that's not needed. Can replace that with an image. But if
            you're even more resource constrained you'd want no image
  fantasai: If we don't have multiple levels now we should design so
            that we can expand later. I think there is multiple levels
            here and it's not just about CSS
  Adam: Good examples. I like them
  <dino> I'm not sure if the type of person who would load a huge
         video as a background image would also provide a fallback
         that is a solid colour :)
  <fantasai> dino, I can see AirBnB doing that, frex. They get pulled
             down over roaming connections a lot.
  astearns: Hearing we need security and privacy section. Second is we
            should have separate issue about needing more then a
            binary state

  astearns: One bit of background. This is on agenda because intent to
            prototype in Chrome
  smfr: Would have liked to see discussion in WG before PR merged
  <fantasai> +1 to smfr, adding features should get WG resolution
  astearns: I think there was some but I agree there could have been
  astearns: Looking through issue and not seeing discussion before
            merge, just comments on the issue
  fantasai: Remove it from draft or add annotation on issues or don't
            leave indication that there's an issue in the draft?
  TabAtkins: I don't think we should remove given client hints serves
             the same data. Exposing to CSS is user friendliness.
             Precise design open issues on that. So long as client
             hints is going through I think we should have this in MQ
             as well
  fantasai: We should annotate the issues a bit in the draft
  TabAtkins: Yeah
  smfr: Are client hints more than one impl? The comparison isn't
        valid if blink is only browser that impl client hints
  astearns: Anyone know the status in gecko?
  heycam: I don't believe we impl that

  astearns: Three issues. Security and privacy section. Add issue for
            more than binary. Add this is still under discussion and
            maybe not ready to ship
  astearns: Accurate?
  Adam: Yes to me

  chris: Question. Agenda item talks about if this should be in FPWD.
         That was published yesterday so whatever we decide will
         impact the ED. I think it was published with this included. I
         just took the ED and went forward
  astearns: Yes, that's what you should have done. We can take it out
            if need be

  astearns: Enough for now? Add the three issues to the draft and add
            them as separate GH issues
  astearns: Proposal: Add three issues to ED

  RESOLVED: Add three issues to the ED

  <TabAtkins> Even in the "video vs img vs color" scenario, I don't
              think there's a particularly useful line to draw there.
              Basically, I don't think there's a particularly useful
              "I have plenty of data, but I'm not the *sultan*" line
              to use, at least in CSS. JS can do more complicated
              stuff, but I think in such a scenario you should
              downgrade all the way to a gradient or a very small
              image, if people are requesting reduced data at all.

CSS Paged Media

Add orientation descriptor
  github: https://github.com/w3c/csswg-drafts/issues/4491

  chrishtr: Discussed in Dec. Can add to a named page to control
            rotation in printed output.
  chrishtr: Use cases are to provide orientation for dominant content
            direction when multi direction. Second it allow dev to
            provide mixed rotations for UA that don't support other
            page rotation parts
  chrishtr: I think some consensus use cases make sense.
  chrishtr: Discussion on name
  chrishtr: Check for consensus and then do name.

  <bkardell_> https://docs.google.com/document/d/1plEqcBz_6ApmtWYCSRxwOANgF5aGoAL2B0s_9PSQJF0/edit#heading=h.zd7icrtuskjo

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4491#issuecomment-590613842
  fantasai: Not clear on the behavior of this. I read TabAtkins
            comment that makes sense but you said it's not that
  TabAtkins: What happens is in cases where printed output but you
             control how pages are displayed, aka pdf, adjusts how
             they're oriented in that display.
  TabAtkins: You can have a whole bunch of portrait and then some are
  fantasai: Example in comment. Doc with a table, assign table to
            landscape with features we have. Printer the landscape is
            oriented to portrait. When open a PDF you get a bunch of
            portrait pages and a landscape for the page that has a
            table which is upright for me on the screen. That's
            without this property. Current behavior
  fantasai: Proposal is to rotate the landscape so it's sideways and
            you have to turn your head to read?
  TabAtkins: It's something else
  fantasai: What is the default that should happen right now?
  TabAtkins: Ideally you do what you described. Wide table you force
             to a named page and say landscape
  TabAtkins: In scenario today where browsers do not have ability to
             do different size pages in layout what you instead do is
             layout everything as portrait. If that means putting out
             bitmaps or whatever it all comes out as portrait.
  TabAtkins: This feature then says if you're output to a pdf go ahead
             and rotate. This is a the good feature isn't impl so
             let's put in this feature for now. It'll be a few years
             before browser can address properly
  fantasai: Okay, I think I understand. So this rotates whole paper
            including headers
  TabAtkins: Correct.
  TabAtkins: When browser can control paper orientation is this
  fantasai: Use case you're bringing up is you pre-rotate using
            writing-mode or transform or something and then rotate
            back to get effect of if we had portrait/landscape
  TabAtkins: Correct

  bkardell: I shared a google doc from gsuites that talked about uses
            involving mixed orientations. Is that included here?
  chrishtr: mixed means some landscape and some portrait. So your
            original comment is correct, and the additional use case
            from TabAtkins is a browser that doesn't fully support to
            still be able to output.
  bkardell: I see that in issue. Thanks

  astearns: Currently for output formats that can handle layout
            orientation. When browser can layout as a landscape page
            would this property start applying to on screen?
  fantasai: No
  TabAtkins: Not unless display in paged format which generally don't
  chrishtr: If site applies page:landscape and rotate:left you get
            things that look sideways. Shouldn't do that. Should only
            apply rotate for layout of printed mode
  astearns: I'm thinking of paged view on tablet. Currently...if you
            had this you could layout such that someone can rotate
            screen and get better view of horz content
  chrishtr: Cases where drawn by dev layout but paginated layout?
  astearns: Future browser with paginated ux
  TabAtkins: Got it. Depends on if it allows rotation of pages. If
             wants to be more like printed it would not respect. But
             if it's just layout onto desktop screen it would respect
             this property and rotate the page for you
  chrishtr: If you consider pdf viewer on tablet you can imagine
            browser to integrate with pdf viewer to not respect this
            and expect you to rotate. It's an option impl could choose
  fantasai: It's a good point astearns and we should write up that
  astearns: I've got people with defined opinions on pdf viewers we
            can consult
  TabAtkins: Want to make sure it's clear in description where this
             applies. Paginated viewing and makes sense to author
             orientation of page based on user preference not device
             orientation. Happy to work together to make sure text
             looks good

  astearns: Other questions or opinions on basic design before we do
  astearns: Let's talk names
  astearns: My opinion is page-rotate makes sense since talking
  chrishtr: Makes sense to me
  astearns: Other opinions?
  astearns: We're not setting anything in stone. I think for now go
            with page-rotate and with issue discussion
  fantasai: page-rotate or page-orient. rotate-left and -right makes
  TabAtkins: I like rotate because it's spinning. I would accept
  fantasai: I think that was my opinion until astearns' examples where
            this is a hint about correct orientation but you might not
            honor that. It's hint about orientation but not a command
            to rotate. I'm not super clear
  astearns: In order to prevent a verb should it be page-rotation?
  astearns: Seems like we're at a lull. Should we resolve on name
  fantasai: Have rotate property
  TabAtkins: But it's a rotate function. There's a reason for it to be
             a verb when we normally have adjectives
  fantasai: I feel inconsistency is not great
  dholbert: Rotate sounds like an angle rather then keyword
  TabAtkins: Breaking with rotate is good
  TabAtkins: Page-orientation
  chris: People talk about page orientation
  chris: page-orientation rotate-left and rotate-right?
  astearns: Makes sense. Rotate seems angle
  astearns: page-orientation with values rotate-left and rotate-right
  dholbert: Don't love rotate-left because sounds like clockwise and
            counter clockwise. Left is direction rather then rotation.
            It's translation
  chrishtr: left is 90deg rather then rotate
  dholbert: Suggests counterclockwise
  astearns: And easier to spell
  astearns: Other concerns?
  astearns: Objections?

  RESOLVED: Name this page-orientation with values rotate-left and

  astearns: Anything else you wanted on this chrishtr?
  chrishtr: That's it, thank you

CSS Values 4

Specify simplification of min() and max() more explicitly
  github: https://github.com/w3c/csswg-drafts/issues/4550

  TabAtkins: Important question is with a min and max function the
             spec declares we simplify argument as much as possible
             and when can fully resolve we replace function with
  TabAtkins: emilio and smfr wanted to partly simplify. Example
             min(10px,20px,1em) we simplify eagerly to eliminate 20px
             because there's no way that can be a result. 1em is
             unclear but when arguments are same unit you can simplify
  TabAtkins: Do we want to do that is the question
  TabAtkins: In general I've held only simplify if can be fully gotten
             rid of. But I do simplify sums so amenable to this level
             of simplification. Not further. If no objections I'm
             happy to go ahead and do what emilio wants and allow same
             unit simple values to be removed from min or max when
             clearly superfluous.
  TabAtkins: If no objections I'll do that bit and no more
  <emilio> TabAtkins: If we do that we also probably want to define
           _some_ ordering for those factors (probably the same as for
           products and sums)
  <emilio> Because to simplify fast you want to sort first

  heycam: For em units it's reasonable to assume non-negative. Case
          for percent?
  TabAtkins: Depending on property % can be positive or negative or
             positive only. Can't tell before resolved so need to
             leave. Don't want to distinguish cases about when % is
             against non-negative because seems more complex then
             needed here. Would rather % stay always because there are
             cases where they can be resolved negative
  heycam: Agree. Technically with 3 % you can get rid of one
  TabAtkins: Yeah but don't want to go to that level

  astearns: emilio commented on IRC
  TabAtkins: He argues we should order factors. Sums serialize in an
             order. emilio argues to do same for min and max where we
             eagerly sort arguments.
  TabAtkins: That's fine, we can do that
  TabAtkins: Makes sense since min and max are equivalent to sum and
             product. If we're doing some simplification I'm fine with
             that case
  astearns: Other comments?

  smfr: Fine with this. Wanted similarity. Want to look at other math
        functions coming up to see if need consistency
  TabAtkins: Other then hypot I don't think anything else. I don't
             think I want to inter-argument simplify hypot. Step too
  TabAtkins: If we have more functions that are commutative binary we
             should do same thing. Nothing outside min and max fit the
             bill so far
  <oriol> I'm having sound problems. I think this may add more
          confusion than anything
  <oriol> And not much consistent to do it for min/max but not for
  astearns: oriol has sound problems but sounds like agrees to do it
            as hypot. Think it may cause more confusion
  TabAtkins: Lots of simplification is arbitrary line of where we do
             it. Saying it's exactly like plus is a fine boundary.
             Happy to do it with min and max and make that the
             boundary. If it's essentially plus you simplify. If not
             you only do it when you can simplify the entire thing away
  <oriol> I think functions are different than sums because sums are
          an operator
  <oriol> So that argument doesn't convince me
  <oriol> It's even implicit in the notation, + is the usual notation
          for a commutative group structure in mathematics. It's less
          clear in min() or max()
  astearns: oriol would you object to the simplifications?
  <TabAtkins> min/max are associate+commutative in the same way that +
              and * are
  <TabAtkins> nothing else (including hypot) is
  <oriol> I don't object, but I think this may just add more confusion
          for authors, so I would prefer to treat functions as black
          boxes until we have resolved all arguments and can actually
          call them

  astearns: TabAtkins can you summarize?
  TabAtkins: Proposal: min and max get simplified by simple unit
             values of the same unit we reduce to one instance of
             each. We also reorder the arguments in the same way that
             sums reorder
  dholbert: Question on that. Is it possible for % to resolve to a
  TabAtkins: Yeah.
  dholbert: So min of two percent values isn't resolvable
  TabAtkins: Yeah, we exclude % from that
  astearns: Also we will look through math functions and make things
  astearns: oriol doesn't object, just doesn't think it's useful.
  astearns: Objections?

  RESOLVED: min and max get simplified by simple unit values of the
            same unit we reduce to one instance of each. We also
            reorder the arguments in the same way that sums reorder.
            Review math functions for consistency

  astearns: oriol please continue discussing in the issue

CSS Fonts

Reconsider the definition of "first available font"
  github: https://github.com/w3c/csswg-drafts/issues/4796

  chris: Not all fonts have glyph for space which means not first
         available font
  chris: Proposal is a three way thing where third item is width of
         .notdef glyph which all fonts are required to have
  astearns: I see that's 2nd on list
  chris: Yes, sorry
  astearns: If .notdef is guarantee?
  TabAtkins: Required and there are different. I'm happy with this

  astearns: Is it what browsers implement?
  chris: We believe so
  chris: There's a WPT that's wrong right now but it would become
         correct with this change. I suspect that means browsers do
         what this is proposed
  astearns: Proposal: Amend our algorithm for selecting first
            available font to check for the 0 glyph, if not there
            check for .notdef glyph, else use 0.5em
  astearns: Objections?

  RESOLVED: Amend our algorithm for selecting first available font to
            check for the 0 glyph, if not there check for .notdef
            glyph, else use 0.5em

  chris: My proposal is in the issue comments
  fantasai: I think it's different then original proposal so wondering
            if he was okay. I've got your proposal and one from
  chris: Right, his includes unicode range so if the unicode range
         excludes space. Not about if font excludes space then it
         counts as not having one.
  astearns: And if you use unicode range you exclude .notdef so it
            falls to 0.5em
  chris: .notdef isn't exclude-able with unicode range
  fantasai: Resolution defines ch unit but first available font is a
            lot more general. I'm a little confused. 4796 from what I
            understand is about the new definition of first available
            font checking whether the font has a space glyph. jfkthame
            proposed not checking if there's a space but if unicode
            range on font would cover space character. Then you
            proposed to check for zero instead of space...
  chris: Not quite. If it doesn't have a 0 then you can use notdef
         glyph rather then say we fail. That's compat with webkit
  fantasai: So to find first available font I check for a space, then
            for a 0, then notdef glyph, then use 0.5em? 0.5em is not a
  chris: Right. I see what you're saying.
  astearns: Talking about how to determine a measure from a first
            available font without a space or a 0 or notdef
  fantasai: ch has a definition of use 0 or 0.5em. If you're looking
            for x there's other metrics. Here we're looking for what
            font file.
  astearns: We're over-time. We should undo previous resolution and
            bring up later

  RESOLVED: Remove previous resolution, discussion continues on github

  astearns: Thanks everyone. Please update Cork wiki with travel
            plans. We'll talk next week

Received on Thursday, 5 March 2020 10:36:22 UTC