W3C home > Mailing lists > Public > www-style@w3.org > March 2019

[CSSWG] Minutes San Francisco F2F 2019-02-25 Part I: CSS Values, MathML Summary, WPTest Center, CSS Color, CSS Pseudo Elements [css-values] [css-color] [css-pseudo]

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 26 Mar 2019 22:27:05 +0300
Message-ID: <CADhPm3vXHdTn_cirj3ScZ9F3pgC8zTVVhSUDusqH1z6oGF=_fg@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 Values

  - RESOLVED: We will use the bracket range notation (Issue #355:
              Define value syntax that limits <integer>, <number>,
              <length>, etc. to ranges)
  - Flag against the issue all specs that need to have their grammar
      updated and authors can remove the flag once they have made the
  - Bikeshed might need an update to correctly parse the new syntax.

MathML summary

  - There is a new community group called MathML Refresh that is
      working on rewriting the MathML spec. It's starting to surface
      questions and issues for the CSSWG in github and those
      interested in Layout should take a look.

WPTest Center

  - TabAtkins did a demo on http://wptest.center/ and how it can help
      the group in writing tests.

CSS Color

  - RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements

  - RESOLVED: pseudo() must always return the same object. Note that
              object can be GC'd if this is unobservable. (Issue
              #3607: Identity of Element.pseudo() return value)


Agenda: https://wiki.csswg.org/planning/sf-2019

  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  Amelia Bellamy-Royds, Invited Expert
  Tantek Çelik, Mozilla
  Emilio Cobos, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, JS Foundation (phone)
  Ian Kilpatrick, Google
  Rune Lillesveen, Google
  Chris Lilley, W3C (phone)
  Cameron McCormack, Mozilla
  Theresa O'Connor, Apeoplee
  François Remy, IDLAB
  Manuel Rego, Igalia
  Florian Rivoal, Invited Expert
  Hiroshi Sakakibara, BPS(Beyond Perspective Solutions)
  Jen Simmons, Mozilla
  Hyojin Song, LG Electronics
  Alan Stearns, Adobe
  Morten Stenshorne, Google
  Greg Whitworth, Microsoft
  Fuqiao Xue, W3C

Scribe: gregwhitworth

CSS Values

Adding min/max constraints
  github: https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

  AmeliaBR: Currently we have something like <length-percent> and in
            the prose it says negative values are invalid
  AmeliaBR: The idea is to get that into the actual syntax grammar
  AmeliaBR: Especially with various houdini APIs we're providing
            authors with access to the syntax
  AmeliaBR: The issue is to discuss what this syntax looks like
  AmeliaBR: My proposal was to look like something like sgml
            attributes, we're using angle brackets for data types
  AmeliaBR: fantasai concern is that that can get verbose
  AmeliaBR: If you go down to the second to last issue I have the
            different options with 4 real world examples
  AmeliaBR: Any pros/cons - I've listed mine but would like to hear
            people's feedback
  fantasai: I like my proposal
  fantasai: I really don't want to make things too verbose, the more
            the grammar has to wrap lines the harder it is to read
  fantasai: I prefer the more human readable version
  <astearns> https://github.com/w3c/csswg-drafts/issues/355#issuecomment-458324757

  [TabAtkins shows options on screen]
  [TabAtkins explains the various proposals in the link above]
  fantasai: A minimum in human readable could be 0+

  TabAtkins: I'm most a fan of the bracket range syntax
  fantasai: If you're going to use multipliers, it uses similar syntax,
            so anyone reading the grammar already needs to learn the
  TabAtkins: This is already in the syntax
  TabAtkins: I agree with the idea in general
  TabAtkins: I agree with AmeliaBR that with Houdini we need to
             provide access to this

  heycam: A non syntax question
  heycam: When we have prose that restricts these values, when we have
          calc expressions, when we have negative inside the calc -
          would a change to this syntax make some values invalid
  TabAtkins: This shouldn't change anything this is just moving the
             prose into the grammar
  TabAtkins: calcs() are still valid and clamp to the range
  heycam: If you have a property number 1-1000
  heycam: and you use any calc inside that
  TabAtkins: Yep, that should work

  astearns: Does anyone have any objections to bracket notation
  astearns: I would prefer to have explicit rather than empty
  TabAtkins: What about writing infinity rather than the symbol
  fantasai: No, too long
  iank: Are we allowing the word infinity?
  iank: I'm biased to the Javascript
  TabAtkins: What about both?
  iank: I'm fine with both
  AmeliaBR: That sounds the best for me
  AmeliaBR: The infinity symbol is nice in a spec but not necessarily
            for typing in code
  <myles> +1 to what AmeliaBR said
  heycam: Rather than brackets and commas you can use ..
  heycam: Some languages include two dots others use three dots
  <astearns> ∞ in the grammar is the start of a slippery slope to
             writing css specs exclusively in emoji
  gregwhitworth: I would prefer no on that
  AmeliaBR: As fantasai noted the brackets are known in CSS in the
  iank: Also the ... may get confused with the destructioring in JS
  TabAtkins: We will go with the bracket version and allow Infinity
             and the infinity symbol
  TabAtkins: I would never propose the infinity symbol for CSS itself,
             this is for syntax

  florian: Bikeshed feature request, convert infinity word to symbol

  fantasai: There is an infinity code and ampersand version
  <TabAtkins> &infin;

  fantasai: What's the case sensitivity of the infinity keyword?
  TabAtkins: In JS it's Infinity
  fantasai: As a string?
  TabAtkins: it would be <number [1, Infinity]>

  <AmeliaBR> Proposal: Use the bracket range notation (from the
             issue), but with infinite ranges (no max/min) represented
             by either `Infinity` or &infin; (or negative thereof)
  AmeliaBR: It's not a string it's a token within the syntax

  fantasai: Question, is our syntax types case sensitive
  TabAtkins: The Houdini syntax cares
  fantasai: Yeah we're consistent in our specs but I was curious
  <TabAtkins> `syntax: "big | BIGGER"` in registerProperty() is
              already case-sensitive
  astearns: Any objections to the proposal

  RESOLVED: We will use the bracket range notation

Go through the specs and update the grammar

  AmeliaBR: I can maybe do some PM on that, but I'm hoping the spec
            editors will do some work
  <myles> I can do fonts
  <chris> I can do color
  heycam: Does that require Bikeshed changes?
  TabAtkins: No
  TabAtkins: We can tag the specs that need the changes and then untag
             as you make the changes
  astearns: If you could please make sure that they all get changed

  florian: Do we do that for specs that are RECs?
  TabAtkins: Do it to the ED and wait for it to get to rec - it's an
             editorial change
  <fantasai> We need to push out the changes to css-values-3 first

  <chris> did people hear? I asked that Rec changes get propagated to
  [working on getting chris audio]
  astearns: Unless there's a really good reason to do that extra work,
            I would prefer not to [in relation to chris's question]
  <chris> I'm not sure why not update the errata
  <chris> it's much less than making a new Rec
  astearns: I'm just looking at it as make work, this isn't adding
            anything to the Recs it's just a shortcut
  <chris> ok in his case, yes, no normative change

MathML summary

  rego: This is a quick point - we were talking with Google about the
        state of things
  rego: Wanted to make everyone aware
  rego: There has been work to update the spec and align closer to how
        the browser works
  rego: There is a new CG called MathML Refresh to write a new spec
        that focuses on what browsers do
  <rego> BTW some related links
  rego: Basically they are starting to move this to a Github repo
  rego: There is a MathML core there to implement in Webkit
  rego: This was planned to be implemented in Chromium but we need to
        clarify some issues with CSS, etc
  rego: There are WPT tests and we'll be creating more tests and
        porting the ones from webkit
  rego: There are some new CSS proposals, but just in case someone is
        interested in it to go take a look
  rego: That's mostly all of it, Igalia has begun implementing MathML
        in LayoutNG in collaboration with Google. It's currently in a
        private Igalia fork
  rego: Let me know if you have any questions
  <gsnedders> there's a whole load of tests for the MathML subset
              Opera supported in the old presto-testo repo, though I
              don't know if they're very useful (they probably aren't
              reftests :()

  TabAtkins: These CSS proposals, they haven't showed up in the group
             at all?
  rego: No - people are just starting to talk about it, if people are
        interested they can take a look
  TabAtkins: Can you open an issue to link to the ideas so that we can
             go look at them?
  astearns: I was going to say similar, as things get further along it
            would be good to bring them here
  iank: I'm going through and filing some core issues with MathML
        today and tomorrow, how should margin collapsing work in
        MathML? Because there is currently no interop, etc
  iank: Those that know layout and have opinions should probably chime
  rego: That's all

  dauwhe: How is the quality of the current MathML spec
  dauwhe: Had to look at it and it's written in this older style that
          is hard to follow
  rego: The meaning of the group is meant to work on that, I can't
        necessarily speak to the quality of the spec
  rego: You can implement in many different ways, the spec didn't
        necessarily define how to implement things
  <bkardell> I believe one task the group wants to do is also spec it
             out more like the newer HTML specs
  dauwhe: Are they considering splitting out the presentational markup
          from the content markup?
  <bkardell> yes that is my understanding
  <bkardell> to what dauwhe said
  bkardell: One task group wants to do things like newer HTML specs
  TabAtkins: Yeah, that's what they're currently doing
  dauwhe: That's good to hear
  dauwhe: afaik semantic MathML is only used in XML  toolchains,
          is not exposed to the Web

WPTest Center

  TabAtkins: A little while ago fremy gave a presentation about
  TabAtkins: I've been using it to write the CSS syntax tests from the
             past 5 years
  [TabAtkins shows a demo on how to do this]
  TabAtkins: Syntax tools are almost all in JS
  <bkardell> this is awesome
  <chris> is there a way to add reftests?
  <bkardell> was just asking someone about this
  <astearns> no reftests from this tool
  <bkardell> thank you astearns
  <chris> I like that this lowers friction for a quick test
  fremy: It's primarily to help unblock the CR so people can quickly
         submit a test
  astearns: I was going to encourage everyone to take a look and try
            it out
  astearns: and we need to be writing more of these tests, maybe the
            ease of this will be nice to add a reftest for this
  astearns: It's OSS so it may be nice to add a file picker to add a
  TabAtkins: You don't have to deal with the repo
  astearns: We are still waiting on hearing from external people

[20 min break]

CSS Color
  Scribe: fantasai

Updated WD of css-color-4

  chris: Hello everyone!
  chris: Quick request to update Color
  chris: Someone was saying "oh, there haven't been changes since
         2016" and I realized they were looking at /TR
  chris: Over weekend I made a list of changes
  chris: Lots of issues still open, but just asking for updated WD
  <AmeliaBR> https://drafts.csswg.org/css-color-4/#changes-from-20160705

  fantasai: Any changes in scope?
  chris: No just improvements to what's there
  chris: Actually, one change in scope, removed color modification
  chris: It was problematic and people weren't happy with it
  chris: We need functionality like that, but not that particular thing
  chris: Became an issue that people were trying to implement what was
         on /TR and we didn't want that implemented

  astearns: any objections to publishing?
  <florian> +1 to publication

  RESOLVED: Updated WD of css-color-4

CSS Pseudo Elements

Identity of Element.pseudo() return value
  github: https://github.com/w3c/csswg-drafts/issues/3607

  heycam: Last time we discussed this on a call, I was suggesting that
          the pseudo() function which returns a CSSPseudoElement object
  heycam: should always return the same object regardless of what
          values content has
  heycam: just so that we don't have to rely on what the current style
          state is to know when these objects should be dropped and
  heycam: It felt a little strange at the time
  heycam: One thing that might argue against returning same object is
          if we have an API in the future that can create from script
          one of these objects and insert it into the tree
  heycam: Might be problematic to have stable object identity created
          for style, vs created from script
  heycam: But that's similar to what we do for @font-face

  TabAtkins: If you re-parse the style sheet, we'll create new objects
  myles: Actually, I spent a week of my time making that not true.
  TabAtkins: Can you open an issue on not doing that?
  myles: I originally wanted to do the thing you said
  myles: It was brought to my attention that it was very common in JS
         that authors would tack on properties to random objects
  myles: so you can't just delete and recreate them
  futhark: For Blink implementation, we used to recreate the
           pseudo-element internally when content changed, but we
           don't do that anymore
  futhark: When content property changes, we regenerate ... but the
           object stays the same
  emilio: But you still regenerate when you switch content property to
          none and back again, right?
  TabAtkins: If you turn content to none and then ask for the pseudo,
             you do return an object that you can return style on
  futhark: Are you talking about the pseudo() method or gCS()
  TabAtkins: pseudo()
  futhark: We don't implement it

  emilio: Do we want to keep them lightweight objects or do we add
  emilio: If we add .style we need to keep the ? around anyway
  fantasai: Currently we've dropped .style from the spec
  TabAtkins: Wait, we dropped .style?
  heycam: We kept .type and .element and it's an event target
  TabAtkins: OK
  emilio: If you add some stateful thing that we don't want to
          disappear randomly, then keeping object itself around is not
          a huge deal because you need to keep that info around
  emilio: but if not, then recreating it would be better
  TabAtkins: I think it should have .style
  TabAtkins: later
  TabAtkins: Because pseudos act like DOM elements, they fill a
             similar purpose
  TabAtkins: Having object identity work it's nice
  TabAtkins: Without that it's more annoying
  TabAtkins: ...

  TabAtkins: Myles's argument about FontFace objects suggests that
             they should stay around on these objects, too.
  myles: I don't know how applicable that argument is to pseudos
  dbaron: I think one other comment about expandos is that CSSOM
          objects are historically one of the objects where expandos
          don't stay around
  dbaron: They stay around in lots of places, but not in CSSOM objects
  TabAtkins: Is it just font face objects that are connected, or
  myles: Font face rules will change... I don't remember.
  <AmeliaBR> https://developer.mozilla.org/en-US/docs/Glossary/Expando
             "Expando properties are properties added to DOM nodes
             with JavaScript, where those properties are not part of
             the object's DOM specification"
  <AmeliaBR> in case anyone else hadn't heard that JS jargon before...

  florian: Another argument in favor of long-lived is if they're not,
           we need to specify in detail what their lifecycles are
  florian: And if we don't we'll expose a lot of implementation details
  florian: Do you regenerate on content property changing from one
           string to another? Flip to none and back? a display : none
  florian: etc.
  TabAtkins: If we just make the element have a weak ref to its
             pseudo, then expandos let you observe GC.
  TabAtkins: Need to be either long-lived or regenerated on every call
  myles: Most important part is that right now it's undefined when the
         CSS engine decides to reparse rules or recreate derived
  myles: That's pretty important for optimization
  myles: so tying JS-visible semantics to that schedule would be scary
  myles: Instead we should define something more rigorous

  dbaron: Why is your GC idea not viable?
  TabAtkins: It allows you to detect when GC happens by seeing how
             long the expando survives
  dbaron: Traditional way around that is that the expando makes it not
  TabAtkins: OK. My idea was to just hold it as a weak ref
  dbaron: I think your weak ref idea is workable if we make expandos
          not collectible.
  myles: It's true in our engine also
  TabAtkins: If that's the case, then all the exposed possibilities
             for GC are handled if expando force a strong reference
  TabAtkins: Incompatible with .style

  fantasai: One concern was about keeping around a lot of memory if
            you iterate the entire tree
  fantasai: If the pseudo doesn't generate a box, you return null, but
            as soon as you generate a box you generate the object and
            keep it around
  emilio: That's also incompatible with making that API work with
          stuff like selection
  emilio: For ::first-line ::first-letter, fine, but won't work for
          some other stuff
  TabAtkins: I think returning null is OK only for things that don't
             exist, like the name is invalid
  <fremy> +1
  fantasai: Shouldn't that throw an error?
  TabAtkins: No
  astearns: We already talked about that

  florian: How long-lived is it?
  heycam: So we always return the same object, and it's kinda like
          it's connected to the element you call it on
  TabAtkins: You're allowed to drop the object if doing so is
  TabAtkins: e.g if no expando, no references, can drop it and
             recreate it
  TabAtkins: I guess you can't observe object identity without a

  smfr: Same object in IDL?
  TabAtkins: That's advisory in the IDL. Have to say in algorithm what
  myles: Can we make another IDL attribute that means "for real"? :)
  heycam: What it means for a particular API is not particularly
          clear, so need to say in the prose what type of object and
  myles: So it means nothing
  heycam: It's a hint to the JS engine, that's all.
  florian: There's a hint to the spec reader that there's some prose
           somewhere that matters?
  TabAtkins: Yes

  astearns: So afaict, the proposed resolution is that pseudo() will
            return the same object always
  astearns: and we will have text suggesting that this can be GC if
            that is unobservable
  <TabAtkins> Proposed Resolution: pseudo() must always return the
              same object (up to observability)
  <TabAtkins> "same object" for a given element/pseudo pair
  astearns: Objections/concerns?

  RESOLVED: pseudo() must always return the same object. Note that
            object can be GC'd if this is unobservable.
Received on Tuesday, 26 March 2019 19:27:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:53:13 UTC