<scribe> ScribeNick: dael
Rossen_: We'll try and start 3
minutes after [your local time]
... We'll start in one minute
... Let's get started.
... We got a number of people, esp. those in Europe, sending
regrets.
... As usual, a call for any other agenda items or changes to
the agenda?
fantasai: I did have one. There's a paint order prop. We were thinking of specing it to have it apply to HTML. If there's obj to that let us know. Otherwise I'll update the spec.
Rossen_: Let's see how we do on
time. I know Dirk will join on the next call or after and he
might have an opinion.
... Any other topics? Especially the people whose time zone is
favorable to them right now.
Rossen_: Berlin dates are confirmed. Location and meeting room has been reserved and is not subject to change.
<fantasai> Rossen, https://github.com/w3c/fxtf-drafts/issues/107
<Rossen_> https://wiki.csswg.org/planning/berlin-2018
Rossen_: For those of you that
haven't booked, please go ahead and start booking. Also please
go ahead and add your name to the wiki. This will give the
organizers an idea of number of people attending and if they'll
need additional space.
... For now as I said the meetings are confirmed.
... one more date ask from Vlad & Typo folks is for those
of you interested in also attending Typo please add yourself to
the yes typo labs column. They have a strict amount of people
they allow and the conference is sold out, but they will make
an exception for CSSWG folks.
... It's a great offer and it's free to CSSWG members. All you
have to do is put yourself on the list.
... Any q on Berlin F2F?
fantasai: There's a note on the wiki about being a part of the hotel room block to add your name to the wiki. What's the proceedure for actually booking?
Rossen_: I'm re-reading Vlad's
email.
... He's working with the Typo Labs organizers to see if we can
get in the block/discount rate. He had a brief exachange with
them but nothing is locked. Based on # of people they'll try to
work out whatever the discount rate will be if it's different
then what's listed on the wiki.
... I'll ask Vlad to post more details to the member list as
soon as possible.
... Does that answer your question?
fantasai: It tells me there isn't an answer right now.
Rossen_: Not a definitive
one.
... I went to the hotel website and it does look like you can
book for yourself for a similar rate.
... Okay, Sydney.
... It was tent. on first week of July. That is between July 3
and 9th. Starting July 2 for Houdini.
... Sydney folks can we confirm?
nainar: Yep 100%
Rossen_: Are there any other...we
have resolved on this in the past. At least for the date July 2
to July 5th is what's on the wiki.
... If everyonen is okay I propose we remove the tentative and
make this a resolution so people can book.
... Obj?
RESOLUTION: Mid-year Sydney F2F dates are July 2 to July 5- July 2 is Houdini, July 3-5 is CSS
github: https://github.com/w3c/csswg-drafts/issues/2156
<nainar> I've changed the wiki page to reflect this: https://wiki.csswg.org/planning/sydney-2018
??: We don't have any useful statistics yet for webkit. I don't think we have enough information to know how often it happens.
<nainar> s/???/ericwilligers
florian: Presumably while gathering stats if we can tell the difference between webkit prefix that exists vs nonsense with a webkit prefix. So we can see if we need a short whitelist or a wildcard.
ericwilligers: I did distinguish but I don't have the data.
<ericwilligers> Chrome bug is crbug.com/547869 The use counter was added in December. We need to wait for this to reach stable before we have useful stats.
xidorn: It seems to be Chrome has
some data for the unknown pseudo elements.
... I think it's 0.003% of pages.
ericwilligers: That's only people running like canary
Rossen_: Are you saying current data is only on canary which isn't very rep?
ericwilligers: Yes.
Rossen_: So fair to say we need to wait a little longer for actual data?
ericwilligers: Yes, before we can make a blink change.
Rossen_: Obj to moving on as the Chrome folks are collecting data?
github: https://github.com/w3c/csswg-drafts/issues/386
fantasai: Request to review some changes to selector grammer which are outlined in a comment.
<fantasai> https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
fantasai: What I did was put the restriction on type selectors and psuedo elments into the grammar rather than just the prose. I wanted to check if there were concerns.
<fantasai> * ordering thereof
Rossen_: I don't believe we,
Edge, have an issue on this. I think we briefly discussed and
it should be fine.
... Seemed TabAtkins was also saying he's fine.
fantasai: I believe it should make no difference to impl. If you dn't understand a selector you have to throw it out wither it's ordering or not, but I wanted to check if it's okay to put in grammar.
Rossen_: sgtm. Obj?
RESOLUTION: Accept the proposed changes outlined here: https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
github: https://github.com/w3c/csswg-drafts/issues/1694
fantasai: Latest was to use live for the css profile and snapshot for the one shot API calls.
<aja> curious...they don't lie in @supports, too, do they?
Wanted to ask if WG accepts that for if there's better ideas.
florian: Sounds reasonable
Rossen_: To me as well.
dbaron: Do we have consensus that the snapshot profile will be used for things like query selector?
fantasai: Thought it was but I'm not sure.
Rossen_: Have we discussed this? Is there an issue about it?
fantasai: Whole point of having that profile was to do that. I'm pretty sure given the number of times we talked about the name there was consesnus on having them.
dbaron: I just remember it as a
thing for selecotrs that print impl wanted.
... impl producing pdfs, not interactive
florian: My memory is this was for the selectors everyone wants but are deemed too slow to use in normal CSS. I think we made it forbidden to support in pdf impl. It needs to be web compat so if web can't they can't.
dbaron: Makes sense. It just wasn't how I remembered the discussion.
Rossen_: I suggest we resolve on
issue of naming. dbaron if you feel the snapshot part needs
further discussion let's bring that sep.
... In terms of naming, any obj?
RESOLUTION: Accept the names Live & Snapshot
github: https://github.com/w3c/csswg-drafts/issues/641
fantasai: We had intro a double child selector syntax. The reason to do that was to a have a visually representative syntax for a desc. combinator but more was to bridge gap between child and shadow piercing descendant selector. Shadow piercing was removed or obj and && syntax was removed. Do we want to persue to have visable combinator or drop it?
Rossen_: dbaron I see you proposed the removal originally. Do you still favor removing?
dbaron: I would. Introducing new syntax and dealing with compat isn't a thing we should spend time on without a good reason to do so
Rossen_: Other opinions or obj?
<astearns> +1 for removal. It's nice but not worth it
fantasai: What dbaron said made sense
Rossen_: I'm also with dbaron
RESOLUTION: removed the descendant combinator from selectors 4
<florian> +1 especially given that selectors are fragile and don't fallback very well, we shouldn't add more opportunities for authors to shoot themselves in the foot
github: https://github.com/w3c/csswg-drafts/issues/2010
fantasai: The proposal is
summarized in leaverou comment. It's common for authors to want
to style the current location differently. They currently have
to do something custom. Would be nice to have a selector to say
this link is pointing to this page.
... We previously had a local link psuedo class. We dropped it.
leaverou 's is different because it also accounts for fragment
identifiers. If it does have a frag. id it must match that of
the URL.
... I think it makes sense.
dbaron: I think it needs a clear processing for what happens if the page's uri changes.
<tantek> is it like :target in that regard?
fantasai: It's a dynamic pseudo.
dbaron: Does that cause anything interesting to happen with things like push state that change the url.
fantasai: I have no idea. If it changes the uri [missed]
tantek: That's the kind of thing :target will need to answer as well.
<fantasai> If the current URL changes , then what :local-link matches changes; but :local-link can't cause the current URL to change.
dbaron: I think :target isn't defined well as well. I think if this goes into spec it should point out existing features that could cause pages uri to change.
tantek: I think that should
happen regardless.
... If :target doesn't express the history state that's an
issue regardless.
dbaron: I remember a lack of interop with dynamic changes originally, I don't know about now.
tantek: My point is it shouldn't be different then the :target impl.
dbaron: My point is the spec should point out to impl things that could cause the uri to change. If the spec designers don't know that they should figure it out so it gets impl right.
fantasai: You're asking for a note?
dbaron: Yes.
fantasai: Okay that's fine.
Rossen_: So the note you're referring to is?
fantasai: Providing the information to point out all the things that could poss. change the URL.
Rossen_: Sounds more normative thent he note.
florian: Point is to find these spec if you're not aware of them.
tantek: It's the kind of thing that's good as a note to start, but could turn into test cases. So it sounds normative-like but doesn't need to be.
florian: I'ts a back reference to existing prose.
<florian> +1 to test cases
tantek: An expanstion to what we thing the normative thing is. Either way you can make test cases.
fantasai: You can make test cases easier because you have a list of what they should be.
Rossen_: So I'm hearing people
are in favor of the proposal for a local link as spec by
leaverou with the additional requirement as well as at the very
least put a note and point back to :target and hope things are
spec well as to what could cause a URL change and make the
pseudo class invalidated.
... Anything else to add/change on this proposal before we
resolve?
... Obj?
RESOLUTION: Accept the proposal with an added note
github: https://github.com/w3c/csswg-drafts/issues/127
fantasai: Issue was filed to say
they don't have a sensible def. or interop. FF doesn't support
them. Proposal was to remove them. Alt was come up with a
useful def. that's specced.
... Easiest is remove, but ti's a Q for the WG.
Rossen_: Based on Chrome 52 data seems like it's below threshold of what google would consider not removing. Q to the chrome folks, are you willing to remove this?
ericwilligers: If it's low I think if that's what the group pref. We haven't discussed.
Rossen_: I don't want to resolve now and then someone say nope we won't remove. Good we took exersize to review but no action will follow. It's good to have more commitment before we resolve. If you guys aren't okay to remove from the get go no reason to talk.
<fantasai> It is not supported in Firefox afaict.
<fantasai> and parses as invalid
florian: Seems to be that the dsicussion isn't that it's useless but that it's not specced right. Maybe something sayinng this might be useful but we didn't get it right, feedback please in the spec.
ericwilligers: Has anyone come up with a different spec for that?
<dbaron> I think Firefox supports :-moz-read-only and :-moz-read-write
tantek: I think it came from a really old draft of css ui and then was assimilated into selectors. I recall there was some type of x-forms back in the day but I don't know if that's used anymore. Prob fine to drop from a modern we don't have use cases. Esp. if the threashold is low enough.
Rossen_: Is FF only one not supporting?
dbaron: We have support with moz prefix, but not unprefixed.
tantek: Regarding fixing b/c it's web exposed now there's a race condition where if it's low enough to remove we should do so to avoid having an emerging compat issue while we figure out how it should work. Then it can procceed without pressure.
<florian> tantek, fair enough
ericwilligers: I think usage has gone up. It seems to be .4%/ https://www.chromestatus.com/metrics/feature/timeline/popularity/1377 on the counter. So the thing you worried about has happened.
Rossen_: We're shipping unprefix. Chrome too. Not sure webkit. myles are you shipping it?
myles: Give me a second.
<ericwilligers> 0.2% for read-write https://www.chromestatus.com/metrics/feature/timeline/popularity/1378
Rossen_: While we wait. ericwilligers you're sugegsting cunnet stats say we can't remove?
ericwilligers: Correct.
Rossen_: So I guess this is a
moot point. That's why we wanted to have the illing to
deprecate discussion. So the uptick in usage is too large to
remove. So as brought by florian we can't remove so how do we
fix them?
... If we're not ready to discuss we can resolve this issue as
not removing from spec and then we can work on further
definition sep.
... Not sure about fantasai if she's still tring to
connect.
<fantasai> sgtm
Rossen_: Obj to resolve on keeping the properites as-is based on usage data and work on further defining their behavior?
myles: Our rendering is same as chrome, different then FF.
Rossen_: FF passes if you add the
prefix.
... Proposal is keep the selectors in the spec and work on
defining and test cases as appropriate.
... Obj?
RESOLUTION: keep the selectors in the spec and work on defining and test cases as appropriate.
github: https://github.com/w3c/csswg-drafts/issues/2157
fantasai: Reasoning is we have
often discussed adding a pseudo element to select the columns
and that would be ::column. If we do that we have the column
psueco class and ::column psuedo element that have nothing to
do with each other.
... WE don't normally abbriviate, but HTML uses col already so
maybe we can break the conflict.
florian: This is impl nowhere?
fantasai: As far as I'm aware it's not impl.
dbaron: My worry is that it makes
it sound like has something to do with nth col element rather
then the nth column. THose aren't nec. the same.
... Tables have col elements with weird spanning mech.
fantasai: Yeah. Col is also used in html syntax in other places like scope=col. Col element is relatively obscure. I think it's fairly well understood that col is a column not a column element.
dbaron: I'd slightly prefer :nth-table-column but I won't hold up.
fantasai: There are potentially other syntatix contrainsts, like there's a data grid. This can also be applied to non-html lang as well.
Rossen_: nth-col will only match table columns? Or grid as wel?
<fantasai> s/constrainsts/constructs/
fantasai: It doesn't have
anything to do with styling. Just markup, so it has nothing to
do with grid. You might have a grid element in your markup and
if the borwser decided to support your mark up it would work,
but you'd have to have built in understanding of the markup
language.
... These are based on the underlying data structure.
Rossen_: Okay.
... That's good.
... So, I heard slight preference for table col and table
column. dbaron is :nth-col somehting you can live with?
dbaron: Yeha.
Rossen_: Obj?
<florian> go for it
RESOLUTION: rename :nth-column to :nth-col
github: https://github.com/w3c/csswg-drafts/issues/2115
<fantasai> fantasai^: Styling the table as all 'display inline' would have no effect on whether these pseudo-classes matched
florian: There's already a bit of
prose that says if you try to use the em usit in font size
property or any usit that depends on font size in the font size
property we say you fetch from the parent to avoid a
loop.
... There was a poorly owrded way to attach this to lh when
defining line height. TH emis-phased part meant we still have a
problem if trying to do line height in terms of font
size.
... What I tried to do is say all font dependant units go to
the parent and in addition lh also goes tot he parent if you
use it in line height. That breaks the loops.
... We could have a less blunt approach, but I don't think
there's use cases for the more subtile variants.
... Precise wording is in the issue.
fantasai: Works for me.
myles: I agree we shouldn't be in the business of trying to do a complex dependency analysis.
Rossen_: I'm waiting for others to have a moment to consider.
dbaron: The proposal is that lh goes to the parent if used in font size or line height.
florian: Yes.
dbaron: Okay.
ericwilligers: Other things like height?
florian: No, there's no loop.
ericwilligers: I know there's no loop, but seems confusing if lh appears 5 times and means 5 different things.
??: we have that with ems
ericwilligers: Don't want to make it worse.
florian: We need to keep toehr cases working because that's the point of hte lh unit. Only sensible option would be to ban it from line ehight.
Rossen_: But for the same reason we should have banned em from font.
florian: And we didn't
Rossen_: And I think anyone that
used em in fonts understands how they did it.
... So, obj to define lh unit resolution to be that of the
aprent when the lh unit is spec on line height or font
size?
<myles> +1
<dbaron> The cases that go to the parent here are probably cases that can be safely recommended against.
RESOLUTION: define lh unit resolution to be that of the parent when the lh unit is spec on line height or font size
dbaron: Should the spec have a not saying we suggest not using that behavior? Suggest it's poor practice to use it that way
myles: Is there one for em?
dbaron: I don't htink so.
florian: If we had a plh unit I would say it is, but since we don't I'm not sure it's bad practice.
Rossen_: I'm fine with either note or no note. If dbaron you feel it's really nec?
dbaron: I don't. It's just a thought.
Rossen_: I want to give the
people on APAC choice of the remaining issues.
... [lists]
... Preference?
github: https://github.com/w3c/csswg-drafts/issues/1253
florian: We used to say they need to convert to absolute height. Was ambiguous. We fixed that. Now it's not ambig. There's not question how they should work for values other then normal. For normal we need to say something.
<fantasai> +1 to Florian's proposal
florian: reasonable?
Rossen_: Yes to me.
dbaron: Behavior as strut sounds good to me
RESOLUTION: Behave as strut
fantasai: We have a spec to apply
fill & stroke from SVG to text in html and css style doc.
It was a question fo aslo applying paint order prop.
... Makes sense to me it should apply.
Rossen_: Makes sense to me.
<fantasai> https://github.com/w3c/fxtf-drafts/issues/107
<fantasai> Github: https://github.com/w3c/fxtf-drafts/issues/107
Rossen_: Okay
fantasai: If there's no obj we should go ahead.
Rossen_: I don't have any
objections from Edge PoV
... Objections?
<aja> may i interject....please add to ::first-letter properties, too
RESOLUTION: Accept proposal in https://github.com/w3c/fxtf-drafts/issues/107
Rossen_: florian we can do overflow first thing next week. Is that okay?
florian: Sure.
<fantasai> aja, the whole fill-stroke spec applies to ::first-letter, or should...
Rossen_: Quick reminder to add yourself to Berlin wiki if you haven't done so. Also give an indication as to if you want to attend typo labs. With that we're done. Thanks for calling in!
<fantasai> since it applies to inlines
<aja> fantasai, think there be blink issues
<florian> fantasai: since we resolve on how to solve the cyclic unit thing, and there is exact wording in the issue, to you still want a pull request, or can I just go ahead an commit to the master branch?
<fantasai> florian: you can go ahead
<florian> thanks
<fantasai> aja, I can't imagine why; first-letter should be just like any other inline by the time you get to painting it
<dbaron> trackbot, end meeting
<Rossen_> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) FAILED: s/???/ericwilligers/ Succeeded: s/1.4%/.4%/ https://www.chromestatus.com/metrics/feature/timeline/popularity/1377/ Succeeded: s/??/mylies/ Succeeded: s/mylies/myles/ Succeeded: s/:nth-column/:nth-table-column/ Succeeded: s/nth-column/nth-table-column/ iirc/ FAILED: s/constrainsts/constructs/ Default Present: dael, Rossen_, liam, nainar, ericwilligers, xidorn, Florian, astearns, alex_antennahouse, birtles, dbaron, rego, plinss, myles, melanierichards, dauwhe, tantek Present: dael Rossen_ liam nainar ericwilligers xidorn Florian astearns alex_antennahouse birtles dbaron rego plinss myles melanierichards dauwhe tantek Found ScribeNick: dael Inferring Scribes: dael WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 03 Jan 2018 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.)[End of scribe.perl diagnostic output]