W3C home > Mailing lists > Public > www-style@w3.org > June 2017

Minutes Telecon 2017-06-07 [css-cascade] [css-pseudo] [css-syntax] [css-overflow] [css-contain] [css-typed-om] [mediaqueries] [selectors]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 7 Jun 2017 21:44:56 -0400
Message-ID: <CADhPm3s06N9XPOg=Zdvwazqo3C-aaVQFqA0WhvYWpopqeetDCg@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.
=========================================


How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------

  - The proposed spec text from the issue is: "Inheriting properties
      of inline fragments that are contained in a ::first-line only
      inherit from the ::first-line if those properties (1) do apply
      to ::first-line, (2) do inherit by default, and (3) are not
      custom properties."
  - Point 1 of the proposal caused some concern as it may not be
      necessary, but during the call some examples were provided
      showing that it was important.
  - RESOLVED: Take the behavior described in the issue and work with
              it to make sure it works for compat.

typed-om editor
---------------

  - Naina will be added as an editor.

"Serializing <an+b>" doesn't match what Firefox or Safari do
------------------------------------------------------------

  - RESOLVED: Drop the 1 or -1 on an+b serialization

<percentage> shouldn't be able to resolve to <number> in calc()
---------------------------------------------------------------

  - RESOLVED: Accept proposal (don't allow <percentage> to resolve
              to <number> in calc())

FPWD as a dependency for [css-contain]
--------------------------------------

  - RESOLVED: Move the text for integration between contain and
              overflow to level 4 of overflow

Non-positive value should be invalid for 'resolution' feature
-------------------------------------------------------------

  - RESOLVED: Spec should say resolution used to disallow negative
              numbers. It makes sense to allow negative with the
              boolean logic with some examples and that's for all MQ
              with a numeric value.

Propagation of the :focus pseudo
--------------------------------

  - This topic will be added to the F2F agenda to get further
      discussion. Any testing before that should be added to both
      the CSSWG & WHATWG issues.

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jun/0008.html

Present:
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Brian Birtles
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Dael Jackson
  Dean Jackson
  Peter Linss
  Myles Maxfield
  Liam Quin
  Naina Raisinghani
  François Remy
  Melanie Richards
  Florian Rivoal
  Alan Stearns
  Shane Stevens
  Greg Whitworth

Regrets:
  Rachel Andrew
  Rossen Atanassov
  Bert Bos
  Angelo Cano
  Benjamin De Cock
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Vlad Levantovsky
  Chris Lilley
  Anton Prowse

Scribe: dael

  astearns: Thanks everyone for calling at the different time.
  astearns: As always, first thing is are there extra items? I got
            the one from TabAtkins about percentage and calc.
  astearns: Next topic is usually spec rec, but I've had no time to
            summarize. Thanks to everyone that updated on group
            list. I'll get something more up to date next week.

How does 'inherit' keyword behave in a child of ::first-line?
-------------------------------------------------------------

  github topic: https://github.com/w3c/csswg-drafts/issues/1097
  fremy: I had been presenting that. We were waiting 2 weeks ago on
         dbaron's reply.
  fremy: dbaron basically agreed with the proposal and I think we
         should probably just resolve on the behavior from the issue.
  fremy: We were debating on best way to enter this into the spec,
         it's editorial so it's up to the editor.
  fremy: We were trying to describe how inherit works when child of
         first pseudo element.
  <dbaron> Proposed resolution was: "Inheriting properties of inline
           fragments that are contained in a ::first-line only
           inherit from the ::first-line if those properties (1) do
           apply to ::first-line, (2) do inherit by default, and (3)
           are not custom properties."
  fremy: To recap: The element is a child of the ::first-line pseudo
         and will generate the property and it will inherit by
         default.
  fremy: dbaron felt the approach was right if not the best wording.
  fremy: We can work through the right wording, I guess.

  astearns: Anyone with more comments or wants more explanation?
  <tantek> this sounds reasonable, I'm wondering what the interop
           situ is on this?
  fantasai: I'm a little confused why we need to check if they apply
            to ::first-line.
  dbaron: That's what my comment was about. It wasn't about wording
          but if that should be more general. Normally in CSS
          applies to don't effect computed values. But applies to
          pseudo elements does effect computed has been my
          understanding. But we don't say that anywhere.
  dbaron: My comment was that if that is the case we should a) say
          it and b) remove condition 1 since it becomes redundant.
  * fantasai thanks dbaron for the clear summary
  fantasai: It could effect computed value on pseudo element. But
            having properties inherit differently is really hairy.
            There are a lot of properties where applies to is more
            general
  dbaron: It's possible that we need to separate applies to and if
          properties apply to pseudo elements. That's more clear cut.
  TabAtkins: I agree. The rest of applies to are editorial pointers,
             but that's reasonably mechanically relevant
  fantasai: There's a lot of properties where we say it applies to
            everything, but that's because it inherits. We could
            tighten that, but the majority of applies to aren't
            tight.
  Florian: And sometimes it's the opposite case where we state the
           things it doesn't apply to. It's a fuzzy mess.
  fantasai: It's not precise enough. If it's going to determine how
            things inherit we need to be rigorous. I don't think we
            should make the spec depend on if a properties applies
            to. It should be if it's inherit or not.
  dbaron: I think we need it for if it applies to pseudo elements,
          but the specs aren't great on specifying. In Gecko we list
          every property that applies to a pseudo in the code. If
          it's doesn't apply the declarations aren't applied. That's
          ::first-letter and ::first-line.

  fantasai: What's that case where we need the distinction?
  dbaron: display
  fantasai: It's not inheritable.
  dbaron: I need to look at examples then.
  fremy: I don't have a list of, but user-select would be one.
  Florian: That's not inherited.
  dbaron: I think the main reason inheritance needed restriction was
          variables.
  fremy: Yes, yes.
  fremy: Variables, in that case, they could apply to any property.
         But that's condition #3 where we say we don't generate
         custom properties for ::first-line. There may be others.
  fantasai: If we're going to have this condition I want an example
            that is inheritable, not a custom prop, and doesn't
            apply to ::first-line. If there's no such property we
            don't need this conditional
  fremy: Is there a list of properties that inherit?
  fantasai: Indexes.
  TabAtkins: That's not tracked across specs. It's on the to do list.

  astearns: Sounds like we're converging on resolving to take the
            proposal except possible condition 1 which needs a real
            world example of why it's needed.
  fantasai: Yes. I'm happy to resolve on the rest but I don't want
            this conditional if it's not needed.
  dbaron: Writing mode and direction are the two properties I've
          found so far that are problematic.
  Florian: If you try and change the writing mode on the
           ::first-line...yeah. Don't do that.
  astearns: The treatment that is currently in the issue, whither or
            not we have that first conditional, are writing mode
            still problematic?
  dbaron: They're inherited, not custom, but no one interprets them
          as applying to ::first-line
  fantasai: That's a good/interesting one. ::first-letter could be
            in a different writing mode.
  <dbaron> 'white-space' may also be a problem (with ::first-line
            and 'pre')

  astearns: To answer tantek from earlier, it sounds like we don't
            have interop. Correct?
  fremy: It's correct, I think. The issue was mostly Chrome allowed
         a few more properties to inherit and the custom properties
         weren't blacklisted in FF.

  astearns: Can we resolve to accept the proposal, possibly
            excluding condition 1 if there is no compelling example.
  Florian: I think we found an example. Which leads to applies to
           not being specific enough to rely.
  fremy: We can agree on the behavior of this issue. I think we can
         discuss the other issue separately. We can agree on the
         behavior and discuss further what applies to means.
  Florian: I think having or not having part 1 is a difference of
           behavior.
  Florian: I'm okay resolving this and filing issues against specs
           to tighten applies to.
  fantasai: That won't happen in any reasonable time frame. The
            exclusion list should be explicit for now and then look
            for a better way to distribute. Most don't take into
            consideration ::first-line and ::first-letter and may
            say "all applies"
  fremy: Currently in pseudo spec there's a list of properties.
  <fantasai> https://drafts.csswg.org/css-pseudo/#first-line-styling

  dbaron: CSS 1 & 2 had a list of what properties apply to
          ::first-line and ::first-letter, but I think it was a
          should.
  dbaron: That may or may not be different to the applies to line.
          We discussed about moving it, but we never did.
  Florian: Should we point to pseudo 4?
  <Florian> pseudo-4 isn't good enough for the list. It has the list
            of "at least these must apply", it does not have "these
            do not".
  <liam> [css 2.1 lists for first-letter, font properties, color
         property, background properties, 'word-spacing',
         'letter-spacing', 'text-decoration', 'text-transform', and
         'line-height', and then says, UAs may apply other
         properties as well. ]
  <liam> [ https://www.w3.org/TR/CSS2/selector.html#first-line-pseudo
         just before 5.12.2 first-letter ]
  <Florian> https://drafts.csswg.org/css-pseudo/#first-line-styling
  <Florian> https://drafts.csswg.org/css-pseudo/#first-letter-styling

  fantasai: What we need here is a list of properties that aren't
            inherited from the pseudo elements and we can come up
            with a more general approaches, but a good black list is
            a starting point.
  astearns: Sounds like we're resolving on the proposal with a
            blacklist, but further define how to do it later. This
            is the behavior we want.
  <dbaron> It could have a list of "these apply", a list of "these
           do not apply" and a note that if it's on neither list you
           should contact the spec editor.
  <fantasai> dbaron: That's a decent approach :)

  tantek: I think I like the rough approach. I asked about interop
          because every time we've tried to do this in the past
          there has been compat issues. If someone wants to try this
          with simple examples it could illuminate the likelihood of
          this approach. I'd propose someone writes tests to test
          their assumptions and show how bad the situation is.
  tantek: It's a hard problem
  astearns: Proposed resolution is try and specify this behavior and
            see how that proposed behavior and interop goes.

  RESOLVED: Take the behavior described in the issue and work with
            it to make sure it works for compat.

typed-om editor
---------------

  astearns: I'd like to add naina as an editor of typed OM
  TabAtkins: I'm fine with that.

"Serializing <an+b>" doesn't match what Firefox or Safari do
------------------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1504

  TabAtkins: If the a value is 1 or -1 you write the digit in
             serialization. This violates general shortest form
             rule. FF and Edge agree on not printing the 1 digit.
             I'd like to change the spec to match that.
  <fantasai> sgtm
  astearns: Makes sense to me. Objections?

  RESOLVED: Drop the 1 or -1 on an+b serialization

<percentage> shouldn't be able to resolve to <number> in calc()
---------------------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1463

  TabAtkins: When you use percentage in calc it's allowed...you can
             use it anywhere the usage would resolve a percentage
             against another type.
  TabAtkins: Applies equally, but per spec it applies to numbers.
             This would apply in opacity, for example. Problem is in
             typed OM when I'm trying to deal with types of
             expression how we described in last F2F numbers have an
             empty type map.
  TabAtkins: If we don't allow percentage against numbers they're
             easy to handle. It's always some type and I can later
             fill in the type.
  TabAtkins: If it could resolve against a number I lose that
             ability. A percentage could be a type or none at all
             and that makes the algorithm harder to describe.

  Florian: Clarification: opacity you have percentage or number and
           it's the same or you have line-height where percentage
           and number aren't combinable. Are there cases where you
           have percentage and number where they're combinable but
           not same?
  fantasai: They're combinable in the sense where number and
            percentage in line-height ultimately resolve to length.
  fantasai: We could, in theory, allow that.
  TabAtkins: There's a reason not to. I'd like to never allow that.
             There's a reason to disallow that.
  TabAtkins: It makes the type of number incoherent. It's typeless
             or has a type. It makes the algorithm to type check
             math extremely more complicated.
  <AmeliaBR> For line-height, percentage and number don't inherit
             the same: percentage gets converted to length before
             inheritance, number is converted at used-value time.
  <fantasai> AmeliaBR: Yeah, and in width, <length> and <percentage>
             have that same difference.
  <AmeliaBR> PS, for length + number, there are all the SVG
             properties to deal with, that treat number as
             equivalent to px
  <AmeliaBR> (e.g., stroke-width, stroke-dasharray)
  TabAtkins: Big problem in when you multiply unitless. If a number
             can represent a length if you multiple 1 x 2px is it a
             length or a length squared?
  TabAtkins: There's only two cases where this matters, line-height
             and tab size. We could just add a unit. For now we're
             okay. Calc doesn't allow you to treat a number as a
             length.

  dbaron: I'm not happy about treating number and percentage the
          same. Number on line-height needs to be distinct from
          percentage.
  TabAtkins: They are. This is where percentage resolves to a
             number. Opacity is the obvious example. I propose we
             say a percentage never resolves to a number type.
  fantasai: Does the percentage value of opacity compute to a number?
  TabAtkins: I believe it computes to a number. That's what it has
             to do. Opacity uses 0 to 1 as a percentage. The two are
             equivalent.
  <Florian> I'm with Tab here. The alternative seems to mean a lot
            of complexity for no good reason.
  fantasai: I think it would be surprising if someone tried to to
            combine and it didn't work. If you're adding a variable
            to an inlined you'd have to be very careful.
  TabAtkins: I agree. That's why we originally wrote percentage can
             resolve against number. But from a practical standpoint
             dealing with types it doesn't work. You get an
             incoherent thing where numbers can sometimes be used as
             extra values. In the worst case you can never tell what
             type an expression is if a number shows up.
  TabAtkins: If I wasn't writing spec text I wouldn't have suggested
             this.

  fremy: Edge does not support percentage in opacity. This is the
         first time I heard you can. I would be fine saying
         percentage doesn't mix with numbers.
  <AmeliaBR> percentage for opacity was a relatively recent addition
             to the spec
  TabAtkins: No one, even browsers that allow percentages, don't
             allow them to mix in calc. Everyone is consistent in
             not allowing this, I want to fix the spec.
  astearns: By not allowing we're matching impl.
  TabAtkins: Yeah.
  dbaron: Some of that is because we don't have a spec for calc()
          unit algebra.
  TabAtkins: It's a lack of support not a positive we're doing this
             on purpose thing. But removing it won't cause problems.
  astearns: Objections to codifying this limitation?

  RESOLVED: Accept proposal

FPWD as a dependency for [css-contain]
--------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1374

  Florian: We resolved to take contain to CR, but overflow was not
           fpwd so it was rejected. Most of the references from
           contain to overflow go to 3 now that we cleaned it. 4
           references are about fragmentation. Given that this is
           least stable, should we change which spec has that text
           so we don't depend on overflow 4?
  fantasai: sgtm
  astearns: It will get contain through the pipeline more quickly.
  astearns: Objections to moving the text for integration between
            contain and overflow to level 4?

  RESOLVED: Move the text for integration between contain and
            overflow to level 4

  astearns: If there's a process issue we can re-resolve, but let's
            use the old resolution

Non-positive value should be invalid for 'resolution' feature
-------------------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1454

  Florian: We found this issue about resolution, but it's more than
           that. There are a number of media features that take a
           range and for which negative value makes no sense.
           Resolution of -300 dpi makes no sense.
  Florian: Old MQ it didn't really matter if we declared this as
           invalid don't parse or value evaluates to false. The
           difference it makes is in the OM. This has changed a bit
           in MQ4 because we have unknown values.
  Florian: If we say it parses and is false there width -300 is
           false NOT width -300 is true.
  Florian: I think it would be more useful to parse it and say it
           evaluates to false. If it doesn't parse we don't know if
           it is -300 or not.
  Florian: We have, from the OM PoV we have interop on the opposite.
           But the boolean logic isn't impl anywhere yet so it's not
           observable.
  Florian: I don't feel like breaking the interop is a major issue,
           but maybe I'm wrong. What do you all think?
  dino: I think we should do as you said and break the interop.
  Florian: If they're relying on media resolution -300dpi this will
           be fine. What this would break is very uncommon.

  dbaron: Does the effect of the change...is it different on if the
          browser impl the unknown thing?
  Florian: Yes. It's part of impl the logic for nested and/or/not.
           If you don't have that then it's undefined what this
           does, I guess.
  dbaron: Maybe the spec should have a note saying that the previous
          version forbade negative values and that shouldn't be
          removed until you impl this stuff.
  Florian: That's fair.

  astearns: Proposal: have the spec say you should parse negative
            values if you implement this boolean stuff. Objections?
  Florian: This is all media features with a range. width, height,
           aspect ratio, color I suppose.
  astearns: Spec should say resolution used to disallow negative
            numbers. It makes sense to allow negative with the
            boolean logic with some examples and that's for all MQ
            with a numeric value.
  dbaron: There should be a note that it's a change from the
          previous version and we're looking for compat feedback.
  Florian: Fair.

  RESOLVED: Spec should say resolution used to disallow negative
            numbers. It makes sense to allow negative with the
            boolean logic with some examples and that's for all MQ
            with a numeric value.

  <AmeliaBR> [Tangent] A reminder that this and many aspects of CSS
             parsing would have been easier define if there were CSS
             Values data types specifically for non-negative or
             strictly-positive values
(https://github.com/w3c/csswg-drafts/issues/355).

Propagation of the :focus pseudo
--------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1240

  Florian: When we introduced :focus-within we tried to clarify
           focus and active. What we attempted was to say active and
           focus propagate to/from the same time. The spec prose for
           that isn't very good. I think I authored that, sorry. It
           also contradicts HTML.
  Florian: I think we should clarify we do what HTML does.
  Florian: Secondary, I think we resolved on a preferred behavior
           which was also in disagreement with HTML. We should
           either try and convince HTML to change their behavior if
           we care about this. For now, we should point to their
           propagation method.

  astearns: Is their method well tested?
  Florian: I think it is. I don't think it was fully interop before.
           IE or Edge didn't used to have it, but there's more
           interop now.
  gregwhitworth: I haven't looked recently, but I thought most still
                 propagates in Edge.
  Florian: I just tried recently and it didn't obviously propagate
           in the general case. I still think it would be better if
           it went both ways. There is an open issue on that in
           WHATWG. I don't say we drop this, but having the
           contradiction isn't useful.
  astearns: So there's an open issue on WHATWG.
  gregwhitworth: Could have sworn I tried to bring that back to
                 CSSWG. It seemed to most of the people in this
                 group felt this want the right behavior. I didn't
                 want people not in the room superseding that. I
                 didn't want to lose that. I can test more throughly.
  Florian: In spirit I agree, but :focus is fairly complex. It's a
           bit of a rabbit hole and I don't think we want to take
           over all of that. If we want some part we need to figure
           out where to split.
  Florian: Looks like we won't resolve, but please look at github.
  <fantasai> testcase:
data:text/html;charset=utf-8;base64,PCFET0NUWVBFIGh0bWw+DQogIDxzdHlsZT4NCiAgICA6Zm9jdXMgeyBiYWNrZ3JvdW5kOiBvcmFuZ2U7fQ0KICA8L3N0eWxlPg0KICA8bGFiZWwgZm9yPXlvPkZvbzwvbGFiZWw+DQogIDxpbnB1dCBpZD15bz4=

  astearns: Can we resolve on removing the contradiction? Or is it
            better to keep it open so the issue gets more :focus?
  Florian: I thought it was better, but gregwhitworth argues that we
           could lose all control.
  gregwhitworth: I hadn't given it too much thought. Can we talk
                 about this in Paris? Or next WG call with everyone
                 on? Other impl were interested before.
  <fantasai> +1 to f2f
  astearns: Seems like bringing this to the F2F is a fair idea. It's
            not that far. Let's do that. I'll put the F2F tag on it.
  astearns: Please do add information to both WHATWG issue and ours
            as you find it.

  astearns: We're at the hour. I think that's it for the day. Thanks
            for making it the different time. We'll try this time
            again the first week in July.
Received on Thursday, 8 June 2017 01:46:02 UTC

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