Cascading Style Sheets (CSS) Working Group Teleconference -- 25 Oct 2017

<Rossen_> we'll get going in 3-4 mins

<Rossen_> dael, https://lists.w3.org/Archives/Public/www-style/2017Oct/0042.html

<scribe> ScribeNick: dael

Rossen_: We'll be starting in 1 minute.

<Chris> myles https://github.com/w3c/web-platform-tests/pull/7972 for your review (once Travis agrees there are no more trailing spaces)

<myles> Chris: yeah, I'll look at it today

Rossen_: Let's get going. Hello everyone.
... 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.
... Any others?

Spec Rec Next Steps

Rossen_: First one is CSS 3 UI

<florian> http://www.w3.org/mid/BBBF6365-4251-426D-A3F0-4F3E7D6C48A4@rivoal.net

<Rossen_> https://drafts.csswg.org/css-ui-3/implementation-report

Rossen_: florian sent an email yesterday summerizing state. There are no issues open, changes are up to date. Test suite ism in his opinion, meeting CR criteria. THere is an impl 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 a ccount. Test isn't fail/pass it's just buggy.

Rossen_: Is the test necessary?

<Chris> mark the test as optional

florian: No, it's jsut linked because it uses box sizing. I just wanted to clarify.

Rossen_: Reasonable.

Chris: florian I suggest we marke the test as optional

florian: It's not optional for grid.
... 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 to mention that.

<rego> the issue is with the build system and JavaScript scripts, the issue is described here: https://github.com/w3c/web-platform-tests/issues/7969#issuecomment-339287076

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

Chris: My pref. would be assmenble a proposed pr and if it fails cycle CR.

Rossen_: Okay, that sounds great.

<fantasai> The build system knows that the test is linked to two specs, one of which is Grid, and which is not REC, so we can safely ignore its results for evaluating css-ui-3.

Rossen_: Are there any reasons why we shouldn't take this to a PR?
... Chris any reasons?

Chris: Nope.

<fantasai> maybe it's worth having Shepherd file such tests into a different category

tantek: We should do it.

Rossen_: not hearing objections

RESOLUTION: 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?
... The markdown template, is there a blank?

Chris: No. That's a good idea.

Rossen_: There was a tag on 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 warrents a 2nd public WD. Should we?

Chris: Go for it

Rossen_: Obj?

RESOLUTION: Take CSS UI 4 to an updated WD

florian: Two follow ups on this topic.
... Should we switch unversioned prefix to be L4?

Rossen_: I don't see why we wouldn't.
... 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 b e 4

tantek: It's reasonable to do at same time as PR request.

florian: A resolution on that would be nice.
... 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.

<Rossen_> plinss, thank you!

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

florian: No, but I'll make one.

RESOLUTION: Repoint CSS UI link to CSS UI 4 spec

Rossen_: Moving on. Flexbox testing.
... There was a bunch of work by gregwhitworth and co. I called for volunteers last week. I don't think there were updates. gregwhitworth can you summerize what you need help with?

gregwhitworth: Melanie offered, but it would helpf or more people. I opened all the issues about non-trivial stuff on GH. At somebody's leasure 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.
... 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.
... 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.
... Next and final is Fonts.

Chris: What's happend is there are a few sections marked as at risk. Some may need to move, somme 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.
... I believe changes is up to date. Maybe need to mention more on OM stuff.

myles: I thought it was, but you're prob right I need to make another pass.

Chris: I think it's just putting it in the changes section.

myles: Sure. And if we repub 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_: Obj to publish a new Fonts 3 CR spec?

RESOLUTION: Publish a new Fonts 3 CR

Rossen_: Thank you chris and myles for all the awesome work.

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

<astearns> github: https://github.com/w3c/csswg-drafts/issues/1888

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.
... Issue proposes we change UA style sheet to turn on the font features.

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

<tantek> fantasai's answer makes sense and would likely make a good FAQ in the spec

fantasai: We had when designing font varient 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 t his change.

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 i nvestigating 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 guar 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 possiblefor a UA to use these gyplhs. This prop i sn'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 peopledidn't want to do it. We can re-open those discussions. We should close this req/ 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 appriciate 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?
... If not we can close with fantasai's suggested rec.

<tantek> lol when Rossen asks that without checking the queue

<Zakim> tantek, you wanted to mention compat just because in case dbaron doesn't :) and to also mention imma let you finish your UA style sheet proposal but test cases that demonstrate

tantek: A couple of comments. I would suspect that changing this for sub and sup it will break compat in unpredicatbale ways since those tags have been used so long.

<fantasai> tantek's got a good point

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 minmum we need that to consider this proposal.

Rossen_: Anyone have a test case or code that can demo this side by side?

<fantasai> if an author, say, fusses with vertical-align on the superscripts on the page, a font-variant-position--based UA style sheet is going to break that page

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.
... That will apply to any case where we try and make things better unless it's really automagic.

Rossen_: Anything else on this topic?

ink skipping should conform to glyph shape

github: https://github.com/w3c/csswg-drafts/issues/1093

fantasai: There was a complaint about how impl, when they cut off the underline they cut off a striaght 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.
... The spec doesn't say anything specific so I was thinking we could have advice, you should have underline edges hug glyph.
... There was a concern on performance which is why I'm suggesting a should. An impl could decide to do it if font size is large enough, but not in general case. That would resolve a lot of perf 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 desc ofo good typography. There's more to good underlining then having it follow contors of glyph. You'll want a larger explination 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?
... Do you think it's too high level for normative?

myles: Yeah.
... 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 head 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 desc.

myles: I think the spec does that as is.

fantasai: It desc certain nec. 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 ex if the spec says underline shoudl follow control of glyph and impl could use mask-base and then you have underlines in the curve of the g and htat'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 desc on ways you can mess thi sup, that's fine. typography of underlines in general is out of scope for this.

myles: Right. Doing this..

fantasai: It's not out o 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 desc here should assume position and thickness was chosen already.

myles: I'm not talking position and thickness.

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.

<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_: Okay. And fantasai if this was a non-normative note would you be okay or would you pref the should.

fantasai: I'd prefer the should so it's clear to impl 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 scroke of the underline shoudl follow the curve of the glyph. That's the text?

fantasai: Yes and a note ot address myles 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 g

dbaron: Will the note have the thing about maybe doing it only at large font sizes?

fantasai: I can do that.

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 not captured in the GH issue and add better pictures.

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 GH issue and add better pictures.

Percentages and intrinsic size

github: https://github.com/w3c/csswg-drafts/issues/509

Rossen_: mats added a quick explinantion of what Mozilla's back computation looks like for grid-gap.
... I want to ask if anyone is prepared to speak to this issue.
... If not we can push to next week or F2F.

<rego> https://github.com/w3c/csswg-drafts/issues/509#issuecomment-334075296

rego: Last week we said we'd leave for TPAC. We need more impl. 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'sresolution we'll discuss for F2F. I'll tag for F2F and remove the agenda+ for weekly calls.
... I propose we switch topics if there are any.

end topic

Rossen_: If there's no other topics we can end early or we can discuss mid-2018 F2F.

<astearns> summer FTF can go to next week, which is an APAC call (so will have hosts on)

Rossen_: Are we ready to discuss mid-2018 F2F meeting?
... 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 recorda nd go with it.

ericwilligers: That's my understanding.

Rossen_: I see nainar confirmed on IRC that's the proposal.

<nainar> I would say lets lock in July 2nd week for Sydney.

Rossen_: Objections to having mid-2018 meeting held week of July 2nd in Sydney with Google as host?

RESOLUTION: have mid-2018 meeting held week of July 2nd in Sydney with Google as host

Rossen_: Any 4 minute topics?
... Thank you everyone and thanks Google to host us mid-2018. We'll talk next week.
... Please remember to add agenda, book travel, book accomodation for F2F.
... Remember next week is different time.

<nainar> Rossen_ happy to host! :)

<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

<tantek> dbaron++

<tantek> thanks nainar!

<Rossen_> nainar, thank you agian - it's always a great place to meet

<nainar> I'll also add a planning page - or is it a bit early for that?

<Rossen_> trackbot, end meeting

<dbaron> my planned meeting schedule for next year has now gone past 75,000 miles of flying already, and we haven't even scheduled many of the late-in-the-year meetings yet

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

25 Oct 2017

Attendees

Contents

Spec Rec Next Steps

Change default <sup> and <sub> styling?

ink skipping should conform to glyph shape

Percentages and intrinsic size

end topic

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output