- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 3 Jan 2018 21:33:29 -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.
=========================================
Berlin & Sydney F2F
-------------------
- Anyone planning on attending the Berlin F2F should add their name
to the wiki and indicate hotel & Typo Labs information.
- RESOLVED: Mid-year Sydney F2F dates are July 2 to July 5- July 2
is Houdini, July 3-5 is CSS
Selectors
---------
- Data is still being gathered to make a decision on issue #2156:
webkit-prefixed pseudo-elements are always treated valid in
WebKit and Blink.
- RESOLVED: Accept the proposed changes to improve grammar/clarity
outlined here:
https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
- RESOLVED: Accept the names Live & Snapshot for the selector
performance profiles. (Issue #1694)
- RESOLVED: Remove the descendant combinator from selectors 4 (Issue
#641)
- RESOLVED: Accept the proposal for :local-link with an added note
about things that would cause a URL to change. (Issue
#2010)
- RESOLVED: Keep the :read-only and :read-write selectors in the
spec and work on defining and test cases as appropriate.
(Issue #127)
- RESOLVED: Rename :nth-column to :nth-col (Issue #2157)
Values & Units
--------------
- RESOLVED: Define lh unit resolution to be that of the parent when
the lh unit is spec on line height or font size. (Issue
#2115)
- RESOLVED: 'normal' value of line-height will behave as strut.
(Issue #1253)
CSS Paint
---------
- RESOLVED: Accept proposal in https://github.com/w3c/fxtf-drafts/issues/107
to have paint-order to affect non-SVG text.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018Jan/0003.html
Present:
Rossen Atanassov
David Baron
Brian Birtles
Tantek Çelik
Dave Cramer
Alex Critchfield
Elika Etemad
Dael Jackson
Peter Linss
Myles Maxfield
Xidorn Quan
Liam Quim
Naina Raisinghani
Manuel Rego
Melanie Richards
Florian Rivoal
Alan Stearns
Eric Willigers
Regrets:
Rachel Andrew
Angelo Cano
Chris Lilley
Lea Verou
Greg Whitworth
Scribe: dael
Agenda Setting
==============
Rossen: Let's get started.
Rossen: We got a number of people, esp. those in Europe, sending
regrets.
Rossen: As usual, a call for any other agenda items or changes to
the agenda?
fantasai: I did have one. There's a paint-order property issue. We
were thinking of speccing it to have it apply to HTML. If
there's objections to that let us know. Otherwise I'll
update the spec.
<fantasai> Rossen, https://github.com/w3c/fxtf-drafts/issues/107
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.
Rossen: Any other topics? Especially the people whose time zone is
favorable to them right now.
Berlin & Sydney F2F
===================
Berlin
------
Rossen: Berlin dates are confirmed. Location and meeting room has
been reserved and is not subject to change.
<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.
Rossen: For now as I said the meetings are confirmed.
Rossen: 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.
Rossen: It's a great offer and it's free to CSSWG members. All you
have to do is put yourself on the list.
Rossen: Any questions 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
procedure for actually booking?
Rossen: I'm re-reading Vlad's email.
Rossen: He's working with the Typo Labs organizers to see if we can
get in the block/discount rate. He had a brief exchange 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.
Rossen: I'll ask Vlad to post more details to the member list as
soon as possible.
Rossen: Does that answer your question?
fantasai: It tells me there isn't an answer right now.
Rossen: Not a definitive one.
Rossen: I went to the hotel website and it does look like you can
book for yourself for a similar rate.
Sydney
------
Rossen: Okay, Sydney.
Rossen: It was tentative on first week of July. That is between July
3rd and 5th. Starting July 2 for Houdini.
Rossen: 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.
Rossen: If everyone is okay I propose we remove the tentative and
make this a resolution so people can book.
Rossen: Objections?
RESOLVED: Mid-year Sydney F2F dates are July 2 to July 5- July 2 is
Houdini, July 3-5 is CSS
<nainar> I've changed the wiki page to reflect this:
https://wiki.csswg.org/planning/sydney-2018
Selectors
=========
webkit-prefixed pseudo-elements are always treated valid in WebKit
and Blink
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2156
ericwilligers: We don't have any useful statistics yet for webkit. I
don't think we have enough information to know how
often it happens.
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.
xidorn: 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 representative?
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: Objections to moving on as the Chrome folks are collecting
data?
Some inconsistent concepts and descriptions
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/386
fantasai: Request to review some changes to selector grammar 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
pseudo elements 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.
Rossen: Seemed TabAtkins was also saying he's fine.
fantasai: I believe it should make no difference to impl. If you
don't understand a selector you have to throw it out
whether it's ordering or not, but I wanted to check if
it's okay to put in grammar.
Rossen: Sounds good to me. Objections?
RESOLVED: Accept the proposed changes outlined here:
https://github.com/w3c/csswg-drafts/issues/386#issuecomment-354649902
More intuitive names for selector performance profiles
------------------------------------------------------
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.
fantasai: 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 consensus on having them.
dbaron: I just remember it as a thing for selectors that print impl
wanted.
dbaron: 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 only. 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
separately.
Rossen: In terms of naming, any objections?
RESOLVED: Accept the names Live & Snapshot
Should the syntax for the descendant combinator still exist?
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/641
fantasai: We had introduced a double child selector syntax. The
reason to do that was to a have a visually representative
syntax for a descendant combinator but more was to bridge
gap between child and shadow piercing descendant selector.
Shadow piercing was removed or objected to and && syntax
was removed. Do we want to pursue to have visible
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.
<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
RESOLVED: Remove the descendant combinator from selectors 4
Match local links
-----------------
github: https://github.com/w3c/csswg-drafts/issues/2010
fantasai: The proposal is summarized in leaverou's 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.
fantasai: We previously had a local link pseudo class. We dropped
it. leaverou's proposal is different because it also
accounts for fragment identifiers. If it does have a
fragment id it must match that of the URL.
fantasai: 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.
tantek: 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 implementors 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.
* tantek agrees with dbarons point
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 possibly change the URL.
Rossen: Sounds more normative then the 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: It's a back reference to existing prose.
tantek: An expansion to what we thing the normative thing is. Either
way you can make test cases.
<florian> +1 to 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.
Rossen: Anything else to add/change on this proposal before we
resolve?
Rossen: Obj?
RESOLVED: Accept the proposal with an added note.
:read-only and :read-write
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/127
* tantek vaguely remembers this got delegated to the Editing TF?
fantasai: Issue was filed to say they don't have a sensible
definition or interop. FF doesn't support them. Proposal
was to remove them. Alternative was come up with a useful
definition that's specced.
fantasai: Easiest is remove, but it's a question for the WG.
Rossen: Based on Chrome 52 data seems like it's below threshold of
what google would consider not removing. Question 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> Testcase -
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%3Aread-write%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3Aread-only%2C%20body%20%7B%20background%3A%20green%3B%20%7D%0A%3C%2Fstyle%3E
<fantasai> It is not supported in Firefox afaict.
<fantasai> and parses as invalid
<dbaron> I think Firefox supports :-moz-read-only and
:-moz-read-write
florian: Seems to be that the discussion isn't that it's useless but
that it's not specced right. Maybe something saying 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?
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. Probably fine to drop from a modern we don't
have use cases. Esp. if the threshold 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 proceed without pressure.
<florian> tantek, fair enough
ericwilligers: I think usage has gone up. It seems to be 0.4% on the
counter. So the thing you worried about has happened.
<ericwilligers>
https://www.chromestatus.com/metrics/feature/timeline/popularity/1377
Rossen: We're shipping unprefix. Chrome too. Not sure webkit. myles
are you shipping it?
myles: Give me a second.
* fantasai notes testcase above
<ericwilligers> 0.2% for read-write
https://www.chromestatus.com/metrics/feature/timeline/popularity/1378
Rossen: While we wait. ericwilligers you're suggesting current 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 willing 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?
Rossen: 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.
Rossen: Not sure about fantasai if she's still trying to connect.
<fantasai> sgtm
Rossen: Objections to resolve on keeping the properties 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.
Rossen: Proposal is keep the selectors in the spec and work on
defining and test cases as appropriate.
Rossen: Obj?
RESOLVED: Keep the selectors in the spec and work on defining and
test cases as appropriate.
Rename :nth-column to :nth-col
------------------------------
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 pseudo class and ::column
pseudo element that have nothing to do with each other.
fantasai: We don't normally abbreviate, 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 necessarily the same.
dbaron: Tables have col elements with weird spanning mechanism.
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 syntactic constructs, like
there's a data grid. This can also be applied to non-html
languages as well.
Rossen: :nth-col will only match table columns? Or grid as well?
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 browser decided to
support your mark up it would work, but you'd have to have
built in understanding of the markup language.
fantasai: These are based on the underlying data structure.
Rossen: Okay.
Rossen: That's good.
fantasai: Styling the table as all 'display inline' would have no
effect on whether these pseudo-classes matched
Rossen: So, I heard slight preference for table col and table
column. dbaron is :nth-col something you can live with?
dbaron: Yeah.
Rossen: Obj?
<florian> go for it
RESOLVED: Rename :nth-column to :nth-col
Values & Units
==============
Cyclic definitions with relative units
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2115
florian: There's already a bit of prose that says if you try to use
the em units in font size property or any unit that depends
on font size in the font size property we say you fetch
from the parent to avoid a loop.
florian: There was a poorly worded way to attach this to lh when
defining line height. The mis-phrased part meant we still
have a problem if trying to do line height in terms of font
size.
florian: What I tried to do is say all font dependent units go to
the parent and in addition lh also goes to the parent if
you use it in line height. That breaks the loops.
florian: We could have a less blunt approach, but I don't think
there's use cases for the more subtle variants.
florian: 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 other cases working because that's the
point of the lh unit. Only sensible option would be to ban
it from line height.
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.
Rossen: So, objections to define lh unit resolution to be that of
the parent 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.
RESOLVED: 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 think 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 necessary?
dbaron: I don't. It's just a thought.
'lh' and 'rlh' unit need to explain how to convert to an absolute
length
-----------------------------------------------------------------
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 ambiguous. There's
not question how they should work for values other then
normal. For normal we need to say something. I suggest
strut.
<fantasai> +1 to Florian's proposal
florian: Reasonable?
Rossen: Yes to me.
dbaron: Behavior as strut sounds good to me.
RESOLVED: Behave as strut.
CSS Paint
=========
Add paint-order property
------------------------
Github: https://github.com/w3c/fxtf-drafts/issues/107
fantasai: We have a spec to apply fill & stroke from SVG to text in
html and css style doc. It was a question of also applying
paint-order property.
fantasai: Makes sense to me it should apply.
Rossen: Makes sense to me.
Rossen: Okay
fantasai: If there's no objections we should go ahead.
Rossen: I don't have any objections from Edge PoV
Rossen: Objections?
RESOLVED: Accept proposal in https://github.com/w3c/fxtf-drafts/issues/107
to have paint-order to affect non-SVG text.
Rossen: florian we can do overflow first thing next week. Is that
okay?
florian: Sure.
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!
Received on Thursday, 4 January 2018 02:34:24 UTC