- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 16 Jan 2019 19:47:45 -0500
- 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.
=========================================
Upcoming F2F
------------
- The group affirmed that Houdini Task Force didn't need a separate
day to meet.
More WPT reviewers needed
-------------------------
- There are many tests that have been submitted, but not reviewed.
This frustration is shared by several people, but no solution
was immediately forthcoming.
- Some people expressed that if they are needed to review an email
prompt may be more effective then a github mention.
Snapshot 2018
-------------
- RESOLVED: Add CSS Transforms to the 2018 Snapshot
- RESOLVED: Move Grid from stable to rough interop in 2018 Snapshot
- RESOLVED: Once these edits have been completed republish 2018
Snapshot
CSS Pseudo
----------
- The resolution to Issue #2850 (How should a selected spelling
error be painted?) is related to the decision on cascading /
inheritance model for ::selection (Issue #2474) so that will be
reviewed further to see if it helps in reaching a resolution.
- RESOLVED: Add a .element property that brings pseudos back to
their element (Issue #2816)
- RESOLVED: Make all the types include the :: prefix for consistency
(Issue #2815)
- RESOLVED: Rename letter and line to ::first-letter and
::first-line (Issue #2815)
- RESOLVED: Accept and add the :placeholder-select pseudo class and
add a note for ::placeholder that we're interested in
working on it (Issue #2517)
- RESOLVED: Add stroke-color, stroke-width, fill-color and
paint-order (Issue #2362)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Jan/0003.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Emilio Cobos Álvarez
Dave Cramer
Benjamin De Cock
Elika Etemad
Simon Fraser
Dael Jackson
Peter Linss
Nigel Megitt
Michael Miller
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Greg Whitworth
Scribe: dael
Upcoming F2F
============
Rossen: Let's go ahead and get started
Rossen: Welcome. As usual, the first item is a call for additional
items or changes you would like made to the agenda
Rossen: I did have one F2F question.
Rossen: Thanks to those who added themselves to the wiki. If you
haven't done so, please do. It will give organizers an idea
of who is coming. It also gives you a chance to add items to
the agenda if they're not tagged in github
Rossen: Question I had was, we had decided there would be no
separate Houdini date. That was decided during TPAC.
Rossen: I wanted to do an additional check to make sure this hasn't
changed. Still good with that?
TabAtkins: No intention of doing it. I thought we'd do a separate
track for Houdini during something like Text if it's
necessary. We do not have enough topics to warrant a full
day.
More WPT reviewers needed
=========================
github: https://github.com/w3c/csswg-drafts/issues/3496
ericwilligers: I wanted to bring attention, there are a few specs
with essentially no reviewers. Some people may be
listed but don't check their review emails.
ericwilligers: It would be helpful if more people volunteered. I can
get Blink people to review, but that's not available
to everyone. More people should be able to submit
tests without going through a browser
Rossen: In general we've had this discussion many times in the past.
Both tests and test reviewers have been a struggle to come
about.
Rossen: Was there anything you were doing to gather external
contributions?
ericwilligers: No. This is tests I wrote that I thought it
unfortunate no one is reviewing
gsnedders: It's notable that CSSWG specs are much harder to get
review than any other spec. People who work on layout
aren't interacting with wpt the way other groups are. Be
interested to know reasons
chris: I've tried to review tests. I share ericwilligers
frustration. I'll submit tests and they sit
dbaron: I review tests when I have time, but I think it may be more
useful to bug individuals then bug the whole WG for reviews
ericwilligers: I specify a person and nothing happened
dbaron: Some of us have hundreds of things in github queues. If you
want me to review something, send an email
ericwilligers: That's all for this issue, thanks
Rossen: Thank you for bringing it to attention again. For us to be
successful as a WG and making sure standards are pushed
through, tests are a huge part. If anyone submits tests,
please be accommodating. I'm bad at following all repo build
up, but I try and respond to direct emails
Rossen: Let's see if we can drain that queue
<tantek> Last time this topic came up, the larger problem of WPT
being poorly documented (processes etc.) was the key
takeaway
<tantek> pretty sure there was an issue filed too
<gsnedders> tantek: that doesn't explain the disparity between CSS
and pretty much every other group, though
<dbaron> gsnedders, There may be issues with difficulty of mapping
tests to engineering areas, and also things specific to not
liking the wpt reftest setup
<dbaron> ericwilligers, btw, I think it may be more useful to bring
up specific specs that are short of reviewers or where
they're not responding to both github requests and emails
than to bring up the topic generally
Snapshot 2018
=============
2018 Snapshot Rough Inteorp List
--------------------------------
Rossen: Is fantasai on?
chris: 2018 or 2019? 2018 has been published
Rossen: I'll paste the mail thread
Rossen: It is 2018 unless it was a mistype in the title
<Rossen> https://lists.w3.org/Archives/Member/w3c-css-wg/2018OctDec/0179.html
[note: link is member only]
<astearns> given that it's 2019 now, we should probably be looking
to make changes to 2019
<chris> CSS Snapshot 2018 W3C Working Group Note, 15 November 2018
Rossen: It was 2018 snapshot publication
fantasai: These are on 2018. We didn't put transforms in 2018 and it
seems it should be there
<chris> seems a bit late tbh.
fantasai: Transforms didn't make it because it hit CR right after we
published the snapshot. But spec is stable and there's
implementations and interop there.
fantasai: Second issue was to move grid not in the main line of the
snapshot because spec hasn't been that level of stable.
We'd put it in a note with something like Animations to
say spec isn't quite there.
<AmeliaBR> Transforms Level 1 is still published as a WD, not CR. Is
that a mistake? https://www.w3.org/TR/css3-transforms/
chris: What's point of doing that? We're in 2019 and we had WG
consensus grid would be in
fantasai: We didn't
florian: That was my mistake and I put it in the wrong category
chris: Worth republishing to back it down?
fantasai: epub specs have started to rely on snapshots. We might
want to rethink what snapshot is, but these are specs not
rec but only because there's a few bugs. But they're
almost there.
chris: Grid isn't almost there?
fantasai: If you look at state of spec in 2018 we got a lot of
issues. It'll get there in 2019.
florian: Is it there now?
fantasai: No. There are a bunch of open issues. When they're
resolved and we republish and impl are up to date
chris: I worry about mixed messages. When do we plan to publish 2019?
chris: If we're going to do it in a couple of months not worthwhile.
We ought to be doing 2019 snapshot in spring 2019
fantasai: I'll do the publishing
chris: Adding a note is easy
* chris has made his point and is happy either way
Rossen: Do we want to add CSS transforms and update the 2018
snapshot for those taking dependency on it? The snapshot
will retroactively present a more realistic picture. Or
chris do you object to that?
chris: Not objecting, good either way. Don't want to send mixed
messages or incorrect ones
Rossen: Additional feedback from the group?
nigel: I'd prioritize fixing incorrect statements over inconsistent
messages. Incorrect information is more dangerous
Rossen: That's a +1 for adding it
<tantek> +1 to adding it
Rossen: Anything else?
Rossen: Objections to add CSS Transforms to the 2018 Snapshot?
RESOLVED: Add CSS Transforms to the 2018 Snapshot
Rossen: fantasai back to you, there were more questions
Rossen: Grid. Do we need to make a change?
florian: I screwed up, let's fix it
fantasai: Grid was supposed to be in the bucket of notes about specs
that are widely deployed but not as stable. I understood
grid would be in that category, not the main. I'm asking
to move it into that position
fantasai: We have several specs which are widely deployed but need
more bug fixing. They're listed in a different section
florian: It is what we resolved, I implemented it incorrectly
<tantek> Link to current editor's draft of snapshot?
Rossen: Since we're going to update the snapshot, what is the ask?
You want to move it?
fantasai: From stable to rough interop
Rossen: Feedback from WG on this?
<tantek> I'm not going to nitpick on section. Happy that it's
included
Rossen: Objections to moving Grid from stable to rough interop?
RESOLVED: Move Grid from stable to rough interop in 2018 Snapshot
Rossen: Resolution to republish snapshot?
fantasai: Yes, please
Rossen: One more. Once these edits have been completed republish
2018 snapshot
RESOLVED: Once these edits have been completed republish 2018
Snapshot
CSS Pseudo
==========
How should a selected spelling error be painted?
------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2850
Rossen: fantasai or AmeliaBR can you summarize?
fantasai: Let's see where we're at
florian: I thought semi reviewed and waiting for additional feedback
fantasai: Yeah
<AmeliaBR> I'm not sure there's much more to discuss. Needs proposed
text.
florian: I think agenda+ was left on rather then added
Rossen: Bot didn't resolve?
<dbaron> the bot only removes agenda+ when there's a resolution, btw
Daniel: I had a chance to digest this. We described in terms of
currentColor
Daniel: I wrote a comment, so to restate. currentColor would solve
this and for all color properties, but not for caret and
text shadow
Daniel: In 2.2 of the same spec we solved this for the first-letter
fantasai: first-letter is different kind of pseudo element. It
inherits fundamentally through the tree. What we're doing
for selection, a selection for a span inherits from the p,
not the span. That has to happen for all the different
properties that inherit
Daniel: I read 2.2 and how it's impl in webkit
fantasai: Webkit impl isn't like any other browser
Daniel: I like webkit where you cascade and then inherit
fantasai: The thing currently implemented, if you have selections
like <p>::selection and inside the p you have a span, you
lose the selection over the span
Daniel: Currently in webkit?
fantasai: That's in every other browser
Daniel: That doesn't happen. I could be wrong, but in my memory of
code that's not what happens. For the span...we do the
cascade, find the parent with the section...right now we do
the cascade
Daniel: I would like what webkit does for first letter. It cascades
first and then does inheritance against first line.
<dbaron> I don't know what you mean by "does the cascade" --
cascading what together?
Daniel: If you had some span that has a first-letter and it's inside
a parent with a first-letter inside a parent with a
first-line, you cascade for first-letter and inherit from
cascade result of first-line. That's my interpretation of
section 2.2
<fantasai> testcase has some emphasized text
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?<!DOCTYPE%20html>%0A<style>%0Ap%3A%3Aselection%20%7B%20background%3A%20green%3B%20%7D%0A<%2Fstyle>%0A<p>this%20is%20some%20<em>emphasized%20text<%2Fem>
fantasai: 2.2 just changed
<fantasai> Cascading / inheritance model for ::selection was changed
in https://github.com/w3c/csswg-drafts/issues/2474
florian: The thing fantasai just pasted run in safari agrees with
what fantasai stated about current behavior.
florian: In the spec we're trying to get away from...it's different
then current, but current implementations aren't useful. If
you're trying to style ::selection applied to particular
elements it breaks if they have children. That's why we
want different model
Daniel: One thing; did fantasai post the example? I can explain.
That's broken. I have a patch for webkit. We only do it for
first-letter and first-line. I'm saying why can't we make
selection have same model as first-letter
fantasai: That's a different issue, that's about fundamental
inheritance and cascade for selection. That still is a
thing that needs to be defined
Daniel: I filed this issue because I wanted to solve
fantasai: There is an issue where we're discussing in general. You
can compare the model. One is cascade one is inheritance.
Both are discussed and you can see both in spec. Cascade
is in the TR and inheritance is in the ED
Daniel: I'll read it and comment on it
florian: To add one thing, the one on TR is what was previous and
the new on is in the ED because we objected to doing it the
cascade way
Daniel: Let me read through both and I'll discuss in github
Rossen: Excellent. Thank you for chiming in.
Add CSSPseudoElement.parentElement
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2816
fantasai: This one was filed by birtles and I don't know too much
about the APIs. They have a big red notice saying this was
just an idea. It seems Mozilla is shipping some form of
this API.
fantasai: We should probably put something there
Rossen: Currently suggested API, parent element was suggested and
then pointed out that was not necessarily the best name at
the very least. It's the originating element and fantasai
suggested .element
Rossen: If this is about naming, we can discuss if we want to add
the API. I think adding is warranted
TabAtkins: Agree having the attribute to get back to the real
element is a necessary part. I like .element suggestion
for the name
Rossen: Additional comments?
<florian> sounds good
Rossen: Objections to adding a .element prop that brings pseudos
back to their element?
RESOLVED: Add a .element property that brings pseudos back to their
element
Should CSSPseudoElement.type value include the "::" prefix?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2815
TabAtkins: As birtles points out, in some other APIs which mention a
pseudo element name, they name with :: prefix. We should
defer to them and do the same
<fantasai> https://drafts.csswg.org/css-pseudo-4/#CSSPseudoElement-interface
TabAtkins: Also, spec defines first-letter and first-line and just
letter and line, we should fix that too so they have the
same name
Rossen: Would be wonderful
Rossen: Additional comments?
Rossen: Objections to making all the types include the :: prefix for
consistency?
RESOLVED: Make all the types include the :: prefix for consistency
<fantasai> https://drafts.csswg.org/css-pseudo-4/#cssom
fantasai: While we're on this I'd like to note that entire section
of the spec is 30% red issues. If anyone is shipping that
can they review and if it's what they're shipping we can
remove the issues?
Rossen: Good general idea for anything we're shipping. I support
your call for review
fantasai: Does anyone impl these?
dbaron: Gecko impl something, but I don't know what
fantasai: Can we ask the person who impl to look?
emilio: I think it's preffed for animations, I can check
<dbaron> conditional on a pref related to web animations
Rossen: You don't have to do it real time. Just do it and comment
back.
<gsnedders> fantasai:
https://wpt.fyi/results/css/css-pseudo/idlharness.html?label=master&label=stable&aligned
shows no stable browser having any FWIW
Clarification: do ::placeholder/:placeholder-shown apply to <select>s'
"placeholder label option"?
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2517
Rossen: Opened a while ago, added to agenda after a pass through
issues.
fantasai: In case of a select the placeholder text is an element
rather than an attribute
fantasai: Question is should ::placeholder match that so text inside
can be styled? A little weird because not generating a new
element, but it serves the same function
TabAtkins: Understand the use case and the complaints in the
original post about how difficult this is to match this
with a selector. I get the use case. A little concerns
about compat, I'm betting :placeholder-shown is mostly on
inputs.
TabAtkins: ::placeholder matching is complicated because
inheritence, but we semi have that already
dbaron: Compat question is if people write input:placeholder-shown
or :placeholder-shown
fantasai: And if they want the styling applied to those kinds of
selects
florian: As for the pseudo element it's fuzzy because select is a
replaced element so you can say actual isn't rendered and
it is a pseudo. If that make sense with appearance: none is
an interesting question
TabAtkins: Don't want to get to idea select is entirely replaced.
Doing some level of styling is useful
dbaron: One point of having web components is we can do something
like that
TabAtkins: It would be be most optimal but we could come up with
parallel pseudo class and pseudo element
TabAtkins: Maybe we can just do pseudo class for now since it
applies on the select?
fantasai: Probably solve the issue easiest because
:placeholder-shown makes the placeholder the first child
and you can style it
TabAtkins: True
TabAtkins: While a theoretical other language select would have more
complex, in HTML it's the first child. Don't need an
extra selector. Let's go with that
florian: Does styling of children of selection work?
TabAtkins: Don't remember, but I want to allow it
florian: We can start with that and see
Rossen: Hearing yea for the pseudo class and wait on pseudo? Is that
the proposal?
TabAtkins: I like that the best
Rossen: Additional points?
fantasai: I can add a note in spec for ::placeholder that we're
interested in doing this and looking for feedback
Rossen: Proposal: Accept and add the :placeholder-select pseudo
class and add a note for ::placeholder that we're interested
in working on it
Rossen: Objections?
RESOLVED: Accept and add the :placeholder-select pseudo class and
add a note for ::placeholder that we're interested in
working on it
florian: I tested and if you try and style an option in a select it
doesn't do anything
Rossen: Okay
Rossen: Where did you test? I think we support some of this in Edge
florian: FF and Chrome. Tried to style color
Rossen: Interesting. Okay
Rossen: We'll add the note and continue
<florian> same thing in safari
TabAtkins: florian did you jsut look or open it? When I open it in
chrome options are styled
TabAtkins: I'm red color and bold stuff and non-selected are both.
Selected is bold.
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6514
<TabAtkins> on chromeos
florian: Not here. Maybe OS dependent. It's a native appearance
control
florian: Let's take it offline
Rossen: Same works in Edge
Should CSSPseudoElement.type value include the "::" prefix?
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2815
TabAtkins: Accept issue to rename to first-letter and first-line
Rossen: Objections to renaming letter and line to ::first-letter and
::first-line?
RESOLVED: Rename letter and line to ::first-letter and ::first-line
Add stroke-color and stroke-width to the list of highlight properties
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2362
Rossen: Discussed a number of times. Seems there's some agreement on
the issue
Rossen: chris do you want to take this?
chris: Been a bit of discussion. General consensus on properties.
Suggestion that they're the long hands. Support that
chris: We've pretty much worked out what this effects.
fantasai: I think we'll look for 2 resolutions. 1 to clarify these
are only ink overflow and second is to make them usable
with selection
chris: Agree with first
fantasai: Question about applying all long hands. One limitation we
have here is we don't want anything that will expose
boundaries of box represent element.
chris: But would it? Someone suggested it would but that was fairly
quickly shown to be wrong
fantasai: Then we're fine
Rossen: Proposal is add stroke-color and stroke-width, fill-color
and paint-order? Is that the list?
chris: I think so. It's in the issue
Rossen: I'm reading from issue. Making sure I'm not missing anything.
Rossen: stroke-color, stroke-width, fill-color and paint-order
Rossen: Objections to adding stroke-color, stroke-width, fill-color
and paint-order
RESOLVED: Add stroke-color, stroke-width, fill-color and paint-order
chris: And the suggestion to add the long hands?
fantasai: My understanding from last time is they need to be
properties that can be handled at a high performance
level. Dashing and filter and fill images and these
things...
chris: Dashing has nothing to do with filters or images. It's common
in animations so can't say it's not performance
fantasai: Question is would impl be up to implementing that for
selections
chris: If you look in graphical editors there's marching ants and
I've seen people use stroke-offset and stroke-array to get
that
leaverou: That's commonly done
fantasai: I don't know answer, but I think implementors need to say
yes they're willing to implement
smfr: [missed] I'm okay with dashing here
<smfr> for webkit, dashing has some painting cost, but not serious
enough to justify excluding it from this list
<smfr> I’m ok with dashing here
Rossen: smfr is okay with dashing
chris: Other implementors?
Rossen: I'll take that as a silent no
fantasai: Next question is what about paint servers and tiling
images. Is that something implementors want to do on
selection?
Rossen: Ooph
TabAtkins: That's backgrounds in css
<smfr> don’t want selection to trigger an image load
fantasai: CSS only allows color, not image
leaverou: Are background images not allowed for reason of showing
element boundaries?
TabAtkins: Probably. We got around the issue by only allowing 0
dimensional images, aka colors
chris: I think that's the same for border images
leaverou: I don't think even borders are allowed
fantasai: Right
<AmeliaBR> For stroke/fill images, the boundaries (in SVG, anyway)
are always the boundaries of the full <text>, not the
given span, so it shouldn't be affected by changes in
selection span.
Rossen: So, no on this one? Soft no? To be consistent with previous
soft no or weak maybe?
fantasai: Stroke and fill will be based on geometry of element so
won't expose border. I don't think it's that useful.
Probably better not to do them. If someone wants them in
the future we can add
Rossen: Easier to add than remove.
Rossen: Let's not add for now. There's enough feedback from silence
and pushback that this isn't comfortable at the moment. When
they're more widely used we can see if shorthands are
warranted.
Rossen: Sound good?
chris: Okay
Rossen: That's this issue
<fantasai> I'm noting that you can still specify the shorthands,
we'd just ignore the longhands of it that aren't supported
Rossen: That brings us to top of the hour
Rossen: We couldn't get to text and inline so next week we'll start
with those
Rossen: We'll chat next week.
Received on Thursday, 17 January 2019 00:48:44 UTC