- From: Dael Jackson <daelcss@gmail.com>
- Date: Tue, 26 Mar 2019 22:27:05 +0300
- 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
changes.
- 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)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/sf-2019
Present:
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
pattern.
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
earlier?
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
grammar
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> ∞
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 ∞ (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
errata
[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
https://people.igalia.com/mrego/mathml-refresh-community-group.html
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
in
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
wptest.center
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
reftest
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
function
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
recreated
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
right?
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
.style?
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
[missed]
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
subtree?
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
objects
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
collectible
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
unobservable
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
reference
smfr: Same object in IDL?
TabAtkins: That's advisory in the IDL. Have to say in algorithm what
happens
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
stuff.
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