IRC log of css on 2015-10-25
Timestamps are in UTC.
- 23:09:27 [RRSAgent]
- RRSAgent has joined #css
- 23:09:27 [RRSAgent]
- logging to http://www.w3.org/2015/10/25-css-irc
- 23:17:02 [projector_]
- projector_ has joined #css
- 23:22:37 [astearns]
- rrsagent, this meeting spans midnight
- 23:23:25 [kurosawa]
- kurosawa has joined #css
- 23:26:27 [glazou]
- glazou has joined #css
- 23:35:11 [Bert1]
- Bert1 has joined #css
- 23:37:52 [kurosawa_]
- kurosawa_ has joined #css
- 23:38:27 [liam]
- liam has joined #css
- 23:38:31 [kurosawa_]
- kurosawa_ has joined #css
- 23:41:52 [hyojin]
- hyojin has joined #css
- 23:42:07 [dwim1]
- dwim1 has joined #css
- 23:43:01 [xidorn]
- xidorn has joined #css
- 23:47:59 [hwlee]
- hwlee has joined #css
- 23:48:11 [yinagaki]
- yinagaki has joined #css
- 23:49:32 [glazou]
- glazou has joined #css
- 23:49:58 [Shinya]
- Shinya has joined #css
- 23:51:30 [projection]
- projection has joined #css
- 23:52:27 [andrey]
- andrey has joined #css
- 23:52:43 [skk]
- skk has joined #css
- 23:53:50 [Shigemi]
- Shigemi has joined #css
- 23:54:48 [shepazu]
- shepazu has joined #css
- 23:55:47 [baba]
- baba has joined #css
- 23:55:55 [sam__]
- sam__ has joined #css
- 23:56:00 [nulltask]
- nulltask has joined #css
- 23:56:30 [hitsujiwool]
- hitsujiwool has joined #css
- 23:57:14 [MaRakow]
- MaRakow has joined #CSS
- 23:58:35 [AH_Miller]
- AH_Miller has joined #CSS
- 23:58:58 [hiro__]
- hiro__ has joined #css
- 00:01:15 [projection]
- projection has joined #css
- 00:01:54 [Okabe]
- Okabe has joined #css
- 00:03:10 [AH_Miller]
- is there a WebEx also of the meeting
- 00:03:41 [zcorpan]
- zcorpan has joined #css
- 00:03:47 [Rossen]
- Zakim, remind us to go home at 6am
- 00:03:47 [Zakim]
- I don't understand 'remind us to go home at 6am', Rossen
- 00:03:48 [jchiba]
- jchiba has joined #css
- 00:03:57 [Rossen]
- Zakim, remind me to go home at 6am
- 00:03:57 [Zakim]
- I don't understand 'remind me to go home at 6am', Rossen
- 00:04:05 [dino]
- dino has joined #css
- 00:04:18 [Rossen]
- Zakim, remind me at 6am to go home
- 00:04:18 [Zakim]
- You can go home any time you like, Rossen
- 00:04:28 [dbaron]
- dbaron has joined #css
- 00:04:29 [Rossen]
- Zakim, lol
- 00:04:29 [Zakim]
- I don't understand 'lol', Rossen
- 00:04:34 [dyamada]
- dyamada has joined #css
- 00:05:55 [myles]
- myles has joined #css
- 00:06:06 [jdaggett]
- jdaggett has joined #css
- 00:06:49 [myles]
- myles has joined #css
- 00:07:49 [Florian]
- Florian has joined #css
- 00:08:30 [TabAtkins]
- INtros:
- 00:08:34 [TabAtkins]
- Peter Linss
- 00:08:38 [TabAtkins]
- Rossen
- 00:08:40 [murakami]
- murakami has joined #css
- 00:08:43 [TabAtkins]
- Matt Rakow
- 00:08:50 [TabAtkins]
- John Daggett
- 00:08:53 [TabAtkins]
- Miles Maxfield
- 00:08:56 [TabAtkins]
- Dean Jackson
- 00:08:57 [TabAtkins]
- Tomu
- 00:08:59 [TabAtkins]
- Simon Sapin
- 00:09:04 [TabAtkins]
- Shane STephens
- 00:09:05 [TabAtkins]
- TAb Atkins
- 00:09:08 [TabAtkins]
- Daniel Glazman
- 00:09:10 [TabAtkins]
- Simon Pieters
- 00:09:14 [TabAtkins]
- Johannes Wilm
- 00:09:20 [TabAtkins]
- Liam Quin
- 00:09:22 [TabAtkins]
- Bert Bos
- 00:09:25 [TabAtkins]
- Brian Birtles
- 00:09:26 [plh]
- plh has joined #css
- 00:09:28 [anssik]
- anssik has joined #css
- 00:09:28 [TabAtkins]
- Dave Cramer
- 00:09:33 [kurosawa]
- kurosawa has joined #css
- 00:09:34 [TabAtkins]
- Shinyu Murakami
- 00:09:37 [TabAtkins]
- Alan Stearns
- 00:09:38 [TabAtkins]
- Andra
- 00:09:39 [TabAtkins]
- Florian
- 00:10:02 [TabAtkins]
- Xidorn Quan
- 00:10:06 [TabAtkins]
- Koji Ishi
- 00:11:10 [Florian]
- s/Andra/Andrey/
- 00:11:20 [myles]
- s/Miles/Myles
- 00:11:38 [tfuji]
- tfuji has joined #css
- 00:11:38 [brady_duga]
- brady_duga has joined #css
- 00:11:42 [shane]
- s/STephens/Stephens
- 00:11:44 [dwim1]
- s/Tomu/Dongwoo/
- 00:11:47 [skk]
- Hiroshi Sakakibara
- 00:12:06 [baba]
- Takao Baba from BPS.
- 00:12:27 [OK]
- OK has joined #css
- 00:13:50 [jchiba]
- Junichi Chiba from BPS
- 00:14:14 [TabAtkins]
- Topic: Agenda
- 00:14:24 [TabAtkins]
- [not scribing the agenda discussion]
- 00:15:58 [TabAtkins]
- Topic: CSSOM
- 00:16:10 [TabAtkins]
- glazou: I think the CSSOM is a basis for a lot of the tuff in the WG.
- 00:16:15 [TabAtkins]
- glazou: We're adding OM to more and more modules.
- 00:16:22 [TabAtkins]
- glazou: I think it's the foundation of too much to leave unattended.
- 00:16:33 [TabAtkins]
- glazou: In particular, we need ot have it improved and possibly reimplemented for Houdini
- 00:16:40 [TabAtkins]
- glazou: I'd like us to b emore active on that front.
- 00:16:41 [johanneswilm]
- johanneswilm has joined #css
- 00:16:48 [TabAtkins]
- glazou: Fortunately I have some free time now to do so. ^_^
- 00:17:00 [Bobby]
- Bobby has joined #css
- 00:17:04 [TabAtkins]
- glazou: I think we should set a deadline for that spec, and be firm on the fact that, at that day in the future, we should have a PR for the basic OM for CSS.
- 00:17:19 [TabAtkins]
- glazou: The work on OM started long ago, and it's now a too-old effort in this WG, but we rely on it.
- 00:17:35 [TabAtkins]
- dino: What do you mean by "the OM"? We talked about typed access and othe rmodern bits. What exactly?
- 00:17:50 [TabAtkins]
- glazou: For me, the OM is the revamp of what we had in the DOM 2 Style spec.
- 00:18:03 [TabAtkins]
- glazou: Cleaner, better, simpler, with no extensions. The foundation should be cleaner.
- 00:18:15 [TabAtkins]
- glazou: Some interfaces not impl'd need to be removed.
- 00:18:29 [TabAtkins]
- glazou: Others are not interoperable, and having a Rec would help stabilizing things.
- 00:18:35 [TabAtkins]
- glazou: With a good foundation, we can improve the OM.
- 00:18:43 [TabAtkins]
- glazou: Without that we're designing new APIs without a foundation.
- 00:18:51 [TabAtkins]
- glazou: It's going to be a problem sooner or later.
- 00:19:04 [TabAtkins]
- dino: So you're suggesting codifying what exists...?
- 00:19:14 [TabAtkins]
- glazou: Taking what Simon has been doing, push that document to Rec asap.
- 00:19:27 [fantasai_]
- i/glazou: Others/fantasai: The CSS2.1 of the CSSOM/
- 00:19:44 [TabAtkins]
- Florian: Re deadline, I think it's helpful to avoi dpushing it forever, but it's only meaningful if impls are pushing. It needs to be both.
- 00:19:56 [TabAtkins]
- glazou: Agree. But without spec work, nothing will happen.
- 00:20:12 [fantasai_]
- Florian^: you need an editor driving, and also the WG responding. You have to have both, ont only one
- 00:20:14 [TabAtkins]
- glazou: We're at crossroads, and this foundation document is too old, but we really need it.
- 00:20:30 [AH_Miller]
- AH_Miller has joined #CSS
- 00:20:32 [TabAtkins]
- glazou: What we have to show is the CSS2.0 OM, which isn't interoperably impld, and sometimes not at all.
- 00:20:33 [shigeya]
- shigeya has joined #css
- 00:20:47 [TabAtkins]
- zcorpan: Also necessary is a test suite, and people working on fixing bugs in browsers.
- 00:21:12 [TabAtkins]
- glazou: So vendors, are you willing to help? Contribute tests, fixing holes, etc?
- 00:21:15 [Florian]
- Florian has joined #css
- 00:21:28 [TabAtkins]
- dino: We'd love to help impl wise. Spec-wise, not so much.
- 00:21:33 [TabAtkins]
- fantasai_: Can you help with testing?
- 00:21:44 [gsnedders]
- I know Servo has interest in tests for this.
- 00:22:04 [gsnedders]
- But they don't have that much in way of resources.
- 00:22:16 [TabAtkins]
- Florian: I think if the champions of each topic bring it to discussion, I think there's a good understanding that it needs to move forward.
- 00:22:36 [TabAtkins]
- shane: Is it possible, at this stage, for the impls to become interoperable?
- 00:22:41 [TabAtkins]
- shane: Ther'es some deep diffs.
- 00:22:42 [dino]
- dino: yes, testing is important to us and we'd contribute to a test suite.
- 00:22:59 [TabAtkins]
- Florian: I think trying to identify where we can join, and where we ccan't, is valuable.
- 00:23:14 [sena]
- sena has joined #css
- 00:23:17 [TabAtkins]
- SimonSapin: Servo is starting to impl as well, and we can bring up issues we find and write tests.
- 00:23:23 [TabAtkins]
- fantasai_: What's scope? New stuff?
- 00:23:36 [TabAtkins]
- zcorpan: Some new stuff. Some of it's impl'd, like CSS.escape().
- 00:23:47 [TabAtkins]
- zcorpan: But in general it's just old stuff.
- 00:23:53 [TabAtkins]
- zcorpan: If anythign needs to be cut, it's fine.
- 00:24:02 [dbaron]
- Isn't one of the really important pieces having a new values OM, which isn't spec'd yet?
- 00:24:08 [TabAtkins]
- fantasai_: It might be worth going thru the spec and seeing what of the old stuff isn't impl'd and needs to be dropped.
- 00:24:31 [TabAtkins]
- zcorpan: One thing is alternate style sheets. In Gecko, but I don't think anywhere else. Maybe MS?
- 00:24:38 [murakami_]
- murakami_ has joined #css
- 00:25:01 [Sangchul_]
- Sangchul_ has joined #css
- 00:25:06 [TabAtkins]
- fantasai_: We can push things that aren't impld or not interop into a level 2 diff spec, just to keep their text around. Then level 1 can just be things with at least 2 impls. If not 2 impls, the web probably doesn't depend on it.
- 00:25:28 [TabAtkins]
- glazou: The last WD is from 2013. I"d like to publish a new one asap, request feedback from community, vendors, etc, and start writing tests.
- 00:25:35 [TabAtkins]
- Rossen: How much has changed since 2013?
- 00:25:38 [TabAtkins]
- zcorpan: Not much.
- 00:26:02 [TabAtkins]
- Rossen: From Daniel's pov, your proposal is to make a spec we can publish asap with the interop core of the OM.
- 00:26:12 [TabAtkins]
- Rossen: Should be relatively straightforward with enough test coverage.
- 00:26:26 [TabAtkins]
- Rossen: Simon, between you and Glenn, do you need any help with editting?
- 00:26:51 [TabAtkins]
- zcorpan: Glenn hasn't done much since I started editting. OM hasn't been a priority for me the last 2 years, but I can def get back to it, particularly if there's impl interest in fixing bugs.
- 00:27:07 [TabAtkins]
- Rossen: I think impls like to fix bugs as long as they're not major architectural redesigns.
- 00:27:23 [TabAtkins]
- zcorpan: The problem with bugs is that there's always a risk of breaking websites.
- 00:27:42 [TabAtkins]
- zcorpan: And there's little benefit in fixing from browser pov, because the web already works.
- 00:28:08 [TabAtkins]
- Florian: From pov of Servo, etc, really valuable. Can have official behavior, with optional compat things specced, and Servo can test to see what's necessary.
- 00:28:19 [fantasai_]
- s/things/exceptions/
- 00:28:21 [TabAtkins]
- glazou: Documentation on the core OM almost doesn't exist. Basically nothings.
- 00:28:48 [TabAtkins]
- Florian: How can we engage with jQuery/etc? They probably know the diffs.
- 00:28:56 [TabAtkins]
- glazou: jQuery foundation is in the WG.
- 00:29:08 [TabAtkins]
- Florian: They probably already have tests. Maybe in the wrong shape, but.
- 00:29:20 [TabAtkins]
- shane: Going back a moment, Blink is willing to contribute tests to help.
- 00:29:38 [TabAtkins]
- fantasai_: So Simon is going to try and trim the spec, repub, request review, get jQuery to send up incompat reports.
- 00:30:06 [TabAtkins]
- fantasai_: And go through the spec every month with "the WG reviews this section". It's a big spec, but with "this month is MQ OM", etc it's easier.
- 00:30:34 [TabAtkins]
- TabAtkins: Like our 2.1 process.
- 00:30:38 [YusukeNakaya]
- YusukeNakaya has joined #css
- 00:30:52 [TabAtkins]
- fantasai_: 2.1 was a bit scattershot. We had tons of issues; didn't have to go looking for them.
- 00:31:04 [karl]
- karl has joined #css
- 00:31:26 [TabAtkins]
- Rossen: So for timeline, Simon, do you think you have time to work on this?
- 00:31:30 [gsnedders]
- There's some CSSOM tests in the presto-testo dump. I don't know how useful/relevant they are.
- 00:31:39 [AH_Miller]
- AH_Miller has joined #CSS
- 00:31:39 [TabAtkins]
- zcorpan: Yeah, certainly. Target 1 year from now to have something close to ready...
- 00:31:54 [TabAtkins]
- fantasai_: It's 11 or 12 major sections, so one a month...
- 00:32:05 [Sangchul]
- Sangchul has joined #css
- 00:32:08 [TabAtkins]
- Rossen: Let's start by IDing the core of the spec.
- 00:32:19 [TabAtkins]
- glazou: The end of our current hcarter is June 2016.
- 00:32:29 [TabAtkins]
- glazou: Would be good to have an idea of the status of this spec by that time.
- 00:32:39 [TabAtkins]
- Rossen: Is there part of the spec we can Rec today?
- 00:32:41 [sam2]
- sam2 has joined #css
- 00:32:48 [TabAtkins]
- fantasai_: Main issue is not spec, but if we have test suite.
- 00:33:14 [TabAtkins]
- zcorpan: I'm not conifendent there's such a section - not enough test coverage for any one section.
- 00:33:20 [TabAtkins]
- zcorpan: But some parts are more interop than others.
- 00:33:38 [TabAtkins]
- fantasai_: Also if we're going thru the spec from the WG, we also need QA people from the browsers converting or writing tests.
- 00:33:44 [AH_Miller_]
- AH_Miller_ has joined #CSS
- 00:33:46 [TabAtkins]
- fantasai_: So not just people in this group, people from testing too.
- 00:34:21 [TabAtkins]
- Rossen: So I guess Simon needs to refocus, and start bringing up issues that need discussion.
- 00:34:32 [TabAtkins]
- Rossen: If we're targetting end of next year, or end of charter...
- 00:34:39 [TabAtkins]
- Rossen: We'll see how it goes from there.
- 00:35:01 [TabAtkins]
- shane: Does Simon want to guide browsers in what to test, or should we be bringing up areas ourselves?
- 00:35:13 [TabAtkins]
- Rossen: Either is fine. If we ID part of the spec that's most interop, we can start from there.
- 00:35:18 [TabAtkins]
- fantasai_: We can do both.
- 00:35:32 [TabAtkins]
- Rossen: I agree that we've been neglecting this for some time.
- 00:35:50 [TabAtkins]
- glazou: I can help.
- 00:35:56 [TabAtkins]
- zcorpan: I don't mind more editors.
- 00:36:17 [TabAtkins]
- Florian: How do we coordinate between this and new Houdini stuff?
- 00:36:37 [TabAtkins]
- Florian: New things that live alongside can stay, but maybe replacements mean we can just drop the old stuff?
- 00:36:46 [TabAtkins]
- fantasai_: This will be the spec of things we can't drop.
- 00:37:06 [TabAtkins]
- shane: I don't think there is much replacement. The big thing in Houdini is the typed OM, for perf reasons. It doesn't drop the other OM.
- 00:37:14 [TabAtkins]
- Rossen: Daniel, do you want to be co-editor?
- 00:37:25 [TabAtkins]
- glazou: Not yet. Need to ramp up. Perhaps later.
- 00:37:50 [TabAtkins]
- fantasai_: So Action Items: 1. Simon goes thru the spec, maybe with help, and trim things we can drop. Then publish WD.
- 00:37:59 [TabAtkins]
- fantasai_: 2. WG reviews and submits tests.
- 00:38:07 [TabAtkins]
- fantasai_: 3. Chairs drive a schedule where we do monthly section reviews.
- 00:38:15 [andrey_]
- andrey_ has joined #css
- 00:38:24 [TabAtkins]
- Rossen: I'll contact Glenn and see what his commitment is.
- 00:38:45 [TabAtkins]
- koji: When you say OM, does that include CSSOM View?
- 00:38:47 [TabAtkins]
- zcorpan: No.
- 00:38:52 [TabAtkins]
- glazou: It's a separate topic.
- 00:40:13 [TabAtkins]
- Topic: GCPM bookmarks
- 00:40:28 [TabAtkins]
- Florian: Don't know if people remember GCPM bookmarks
- 00:40:39 [TabAtkins]
- Florian: Sets of 3 props that let you do PDF-style bookmarks.
- 00:41:01 [astearns]
- https://drafts.csswg.org/css-gcpm/#bookmarks
- 00:41:04 [johanneswilm]
- johanneswilm has joined #css
- 00:41:18 [TabAtkins]
- Florian: Bookmark-label, defaults to content. Bookmark-state, which is open or closed. And bookmark-level.
- 00:41:30 [TabAtkins]
- Florian: First, it's slightly weird in CSS. It doesn't really affect the doc's style.
- 00:41:43 [TabAtkins]
- Florian: But then there are many ways to render the doc; you can render to PDF, and have a bookmark pane.
- 00:42:07 [TabAtkins]
- Florian: This relies on the cascade/etc, so it's a slightly weird fit. Would be better with cascading attribute sheets, but we don't.
- 00:42:17 [TabAtkins]
- Florian: [missed]
- 00:42:41 [TabAtkins]
- Florian: But I was wondering about bookmark-level. Can we add an "auto" level, to work with the HTML algo, rather than setting up selectors manually?
- 00:42:41 [dsinger]
- dsinger has joined #css
- 00:43:04 [TabAtkins]
- Florian: If you, for example, use nesting+h1, it's a little difficult. The HTML outline algo defines the heading level there.
- 00:43:17 [TabAtkins]
- Florian: But there's nothing there right now. It's just none or manual.
- 00:43:20 [astearns]
- s/[missed]/listing places where this is implemented or intent to implement/
- 00:43:24 [TabAtkins]
- fantasai_: Can we do this through the UA stylesheet?
- 00:43:35 [dsinger]
- dsinger has left #css
- 00:43:54 [TabAtkins]
- Florian: Maybe. If you use h1-6 it's easy. But with h1+nesting, it's a little more complex. With nesting+mixtures of heading numbers, much harder.
- 00:43:58 [kokabe]
- kokabe has joined #css
- 00:44:13 [TabAtkins]
- Florian: HTML outline algo defines how all that works, combining nesting and numbering. Very diff or impossible to do through selectors.
- 00:44:37 [TabAtkins]
- Florian: [example of combining nesting and numbering]
- 00:45:06 [TabAtkins]
- zcorpan: The outline algo in HTML is not impl'd. The a11y techs that are supposed to benefit from it don't use it, they just expose h1-6 etc.
- 00:45:13 [fantasai_]
- fantasai^: I think you can do this with selectors, it'll just be a lot of selectors
- 00:45:31 [TabAtkins]
- zcorpan: It seems premature to create selectors for it.
- 00:45:38 [TabAtkins]
- TabAtkins: This isn't for Selectors, it's just about bookmark-level.
- 00:45:56 [TabAtkins]
- Florian: We could make a bunch of selectors in the UA stylesheet, maybe, but it's troublesome.
- 00:46:06 [TabAtkins]
- Florian: And it's HTML-specific. I'd prefer one that depends on the doc language.
- 00:47:02 [TabAtkins]
- liam: [shit, missed this due to transient internet failure]
- 00:47:15 [TabAtkins]
- liam: I support the idea that there's a use-case for explicitly marking things for PDF bookmarks.
- 00:47:32 [TabAtkins]
- Florian: Not suggesting getting rid of explicit levels. Definitely reasons to set manually.
- 00:47:48 [TabAtkins]
- Florian: But seems to be a large set of docs that you shouldn't need to do this for - you can just get it from the structure.
- 00:48:01 [fantasai_]
- liam^: When we added this to XSL:FO, we had to allow for e.g. table sand figures to appear in different levels of the ToC, some tables appearing others not, etc.
- 00:48:03 [dwim1]
- dwim1 has left #css
- 00:48:04 [TabAtkins]
- Florian: Just wanting to *add* an "auto" value.
- 00:48:22 [TabAtkins]
- dauwhe: I'd be happier with examples of docs where you can't achieve the desired effect with the existing property.
- 00:48:39 [jeff_]
- jeff_ has joined #css
- 00:48:54 [TabAtkins]
- Florian: I think for any individual doc you can do it manually. But there's a lot of information that's present.
- 00:49:03 [TabAtkins]
- dauwhe: I'd like to see if we can do it via selectors
- 00:49:07 [TabAtkins]
- TabAtkins: It's very messy.
- 00:49:54 [TabAtkins]
- fantasai_: I like the UA stylesheet. WE can tweak it later. A UA can impl it specially if they want to. And this is the easiest way to impl - just copypaste.
- 00:50:09 [TabAtkins]
- fantasai_: And authors can easily tweak.
- 00:50:31 [jchiba_]
- jchiba_ has joined #css
- 00:50:33 [sena_]
- sena_ has joined #css
- 00:50:54 [TabAtkins]
- Florian: I was wondering if we would need to use cascading properties to do additive math as we go down the tree.
- 00:51:05 [Shinya_]
- Shinya_ has joined #css
- 00:51:16 [TabAtkins]
- fantasai_: I suggest just trying to do it, first.
- 00:51:25 [TabAtkins]
- dauwhe: I'm happier with a UA stylesheet first, too.
- 00:51:34 [fantasai_]
- s/I like the UA/I prefer the UA/
- 00:51:46 [fantasai_]
- s/tweak it later/tweak it later as we find problems much more easily/
- 00:51:53 [TabAtkins]
- dauwhe: And easier to debug, if a customer doesn't understand why something has a weird level. I could just see the rule applying it.
- 00:51:59 [TabAtkins]
- Rossen: Agree. If we can do without magic, good.
- 00:52:00 [zcorpan]
- https://html.spec.whatwg.org/multipage/rendering.html#sections-and-headings is HTML's UA stylesheet for sections and headings
- 00:52:07 [fantasai_]
- s/specially/with non-CSS code (e.g. C++)/
- 00:52:07 [TabAtkins]
- Florian: Okay, I can try.
- 00:52:31 [TabAtkins]
- dauwhe: Also, given how picky people are, I'm not sure an "auto" keyword can actually satisfy enough people.
- 00:53:04 [Florian_]
- Florian_ has joined #css
- 00:53:15 [TabAtkins]
- ACTION Florian to try and implement some approximation of the outline algorithm using Selectors, for bookmark-level.
- 00:53:18 [trackbot]
- Created ACTION-726 - Try and implement some approximation of the outline algorithm using selectors, for bookmark-level. [on Florian Rivoal - due 2015-11-02].
- 00:53:29 [TabAtkins]
- dauwhe: This material officially leaves in Generated Content, not in GCPM.
- 00:53:34 [TabAtkins]
- Rossen: I'll remove it from GCPM.
- 00:53:42 [fantasai_]
- s/I'll/Then let's/
- 00:53:44 [TabAtkins]
- s/I'll/Go ahead and/
- 00:53:45 [Mitsumasa]
- Mitsumasa has joined #css
- 00:54:03 [dyamada]
- dyamada has joined #css
- 00:54:03 [TabAtkins]
- johanneswilm: Are people other than the publishing programs even thinking of bookmarks?
- 00:54:04 [Bert1]
- -> https://drafts.csswg.org/css-content-3/#css-bookmarks Bookmarks (for PDF)
- 00:54:30 [dwim1]
- dwim1 has joined #css
- 00:54:38 [TabAtkins]
- Topic: CSS style attr
- 00:54:55 [astearns]
- http://www.w3.org/mid/737F97AF-69E2-41DD-A047-E71012B81B71@rivoal.net
- 00:54:57 [TabAtkins]
- Florian_: There's a bug in the spec's markup, and confuses Bikeshed.
- 00:55:07 [plh]
- plh has joined #css
- 00:55:09 [TabAtkins]
- Florian_: There was an action, but nothing happened.
- 00:55:13 [SimonSapin]
- dauwhe, https://drafts.csswg.org/ lists "Generated Content" which links to GCPM. Is there another Generated content?
- 00:55:17 [TabAtkins]
- fantasai_: If it's just a markup fix, Bert can do it inline.
- 00:55:42 [TabAtkins]
- Bert1: As long as it's just a markup fix, yeah.
- 00:56:11 [TabAtkins]
- Florian_: Yeah, "style attribue" was just <dfn>'d twice. I removed the tag from one.
- 00:56:18 [TabAtkins]
- Topic: Inline character grid.
- 00:56:25 [TabAtkins]
- Florian_: This was brought up last night.
- 00:56:35 [TabAtkins]
- Florian_: Line Grid has a strict arrangement of lines.
- 00:56:48 [TabAtkins]
- Florian_: In CJK, they do similarly with characters in the inline dimension.
- 00:56:52 [liam]
- liam has joined #css
- 00:57:07 [TabAtkins]
- Florian_: This is probably not something to tackle right now (tho I"d be happy to think about it), but there's some small steps we can take now.
- 00:57:25 [hitsujiwool]
- hitsujiwool has joined #css
- 00:57:54 [TabAtkins]
- Florian_: If the line length is a multiple of the CJK character width, then justifying works. Fine for pure CJK, and works right when mixing in Latin.
- 00:58:16 [TabAtkins]
- Florian_: So I suggest being able to define some max-width thing that goes up as a step function of the CJK size.
- 00:58:23 [dino]
- dino has joined #css
- 00:58:37 [TabAtkins]
- fantasai_: Ther'es two places you might need to put space - padding or margin.
- 00:58:53 [TabAtkins]
- fantasai_: Agree that it should be solved, but don't have a concrete proposal that would address the concern.
- 00:59:07 [TabAtkins]
- Florian_: I have two questions, and maybe answers.
- 00:59:47 [TabAtkins]
- Florian_: Does the extra space go to padding or margin?
- 00:59:51 [TabAtkins]
- TabAtkins: Can't box-sizing do this?
- 01:00:01 [TabAtkins]
- fantasai_: Don't think so - you're always sizing the content box.
- 01:00:31 [TabAtkins]
- fantasai_: If you have a max-width of 90px, and available space 100px, the 10px will go outside (margin). But we might want it to be inside (padding).
- 01:00:49 [TabAtkins]
- fantasai_: And if there's space, how to align content? We have the alignment properties to handle that.
- 01:01:10 [TabAtkins]
- fantasai_: So as we limit the length of the line, are we leaving the padding in place, or are we pulling the border-box in with us?
- 01:01:17 [TabAtkins]
- fantasai_: I think just working with max-width works.
- 01:01:22 [TabAtkins]
- fantasai_: Just do it as a step increment.
- 01:01:45 [TabAtkins]
- fantasai_: Imagine you're in a box, and want the bgcolor to fill the box. Padding to give you some space.
- 01:01:55 [TabAtkins]
- fantasai_: If you pull in the border-edge to satisfy a max-width, you have a gap you weren't expecting.
- 01:02:15 [TabAtkins]
- Florian: So look at use-cases, I guess.
- 01:02:36 [Florian_]
- Florian_ has joined #css
- 01:02:38 [TabAtkins]
- Florian: So does this look like a property, or as a value?
- 01:02:43 [TabAtkins]
- TabAtkins: Look at use-cases. ^_^
- 01:03:20 [TabAtkins]
- jdaggett: I think you need to be more specific. And I have some concerns that this might be hacky, but I can't say that firmly until I see something.
- 01:03:21 [fantasai_]
- I'd talk to some CJK CSS authors
- 01:03:41 [TabAtkins]
- Hiroshi: If we want to discuss char grid, do we need a draft spec for it?
- 01:03:48 [TabAtkins]
- Hiroshi: Is it good for this group?
- 01:04:00 [TabAtkins]
- fantasai_: The actual Character Grid, we're not tackling yet. Line Grid first.
- 01:04:15 [TabAtkins]
- fantasai_: This is a smaller issue of measurement - just making sure the context box is an integer number of chars wide.
- 01:04:28 [TabAtkins]
- fantasai_: Easier topic.
- 01:05:11 [TabAtkins]
- fantasai_: [reiterating the discussion]
- 01:05:28 [katashin]
- katashin has joined #css
- 01:05:51 [TabAtkins]
- Florian_: So based on that, I think getting the CJK community to look for examples, and find where the space wants to go.
- 01:06:08 [TabAtkins]
- Florian_: If everyone wants the same thing, then easy. If different, we need a switch.
- 01:06:25 [TabAtkins]
- fantasai_: I say don't look at "documents", but at magazines and websites, and think about them as the page changes size.
- 01:06:39 [TabAtkins]
- Rossen: I'm assuming you already have test-cases.
- 01:06:56 [MaRakow]
- MaRakow has joined #CSS
- 01:06:58 [TabAtkins]
- Hiroshi: Yes, can help gather and send to the group.
- 01:07:08 [wilhelm_]
- wilhelm_ has joined #css
- 01:07:20 [fantasai_]
- TabAtkins: Been discussion before about min() max() functions or floor() ceiling() functions
- 01:07:31 [fantasai_]
- TabAtkins: Rejected in past because can reverse layout constraints
- 01:07:41 [fantasai_]
- TabAtkins: You no longer have a linear function for the size, it's piecewise linear
- 01:07:48 [fantasai_]
- TabAtkins: much harder to handle in sizing algorithms
- 01:07:55 [fantasai_]
- TabAtkins: dbaron can elaborate more
- 01:08:13 [fantasai_]
- Florian_: One way to deal with that would be to limit just the line length
- 01:08:21 [fantasai_]
- Florian_: Whether or not that addresses use cases ...
- 01:08:30 [kurosawa]
- kurosawa has joined #css
- 01:08:39 [TabAtkins]
- fantasai_: Related issue is shrink-wrapping.
- 01:09:02 [TabAtkins]
- fantasai_: When you shrinkwrap, we follow the formula of max(min-content, min(max-content, available space))
- 01:09:36 [dholbert]
- dholbert has joined #css
- 01:09:38 [TabAtkins]
- fantasai_: If you're doing line-breaking, taht can get you to a position where you have a lot of extra space in your element that doesn't need to be there, because you wrapped. (Some big items get wrapped, leave a big gap at the end of th eline.)
- 01:09:49 [TabAtkins]
- fantasai_: This happens a lot with text-wrap: balance.
- 01:09:55 [TabAtkins]
- fantasai_: [draws diagram]
- 01:10:15 [TabAtkins]
- fantasai_: Four large words in the element. max-content slightly overflows.
- 01:10:29 [TabAtkins]
- fantasai_: shrinkwrap is two-lines tall. Three items on one line, one item on next.
- 01:10:45 [TabAtkins]
- fantasai_: For "balance", you want two items on each line, and shrinkwrapped to the width of that.
- 01:11:03 [TabAtkins]
- fantasai_: What you get instead is still width of available space, with tons of empty space.
- 01:11:04 [dauwhe]
- SimonSapin: https://drafts.csswg.org/css-content/
- 01:11:29 [TabAtkins]
- Florian_: Does this mean the shrinkwrap formula needs to be enhanced?
- 01:11:40 [TabAtkins]
- fantasai_: It used to be, in distant past, but for perf reasons we moved to this simpler one.
- 01:11:55 [TabAtkins]
- fantasai_: But we will need some way to opt this later.
- 01:12:32 [TabAtkins]
- astearns: For example, a background behind a "balanced" box that's sized to the line length, not the full available space.
- 01:12:49 [TabAtkins]
- astearns: In the last pub of LIne Grid, I stripped it to what i think is the minimum necessary step.
- 01:13:10 [TabAtkins]
- astearns: The Line Grid and Line Snapping are ready to impl. Box snapping might still need spec work.
- 01:13:18 [TabAtkins]
- astearns: So, vendors, take a look and I think it's mostly ready.
- 01:13:30 [TabAtkins]
- FLORIAN: What di dyou remove?
- 01:13:41 [TabAtkins]
- astearns: Character gried, and some things that dealt with the issue you brought up.
- 01:13:55 [shane]
- s/gried/grid
- 01:14:09 [dbaron_]
- dbaron_ has joined #css
- 01:14:13 [shane]
- s/di dyou/did you/
- 01:14:15 [TabAtkins]
- Rossen: So action the group to have impls review.
- 01:14:17 [Florian_]
- Florian_ has joined #css
- 01:14:26 [TabAtkins]
- fantasai_: I think it needs more work, but getting impl eyes on it would be useful.
- 01:15:12 [TabAtkins]
- Rossen: Agreed. Table discussion yesterday concluded that even something simple, where lines are a multiple of some size, would be sufficient.
- 01:15:17 [jchiba_]
- https://www.dropbox.com/s/f6h3bq0wigul1tk/shrink-wrap.jpg
- 01:15:45 [TabAtkins]
- [discussion of various things that make line-height not sufficient to do simple line grid]
- 01:16:13 [TabAtkins]
- <br duration=15m type=coffee>
- 01:24:59 [adenilson]
- adenilson has joined #css
- 01:25:21 [jihyer]
- jihyer has joined #css
- 01:25:44 [jihye]
- jihye has joined #css
- 01:29:29 [myles]
- myles has joined #css
- 01:43:04 [dwim1]
- dwim1 has joined #css
- 01:44:07 [kurosawa]
- kurosawa has joined #css
- 01:44:35 [jdaggett]
- http://typeproject.com/fonts/tpmincho
- 01:46:50 [AH_Miller]
- AH_Miller has left #css
- 01:47:09 [dholbert]
- dholbert has joined #css
- 01:47:13 [AH_Miller]
- AH_Miller has joined #CSS
- 01:52:35 [sena]
- sena has joined #css
- 01:55:35 [johanneswilm]
- johanneswilm has joined #css
- 01:56:08 [kokabe]
- kokabe has joined #css
- 01:56:28 [dbaron]
- ScribeNick: dbaron
- 01:57:06 [murakami]
- murakami has joined #css
- 01:57:07 [dbaron]
- Topic: font-weight-adjust
- 01:57:08 [dbaron]
- Florian: There's an ongoing thread about font-weight-adjust.
- 01:57:11 [astearns]
- http://www.w3.org/mid/F1E15038-FA2D-485D-B328-089293E691AC@rivoal.net
- 01:57:36 [shigeya]
- shigeya has joined #css
- 01:57:40 [dbaron]
- Florian: If you're trying to pair fonts in a document, and have font that looks the way you want, we can adjust when x-heights don't match using font-size-adjust
- 01:58:09 [dbaron]
- Florian: We have a similar problem with font-weight. You might want to match 2 different fonts with different ways in the document -- or especially with fallback (doesn't load; Unicode ranges).
- 01:58:23 [dbaron]
- Florian: If the pairing of fonts is to your taste except font weights don't match, then you have an issue
- 01:58:53 [dbaron]
- Florian: font weights have numeric value, but the number doesn't have a meaning against some measurement
- 01:59:06 [dbaron]
- Florian: want a way to say 400 weight for main font but 600 weight for fallback
- 01:59:10 [katashin]
- katashin has joined #css
- 01:59:12 [dbaron]
- Florian: John doesn't seem to agree on problem or the solution
- 01:59:23 [dbaron]
- Florian: I understand disagreeing about solution; more confused about disagreeing about problem
- 01:59:44 [dbaron]
- John: If you go across different scripts, e.g., Latin to CJK, or Thai, Arabic, pairing typefaces is a classic design problem for type design.
- 02:00:18 [dbaron]
- John: IT's not a simple problem to solve. Type designers spend a lot of time thinking about how to express voice of one typeface in a different script.
- 02:00:20 [shigemi]
- shigemi has joined #css
- 02:00:23 [dbaron]
- John: IT's not just weight
- 02:00:32 [Bobby]
- Bobby has joined #css
- 02:00:42 [dbaron]
- John: What I don't agree with in the formulation of the problem is the notion that you're using a single font list for all languages
- 02:01:09 [dbaron]
- John: That's what people do, but it's not the right thing to be doing. Right thing: if you have content in Japanese, use appropriate Japanese typeface; content in Greek, use appropriate Greek typeface.
- 02:01:22 [dbaron]
- John: Ideally those are all typefaces you selected that support the specific script.
- 02:01:39 [YusukeNakaya]
- YusukeNakaya has joined #css
- 02:01:42 [dbaron]
- John: Making a design decision for each language...
- 02:01:51 [dbaron]
- John: You could make universal font list work, but not ideal.
- 02:02:06 [dbaron]
- John: Matching on weight is difficult. A particular weight in a typeface may be difficult to match with a different typeface.
- 02:02:32 [dbaron]
- John: When you're talking about a fallback situation, not providing a webfont, stuck with a tough problem. The way the typeface is designed used a different set of principles, so just matching weight won't get you much.
- 02:02:42 [zcorpan]
- q+
- 02:02:52 [dbaron]
- Florian: I agree just matching weight won't get you much. I don't see why it's useful to have the size adjust and not have this one.
- 02:03:01 [Bert]
- q-
- 02:03:18 [dbaron]
- John: size is a linear scale; weight is not consistent across fonts
- 02:03:21 [hwlee]
- hwlee has joined #css
- 02:03:27 [dbaron]
- John: one family may have regular and bold; another family may have broader range
- 02:04:05 [dbaron]
- John: size is consistent with a little tweak; font-size-adjust gets you that. Weight is not consistent. Taking a font designed one way, comparing to other family not designed with same principles, won't get something that matches.
- 02:04:19 [dbaron]
- John: Example I wanted to show: http://typeproject.com/fonts/tymincho
- 02:04:41 [dholbert]
- dholbert has joined #css
- 02:04:47 [dbaron]
- John: They've designed a range of font families. There's a high-contrast face. Contrast is how thickness of vertical stems compares to thickness of horizontal stems.
- 02:05:02 [dbaron]
- John: Can see simila construction of Latin typefaces.
- 02:05:14 [dbaron]
- John: Bottom one is a low contrast face. The verticals and horizontals are roughly comparable.
- 02:05:33 [dbaron]
- John: Going from one face with different contrast to a family without that same contrast, no matter what the weight is, won't get something that's matching.
- 02:05:49 [dbaron]
- John: That weight value doesn't move well across families.
- 02:05:59 [dbaron]
- Florian: Isn't that also true about size adjustment?
- 02:06:27 [dbaron]
- John: The step function, the weights available, is going to be different. With font-size-adjust, can tweak the size a tab and get something comparable. Though not a be-alland-end-all solution.
- 02:06:35 [dbaron]
- John: I don't think what you're proposing is going to work in practice.
- 02:06:59 [dbaron]
- John: What Jonathan was saying on the list: if you want to do something like this, pair a Latin face with faces from different locales, you can do something like this already using @font-face rules with local().
- 02:07:05 [dbaron]
- (sorry, typing the link from screen)
- 02:07:09 [adenilson]
- adenilson has joined #css
- 02:07:20 [dbaron]
- tymincho -> tpmincho
- 02:07:42 [shane]
- s/http://typeproject.com/fonts/tymincho/http://typeproject.com/fonts/tpmincho/
- 02:08:09 [dbaron]
- Florian: If you were to use a mechanism like that, have to use fonts side by side. For most random pairing of fonts, no [...]. Just like for size adjustment need to look side-by-side and pick specific value.
- 02:08:10 [astearns]
- http://typeproject.com/fonts/tpmincho
- 02:08:19 [Rossen]
- q
- 02:08:31 [Bert1]
- q?
- 02:08:36 [dbaron]
- zcorpan: As I understand it, the ability to use different fonts for different languages is orthogonal; you can do that with :lang() selector.
- 02:08:58 [dbaron]
- zcorpan: This is only the case where you want to fix font weights between primary font and fallback font, only have 2 fonts for one specific language to deal with.
- 02:09:04 [Bert1]
- ack zcorpan
- 02:09:07 [dbaron]
- zcorpan: I don't see that this is trying to fix everything with one mechanism.
- 02:09:21 [dbaron]
- zcorpan: I think this is just fixing weight of primary font vs. fallback font.
- 02:09:30 [dbaron]
- John: You think this mechanism makes sense?
- 02:09:52 [katashin]
- katashin has joined #css
- 02:09:53 [dbaron]
- zcorpan: Not saying proven to be necessary, but I think the argument that it won't fix ... that you should be doing language-specific instead is orthogonal.
- 02:10:01 [dauwhe]
- q?
- 02:10:10 [SteveZ]
- SteveZ has joined #css
- 02:10:11 [SteveZ]
- q+
- 02:10:13 [dbaron]
- John: If you're doing it languagespecific, you can say that for bold you want a particular weight
- 02:10:25 [dauwhe]
- q+
- 02:10:32 [sam__]
- sam__ has joined #css
- 02:10:45 [dbaron]
- John: The only way to pair faces from different fonts is to know those actual fonts.
- 02:10:53 [dbaron]
- John: so you can use @font-face with local()
- 02:11:06 [dbaron]
- John: To match what he's talking about, you have to know the faces.
- 02:11:07 [TabAtkins]
- q+
- 02:11:12 [TabAtkins]
- ack SteveZ
- 02:11:13 [zcorpan]
- q-
- 02:11:46 [dbaron]
- Steve: I wanted to say 2 things. font-size-adjust doesn't really do all the adjustments you want; doesn't deal with Thai, which has small x-height on some letters due to additions above and below, so matching a Latin face to Thai using the same font size typically looks ugly; Arabic has similar types of problems.
- 02:11:58 [MaRakow]
- MaRakow has joined #CSS
- 02:12:02 [dbaron]
- Steve: My concern overall is that all of these quick fixes work well for Latin text but don't work well for international text.
- 02:12:22 [zcorpan]
- s/won't fix .../won't fix everything and/
- 02:12:24 [dbaron]
- Steve: Trying to fix each problem means we end up with large number of properties: then you'll want contrast, and then how do they interact when all specified?
- 02:12:54 [dbaron]
- Steve: Makes more sense to put in a language map, where some properties will allow you to pick specific things for the language, rather than doing cleve things that do matching without understanding what's going on.
- 02:13:16 [dbaron]
- Florian: In that direction, John was saying in some cases use language tagging and in some cases use @font-face.
- 02:13:30 [dbaron]
- Florian: What I didn't understand was for Web fonts (not local fonts), does the fragment identifier thing work?
- 02:13:45 [dbaron]
- John: I don't understand why font packaging came up in that thread. It's orthogonal to that issues.
- 02:13:52 [zcorpan]
- q?
- 02:14:08 [dbaron]
- John: Doesn't matter whether a font is packaged or separate fonts. No current browser supports TrueType collections
- 02:14:22 [dbaron]
- Florian: Your mechanism only works for local fonts.
- 02:14:45 [ChrisL]
- ChrisL has joined #css
- 02:15:56 [dbaron]
- dbaron: [explains about @font-face rules each being a single face with a single weight]
- 02:16:16 [dbaron]
- John: TrueType collections is a simple format; just a bunch of offsets for the fonts; effectively still loading individual fonts
- 02:17:41 [dbaron]
- Florian: If we were to have @font-face rules that pointed to a collection, then this would be a problem
- 02:17:49 [dbaron]
- John: But this has little bearing on the original case
- 02:18:05 [glazou]
- hey ChrisL :-)
- 02:18:05 [dbaron]
- John: But to be clear, there will never be a format where a single @font-face rule points to a set of fonts rather than a singel face.
- 02:18:28 [dbaron]
- dauwhe: Do you have examples of sites that are visually confusing now because of problems matching weights on fallbacks?
- 02:18:40 [ChrisL]
- we will have @font-face rules that point to a TTC. But they will use fragids to point to individual faces, not the collection as a whole.
- 02:18:46 [dbaron]
- dauwhe: I've been trying to construct examples with fonts on my machine, but haven't been able to yet.
- 02:18:55 [jeff_]
- jeff_ has joined #css
- 02:18:56 [bob]
- bob has joined #css
- 02:19:17 [dbaron]
- Florian: Have seen examples within bloomberg, with requirement to use latin font for all latin and digits even in other languages; digits match badly against CJK font.
- 02:19:27 [dbaron]
- Florian: The correct answer may be to use digits in the CJK font.
- 02:19:35 [astearns]
- ack dauwhe
- 02:19:36 [dbaron]
- John: Going between Latin and CJK generally want a different size altogether.
- 02:19:51 [dbaron]
- John: If you're going to support multiple locales on a site, decision about attribute and typeface to use is a design decision.
- 02:20:35 [dbaron]
- Florian: As a design decision, you have latin letters in the CJK that you want to match... to adjust. You could say not to use the Latin font, but their design decision is to use the Latin font everywhere.
- 02:20:48 [dbaron]
- John: It's difficult to take 2 typefaces designed to different principles together.
- 02:21:15 [dbaron]
- Florian: That specific example, the most glaring example was weight; fixing weight wouldn't make it perfect, but probably tolerable for most readers.
- 02:21:31 [dbaron]
- Florian: I think using @font-face is adequate for solving this.
- 02:21:59 [dbaron]
- John: Apple's UI font has an explicit cascade list set up. If you are drawing in UI in the system font, and hit different script, there's a chain of postscript names that idientifies all the fonts that will be used as falllbacks
- 02:22:03 [ChrisL]
- +1 @font-face suffices for this
- 02:22:20 [dbaron]
- John: That's a controlled environment, they know the set of fonts.
- 02:22:42 [dbaron]
- Florian: Apple is not the only case where there's a controlled environment. Webfonts can also be controlled environment.
- 02:22:47 [dbaron]
- John: You can do the same thing using ...
- 02:23:00 [dbaron]
- Florian: I was unclear about collections (that's cleared up); I'm still fuzzy about sizing part of it.
- 02:23:07 [dbaron]
- Florian: We can try to see if that works.
- 02:23:20 [astearns]
- ack TabAtkins
- 02:23:39 [dbaron]
- Tab: I agree with John; unless using @font-face is really bad or hard to work with, we should stick with @font-face instead of duplicating functionality.
- 02:23:43 [dbaron]
- ??: I also agree with that.
- 02:23:57 [astearns]
- s/??/myles/
- 02:23:59 [myles]
- yes
- 02:24:24 [dbaron]
- Topic: finding the next topic
- 02:24:37 [dbaron]
- Topic: CSS Fragmentation
- 02:24:57 [shigeya_]
- shigeya_ has joined #css
- 02:25:06 [dbaron]
- fantasai: maybe wait for hober since he raised it
- 02:25:16 [dbaron]
- Topic: finding the next topic
- 02:25:29 [dbaron]
- fantasai: Want r12a here for logical stuff
- 02:26:36 [TabAtkins]
- ScribeNick: TabAtkins
- 02:26:43 [TabAtkins]
- Topic: Box Alignment
- 02:26:57 [yinagaki]
- yinagaki has joined #css
- 02:27:43 [TabAtkins]
- fantasai_: There's a lot of values in this spec.
- 02:27:57 [TabAtkins]
- fantasai_: The ones we need to keep are positional alignment, baseline value, and the distributed-alignment keywords.
- 02:28:08 [TabAtkins]
- fantasai_: The major point where I'm pretty unsure is the overflow-alignment keywords.
- 02:28:29 [TabAtkins]
- fantasai_: If you try to use margins for alignment, you do "safe" alignment - if you're bigger than container, you don't center or end-align, you always start align.
- 02:28:29 [shigeya]
- shigeya has joined #css
- 02:28:30 [jeff__]
- jeff__ has joined #css
- 02:28:42 [TabAtkins]
- fantasai_: In Flexbox/Grid, you're aligned absolutely, so you can overflow off the start edge.
- 02:28:53 [TabAtkins]
- fantasai_: Margins do that because you can't scroll to content that overflows the start edge *of the viewport*.
- 02:29:05 [TabAtkins]
- fantasai_: So margins might not always center, but it ensures it won't overflow to the unscrollable area.
- 02:29:26 [TabAtkins]
- fantasai_: So one issue is, what should the alignment properties do on layout models other than Flexbox/Grid? Should they be consistent, or use the margin behavior?
- 02:29:49 [TabAtkins]
- fantasai_: Second issue is, whatever the default is, do we need a switch to change, or need some other solution to let the user reach the content in the unscrollable region?
- 02:30:14 [TabAtkins]
- fantasai_: So, what should the default behavior of the alignment properties be?
- 02:30:55 [TabAtkins]
- TabAtkins: I'm for simplicity, so I'm okay with them all being "true".
- 02:31:12 [dholbert]
- dholbert has joined #css
- 02:31:27 [TabAtkins]
- dbaron: I guess I'm okay with them all being "true" by default.
- 02:31:44 [TabAtkins]
- dbaron: Tho, it's a little bit of a footgun, but it is easier to understand.
- 02:32:33 [TabAtkins]
- TabAtkins: Agree - I've had authors ask me about centered Flexbox overflowing off-screen, so I had to tell them to use margins. But it's annoying to *not* do true, too.
- 02:33:20 [TabAtkins]
- szilles: [question about center on text]
- 02:33:38 [TabAtkins]
- szilles:It's clear what overflowing off the flow direction, means.
- 02:33:53 [TabAtkins]
- szilles: But less sure aobut what overflowing means from a wrap point of view.
- 02:34:26 [TabAtkins]
- fantasai_: That's a different issue; these don't apply to text.
- 02:34:31 [TabAtkins]
- fantasai_: Anyone object to making everything "true"?
- 02:34:35 [TabAtkins]
- [no objection]
- 02:34:44 [TabAtkins]
- dbaron: I'm okay with it, given that you can specify the "safe" behavior.
- 02:35:15 [TabAtkins]
- RESOLVED: All layout modes use "true" alignment by default for the alignment properties.
- 02:35:30 [TabAtkins]
- fantasai_: Now, is the current safe/true switch what we want, or do we want something even smarter?
- 02:35:43 [TabAtkins]
- fantasai_: Or is there some other solution to the problem of centered things overflowing into the usncrollable region?
- 02:36:48 [TabAtkins]
- TabAtkins: I doubt we'll be able to come up with a general solution to unscrollable areas.
- 02:37:00 [TabAtkins]
- TabAtkins: But I'm fine with the current switch. A little footgunny, but probably fine.
- 02:37:56 [TabAtkins]
- fantasai_: So is everyone fine with the current switch syntax? Or just have the "safe" keyword, and make unspecified be true?
- 02:38:09 [TabAtkins]
- dbaron: We might eventually want to apply this to text-align, which defaults to safe.
- 02:38:20 [TabAtkins]
- szilles: I think it's better to have authors specify what they mean.
- 02:38:32 [TabAtkins]
- fantasai_: Too late for that unfortunately - the properties already allow it to be omitted in impls.
- 02:39:08 [TabAtkins]
- fantasai_: [discusses serialization]
- 02:39:13 [shepazu]
- shepazu has joined #css
- 02:39:27 [TabAtkins]
- fantasai_: If you write "true center", it'll serialize back to just "center", since omitted defaults to "true".
- 02:40:09 [dsinger]
- dsinger has joined #css
- 02:40:29 [TabAtkins]
- TabAtkins: So per dbaron's argument, I think it's fine to leave "true" here. We don't need it yet, but it'll simplify merging in more alignment properties later.
- 02:40:40 [dsinger]
- dsinger has left #css
- 02:40:48 [fantasai_]
- szilles: +1
- 02:40:52 [dsinger]
- dsinger has joined #css
- 02:40:55 [fantasai_]
- dbaron: true looks like a boolean ...
- 02:41:00 [TabAtkins]
- [bikeshedding "true"]
- 02:41:05 [fantasai_]
- fantasai^: anyone want to bikeshed the keywords?
- 02:41:05 [dsinger]
- dsinger has left #css
- 02:41:30 [TabAtkins]
- literal, exact, always, dwim, honored
- 02:42:00 [fantasai_]
- force?
- 02:42:19 [TabAtkins]
- even-if-overflow
- 02:42:28 [dbaron]
- unsafe?
- 02:42:45 [TabAtkins]
- Action tab to write poll about naming of "true" keyword, using suggestions in the minutes.
- 02:42:45 [trackbot]
- Created ACTION-727 - Write poll about naming of "true" keyword, using suggestions in the minutes. [on Tab Atkins Jr. - due 2015-11-02].
- 02:43:23 [TabAtkins]
- fantasai_: I remember why we had it vary per el - we wanted to do <center>/etc thru these properties, and they needed to be safe.
- 02:43:34 [TabAtkins]
- fantasai_: But maybe we can key that to "legacy".
- 02:43:45 [TabAtkins]
- TabAtkins: Or just drop it, like we discussed, and handle <center> somehow else, or not at all.
- 02:43:53 [TabAtkins]
- fantasai_: Yeah, so we'll discuss that with dbaron later.
- 02:44:10 [dbaron]
- SimonSapin, it's not all that different...
- 02:44:16 [bkardell_]
- bkardell_ has joined #css
- 02:44:16 [TabAtkins]
- fantasai_: So really we're just blocked on review.
- 02:44:58 [TabAtkins]
- action everyone to provide feedback for the Align spec.
- 02:44:58 [trackbot]
- Error finding 'everyone'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
- 02:45:47 [Bert1]
- q+
- 02:46:02 [dbaron]
- $ grep "Date:" */Overview.bs
- 02:46:03 [dbaron]
- css-align/Overview.bs:Date: 2014-12-18
- 02:46:03 [dbaron]
- css-egg/Overview.bs:Date: 2015-04-01
- 02:46:03 [dbaron]
- css-grid/Overview.bs:Date: 2015-09-17
- 02:46:04 [dbaron]
- css-pseudo/Overview.bs:Date: 2015-01-15
- 02:46:04 [dbaron]
- css-text-decor/Overview.bs:Date: 2014-03-20
- 02:46:05 [dbaron]
- css-variables/Overview.bs:!Date: 2014-05-06
- 02:46:37 [shepazu]
- shepazu has joined #css
- 02:46:40 [TabAtkins]
- Bert1: There's two kinds of "true" centering for text - overflow to the left, and ignoring floats - center text while ignoring images on the side.
- 02:47:22 [fantasai_]
- fantasai: That's tricky, because currently text-align only distributes extra space on the line after line breaking
- 02:47:22 [TabAtkins]
- fantasai_: That's tricky, because it affects text-wrapping.
- 02:47:50 [fantasai_]
- s/That's tricky, because/But this would/
- 02:47:52 [TabAtkins]
- TabAtkins: Maybe that's a separate ability, then - the ability to ignore floats for line-length determination. Then you can still just safe-align or something.
- 02:48:07 [shepazu]
- shepazu has joined #css
- 02:48:45 [TabAtkins]
- Topic: Dev meetup in Sydney
- 02:49:04 [TabAtkins]
- Bert1: Sydney has John Allsopp, the Web Directions conf guy, and he can organize something if we want.
- 02:49:13 [TabAtkins]
- Bert1: So do we want to attend that, or speak at it?
- 02:49:42 [TabAtkins]
- [discussing Sydney meeting timing]
- 02:49:50 [TabAtkins]
- Rossen: So this meetup will happen one of the SVG meeting days?
- 02:49:58 [TabAtkins]
- Rossen: And this is somewhere in Sydney, tbd
- 02:50:11 [TabAtkins]
- Bert1: Yeah, depending on how big we want it to be. John Allsopp has some space...
- 02:50:14 [TabAtkins]
- dino: It's tiny.
- 02:50:25 [TabAtkins]
- shane: We can probably offer a venue for this.
- 02:50:39 [TabAtkins]
- Rossen: Do you ahve a big enough space?
- 02:50:44 [TabAtkins]
- shane: It can hold 150 people.
- 02:50:50 [TabAtkins]
- shane: I'll need to confirm it, but it shoudl be fine.
- 02:50:57 [TabAtkins]
- Rossen: So what day is it?
- 02:51:14 [AH_Miller]
- AH_Miller has left #css
- 02:51:22 [TabAtkins]
- shane: Feb 3rd is FXTF. Maybe best overlap?
- 02:51:31 [TabAtkins]
- astearns: Then, people who need to leave might still be able to make it.
- 02:52:07 [dbaron]
- dbaron has joined #css
- 02:52:29 [TabAtkins]
- Rossen: So idea is that, on Wed (feb 3), we'll have the biggest mass of standards people. All SVG, CSS, and maybe some Houdini.
- 02:52:40 [TabAtkins]
- shane: Except CSS people who have to leave that night, but it doesn't sound likely.
- 02:52:47 [TabAtkins]
- shane: And I think most US flights leave in the morning, anyway.
- 02:52:57 [TabAtkins]
- Rossen: Sounds good. Who's organizing?
- 02:53:00 [TabAtkins]
- Bert1: I can coordinate.
- 02:53:08 [TabAtkins]
- shane: Email me so I have a permanent record.
- 02:53:49 [TabAtkins]
- TabAtkins: I"m giving a <20min Houdini talk next month, I can re-give it.
- 02:54:10 [TabAtkins]
- Rossen: Is this meant to be CSS-only? Or SVG too, etc.
- 02:54:17 [TabAtkins]
- Bert1: WAsn't thinking about it yet. All 3 would work.
- 02:54:19 [TabAtkins]
- shane: Agree.
- 02:54:34 [kwkbtr]
- kwkbtr has joined #css
- 02:54:41 [TabAtkins]
- Rossen: Okay, sounds great. Let's organize that. Tentative schedule is evening of Feb 3rd, wednesday, hosted at google around 6pm or 7pm.
- 02:54:55 [TabAtkins]
- shane: Worst case, if Google can't host, Atlassian probably can.
- 02:55:27 [TabAtkins]
- <br type=lunch duration=1h>
- 02:55:54 [TabAtkins]
- s/Atlassian/someone else/
- 02:57:50 [Bobby]
- Bobby has joined #css
- 03:00:02 [Bert1]
- Bert1 has joined #css
- 03:01:46 [dholbert]
- dholbert has joined #css
- 03:03:58 [astearns]
- after lunch, wide gamut then scroll snap
- 03:07:10 [yeonsoo]
- yeonsoo has joined #css
- 03:09:15 [yeonsoo]
- yeonsoo has joined #css
- 03:10:30 [ChrisL]
- what time are you guys coming back from lunch? I need to be there for wide gamut
- 03:12:16 [yeonsoo_]
- yeonsoo_ has joined #css
- 03:14:11 [Bobby]
- Bobby has joined #css
- 03:57:19 [glazou]
- glazou has joined #css
- 03:58:32 [astearns]
- After lunch start slightly delayed. Shane found espresso
- 04:01:59 [shigeya]
- shigeya has joined #css
- 04:02:45 [Bert1]
- Bert1 has joined #css
- 04:03:55 [brady_duga]
- brady_duga has joined #css
- 04:05:40 [glazou]
- glazou has joined #css
- 04:07:22 [Florian]
- Florian has joined #css
- 04:07:34 [dauwhe]
- astearns: people want to know where!
- 04:09:40 [Bobby]
- Bobby has joined #css
- 04:10:31 [TabAtkins]
- too late now!
- 04:10:55 [glazou]
- glazou has joined #css
- 04:14:34 [Andrey]
- Andrey has joined #css
- 04:15:25 [skk]
- skk has joined #css
- 04:15:28 [tfuji]
- tfuji has joined #css
- 04:17:12 [astearns]
- It's called plantation. On our way back
- 04:17:34 [dbaron]
- dbaron has joined #css
- 04:20:11 [katashin]
- katashin has joined #css
- 04:21:47 [sam]
- sam has joined #css
- 04:23:02 [johanneswilm]
- johanneswilm has joined #css
- 04:23:05 [kurosawa]
- kurosawa has joined #css
- 04:23:55 [Florian]
- Florian has joined #css
- 04:25:44 [yeonsoo]
- yeonsoo has joined #css
- 04:29:07 [karl]
- karl has joined #css
- 04:33:54 [MaRakow]
- MaRakow has joined #CSS
- 04:35:00 [zcorpan]
- zcorpan has joined #css
- 04:37:19 [skk_]
- skk_ has joined #css
- 04:37:42 [cssroom]
- cssroom has joined #css
- 04:38:41 [kokabe]
- kokabe has joined #css
- 04:39:29 [ChrisL]
- ChrisL has joined #css
- 04:39:30 [dyamada]
- dyamada has joined #css
- 04:39:43 [fantasai_]
- Topic: wide gamut
- 04:39:51 [myles]
- myles has joined #css
- 04:39:52 [jchiba]
- jchiba has joined #css
- 04:39:56 [shigemi]
- shigemi has joined #css
- 04:40:08 [myles]
- hello
- 04:40:12 [dino]
- dino has joined #css
- 04:40:18 [fantasai]
- dino: Few things to discuss
- 04:40:27 [fantasai]
- dino: FIrstly, most importantly, ability to specify colors that are outside sRGB
- 04:40:31 [johanneswilm]
- johanneswilm has joined #css
- 04:40:42 [fantasai]
- dino: I think Tab and smfr had a discussion about whether or not RGB values are clipped
- 04:40:59 [fantasai]
- ChrisL: They're clipped to the gamut
- 04:41:13 [fantasai]
- Tab: We don't syntactically clip them. The actual value is clipped
- 04:41:27 [fantasai]
- ChrisL: This is so that you can speicfy outside the range using negative numbers
- 04:41:39 [fantasai]
- ChrisL: Downside is that the mapping outside the sRGB gamut isn't specified
- 04:41:44 [fantasai]
- dino: So what do we do about that?
- 04:41:53 [fantasai]
- ChrisL: We've discussed adding the LAB numbers
- 04:42:13 [fantasai]
- ChrisL: Second way to do it is to add support for other RGB models, e.g. Adobe RGB
- 04:42:20 [fantasai]
- ChrisL: All of these require adding syntax to specify the value
- 04:42:28 [fantasai]
- ChrisL: And also to extend the rendering space in which you do calculations
- 04:42:35 [fantasai]
- ChrisL: LAB means you'll never get clipping
- 04:42:42 [fantasai]
- ChrisL: interpolation of gradients etc. will be done in that space
- 04:42:47 [fantasai]
- ChrisL: You will never clip prematurely
- 04:42:48 [yeonsoo]
- yeonsoo has joined #css
- 04:42:50 [fantasai]
- ChrisL: That's the current plan
- 04:42:55 [shepazu]
- shepazu has joined #css
- 04:42:58 [fantasai]
- SimonSapin: Would that require a separate property?
- 04:43:05 [fantasai]
- ChrisL: Yes, require separate proeprty for interpolation space
- 04:43:22 [fantasai]
- leaverou: Wouldn't tha tmean that any kind of interpolation, gradients or transitions, would all be the same
- 04:43:32 [murakam]
- murakam has joined #css
- 04:43:35 [fantasai]
- leaverou: Might want different choices for different uses
- 04:43:41 [fantasai]
- ChrisL: That's a good point.
- 04:43:45 [fantasai]
- ChrisL: Right now no choice
- 04:43:52 [fantasai]
- ChrisL: SVG had one for [??] and another for filters
- 04:43:54 [hitsujiwool]
- hitsujiwool has joined #css
- 04:44:05 [fantasai]
- ChrisL: What's your gamut?
- 04:44:11 [fantasai]
- dino: Less than Adobe RGB
- 04:44:17 [Bobby]
- Bobby has joined #css
- 04:44:30 [fantasai]
- dino: Ultimately wnat to get to specifying colors in LAB
- 04:44:37 [ChrisL]
- s/discussed adding/decided to add/
- 04:44:39 [fantasai]
- dino: maybe simpler to experiment with not clipping?
- 04:44:42 [fantasai]
- dino: See what breaks
- 04:44:50 [fantasai]
- dino: Then allow something like Adobe RGB to specify as gamut
- 04:44:59 [fantasai]
- TabAtkins: Discussed a lot with ? who does grpahics
- 04:45:17 [fantasai]
- TabAtkins: Our major issue is, if you're outside the sRGB gamut, you need more storage space
- 04:45:30 [fantasai]
- TabAtkins: inflates all the colors
- 04:45:44 [fantasai]
- ChrisL: Need 10-12 bits per color, but then for storage would want 16...
- 04:45:47 [fantasai]
- ...
- 04:45:51 [fantasai]
- dino: Other problem we came across..
- 04:46:11 [fantasai]
- dino: Topic 2 is imageset, where you might want to provide different artwork on wide gamut vs normal gamut
- 04:46:19 [fantasai]
- TabAtkins: We already have a media query for handling that
- 04:46:25 [fantasai]
- TabAtkins: It tells you number of bits
- 04:46:29 [fantasai]
- ChrisL: That's not sufficient
- 04:46:41 [fantasai]
- ChrisL: That tells you the resolution within the gamut, not how wide the gamut is
- 04:46:46 [MaRakow]
- MaRakow has joined #CSS
- 04:46:48 [fantasai]
- TabAtkins: We can invent another media query
- 04:47:20 [fantasai]
- Florian: I'm not sure how eas it would be to make an MQ
- 04:47:36 [fantasai]
- Florian: Easy for "is it bigger than sRGB", but how much bigger?
- 04:47:41 [fantasai]
- ChrisL: Do want "how much bigger"
- 04:47:53 [fantasai]
- TabAtkins: Don't think we need anything fancy for imagset or picture element etc.
- 04:47:57 [fantasai]
- TabAtkins: Just need the MQ
- 04:48:02 [fantasai]
- TabAtkins: The biggest issue is how to support that
- 04:48:02 [liam]
- liam has joined #css
- 04:48:13 [fantasai]
- TabAtkins: without blowing out texture budgets
- 04:48:33 [fantasai]
- Florian: With unlimited resources, would always would like to always use LAB
- 04:48:50 [fantasai]
- Florian: Might want to selectively apply to things that really matter, e.g. for gradients but not transitions
- 04:48:59 [fantasai]
- Florian: Been playing around with using half-floats as well
- 04:49:08 [fantasai]
- (16-bit floats)
- 04:49:48 [fantasai]
- dino: That's impl specific
- 04:49:56 [fantasai]
- ChrisL: But then your CSSOM is inconsistent
- 04:50:04 [fantasai]
- TabAtkins: They just come out as numbers
- 04:50:10 [jeff]
- jeff has joined #css
- 04:50:14 [fantasai]
- dino: Can work on MQ on-list
- 04:50:21 [fantasai]
- dino: Don't think there's any problem with imageset, just address with MQ
- 04:50:51 [fantasai]
- dino: Still missing bit where we specify the gamut
- 04:51:04 [fantasai]
- ChrisL: At one point we had an ICC profile @rule
- 04:51:07 [fantasai]
- TabAtkins: @color-profile
- 04:51:12 [fantasai]
- ChrisL: Not sure that's the best way forward, but it's one way
- 04:51:24 [fantasai]
- ChrisL: Images have their own tags, but if it's just a CSS color, then need a way to say
- 04:51:46 [fantasai]
- ...
- 04:51:51 [fantasai]
- ChrisL: That has advantage of triplet of values
- 04:52:01 [fantasai]
- ChrisL: Other way you'd have to specify color profile in addition to triplet
- 04:52:18 [fantasai]
- TabAtkins: Current spec has color-correction property
- 04:52:21 [fantasai]
- ChrisL: That's not quite..
- 04:52:30 [fantasai]
- TabAtkins: It can be extended, too. In any case that's what we have in the current draft.
- 04:52:39 [fantasai]
- ChrisL: We can keep the section title and remove all the text
- 04:52:47 [fantasai]
- dbaron: Has the compatibility problem there been solved?
- 04:53:18 [fantasai]
- dbaron: Is there a browser that is shipping support for CSS and untagged image colors as sRGB
- 04:53:19 [karl]
- karl has joined #css
- 04:53:21 [fantasai]
- dino: Yes, Safari does
- 04:53:49 [fantasai]
- TabAtkins: CSS says you can use any color space as long as same one for untagged CSS and untagged images
- 04:54:09 [fantasai]
- dbaron: No, you're wrong, it says sRGB
- 04:54:20 [fantasai]
- TabAtkins: Everything talks about it as sRGB
- 04:54:31 [fantasai]
- TabAtkins: but allows you to do other things
- 04:54:59 [fantasai]
- ChrisL: [... something about old stuff being outdated and Apple no longer shipping 1.8 gamut something-or-other ... ]
- 04:55:07 [Florian]
- q+
- 04:55:11 [fantasai]
- ChrisL: So we can drop the color-correction property, or repurposeit to do something useful.
- 04:55:14 [ChrisL]
- q+
- 04:55:18 [Bert1]
- q-
- 04:56:17 [fantasai]
- fantasai: Any objections?
- 04:56:19 [fantasai]
- Florian: No but a question
- 04:56:28 [fantasai]
- Florian: Wasn't it for matching Flash?
- 04:56:41 [fantasai]
- ChrisL: Flash added color correction
- 04:56:53 [fantasai]
- ChrisL: This is all realy weird historical stuff that isn't needed anymore
- 04:56:59 [fantasai]
- Florian: Just wanted to check the reasons no longer exist
- 04:57:12 [fantasai]
- RESOVLVED: Drop color-correction property from CSS Color
- 04:57:23 [fantasai]
- s/RESOVLVED/RESOLVED/
- 04:57:31 [dsinger]
- dsinger has joined #css
- 04:57:46 [ChrisL]
- q?
- 04:57:49 [fantasai]
- dino: We tell the flash plugin to use sRGB so that it will match the colors that the page will have, because we're the only browser rendering in sRGB
- 04:58:02 [fantasai]
- Florian: I'm happy about dropping this, but I think that property, even though not iplemented,
- 04:58:12 [fantasai]
- Florian: Was the only thing that allowed the rest of the browsers to not work in sRGB
- 04:58:15 [fantasai]
- ChrisL: No.
- 04:58:31 [fantasai]
- ChrisL: What it actually means is you work in sRGB, and the level of fidelity with which you are required to conform to sRGB is astoundingly low
- 04:58:41 [dsinger]
- dsinger has left #css
- 04:58:49 [fantasai]
- ChrisL: How do you composit outside gamut stuff with other stuff?
- 04:58:57 [fantasai]
- ChrisL: If you say it's all sRGB, it's all defined, and you can do the conversions
- 04:59:01 [fantasai]
- ChrisL: Nice, simple, consisten tmodel.
- 04:59:06 [fantasai]
- ChrisL: Better to express it that way
- 04:59:16 [fantasai]
- TabAtkins: Everywhere except color correction, spec does say it's all sRGB
- 04:59:29 [fantasai]
- SimonSapin: Crappy monitors will still exist when everyone supports LAB
- 04:59:30 [astearns]
- q?
- 04:59:40 [ChrisL]
- ack Fl
- 04:59:44 [fantasai]
- TabAtkins: Removing that section will lose that untagged images are in sRGB
- 04:59:46 [ChrisL]
- ack ChrisL
- 04:59:53 [fantasai]
- TabAtkins: Need to keep that untagged images are in sRGB
- 05:00:02 [ChrisL]
- so we need to preserve that sentence
- 05:00:05 [fantasai]
- RESOLVED: Keep sentence about untagged images being sRGB
- 05:00:18 [Rossen]
- q
- 05:00:34 [fantasai]
- dino: So I think we're back to the last remaining bit, so someone should come up with a proposal for specifying interpretation of RGB values
- 05:00:47 [fantasai]
- dino: wrt profile, downloadable or named or whatever
- 05:00:51 [fantasai]
- ChrisL: I'm happy to add that
- 05:01:29 [fantasai]
- ChrisL: SVG did that by using a functional notation where the first three parameters were the color, and the last parameter told you which ICC profile was in use for that definition
- 05:01:38 [fantasai]
- ChrisL: Token was specified via @rule
- 05:01:50 [fantasai]
- Florian: Were there predefine dnames?
- 05:01:54 [fantasai]
- ChrisL: There weren't, but there could be
- 05:02:02 [fantasai]
- s/@rule/@rule with URL/
- 05:02:11 [fantasai]
- ChrisL: We can do it differently, but that's what SVG did.
- 05:02:18 [fantasai]
- ChrisL: plugins implemented, no browsers though
- 05:02:28 [fantasai]
- ChrisL: I think it was relatively sane
- 05:02:41 [fantasai]
- Florian: Trial and no evidence of problems?
- 05:02:49 [fantasai]
- ChrisL: No evidence of problems. It worked. Could possibly do other things
- 05:03:09 [fantasai]
- dino: These colors have impact on other parts of the platform, e.g. <canvas> and WebGL
- 05:03:15 [fantasai]
- dino: So.
- 05:03:23 [fantasai]
- ChrisL: I agree that should somehow be defined
- 05:03:44 [fantasai]
- dino: If we invent new syntax for RGB, you set that as your fill style, might need to define what happens
- 05:03:54 [fantasai]
- TabAtkins: Need to define osme way for canvas to use higher image store
- 05:04:12 [fantasai]
- dino: My proposal for WebGL is that... atm you get rgba framebuffer, could requre other
- 05:04:20 [fantasai]
- dino: 2D Canvas has APi that explicitly returns bytes
- 05:04:28 [fantasai]
- TabAtkins: If you switch context-creation argument, API would have to change
- 05:04:32 [fantasai]
- dino: Or flattens if you call it
- 05:04:47 [fantasai]
- Florian: We can have two different APIs, one that always returns 8bit sRGB after conversion
- 05:04:56 [fantasai]
- Florian: And tack on an addition API that returns all information
- 05:05:07 [fantasai]
- ChrisL: Flattening is not simple, there's multiple ways to flatten.
- 05:05:11 [fantasai]
- ChrisL: So 2nd api is better
- 05:05:27 [fantasai]
- dino: If haven't specified higher store.. do you magically clip canvas? do you ???
- 05:05:56 [fantasai]
- ACTION ChrisL Propose color profile feature for CSS
- 05:05:56 [trackbot]
- Created ACTION-728 - Propose color profile feature for css [on Chris Lilley - due 2015-11-02].
- 05:06:02 [fantasai]
- ACTION TabAtkins Drop color-correction property
- 05:06:03 [trackbot]
- Created ACTION-729 - Drop color-correction property [on Tab Atkins Jr. - due 2015-11-02].
- 05:06:17 [fantasai]
- ChrisL: I started moving around sections in the spec, btw
- 05:06:25 [fantasai]
- ChrisL: to make it clearer when we're talking about sRGB or not
- 05:06:37 [fantasai]
- Florian: Does introducing all this stuff solve cmyk?
- 05:06:42 [fantasai]
- ChrisL: Not really
- 05:06:52 [fantasai]
- ChrisL: If the syntax for an arbitrary ICC space...
- 05:07:13 [fantasai]
- ChrisL: If the first parameter is always the token, then you could change it from taking 3 numbers to N numbers, and accept 3 or 6 numbers as needed
- 05:07:24 [fantasai]
- Florian: Then the problem will only be device-cmyk()?
- 05:07:31 [fantasai]
- ChrisL: That's why needed sRGB fallback
- 05:07:51 [fantasai]
- ChrisL: This isn't a case of not understood, I'm fine with wierd cmyk
- 05:08:03 [fantasai]
- ChrisL: Problem is computing interpolation for transitons etc.
- 05:08:42 [fantasai]
- TabAtkins: device-cmyk() has fallback acrgument. If unspecified, it gives a really bad fallback, but at least a fallback
- 05:08:42 [sam]
- sam has joined #css
- 05:08:55 [fantasai]
- Florian: The alternative proposal was syntax error at composition time...
- 05:09:19 [sena]
- sena has joined #css
- 05:09:21 [fantasai]
- Florian: Does this syntax give color space first, then aribtrary?
- 05:09:25 [hiro___]
- hiro___ has joined #css
- 05:09:33 [fantasai]
- ChrisL: 1st param seems more reasonable
- 05:09:41 [fantasai]
- Florian: Would this support pantone colors?
- 05:09:46 [fantasai]
- ChrisL: Yes, could have named profiles
- 05:09:57 [fantasai]
- ChrisL: It would be a palette
- 05:10:08 [fantasai]
- ChrisL: Could have named color profiles that you deal with yourself
- 05:10:19 [fantasai]
- ChrisL: Also deals with #1 issue of "How do I name my own colors?"
- 05:10:24 [fantasai]
- leaverou: Could also use CSS Variables
- 05:10:48 [fantasai]
- ChrisL: Can kick around details after proposal is drafted
- 05:10:51 [dwim1]
- dwim1 has joined #css
- 05:11:09 [fantasai]
- fantasai: We've had a draft of of CSS4 color for a long time now
- 05:11:16 [fantasai]
- TabAtkins: Yeah, it's time to start trimming and punting
- 05:11:26 [fantasai]
- fantasai: What here has 2 impls?
- 05:11:45 [fantasai]
- TabAtkins: None of it atm
- 05:11:58 [fantasai]
- TabAtkins: I think Servo has 8-digit hex, and I have a patch for blink
- 05:12:15 [fantasai]
- fantasai: Do we have a single impl of other stuff?
- 05:12:52 [fantasai]
- TabAtkins: color-adjust has at least 1 implementation
- 05:12:57 [fantasai]
- TabAtkins: That's it
- 05:14:57 [fantasai]
- fantasai: If we don't have prioritzation base don implementation, we should survey authors to find out what's the best features we should add to help them
- 05:15:43 [fantasai]
- discussion about color() function being suboptimal wrt syntax
- 05:15:49 [kwkbtr]
- kwkbtr has joined #css
- 05:15:58 [fantasai]
- fantasai: Trivial stuff could be pushed to implementations first, other stuff leave for us to work on more
- 05:16:28 [fantasai]
- ...
- 05:16:37 [fantasai]
- dino: Designer of page might decide the result is not what they wanted
- 05:16:57 [fantasai]
- dino: The math isn't changing, still worth considering that you'd have to write another rule in your section that says, okay, it's aidfferent type of adjustment I wnat when I'm on this display
- 05:17:00 [nsakai_]
- nsakai_ has joined #css
- 05:17:07 [fantasai]
- dino: I'm actaully really surprised these adjustments are populare
- 05:17:14 [fantasai]
- dino: I think majority of designers want this very specific color
- 05:17:22 [fantasai]
- TabAtkins: if you look at SASS, it's everywhere.
- 05:17:28 [fantasai]
- TabAtkins: people give lots of talks on its
- 05:17:39 [fantasai]
- TabAtkins: People pick two colors, want to generate colors
- 05:18:05 [fantasai]
- ChrisL: Recacluates colors based on the few they picked, lots fewer hard-coded colors that don't mean anything
- 05:18:28 [fantasai]
- ...
- 05:18:34 [fantasai]
- ChrisL: Already resolved to do LAB ones
- 05:18:51 [fantasai]
- Florian: Don't what t orathole on this too long, but for color-adjust, it seems to me that this is independent of color space your'e operating in
- 05:19:16 [fantasai]
- Florian: At the syntax level, want nicely lightened, or nicely darkened color, but then fine with storing in sRGB
- 05:19:25 [fantasai]
- Florian: Which is why I would like Chris's stuff to happen first
- 05:19:39 [fantasai]
- s/color-adjust/color adjustment function/
- 05:22:11 [fantasai]
- fantasai: Maybe TabAtkins and ChrisL could go through the spec and ask, for each feature, "Are there any open or expected issues/changes?" If no for both, put in L4, else in L5. Then implementers know what's stable and ready to implement, and what's still being worked on.
- 05:22:25 [fantasai]
- fantasai: Because it seems like a bunch of stuff here is super stable, and others are still being worked out. Not clear which is which.
- 05:22:53 [fantasai]
- dbaron: Can we not have a concept that's color-adjust and onother one that's color adjustment? It's confusing.
- 05:23:07 [Bert1]
- ScribeNick: Bert1
- 05:23:13 [Bert1]
- Topic: Scroll snap
- 05:25:33 [Bert1]
- -> https://drafts.csswg.org/css-snappoints-1/ snap points module
- 05:25:56 [SteveZ]
- SteveZ has joined #css
- 05:26:11 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue
- 05:26:49 [Bert1]
- fantasai: Issue 10
- 05:27:11 [Bert1]
- … comment that element-based snapping should be sufficient.
- 05:27:53 [Bert1]
- … We have implementations of the repeat syntax already, in some form.
- 05:28:26 [Bert1]
- … If we want to drop it, we need to check if elemebt-based actually does it all.
- 05:28:57 [Bert1]
- Florian: is the question whether there is content based on this?
- 05:29:26 [Bert1]
- fantasai: No, but in that case implementers would keep their prefix syntax
- 05:30:01 [Bert1]
- dino: I'd be in favor of removing, nor,ally, but this seems simple to implement so let's leave it.
- 05:30:14 [Florian]
- q+
- 05:30:33 [Bert1]
- Rossen: We (MS) do see usage
- 05:31:01 [Bert1]
- TabAtkins: We are weakly for dropping it, but won't cry.
- 05:31:44 [Bert1]
- Florian: If there is a good way with element, then better to remove this less good way before people use it.
- 05:32:11 [Bert1]
- lea: As an autor, I think elements are simpler. Wouldn't use this synytax.
- 05:32:54 [Bert1]
- matt: interval-based: every 5th element, e.g., then repeat is simpler.
- 05:33:36 [Bert1]
- Florian: But that seems fragile. Syntax shows result of a computation in your head, not the reason for that calculation.
- 05:33:53 [Bert1]
- TabAtkins: Thinking you could container elements… never mind.
- 05:34:31 [Bert1]
- matt: Can make a script to calculate 90% of the elements, easier.
- 05:35:10 [Bert1]
- Florian: If the images are oddly size, then can't use the repeat anyway.
- 05:35:37 [Bert1]
- TabAtkins: And if you use flexbox, there may be some white space between them.
- 05:36:16 [Bert1]
- SteveZ: It seems you want snap after N-1 images.
- 05:36:25 [Bert1]
- … Where N depends on viewport
- 05:36:42 [MaRakow]
- MaRakow has joined #CSS
- 05:36:42 [Bert1]
- TabAtkins: Actually, can use a container.
- 05:36:58 [Bert1]
- fantasai: Can use selectors […]
- 05:37:20 [Bert1]
- TabAtkins: container and nth-child()
- 05:37:40 [Bert1]
- … Assuming you know the number and the size.
- 05:38:12 [Bert1]
- Florian: So, if you have that info, then you can also do it with elements.
- 05:38:27 [Bert1]
- fantasai: So leaning towards dropping it.
- 05:38:38 [jchiba]
- jchiba has joined #css
- 05:38:47 [Bert1]
- dino: We may complain later, but OK now.
- 05:39:27 [Bert1]
- RESOLVED: drop 'scroll-snap-points-x/y: repeat() '
- 05:40:16 [Bert1]
- Florian: So the whole section in the draft disappears?
- 05:40:24 [Bert1]
- … But there is an issue in that section.
- 05:40:31 [Bert1]
- fantasai: We'll get to that.
- 05:40:45 [Bert1]
- fantasai: Issue 11
- 05:40:56 [Bert1]
- … mutliple snap points per element.
- 05:41:20 [Bert1]
- … roc answered you could add more elements.
- 05:41:53 [Bert1]
- … Tab and I thought you might want other things beside snapping happening to those points.
- 05:42:10 [Bert1]
- … So simpler to have just one point per element.
- 05:42:28 [Bert1]
- matt: It seems useful functionality to me.
- 05:42:44 [Bert1]
- fantasai: I'd like more feedback first, and possibly add it in next level.
- 05:43:08 [Bert1]
- … Need compelling use case that cannot be solved adequately.
- 05:43:40 [Bert1]
- TabAtkins: Example of canvas: shouldn't have one bigger than screen anyway.
- 05:44:00 [Bert1]
- … Exmaple of SVG: SVG has elements, so you can set snap point on them already.
- 05:44:45 [Bert1]
- Florian: Image with people: want to snap to each person's face. But better to overlay elements corresponding to the faces.
- 05:45:06 [Bert1]
- matt: Did Moz or Apple implement snap points?
- 05:45:23 [Bert1]
- dbaron: We have some tests for parsing.
- 05:45:39 [Florian]
- q-
- 05:45:43 [Bert1]
- fantasai: Roc didn't see an issue with dropping multiple points.
- 05:45:56 [Bert1]
- … Shall we resolve to drop the feature?
- 05:46:27 [Bert1]
- SteveZ: Adding elements means need to chnage the content.
- 05:46:52 [Bert1]
- TabAtkins: Unlikely that you wouldn't want elements there anyway, for other reasons.
- 05:47:24 [Bert1]
- astearns: thinking about element-based regions… :-)
- 05:47:50 [Bert1]
- SteveZ: Agree that hover would be common, indeed.
- 05:48:19 [karlcow_]
- karlcow_ has joined #css
- 05:48:54 [Bert1]
- RESOLVED: drop feature of multiple snap points per element
- 05:49:11 [Bert1]
- fantasai: Issue 12
- 05:49:50 [Bert1]
- TabAtkins: Similar to grid. You have elements, or pseudo-elements.
- 05:50:24 [Bert1]
- RESOLVED: Don't do anything special for multioclumn or grid.
- 05:50:52 [Bert1]
- dino: How far away are we from ::column pseudo?
- 05:51:12 [Bert1]
- fantasai: issue 16
- 05:52:03 [Bert1]
- … inlines can be snap targets.
- 05:52:10 [Bert1]
- bert: what do you snap to?
- 05:52:14 [Bert1]
- fantasai: bounding box
- 05:52:32 [Bert1]
- RESOLVED: scroll-snapping applies to all elements
- 05:53:00 [Bert1]
- fantasai: issue 22
- 05:53:13 [Bert1]
- … what happens on re-layout?
- 05:53:43 [Bert1]
- … roc said it was hard, but matt said people expected it.
- 05:53:49 [Bert1]
- … roc could live with that.
- 05:54:46 [Bert1]
- Florian: scroll to end of a growing box, like our irc log on the projector
- 05:55:13 [Bert1]
- tab: that is diff. feature, sticky boxes.
- 05:56:03 [Bert1]
- matt: proximity snap point updates are a MAY currently,
- 05:56:50 [Bert1]
- Florian: I agree that mandatory points need MUST, but if an image loads late, the end of the document may disappear just as you were reading it.
- 05:57:29 [Bert1]
- stevez: in case […] I'd like to stay were I am.
- 05:57:36 [Bert1]
- Florian: Different situation
- 05:57:41 [Bobby]
- Bobby has joined #css
- 05:57:41 [katashin]
- katashin has joined #css
- 05:57:54 [fantasai]
- Florian: There are 2 cases -- if you are already snapped to a point, probably want to stay htere. If not snapped, then whether you snap after reflow or not is a idfferent question
- 05:58:06 [Bert1]
- matt: Imagin a snap element is deleted, do you snap to a different element now?
- 05:58:37 [Bert1]
- Florian: I haven't seen a case where […]
- 05:59:01 [Bert1]
- fantasai: Makes sense that when you are already snapped to a point, you stay there.
- 05:59:20 [Bert1]
- dbaron: It may that when you resize, you end up too close to the edge.
- 05:59:52 [Bert1]
- matt: Possibly if the snap point still exists after the relayout, you MUST resnap to it.
- 06:00:35 [Bert1]
- Rossen: We are talking layout changing, not transform, right?
- 06:00:59 [Bert1]
- TabAtkins: Transforms are taken into account, spec is clear.
- 06:01:05 [Bert1]
- dino: And animations
- 06:01:09 [Bert1]
- TabAtkins: Also.
- 06:01:59 [fantasai]
- Proposal:
- 06:02:11 [fantasai]
- 1. If mandatory, must resnap after geometry changes
- 06:02:18 [fantasai]
- 2. If proximity, may resnap after geometry changes
- 06:02:34 [Bert1]
- fantasai: Proposal: Changes in the geom. of the snap point wrt the scroller MUST resnap to the active snap point, even if it is proximity snap.
- 06:02:37 [fantasai]
- 3. If actively snapped (in either case), must stay snapped to that snap position (so long as it continues to exist)
- 06:03:20 [Bert1]
- dbaron: Need a condition that you *can* snap to it.
- 06:03:44 [Bert1]
- … If screen size chnages, e.g.
- 06:04:12 [Bert1]
- fantasai: Another related issue for that.
- 06:04:42 [dwim1]
- dwim1 has left #css
- 06:05:05 [nulltask]
- nulltask has joined #css
- 06:05:09 [Bert1]
- Florian: There is a difference between proposal and what I said: if the element moved too far to be able to snap, and then moves back, do you snap?
- 06:05:35 [dwim_]
- dwim_ has joined #css
- 06:05:41 [Bert1]
- TabAtkins: That is separate isseu of snapping beyond scrollable area.
- 06:06:12 [Bert1]
- dbaron: If are required to snap to a snap point… let's talk about that later.
- 06:07:04 [Bert1]
- … I want to come back to this issue obce we talkedabout the other ones
- 06:08:44 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-25
- 06:08:49 [Bert1]
- fantasai: issue 25
- 06:08:58 [fantasai]
- (previous was https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-22 )
- 06:09:36 [Bert1]
- everybody agrees that js-based scrolling should snap, just like other types of scrolling.
- 06:10:01 [Bert1]
- dino: You scroll to what JS said, and *then* snap?
- 06:10:13 [Bert1]
- TabAtkins: Yes, the spec is clear on that.
- 06:10:28 [Bert1]
- matt: spec is less specific about animation curves.
- 06:10:37 [Bert1]
- … Not every UA will have animations
- 06:10:50 [Bert1]
- … This is better left to UA
- 06:11:49 [yeonsoo]
- yeonsoo has joined #css
- 06:11:54 [Bert1]
- dino: if js scrolls to […] operation has no effect.
- 06:12:29 [Bert1]
- fantasai: seems we agree that DOM APIs for scrolling all snap.
- 06:12:52 [sena]
- sena has joined #css
- 06:13:12 [fantasai]
- fantasai: And the animation is UA-defind -- just have to end up at that snap point
- 06:13:28 [Bert1]
- RESOLVED: always apply snap after all JS-based scrolling operations.
- 06:13:32 [brady_duga]
- brady_duga has joined #css
- 06:13:46 [Bert1]
- fantasai: Note that it may not snap if you end far from a procximity point.
- 06:14:13 [kwkbtr]
- kwkbtr has joined #css
- 06:15:53 [Bert1]
- tab: if js scrolls to halfway between points, do we need to specify where it goes. (Also inertia, but that can be left fuzzy)
- 06:16:13 [Bert1]
- matt: User can usually do another scroll if result is not what he wanted.
- 06:16:24 [Bert1]
- Rossen: Let's not deal too much with error cases.
- 06:16:39 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-24
- 06:16:47 [Bert1]
- fantasai: issue 24
- 06:17:04 [Bert1]
- … When do layout changes trigger resnapping?
- 06:17:17 [Bert1]
- … Not sure how to say this in the spec.
- 06:17:33 [Bert1]
- TabAtkins: "When document is stable"
- 06:17:44 [Bert1]
- dbaron: consider smooth scroll…
- 06:18:09 [Bert1]
- fantasai: So question is who can write that text for the spec?
- 06:18:18 [Bert1]
- dbaron: May need some implementation experience.
- 06:18:38 [Bert1]
- TabAtkins: OK, so we need something rough and then experinece can update it
- 06:18:47 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-28
- 06:18:55 [Bert1]
- fantasai: issue 28
- 06:19:04 [Bert1]
- … I'd suggest to defer this to later.
- 06:19:26 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-70
- 06:19:35 [Bert1]
- RESOLVED: deferred (issue 28)
- 06:35:35 [shigeya]
- shigeya has joined #css
- 06:42:49 [kwkbtr]
- kwkbtr has joined #css
- 06:45:34 [sena]
- sena has joined #css
- 06:48:41 [katashin]
- katashin has joined #css
- 06:50:10 [YusukeNakaya]
- YusukeNakaya has joined #css
- 06:52:49 [adenilson]
- adenilson has joined #css
- 06:54:39 [kurosawa]
- kurosawa has joined #css
- 06:55:51 [dwim1]
- dwim1 has joined #css
- 06:56:37 [dwim1]
- dwim1 has left #css
- 07:00:29 [glazou]
- glazou has joined #css
- 07:00:54 [sam_]
- sam_ has joined #css
- 07:02:05 [myles]
- myles has joined #css
- 07:02:06 [fantasai]
- https://drafts.csswg.org/css-scroll-snap/issues-by-issue#issue-44
- 07:02:38 [Bert1]
- fantasai: Should start and end edge be automatic scroll positions?
- 07:02:53 [Bert1]
- … There has been discussion.
- 07:03:27 [Bert1]
- … You can have the effect by having elements there.
- 07:03:48 [Bert1]
- … Sometimes maybe pseudo-element.
- 07:04:01 [Bert1]
- … So our conclusion was to not automatically add those points.
- 07:04:02 [murakami]
- murakami has joined #css
- 07:04:14 [Bert1]
- matt: I agree with not adding implicit points.
- 07:04:21 [Bobby]
- Bobby has joined #css
- 07:04:26 [kokabe]
- kokabe has joined #css
- 07:04:40 [Bert1]
- TabAtkins: Our proposal allows to add both edges explicitly.
- 07:05:52 [Bert1]
- Florian: agree, but wondering if there need there to be an eplicit switch.
- 07:06:04 [Bert1]
- … Seems you can get it through elements.
- 07:06:10 [MaRakow_]
- MaRakow_ has joined #CSS
- 07:06:23 [Bert1]
- … Can still add it later in compatible way
- 07:06:38 [r12a]
- r12a has joined #css
- 07:06:40 [Bert1]
- fantasai: That was Tab and my conclusion. Can we resolve?
- 07:07:32 [Bert1]
- RESOLVED: No automatic snap point at start and end of scrollable area. (issue 44 no chnage)
- 07:08:24 [liam]
- liam has joined #css
- 07:08:55 [fsasaki]
- fsasaki has joined #css
- 07:09:05 [fsasaki]
- present+ fsasaki
- 07:09:20 [liam]
- present+ LiamQuin
- 07:09:40 [Bert1]
- topic: logical properties and values
- 07:09:53 [Bert1]
- fantasai: First one is background-position
- 07:10:14 [Bert1]
- … We had requests from I18N WG to add logical keywords for bg images.
- 07:10:21 [Bert1]
- … (among other things)
- 07:10:47 [Bert1]
- … There are longhand properties.
- 07:10:57 [Bert1]
- … I came up with a syntax [see draft]
- 07:11:13 [Bert1]
- … Can pick direction within an axis.
- 07:11:20 [dwim1]
- dwim1 has joined #css
- 07:11:38 [Bert1]
- … [shows examples]
- 07:11:53 [Bert1]
- … bg-pos: x-start
- 07:11:58 [Bert1]
- … bg-pos: left
- 07:12:12 [Bert1]
- … bg-pos: start 10px
- 07:12:13 [dbaron]
- https://drafts.csswg.org/css-backgrounds-4/#the-background-position
- 07:12:49 [Bert1]
- fantasai: people probably need more time to look at this, but initial reactions?
- 07:13:21 [ChrisLilley]
- ChrisLilley has joined #css
- 07:13:50 [Bert1]
- [discussion about physical-logical mix]
- 07:14:17 [Bert1]
- TabAtkins: Florian once asked for 'top x-start'
- 07:14:35 [Bert1]
- stevez: this is mostly to be able to distinguish when used in the short hand.
- 07:15:08 [Bert1]
- dbaron: A little hesitant about the one-value syntax with 'start' or 'end'
- 07:15:31 [Bert1]
- fantasai: Yes, you default to center for 2nd value normally, but 'start' duplicates itself.
- 07:15:39 [Bert1]
- … and 'end' too
- 07:16:07 [Bert1]
- dbaron: Given that center is default for 2nd in other cases, I'd prefer simply not allowing a sole 'start' or 'end'
- 07:16:27 [Bert1]
- TabAtkins: I'd be OK with that…
- 07:16:55 [Bert1]
- fantasai: I'd like to allow them, because I don't see why not. And duplicating is a common pattern for CSS properties.
- 07:17:06 [Bert1]
- dbaron: … except for background.
- 07:17:42 [Bert1]
- johannes: [missed]
- 07:18:02 [adenilson]
- adenilson has joined #css
- 07:18:33 [Bert1]
- fantasai: This topic is not only about bg, also floats, e.g.
- 07:18:51 [Bert1]
- leaverou: It does make sense to mix them
- 07:19:00 [Bert1]
- dbaron: Back to background:
- 07:19:07 [Bert1]
- … I see two bigger problems.
- 07:19:40 [Bert1]
- … One is that before top and […] were mutually exclusive. That seems to be no longer the case.
- 07:19:50 [Bert1]
- … Maybe not a problem.
- 07:20:06 [Bert1]
- … Some longhands may not have an equivalent short hand.
- 07:20:13 [Bert1]
- TabAtkins: That happens sometimes.
- 07:20:23 [Bert1]
- fantasai: What case?
- 07:20:42 [Bert1]
- dbaron: If you mix bg-pos-x and bg-pos-inline
- 07:21:04 [Bert1]
- TabAtkins: It is fine to have values that cannot be expressed in shorthand.
- 07:21:15 [Bert1]
- dbaron: Probably OK
- 07:21:57 [Bert1]
- fantasai: We found initial values did not match easily. UNlike for margin, e.g., where the initial is 0.
- 07:22:25 [Bert1]
- dbaron: Can say that shorthand has no initial value.
- 07:22:41 [Bert1]
- fantasai: Is that possible? In that case OK
- 07:23:11 [dbaron]
- s/shorthand/logical property/
- 07:23:43 [Bert1]
- stevez: need to explain what not applicable means.
- 07:24:15 [Bert1]
- … In general module about properties syntax.
- 07:24:16 [ChrisLilley]
- to atomic explosiveness of longhands?
- 07:24:46 [Bert1]
- dbaron: [typing text]
- 07:25:19 [Bert1]
- fantasai: Tab and I noticed we could not keep track of which came first when using two-value syntax.
- 07:25:27 [ChrisLilley]
- atomic, explosiveness, of, longhands?
- 07:25:28 [karl]
- karl has joined #css
- 07:25:52 [Bert1]
- … bg and border-spacing have horiz then vertical.
- 07:26:09 [Bert1]
- TabAtkins: logical ones start with block then inline.
- 07:26:32 [Bert1]
- … I always write it wrong.
- 07:26:33 [Ms2ger]
- Ms2ger has joined #css
- 07:26:53 [Bert1]
- … So we issues and no satisfactory answers.
- 07:27:58 [fantasai]
- https://lists.w3.org/Archives/Public/www-style/2015Oct/0212.html
- 07:28:08 [Bert1]
- fantasai: Grid-area vs grid-template…
- 07:28:28 [Bert1]
- TabAtkins: options A an B [see link above]
- 07:29:01 [Bert1]
- stevez: always block before inline seems easy to remember
- 07:29:25 [Bert1]
- TabAtkins: Some properties have four values and two values.
- 07:29:47 [Bert1]
- fantasai: Should go back in time and tell Hakon and bert that bg should be consistent with other proeprties.
- 07:30:20 [fantasai]
- Florian: With Option B, we don't have a time machine to go fix it, but we can travel to a parallel universe where everything works correctly
- 07:30:30 [Bert1]
- Florian: Is this an incentive for people to start using logical properties?
- 07:31:13 [Bert1]
- tab: any objection to option b, block before inline?
- 07:31:27 [JonathanC]
- JonathanC has joined #css
- 07:32:19 [Bert1]
- RESOLVED: option b (always block then inline)
- 07:32:55 [Bert1]
- ACTION tab: update grid with this resolution
- 07:32:55 [trackbot]
- Created ACTION-730 - Update grid with this resolution [on Tab Atkins Jr. - due 2015-11-02].
- 07:33:21 [dwim_]
- dwim_ has joined #css
- 07:33:51 [Bert1]
- fantasai: Next issue is cascade of physical and logical properties.
- 07:34:00 [Bert1]
- … The spec is currently a mess.
- 07:34:14 [Bert1]
- … Problem is which writing-mode the property is relative to.
- 07:34:22 [Bert1]
- … We discussed this before.
- 07:34:33 [Bert1]
- … Complexity comes from there is no perfect answer.
- 07:34:34 [astearns]
- https://drafts.csswg.org/css-logical-props/#property-index
- 07:34:42 [Bert1]
- … Simples anwer is use writing-mode of elt itself.
- 07:34:50 [Bert1]
- … Easy to understand mapping,
- 07:35:02 [Bert1]
- … but many rules reference CB
- 07:35:33 [Bert1]
- … E.g., drop margin based on CB
- 07:35:34 [jeff_]
- jeff_ has joined #css
- 07:35:49 [Bert1]
- … Float start will float to start of CB
- 07:36:10 [Bert1]
- … Grid container instead of grid item itself.
- 07:36:10 [dholbert]
- dholbert has joined #css
- 07:36:32 [Bert1]
- stevez: writing mode applies to […]
- 07:36:53 [Bert1]
- Rossen: All the examples you gave make sense to reference CB
- 07:37:09 [Bert1]
- … Everything from border inside makes sense to refer to elt itself.
- 07:37:22 [Bert1]
- fantasai: Border itself could be either.
- 07:37:47 [Bert1]
- … Inside the box, e.g., text-align refrrs to wrtiting-mdoe of elt itself.
- 07:38:33 [Bert1]
- … If box has has margin on end but different writing mode than CB, then margin mey not disappear where it should.
- 07:38:40 [Bert1]
- … Frustration for authors.
- 07:39:05 [Bert1]
- … In that case use parent, because difficult to compute layout of CB
- 07:39:32 [Bert1]
- Rossen: Really only applies to positioned elements.
- 07:39:46 [Bert1]
- … means static psotion still computed to parent
- 07:40:00 [Bert1]
- fantasai: No, this is about cascading.
- 07:40:18 [rego]
- rego has joined #css
- 07:40:34 [Bert1]
- … Most things that have longhands work better against CB.
- 07:40:50 [Bert1]
- … Pretty much everything in the draft.
- 07:41:15 [Bert1]
- … Orthogonal flows is going to be small percentage of cases.
- 07:41:55 [Bert1]
- Rossen: block and inline size should be kept in @@@
- 07:42:35 [Bert1]
- TabAtkins: Both seem reasonable: sometimes want to set content size, sometiomes want all siblings the same size, indep. of their writing-mode.
- 07:43:01 [Bert1]
- stevez: Example of counting in number of lines.
- 07:43:22 [Bert1]
- johannes: You want images of a certain number of lines?
- 07:43:40 [Bert1]
- stevez: thinking of a table, with one cell in japanese.
- 07:43:56 [Bert1]
- fantasai: Can always still use the physical properties.
- 07:44:35 [Bert1]
- … auto will shrink wrap; explicit size, like 50% keys off surrounding size.
- 07:45:04 [Bert1]
- … Is percentage referring to horiz or vertical dimension?
- 07:45:24 [Bert1]
- … Want 50% in inline dimension and auto in block dimension
- 07:45:45 [Bert1]
- johannes: if you could specify lines, might want float of 10 lines high.
- 07:46:14 [Bert1]
- florian: say a magazin layout, with some boxes in differen direction, but all specified to parent which is always in same direction.
- 07:46:42 [Bert1]
- TabAtkins: Can have a keyword 'self' when you want to be refer to elt itself.
- 07:47:41 [Bert1]
- koji: [missed]
- 07:48:03 [r12a]
- Koji: I think i agree with Steve
- 07:48:10 [r12a]
- Steve: i think i now agree with Tab
- 07:48:20 [koji]
- s/[missed]/I see both cases exist, but not sure which case is more common. My instinct is to agree with szilles
- 07:48:24 [ChrisLilley]
- steve: I disagree with myself and now agree with tab
- 07:48:55 [Bert1]
- fantasai: Say I have simple, one-flow document. Want a block of 50% and then lay something out inside it.
- 07:49:27 [Bert1]
- rossen: Say you have a rtol container, inside it a ltor container.
- 07:49:39 [Bert1]
- … And set 1em padding on the end.
- 07:49:52 [Bert1]
- … Now you say I end up with 1em on the end.
- 07:49:59 [Bert1]
- … That makes no sense to me.
- 07:50:24 [Bert1]
- TabAtkins: Browsers have had different default margins and paddings, e.g., in lists.
- 07:50:57 [Bert1]
- rossen: With physical properties you can get away with that.
- 07:51:20 [Bert1]
- florian: When ypu have float, size and margin refer to CB, agreed?
- 07:51:48 [Bert1]
- rossen: Yes, but everything inside the broder refers to elt itself.
- 07:52:14 [Bert1]
- Florian: If you put some margin between yourself and parent, you may want the margin to be on the same side for all elt.
- 07:52:38 [yeonsoo_]
- yeonsoo_ has joined #css
- 07:52:38 [Bert1]
- stevez: do we agree that everything from border out refers to parent?
- 07:53:15 [Bert1]
- florian: the blue border in our proeprty definitions in the spec style should refer to parent.
- 07:53:32 [Bert1]
- stevez: We agree on borders: borders are on outside.
- 07:53:53 [Bert1]
- … and we can discuss about the other pieces.
- 07:54:08 [Bert1]
- r12a: You can have borders on spans, too.
- 07:54:35 [Bert1]
- … Dont you want the border relative to the text?
- 07:54:53 [Bert1]
- TabAtkins: Some properties are arguable both ways.
- 07:55:03 [Bert1]
- … We have a convention for that.
- 07:55:18 [Bert1]
- dbaron: We are over-analysing the example.
- 07:55:38 [Bert1]
- … In most cases there will be multiple relatives.
- 07:56:04 [Bert1]
- … IS the let with the border the same as the elt with the rl text?
- 07:56:21 [Bert1]
- … Many structures will have multiple elts.
- 07:56:41 [Bert1]
- TabAtkins: And sometimes not. E.g., LI is often just naked text.
- 07:57:16 [Bert1]
- johannes: When we talked half a year go or so we thought it strange margins would go on other side and we though let's just put in a DIV.
- 07:57:50 [Bert1]
- … Extra DIV allows youto change the inner one without problem.
- 07:58:20 [Bert1]
- stevez: Issue is can we have a simple rule, while still allow people to set it up the other way.
- 07:58:32 [Bert1]
- … A simple rule that people can remember.
- 07:59:35 [Bert1]
- rossen: in general it seems our implem. follows stevez's rule, border and everything out is relative to CB.
- 07:59:48 [Bert1]
- dbaron: But we're talking about parent not CB now,
- 08:00:04 [Bert1]
- fantasai: Look at quotes: they use rules of container.
- 08:00:17 [shigemi]
- shigemi has joined #css
- 08:00:21 [Bert1]
- … border is similar
- 08:00:46 [kurosawa]
- kurosawa has joined #css
- 08:00:47 [Bert1]
- stevez: if arabic text in english contetx is broken over two lines,
- 08:00:54 [Bert1]
- … still want english rules.
- 08:01:15 [Bert1]
- fantasai: All our rules are designed around CB
- 08:01:42 [Bert1]
- rossen: Only talking about the case there is a switch of writing-mode, otherwise no difference.
- 08:02:19 [Bert1]
- fantasai: In japanese, writing-mkode switch in side notes, caption, table headings, is quite common.
- 08:02:45 [karl]
- example of Japanese Typography
- 08:02:45 [karl]
- http://la-grange.net/2007/07/23-japanese-typography
- 08:03:29 [Bert1]
- stevez: We are talking about a general rule. There may still be other use cases.
- 08:04:05 [Bert1]
- rossen: positional properties, such as margins, makes sense to me to be relative to container.
- 08:04:19 [Bert1]
- … sizes make sense to be relative to elt.
- 08:04:49 [Bert1]
- stevez: That's why I want to agree on the outside case first.
- 08:04:59 [Bert1]
- … But I udnerstand r112a's use case.
- 08:05:25 [Bert1]
- fantasai: everything from border-box out.
- 08:05:40 [fantasai]
- Seem to have consensus on properties affecting positioning of the border box being wrt parent writing mode
- 08:05:43 [Bert1]
- rossen: that includes alignment, float alignment...
- 08:06:15 [Bert1]
- fantasai: inside the content-box belongs to element.
- 08:06:24 [fantasai]
- Seem to have consensus on properties affecting inside the content box being wrt element's own writing mode
- 08:06:34 [Bert1]
- stevez: so we have disagreement on border and padding
- 08:07:08 [Robert]
- Robert has joined #css
- 08:07:12 [Bert1]
- florian: also disagree on size
- 08:07:32 [Bert1]
- fantasai: text-indent is inside.
- 08:08:41 [Bert1]
- TabAtkins: proposed resolution: Everything outside the border-box is resolved relative to parent's writing-mode
- 08:09:10 [Bert1]
- astearns: Let's do whiteboard discssion outside this meeting.
- 08:09:43 [Bert1]
- bert: And that says "parent" not "CB" is that correct?
- 08:09:47 [Bert1]
- TabAtkins: correct.
- 08:10:49 [Bert1]
- fantasai: implementers see margins as positioning, different from border and padding. Authors see it as similar to padding and border.
- 08:11:03 [Bert1]
- leaverou: New authors confuse margin and padding a lot.
- 08:11:14 [Bert1]
- … Experienced uses see them as separate.
- 08:11:41 [fantasai]
- s/them as separate/margins as separate from borders and padding/
- 08:11:50 [Bert1]
- Florian: If you set 'margin: auto'…
- 08:11:59 [fantasai]
- Florian: Given margin: auto can affect the size of the element, it's weird to treat them differently
- 08:12:03 [Bert1]
- rossen: margins never influence the width.
- 08:12:26 [kurosawa_]
- kurosawa_ has joined #css
- 08:12:36 [Bert1]
- florian: If margins are outside and relative to parent […]
- 08:12:52 [Bert1]
- rossen: You want to set what exactly?
- 08:13:07 [Bert1]
- florian: width to specific value, relative to parent.
- 08:13:55 [Bert1]
- rossen: Don't see that use case.
- 08:14:30 [Bert1]
- johannes: There are rules for how many charatcers per line and how many lines minimum. Then you want all measurements relative to outside.
- 08:15:02 [Bert1]
- florian: Character grid rythm.
- 08:15:42 [Bert1]
- stevez: So seems we can agree on the proposed resolution.
- 08:17:04 [hitsujiwool]
- hitsujiwool has joined #css
- 08:17:14 [fantasai]
- RESOLVED: Properties affecting position of border-box (i.e. stuff outside the border edge) cascades by the parent's writing mode; stuff affecting inside the content-edge of the element keys off of the element's own writing mode. border/padding/sizing TBD
- 08:18:00 [Bert1]
- fantasai: I think that is it for the major issues. Rest is tons of issues to edit.
- 08:18:23 [Bert1]
- astearns: So what topic next?
- 08:18:40 [Bert1]
- fantasai: We have i18n people here, any topics related to that?
- 08:19:08 [Bert1]
- r12a: I have no issues at the moment.
- 08:19:27 [Bert1]
- fantasai: snap points with logical keywords.
- 08:20:07 [glazou]
- glazou has joined #css
- 08:20:10 [Bert1]
- matt: I think all the x/y stuff is gone already.
- 08:20:43 [Bert1]
- Rossen: Snapping is more of a positional property.
- 08:20:55 [Bert1]
- … Someting consistent in the parent scrollable.
- 08:21:44 [Bert1]
- … Calling it start rather than left makes.
- 08:22:02 [Bert1]
- bert: I want to be able to just say 'left' as well.
- 08:22:31 [Bert1]
- matt: only thing in spec that implies logical is positioning.
- 08:23:00 [Bert1]
- fantasai: LArger disciusion, 1D vs 2D and things.
- 08:24:19 [Bert1]
- Rossen: wrt Bert's issue: If I specify left and than transform, whereis the snap point now?
- 08:24:47 [Bert1]
- … Left refers to bounding box.
- 08:25:32 [Bert1]
- matt: I think we don't need to edit anything in the spec for this.
- 08:25:50 [Bert1]
- fantasai: if split into scroll-snap-area and -align.
- 08:26:11 [Bert1]
- matt: No actual text change.
- 08:26:53 [Bert1]
- fantasai: Either way we'll add logical stuff. That probably solves that problem.
- 08:27:21 [Bert1]
- Topic: next meetings
- 08:27:32 [Bert1]
- astearns: TPAC 2016 is in Sep.
- 08:27:39 [Bert1]
- … So no sense in an Aug ftf.
- 08:28:03 [Bert1]
- glazou: Was a suggestion to have a meeting in Sophia-Antipolis between Feb and TPAC.
- 08:28:16 [Bert1]
- … Probably only 3 ftfs next year.
- 08:28:27 [Bert1]
- dbaron: CAn also have a meeting in December.
- 08:28:40 [Bert1]
- glazou: But avoid blizzards :-)
- 08:28:52 [Bert1]
- TabAtkins: Holiday travel is problem.
- 08:29:13 [Bert1]
- Florian: TPAC is not on halloween, so can do ftf on Xmas :-)
- 08:30:09 [Bert1]
- [forgot-name]: Can host at Keio around June
- 08:30:25 [Bert1]
- dbaron: AC meeting is in March in Boston
- 08:30:48 [Bert1]
- john: June is not so good for Moz.
- 08:31:14 [Bert1]
- dbaron: Whole of Moz will be in London June 10 to June ?
- 08:31:24 [baba]
- s/[forgot-name]/skk
- 08:31:27 [Bert1]
- … Adjacent weeks may work, depending on location
- 08:31:39 [dbaron]
- Moz folks will be in London June 13-17
- 08:32:12 [Bert1]
- dino: Apple can host early May in Bay Area, or after mid June
- 08:32:21 [Bert1]
- … May is not guaranteed.
- 08:32:46 [Bert1]
- fantasai: So many companies in Bay Area, if Apple can't we can find another.
- 08:33:25 [Bert1]
- dbaron: The mid point between Feb and Sep would be end of May begin of June
- 08:33:59 [Bert1]
- dino: That would not work for Apple, Apple conference.
- 08:34:45 [fukatsu_]
- fukatsu_ has joined #css
- 08:34:55 [Bert1]
- rossen: Besides Apple, other orgs with constraints on that time?
- 08:35:18 [dbaron]
- There's actually not an exact midpoint -- the midpoint between the February and September meetings is halfway between meeting the week of May 23-27 and the week of May 30 - June 3.
- 08:35:40 [Bert1]
- dino: If you pick a day, I can see if I can host. And if not, we can definitely still send someone to the ftf.
- 08:36:05 [antonp]
- antonp has joined #css
- 08:36:22 [Bert1]
- TabAtkins: May Google conference.
- 08:36:56 [Bert1]
- astearns: Sounds like 9-11 May
- 08:37:05 [Bert1]
- dino: Houdini meeting, too?
- 08:37:19 [Bert1]
- glazou: Then take whole week.
- 08:37:49 [TabAtkins]
- s/May Google conference/Late May is probably Google IO - bad for hotels in Bay Area/
- 08:38:33 [Bert1]
- Rossen: Last time, San Diego was wonderful
- 08:39:22 [Bert1]
- astearns: So 2nd week of May, and we'll find out who can host.
- 08:39:31 [Bert1]
- [1st week is Golden Week in Japan]
- 08:40:04 [Bert1]
- dbaron: So going *to* Japan at the end of that week could be inexpensive.
- 08:41:11 [TabAtkins]
- s/inexp/exp/
- 08:41:34 [Bert1]
- Rossen: Proposall is 2nd week of May, 9-11 (with possible Houdini 12-13), anywhere on US west coast.
- 08:42:01 [Bert1]
- … Host TBD
- 08:42:25 [Bert1]
- RESOLVED: 2nd week of May, 9-11 (with possible Houdini 12-13), anywhere on US west coast. Host TBB.
- 08:42:47 [Bobby]
- Bobby has joined #css
- 08:44:29 [Bert1]
- Rossen: We talked about short meetings. In parallel, one joint meeting the 2nd day.
- 08:45:14 [Bert1]
- fantasai: People prepare for ftf. Do those topics first. Then split into parallel for the rest.
- 08:45:33 [Bert1]
- Florian: 3 days is not long. 7 days is long.
- 08:46:05 [Bert1]
- … No need to shorten a 3 day meeting. Can have Houdini in parallel with some CSS topic.
- 08:46:37 [Bert1]
- TabAtkins: With few exceptions (fantasai :-) ), half of room tunes out for some topics.
- 08:46:59 [Bert1]
- Rossen: We can try maybe already in Sydney.
- 08:47:16 [Bert1]
- johannes: page-related stuff can also be split out in parallel.
- 08:47:26 [Bert1]
- dino: So that means we need multiple rooms.
- 08:47:37 [Bert1]
- tab: One big room and some small.
- 08:48:23 [Bert1]
- shane: Can't guarantee extra rooms in Sydney.
- 08:48:56 [Bert1]
- johannes: There may also be even "smaller" topics, say footnotes.
- 08:49:35 [Bert1]
- rossen: I will send out a mail, list the topics, and ask people what they want to work on.
- 08:50:04 [Bert1]
- … Be honest: if you don't care about X, that's OK
- 08:50:21 [Bert1]
- astearns: You mean break-outs will never resolve on anything?
- 08:50:34 [Bert1]
- rossen: They will resolve, but report.
- 08:50:51 [Bert1]
- … We have two chairs, we can have two parallel sessions.
- 08:51:39 [Bert1]
- stevez: I think fantasai's point is that they are resolutions, but people not there can come back to them.
- 08:51:54 [Bert1]
- florian: Better to call it a tentative resolution.
- 08:52:13 [Bert1]
- … Then you can reopen, even if you bring no new arguments.
- 08:52:35 [Bert1]
- rossen: OK, we'll try to start this method in Sydney, if we can get rooms.
- 08:52:49 [Bert1]
- shane: Can't get rooms on Monday, maybe on other days.
- 08:52:57 [Bert1]
- rossen: That'll work.
- 08:53:18 [Bert1]
- fantasai: If we split too much, we get inconsistent, so
- 08:53:43 [Bert1]
- … in favor of coming to resolution, but indeed call it tentative.
- 08:54:02 [sam]
- sam has joined #css
- 08:54:42 [Bert1]
- Adjourned until tomorrow.
- 08:54:56 [dauwhe]
- dauwhe has joined #css
- 08:55:47 [astearns]
- rrsagent, make logs public
- 08:56:01 [astearns]
- rrsagent, bye
- 08:56:01 [RRSAgent]
- I see 1 open action item saved in http://www.w3.org/2015/10/26-css-actions.rdf :
- 08:56:01 [RRSAgent]
- ACTION: tab to update grid with this resolution [1]
- 08:56:01 [RRSAgent]
- recorded in http://www.w3.org/2015/10/25-css-irc#T07-32-55