W3C home > Mailing lists > Public > public-houdini@w3.org > March 2015

Minutes Sydney F2F 2015-02-08 Part I: CSS Parser

From: Dael Jackson <daelcss@gmail.com>
Date: Tue, 3 Mar 2015 14:22:47 -0500
Message-ID: <CADhPm3vTEsyeT5WEon8MNNeRZwqcXEaHQAN7nq4v-_jUm1vw4Q@mail.gmail.com>
To: public-houdini@w3.org
CSS Parser

  - There was conversation about both exposing and extending the
  - Concern was expressed that too many additions to or too much
        exposure of the parser would create performance implications.
  - Due to the complications from Selectors, the parser will likely
        only be able to return tokens, but several options for
        handling custom selectors were also discussed.
  - RESOLVED: TabAtkins, Shane, glazou and bkardell to start work on
              CSS Parser document

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

  Rossen Atanassov
  Tab Atkins
  David Baron
  Rick Byers
  Daniel Glazman
  Dean Jackson
  Brian Kardell (on phone)
  Toru Kawakubo
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Robert O'Callahan
  Xidorn Quan
  Fran├žois Remy (on IRC)
  Simon Sapin
  Dirk Schulze
  Elliott Sprehn
  Alan Stearns
  Shane Stephens
  Ojan Vafai
  Jet Villegas
  Greg Whitworth
  Johannes Wilm
  Steve Zilles

  Agenda: https://wiki.css-houdini.org/planning/sydney-2015?&#actual-agenda

  Scribe: roc

  Rossen: Yesterday we had introductions. Today we get to do magic
  Rossen: Introducing Elliot Sprehn, krit Schultze, Jet Villegas
  esprehn: [introduces himself]
  krit: [introduces himself]
  Jet: [introduces himself]

CSS Parser

  Rossen: Let's start with parsing.
  Rossen: To recap: we did agree on a scope and charter for the WG...
          Pretty much anything goes at this point?

  krit: When does the CSSWG join Houdini?
  Rossen: Yesterday we discussed box tree. Agreed on an initial set
          of editors. Recorded a resolution to start working on a
          draft. Shane checked in the first version of a draft.
  Shane: There's not much in there.
  Rossen: That went well yesterday. Let's figure out the set of
          people interested in extending the CSS parser and figure
          out the scope of that module.

  Rossen: glazou, please start
  [glazou goes to whiteboard]
  glazou: Currently people do quirky things with regexps and
          homemade parsers that are partial and have lots of
          problems and bugs with character sets and everything.
  glazou: It feels wrong to re-implement when the browser has a
  glazou: Concrete example: my own tool. I all the time have to
          parse selectors, rules, values, unknown properties,
          complete stylesheets,
  glazou: Can't use browser to preserve unknown properties and
  glazou: Complex backgrounds and gradients are the worst.
  glazou: Often have to parse, modify one single value, and
  glazou: Need a CSS.parser API

  roc: So this is about exposing the parser, not extending the
  glazou: Right.
  SteveZ: Two things: callback on error; send a string to the parser
          with some context information and get back some table or
  glazou: We need to expose structures for selectors, values etc.
  glazou: CSSOM exists for values but it's bad. Selectors are not
          exposed at all.
  glazou: These things are built into every browser and we should be
          able to use that.
  glazou: [writes "CSS.parser; internal representation" ...
          "Selectors; updated CSSValue"]
  glazou: A lot of complex values like gradients are not exposed
          through CSSValue. Accessing one color of a color stop is a
          real pain.
  glazou: A few bits we miss from the OM... a CSSText attribute on
          rules, but not stylesheets. Another paint.
  Rossen: That's a very common ask.
  glazou: If you tweak one style rule and you want to reserialize
           everything, you cannot do that by querying the CSSText on
           the stylesheet. Rendering engine has all the machinery
           but we can't get it.
  glazou: [writes "OM consistency"]

  Jet: Would you expect CSS variables to be evaluated before parsing
       or after?
  glazou: We can even forbid variables if you like.
  glazou: Restrictions on this are perfectly understandable and
  plinss: I would not expect variables to resolved at this point.
  TabAtkins: At parse time they're just a list of tokens.
  SimonSapin: Maybe extrapolating variables could be a separate step
              from parsing.
  glazou: Sure.

  glazou: Steve, I agree about the callbacks. That's a very good
  glazou: You can understand it in different ways. You want a
          callback on errors, or when somethings unrecognized in the
  glazou: I know that throwing away unrecognized stuff is a useful
          restriction in browsers, but it's a problem for editors.
  ChrisL: You could parse everything, optionally stores everything,
          and then optionally throws away everything it doesn't
  ChrisL: Seems cleaner to mark things as dirty and then throw them
  glazou: Like syntax highlighters.
  TabAtkins: CSS syntax does no validation. expects a later phase to
             throw things away.
  Rossen: Either use the parser as an evaluator, or use it to parse
          the current style sheet?
  glazou: What is interesting to me (just my projects) is getting
          the parsed representation of what I pass as an argument:
          stylesheet, rule, declaration or value
  glazou: Then tweak one single token and reserialize it.

  Shane: Is performance an issue here? It sounds a bit slow. Is this
         going to impact browser's evaluate paths?
  glazou: Don't we have exactly the same problem as queryselector?
  glazou: querySelector has the same issue.
  Rossen: So does @supports.
  Shane: If you take an entire stylesheet, tweak and reserialize it
         might not perform well.
  glazou: It's a non-issue because you're in an editor where
          performance is less of an issue because the user hit the
          save button or did an action with an input event.
  glazou: The only case where it's an issue is when you're in an
          animation editor and you change a stop, but we're already
          doing it with good performance in JS so it's not an issue
          with native code.
  shane: Just exposing a JS implementation with Web Animations can
         avoid string conversion cost.
  shane: Should we do this?
  glazou: Sure.
  TabAtkins: react.js bypassing CSS would be helped by ability to
             throw a CSS object at the DOM,
  TabAtkins: And style an element.

  glazou: A few other areas: CSS extensions to the parser.
  glazou: Being able to declare a new pseudo class, a new
          combinator, whatever.
  glazou: A few things in the OM would like to see fixed: all the
          insertion methods rely on indexes, this is seriously
  glazou: We need to insert a rule before/after a given rule.
  glazou: We check many websites are doing editing, all computing
          the indexes of rules all the time.
  glazou: It feels like 1995.
  glazou: How do we do this given the current OM?
  glazou: Given the compat issues? Do we need another one? Can we
          improve this one?
  <bkardell> Improving existing seems unlikely.
  <bkardell> I am with glazou here, proposed this myself 3-4 years
  TabAtkins: I have ideas, however they depend on value objects in
             JS, hopefully they'll show up soon.

  glazou: [points at Selectors/CSS Values]
  Rossen: Those are next on the agenda
  glazou: Selectors are not too complicated. There will be
          discussions about making them performant.
  glazou: I'm perfectly willing to edit a proposal. I can dedicate a
          lot of time to that. I will dogfood it, I miss it.
  rbyers: This all sounds super exciting. TAG wants us to not just
          make CSS extensible, but explain it.
  rbyers: We can't write an alternate CSS parser.
  TabAtkins: You can fetch, parse, reserialize.

  <franremy> Rossen: sorry, but where's the *ordered* agenda for
             today to be found? can't stay for the whole thing,
             would like to schedule my sleep time?
  <shane> franremy: updated here:

  glazou: I had STTS ... a CSS-like language
  glazou: These properties change the tree
  rbyers: Would this parser API help with that?
  glazou: Yes. We have to decide whether to return just a set of
          tokens or more than that?
  glazou: If I can only get partial things I'll live with that.
  glazou: Some areas of the browser are considered to be moved from
          CSS to JS.
  glazou: We've seriously discussed moving all editing from C++ to
  glazou: In Gecko most HTML editing rules could be exported to JS.
  <bkardell> Rework has something, not great, but not bad either.
  <bkardell> It's not so much OM, almost like AST.
  <bkardell> esprima might be a good corollary.

  krit: You already mentioned the parser might return tokens? Is
        there a way it could return an OM?
  glazou: The problem is for selectors. Their parsing is a bit
  glazou: Dealing with only tokens is complex. You need heuristics
          to figure out selectors.
  glazou: I'd love to have access to both.
  plinss: We should have a low level API to return tokens, and a
          parser that consumes tokens.
  glazou: My code is like that.
  krit: CSS syntax already specifies a tokenizer?
  TabAtkins: Yes.
  plinss: We just need to expose it.
  glazou: It can be an iterator on strings.

  glazou: Who's willing to work on a spec?

  esprehn: All engines have tokenizers, but some engines may not
           build a tree structure (cites V8 as example).
  glazou: This is something extra that we'll build.
  esprehn: Is it just for editors?
  glazou: No, Webapps
  glazou: You will never inject what you've parsed into the engine.
          It's made for consumption by apps.
  dino: You're not talking about extending the parser, just getting
        access to what it's done.
  glazou: I'm interested in both.

  dbaron: I'm having trouble understanding what this API's like.
  dbaron: Parsing depends on context. What's generic between a token
          stream and an object model?
  dbaron: The parser has custom logic to convert from tokens to OM
          that's context sensitive?
  dbaron: You could build a tree that corresponds to the OM, but if
          you put enough information in the tree to validate that
          it's correct syntax, you're back to a token stream.
  dbaron: Validating gradient syntax requires checking parenthesis,
          commas, spaces.
  TabAtkins: The current output of the parsing stage is a function
             object with a token stream argument.
  dbaron: A hierarchical token stream?
  TabAtkins: Yes. Function and block structure and that's it.
  dbaron: Not a whole lot else there.
  glazou: Return value could be a function with a comma-separated
          list of values, each stop a space-separated list of
          values, each a list of one color and one percentage.
  glazou: I'm open to anything.

  TabAtkins: It's a good idea to expose parser/tokenizer
  TabAtkins: The exact shape can be discussed.
  Rossen: We have glazou and TabAtkins so far. SimonSapin, are you
  glazou: You gave me good feedback.
  Simon: definitely interested in reviewing
  <bkardell> I am interested.
  bkardell: Esprima is a similar thing
  bkardell: rework has a nice thing, halfway between AST and OM
  <TabAtkins> ReworkCSS
  <TabAtkins> https://github.com/reworkcss/rework
  <shane> We didn't capture Tab's resolution btw

  glazou: Is extensions to the parser now?
  Rossen: Yes.
  glazou: First thing that comes to mind is psuedo classes.
  glazou: You need very little context, it replies with just a
          boolean, so it's quite easily extensible.
  glazou: TabAtkins wants a declarative way.
  TabAtkins: I want both.
  glazou: I would prefer a link between a JS function and a CSS
  glazou: actionscripts.
  glazou: I wanted to preserve the ability to disable JS and CSS.
          Seems so long ago.
  glazou: It's so easy to write function foo() of one argument that
          returns boolean.
  TabAtkins: The current proposal is just an alias. Most custom
             selectors like JQuery can be declarative.
  glazou: I don't think we need two solutions.

  dbaron: Are you talking about a function that takes an element and
          returns a boolean or about a way to add/remove elements
          from a set?
  TabAtkins: A way to turn one selector into another in JS.
  TabAtkins: I'm lying about that.
  TabAtkins: The current approach is a boolean function.
  TabAtkins: A base selector to limit which elements are applicable,
  TabAtkins: Run that function on a bunch of elements,
  TabAtkins: Do some caching stuff there.
  roc: You don't want to run user JS that accesses the DOM during
       selector matching.
  roc: It's not just performance; safety issues.
  TabAtkins: HitchJS polyfill works OK.
  <bkardell> https://www.irccloud.com/pastebin/WtJrSusx
  roc: The browser might want to selector matching when it's not
       safe to run user JS.

  shane: I was just going to say there might be other ways of doing
         script for custom selectors.
  shane: That wouldn't require you to run JS inside selector
  shane: You might need a pre-match call.
  esprehn: If you're just adding an element to a set, how is this
           different to a class?
  dbaron: Mostly it's not, it might be that something doesn't want
          to expose that set to other parts of code?
  TabAtkins: Simple declarative is better than a class, it handles
             mutations for you.
  shane: The set changes.

  esprehn: When would this be useful?
  TabAtkins: jquery has custom pseudoclasses that it accepts.
  TabAtkins: :heading
  TabAtkins: :input
  TabAtkins: These simple things are really useful.
  TabAtkins: Brian's being working on this in Hitch
  <bkardell> We did an examination of this, jquery had like more
             than a dozen, most of which are simple aliases.
  <bkardell> Custom things are better for standards in a lot of
             cases too - prototype your solution, let's use and
             evaluate it.
  glazou: It's good for prototyping polyfilling.
  <franremy> (something to think about: if selectors are extensible,
             there's a huge conflict risk -- jQuery first tries to
             give a selector to the native engine, we may have
             conflicting meaning for selectors)

  dino: I wanted to reemphasize what roc said: running JS code for
        selector matching will be a performance hit.
  dino: I prefer declarative way
  esprehn: We have a sophisticated invalidation system. We
           potentially will have to invalidate all custom selectors.
  TabAtkins: With the current API shape, we have a base selector to
             tell you what it cares about.
  TabAtkins: We'll see if it's good enough.
  glazou: Extending parser is in Tab's specs. Where are extensions
          physically in the stylesheets? Always before everything?
  glazou: We need JS API to achieve the same thing.
  glazou: We need to discuss interactions with variables.
  Rossen: Everything should be on the table.
  TabAtkins: Informal namespacing works pretty well.
  TabAtkins: We can introduce namespaces later if we need to.
  <franremy> re TabAtkins: so, with "--" prefix to avoid conflict
             with native and not like jQuery, right?
  <TabAtkins> Yeah.
  <franremy> ok, that was my concern;

  Rossen: Anything more?
  glazou: One special beast: pseudo elements
  glazou/Simon: The definition of pseudo elements is the issue.

  Rossen: Anything more for the parser discussion?
  dino: Could do a lot of parser extensions through declarative API
        --- CSS variables-like aliasing/psuedoclasses.
  dino: Possibly that's not what glazou needs.
  glazou: Not just for myself only.
  Rossen: For the resolution: who are the final editors? glazou,
          TabAtkins, Shane?
  Rossen: Any objections?

  RESOLVED: TabAtkins, Shane, glazou and bkardell to start work on
            CSS Parser document

  <dbaron> It might be good to call it "CSS Parser API" to make it a
           little more distinct from CSS Syntax...
  <SimonSapin> dbaron +1
Received on Tuesday, 3 March 2015 19:23:15 UTC

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