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

[CSSWG] Minutes Lyon F2F 2018-10-23 Part V: CSS Cascade, Filter Effects, Text Decoration, Next F2F, CSS Conditional, Selectors, CSS Inline [css-cascade] [filter-effects] [css-text-decor] [css-conditional] [selectors] [css-inline]

From: Dael Jackson <daelcss@gmail.com>
Date: Sun, 2 Dec 2018 06:25:39 -0500
Message-ID: <CADhPm3sOF+KJ9tyi5vheeHqHYUEqJXRkdrhLC4xBsr7Mf=O2cA@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 Cascade

  - There were some preliminary proposals for how to only import
     needed stylesheets, but the group discovered the scope of this
     request was much bigger and could use more feedback from webdevs.
  - RESOLVED: Move this (Issue #3050) to WICG.

Filter Effects

  - RESOLVED: In mix-blend-mode, the default background color is also
              painted within the page group. (FXTF Issue #282)
  - RESOLVED: The filter applies to the result of the page group on
              top of the root background color. (FXTF Issue #282)
  - RESOLVED: clip path, opacity, mask will be applied to the output
              of the page group on top of the root group. (FXTF Issue
  - RESOLVED: The background color is UA defined with default being
              white. (FXTF Issue #282)
  - There is still more investigation to do around use cases for FXTF
      Issue #53 (Backdrop filters should not use BackgroundImage).

Text Decoration

  - RESOLVED: auto position resolves to the alphabetic baseline if the
              offset is not auto. (Issue #3118)
  - RESOLVED: text-decoration-width is now text-decoration-thickness

Next F2F

  - It will be in San Fransisco February 25th-27th

CSS Conditional

  - RESOLVED: Create CSS conditional rules level 4
  - RESOLVED: Accept selector feature functions for selector support
              in @supports, accepting a single complex selector as an
              argument. (Issue #3207)
  - RESOLVED: Namespaces are either always valid or valid when they're
              declared. (Issue #3220)


  - RESOLVED: Name the selector [the “functional pseudo-class like
              :matches() with 0 specificity”] :where (Issue #2143)

CSS Inline

  - RESOLVED: Add a leading trimming feature to the CSS inline spec.
              (Issue #3240)


Agenda: https://wiki.csswg.org/planning/tpac-2018#schedule

Scribe: gregwhitworth

CSS Cascade

Import only in moment when we need it
  github: https://github.com/w3c/csswg-drafts/issues/3050

  TabAtkins: Did I add this?
  TabAtkins: ok ok ok
  TabAtkins: ah
  TabAtkins: People want to only be able to import styles based on MQs
  TabAtkins: but for reasons, we don't actually block downloading
  TabAtkins: We have to go down the styles
  TabAtkins: The web depends on them being walked

  TabAtkins: So, people still want this
  TabAtkins: Leave the downloads only for devices that need them, etc
  TabAtkins: @supports is a good example of doing this
  TabAtkins: The proposal - the two that I have are either a: keyword
             like async after url()
  TabAtkins: this indicates the stylesheet can be loaded async
  TabAtkins: Or we can add a media function similar to supports, the
             old will be forced function but this one will only occur
             when the method is satisfied
  TabAtkins: Does this seems like good possibilities, if so which do
             you prefer?

  myles: Kind of like device width, if you resize the browser it will
         only fetch as you resize
  TabAtkins: yes, it's bad to put it on things that are likely to

  heycam: I think it seems reasonable to add support for this - the
          media function doesn't seem like the best approach
  heycam: for print I'm not even sure
  heycam: You hit cntrl+p and having to print
  heycam: Do you have any other scenarios

  jensimmons: I'm very skeptical about this
  jensimmons: I think it's a thing we want to think about deeply
  jensimmons: There are many ways that people do to make it so that
              it's faster
  jensimmons: Some of them are terrible
  jensimmons: Some of them make far more CSS, I'm not sure of anything
              but we don't want to do it too quickly
  jensimmons: Offering the tool - it will have a huge impact on how
              people work with CSS
  jensimmons: Now the industry is straining about CSS performance and
              it's getting kind of scary
  jensimmons: It's something we really want to explore - but we should
              dig into all of the aspects and not ship too quickly
              when the industry moves to a different approach that
              negates the investments here

  emilio: Why do we need to add import instead of link
  TabAtkins: Right now link rel=stylesheet doesn't have async
  TabAtkins: Whatever changes we have here we'll want to port over
             there as well
  jensimmons: You know what I might be saying is that I want to engage
              with a CG with more webdevs
  emilio: We rely on import, and others rely on that
  emilio: ...

  TabAtkins: One thing I'm running into - this might want to be, more
  TabAtkins: rather than just @supports
  TabAtkins: and import stays how it is

  emilio: What is the context of why?
  emilio: Why do we load print stylesheets even if we aren't printing
  TabAtkins: The reason we do it now is because people expect this to
             be the way it always has been
  TabAtkins: Back in the day we didn't have promises for these types
             of things
  TabAtkins: This will avoid some of our issues

  TabAtkins: This is getting more complicated - let's WICG it, let's
             do what Jen said
  TabAtkins: That sounds reasonable to me
  emilio: There is a way to do this in webkit, the .disable factory
  emilio: It won't load it
  emilio: It feels like I've filed various issues on that
  emilio: If we could agree on that - we could get web developers
          ideas on it, no need for something new
  TabAtkins: That functionality doesn't work on import
  emilio: I was hoping to not have to do this on import
  TabAtkins: Yeah we should though
  emilio: We don't support all security on that either
  TabAtkins: We should

  RESOLVED: Move this to WICG.

Filter Effects

What is the visual effect of filter() on the document element?
  github: https://github.com/w3c/fxtf-drafts/issues/282

  Rossen: This is about success on filters elements on the root element
  chrishtr: I brought this a few months ago - there were a few pieces
            of feedback
  chrishtr: How do you treat the root element, in particular frames
            that are transparent - similar to iframes
  chrishtr: It's in a webview in side of an app for example
  chrishtr: some other device that wants transparency
  chrishtr: I did some more testcases
  chrishtr: and have a proposed solution

  chrishtr: The new proposal is that - there are two conceptual layers
            you draw into, the frame root background layer
  chrishtr: the root element layer
  chrishtr: the background is always opaque white
  chrishtr: So there is white and then the root element
  chrishtr: You draw the stacking context of the root element into
            that layer except the background is extended into the
            infinite canvas
  chrishtr: everything would apply as is
  chrishtr: Clipping and filter and blend-mode and backdrop-filter are
            done in the same order as before
  chrishtr: So I went through the examples that smfr came out as he

  mstange: I don't think that is true.
  mstange: In your root element layer there is no white background
  mstange: If you don't have a background element on html then you can
           apply and filter and it will break
  mstange: If you have the background there then we will get what
           Simon expects
  mstange: We need to update background-blend-mode or we cannot invert
  krit: Blend mode currently defines white to be the page's backdrop
  mstange: Yes it does, but only the result of the blending is
           composited on top of it - it doesn't participate
  chrishtr: Is the contention - if you make it part of it then it
            fixes the invert, but if you don't then it breaks it
  mstange: If you make the white part - part of the page group you fix
           invert but change how mix-blend-mode is defined
  mstange: This part isn't implemented by Chrome
  mstange: Correct?
  chrishtr: I think Chrome is probably incorrect
  mstange: But if we change it, Chrome doesn't need to change
  chrishtr: True

  krit: I want to change web pages that will always have the white
  krit: it is there for sites that didn't provide a background, is it
        providing the background for websites
  mstange: We still allow people to change the default color to the
  mstange: There may be a11y issues here
  chrishtr: Let's save that for a different issue
  mstange: Sure

  chrishtr: Do we want to consider white as part of the root
  chrishtr: Then the root is not different than any other stacking
  mstange: The filter may be opacity: 0 - you'll need some type of
  mstange: I support painting the background twice, once inside and
           outside of the page group
  mstange: and defining the remaining issues
  chrishtr: Why twice
  chrishtr: Why isn't it ok to composite the filter to white?
  mstange: That could work
  chrishtr: You should just expect it to be composited to white
  mstange: If we say it's white for now
  mstange: If you want invert to be inverted
  mstange: It needs to be painted in the page group
  mstange: If you want a merge to apply to the default background color
  mstange: The white needs to be present to the input of the filter,
           now you have a result so you composite that to something,
           what is under the result
  chrishtr: It is white
  mstange: That's why it needs to be twice
  chrishtr: In the scenario where there is no background defined
  Simon: You propagate the color to the root element layer, and then
         do the composition
  chrishtr: Yes
  chrishtr: I think it's equivalent
  simon: If the root is white with alpha
  chrishtr: I think the math comes out the same
  krit: Depends on the transform and color
  krit: Let's say you can set the color in the page group, what would
        happen? Would backdrop not get inverted?
  mstange: FF settings don't allow alpha, the result would be opaque
           and that would be composted onto white, always gives you
           the same result
  krit: My only concern - do we always have a solid color
  mstange: As written, it would allow support for any background color
           including no background color besides what is defined on
           the root background color
  chrishtr: Whatever the screen happened to have on it would be

  <mstange> proposed resolution: In mix-blend-mode, reword the
            paragraphs "The page group is an isolated group. The page
            group is composited with a backdrop color of white with
            100% opacity." to mention that the default background
            color is also painted within the page group, i.e. that
            blending happens with the default background color.
  Rossen: Any objections?

  RESOLVED: In mix-blend-mode, the default background color is also
            painted within the page group.

  Proposed Resolution: the filter applies to the result of the page
           group on top of the root background color
  Rossen: objections?

  RESOLVED: The filter applies to the result of the page group on top
            of the root background color.

  mstange: Your document also changes opacity, mix blend modes and
  chrishtr: You mean it also changes opacity?
  mstange: If you have a background red on root and opacity: 0
  mstange: If I have background red on the root element, does this go
           inside the page group and root group?
  chrishtr: No
  mstange: That changes what occurs - this does not change the root
  chrishtr: This would change

  mstange: opacity is a type of filter
  mstange: clip-path and mask would change as well
  mstange: If you have clip-path on the root element, the clip would
           effect the background of red
  chrishtr: I think that's good
  mstange: I agree
  Proposed Resolution: opacity, clip-path, mask and clip path will be
           applied to output of the page group on top of the root group
  mstange: I don't agree with clip
  chrishtr: It's always a stacking context
  mstange: Should we just not mention clip
  chrishtr: Sounds fine

  Proposed Resolution: clip path, opacity, mask will be applied to the
           output of the page group on top of the root group
  Rossen: Objections?

  RESOLVED: clip path, opacity, mask will be applied to the output of
            the page group on top of the root group

  chrishtr: The reason I think we should use white as the background
            is to provide consistency to authors
  chrishtr: This is inconsistent with the need for a dark mode
  krit: Why not just keep a weight
  Simon: Why not have white be the default and allow UAs to adjust it
  chrishtr: I'm fine with that
  chrishtr: Should we ok with defining opaque
  krit: We should define the UA may define the background color and
        default is white
  Simon: And it doesn't need to be opaque

  Proposed Resolution: The background color is UA defined with default
           being white

  RESOLVED: The background color is UA defined with default being white

Backdrop filters should not use BackgroundImage
  github: https://github.com/w3c/fxtf-drafts/issues/53

  chrishtr: For reasons of implementation complexity, number 1 and
            avoiding situations developers would find confusing
  chrishtr: I want backdrop-filter to only apply to containing
            isolated group, which in spec terms is the background
            image of the group
  chrishtr: Takes the group - applies filter and then clips and paint
            behind it and then paint on top
  chrishtr: Issue 53, was originally filed to change the spec to not
            image but all the images from the root
  chrishtr: The prefixed impl that Safari has that draws everything up
            to the root - and unprefixed version in Edge also has that
  chrishtr: The reason I prefer it to the isolated group is because
            it's easier to implement and more performant
  chrishtr: Whereas if you draw all the way up to the root we'll need
            to implement a new algo
  chrishtr: If you go to an isolated group that is above the
            containing isolated group you may have to take into
            account other graphical effects into account with filters
            that move pixels, etc
  chrishtr: This increases complexity a lot
  chrishtr: This makes it complicated for developers - there are a few
            scenarios in the issue
  chrishtr: There's an element with backdrop-filter, somewhere in the
            ancestor an element has opacity but it isn't in the
            isolated group but that opacity must be included - so
            you're getting double opacity

  krit: I have to agree that opacity is indeed strange, did you do
        testing on Edge/Safari
  chrishtr: Yes, there are screenshots in the issue and they do double
  krit: I think there is developer desire to do it on the entire
        section, not just the isolated group

  mstange: Can you mention a case that would be impossible?
  krit: When you do an animation that has a filter on it
  krit: There wouldn't be any backdrop filter on it since it's
  mstange: That sounds like an animation issue
  mstange: That sounds like an ordering issue
  mstange: I agree with chrishtr that it would be easier to implement
           and be more predictable for authors
  krit: How does it work more consisted with mix-blend-modes?
  krit: You have two divs on top of each other, the second would be an
        isolation group - you would blend them together
  mstange: Mix blend mode and isolation groups are not always the same
  mstange: I'm interested in seeing scenarios in which I'm wrong
  krit: or maybe I'm missing some

  <krit> https://codepen.io/krit/pen/pxOMdz
  [looking at codepen]

  Simon: As I understand anything that creates a stacking context
         creates an isolation group
  Simon: That is contrary to the point of backdrop-filter which should
         apply to everything behind you
  chrishtr: Yeah
  chrishtr: I think this needs more discussion offline
  Rossen: OK, thank you chrishtr
  <krit> mstange: https://dbaron.org/log/20130306-compositing-blending

Text Decoration

Rethinking text-underline-offset
  github: https://github.com/w3c/csswg-drafts/issues/3118

  myles: We have two properties:
  myles: text-underline-offset and text-underline-position
  myles: [reads out values for each]
  myles: Question is, both of these properties-
  myles: the problem is only in horizontal WM-
  myles: both of these describe the vertical position of the underline
  myles: The spec does describe some situations on how they play
  myles: What happens if they collide?
  myles: There are two possible ways to solve this problem, is rules
         and also to join them into one property and avoid the bad
         issues at the syntax scenario
  myles: I prefer the latter as it's intentional and mechanical

  fantasai: I guess, I'm not sure which one is the better option
  fantasai: The reason they were separated was due to position may be
            dependent on the language where as the offset may be
            author messing with it
  fantasai: That means any time you want to make an adjustment you'd
            need to provide the offset change and which side the line
            is on
  fantasai: That is mostly important in vertical text where the line

  drott: I think we still need both values, even if you combine them
  drott: under auto | we still have to define rules when you combine
  myles: Thinking of them as one as a position and as offset isn't
         valuable because having an offset from auto isn't useful
         because every UA has a different auto
  myles: The pixel from the baseline to the underline is different
  myles: We're in agreement here
  myles: I do have a proposed syntax for this issue
  fantasai: In the case of the conflict, over and from-font there are
            three ways
  fantasai: Treat from-font as 0, as auto, or to take the distance from
            the alphabetic baseline and compute that to a pixel
  myles: You mentioned three of them
  myles: Two of them, pick a winner
  myles: Third is typographically bad - because it's defined to not be
         applied anywhere else

  fantasai: Before we add another keyword
  fantasai: There are whole lot of complications with underlines
  fantasai: When you have inline elements that have different font
            sizes the position of the underline gets complicated
  fantasai: If they're aligned alphabetically you're at least setting
            them from the same offset
  fantasai: But if text is aligned along the central baseline you
            don't want the line crossing through the chars
  fantasai: If you use under, you need to go below the largest
            descender and those calculations aren't tightly defined in
            L3 and we need to think about it for L4
  fantasai: I want us to be thinking about it
  myles: Are you referring to the decorator box
  fantasai: Not sure which one is that, but you don't want to cross
            through text - the UA should be taking the descendants
            into account
  myles: ok

  fantasai: Not sure where that brings us on this topic
  drott: can you sketch out your syntax proposal
  myles: I can link to it
  <myles> https://github.com/w3c/csswg-drafts/issues/3118#issuecomment-421827968
  fantasai: Easiest for combining is auto | from-font | length
  koji: How you set position of underline
  myles: No opinion - defer to fantasai
  fantasai: The offset measures in the block axis, so it works fine for
            vertical text
  fantasai: If the line is on the ascender side it goes away from the
            alphabetical baseline based on the value
  drott: Do we agree that the from-font should not be used for
         vertical text?
  fantasai: I don't see why not?
  drott: So we do want to use it as well?
  drott: The second point here is a bit inconsistent because we had
         from-font only for offset value and here it's for a base align
  drott: Here it's changing baseline left is equivalent to position

  <fantasai> auto | from-font | [ under || [ left | right ] ||
             <length> ]
  fantasai: Actually I think there is something we can do
  fantasai: Move from-font to the other property
  myles: So it will clobber the other
  myles: Would it be added?
  fantasai: from-font + a length?
  fantasai: You get the offset and then it's added to the length
  fantasai: I want it shifted down more
  myles: So would auto mean 0?
  fantasai: Auto currently means what the UA does?
  myles: The property that takes the length
  fantasai: I'm not sure if the offset for left and right is 0
  fantasai: If the UA does not hide the metrics of top or bottom, left
            or right
  myles: Underlines are exactly on the bottom of the descenders
  koji: What about when the issue is on the baseline?
  fantasai: You're right we would have to do that
  fantasai: The underline might be 0, but the alphabetic baseline
            there would be an offset that is UA defined
  fantasai: Auto means the UA gets to define what is appropriate
  myles: You said they add
  fantasai: We can't have an offset of 0 go from a UA-defined position,
            it needs to be exactly on the baseline or the author has
            very little control
  fantasai: The offset needs to be absolute
  fantasai: Underline position is something that folks will primarily
            use in CJK, for vertical underlines
  myles: So if both are auto it will look good, but if you set it to 0
         it jumps up
  fantasai: Yes

  Rossen: So what do we resolve on?
  <myles> auto | [ [ under | from-font] || [ left | right ] ]
  myles: The grammar of text-underline-position turns into this^
  <myles> auto | <length>
  myles: The grammar of text-underline-offset is this^
  koji: Yep
  fantasai: Yeah I think that's right
  drott: And the behavior if the value is from-font and then a length
         with offset they are added?
  fantasai: Yes
  myles: So if position is auto or from-font then they add
  fantasai: No they always add, but auto resolves to the alphabetic
            baseline if the offset is a <length>
  Rossen: Any objections?

  RESOLVED: auto resolves to the alphabetic baseline if the offset is
            not auto


  myles: this is text-decoration-width
  [myles shows presentation]

  myles: We wanted to be consistent with other things, but the purpose
         of consistency is easy of learning, and people are clearly
         confused, so I propose text-decoration-thickness

  RESOLVED: text-decoration-width is now text-decoration-thickness

Next face-to-face
  scribe: mstange

  TabAtkins: Last week of February, 25th-27th
  TabAtkins: Same building as last time
  TabAtkins: San Francisco's February weather isn't the best but
             better than San Francisco's summer weather
  TabAtkins: TGIF uses that floor on Thursday, so we only really have
             half the day
  TabAtkins: Monday to Wednesday are the only days we can use it
  Rossen: Are we not doing houdini topics?
  TabAtkins: Don't have any plans, expect to do a half-day side-track
             during CSS for anything we need to discuss

CSS Conditional

Selector feature query function for selectors
  github: https://github.com/w3c/csswg-drafts/issues/3207

  dbaron: When we discussed @supports back when we originally did it,
          one of the things we talked about that we maybe want to have
          support for more than querying for values
  dbaron: There may be more important use cases
  dbaron: Next addition would be testing for selectors
  dbaron: If you have three comma-separated selectors, the entire rule
          is supposed to get dropped if any of them is unrecognized.
  dbaron: This is painful because you don't get good negation
  dbaron: It has also come up recently when looking at scrollbar
  dbaron: @supports is useless for existing scrollbar styling use cases
  dbaron: because some of them use selectors
  dbaron: We all agree on what the syntax of testing for selectors
          should be, which is, it should be a function called selector.
  dbaron: We want to allow combinators.
  dbaron: There are currently some quirks related to ::-webkit pseudo
  dbaron: There is a quirk that makes all ::-webkit pseudo elements
          not invalidate the selector
  dbaron: We do not want to carry over this quirk to @supports selector

  heycam: There is an open question about namespace testing
  <myles> https://bugs.webkit.org/show_bug.cgi?id=189089
  dbaron: This turns out to be a bug in existing @supports because we
          didn't define it for content: attr(?)
  dbaron: We should figure out how it interacts with @namespace prefix
  TabAtkins: I'm fine with not having them
  TabAtkins: I definitely do not want to look at namespace, should
             either fail or pass always
  fantasai: I agree
  dbaron: I would lean towards saying the always succeed and act as
          they always match the namespace
  emilio: I would like to argue for the opposite, we should actually
          look at the namespaces in the stylesheet
  emilio: If you are testing for a selector that you actually use
          inside your @supports rule, that's what you want.
  emilio: It also doesn't require any special cases in the
  plinss: Isn't that the point, to ask whether you support "this type
          of selector", not "this particular selector"?
  emilio: I would argue that if it's an unknown namespace, you should
          not go into the @supports rule
  emilio: Invalid namespaces are invalid, they drop the whole rule
  emilio: just doing syntactic checking is inconsistent with other DOM
          APIs that throw on invalid selectors
  emilio: Like .matches
  TabAtkins: Can we make them always invalid?
  emilio: I'd prefer that over making them always valid
  dbaron: There's a risk with newly-supported selectors in the future
  emilio: Please don't introduce a special case
  TabAtkins: The matches function always ignores namespaces, because
             it always throws when there's a namespace
  emilio: Because there's no stylesheet
  fantasai: There's a rule in the :matches() spec that talks about
            namespaces, but it doesn't make it invalid

  dbaron: The other thing about the selector functions is that at some
          point the drafts of those functions had a namespace argument
          that got dropped.
  heycam: With CSS prefixes on the DOM node, no namespace prefixes are
          going to succeed except * or |
  TabAtkins: That same behavior seems fine to have for @supports
  fantasai: That doesn't make sense
  fantasai: I want to check whether I support a selector. Any selector
            that I'm using in my stylesheet, I should be able to put
            it into @supports
  emilio: I agree.
  fantasai: Which is not what TabAtkins is saying.
  fantasai: .supports would still return "yes I support namespaces"
  fantasai: it's not about "Does querySelector" support this
  fantasai: We're checking things at the syntactic level
  fantasai: I'd be ok with checking the namespace whether it resolves
  emilio: I would prefer to look at the namespace map, if it's around
  emilio: Then we don't conditionally need to make all namespaces
          valid in some cases.
  emilio: The rules in @supports should be the same rules as for
          regular parsing.

  TabAtkins: What do you think about changing the regular parsing rule
             of "bad namespaces" kill the rule?
  futhark: I tend to agree for regular namespaces. If we're not
           checking namespaces, I prefer that we actually allow
  emilio: So either check the namespace map as normal, or always

  dbaron: We need another resolution first, which is to create level 4
          of CSS conditional rules
  dbaron: unless we want to put this in level 3

  RESOLVED: Create CSS conditional rules level 4

  RESOLVED: Accept selector() feature functions for selector support in
            @supports, accepting a single complex selector as an

  dbaron: Do we want a resolution or two about the namespace thing?
  <heycam> the namespace prefix issue is
  fantasai: For the namespace we've resolved that they're not always

  RESOLVED: Namespaces are either always valid or valid when they're


Name the “functional pseudo-class like :matches() with 0 specificity”
  github: https://github.com/w3c/csswg-drafts/issues/2143

  <fantasai> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-408128027
  fantasai: Lea is not here, do we want to talk about it?
  fantasai: Anybody have anything to add to this discussion? There's
            no clear "this is definitely what we should do" resolution.
  fantasai: This takes a list of selectors of which any can match.
            Unlike the :matches() selector it basically zeroes out the
            specificity: anything you put inside has a specificity of
  fantasai: This gives you more control about which parts of the
            selector affect the specificity and which don't.
  fantasai: The only question is what to name it.
  fantasai: Some of the suggestions didn't get any traction.
  fantasai: We don't have any suggestion that is clearly better than
            the other ones.
  fantasai: My concern with a lot of these is that it is not very
            clear e.g. for :if() or :where() why this is different from
  fantasai: It's different because of the zero specificity, so the
            name should have something to do with that.

  franremy: Last time we had narrowed it down to three.
  fantasai: New ones were added after last time.
  franremy: We almost agreed on one of them last time, don't remember
            which one.
  franremy: Would prefer to not expand the length of the list of
  dbaron: To make progress, we need to say "Nobody leaves the room
          until we decide."
  <ericwilligers> Last time: :if() vs :where()
  <fantasai> https://lists.w3.org/Archives/Public/www-style/2018Jul/0027.html
  fantasai: Our resolution last time was to narrow the short list to
            :if() and :where(), and since then people also suggested
            :nil() and :zero().
  fantasai: So we could choose between those.
  <iank> :quash()

  Rossen: (1)if, (2)where, (3)nil, (4)zero, (5)quash
  Rossen: In that order, go ahead and put in your preferred 3.
  Rossen: In the order of preference
  * jensimmons doesn’t know what this does
  <franremy> 1 2 ... 4 3 5
  <iank> 2, 5, 3
  <fantasai> 5, 3, 4, 1, 2
  <cbiesinger> 2, 1
  <florian> 1, 2
  <TabAtkins> 3, 2, 1
  <heycam> 2, 1
  <futhark> 2 3 5
  <dbaron> 4 3 2 5 1
  <ericwilligers> 2, 1, 4
  <Rossen> 2, 1
  <eae> 3 2 1
  <melanierichards> 2
  <AmeliaBR> 2 4
  <rachelandrew> 2, 1 , 3
  <emilio> 3, 1
  <Oriol> 1, 2, 4, but I would prefer any
  <tantek> 4 3 5 :ns (no specificity)

  <fantasai> https://github.com/w3c/csswg-drafts/issues/1170
  <AmeliaBR> Why was `:is` dropped from the options?

  Rossen: A lot of votes for number 2 as the first choice
  Rossen: Resolve on :where()?
  Rossen: If anyone has a strong reason to change this, speak up now.

  RESOLVED: Name the selector :where()

CSS Inline

Leading Control
  github: https://github.com/w3c/csswg-drafts/issues/3240

  fantasai: On that page you see some diagrams that Jan and Niklas
            sent me.
  fantasai: The problem we have in CSS that is driving a lot of
            typesetting people crazy is that we have space above and
            below text content, and it's very difficult to line up the
            text with other elements.
  fantasai: You basically have to figure out how much space there is
            and use a negative margin. This is not a very robust
            system for achieving alignment.
  fantasai: We need the ability to strip out the top part of the line
            box that is above the text, so that you only have leading
            between the lines but not above the first or below the
            last line.
  fantasai: But not only do we need to be able to strip out the
            half-leading, which comes on top of the ascent, but also
            space between the ascent and the visible glyphs, which
            is some arbitrary number that the font author put in that
            might not have much to do with anything.
  fantasai: For different writing systems you want to use different
            metrics here, e.g. cap height for English, ideographic
            top for Japanese, etc.
  fantasai: So we need to strip it down to one particular font metric.
  <astearns> didn't we talk about a first-baseline-offset property at
             some point in the past?

  fantasai: The proposal is to add two new properties, for the over
            and under edge.
  fantasai: Which strips the size of the space down to a particular
            font metric.
  fantasai: The proposal is to have leading-trim-over/under properties
            which strip out the space.

  dbaron: I'm concerned about how this works if you have multiple
          things in a line.
  dbaron: If the goal is to have two things to line up with each
          other, adding properties which help you remove one of the
          things that cause the misalignment helps you get there, but
          it is not solving the problem as directly as you'd like.
  fantasai: We also need the ability to control the line box sizing
            more precisely, but that's separate.
  dbaron: What I'm thinking is that this seems more like a use case
          for something like line grid, or something line grid-ish.
  fantasai: It is not about having a grid.
  fantasai: It is about having the top align with an adjacent thing,
            or precisely controlling padding.
  fantasai: If I have letters in a box with padding, the amount of
            space between the top of the capital letters and the top
            of the box, visually speaking, is not the number in my
            padding property.
  fantasai: Having a line grid will not make that go away. It makes
            sure that consecutive lines have a particular rhythm, but
            it doesn't strip out this space.
  fantasai: The problem in the images in this issue is that the top of
            the text is not lining up with the top edge of its
  <astearns> (agrees with fantasai fwiw - this seems useful with or
             without a grid)

  dauwhe: One of them is about getting two things to line up, and one
          of them is about getting uniform spacing around something.
  fantasai: The distance between the content box top edge and the text
            as you see it visually is not controllable by the author.
  dauwhe: I've seen this problem in my work.
  fantasai: Our job is to make it so that you don't need JavaScript to
            do basic layout.
  fantasai: (Comparing to initial letter:) We do very precise
            alignment for initial letter. It is not about measuring
            the space, it is about getting the browser leave enough

  koji: Would like to have these metrics be accessible from both CSS
        layout and from an API.

  dbaron: What I was wondering is whether this is going to make other
          things that we want to do in this space harder.
  dbaron: Is this an independent thing that is going to be able to
          float on its own or does it make other things more
  dbaron: It's probably ok but I'm a bit worried about it.
  fantasai: If your concern is about the line grid stuff, this is just
            about helping to set where that line grid starts.
  fantasai: Line grid snaps baselines. Whatever calculation we do here
            is not going to affect the ability to snap things to
  fantasai: And step sizing works on the margin box, so it's not going
            to be badly affected by this either.

  florian: Detail: This needs to apply to the first and last lines in
           the paragraph, and not just to the direct children.
  florian: This is not a problem with the design, but should be
  florian: If you have several paragraphs, you want this to apply to
           the first line of the first paragraph, not to each
  dbaron: So you're saying it should be a non-inherited property that
          applies to the first formatted line.
  koji: I support it.

  <jensimmons> if this is helpful to anyone, I just wrote this demo to
               help me: https://codepen.io/jensimmons/pen/GYYpvN

  RESOLVED: Add a leading trimming feature to the CSS inline spec.

Meeting closed.
Received on Sunday, 2 December 2018 11:26:44 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 December 2018 11:26:44 UTC