- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 Oct 2017 21:34:52 -0400
- 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.
=========================================
CSS UI 3 & 4
------------
- RESOLVED: Take CSS UI 3 to PR.
- RESOLVED: Take CSS UI 4 to an updated WD.
- RESOLVED: Re-point CSS UI link to CSS UI 4 spec.
Fonts 3
-------
- RESOLVED: Publish a new Fonts 3 CR.
HTML
----
- Though the group is generally supportive of the effort to
incorporate better typography in issue #1888, the proposal to
change <sup> and <sub> has a very high likelihood of causing
breakage. This should instead be filed as a bug against Fonts 4
or 5 as a proposal to change CSS. Any request should also have
test cases to demonstrate what would be different between the
current and proposed approach.
CSS Text Decor
--------------
- RESOLVED: Add the statement that stroke should follow the curve of
the glyph as well as adding a non-normative note that
points out anything captured in the Github issue and add
better pictures.
CSS Grid
--------
- The remaining open topics on issue #509 (percentages and intrinsic
sizes: https://github.com/w3c/csswg-drafts/issues/509 ) will be
discussed at the F2F.
F2F Meetings
------------
- RESOLVED: Have the mid-2018 meeting held week of July 2nd in
Sydney with Google as host.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Oct/0042.html
Present:
Rossen Atanassov
Daid Baron
Tantek Çelik
Dave Cramer
Alex Critchfield
Benjamin De Cock
Elika Etemad
Javier Fernandez
Dael Jackson
Chris Lilley
Peter Linss
Myles Maxfield
Anton Prowse
Manuel Rego Casasnovas
Melanie Richards
Florian Rivoal
Jen Simmons
Alan Stearns
Greg Whitworth
Regrets:
Rachel Andrew
Tab Atkins
Tony Graham
Michael Miller
Lea Verou
Scribe: dael
Rossen: Let's get going. Hello everyone.
Rossen: Are there any additional items for the agenda or any changes
we need to make?
Chris: I sent one for CSS Fonts 3 which could do with a republish.
Updated CR.
Rossen: Thank you.
Rossen: Any others?
Spec Rec Next Steps
===================
CSS UI 3 & 4
------------
Rossen: First one is CSS 3 UI.
<florian> http://www.w3.org/mid/BBBF6365-4251-426D-A3F0-4F3E7D6C48A4@rivoal.net
Email Body:
[
## CSS-UI-3 ##
* There are 0 open issues:
https://github.com/w3c/csswg-drafts/labels/css-ui-3
* The change section is up to date:
https://drafts.csswg.org/css-ui-3/#changes
* All changes are fairly minor: mostly clarifications, and
some small tweaks to align the spec with implementation
* All testable / normative changes since last CR have tests
updates or additions, linked to from the changes section.
* The test suite is (IMO) sufficiently complete for REC
advancement purposes.
* The pass rate of the test suite meets CR exit criteria:
https://test.csswg.org/harness/results/css-ui-3_dev/grouped/
(minus one test, which is pending the next build of the
test-suite builder, and will be fine once that happens)
* Implementation report:
https://drafts.csswg.org/css-ui-3/implementation-report
* The DoC is up to date:
https://drafts.csswg.org/css-ui-3/issues-2017-2
]
<Rossen> https://drafts.csswg.org/css-ui-3/implementation-report
Rossen: florian sent an email yesterday summarizing state. There are
no issues open, changes are up to date. Test suite is, in
his opinion, meeting exit criteria. There is an
implementation report ^
<Rossen> https://drafts.csswg.org/css-ui-3/issues-2017-2
Rossen: DoC is up to date.
florian: Clarification. Since I wrote this there was a new test
using box-sizing with grid. That test has bugs and isn't
passing, but since it's grid I don't think we need to take
it into account. Test isn't fail/pass it's just buggy.
Rossen: Is the test necessary?
<Chris> mark the test as optional
florian: No, it's just linked because it uses box-sizing. I just
wanted to clarify.
Rossen: Reasonable.
Chris: florian I suggest we mark the test as optional.
florian: It's not optional for grid.
florian: We can't mark it as optional just for UI.
Chris: Okay. Then we just have to explain in the request.
florian: I'll update the impl report to mention that.
Chris: Everything looks great. Are there substantive changes since
last CR?
florian: Yes, there are some. I think that we might not have to
cycle CR, but that's a judgment.
Chris: My preference would be assemble a proposed PR and if it fails
cycle CR.
Rossen: Okay, that sounds great.
Rossen: Are there any reasons why we shouldn't take this to a PR?
Rossen: Chris any reasons?
Chris: Nope.
tantek: We should do it.
Rossen: Not hearing objections.
RESOLVED: Take CSS UI 3 to PR.
Rossen: Congrats to editors and all involved.
florian: Thanks tantek for giving me the shoulders to stand on to
get this done.
tantek: Thanks for all the work for the tests.
florian: Chris will you work with me on requests?
Chris: Yes. You notice I've been doing them as markdown. Is that
okay?
florian: Yes.
Chris: I'll give you the checklist after the call.
tantek: Do we have a PR template?
tantek: The markdown template, is there a blank?
Chris: No. That's a good idea.
Rossen: There was a tag on topic to this summary about UI 4.
florian: UI 4 was a delta over 3, but since 3 is kinda done I merged
in the 3 stuff to L4. I also caught up on pending actions
and warnings on unstable sections. I think that warrants a
2nd public WD. Should we?
Chris: Go for it.
Rossen: Objections?
RESOLVED: Take CSS UI 4 to an updated WD.
florian: Two follow-ups on this topic.
florian: Should we switch unversioned prefix to be L4?
Rossen: I don't see why we wouldn't.
Rossen: CSS UI 4 will be the currently worked on.
tantek: Do we have a policy of when we do that switch?
Chris: We don't. We do it when the current one worked on switches.
plinss: Policy is what's considered current. Someone looking for the
first time, where do they look.
Rossen: 3 isn't intended to move so 4 is the current.
plinss: It's no longer a delta.
florian: Yeah.
plinss: Then it should be 4.
tantek: It's reasonable to do at same time as PR request.
florian: A resolution on that would be nice.
RESOLVED: Re-point CSS UI link to CSS UI 4 spec.
<plinss> (switch css-ui to css-ui-4 done)
florian: Last, there is one thing in CSS UI that doesn't really
belong. It's box-sizing. It's a patch over from CSS2.1.
Some other spec should cover that...it should go into css
sizing I think. Once that happens we can remove the patch
from L4. For now it will be there, but I think other
editors should look into doing this.
tantek: That's a long standing request.
florian: I think it was waiting for this patch to get to REC so it's
a decent time to start looking at that.
tantek: We looked at the permalinking.
florian: Keep the section heading, but if a non-patch version starts
to exist I can point there.
plinss: No one should use unversioned short paths for permalinks.
tantek: Is there a github?
florian: No, but I'll make one.
Flexbox
-------
Rossen: Moving on. Flexbox testing.
Rossen: There was a bunch of work by gregwhitworth and company. I
called for volunteers last week. I don't think there were
updates. gregwhitworth can you summarize what you need help
with?
gregwhitworth: Melanie offered, but it would help for there to be
more people. I opened all the issues about
non-trivial stuff on github. At somebody's leisure
they could start squashing those. Melanie and I have
started pivoting in that direction. They are where
they should live. If you can do any part of if and
submit a PR it helps me out.
Chris: I can try and help depending on what else I have to do.
Rossen: Thank you Chris.
Rossen: gregwhitworth You said you needed help with bucketizing?
gregwhitworth: No, I sent it to the list yesterday.
<gregwhitworth>
https://github.com/w3c/web-platform-tests/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20%5Bcss-flex%5D%5Bspec-rec%5D
gregwhitworth: I bucketized the non-trivial ones. I need to do some
trivial stuff but these are the buckets of tests we
need. If you can help, please self-assign and
describe what you're going to do. These are the 6
categories of areas we need help.
gregwhitworth: Reach out to me if you have questions or update it on
the thread.
Rossen: Thank you gregwhitworth for this awesome work and thanks
Chris for volunteering.
Fonts 3
-------
Rossen: Next and final is Fonts.
Chris: What's happened is there are a few sections marked as at
risk. Some may need to move, some we're not sure. Seems
worthwhile to update the spec that was last published in 2013
so people know things are at risk. Means if we drop moving to
PR we're good.
Chris: I believe changes list is up to date. Maybe need to mention
more on OM stuff.
myles: I thought it was, but you're probably right I need to make
another pass.
Chris: I think it's just putting it in the changes section.
myles: Sure. And if we republish I'll need help.
Chris: Right.
Rossen: Is this CR or WD?
Chris: Updated CR with technical changes?
Rossen: When will you be ready?
Chris: I'll leave it to myles.
myles: End of the week.
Chris: Ping me when you're ready and I can send the request.
Rossen: But you want a resolution.
Chris: Yes, please.
Rossen: Objections to publish a new Fonts 3 CR spec?
RESOLVED: Publish a new Fonts 3 CR
Rossen: Thank you chris and myles for all the awesome work.
HTML
====
Change default <sup> and <sub> styling?
---------------------------------------
github: https://github.com/w3c/csswg-drafts/pull/1888
Rossen: Anyone want to take this? florian and dbaron were involved,
I know. Or myles.
myles: I can summarize.
myles: In HTML there's <sup> and <sub> that are defined in UA
stylesheet to do vertical align and reduce font size. Now
that open type fonts are available it may be that there are
specific information in the font for this.
myles: Issue proposes we change UA style sheet to turn on the font
features.
* tantek is going to go out on a limb and say there are likely major
compat issues with touching this
<tantek> perhaps experiment with MathML super/subscripts first?
fantasai: Problem with this is that it doesn't handle anything that
is nested so if you have any elements inside it like
something to an exponent and the exponent has an exponent
in it the feature won't work. So this breaks cases that
would have worked.
fantasai: We had when designing font variant feature it was decided
not to do that which is why font spec doesn't recommend
this as a replacement. Given that's the case we should
advise HTML to not make this change.
<tantek> fantasai's answer makes sense and would likely make a good
FAQ in the spec.
florian: I followed up trying to make a hybrid using font features
for first level and then fallback for nesting. I'm not sure
it handles all cases. If people want to keep investigating
if we can write such rules maybe we can look into that. I'm
not confident it's sufficient.
Chris: I think it's a good approach. The PR is sent for tests for
CSS 3 fonts actually mentions that. I think it's better to
make the single level of nesting use the open type feature
which will give you a better result in the common and if
you're complex maybe you should use MathML.
dbaron: I don't think...I think what chris suggests for top level
won't work if the font metrics are inaccurate which is
common. There's no guarantee it'll work or that a subscript
will align anywhere correct so you could distinguish the
super script of a superscript.
florian: I think it works mostly.
dbaron: It depends on how well the font metrics match the characters.
fantasai: It also doesn't handle images in the subscript so I think
there's a lot of things that will break.
myles: First, I'd like to agree with fantasai and dbaron. Apart from
that we would like some ability for the UA to use the glyphs
if it can figure out the right way. We don't think this
proposal is sufficient, but it is possible for a UA to use
these glyphs. This proposal isn't the right way but we'd like
some sort of affordance in the future.
fantasai: But that would require new CSS features. We've discussed
that in the past and people didn't want to do it. We can
re-open those discussions. We should close this request
and say you can't do that, but if you want to make a bug
against Fonts 4 or 5 to make this possible you can do that.
myles: I agree. This isn't the right place but the goal is noble.
fantasai: We appreciate the effort to incorporate better typography,
but this isn't the right place and it's not able to handle
it currently.
Rossen: Any other comments or suggestions?
Rossen: If not we can close with fantasai's suggested rec.
tantek: A couple of comments. I would suspect that changing this for
sub and sup it will break compat in unpredictable ways
since those tags have been used so long.
tantek: Second question is, I didn't see a URL to a test case that
demos what this would look like old vs new style. I think at
a minimum we need that to consider this proposal.
<fantasai> tantek's got a good point
* bradk agrees with tantek, just didn’t want to beat a dead horse
Rossen: Anyone have a test case or code that can demo this side by
side?
Rossen: I don't hear any. We can go back to the issue and wait for
the people discussing it to see if anything will come
through.
fantasai: I think tantek has a good point about how this has been
used a long time. People have tweaked their style sheet to
make these tags look better and may be relying on
vertical-align or font-size cascading through. We will
break pages if we try and change the default stylesheet.
* bradk always changes font-size, vertical-align, and relative
position in order to “fix” SUPs
fantasai: That will apply to any case where we try and make things
better unless it's really automagic.
Rossen: Anything else on this topic?
CSS Text Decor
==============
ink skipping should conform to glyph shape
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1093
<Rossen> illustration https://twitter.com/TobiReif/status/839809400529383424
fantasai: There was a complaint about how implementations, when they
cut off the underline they cut off in a straight line. You
don't want the underline to stop with a blunt edge and
then have a gap between glyph edges, you want it to follow
the edges of the glyph.
fantasai: The spec doesn't say anything specific so I was thinking
we could have advice, you should have underline edges hug
the glyph.
fantasai: There was a concern on performance which is why I'm
suggesting a should. An implementation could decide to do
it if font size is large enough, but not in general case.
That would resolve a lot of performance considerations. I
think spec should offer this advice.
<fantasai> https://www.ietf.org/rfc/rfc2119.txt
<fantasai> proposed text: "stroke endings should follow the curve of
the glyph"
myles: You can have a description of good typography. There's more
to good underlining then having it follow contours of glyph.
You'll want a larger explanation of good typography of
underlines and that doesn't feel like it should be a
normative description. It feels another spec or note.
florian: Are they big enough that they cannot be phrased as shoulds?
florian: Do you think it's too high level for normative?
myles: Yeah.
myles: If you're going to have a couple paragraphs on good
typography it shouldn't be normative.
Rossen: I'm hearing one proposal for adding the should which
suggests how a good typography works for underlining and I
heard some push back on why is this normative and not
informative somewhere.
dbaron: One comment on myles' statement. I don't want to get into a
situation where you need to be an expert in other fields to
impl the spec. The spec ought to say what you need to do to
impl. If there's advice on good typography that should be
known by an impl it should be on the WG to have that as part
of the behavior the spec describes.
myles: I think the spec does that as is.
fantasai: It describes certain necessary things. We'd like the
impl...given the option we'd say yes you should have the
curve follow the glyph curve. What follow means, you have
to think about that, but that's why we shouldn't be over
specific. That's why we word things with an appropriate
level of specificity so you know what to do.
myles: Point I was trying to make...for example if the spec says
underline should follow contour of glyph and implementors
could use mask-base and then you have underlines in the curve
of the g and that's worse typography. If you're going to have
this it needs to be much longer. If it's a general of how
underlines should work...
fantasai: Typography is very broad. If you want more description on
ways you can mess this up, that's fine. Typography of
underlines in general is out of scope for this.
myles: Right. Doing this..
fantasai: It's not out of scope for the spec. L4 has the ability to
adjust underline and will have much more detail. This
topic isn't position, this is where you don't draw a line.
A description here should assume position and thickness
was chosen already.
myles: I'm not talking position and thickness.
<dbaron> If the spec says "use the position and thickness specified
in the font metrics" then position and thickness aren't
something that implementors need to think about
Rossen: myles is your push back on adding this statement very strong
or is this something you can live with?
myles: I'm not going to object.
Rossen: Okay. And fantasai if this was a non-normative note would
you be okay or would you prefer the should?
fantasai: I'd prefer the should so it's clear to implement this is
the behavior that we want. We can add a note saying
there's things you need to watch out for and if myles
wants to point out anything not in the issue when doing
the note I can add that.
Rossen: In summary you propose to add the stroke of the underline
should follow the curve of the glyph. That's the text?
fantasai: Yes and a note to address myles's concerns.
myles: We should also add a picture because the one in the spec is
2px tall.
fantasai: Good idea. We can have some of those Gs.
dbaron: Will the note have the thing about maybe doing it only at
large font sizes?
fantasai: I can do that.
<tantek> "large" = when it uses a lot of physical pixels
<fantasai> probably px units is appropriate here, as resolutions
increase we don't want to be doing it for paragraph-size
text
Rossen: Proposed resolution: add the statement that stroke should
follow the curve of the glyph as well as adding a
non-normative note that points out anything captured in the
Github issue and add better pictures.
RESOLVED: Add the statement that stroke should follow the curve of
the glyph as well as adding a non-normative note that
points out anything captured in the Github issue and add
better pictures.
CSS Grid
========
Percentages and intrinsic size
------------------------------
github: https://github.com/w3c/csswg-drafts/issues/509
Rossen: mats added a quick explanation of what Mozilla's back
computation looks like for grid-gap.
<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296
Rossen: I want to ask if anyone is prepared to speak to this issue.
Rossen: If not we can push to next week or F2F.
rego: Last week we said we'd leave for TPAC. We need more
implementors. We resolved that we should back compute, but
anyway it needs a lot further discussion.
Rossen: I agree. It sounds like...I don't see in last week's
resolution we'll discuss for F2F. I'll tag for F2F and
remove the agenda+ for weekly calls.
Rossen: I propose we switch topics if there are any.
F2F Meetings
============
Rossen: If there's no other topics we can end early or we can
discuss mid-2018 F2F.
Rossen: Are we ready to discuss mid-2018 F2F meeting?
Rossen: If not we can push this off.
tantek: I'd like thoughts on that.
Rossen: The last discussions were about Google hosting either at
Australia or Toronto.
<tantek> +1 to both
ericwilligers: We thought we were picking Sydney and dates the week
of July 2nd
<nainar> I'm not on the call. But what ericwilligers said.
ericwilligers: Do we need to wait for someone to confirm?
Rossen: We did pick dates, but there was an open question as to if
Toronto was still on the table. That's my recollection. If
we agree it's Sydney week of July 2 we can put that on the
record and go with it.
ericwilligers: That's my understanding.
Rossen: I see nainar confirmed on IRC that's the proposal.
Rossen: Objections to having mid-2018 meeting held week of July 2nd
in Sydney with Google as host?
<tantek> for some reason I recall August, but ok with July
<nainar> I would say lets lock in July 2nd week for Sydney.
<tantek> note US Holiday July 4th
<tantek> just a note, no objection :)
RESOLVED: Have the mid-2018 meeting held week of July 2nd in Sydney
with Google as host.
Rossen: Any 4 minute topics?
Rossen: Thank you everyone and thanks Google to host us mid-2018.
We'll talk next week.
<nainar> Rossen happy to host! :)
Rossen: Please remember to add agenda, book travel, book
accommodation for F2F.
Rossen: Remember next week is different time.
<dbaron> next week's call will also be an hour earlier for Europeans
than other APAC calls
<dbaron> since Europe will have changed off summer time, but the US
won't
Received on Thursday, 26 October 2017 01:35:48 UTC