[CSSWG] Minutes Telecon 2019-10-09 [writing-modes] [resize-observer] [css-text] [css-grid-2]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Writing Modes

  - RESOLVED: Close this issue (Issue #4357: Propagation from body to
              document element is annoying) no change


  - The group continued the conversation started at TPAC about the
      proposal for device-pixel-border-box (Issue #3554)
  - The name 'device-pixel-border-box' will need to be bikeshedded
      since it's not referring to the border-box but instead the
  - Making the value optional could lead to too inconsistent of
      results to be worth doing. This will be split into a separate
  - The object will be a width and height not a rectangle since
      there's no need for a top left setting.
  - The discussion as to if there is a new API required if this is
      added to resizeObserver will be split into a separate issue.
  - RESOLVED: Add API to get content box height and width in device
              pixel sizes to resize observer. Only return when
              requested and applies to all element.

CSS Text

  - RESOLVED: If there is a language for which you do not know the
              breaking rules. Rather then treating as unbreakable you
              treat it as breakable anywhere similar to
              overflow:anywhere (Issue #4284: Allow breaking anywhere
              when dictionary is missing for SEA scripts)

CSS Grid 2

  - RESOLVED: Accept Mat's proposal which is that resolved value
              unwraps repeat notations and does not insert track sizes
              for subgrid (Issue #4362: `grid-template-rows/columns`
              Computed / Resolved Values for 'subgrid' values)
  - fantasai plans to request CR for Grid 2 during next week's call.


Agenda: https://lists.w3.org/Archives/Public/www-style/2019Oct/0008.html

  Rossen Atanassov
  Oriol Brufau
  Emilio Cobos Álvarez
  Dave Cramer
  Elika Etemad
  Simon Fraser
  Chris Harrelson
  Dael Jackson
  Sanket Joshi
  Myles Maxfield
  Anton Prowse
  Florian Rivoal
  Devin Rousso
  Ken Russell
  Jen Simmons
  Alan Stearns

  Tab Atkins
  Tantek Çelik

Scribe: dael

  astearns: I think we have enough to start
  astearns: As always, are there any changes to the agenda?
  astearns: One change, we can't usefully do item 5 unless we get some
            extra people on the call
  astearns: Other changes?

Writing Modes

Propagation from body to document element is annoying
  github: https://github.com/w3c/csswg-drafts/issues/4357

  astearns: Who wants to lead?
  [discussion about if emilio has audio]
  * fantasai notes there was a request to do device-pixel-border-box
  * fantasai https://lists.w3.org/Archives/Member/w3c-css-wg/2019OctDec/0019.html
  * fantasai notes we also need to set dates for the summer 2020 F2F

  emilio: We resolved hesitantly on propagate the used writing mode
          from body to document element and to viewport I assume
  emilio: We have an implementation but afaict other engines are not
          ready to implement since don't store value in layout tree
  emilio: Resolution is hacky to implement.
  emilio: Should we implement this? Do what other engine impl which is
          just propagate to viewport? And tell people if they want
          orthogonal set on document element

  florian: Discussion on github is this looks hacky but doable in
           Blink as well. Given we resolved there is some willingness
           to do this. If not, I wonder why we resolved. We can reopen
           but it's unpleasant. If can do in blink and FF and we're
           moving the spec forward and it's nicest for author I would
           hope keep as is
  florian: If people not going to do it you're right it's not helpful
           for spec to say one thing and do another
  emilio: This is only thing that propagates to document element,
  florian: Propagation on other things is a bit complicated but less
           so. Only thing that propagates in this way
  emilio: As gecko dev I'm not in love with hack. Easier to propagate
          to viewport. Happy to impl if other engines will do it

  fantasai: In writing modes we wanted to make sure it's propagated in
            same way as direction. Means spec was not quite correct in
            way direction propagated.
  fantasai: Adding writing modes and direction need to propagate
            together. I understand how hacky it is, Blink solution
            sounds pretty crazy. I think propagate was a mistake, but
            it happens so have to address. Doesn't have to be perfect.
  emilio: Direction in gecko does not propagate at all, only have hack
          for scrollbar directionality and that would not be needed if
          both propagate to viewport
  emilio: Blink propagates to the viewport is to fix the same case and
          the hack for look up body style from scrollbox is doing.
  emilio: Intent is same, behavior is different as is impl complexity
  florian: Would like to hear from blink. We can investigate ideal.
           It's hacky but doable in gecko. If blink will do we don't
           have to revisit. We have discussed preferable behavior.
  emilio: But it was on assumption direction was propagate somehow.
          But in blink and webkit it is propagated with writing mode
          to viewport. In gecko there's no propagation, just lookup a
          box for this style
  florian: I suspect that if you fix bugs related to printing you'll
           have to do it there as well.
  emilio: Sure, but scrollbar position....that also works if you
          propagate writing mode to viewport
  florian: Direction only not propagate to document element is fine.
           But direction if you don't go through element you create
           horizontal flow and that's not nice. Ideally for authors we
           propagate the whole thing properly. If can't do that there
           are intermediate solutions.

  fantasai: I think important point that page progression direction
            and fragmentation direction needs to be consistent with
            how modify scrollers. That doesn't require us to change
            the root element
  fantasai: Means content will overflow root, but in a direction we've
            chosen. Similar to how the root element in the scrolling
            case doesn't grow to accommodate the content. Solveable
            but important to solve
  florian: If we just propagate to viewport it's workable but less
           nice for authors
  Rossen: That solution will be commonly hit by authors because most
          tools set direction on body rather than root element

  Rossen: When originally discussed I was in full support as
          documented in spec and that's the behavior in Edge where we
          propagate from body to root and all the way to viewport.
          Allows us to avoid all these corner cases of root element
          and body element differing by writing mode and causing
  Rossen: Unless explicitly set rules elsewhere that set different
          writing modes explicitly
  Rossen: In our impl it wasn't crazy to impl given we're kinda sorta
          doing it in overflow. I looked at blink and what I described
          is impl there. I don't know if we have resources right now,
          but wouldn't be opposed to giving that a go and having
          better results for authors as we have described
  Rossen: Doesn't mean I'm saying I'll definitely land it in blink,
          saying not opposed to landing.
  Rossen: Looking at rune's comments on GH he's not crazy about it but
          doesn't sound against. Don't want to speak for him/chrome,
          but looking through what's needed and what we spec that
          matches what as an author I would expect to see happen
  emilio: I'm okay closing no change if this is eventually implemented
  astearns: Sounds to me that yes impl is hacky but people are willing
            to change. Given author benefit I think we close no change
            and wait on impl
  astearns: Objections?

  RESOLVED: Close this issue no change

  * fantasai is just so sad that someone decided to do this
             propagation for direction in the past, and now we're
             stuck with all this nonsense
  astearns: Thanks emilio for bringing this up

  [agenda discussing]


device-pixel-border-box size
  github: https://github.com/w3c/csswg-drafts/issues/3554#issuecomment-538465771

  astearns: Discussed device-pixel-border-box size at TPAC
  astearns: I recall we still weren't sure how change will effect
            Safari. Example have now been provided. Do we have enough
            information on impact to Safari?
  smfr: Saw a couple of examples. I think Chris said he ran the tests
        on Macbook pro retina with the fixes and it made it look
        better. Can't say without doing work in webkit, but I think
        sufficient proof this is useful. On non-apple it's well known
        it's necessary
  astearns: Any other new information?
  chrishtr: Nothing new except demos and version of chrome that fixes
  smfr: I'm surprised you could get good results. Most macbooks have
        default scaling. Surprised you got good results on a machine
        with that behavior
  chrishtr: Tested on not absolute newest, but a macbook pro retina. I
            think it does have value and OS scaling if it's outside of
            control of application those situations can't be fixed
  smfr: What I'm interested in understanding is if on hardware with
        built in scaling such that you never get pixel perfect is
        there improvement in device-pixel-border-box? Is there value
        in making it optional and allow UA to not provide if it thinks
        it can provide better. Or do we make it required and force UA
        to do this when it's not going to get better
  myles: Easy to test if you change resolution of OS in your macbook

  astearns: Sounds to me like we don't have an objection to adding
            device-pixel-border-box size to the API, but may want
            another issue about behavior of API possibly making it
  ken: Would app fallback be multiply css pixel width and height by
       device-pixel ratio if UA doesn't supply?
  smfr: Impl will already have to multiply by device-pixel-ratio. No,
        does multiply. Okay.
  ken: That was the point, rounding or flooring can't get consistent
  smfr: Okay, then makes optional thing annoying
  ken: I don't know if built in scaling is higher quality but we got
       really good results on macbook pros even with non-1 to 1
  smfr: Okay

  smfr: Not objecting to adding. Question if needs to be rectangle or
        just a size since left and top don't mean anything
  chrishtr: Use case for canvas sizing top left not necessary
  smfr: We don't have a dom size object
  chrishtr: Yep. More consistent to have a rect, rect does have
            meaning. Not used in canvas case
  myles: Position of rect a little confusing if you consider overflow
  chrishtr: Does mean where it is on device window though
  chrishtr: It's used within the native texture if there's not special
            scaling smfr referred to. If texture is scrolled it's
            still...it doesn't take into account transforms and scrolls
  myles: Values off the top of the screen?
  chrishtr: I think would be fine to have size only for this reason
  chrishtr: Top left doesn't seem to mean much, want to know canvas
  astearns: Array of 2 values or are you minting a new size object?
  chrishtr: I don't know. Maybe new size object?
  smfr: If it always integral?
  chrishtr: Yeah
  smfr: Maybe you just have two long on the entry
  chrishtr: That are just width and height
  chrishtr: As relates to desire to add the equivalent method to
            getBoundingClientRect it would change to get device pixel
            width and height

  smfr: If we agree to resizeObserver do we still need [missed]?
  chrishtr: Don't think so, but Jeff Gilbert from Mozilla thought case
            was strong so I was okay adding
  smfr: Which case was it?
  chrishtr: You have a full screen where you don't want resizeObserver
            and you want a slight jump on resize frames
  ken: Jeff also had concerns that it fires late and application would
       fall behind a frame which is legit concern
  myles: You would need to execute heavy calculations every frame with
         this. resizeObserver means code only called when need to be.
  ken: Agree, but in experience from a dev on FF stack we felt it was
       important to alleviate concern. And FF intends to not recompute
       if layout isn't dirty
  smfr: I don't want every getBoundingClientRect to be more expensive
  chrishtr: Adding a new thing
  smfr: Okay, okay. Should discuss separately
  chrishtr: Okay with me. Is Jeff Gilbert on? Want to make sure he's
            okay to separate.
  chrishtr: If he's not, maybe tentatively do that.
  ken: I think Jeff would object. Not to represent his opinion, but I
       think he would.
  chrishtr: Great to resolve device-pixel-border-box size makes sense
            and then follow-up on the other one
  chrishtr: To make progress.
  ken: Want progress too
  astearns: smfr you would rather continue new API discussion or
            resolve to add it and continue discussion?
  smfr: Prefer to fork into separate issue

  fantasai: Question, says doing device-pixel-border-box size. What if
            person wants size of padding or content box?
  chrishtr: Those other boxes have use cases and tracked via other
            issues on the spec
  florian: But not at device pixel level the others
  chrishtr: No. Only use case for device pixels is canvas
  fantasai: But why wouldn't people using canvas want to paint inside
            the border?
  <AmeliaBR> Wouldn't it be the content-box that is important for the
             canvas? Since that's what they're using in their code?
  chrishtr: Canvas has a certain size and border is outside of that.
            Browser does that for you.
  fantasai: border-box size includes border so if it's not included
            it's not a border-box
  chrishtr: It's the device pixel box size in case of canvas. It's
            actual size of canvas
  fantasai: Then it's the content box and we should call it that and
            not border box
  chrishtr: Right
  ken: Sounds good

  astearns: Other discussion?
  fantasai: Summary of proposal?
  astearns: Add an API to get canvas height and width to resizeObserver
  chrishtr: Actual device width and height of the canvas. When changes
            resizeObserver fires.
  fantasai: I want to be clear. Adding and API which is only available
            on canvas element. Reflects pixel size of content box of
            canvas element
  fantasai: And it has a name that is not device-pixel-border-box
  chrishtr: Yes
  smfr: Available for any element you resizeObserve not just canvas
  fantasai: Have had various discussion on only canvas or all and want
            to be clear
  chrishtr: Only use case I know is canvas. Could do it for all
  smfr: I wonder if this should be something the user of the API
  chrishtr: For any API you ask for what you want and you're saying
            only available on canvas?
  smfr: Only want browser to do computation if author asks for data
  chrishtr: For sure. Part of draft spec to observe multiple types of
            boxes. You say what to observe. I agree browser should
            only do this if needed
  astearns: Further question of if someone requests this on not canvas
            what happens
  chrishtr: Allow or not allow is both okay. In terms of APIs
            implicitly maybe better on all
  smfr: Can imagine on something like video. Better on all
  chrishtr: No impl difficulty from allowing it
  fantasai: Add API to get content box height and width in device
            pixel sizes to resize observer. Only return when requested
            and applies to all.
  chrishtr: Can bikeshed name
  florian: Not objection, but want to be cautious on all elements.
           pixels vs device pixels people can get confused about and I
           have mild concern making this too easily available people
           will try and use it.
  astearns: A lot of things discussing now should be separate issues
            once we have draft text in place.
  astearns: Objections to adding this?

  RESOLVED: Add API to get content box height and width in device
            pixel sizes to resize observer. Only return when requested
            and applies to all element.

  astearns: Thanks chrishtr
  chrishtr: I appreciate all the feedback
  ken: Thanks for discussion

  fantasai: Want to discuss optionality
  astearns: Add an issue for that

CSS Lists

Should automatic list-item increment adjust for ol[reversed]?
  github: https://github.com/w3c/csswg-drafts/issues/4181

  <fantasai> https://github.com/w3c/csswg-drafts/issues/4181#issuecomment-522196318
  fantasai: Where we are is in this comment ^
  fantasai: Given TabAtkins isn't here maybe not now

CSS Text

Allow breaking anywhere when dictionary is missing for SEA scripts
  github: https://github.com/w3c/csswg-drafts/issues/4284

  fantasai: Certain languages where breakpoint not obvious from
            character code. Have to do analysis. If you do not have
            the dictionary or rules in the engine you don't break the
            text and it'll be long and overflow. I suggest saying if
            you don't know how to break then you should break
            somewhere. Doesn't matter where but between grapheme
            clusters. Have to have break opportunities
  myles: Did you mean must?
  fantasai: Yeah
  fantasai: Proposal to add that. Discussion in issue about where to
            break in languages, but this is about what to happen when
            UA doesn't have rules.
  florian: I think saying you must break somewhere and not middle of
           grapheme cluster. If you can do mid analysis with
           meaningful unit of breaking do that. But must break and not
           break grapheme clusters

  myles: How does browser know which scripts?
  fantasai: There's a classification, let me see.
  <fantasai> http://unicode.org/reports/tr14/#SA
  fantasai: Class SA is complex context dependent. If you're one of
            these scripts and don't have a resource to tell you where
            to break you should break somewhere
  myles: As long as spec says that this is fine
  fantasai: Okay
  astearns: Other concerns?
  fantasai: Proposal: If there is a language for which you do not know
            the breaking rules. Rather then treating as unbreakable
            you treat it as breakable anywhere
  astearns: And something about not breaking through grapheme cluster?
  fantasai: Yes. If we copy from overflow: anywhere that comes

  RESOLVED: If there is a language for which you do not know the
            breaking rules. Rather then treating as unbreakable you
            treat it as breakable anywhere similar to overflow:anywhere

CSS Grid 2

`grid-template-rows/columns` Computed / Resolved Values for 'subgrid'
  github: https://github.com/w3c/csswg-drafts/issues/4362

  fantasai: Just accept Mats proposal
  astearns: Opinions?
  Rossen: Wish I had time to read it.
  Rossen: This doesn't sound like something needed right now. Resolve
          next week?
  jensimmons: Can fantasai explain and then Rossen you can feel you
              understand? I don't want to postpone because we're
              trying to ship subgrid
  fantasai: Issue is when getting resolved value, value from gCS, what
            that value is not well defined. Regular grids resolved
            value expands all repetitions so you have number of tracks/
            columns. Mats proposal is same for subgrid but don't
            include length because that's not valid value.
  fantasai: You would say subgrid and then a list of all the line
  fantasai: Example in the bottom makes it clear

  Rossen: In this way it will be...subgrid columns will be serialized
          as part of grid columns?
  fantasai: grid-template-columns is property, subgrid keyword.
            Optional line names which are matched up. Can use repeat
  Rossen: Grid-template-columns would resolve to what he suggests in
          very last sentence?
  Rossen: Is that the expected behavior?
  fantasai: Yeah
  fantasai: We do the same thing as for regular grids, but we don't
            specify sizes in resolved value. Otherwise same rules for
            expanding repetitions

  Rossen: Going through examples to figure out if it's lossy for what
          you can reconstruct
  fantasai: It is lossy in same way as current without subgrid. We
            return resolved style, not computed.
  Rossen: I'm trying to figure out if it's more lossy, but seems about
  fantasai: Yeah
  Rossen: Doesn't sound bad
  fantasai: Alternatives is to fill in all sizes, but then can't read
            it back in. Want it to roundtrip
  Rossen: Agree
  fantasai: Other is to not unwrap but that's inconsistent with
            regular grids.
  Rossen: Yeah. That would have been my preference but we are where we
  Rossen: This seems consistent. Not opposed

  astearns: Proposal: Accept Mats' suggestion which preserves
            consistency with the rest of grid but allows subgrid
            values to roundtrip
  fantasai: Proposal: Accept Mat's proposal which is that resolved
            value unwraps repeat notations and does not insert track
            sizes for subgrid
  astearns: Objections?

  RESOLVED: Accept Mat's proposal which is that resolved value unwraps
            repeat notations and does not insert track sizes for


  fantasai: Related topic, this is only issue on subgrid. I suggest we
            go to CR in the next week or two.
  Rossen: Yay!
  astearns: Alright, fair warning.

  astearns: Thanks everyone for calling in.

Received on Wednesday, 9 October 2019 22:28:52 UTC