- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 27 Mar 2019 21:57:13 +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.
=========================================
Can we move Easing Functions and Scrollbars to CR?
--------------------------------------------------
- There were no objections to moving Easing Functions to CR, however
the editors were not on the call so resolution will be called
for next week.
- Scrollbars was not quite ready for CR. There are still some open
issues that need to be resolved and myles said he has some more
to file. However, work is definitely progressing toward a CR.
Houdini meeting at TPAC?
------------------------
- Houdini will request a room to meet on the Friday of TPAC.
CSS Inline
----------
- RESOLVED: Return 'normal' for line-height (Issue #3749: A question
for the procedure to compute the resolved value of
"line-height")
Republishing drafts with dev.w3.org links updated
-------------------------------------------------
- RESOLVED: Republish Selectors Nonelement as a note and we are
abandoning this work
CSS Transforms
--------------
- RESOLVED: For SVG Transform attribute there is no requirement for
space or comma between transform functions (Issue #3719:
SVG transform attributes: transforms don't need to be
separated)
Selectors 4
-----------
- RESOLVED: Defer complex selectors for all of these selectors
[:nth-child()/:nth-of-type()/:is()/:where()/:not()/
:has()] and have a note in the current level mentioning
this is an enhancement we'll get to in the next level
(Issue #3760: Defer complex selectors inside
:nth-child() etc. to L5)
CSS Environmental Variables
---------------------------
- florian introduced his proposal to be able to reuse the title of
the document inline such as making it always present in the
header or footer (Issue #3685) . There was concern about if
using title was the best way to solve the use case, but there
wasn't enough time on the call to dive deeper.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Mar/0016.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Oriol Brufau
Tantek Çelik
Emilio Cobos
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Brad Kemper
Brian Kardell
Chris Lilley
Peter Linss
Myles Maxfield
Nigel Megitt
Anton Prowse
Melanie Richards
Florian Rivoal
Dirk Schulze
Lea Verou
Sean Voisen
Fuqiao Xue
Regrets:
Manuel Rego Casasnovas
Greg Whitworth
Scribe: dael
Can we move Easing Functions and Scrollbars to CR?
==================================================
Easing Functions
----------------
astearns: I don't think we have an Easing Functions editor on call
fantasai: I can summarize where we are
<smfr> https://drafts.csswg.org/css-easing/
fantasai: Easing spec, aka Timing Funcitons has been stable since
last changes went in during the summer.
fantasai: Current status is there is no open issues except adjusting
wording to be more generic. Aside from that it's
implemented, deployed, stable, should be in CR. I think
editorial work could happen in CR. WE shouldn't hold it
back.
fantasai: It's ready for implementation and can encourage
implementation
astearns: Concerns with direction?
<florian> Sounds good to me
astearns: I will ping the editors in case they don't read minutes.
We can take it up next week with one or both on call
Scrollbars
----------
astearns: Scrollbars? Ready for CR?
fantasai: No but close. It's impl and deployed in Gecko. Most of the
issues feel can be closed with a little editor effort.
Nothing contentious open. Not far but can't publish to CR
smfr: We'd like 1958 resolved. Scrollbar width as a length
<smfr> https://github.com/w3c/csswg-drafts/issues/1958
astearns: Any other concerns with scrollbars?
tantek: I'm not seeing that in query
fantasai: Was marked as closed
<@fantasai> https://github.com/w3c/csswg-drafts/issues/1958#issuecomment-417146619
tantek: What additional are you looking for smfr ?
smfr: Reading through. Not sure what resolution was
astearns: xidorn put in scrollbar width to spec with auto|thin|none
smfr: ED not up to date or am I not looking at it?
<@fantasai> https://drafts.csswg.org/css-scrollbars-1/#scrollbar-width
smfr: ED still has length value and mentions the note
astearns: There is a note in the draft but issue is not open
smfr: So spec needs updated
tantek: Thanks for pointing out
chris: If you use edits needed tag on issue and open it again
astearns: Okay, so we can work through that issue and other edits
and possible look for CR in near future?
tantek: I think there were a few issues that applied to other spec
and features that were open regarding scrollbars. Don't know
if want to include or resolve or punt to another version
tantek: I guess I disagree with fantasai summary for a few issues. I
agree for most issues. Some require responding to folks that
want more features and saying we're not doing that.
tantek: 2899 is a good example
fantasai: I think if we need to defer to next level we can do it.
Given you are shipping and there's no sign. Issues we
should put in CR
tantek: Because scrollbar-gutter not ready?
fantasai: Not impl. You can try editing it in if you feel there's
enough detail. I don't have strong opinion on this level
or not. I don't want it to hold back CR because we have
stable and shipping
<smfr> https://www.w3.org/TR/css-overflow-4/#scollbar-gutter-property
florian: We had significant design discussion but no one has tried
implement. We can put in as at-risk or just put in next
level
tantek: Is it ready for implementation?
florian: I think so
tantek: It's got tests?
florian: I don't think it has tests. Should get some. I don't think
wait for spec work, we should write tests and impl. Trying
to get to CR doesn't sound crazy, but it doesn't have impl.
tantek: If we haven't had tests I don't feel good putting in CR
myles: I have some issues I haven't filed yet on this spec
florian: People looking at impl is good way of getting tests.
Signaling it's ready for impl may get tests
fantasai: CR means spec is as stable as it will get with us
discussing in a room. We're done with design, have to work
out details based on experience of impl and writing tests.
fantasai: I don't mind either way. If the editing work or issues
will hold back CR I'd prefer to hold, but if it's doable
we can put it in as at-risk
florian: I don't think there are open issues on scrollbar-gutter
astearns: May be because no one looked from implementation standpoint
florian: Maybe
florian: I think it's significantly more stable then other things in
overflow 4
tantek: Have implementors indicated interest in scrollbar-gutter? I
don't know for Gecko
florian: When we discussed significant interest to solve that
problem and agreement this would solve. I'm not sure if
that's same as impl interest
tantek: It's not. Implementor interest is an implementor saying we
want to implement.
florian: I heard we want to solve a problem and that looks good way
astearns: Any implementors on the call want to speak up?
astearns: Let's move on. Good to get status. Sounds like
conversation is settled where it needs to.
tantek: I can go ahead and do edits and put the scrollbar-gutter
into current and we can try the at-risk approach to see if
it gathers the attention.
tantek: Was it myles that said he had more issues?
myles: Yep
tantek: Those would be good to see as well. That's what we have to
do to take toward CR
Houdini meeting at TPAC?
========================
astearns: Signed up for Mon and Tues. Interest for a half day
Houdini. Do people care if it's Thurs or Fri?
astearns: I know krit concerned about overlap on SVG
smfr: Prefer contiguous with CSS
<AmeliaBR> I'd also prefer not-Thursday because of SVG overlap.
astearns: Can't do it entirely because Wed can't pick
chris: Prefer Fri
leaverou: Me as well. I have interest in participating in SVG
chris: Having said that I have conflicts Thurs & Fri
leaverou: AmeliaBR would have a problem because she would need both
<myles> SVG is on Thursday, right?
astearns: Yes, SVG is Thurs.
nigel: I did wonder...maybe it's best to do a poll
astearns: Definitly possible
florian: A doodle or something light
<tantek> ok with either day
<tantek> Yes Friday makes slightly more sense because it avoids AC
meeting conflict on Thursday
Rossen: If SVG is on Thursday and so are A/C meetings. Traditionally
didn't use Friday but I didn't hear anyone say no Friday
because I'm out. How about we pencil in Friday and if we
don't hear otherwise we reserve the room and move on.
Elsewise we might miss deadline for sign up.
astearns: That's true. I wasn't considering deadline
chris: It is important to get rooms, they do fill up.
astearns: Objections to having Houdini meeting on Fri of F2F?
astearns: Alright, I will send in a request for a room on Friday for
Houdini
<myles> by the way, everyone should remember to re-join the newly
rechartered SVG WG
astearns: [reads myles IRC comment]
chris: Almost everyone needs to rejoin
CSS Inline
==========
A question for the procedure to compute the resolved value of
"line-height"
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3749
florian: Bit of discussion in GH was first a suggestion maybe
line-height isn't special because many types of boxes that
can fragment and we always return first. Two buts: we're
talking contiguous runs of text which is poorly defined to
say first. This is not what Gecko or WK return, both return
more theoretical rather than actual layout
florian: But it is similar.
florian: I maintain given that we're not providing a post layout
usable value we may as well preserve as keyword as Chrome
does. But alternative isn't hard to spec so if people feel
strongly, why not. I'm not sure there's a use case for it.
florian: If we want to drill down to font metrics it's more houdini
space.
myles: I was reading conversation from last week and I think I
didn't make something clear. Philosophically I think you're
right. There is no px value that will always be correct. My
concern was web compat. If we do keyword and not number and
line of JS tries to parse it could cause exceptions
myles: I brought up we should do analysis.
florian: Question on compat concern. Anything we change from any
engine could break amount of web. The fact that Chrome
ships other behavior tends to make me think it's probably
okay. Do you have a specific reason to worry about this one
or is it a general case of changing might break?
myles: Why this might be different is line-height and
getComputedStyle have been around forever. Changing behavior
that's been consistent in engine for decades is scary
fantasai: If we want interop someone needs to change. Either Chrome
to return px or other engines return 'normal'
fantasai: Is that not correct?
TabAtkins: myles, given we have real life compat data that Chrome
returns keyword, what information do you want obtained?
myles: A blunt tool is how many times getComputedStyle called where
result is 'normal'
TabAtkins: Potentially obtainable, but a fairly invasive use counter
florian: Would that data from Chrome help? We know Chrome is fine.
If there's a problem it's because websites are build
differently perhaps on mobile where Chrome has less market
share. So would it help?
<@Rossen> https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/line-height/
<@Rossen> in case this helps a bit ^
<@fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0Ax%0A%3Cscript%3E%0Aw(window.getComputedStyle(document.body).lineHeight)%3B%0A%3C%2Fscript%3E
emilio: I'm somewhat concerned...result of getComputedStyle on form
controls have particularly weird computation. WK and Blink
mangle line-height to give computed line-height. I suspect
there are cases where if you have a select element if this
change impl in Gecko it could return keyword and Blink
returns pixel. I recall something where like if the height
is fixed it becomes a fixed height value.
emilio: Willing to try and change, but that's my concern
nigel: Observing this seems a bit of a tie here. Current behavior is
return 'normal' and that's closer to computed value. Resolved
isn't always computed, but being as close as possible seems a
reasonable rule to use to break the tie.
fantasai: I think if Gecko is willing to try that should resolve web
compat concerns. I agree that's probably the direction to
try and go in.
myles: If Gecko makes this change and there's no problem that's
sufficient. I agree with fantasai. Don't need a use counter
in that case
astearns: Way forward is spec we return 'normal' have Gecko try it
out and hope for the best
fantasai: And if problem open issue
astearns: Objections to return 'normal' for line-height?
RESOLVED: Return 'normal' for line-height
astearns: Thanks emilio for being the guinea pig
emilio: I'll add a use counter and not blindly change, but happy to
give a shot
Republishing drafts with dev.w3.org links updated
=================================================
astearns: I'm not sure if the republishing in this email thread is
required. I'm assuming links will continue to work and we
don't have other dependencies on machinery being shut
down. Is that correct?
xfq: It's not required because the redirection will continue working
although it's an old server that will be read-only and some
spec haven't been updated for 3, 4, or 5 years on /TR
astearns: I agree we should update some specs. I don't know if it's
useful to have a mass repub
<tantek> does this effect CSS 2.2 publication? what legacy systems
are we talking about?
xfq: We can do that case by case. Refreshing some old specs I think
we can discuss the ones that might need retirement like
non-element selectors. Concern in retiring?
chris: We should certainly retire at least that.
xfq: And page floats we got 2 need editors last year so maybe hold
<@fantasai> FTR, the specs xfq has listed are css-lists-3,
css-scoping-1, css-gcpm-3, css-ruby-1, css-line-grid-1,
css-regions-1, css-exclusions-1, css-page-floats-3,
selectors-nonelement-1
florian: Page floats we should not republish because if I am an
editor I haven't been able to work for a long time but
there are outstanding resolutions that have not been
editing in. Publishing when knowing text is wrong is bad
<@fantasai> +1
florian: They're difficult edits
fantasai: I think line grid spec I don't think much is changed so
fine to republish. I would skip announcing it
astearns: I think there are enhancements to examples agreed on but I
have not made edits. It's in the same boat where
republishing is not quite right
chris: Some of these spec have changes with PRs so there is
outstanding stuff incorporated but not published since
astearns: Those PRs are part of the big PR backlog. If you are an
editor on one of these specs for the changelog please
approve
xfq: And thanks to those that reviewed
astearns: I think there is no reason not to publish selectors
nonelement as a note.
astearns: Objections to republish selectors non-element as a note?
florian: Gutted note or note with content?
chris: With content. But status says not worked on
xfq: Agree
<tantek> sounds more like abandoned by the WG
<tantek> "not worked on" sounds temporary for now
astearns: tantek mentioned it sounds abandoned and that's purpose of
note
chris: Note can say it's retired when you publish. The idea is that
people don't get confused by a slew of stuff
dbaron: At some point I thought that a bunch of pseudo elements
removed from selectors with the thought to move. Where are
they?
TabAtkins: Pseudo spec. This is just for attr nodes
chris: I don't think it's been lost
<tantek> Lists would be good to republish, since we're implementing.
And realizing looking at it I was formerly an editor 😂
astearns: I'm hearing no objections
RESOLVED: Republish Selectors Nonelement as a note and we are
abandoning this work
astearns: Any other things to talk about with old drafts?
astearns: People look at the list. If you are editing anything
mentioned or you are a former editor it would be good to
update
tantek: Good to get Lists repubished. It's almost 5 years out of
date and we're impl the current set of resolutions to having
it published would be good
TabAtkins: Next thing I'm working on so agreed
tantek: Thanks
CSS Transforms
==============
SVG transform attributes: transforms don't need to be separated
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3719
krit: There is a historical difference between SVG and CSS. If we
just look at SVG there is a case of full interop that's not
covered by spec. There's no space or comma between any
transform list. Spec requires it but impl don't. I request we
relax the syntax to follow impl
TabAtkins: This falls out of CSS definition where you don't need
spaces if you can distinguish
AmeliaBR: Not that simple because rest of syntax can't be desc with
CSS syntax. Have special parsing for transform based on
SVG1. This happens to be where all browsers don't match
SVG1 so might as well match other browsers
AmeliaBR: Found other weirdness that's inconsistent but I'm happy to
ignore certain browsers allow mangled syntax. But if
everyone supports we should include in spec
krit: Requested is for SVG Transform attribute there is no
requirement for space or comma between transform functions
astearns: Just transform attribute?
krit: For CSS that falls out with the tokenizer so yes just for
transform attribute
astearns: Objections?
myles: IN SVG transform definition just links to css
krit: Correct
AmeliaBR: There's a section in css transforms that gives special
rules for parsing the attribute
<krit> https://drafts.csswg.org/css-transforms/#svg-transforms
krit: Link ^
astearns: It's in css draft where this is defined
krit: Yep
RESOLVED: For SVG Transform attribute there is no requirement for
space or comma between transform functions
Selectors 4
===========
Defer complex selectors inside :nth-child() etc. to L5
------------------------------------------------------
astearns: Discussed earlier but didn't resolve
fantasai: These selectors have been highly requested for years. We
know that WK had implemented the full functionality
allowing combinators and everything but no one else has
impl. There is a question of should we reduce scope of L4
fantasai: Question I wanted to ask is do we take this back to only
allow compound for now and add complex in the future to
make impl easier or is that not relevant concern?
fantasai: Interop of reduced subset solves most of the problems
AmeliaBR: No one would ask WK to rollback it's jsut defer to next
level?
fantasai: Yes
astearns: Concerns from WK?
smfr: I think we're okay moving those bits to next level
astearns: In issue question of how many selectors we defer complex
selectors for.
astearns: Question is do we defer complex for :nth set or also the
is/where/not/has collection?
myles: For specs to get to rec we need two impl so why not start
there?
astearns: With everything?
myles: If not 2 impl and no plan for another one...
myles: We have to defer
myles: Sooner or later
fantasai: I don't want to have someone not impl and push off impl of
these features in general because doing all at once is too
much. If reducing size gets us an impl fast that's good.
fantasai: I want to hear from Gecko and Blink are you planning to
impl and if yes would trimming make it faster
TabAtkins: I have to ask, I'm not certain. We're not against it but
I don't know scheduling
AmeliaBR: Comment in issue from Eric W that he started but hasn't
worked recently
emilio: We don't have immediate plans to impl, but complex selectors
really complicate getting invalidation right so it would
definitely take more if we had to figure out combinators
fantasai: Is that true for the nth set only or also is/where/not
emilio: If we solve we have to do for all at once
fantasai: That seems like a good argument to refer to next level if
can get Gecko impl sooner
dbaron: I think if the result you want is finding out...is A
encouraging impl and B finding out if extra parts will cause
pain I think perhaps best way is add a note to spec that
says we're considering dropping. If they make your impl
harder please impl without and let us know. Because then
there's clear intent WG is interested in feature as a whole
but also just those parts
fantasai: Could do opposite and just add subset and note we're doing
the rest in L5 and these already impl in WK but seemed too
complex for others
florian: That's harder editorially. Do you think subset is easy to
figure out in reading spec? Or is note saying can do subset
is enough so don't have to editorially split it up
fantasai: If we're doing it for all at once it's quite simple
editorially.
astearns: For myself it would be clearer reading spec to have
complex selectors broken to next level with a note saying
intend to add in future level. It's easy to look at
production with complex selectors and miss the note and
think it's too much
astearns: My preference is to defer complex selectors for all of
these and have a note in the current level mentioning this
is an enhancement we'll get to in the next level
astearns: Objections?
RESOLVED: Defer complex selectors for all of these selectors and
have a note in the current level mentioning this is an
enhancement we'll get to in the next level
CSS Environmental Variables
===========================
Getting access to the document title
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3685
florian: There is a feature in GCPM that lets you in paged media
generate header and footer with repeating document title in
box. Interesting, but highly specific so not impl by a
mainstream browser. Base feature to take document title and
inject somewhere visible is useful. nth function seems like
it could achieve that. Proposal is to have nth-doc-title
expose the title of the element to be used in generated
content
<tantek> q+ to note "title of the document" is not necessarily
<title> but sometimes (often) <h1> etc.
florian: I'm specifically referring to a title element, not an h1.
This isn't regions. H1 can have complex markup which
wouldn't transfer to nth. HTML title element is just text
so it's useful as well. Regions is useful but bigger
<tantek> right, I know that. I'm saying your use-case is
disconnected from your solution.
tantek: Not about extra markup but typical title elements contain
things from name of website to author to doc name. If
looking to solve use case and you want to repeat the human
readable title of document that information is often in
first H1. If the use case is the repeating thing that
doesn't solve with how people publish on web today.
florian: I think will work with most eBooks but you have a point
tantek: I would want to double check solution
<AmeliaBR> +1 to tantek's argument on practicality. But I like the
general idea of env() to access document properties.
astearns: We're out of time. Thanks everyone for calling in
Received on Wednesday, 27 March 2019 18:58:07 UTC