<Rossen_> trackbot, start meeting

<trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference

<trackbot> Date: 16 January 2019

<scribe> ScribeNick: dael

Rossen_: Let's give it one more minute and we'll start
... Let's go ahead and get started
... Welcome. As usual, the first item is a call for additional items or changes you would like made to the agenda
... I did have one F2F question.
... 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
... Question I had was, we had decided there would be no separate Houdini date. That was decided during TPAC.
... 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.
... 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.
... 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'l 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 spec a person and nothing happened

dbaron: Some of us have hundreds of thigns in github queues. If you want me to review something, send an email

ericwilligers: That's all for this issue, thanks

<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

Rossen_: Than 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 accomodating. I'm bad at following all repo build up, but I try and respond to direct emails

<gsnedders> tantek: that doesn't explain the disparity between CSS and pretty much every other group, though

Rossen_: Let's see if we can drain that queue

2018 Snapshot Rough Inteorp List

Rossen_: Is fantasai on?

<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

chris: 2018 or 2019? 2018 has been published

Rossen_: I'll paste the mail thread
... It is 2018 unless it was a mistype in the title

<Rossen_> https://lists.w3.org/Archives/Member/w3c-css-wg/2018OctDec/0179.html

<astearns> given that it's 2019 now, we should probably be looking to make changes to 2019

[note: link is member only]

<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

<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

<chris> seems a bit late tbh.

fantasai: Transforms didn't make it b/c it hit CR right after we published. But spec is stable and there's impl and interop there.
... 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.

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?

<AmeliaBR> Transforms Level 1 is still published as a WD, not CR. Is that a mistake? https://www.w3.org/TR/css3-transforms/

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?
... If we're going to do it in a couple of months not worthwhile. We ought to be diong 2019 snapshot in spring 2019

fantasai: I'll do the publishing

chris: Adding a note is easy

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 inconsistant messages. Incorrect information is more dangerous

Rossen_: That's a +1 for adding it

<tantek> +1 to adding it

Rossen_: Anything else?
... Obj to add CSS Transforms to the 2018 Snapshot?

RESOLUTION: add CSS Transforms to the 2018 Snapshot

Rossen_: fantasai back to you, there were more questions
... 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

<tantek> FWIW I am for including Grid since it has usable implementation interop, and to make that clear, despite any spec thrash

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_: Obj to moving Grid from stable to rough interop?

RESOLUTION: 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

RESOLUTION: Once these edits have been completed republish 2018 snapshot

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
... I wrote a comment, so to restate. currentColor would solve this and for all color properties, but not for caret and text shadow
... In 2.2 of the same spec we solved this for the first letter

fantasai: first letter is different kind of psuedo element. It inherits fundimentally 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 impl, 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

<fantasai> testcase his is some emphasized tex

<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>

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: 2.2 jsut changed

florian: The thing fantasai just pasted run in safari agrees with what fantasai stated about current behavior.

<fantasai> Cascading / inheritance model for ::selection was changed in https://github.com/w3c/csswg-drafts/issues/2474

florian: In the spec we're trying to get away from yest it's different then current, but current 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-line

fantasai: That's a different issue, that's about fundimental 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.
... We should probably put something there

Rossen_: Currently suggested API, parent element was suggested and then pointed out that was not nec. the best name at the very least. It's the originalting element and fantasai suggested .element
... 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 psuedos back to their element?

RESOLUTION: Add a .element prop that brings psuedos 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
... Additional comments?
... Obj to making all the types include the :: prefix for consistency?

RESOLUTION: 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

Rossen_: You don't have to do it real time. Just do it and comment back.

<dbaron> conditional on a pref related to web animations

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 s aselect the placeholder text is an element rather than an attribute
... 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.
... ::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 b/c select is a replaced element so you can say actual isn't rendered and it is a psuedo. If that make sesne 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 par. psuedo class and pseudo element
... Maybe we can jsut do pseudo class for now since it applies on the select?

fantasai: Prob solve the issue easiest because :placeholder-shown makes the placeholder the first child and you can style it

TabAtkins: True
... While I 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_: Prop: Accept and add the :placeholder-select pseudo class and add a note for ::placeholder that we're interested in working on it
... Objections?

RESOLUTION: 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
... Where did you test? I think we support some of this in Edge

florian: FF and Chrome. Tried to style color

Rossen_: Interesting. Okay
... 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
... 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
... 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?

RESOLUTION: 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
... chris do you want to take this?

chris: Been a bit of discussion. General consensus on properties. Suggestion that they're hte long hands. Support that
... 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 bounderies of box rep. element.

chris: But owuld it? Someone suggested it would but that was fairly quickly shown to be wrong

fantasai: Then we're fine

Rossen_: Prop 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.
... stroke-color, stroke-width, fill-color and paint-order
... Objections to adding stroke-color, stroke-width, fill-color and paint-order

RESOLUTION: 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 lookin graphical editors there's martching 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 impl need to say yes they're willing to impl

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

[everyone reads]

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 impl 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 boundries?

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. prob better not to do them. If someone wants them in the future we can add

Rossen_: Easier to add then remove.
... 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 warented.
... Sound good?

chris: Okay

Rossen_: That's this issue

end

Rossen_: That brings us to top of the hour

<fantasai> I'm noting that you can still specify the shorthands, we'd just ignore the longhands of it that aren't supported

Rossen_: We couldn't get to text and inline so next week we'll start with those
... We'll chat next week.

<astearns> trackbot, end meeting

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/[missed]/preffed/
Default Present: dael, rego, astearns, Rossen_, melanierichards, bdc, dauwhe, ericwilligers, smfr, jensimmons, plinss, gsnedders, leaverou, Nigel, oriol, TabAtkins, dbaron, tantek, antenna, emilio, florian, AmeliaBR
Present: dael rego astearns Rossen_ melanierichards bdc dauwhe ericwilligers smfr jensimmons plinss gsnedders leaverou Nigel oriol TabAtkins dbaron tantek antenna emilio florian AmeliaBR rachelandrew
Found ScribeNick: dael
Inferring Scribes: dael

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 16 Jan 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)