[CSSWG] Minutes Telecon 2019-10-16 [web-animations-1] [css-sizing-4] [css-grid-2] [css-text-3]

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

Web Animations

  - RESOLVED: Pseudo elements are targeted via a parent plus a pseudo
              selector (Issue #4301: Dependency on CSSPseudoElement)

CSS Sizing

  - RESOLVED: intrinsic-size is the name of the new property and value
              set is 'auto', 'legacy' and a length (Issue #4229:
              Proposal: content-size CSS property)
  - RESOLVED: We are redefining the size property in @page to be
              called page-size. Also defining that size in the page
              context parses into page-size. The size property is a
              shorthand for width and height (Issue #820: Adding a
              'size' shorthand for 'width'/'height')

Grid 2

  - There is ongoing discussion on github for how to resolve issue
      #4411 with several proposed solutions. The proposals are:
      1) Define that a subgrid subsets its parent grid’s template
         based on what part of it is covered, and ensures that its
         edges provide the requisite -start/-end lines at its edges.
      2) Define that the grid-*-start property searches the implicit
         lines before the first line instead of the lines after the
         last line if a specified line name is missing, similar to how
         span foo searches in opposite directions based on whether its
         a grid-*-start or grid-*-end value.
      3) Define that, while implicit lines have most names in the
         infinite space of possible names, only lines before the first
         line also have names ending in -start, and only lines after
         the last line have names ending in -end.
      4) Don't handle template subsetting; the cases you describe will
         be a type of error.
      - Anyone interested should add their thoughts to the github

  - RESOLVED: Serialize the subgrid template rows and columns to only
              include line names defined for the subgrid locally and
              not include names that came from the parent grid (Issue
              #4362: `grid-template-rows/columns` Computed / Resolved
              Values for 'subgrid' values)

CSS Text

  - RESOLVED: Space before a line break is removed even if reordered
              to the middle of line by bidi reordering (Issue #4308:
              Define break at space to remove a space explicitly)
  - Florian will get i18n feedback for issue #4283 (Need additional
      value of word-break for Korean) to see if the property has use
      cases outside of Hangul, but the group was generally inclined to
      add a property to support this use case.


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

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  Amelia Bellamy-Royds
  Oriol Brufau
  Tantek Çelik
  Emilio Cobos Álvarez
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Chris Lilley
  Myles Maxfield
  Stephen McGruer
  Peter Linss
  Anton Prowse
  Florian Rivoal
  Jen Simmons

  Lea Verou

Scribe: dael

  Rossen: Let's get going. We have too much to discuss today so we
          should start
  Rossen: I will call for agenda changes or additions

Web Animations

Dependency on CSSPseudoElement
  github: https://github.com/w3c/csswg-drafts/issues/4301

  smcgruer: I'm hoping this is a rubber stamp. Hopefully everyone has
  smcgruer: We have a problem where CSSPseudoElement has a lot of
            questions. For animations events and objects want to
            specify pseudo element by target being parent element.
            Similar to animations and transitions
  smcgruer: We expect this is how all will have to for for pseudo
            elements. No way to change events that happen today.
  smcgruer: Want to make sure makes sense for group

  florian: There was another conversation on pseudo events for
           highlighting and discussed with editing TF. Opinion of the
           Editing TF is it was inadequate so let's be careful how we
  florian: Not expert, but there was discussion on changing how looks/
  Rossen: I think the discussion florian referring to for highlight
          API were close to what's being proposed. From last I heard
          they want to start taking more dependency on this proposed
          model. Another was inking input want similar exposure for
          various types of actions and states. Want to be able to
          target similar eventing model

  Rossen: I have read the proposal, I don't think it's controversial.
          Want to hear from more people working in this space.
  Rossen: Not hearing any.
  Rossen: Are you looking for a resolution smcgruer? That accepts the
  smcgruer: Yeah
  fantasai: I wanted to ask if birtles has weighed in and what's his
  smcgruer: My understanding is he agrees. He was part of the
            discussion. But I can't represent him directly
  Rossen: I don't believe he was opposed. We can re-open and continue
          if it's not complete. It doesn't come across that birtles is
          against in the thread.
  Rossen: I propose we resolve and if there's additional conversations
          we can re-open
  fantasai: Okay with that if assumption is correct

  AmeliaBR: What's the exact proposal?
  smcgruer: Prop: Animations have a target element. We propose for
            animations targeting pseudo elements is the target is the
            parent and an additional selector that lets you know which
            the new element it
  Rossen: Pseudo elements are targeted via a parent plus a pseudo
  * flackr notes it is equivalent to AnimationEvent here

  AmeliaBR: Has anyone thought about forward compat for a pseudo
            element dom object?
  smcgruer: Not extensively. That's fair. Problem in general is event
            targeting in general will have to solve that
  AmeliaBR: True. We have events where event target is the element.
  Rossen: Even if go down path of exposing pseudo element as objects
          need to have a way to target through selectors. That way
          will have to work here. Only change to model is how to get
          to event target.
  Rossen: If we expand the pseudo family we have to figure out how to
          select. Not unique to this proposal
  Rossen: Objections?

  RESOLVED: Pseudo elements are targeted via a parent plus a pseudo

CSS Sizing 4

Proposal: content-size CSS property
  github: https://github.com/w3c/csswg-drafts/issues/4229

  <AmeliaBR> https://drafts.csswg.org/css-sizing-4/#intrinsic-size-override
  TabAtkins: With fantasai help and later edits after review with impl
             we drafted the property the intrinsic size property in L4
  TabAtkins: Sets intrinsic size of the content. We thought we could
             do it by manipulating contributions, but not workable so
             it explicitly sets the intrinsic size. Further discussion
             about how to interact with overflow.
  TabAtkins: This is what we discussed at TPAC and said it was cool.
             It's authored now, review if you're interested

  florian: Contribution vs intrinsic summary?
  TabAtkins: Are you familiar with difference? Contribution is what a
             child element will tell parent its size is when parent
             defines size. If the child has width 50px it will say
             that regardless of content
  Rossen: Important to know it's border box size of the child. Content
          is content size which is content-box. That trips a lot of
  TabAtkins: Reason why we couldn't go with contribution is because it
             doesn't have effect on sizing of element itself. It only
             effects parent's size. As defined before this property
             contribution is how it wants to be sized normally. Had to
             switch to the intrinsic size so when it tries to size
             itself it uses those contribution

  AmeliaBR: I think new name helps clarify. It's using wording we
            have. As long as consistent that this new property does
            the intrinsic size it might help clear up confusion
  TabAtkins: fantasai and I concerned with spelling being tricky, but
             it's used throughout the language so we figured it was a
             lost cause and should use the same word
  AmeliaBR: One point from heycam at end of issue about naming of
            keywords. He has a good point that legacy and auto aren't
            informative. Before naming something legacy we want to
            make sure we're certain only use case is describing stupid
            existing behavior
  TabAtkins: fantasai and I are convinced this is bad old legacy
             behavior and you wouldn't want intrinsic size of a
             scroller to report a really wide size. Point of a
             scroller is it's scrollable. We believe this is legacy
             and we do not want it. Lost opportunity to fix it but we
             think it is a straight up mistake and naming reflects that
  <fantasai> Issue wrt legacy vs normal

  Rossen: Proposal?
  TabAtkins: No resolution now. We did resolve at TPAC. This is a
             request for review.
  AmeliaBR: Resolve to accept the new names?
  TabAtkins: Probably? Let's resolve on intrinsic-size as the name
             with 'auto' and 'legacy' values
  Rossen: Proposal: intrinsic-size is the name of the new property and
          value set is 'auto' 'legacy'
  emilio: Wasn't there a proposal to set intrinsic size and that's
          separate? Seems like it should be a size not a keyword
  AmeliaBR: Default is a keyword that is do what we normally do
  TabAtkins: And you can specify a length or 2 lengths
  Rossen: Objections to intrinsic-size is the name of the new property
          and value set is 'auto' 'legacy' and a length?

  RESOLVED: intrinsic-size is the name of the new property and value
            set is 'auto', 'legacy' and a length

Grid 2

Subsetting grid-template-areas in subgrids
  github: https://github.com/w3c/csswg-drafts/issues/4411

  fantasai: Presenting the issue: Mats pointed out don't have way to
            have subgrid...if you have a grid area that's named with
            template and a subgrid that partially overlaps it will
            have only inherited line names. Might have foo-n line in
            the middle, but foo-start not inside subgrid
  fantasai: If you try and place item in slot foo it can't find the
            start line
  fantasai: Can we get that to fit within the part of the slot where
            it overlaps
  fantasai: Multiple ways to impl with proposals in issue. One is
            template areas are handled specially and generate extra
            line as necessary in order to have both edges represented
            within the subgrid.
  fantasai: Disadvantage is if you created grid area using lines it
            doesn't behave the same as with template.
  fantasai: Another proposal was define that if we can't find and
            foo-start lines or any foo lines in subgrid as searching
            grid-column-start instead of going to the nth edge of the
            subgrid we search into previous area
  fantasai: Problem with this is it's a slight change to general way
            grids work; could be web compat
  fantasai: Another is change search direction only for line names
            that start with 'start'. Again a behavior change
  fantasai: Last is don't handle template subsetting and you have the
            case where n line exists but start doesn't
  fantasai: Active discussion in issue, I don't think there's a clear
            right answer. Easiest is we pull the line names and you
            get weird results if using name from parent template grid.

  AmeliaBR: I don't think anyone will have strong opinions without
            looking in great details. Are you just letting us know?
  fantasai: Wanted to collect opinions. If no one has anything to add
            we can come back later
  Rossen: I think we should continue on GH on this one
  AmeliaBR: Isn't this a bit of a rush b/c FF is shipping?
  fantasai: Yeah, we should aim to figure out in the next week
  Rossen: Once we have a proposed solution we can add it.

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

  fantasai: Have a WG resolution, noted there is a minor point
            that...we took resolved value as used value similar to
            regular grid. What we didn't consider is we unroll repeat
            values and truncate line names list to number we have.
            Didn't consider if adopt parent names active on sub grid.
            Mats prefers to leave then out of resolved value
  TabAtkins: And we're fine either way

  AmeliaBR: Debate is return extra information about the computation
            rather keep simplest computed style?
  Rossen: In case of one line name in subgrid and that name comes from
          parent grid it will serialize to nothing. Is that proposal?
  TabAtkins: Yes, if subgrid didn't get line names it will resolve to
             enough empty line name sets to give number of lines. You
             won't see parents line name
  Rossen: This makes sense from model point of view. Trying to think
          through scenarios where you need awareness of names
  TabAtkins: If you're trying to do some modeling on your own based on
             line names you might want full set. You can walk up grid,
             but it is more work. I suspect that's a low value case.
             Given not reflecting them down is easier for impl I'm
             fine leaving off
  Rossen: Also I think it is a better model. We can later on if
          there's use cases we can add with a different serializer
  Rossen: It's a good clarification to the previous resolution

  oriol: I think current wording is confusing it says excluding those
         defined in parent grid. What if they define same name, do we
         want to include? I think you're trying to say only include
         the one locally
  TabAtkins: Yes, it's local names, not local names minus parent. We
             can reword to make it clear
  Rossen: Anything else?
  Rossen: Proposal: Serialize the subgrid template rows and columns to
          only include line names defined for the subgrid locally and
          not include names that came from the parent grid

  RESOLVED: Serialize the subgrid template rows and columns to only
            include line names defined for the subgrid locally and not
            include names that came from the parent grid

CSS Text

Define break at space to remove a space explicitly
  github: https://github.com/w3c/csswg-drafts/issues/4308

  florian: Turns out that it isn't exactly defined or interoperably
           implemented what happens with interaction of dropping
           collapsible whitespace and bidi. If something would have
           been at the end and bidi moves it do you still drop it?
           Fuzzily defined. Chrome and FF do one thing, Safari and
           Edge HTML is different. I think Chrome/Firefox makes more
           sense. Screenshots in the issue
  florian: I propose we adopt Chrome/Firefox behavior and task editors
           to define it
  myles: Webkit would be willing to change
  Rossen: Edge HTML this could be considered. It's reasonable behavior
  florian: Proposal: Adopt the Chrome/Firefox behavior and action the
           editors to spec it
  Rossen: Can you be more specific?
  fantasai: Space before a line break is removed even if reorder to
            middle of line by bidi reordering

  RESOLVED: Space before a line break is removed even if reordered to
            the middle of line by bidi reordering

CSS Sizing

Adding a 'size' shorthand for 'width'/'height'
  github: https://github.com/w3c/csswg-drafts/issues/820

  TabAtkins: Discussed in past. Useful because size often set
             together. @page rule has a size declaration and we can't
             collide names.
  TabAtkins: fantasai had a great suggestion to unblock. Rename @page
             declaration to page-size. Define @page has a parse time
             alias of size turning into page-size and that frees up
  TabAtkins: Any existing pages using size will work. Anyone using
             CSSOM to page @page will see a page-size property. I
             suspect that's almost 0 since @page is only useful in
             printing. Printing doesn't have much JS support. Almost
             no possible breakage and this will let us do the size
             thing we've wanted to do for at least a decade.
  TabAtkins: Clever way to get what we want.
  florian: I think you're slightly overstating lack of JS support, but
           I agree with the argument
  Rossen: It's a cool proposal. I'm in favor. Other opinions?

  dauwhe: I'll try and contact Prince about this
  dauwhe: They're a PDF formatter that uses @page and supports JS
  Rossen: Should we wait?
  dauwhe: No, go ahead
  Rossen: Thanks for the reach out

  florian: Since this is new aliasing should we be explicit about how
           it can be used?
  fantasai: It's defined at parse time and you never see the other
  florian: Of CSS file?
  AmeliaBR: Does become a question. If you use cssom method to pass a
            string that's parsed that is also parse time. Need defined
            somewhere. Need to define it somewhere for explaining
            relationship of MS prefixed force-colors vs new force-color
  florian: We have general aliasing, but this alias is weird
  TabAtkins: Normal is shorthanding based. Property then does show up
             in all contexts. This would be not that. Does need
             clarification. Happy to work to see exactly what to
  emilio: If can put width and height in @page this would be quirky
          because size means one thing in @page
  emilio: Can set width and height in @page rule. Means size does
          something different in @page then everywhere else.
  TabAtkins: That's why we can't overlap. Because size is not a
             shorthand in @page
  fantasai: Confusion from naming property anything other than 'size'
            is higher then size in @page not being width and height

  florian: Dev tools should be warning about this. If page-width
           exists and you try and use size you should be warned.
  TabAtkins: I don't think any browser respects @page size declaration
  florian: Chrome does
  TabAtkins: Okay. Cool. I think spec should clarify that it's
             page-size and it's required to do this parsing. And I'll
             file a bug on our dev tools that we should have a maybe
             use something else

  Rossen: Proposal: Add size as a shorthand for width and height for
          everywhere by @page?
  fantasai: Several things. 1) We are redefining the size property in
            @page to be called page-size.
  Rossen: Let's resolve there first
  fantasai: Also defining that size in the page context parses into
  fantasai: Once that's resolved, then the size property is a
            shorthand for width and height
  Rossen: Objections to these three steps?

  RESOLVED: We are redefining the size property in @page to be called
            page-size. Also defining that size in the page context
            parses into page-size. The size property is a shorthand
            for width and height

  <AmeliaBR> (To clarify my earlier comment, the similarity to forced
             color was that any rule inside the `@media
             (-ms-high-contrast)` would include an implicit
             `forced-color-adjust: none` declaration added at parse
             time. But doesn't look like that got included in the
             spec, it was just a suggestion of how MS could handle

CSS Text

Need additional value of word-break for Korean
  github: https://github.com/w3c/csswg-drafts/issues/4285

  florian: Reminding people: Korean traditionally written like
           Japanese without spaces. Now use spaces, but line-breaking
           has not changed where you can break like Japanese
  florian: Some typographers agree in many contexts it's nice to
           line-break Korean like English. Not everyone agrees with
           that. Discussion in GH shows that.
  florian: We need another value because the existing 'keep-all' only
           works if you can lang-tag. Do we care about allowing this
           behavior for Korean that can't be language tagged? I think
           we do.
  florian: If you're writing Korean in a text editor or from a
           database where you don't have language tags it's tricky to
           tag on the fly. Amount of magic you have to do is really
  florian: Either we say when editing this behavior is impossible or
           we say for the Korean alphabet you get the normal or we add

  myles: Putting Hangul in the value doesn't make sense when you use
         lang tag
  florian: But you can't put lang on contentEditable section because
           you don't know what will go in there. If they do a mix of
           languages you can't language tag. Adding spans on the fly
           depending on what user types is performance-wise terrible.
  myles: Seems wrong level of abstraction. Wish it could be
         generalized. Worried eventually have 100 different lang
         specific values.
  florian: Possibly. It's really that there are two normal behaviors
           so normal can't do the right thing. We need two normals. I
           don't think there are that many languages that need two
  AmeliaBR: That's my concern too. Before settling on language
            specific keyword do more research to see if more languages
            have this issue. How much input have you had from general
            i18n experts beyond Korean use case
  florian: Have not heard of any language. People who would probably
           know have been involved
  fantasai: I think if there were other languages they would need a
            separate keyword. It's separating Hangul from Chinese and
            Japanese. Most other writing systems don't mix in the name
            way and not that many that break everywhere like this. I'm
            not aware of any others that alternate in the same way as

  jensimmons: I like what florian is proposing. I understand concern
              on break from purity, but I feel like one thing web
              didn't do well was support international languages. This
              is a way web can keep up with evolving graphic design
              changes. Feels like a way to make sure web supports a
              culture and its ability to evolve instead of saying it's
              complicated and we don't know where it's going to go
  chris: Good idea as long as clearly defined what this value does
         when don't meet Korean text. I think it's a thing we need. If
         web started in Korea we would have had this from the start
  florian: If you're not in Hangul you do the same as keep-all

  tantek: I want to re-raise something from AmeliaBR. AmeliaBR asked
          how much input we had from general i18n experts. I want to
          raise that and propose before we resolve we file and issue
          on i18n discuss ( https://github.com/w3c/i18n-discuss/issues )
          to get input from broader experts.
  tantek: florian saying you haven't heard of other languages isn't
          quite sufficient
  florian: Reaching out to i18n, yes. But to have a modern language
           that has the exact same behavior so we can name the keyword
           something else we need a language who by defaults breaks
           between every language and want to move away from that and
           there aren't that many.
  tantek: I'm saying it shouldn't be dependent on just your expertise.
          You may be correct, but worth getting that group to take a

  myles: Wanted to ask if any thought given on how to impl? Like are
         there line breaking libraries that impl this behavior?
  florian: This would need to be impl in ICU. ICU seems amenable to
           this but if we expand ICU would have to expand as well.
  Rossen: I hear requests to get more from i18n. florian are you okay
          to do that this week? To get traction or a checkmark to say
          it's good?
  florian: Yes, I can look into this

  Rossen: That's it for today, have a great rest of your week.

Received on Wednesday, 16 October 2019 22:35:53 UTC