- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 3 Mar 2015 14:22:47 -0500
- To: public-houdini@w3.org
CSS Parser
----------
- There was conversation about both exposing and extending the
parser.
- 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 =======
Present:
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
tricks.
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
parser.
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
values,
glazou: Complex backgrounds and gradients are the worst.
glazou: Often have to parse, modify one single value, and
regenerate.
glazou: Need a CSS.parser API
roc: So this is about exposing the parser, not extending the
parser?
glazou: Right.
SteveZ: Two things: callback on error; send a string to the parser
with some context information and get back some table or
something.
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
acceptable.
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
idea.
glazou: You can understand it in different ways. You want a
callback on errors, or when somethings unrecognized in the
OM.
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
understand.
ChrisL: Seems cleaner to mark things as dirty and then throw them
out.
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
broken.
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
back.
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:
https://wiki.css-houdini.org/planning/sydney-2015?&#actual-agenda
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
JS.
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
peculiar.
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
interested?
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
declaration.
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
matching.
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