13:26:04 <RRSAgent> RRSAgent has joined #css
13:26:04 <RRSAgent> logging to http://www.w3.org/2015/05/18-css-irc
13:26:41 <glazou> RRSAgent, make logs public
13:28:41 <glazou> or smog
13:28:48 <SteveZ> SteveZ has joined #css
13:32:52 <Florian> Florian has joined #css
13:33:26 <murakami> murakami has joined #css
13:37:13 <smfr> smfr has joined #css
13:37:16 <dbaron> dbaron has joined #css
13:37:54 <jet> jet has joined #css
13:39:16 <dbaron> trackbot, start meeting
13:39:18 <trackbot> RRSAgent, make logs member
13:39:18 <Zakim> Zakim has joined #css
13:39:20 <trackbot> Zakim, this will be Style_CSS FP
13:39:20 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
13:39:21 <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
13:39:21 <trackbot> Date: 18 May 2015
13:39:27 <dbaron> RRSAgent, make logs public
13:39:39 <csswgproj> csswgproj has joined #css
13:39:45 <dbaron> Zakim, remind us in 9 hours to go home
13:39:45 <Zakim> ok, dbaron
13:40:33 <dbaron> https://wiki.csswg.org/planning/new-york-2015#proposed-agenda-topics
13:44:01 <bcampbell> bcampbell has joined #css
13:44:06 <dbaron> [glazou edits agenda to schedule things]
13:47:32 <dbaron> glazou: At AC meeting I got feedback that we need a document describing the current state of CSS
13:47:37 <dbaron> various: not the snapshot?
13:48:15 <dbaron> SteveZ: One thing people want with tools is to automate some things so you can have a crawler that updates page.  When editor or chair updates it it always gets out of date.
13:48:29 <dbaron> glazou: It's not the topic right now; that's the agenda.
13:51:52 <Zakim> Zakim-bot restarting in 1 minute to recover bridge connection
13:55:52 <Zakim> Zakim has joined #css
13:55:56 <TabAtkins> ScribeNick: TabAtkins
13:56:17 <tantek> tantek has joined #css
13:56:26 <fantasai> http://dev.w3.org/csswg/css-break-3/issues-lc-2015
13:56:33 <dauwhe> dauwhe has joined #css
13:57:34 <TabAtkins> fantasai: There's a few issues for the WG.
13:57:44 <TabAtkins> fantasai: First is replaced content
13:58:00 <TabAtkins> fantasai: We ahve an issue from howcome. We currently say you can slice an image if it doesn't fit, but you should try to move it first.
13:58:14 <TabAtkins> fantasai: He suggested we should be able to control it, to make it slice immediately.
13:58:36 <TabAtkins> fantasai: One way to do it is to say that replaced content has "break-inside:avoid" in the UA stylesheet.
13:58:46 <TabAtkins> fantasai: So the author can change that.
13:58:53 <TabAtkins> fantasai: On <img>, <iframe>, etc
13:59:14 <TabAtkins> Florian: This gives the same current behavior, and easily controls if you want different behavior, so looks nice.
13:59:35 <TabAtkins> fantasai: You wouldn't get the avoidance behavior by default if you were using some other type of image, like from the 'content' property.
14:00:04 <TabAtkins> dbaron: There's also a slight difference with <object> fallback, though I'm not sure how much that matters
14:00:20 <TabAtkins> dbaron: We should probably have a pseudo to select when it's doing fallback, so we can deal with those cases.
14:00:31 <TabAtkins> dbaron: I think Gecko actually does have a pseudo.
14:00:45 <TabAtkins> TabAtkins: I think the change sounds good.
14:01:09 <TabAtkins> RESOLUTION: Allow break-inside to work on replaced content, put "break-inside:avoid" in the UA stylesheet for replaced elements.
14:01:34 <TabAtkins> szilles: Should we put it in create pseudos to select fallback?
14:01:36 <glazou> Present: andrey, johannes, Florian, leaverou, Chris, smfr, jet, dbaron, glazou, fantasai, simonsapin, bocampbell, szilles, dauwhe, Bert, TabAtkins, gregwhitworth, Rossen, plinss, shane, iankilpatrick
14:01:54 <TabAtkins> [wait, something about 'content' instead]
14:02:02 <TabAtkins> fantasai: We can't have a selector based on a property.
14:02:19 <glazou> Regrets: zcorpan, astearns, hyojin, antonp, dael, jdaggett
14:02:45 <TabAtkins> fantasai: For example, if we have 'content' image, it can get sliced in the middle by paginating.
14:03:00 <TabAtkins> dbaron: Does this property apply for things like inlines?
14:03:16 <TabAtkins> fantasai: Yes, it'll forbid a page break within the inline. (But we don't allow page breaks there anyway.)
14:03:41 <TabAtkins> Florian: Maybe explicitly add an "allow" value, and have "auto" give the right behavior to replaced content?
14:03:59 <TabAtkins> fantasai: Yeah, I think I like that better.
14:04:09 <TabAtkins> fantasai: I'll propose that to howcome and see what he thinks.
14:04:19 <dbaron> dbaron has joined #css
14:04:40 <TabAtkins> RESOLUTION: Never mind the previous resolution, instead try to redefine "break-inside:auto" to work correctly for replaced elements.
14:05:01 <TabAtkins> fantasai: So in this level, or next? I'm leaning for next level.
14:05:05 <TabAtkins> fantasai: Want to wrap up this level.
14:05:16 <TabAtkins> fantasai: And there's still some questions about what "auto" should do in some cases.
14:05:27 <TabAtkins> szilles: Agreed, it's too many unanswered questions for CR.
14:05:45 <TabAtkins> fantasai: So let's have auto do what it says right now, and next level we add the new behavior.
14:06:02 <TabAtkins> test
14:06:15 <glazou> test too
14:10:34 <TabAtkins> test
14:10:56 <ChrisL> ChrisL has joined #css
14:11:35 <TabAtkins> RESOLUTION: Don't make the break-inside changes for level 3; in level 4 look into the "allow" keyword and changing "auto" behavior to automagically work correctly.
14:12:02 <TabAtkins> fantasai: Next issue: "any" is confusing.
14:12:15 <TabAtkins> fantasai: What it does is find the nearest ancestor fragmentainer, and fragment that.
14:12:44 <TabAtkins> fantasai: If you have a multicol which is in a region chain, and we're printing. "any" will cause a column break.
14:13:56 <TabAtkins> Florian: Suggest "closest" as a name? Better than "deepest", which suggests starting at top rather than going down.
14:14:20 <TabAtkins> dbaron: "closest" might suggest lateral movement
14:14:33 <TabAtkins> TabAtkins: DOM has .closest(), from jQuery, which has this exact semantic.
14:15:13 <TabAtkins> fantasai: I'm not even sure "any" has a use-case.
14:15:39 <TabAtkins> fantasai: I'd like to hear from szilles, plinss, alan, etc for if there's even a use-case for "any" or if we should just drop it.
14:15:59 <TabAtkins> johannes: Why did we even add it?
14:16:28 <TabAtkins> fantasai: I think it was because we had an "always" value, and it wasn't clear what it meant. We decided it meant "break through everything", and we'd add "any" to have the other semanticd.
14:16:47 <TabAtkins> Florian: There's definitely cases to break the closest thing, but you probably know what type of break it is.
14:17:05 <TabAtkins> Florian: When you ask for a "column" break, does it break the nearest column or all?
14:17:09 <TabAtkins> Rossen: Nearest.
14:17:20 <johanneswilm> johanneswilm has joined #css
14:17:45 <TabAtkins> Rossen: I think that's the right use-case, yeah.  Content that might be in a multicol *or* a region, isn't aware of how it's fragmented, but wants a break.
14:18:12 <TabAtkins> Rossen: Like if you have content with sections, and you want sections to always start at the next fragment, regardless of whether it's in columns or pages.
14:18:23 <TabAtkins> szilles: Like if you have a template you're filling.
14:18:55 <TabAtkins> Florian: Using overflow:fragment, you might start in multicol and then overflow into a region chain.  You can't tell ahead of time what kind of break you need to trigger.
14:20:16 <TabAtkins> fantasai: Can we check if AH or Prince implements it?  If they do, and we can't come up with a *much* better name, we should maybe keep it.
14:20:33 <TabAtkins> Florian: Prince has the *-break-before props, but not the combined break-before, so no compat impact.
14:21:11 <TabAtkins> fantasai: [reviews the spec]
14:21:30 <TabAtkins> fantasai: Hm, "always" is defined as a page break here.  Looks badly specified.
14:21:39 <smfr_> smfr_ has joined #css
14:21:45 <TabAtkins> Florian: According to AH docs, they don't support "any".
14:22:39 <TabAtkins> fantasai: For regions, I can see a use-case for column and/or page break.  Regions are trickier.
14:22:51 <TabAtkins> fantasai: You can use them for paginating, but they might be for other weird things.
14:23:13 <TabAtkins> fantasai: So I can see a value that breaks columns/pages, but not regions.
14:24:00 <TabAtkins> TabAtkins: I'd prefer we wait till we have more fragmentation types, so we can generalize properly.
14:24:19 <TabAtkins> fantasai: We'll discuss over break, do mor ethinking.
14:24:27 <TabAtkins> fantasai: Next topic: what if I want to avoid breaks in columns *and* pages.
14:24:43 <TabAtkins> fantasai: I said to use "avoid". It also avoids region breaks, but for most cases it's probably good enough.
14:24:57 <TabAtkins> fantasai: We could let the property have multiple values.
14:24:59 <ChrisLilley> ChrisLilley has joined #css
14:25:06 <TabAtkins> fantasai: So you can say "avoid-column avoid-break" and leave regions alone.
14:25:16 <TabAtkins> fantasai: I dont' think that's too necessary. I suggest we wait for the next level.
14:25:43 <TabAtkins> plinss: I think it's less unusual to *force* breaks on column/page, but not regions.
14:25:56 <TabAtkins> plinss: So maybe worth doing all the combinations.
14:26:07 <TabAtkins> dbaron: I guess I"m starting to feel like this is a very weird API.
14:26:27 <TabAtkins> dbaron: It kinda made sense when it was just page breaks, but now that things can be nested, this doesn't feel like a sensible way to force a break.
14:26:34 <TabAtkins> dbaron: I don't have any ideas to fix it.
14:26:38 <Chris_Lilley> Chris_Lilley has joined #css
14:26:48 <TabAtkins> dbaron: But I think anyone who actually hits these cases will find the properties unsatisfying.
14:27:06 <TabAtkins> Florian: For advanced cases wouldn't you need to be able to name a fragmentainer, and say to break up to that name?
14:27:08 <TabAtkins> dbaron: Maybe.
14:27:12 <TabAtkins> fantasai: For regions especially, yeah.
14:27:19 <andrey-bloomberg> andrey-bloomberg has joined #css
14:27:31 <TabAtkins> Florian: [example of nested multicol]
14:27:41 <TabAtkins> Florian: Multicol text, and in that, small bulleted list that is multicol.
14:28:12 <TabAtkins> fantasai: My proposal is no change, and deal with it next level.
14:28:25 <TabAtkins> TabAtkins: Sounds reasonable to me.
14:28:33 <TabAtkins> dbaron: How stable is the break-before/after naming?
14:28:43 <TabAtkins> fantasai: Pretty stable. It's been in the multicol spec since that hit CR.
14:28:53 <TabAtkins> fantasai: We have impls in at least AH and (old) Opera.
14:29:03 <TabAtkins> dbaron: This discussion is making me skeptical that this is what we want.
14:29:28 <TabAtkins> szilles: Skeptical that it's hard to get what you want, or that there will be weird effects, or...?
14:29:31 <TabAtkins> dbaron: I think all of the above.
14:29:52 <TabAtkins> dbaron: It seems like we extended the old thing into the new thing, and it's not the right shape for the new thing.
14:30:58 <TabAtkins> fantasai: I think having a generic "region" name is awkward; you generally want to name the region you're breaking to.
14:31:08 <TabAtkins> fantasai: Pages/columns are less awkward. They don't nest often.
14:31:18 <ap_bb> ap_bb has joined #css
14:31:42 <TabAtkins> szilles: It seems to me there's a difference between "avoid", which you want to apply in any context, and breaks, which needs some information about context. Maybe sticking those together is the problem.
14:32:11 <TabAtkins> fantasai: Yeah, maybe. But you can't both force and avoid a break.
14:32:26 <TabAtkins> dauwhe: We had a user request for prioritizing breaks. TeX does that.
14:32:48 <TabAtkins> fantasai: We do have some priority - break-inside:avoid does some priority of what to do with breaks in descendants.
14:33:00 <TabAtkins> fantasai: Without using numbers. Would like to avoid the z-index problem.
14:33:28 <TabAtkins> fantasai: There might still be cases where an arbitrary number is necessary, but much smaller set.
14:34:04 <TabAtkins> Bert_: WRT named regions, we also had a proposal for naming page templates, so you could break to a particular type of page.
14:34:30 <TabAtkins> Florian: For InDesign, it has region/column/page/even-page/odd-page
14:34:51 <TabAtkins> fantasai: We have left/right/recto/verso in the break spec
14:35:01 <astearns> you want to name your fragmentation context, not really a specific region
14:35:04 <TabAtkins> fantasai: My proposal is to close issue 10 as no change, investigate syntax for next level.
14:35:25 <TabAtkins> RESOLVED: Close issue 10 no change, punt to next level.
14:35:41 <TabAtkins> fantasai: Last is about box-decoration-break and margins, and whether "clone" clones margins.
14:35:52 <TabAtkins> fantasai: If I have a box with a border, and it breaks, two ways to handle it.
14:35:56 <Florian> So this means that InDesign has neither always nor any
14:36:06 <TabAtkins> fantasai: First is to just slice the box, so no border at slice.
14:36:17 <bb75> bb75 has joined #css
14:36:17 <TabAtkins> fantasai: Other is to wrap the border around fully.
14:36:24 <TabAtkins> fantasai: So question is whether to clone margins too.
14:37:00 <TabAtkins> fantasai: So if you had margin-top, does that show up at the top of the next fragment?
14:37:07 <TabAtkins> Florian: Margin-collapsing?
14:37:11 <TabAtkins> fantasai: Interesting.
14:37:24 <TabAtkins> dbaron: And what if multiple collapsing elements have differing values for b-d-b.
14:37:49 <observer> observer has joined #css
14:37:50 <TabAtkins> fantasai: Current behavior is to restart at the border box; no cloning of margins.
14:38:02 <TabAtkins> Rossen: Yeah, anything else can get weird, especially with negative margins.
14:38:36 <TabAtkins> Rossen: Another case is the border itself being bigger than the next fragment; will infinite-loop currently.
14:38:53 <TabAtkins> fantasai: We said you have to make at least 1px of progress in each fragment.
14:40:04 <TabAtkins> Rossen: So you'd just print part of the borders on each page, with 1px of content overflowing off the page.
14:40:11 <TabAtkins> Rossen: Sounds "useful".
14:40:22 <Nik> Nik has joined #css
14:40:48 <TabAtkins> Rossen: I propose that if there's not enough space to clone, we drop the borders.
14:41:25 <TabAtkins> szilles: There's some govt stuff about mandatory borders on warnings.
14:42:25 <TabAtkins> Florian: Just don't print your govt warnings on 10px tall pages.
14:43:36 <TabAtkins> TabAtkins: This isn't something we're doing wrong on our part. It's badly-authored pages. It's the author's fault if they're violating some govt standard.
14:44:24 <TabAtkins> fantasai: So you drop the bottom border in each fragment.
14:44:35 <TabAtkins> Rossen: No, both borders. The top border can also be too tall.
14:44:59 <TabAtkins> Rossen: [draws example in MSPaint]
14:45:07 <bl4de> bl4de has joined #css
14:46:23 <TabAtkins> Rossen: In this example, the top border *itself* is too tall to go in the fragment.
14:47:19 <TabAtkins> TabAtkins: If we're willing to drop the bottom border to avoid the "1px of progress per page" case, why wouldn't we be willing to drop the top too? We can prioritize dropping bottom first.
14:47:22 <TabAtkins> Rossen: Yes.
14:47:32 <TabAtkins> szilles: What about left border?
14:47:54 <TabAtkins> Rossen: Not relevant; you don't fragment in 2d. You just overflow if your side borders are too big.
14:48:54 <TabAtkins> RESOLVED: If the cloned border is larger than the fragment, drop it. Drop bottom first; then drop top if still no space.
14:49:37 <TabAtkins> fantasai: And I think issue 13 is that it doesn't matter; margins get collapsed into the pagination break.
14:49:51 <TabAtkins> Rossen: Yeah
14:50:03 <TabAtkins> dbaron: Margins don't disappear for inlines, right?
14:50:05 <TabAtkins> fantasai: right
14:50:14 <TabAtkins> dbaron: Presumably b-d-b applies to inlines, too.
14:50:16 <TabAtkins> fantasai: Yes.
14:51:43 <TabAtkins> fantasai: So yeah, inlines are still a problem. No strong opinion, but since inline margins don't normally collapse into the line edge, I think we should keep it (clone inline margins)
14:52:27 <dael> dael has joined #css
14:53:54 <zcorpan> zcorpan has joined #css
14:54:02 <dbaron> FWIW, Gecko's implementation of box-decoration-break:clone on inlines does agree with what we just resolved
14:54:09 <dbaron> (er, except we didn't record a resolution!)
14:54:11 <smfr> smfr has joined #css
14:54:15 <dbaron> i.e., we do clone the margins
14:54:18 <fantasai> RESOLVED: box-decoration-break clones margins
14:54:28 <fantasai> (note this only affects inlines)
14:59:59 <AH_Miller> AH_Miller has joined #CSS
15:00:12 <AH_Miller> AH_Miller has left #css
15:22:19 <fantasai> ScribeNick: fantasai
15:22:24 <bcampbell> bcampbell has joined #css
15:22:24 <fantasai> Topic: Snapshot & State of CSS
15:22:43 <fantasai> glazou: During AC meeting, two weeks ago, there were extensive discussions about future of HTML and organization of all activities of the consortium
15:22:52 <fantasai> glazou: One of the proposed plans is to drastically reshuffle the working groups
15:22:59 <fantasai> glazou: HTML, WebApps, etc.
15:23:08 <fantasai> glazou: The good thing is that the CSSWG would be untouched.
15:23:19 <fantasai> glazou: "It is an example of a WG that works well, and we don't touch things that work well."
15:23:27 <fantasai> glazou: I think we should be glad about it :)
15:23:46 <fantasai> glazou: One remark I got, there are more and more questionsa bout "what is the current state of CSS" and "what is CSS as of today"
15:24:02 <fantasai> glazou: People are aware of the snapshots, and current-work, and our work on the /TR page
15:24:13 <fantasai> glazou: They would like us to maintain it better, automatically or not, don't care, but better
15:24:36 <fantasai> glazou: If you are a newcomer, where do you find out standards-wise the state of CSS or implementation-wise the state of CSS?
15:24:57 <fantasai> glazou: I asked plh, do you really want us to handle implementation status ourselves? There is caniuse, etc.
15:25:25 <fantasai> glazou: He replied, yes, I'd love to have workforce within W3C to handle these kind of things.
15:25:41 <fantasai> Florian: I would guess the goal would be different than caniuse
15:25:51 <fantasai> glazou: Question is, can I rely on it or not?
15:26:12 <fantasai> glazou: I think it would be important wrt outreach for us to handle these concerns.
15:26:27 <fantasai> glazou: Question wrt "what is CSS3?", answer is "no such thing"
15:26:30 <fantasai> glazou: What can we do on this front?
15:26:45 <fantasai> Chris_Lilley: Related to publishing, there's an effort to share scripts, e.g. mathjax
15:27:05 <fantasai> Chris_Lilley: Another one is our testing status script, which annotates the headings with our test results
15:27:27 <fantasai> Chris_Lilley: Right now, it's removed from our specs for /TR, but in the future will include in /TR publications
15:27:46 <fantasai> [discussion of bikeshed's inlining of stuff]
15:27:58 <fantasai> Chris_Lilley: There will be centrally managed scripts that we can publish with
15:28:43 <fantasai> [discussion of systems logistics]
15:30:00 <gregwhitworth> gregwhitworth has joined #css
15:31:39 <fantasai> glazou: The current-work page... is it automated?
15:31:52 <fantasai> Bert_: It's built off a .ini file that generates html
15:32:32 <fantasai> fantasai: We can't automate that, because the status is more granular than the W3C statuses
15:32:38 <dbaron> dbaron: Can't we put that status in the spec?
15:33:08 <fantasai> [discussion of automation]
15:33:25 <fantasai> Florian: What should also be in the draft in machine-readable format is, what spec is this spec replacing?
15:33:32 <fantasai> Florian: We have this in the Module Interactions section
15:33:41 <fantasai> Florian: We should mark this up
15:33:59 <fantasai> Chris_Lilley: The IETF got this right, they update when a spec has been obsoleted
15:34:27 <fantasai> TabAtkins: I have a standing bikeshed issue to do exactly that
15:34:49 <fantasai> glazou: I would like an action item to make this automated
15:35:00 <johanneswilm> johanneswilm has joined #css
15:35:09 <fantasai> glazou: May not be able to put it in the official headers...
15:35:18 <fantasai> dbaron: We put pretty arbitrary things in the headers at this point.
15:35:27 <fantasai> glazou: I will take an action item to gather all the data
15:35:43 <fantasai> glazou: Next issue, some documents on dev.w3.org have no advocate, and we'll need to anull them.
15:35:51 <fantasai> fantasai: Tables
15:36:43 <fantasai> gregwhitworth: wrt the caniuse stuff, is there an index of some kind in addition to the headers?
15:36:46 <fantasai> ...
15:36:53 <fantasai> Chris_Lilley: Want an index of all properties
15:37:02 <fantasai> fantasai: On Tab's to-do list for bikeshed. Will be part of the Snapshot
15:38:06 <fantasai> [discussion of updating snapshot]
15:38:43 <fantasai> glazou: If we update current-work automatically, do we still need the snapshot
15:39:33 <fantasai> fantasai: Snapshot has more context, prefixing policy, indexes, etc.
15:39:37 <fantasai> glazou: I'm not so sure
15:40:30 <fantasai> Chris_Lilley: If there's an up-to-date index of properties, why would anyone look at the snapshot that's updated once a year?
15:40:40 <fantasai> fantasai: That's the same issue of why should anyone ever look at specs on /TR
15:41:00 <fantasai> Armen Nakashian (observer): I've had a lot of frustration with /TR and documents on the website
15:41:10 <fantasai> Armen: It's hard to tell what is up to date, am I looking at the right thing?
15:41:26 <fantasai> Armen: I tried from portal, can't find anything, end up googling and landing in something ancient
15:41:39 <fantasai> Armen: Find interesting context, but usually not quite the right thing
15:41:48 <fantasai> Armen: Often way out of date
15:42:02 <fantasai> Armen: Lots of professional looking documents, but nothing ages the document out
15:42:09 <fantasai> Armen: Don't know if what you're proposing will help
15:42:28 <fantasai> Chris_Lilley: Some specs has red boxes as warning
15:42:34 <fantasai> Florian: We have htis on specs that are known to be wrong.
15:42:41 <fantasai> Florian: Don't have this on /TR drafts that haven't been published recently
15:43:07 <fantasai> Chris_Lilley points out that Google link ranking works against us, because older documents tend to have more incoming links
15:43:47 <fantasai> SteveZ: There's a standing request for IT to automate flagging out-of-date documents
15:44:00 <fantasai> SteveZ: Overlay a watermark saying this document is out of date, click on link for up-to-date document
15:44:35 <fantasai> Florian: Would that hande, e.g. multicol spec that has no newer spec?
15:44:53 <fantasai> fantasai: We could add a script to the script library that does exactly that.
15:45:16 <fantasai> gregwhitworth: Is the stuff that we're discussing going to have a JS API?
15:45:59 <fantasai> Bert_: There will be a JSON api for published specs
15:46:37 <fantasai> [discussion of who's working on that]
15:48:36 <fantasai> [side discussions]
15:49:15 <fantasai> Bo: For someone learning the process, it's very difficult experience trying to understand what these documents mean, what version, where they are
15:49:24 <fantasai> Bo: Why is it out of date? Where are we going? Who is the target audience here?
15:49:51 <fantasai> glazou: I want a link to current-work on all pages
15:49:59 <fantasai> glazou: Last stable state, current version, next stage
15:50:17 <fantasai> glazou: We'll have to think about these extra bits of prose on status to the document
15:50:23 <fantasai> glazou: Once we have that, we can start to think about caniuse, etc.
15:50:28 <fantasai> glazou: Need basic information about the spec first
15:51:23 <fantasai> Bo: Status, what is an editor's draft, what does it mean to me, etc.
15:51:43 <fantasai> fantasai: There's a stalled project on redesinging the spec templates, shoudl help with that.
15:52:02 <fantasai> SteveZ: The specs aren't really the best place for developers to start learning about somehting. Goal is interoperable implementations.
15:52:14 <glazou> s/DOES/DOES NOT
15:52:15 <fantasai> TabAtkins: Good examples always help, help implementers too
15:52:44 <fantasai> Jonas: THe idea of having spec for developer is to check if what he expects of behavior, if that's what the spec says
15:52:54 <fantasai> johanneswilm: If browser doesn't do that, then he can file a bug
15:53:31 <fantasai> Florian: Nobody should be learning CSS from scratch from the specs, but once you have the foundation, specs are sometimes the best place to learn about a new thing
15:53:47 <fantasai> TabAtkins: I get this same feedback from web developers as well. Not everybody, but some developers do that.
15:54:07 <fantasai> SteveZ: Also over time; once I'm familiar with something, more likely to look to spec, cuz has all the details
15:54:47 <fantasai> ACTION fantasai file an issue against Tab for bikeshed to include CSSWG status codes
15:54:47 <trackbot> Created ACTION-684 - File an issue against tab for bikeshed to include csswg status codes [on Elika Etemad - due 2015-05-25].
15:55:10 <fantasai> ACTION leaverou write outdated-spec-watermark script for w3.org to put on /TR
15:55:11 <trackbot> Error finding 'leaverou'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
15:55:37 <fantasai> ACTION glazou Investigate which data needs to be added and how to automate current-work
15:55:39 <trackbot> Created ACTION-685 - Investigate which data needs to be added and how to automate current-work [on Daniel Glazman - due 2015-05-25].
15:56:11 <fantasai> glazou: OK, so we will do these actions, and then go back to AC/plh and iterate
15:56:19 <fantasai> Topic: Grid Issues
15:56:44 <glazou> https://lists.w3.org/Archives/Public/www-style/2015May/0148.html
15:57:05 <fantasai> 
15:57:07 <Bert_> Scribenick: Bert
15:57:12 <Bert_> Scribenick: Bert_
15:57:50 <Bert_> -> https://lists.w3.org/Archives/Public/www-style/2015May/0148.html issues
15:58:05 <Bert_> TabAtkins: 2 basic cases:
15:58:39 <Bert_> ... A and B
15:58:53 <Bert_> ... Case A grid container determines static position
15:59:27 <Bert_> ... Case B grid container determines size
15:59:34 <Bert_> ... case C [...]
15:59:49 <Bert_> fantasai: [Draws on whiteboard]
16:00:28 <Bert_> ... [3x3 grid, cell 8 is container, elt has an offset relative to top left of cell 1]
16:01:11 <Chris_Lilley> s/[...]/grid container determines both
16:01:14 <Bert_> ... This is in the case 'grid-row: 3; grid-column: 2'
16:01:35 <Bert_> ... grid is the CB for the abspos elt.
16:01:38 <Bert_> ... If you don
16:02:01 <Bert_> t specify grid pos property, then padding edges are the lines to use.
16:02:05 <dbaron> fantasai: abs pos in grid *with* grid positioning property use the grid cell as their CB
16:02:17 <dbaron> Tab: This was done to address use case of content responding to grid but not vice versa
16:02:18 <Bert_> ... Identical to a 'block'
16:02:42 <Bert_> TabAtkins: 1st issue is:
16:03:17 <Bert_> ... we treat the two cases separately, so the static position in one case isn't determiend by the grid, can be outseide it.
16:03:35 <Bert_> ... We called it out specially in the draft, so that static pos respects the bounds.
16:03:44 <Bert_> fantasai: There are 3 possibilities;
16:04:02 <Bert_> ... 1) We don't care that the stat pos is outside.
16:04:47 <Bert_> ... 2) In cases where grid container is parent and CB of abs pos elt, then static pos uses grid positioning props and offset from there.
16:05:16 <Bert_> ... 3) In all cases, if parent is grid container, than use grid containter to determine stat pos, and offset from there.
16:06:00 <Bert_> TabAtkins: Spec currently has [???]
16:07:01 <Bert_> dbaron: If grid pos props are used, in 3rd case, is the static pos (0,0)?
16:07:26 <Bert_> ... I'd like not to add more complications to static position. It was a hack in the first place...
16:07:40 <Bert_> ... Don't complicate unless there is a use case.
16:07:57 <Bert_> ... So you propse B?
16:08:00 <Bert_> TabAtkins: No, A
16:08:25 <Bert_> dbaron: The ordering of proposals is weird...
16:08:33 <Bert_> TabAtkins: I find B incoherent.
16:09:00 <Bert_> ... Grid container parent and CB are using same grid pos properties, even if they may be diffrernt grids.
16:09:09 <Bert_> ... So I'm for A or C.
16:09:14 <Bert_> ... Spec says A currently.
16:09:26 <Bert_> fantasai: Prev draft said C, we changed it.
16:09:36 <Bert_> Rossen: Flex spec is closer to C.
16:10:04 <Bert_> ... If you have props that target grids, and you r paren tis a grid,
16:10:13 <Bert_> ... your statioc pos may be affected.
16:10:27 <Bert_> ... In Flex wesaid, you static pos is not affected.
16:10:38 <Bert_> ... So I'm with dbaron.
16:10:50 <Bert_> ... More or less static pos tracks inline position.
16:10:59 <Bert_> TabAtkins: OK
16:11:01 <Bert_> fantasai: OK
16:11:23 <Bert_> dbaron: Or we can says in some cases static pos is (0,0), more like A.
16:11:36 <Bert_> fantasai: You can set offsets to 0, if you want it in that box.
16:12:39 <Bert_> Rossen: Elika said static pos possibly outside grid, that is not a pb. You can either use 0,0, or use grid-row/columns.
16:12:57 <Bert_> fantasai: Other option with 'auto' option...
16:13:01 <Bert_> TabAtkins: That is option A
16:13:15 <Bert_> fantasai: No, say you have an arbitrary descendant of the grid,
16:14:09 <Bert_> ... and it is abs positioned,
16:14:25 <Bert_> ... I want it to be pos'ed to the grid container,
16:15:12 <Bert_> ... you'd have to set all offsets to 0.
16:15:31 <Bert_> Florian: Is that same as A?
16:15:45 <Bert_> TabAtkins: There is a difference in case [...]
16:15:58 <Bert_> Rossen: Why do we mix static pos and grid pos?
16:16:07 <Bert_> ... If I have an inline abs pos elt,
16:16:30 <Bert_> ... And I have a static pos based on its text wrapping,
16:16:51 <Bert_> ... why then do I need to ignore the stat pos when an ascender is a grid?
16:17:08 <Bert_> ... If it is a firs-level child of the grid,
16:17:50 <Bert_> ... then stat pos is parent.
16:18:24 <Bert_> TabAtkins: In both A nd C, the stat pos computation must be the same.
16:18:51 <Bert_> [Confusion over which is A which is C]
16:19:18 <Bert_> dbaron: Tab said grid pos properties should not aply to two different grids.
16:19:40 <Bert_> ... That implies grid pos pops need to *never* apply for determineing stat pos.
16:20:14 <Bert_> TabAtkins: OK, so stat pos is always (0,0).
16:20:25 <Bert_> Rossen: [Draws trees]
16:20:42 <Bert_> ... When computing stat pos in either of these trees,
16:21:19 <Bert_> ... the grid elt may or may not be positioned itself.
16:21:42 <Bert_> ... The stat pos should always be computed releative to CB.
16:21:56 <Bert_> ... If abs pos elt is direct child of grid,
16:22:13 <Bert_> ... then q is if row/col shoul dbe taken into account.
16:22:42 <Bert_> ... That is the only issue we have to decide on.
16:23:00 <Bert_> dbaron: Inside there may be another grid.
16:23:10 <Bert_> Rossen: We are talking about stat pos.
16:23:32 <Bert_> dbaron: There may be nested grids. Then grid-row/column prop may be applied twice.
16:23:42 <Bert_> Rossen: That is execatly what I dont' want.
16:24:23 <Bert_> ... If we all agree that we want the simple case, static pos is (0,0), i.e, not based on grid-row/column properties, then life becomes simple.
16:24:47 <Zakim> Zakim has left #css
16:25:41 <Bert_> SteveZ: If an elt is inside a container, and I want it in a cell...
16:26:13 <Bert_> Rossen: Compare case of abs pos elt between two table rows, what is its stat pos? That's the same case.
16:26:54 <Bert_> SteveZ: It seems the default doesn't do the right thing. It should have all four offsets 0.
16:27:28 <Bert_> Florian: So Rossen's objection is that stat pos shuld not depend on whether parent is a grid?
16:28:14 <Bert_> Rossen:Yes, because then an unrelated property may require re-validating.
16:28:16 <dauwhe> dauwhe has joined #css
16:29:24 <Bert_> RESOLVED: Proposal c
16:30:15 <Bert_> @@: Do I have to find the margins and paddings if I want an elt to span?
16:30:44 <Bert_> fantasai: No, span from 1 to -1. That is different from static pos.
16:30:57 <Bert_> TabAtkins: 2nd issue:
16:32:06 <Bert_> fantasai: Initial valueof grid pos props is 'auto'
16:32:14 <Bert_> ... That puts elt in next slot.
16:32:36 <Bert_> ... There is an implied special line at the padding edge.
16:32:55 <Bert_> ... But then we we need to define these lines relative to rest of grid.
16:33:03 <Bert_> ... What does span 2 mean?
16:33:20 <Bert_> ... Is it the "negative 0" line?
16:33:40 <Bert_> SteveZ: So you're giving a label to the line?
16:33:54 <Bert_> fantasai: We're not actually allowing to refer to the line directly.
16:34:25 <Bert_> Rossen: Authors would expect in a 2x2 grid with span 2, you would span the slots.
16:34:37 <Bert_> TabAtkins: You' dhave to say span: 1/2
16:35:15 <Bert_> SteveZ: These cases will be explicitly warned about in the spec?
16:35:53 <Bert_> Rossen: Seems OK, if you want to snap to a grid line, then say so explicitly.
16:36:45 <Bert_> RESOLVED: Auto line counts as the 0 for negative 0 line for span purposes.
16:38:28 <Bert_> TabAtkins: Next issue. Any lines byond implicit grid are clamped. Position at line 100, will be at actual last line.
16:38:39 <Bert_> fantasai: But that doesn't work for spans,
16:39:10 <Bert_> ... So option A is not an option.
16:39:36 <Bert_> ... Options are B, C, D, E.
16:40:02 <Bert_> Rossen: I like E
16:40:07 <Bert_> TabAtkins: E is terrible.
16:40:28 <shepazu> shepazu has joined #css
16:40:30 <Bert_> Rossen: Yes, it is invalid, so you fall back to static pos. It is an error condition.
16:40:56 <Bert_> SteveZ: So I have a 2x2 grid and position to start on 2 and 4, what happens?
16:41:34 <Bert_> TabAtkins: [Draws case with 2x2 grid and position on 3/5]
16:41:52 <Bert_> SteveZ: So I will see something in the padding area?
16:42:24 <Bert_> TabAtkins: Not in option C. In D and E yes.
16:42:51 <Bert_> TabAtkins: In that case 3 is valid line, 5 is not. Take case 4/5, both lines invalid.
16:43:08 <Bert_> SteveZ: So the case with one valid line and one invalid?
16:43:23 <Bert_> fantasai: In a lot of error cases you'll end up in the padding area.
16:43:44 <Bert_> SteveZ: As long as I at least see something, so I can see I did something stupid.
16:44:26 <Bert_> TabAtkins: In normal grid 3/5 and 4/5 look very similar. Would be starnge if abs pos suddenly chnages that.
16:45:07 <Bert_> SteveZ: So if I understand: You want to snap to last valid line and snap to auto line if [...]
16:45:21 <Bert_> ... In 4/5 case, nothing displays, it's zero-width.
16:45:33 <Bert_> dbaron: People may use it as a feature.
16:45:54 <dbaron> s/People may/in Elika's case it sounds like people are more likely to/
16:46:14 <dbaron> (which I think is probably a bad thing)
16:46:58 <Bert_> @@: Chnaging the grid may make it impossible to see why things go wrong.
16:48:03 <Bert_> fantasai: Could say invalid start edge means first padding edge, invalid end edge means last pdding edge.
16:48:12 <Bert_> TabAtkins: [Draws]
16:48:41 <Bert_> ... 3/100 shows on the right, 4/100, because 4 is invalid, spans whole elt.
16:49:06 <Bert_> ... Under proposal D, 4/100 would also be on the right.
16:49:47 <Bert_> ... So choices are D and E.
16:49:57 <Bert_> strawpoll: 7 for E
16:50:03 <Bert_> 2 for D
16:50:13 <Bert_> E wins
16:50:15 <dbaron> (Tab and I were for D)
16:50:44 <Bert_> RESOLVED: Proposal E wins for issue 17
16:51:33 <Bert_> TabAtkins: Final issue:
16:51:39 <Bert_> ... We said final line is padding edge.
16:51:55 <Bert_> ... That is fine if elt is bigger.
16:52:12 <Bert_> ... Now imagine elt is smaller and we have a scroll bar.
16:52:38 <Bert_> ... And assume overflow is visible.
16:52:45 <dbaron> Does CSS actually define that "inner padding edge"?
16:52:53 <Bert_> ... [Draws on whiteboard]
16:53:16 <Bert_> ... There are four options.
16:53:32 <Bert_> ... A, B, C, D
16:54:16 <Bert_> dbaron: Is that the correct padding edge as defined by CSS? Is that term defined at all?
16:54:58 <Bert_> TabAtkins: A is last grid or padding, whichever is further out.
16:55:14 <Bert_> ... B is to flip start/and
16:55:30 <Bert_> ... C is to ignore auto line
16:55:49 <Bert_> ... D is anything else.
16:56:21 <Bert_> Rossen: We don't ignore static pos in normal case, so we shouldnt ignore it here.
16:56:45 <Bert_> ... I believe that means option B.
16:57:18 <Bert_> fantasai: We already decided we use the auto line, we now have to decide where the auto line is.
16:57:59 <Bert_> Florian: So do we make position '5/3' be the same as '5/3'?
16:58:36 <Bert_> plinss: Why do we have an auto line that is not grid line?
16:58:51 <Bert_> fantasai: BEcuse pos is normally defined by a box, not a grid line/
16:59:13 <Bert_> TabAtkins: We want ot be able to position against the edge.
16:59:48 <Bert_> fantasai: E.g., a centered grid in an elt, or with a large padding.
16:59:57 <Bert_> ... Grid doesn't always fill the container.
17:00:46 <Bert_> TabAtkins: So rossen likes B, Florian suggested chnaging the error correction by swapping 5/3 to 3/5.
17:01:18 <Bert_> ... Should we always treat 5/3 as 5/3?
17:01:39 <Bert_> ... Or 5/3 becomes 5/auto, as curently?
17:01:53 <Bert_> plinss: Also swap named lines?
17:02:08 <Bert_> TabAtkins: Yes, same way.
17:02:30 <Bert_> Rossen: Makes sense. Imagine you snap to lines and later reposition the lines.
17:02:56 <Bert_> TabAtkins: It may not be intentional, it may be just a mistake, but I'm fine with it.
17:03:15 <dbaron> I think the resolution above with "0 for negative 0" should say "0 or -0"
17:03:20 <Bert_> SteveZ: I'd need more time, but
17:03:43 <Bert_> ... but bothered that turning off scrolling makes things behave differently.
17:03:54 <Bert_> TabAtkins: Overflow does that.
17:04:13 <Bert_> SteveZ: It seems a simple chnage, but with unexpected results.
17:04:35 <Bert_> SteveZ: Not sure what option B means.
17:05:10 <Bert_> TabAtkins: It means auto line can be always the padding edge, even with overflow.
17:06:21 <Bert_> TabAtkins: A and B each make two different cases out of four consistent.
17:06:45 <Bert_> ... So seems we lean to consensus on B.
17:07:14 <Bert_> ... Proposeal: Padding edge is always the auto line, and we will error-correct mis-ordered lines:
17:07:54 <Bert_> RESOLVED: Padding edge is always the auto line, and we will error-correct mis-ordered lines.
17:08:53 <Bert_> [lunch]
17:10:26 <Florian> Florian has joined #css
17:11:31 <Florian> Florian has joined #css
17:18:31 <Florian_> Florian_ has joined #css
17:21:37 <zcorpan> zcorpan has joined #css
17:30:50 <renoirb> renoirb has joined #css
17:33:37 <shepazu> shepazu has joined #css
17:53:42 <Florian> Florian has joined #css
17:56:28 <johanneswilm> johanneswilm has joined #css
17:56:35 <dauwhe> dauwhe has joined #css
17:59:27 <smfr> smfr has joined #css
18:04:07 <Ms2ger> Ms2ger has joined #css
18:09:06 <smfr> smfr has joined #css
18:16:15 <glazou> glazou has joined #css
18:19:50 <quadcore> quadcore has joined #css
18:26:56 <bcampbell> bcampbell has joined #css
18:28:54 <shane> scribenick: shane
18:29:29 <shane> Florian: white-space pre-wrap  interoperability
18:29:45 <shane> Florian: runs of spaces are preserved interoperably except at the end of the line
18:29:54 <shane> ... firefox does the specified base behavior
18:30:24 <shane> ... nbsps are part of the word before.
18:30:39 <shane> ... spec also says you can collapse nbsps, which is what Chrome does
18:30:53 <shane> ... IE doesn't match the spec - doesn't wrap, but preserves the spaces
18:31:48 <shane> ... switching word-wrap to break-word changes things. For Firefox, moves spaces down to the next line. Not for Chrome or IE.
18:31:55 <smfr> http://florian.rivoal.net/csswg/wrap/wrap.html
18:32:06 <shane> ... possibly due to ambiguity in spec which doesn't define what a word is
18:32:18 <shane> fantasai: the spec says you can break between any two letters
18:32:41 <shane> Florian: IE has different interpretations depending on whether in a regular element or a text area
18:32:53 <shane> ... in a text area it behaves like Firefox
18:32:54 <fantasai> Nevermind, I'm thinking of word-break, not word-wrap
18:33:01 <shane> Rossen: editable or not makes a difference
18:33:30 <shane> Florian: another one - word-break: break-all. Firefox will break between anything (letters or nbsps). Not what spec says (spec says letters only)
18:33:57 <shane> ... Chrome and IE break in words but not in spaces, like the spec says.
18:34:12 <shane> ... finally, combining both. In IE on text areas it does something .. weird.
18:36:20 <shane> Florian: go to http://florian.rivoal.net/csswg/wrap to see
18:36:46 <shane> ... things get more interesting if you align: right instead of align: left.
18:37:04 <shane> ... consistent with what's happening before, but the fact that Firefox doesn't collapse nbsps amplifies the differences.
18:37:24 <shane> ... same is true of centering or justifying
18:37:47 <shane> ... Point is: no interop at end-of-line with a bunch of nbsps
18:38:26 <fantasai> s/nbsps/spaces in pre-wrap/
18:38:32 <shane> ... Do we agree that there's something that needs to be fixed?
18:39:27 <shane> ... Going back to align: left. Even though Firefox is compliant, I don't think the result is very nice.
18:39:38 <shane> ... Chrome and IE have more reasonable behavior in the simple case.
18:40:01 <shane> ... in the Chrome view, though, if you want to apply word-wrap: break-word then you never get spaces wrapping on the next line.
18:40:22 <shane> ... I think this is nice - you're asking for space to be preserved and things to be wrapped, so the spaces should be wrapped.
18:41:06 <shane> ... so I think we should choose Chrome or IE behavior for base case, and either preserve the spaces (IE case) or reinsert them (Chrome case) when wrapping.
18:42:02 <shane> ... one issue is that word-break: break-all and word-wrap: break-word would then start to behave the same.
18:42:31 <shane> ... proposal: add break-spaces to word-wrap (which is now overflow-wrap, btw) to support the case previously word-break: break-all.
18:42:50 <shane> fantasai: I think we want to have another value for whitespace which allows breaking in runs of spaces, and makes those spaces kind of visible.
18:43:06 <shane> fantasai: another issue, should we underling the trailing spaces?
18:43:28 <shane> Florian: in the base case, probably don't care about the spaces so everything should get pushed right.
18:43:50 <shane> ... only if you really really ask for the spaces to be preserved.
18:44:08 <shane> ... difference between kinda preserve the spaces sometimes and, no, really, preserve them
18:44:28 <shane> SteveZ: why are the ones on the left important but not the ones on the right?
18:44:54 <shane> ... left with left-align are preserved. Why not right with right-align?
18:45:42 <shane> Florian: if you do want the spaces on the right edge to be taken into account you do pre-wrap. If not you do pre-line.
18:45:53 <shane> fantasai: pre-line will also collapse the spaces within the line
18:46:06 <shane> ... seems like people might want to do special things at beginning/end only
18:46:23 <shane> Florian: (1) is there a problem? (2) can we agree on the base case? (3) which additional switches are important?
18:46:35 <shane> ... think we should at least be interoperable in the base case.
18:47:23 <shane> ... will also cause problems in content-editable. Pressing space in Chrome won't do anything but in IE will advance the cursor to the right
18:47:33 <shane> Rossen: that's why we did it. Similar to Word behavior
18:47:51 <shane> Florian: so IE probably has the best behavior but isn't spec compliant
18:47:57 <shane> ... we should fix it.
18:48:11 <shane> johanneswilm: what's the relation between that and the white-space property?
18:48:25 <shane> Florian: in all of these cases, white-space is pre-wrap. So spaces are preserved.
18:50:51 <shane> <debate over which behavior is best in each case>
18:51:18 <shane> Florian: and what about the other alignments? Same behaviors?
18:52:07 <shane> johanneswilm: with poetry example, wouldn't you just set the white-space to something else?
18:52:17 <shane> Rossen: e.g. white-space: preserve?
18:53:04 <shane> Florian: do we have agreement that we should seek interoperability? That will require changes in browser behaviors
18:53:29 <shane> smfr: for Safari we'll need to look at which clients use the combinations that would change and see if that would cause deviations in their behavior.
18:54:16 <shane> Rossen: so last time we were wondering: does this really matter?
18:54:28 <shane> Florian: why do we have these properties if it doesn't matter?
18:54:36 <shane> Rossen: haven't seen any bugs
18:54:50 <shane> Florian: maybe because there's no interoperability so no-one is using them.
18:55:05 <shane> ... Bloomberg had a requirement for something that is none of the above.
18:55:23 <shane> ... word-wrap: break-word on, with spaces being preserved on the next line.
18:56:01 <shane> fantasai: so basically they want a break opportunity anywhere in the spaces rather than at the end.
18:56:07 <shane> ... which I think makes a lot more sense.
18:56:17 <shane> Florian: but nobody does that in the base case yet.
18:56:39 <shane> Rossen: so you want to be able to break on any space that happens to hit the end of the containing block space, but you don't want to break inside words?
18:56:52 <shane> ... and also preserve all the space?
18:56:59 <shane> Florian: I think that's one desirable behaviour.
18:57:13 <shane> fantasai: that would be my preferred default.
18:57:45 <shane> <discussion about priorities>
18:58:06 <shane> smfr: is it really about where to break, or about ignoring the trailing spaces on the line?
18:58:34 <shane> Florian: I don't think there's a single thing that authors want. Having the spaces go off and disappear might be one thing they want. Wrapping spaces when they hit the end of the line might be another.
18:58:42 <shane> Rossen: what does content-editable do?
18:59:00 <shane> Florian: same as text areas, I think. Strange things if not white-space: pre-wrap (for legacy)
18:59:34 <shane> ... spec says this is insane so authors should opt into sanity by using white-space: pre-wrap
18:59:38 <shane> ... which doesn't do the right thing
18:59:53 <shane> fantasai: I think we should have 2 values, one for content-editable thing and one for looking pretty thing
19:00:33 <shane> fantasai: if there's a wrap opportunity and we're not taking it but we are overflowing - that's weird.
19:00:52 <shane> ... so, one mode where spaces are visible chunks of wrappable text, and underline
19:00:59 <shane> ... and another which something something
19:02:00 <shane> johanneswilm: just to note, in content-editable there are lots of problems in various browsers.
19:02:17 <shane> Florian: the intent is reasonable but the way of achieving it is a huge hack that's only kind of working
19:02:48 <shane> fantasai: if we made the behavior of pre-wrap different to what you're doing and added another value that does what you're doing, would that be OK?
19:03:19 <shane> smfr: we'd need to change our UA stylesheet for text areas. Might also have other clients but could deal with that. Preference would be not to change the behavior but if necessary could switch to a new value.
19:03:45 <shane> fantasai: current behavior hard to explain. Would be more understandable if we did it differently.
19:04:36 <shane> smfr: we don't want a behavior change in text area.
19:04:41 <shane> fantasai: that would be up to the UA
19:05:27 <tantek> tantek has joined #css
19:05:32 <shane> glazou: I want to avoid liberties for UA to do things inside text areas that become too hacky for WYSIWYG editors to rely on
19:05:47 <shane> fantasai: if you set pre-wrap then you get the base behavior
19:06:11 <shane> ... you probably want default behavior for text areas to match the platform, which we're not going to be able to standardize
19:06:27 <shane> Florian: that doesn't happen currently
19:08:42 <shane> Florian, fantasai, et al?: So have a default that is 'same as system text' (auto?) then change base case (word-wrap: normal) to something sensible and interoperable, and have another case for text input that is interoperable.
19:09:53 <shane> Florian: so are browsers happy with that?
19:09:59 <Bert_> (white-space: pre-wrap-but-keep-spaces-at-line-breaks' but with a slightly shorter name?)
19:10:54 <Chris_Lilley> (white-space: preserve-spaces)
19:11:53 <shane> fantasai: we have a combinatorial problem here: white-space: pre-wrap|new-value; word-wrap: normal|break-word; word-break: normal|break-word;
19:12:07 <shane> ... so white-space is the two base cases, for nice text and for editable text.
19:12:19 <shane> ... then word-wrap and word-break are two properties that modify that
19:13:17 <shane> ... word-break: break-word is treat english characters like chinese characters, essentially
19:13:28 <shane> ... word-wrap: break-word is do terminal-style wrapping
19:14:11 <shane> Florian: so if you're in the Chrome behavior (collapsing spaces at EOL) and you turn on break-word then you resurrect the spaces?
19:14:18 <shane> fantasai: no
19:15:00 <shane> ... so there's 8 combinations.
19:15:29 <shane> Florian: do we want another keyword for an interoperable edit behavior?
19:15:40 <shane> fantasai: should wait and see if there's a demand
19:15:52 <shane> ... a lot of those cases will be dealt with by pre-line
19:16:41 <shane> smfr: how does pre-line and pre-wrap differ?
19:16:53 <shane> fantasai: pre-line collapses all the spaces but preserves line breaks
19:17:22 <shane> SteveZ: how does it interact with hyphenation?
19:17:37 <shane> fantasai: different switch. hyphens never insert into sequences of whitespace
19:17:53 <shane> .. hyphenate first, chunk if unhyphenatable
19:18:13 <shane> Florian: call do-whatever-the-platform-does auto.
19:18:21 <shane> Bert_: what does pre-wrap do then?
19:18:36 <shane> Florian: preserves the spaces, and wraps.
19:19:12 <shane> Bert_: should drop spaces at wrap points
19:19:36 <shane> fantasai: that's asymmetric - spaces at left side are preserved.
19:20:07 <shane> Bert_: that's what the new value should be for, rather than auto
19:20:43 <shane> Florian: that's what we wanted to wait for demand for.
19:20:47 <shane> ... can we?
19:21:05 <shane> ... no consistency between editors
19:21:20 <shane> fantasai: in a text editor, when you wrap to the next line the space is gone. Not invisible, gone.
19:21:29 <shane> ... we're just talking about the rendering.
19:21:55 <shane> ... not modifying the DOM
19:22:00 <shane> ... or exporting
19:23:07 <shane> <more discussion about asymmetry>
19:23:55 <shane> Florian: so conceptually, three values exist. May not need to add Bert's just yet. Default should be auto.
19:24:17 <shane> smfr: auto is awkward - it's a pre- behavior.
19:24:31 <shane> Florian: auto-pre-wrap?
19:25:02 <shane> fantasai: can we resolve on this?
19:25:45 <shane> ChrisL: is that OK with you, Microsoft?
19:25:52 <dauwhe> dauwhe has joined #css
19:25:54 <shane> Rossen: once we start defining it, we'll see
19:26:17 <shane> ... not ready for discussion yet but won't block.
19:26:22 <shane> ... will revisit when it's better defined.
19:27:12 <shane> smfr: can UAs specify this behavior for content-editable?
19:27:14 <shane> Florian: yep
19:27:20 <shane> fantasai: but would you want to?
19:27:51 <ChrisL> s/is that OK/I heard explicit agreement from Apple - is that OK/
19:29:37 <shane> plinss: I'm concerned that if we're changing behaviour at LC for level 3, no one will change behavior for years
19:29:55 <shane> fantasai: could just put a note in L3 that things are going to change in L4
19:30:25 <shane> Florian: but what L3 permits, L4 would forbid
19:30:33 <shane> fantasai: let's put it in L3 and mark it at risk
19:32:36 <shane> RESOLVED: pre-wrap preserves all spaces visibly and allows wrapping before and after every space (to go into level 3 and mark as at risk)
19:33:20 <shane> RESOLVED: add auto-pre-wrap* which does system-dependent behavior for multi-line text fields (to go into level 3 and mark as at risk) *TBB
19:34:42 <shane> RESOLVED: add pre-wrap-trim to level 4
19:40:25 <shane> RESOLVED: And The Name Shall Be pre-wrap-auto
19:40:42 <dbaron> (we almost concluded on "-pre-wrapauto" :-)
19:40:52 <shane> Florian: the ch unit doesn't mean the same thing in IE to everwhere else
19:40:56 <shane> Rossen: file a bug
19:41:29 <ChrisL> http://www.w3.org/TR/CSS2/
19:41:38 <shane> Topic: CSS2.2
19:41:42 <ChrisL> W3C Recommendation 07 June 2011, edited in place 17 December 2014 to point to new work
19:42:06 <gregwhitworth> gregwhitworth has joined #css
19:42:12 <shane> ChrisL: there's a big red scary box that says don't look at CSS2.1 anymore because we've got new work and it's better
19:42:18 <ChrisL> http://dev.w3.org/csswg/css2/cover.html
19:42:23 <shane> ... but that work has never been published. Have an ED but no FPWD.
19:42:34 <shane> dbaron: is there a diffed version around?
19:42:47 <shane> <a resounding maybe>
19:42:53 <ChrisL> http://dev.w3.org/csswg/css2/changes.html
19:43:11 <shane> ChrisL: yes there's a changes list. So does anyone object to publishing an FPWD?
19:43:23 <shane> smfr: how long-lived is this going to be? Does it contain anything that isn't in another module?
19:43:30 <shane> fantasai: tables. So it'll exist for a while.
19:43:38 <shane> ChrisL: plan was to migrate eventually but it won't happen soon.
19:43:57 <shane> fantasai: so we're publishing 2.2 as a way of updating the rec without updating the rec?
19:44:08 <shane> ChrisL: yeah. We already made this decision though - see the big red box
19:44:44 <shane> dbaron: needs to refer to itself as CSS2.2 more consistently
19:44:51 <shane> Bert_: I'll update.
19:44:57 <shane> dbaron: mostly just the abstract
19:44:59 <Florian> Florian has joined #css
19:45:20 <shane> SimonSapin_: can we make the scary red box appear on every page of 2.1?
19:45:28 <shane> plinss: yes we should do that
19:45:47 <shane> smfr: can we annotate this to point out the sections that have been superceded?
19:45:53 <shane> ??: tab has an action
19:46:01 <shane> ChrisL: yeah but should also be an issue on the spec
19:46:18 <shane> ... so is there agreement to do minimal cleanup then publish as FPWD?
19:46:30 <shane> RESOLVED: FPWD of CSS2.2
19:47:02 <SimonSapin_> https://github.com/servo/servo/wiki/Relevant-spec-links#css-2 maps CSS2 sections to CSS 3+ documents that replace them, to the best of my knowledge.
19:47:26 <shane> RESOLVED: republish CSS2.1 with more angry red boxes
19:48:04 <smfr> smfr has joined #css
19:52:23 <Florian> Florian has joined #css
20:08:05 <gregwhitworth> gregwhitworth has joined #css
20:10:00 <Florian> Florian has joined #css
20:12:20 <glazou> glazou has joined #css
20:12:21 <Florian> Florian has joined #css
20:15:40 <gregwhitworth> scribenick: gregwhitworth
20:15:50 <gregwhitworth> Topic: CSS Zoom
20:16:43 <Rossen> https://cdn.rawgit.com/atanassov/css-zoom/master/Overview.html
20:17:53 <Rossen> http://output.jsbin.com/quwoyovugu/1/
20:19:21 <andreyr> andreyr has joined #css
20:19:37 <gregwhitworth> http://output.jsbin.com/quwoyovugu/1/
20:19:38 <Florian> https://cdn.rawgit.com/atanassov/css-zoom/master/Overview.html
20:21:33 <gregwhitworth> ratan: Anyone not familiar with CSS Zoom
20:21:39 <gregwhitworth> florian: not the details
20:21:52 <gregwhitworth> ratan: I had to implement this for the third time, and I'm tired of this
20:22:01 <gregwhitworth> ratan: we made it closer to webkit's implementation
20:22:15 <gregwhitworth> ratan: I was able to check the original zoom prop to IE5.5
20:22:59 <gregwhitworth> ratan: The rest is history, so I don't have the background on why they implemented it
20:23:17 <gregwhitworth> ratan: All zoom does, is it is a factor that multiplies all of the length values in your computed style
20:23:34 <gregwhitworth> ratan: This happens during cascade
20:23:39 <gregwhitworth> ratan: it is pre-layout
20:24:09 <gregwhitworth> ratan: The way it affects layout is it becomes an aggrate multiplier
20:24:15 <gregwhitworth> ratan: [gives an example]
20:24:57 <gregwhitworth> ratan: The use, was to be able to have an element and then zoom it by %, and all properties would be multiplied by that
20:25:42 <gregwhitworth> ChrisL: So if it was abspos it would be shifted down
20:25:46 <gregwhitworth> ratan: yes
20:25:56 <gregwhitworth> ChrisL: Do you allow negative values?
20:25:58 <gregwhitworth> ratan: no
20:26:11 <gregwhitworth> glazou: Is it animatable?
20:26:25 <gregwhitworth> ratan: Haven't tested, but not sure if it is, it should be
20:26:40 <gregwhitworth> dbaron: What happens with 'em' units?
20:26:43 <gregwhitworth> ratan: Yep
20:27:16 <gregwhitworth> dbaron: [give a very long nested example]
20:27:28 <gregwhitworth> ratan: [begins building a fiddle to test]
20:28:35 <gregwhitworth> ratan: It is not inherited
20:28:38 <gregwhitworth> dbaron: oh
20:28:55 <dael> dael has joined #css
20:29:03 <gregwhitworth> ratan: it is accumulated
20:29:20 <gregwhitworth> ratan: What lengths and how do we apply those, obviously auto doesn't get scaled
20:29:58 <fantasai> so, computed values are multiplied (i.e. lengths amde absolute)
20:30:04 <gregwhitworth> ratan: One new behavior to be more interopable with webkit, % are not effected by zoom
20:30:18 <dbaron> ratan: percentages were affected in Trident
20:31:20 <fantasai> ratan: To get percentages to work right, you need to apply zoom factor only to the element with 'zoom' on it, not to any descendants
20:31:23 <gregwhitworth> florian: a background point, I have a usecase
20:32:05 <gregwhitworth> florian: you may think transforms are just fine, the spec doesn't say what to do with font rendering in a transform, and while it's getting better using zoom has consistent results
20:32:21 <gregwhitworth> smfr: that's a bug though
20:33:25 <gregwhitworth> ratan: When we were playing with this, we started looking at the various APIs that should be affected by zoom, what is returned
20:33:42 <gregwhitworth> ratan: There are two distinct behaviors
20:34:03 <gregwhitworth> ratan: they are their used value
20:34:47 <gregwhitworth> ratan: then there are ones that remove the zoom value as though you did layout without the zoom
20:35:53 <gregwhitworth> glazou: I'm a little upset that there are two different things
20:36:18 <gregwhitworth> ratan: I agree, I don't want to standardize on this nonsense, I actually want to kill this property
20:36:29 <gregwhitworth> ratan: I've been asking since IE8 for this
20:37:03 <dbaron> ratan: zoom:1 was used to trigger hasLayout
20:37:18 <fantasai> s/for this/to remove this/
20:37:18 <gregwhitworth> ratan: this was a leave behind from hasLayout
20:37:26 <dauwhe> dauwhe has joined #css
20:37:31 <dbaron> I still don't understand what causes the cumulative effect based on this description.
20:37:35 <gregwhitworth> ratan: there were a lot of sites that used this so I couldn't remove it
20:38:23 <gregwhitworth> ratan: What we have in MS Edge which aligns with Webkit, makes absolutely no sense
20:39:20 <fantasai> ratan: We as a group can decide to take this spec onits merits, and then start active work on it
20:39:25 <gregwhitworth> ratan: We as a group can decide to take this "spec" and start active work on it
20:40:39 <fantasai> ratan: Lot of mobile content that uses zoom:2 or zoom:1.5. Is kindof now a de-facto standard
20:40:53 <gregwhitworth> ratan: there is a lot of web content now for mobile using this
20:40:58 <fantasai> ratan: So either we should adopt this, or we should band together and kill it once and for all
20:41:35 <gregwhitworth> ratan: I propose we either work on this spec and fix these issues, or kill it all together and get a date to when we remove this from the web
20:42:49 <gregwhitworth> ratan: explains example http://output.jsbin.com/quwoyovugu/1/
20:45:05 <gregwhitworth> glazou: looking at that page and the results, you really need a way to get the original size and the scaled ones from the OM and not rely on your own computations, I want this property
20:45:14 <gregwhitworth> dbaron: this property makes no sense
20:45:32 <fantasai> s/this property/from the way it's been described, this property/
20:46:15 <gregwhitworth> ratan: I'm not here to praise it, but show what the current system is
20:46:33 <fantasai> smfr: Safari uses zoom for page zoom, zooms the whole page
20:46:41 <fantasai> smfr: We have 5 different ways of zooming, this is one of them
20:46:58 <gregwhitworth> smfr: We scale a certain way that uses zoom so this may be why you're seeing some of those issues
20:47:08 <gregwhitworth> ratan: Is this something that we want to see on the standards track
20:47:51 <gregwhitworth> glazou: It's used a lot by the web correct, are you going to annoy them by killing it
20:48:42 <gregwhitworth> shane: most people have zoom: 1 for IE8 support and to keep pinch zoom
20:49:13 <gregwhitworth> glazou: are you going to replace it with transforms?
20:49:36 <gregwhitworth> iank: we have data that shows there is only zoom:1 being used
20:49:52 <gregwhitworth> shane: they can use scale transform
20:50:01 <gregwhitworth> smfr: that affects layout though
20:50:42 <gregwhitworth> florian: if we are going to recommend people to use transforms instead of zoom, can we tighten up on font rendering
20:50:52 <gregwhitworth> smfr: let's not tangent on that, that's just a bug
20:51:20 <gregwhitworth> smfr: we could get transforms that focus on affecting layout
20:52:24 <gregwhitworth> plinss: I would like to see this removed from the standards, and not have it embedded in the web
20:53:15 <gregwhitworth> plinss: State your case Daniel, if you're upset
20:53:37 <gregwhitworth> glazou: let's take an accessiblity aspect, that you want to zoom in on the content not the nav bar
20:53:57 <fantasai> gregwhitworth^: We'd do what we're doing for visible control codes -- set a timetable, implement behind a flag, and coordinate the release
20:54:23 <gregwhitworth> plinss: no one is arguing having transforms that affect layout, we should evolve that instead of using this terrible property
20:54:44 <gregwhitworth> steveZ: I wrote a spec for it a long time ago, no one wanted it at the time
20:55:09 <gregwhitworth> plinss: there are a lot of use cases for this
20:56:15 <gregwhitworth> ratan: Question again, is this something that we should A) keep and standardize on the track or B) kill
20:56:21 <gregwhitworth> shane: I'll provide the fire
20:56:52 <gregwhitworth> smfr: I don't think we feel that people use zoom all that much, so I don't have a strong desire to see this specified
20:58:40 <gregwhitworth> ChrisL: Did you like the argument for using transforms?
20:58:59 <gregwhitworth> glazou: I think I can live with it, but don't like the name
20:59:37 <gregwhitworth> glazou: Do you officially ask us to start working on transforms that affect layout?
21:00:08 <gregwhitworth> ratan: I believe the use case is strong, I don't have a strong preference between zoom or transforms
21:00:42 <gregwhitworth> glazou: I don't disagree with that, but I want to know if we will be moving forward with layout transforms
21:01:33 <ChrisL> Léonie
21:01:35 <gregwhitworth> ACTION | glazou to ping Leonie regarding accessibility with the zoom
21:01:35 <trackbot> Error finding '|'. You can review and register nicknames at <http://www.w3.org/Style/CSS/Tracker/users>.
21:01:50 <gregwhitworth> ACTION: glazou to ping Leonie regarding accessibility with the zoom
21:01:51 <trackbot> Created ACTION-686 - Ping leonie regarding accessibility with the zoom [on Daniel Glazman - due 2015-05-25].
21:02:36 <ChrisL> action-686?
21:02:37 <trackbot> action-686 -- Daniel Glazman to Ping leonie regarding accessibility with the zoom -- due 2015-05-25 -- OPEN
21:02:37 <trackbot> http://www.w3.org/Style/CSS/Tracker/actions/686
21:03:17 <gregwhitworth> bcampbell: I would like to see some use cases to make a better accessiblity decision on this
21:03:46 <gregwhitworth> ratan: [gives example of illustration on random website for Bo]
21:04:48 <gregwhitworth> ratan: explains how it affects layout on said page
21:06:57 <gregwhitworth> ratan: It's suggested not to be used here: https://css-tricks.com/almanac/properties/z/zoom/
21:07:27 <gregwhitworth> bcampbell: any assistive technology would a need to zoom as well
21:07:46 <Florian> Florian has joined #css
21:08:01 <gregwhitworth> bcampbell: assume someone use zoom to zoom in on something small, as long as you can still zoom in the item via the UI
21:08:38 <gregwhitworth> iank: having UI hidden for accessibility doesn't help
21:09:01 <gregwhitworth> ianK: the limited stuff I've done, that stuff needs to be done in and by the browser, not by the author for discovery reasons
21:09:07 <gregwhitworth> bcampbell: I agree with that
21:09:27 <gregwhitworth> ratan: [shows same change using transform]
21:11:10 <gregwhitworth> ratan: Among implementers it does seem there is agreement to hide it from developers with a decent timeline for them to update their sites
21:12:03 <gregwhitworth> florian: transforms do a bad job of kerning, etc
21:12:36 <gregwhitworth> ratan: I don't know how bad kerning in transforms affects the decision on zoom
21:12:58 <gregwhitworth> florian: I'm not saying this is blocking, but it would be easier transistion for authors to solve that use case for using zoom
21:13:24 <gregwhitworth> florian: I'm not an expert on rending of fonts, but would like to see it addressed
21:13:35 <gregwhitworth> ratan: Any objections to deprecating zoom
21:13:56 <gregwhitworth> ChrisL: I object to deprecation, because I think you actually want to kill it
21:14:40 <gregwhitworth> florian: We should handle this like control characters
21:14:49 <gregwhitworth> Resolution: Resolved to kill it with fire
21:14:51 <ChrisL> deprecate means new content should not use it, but implementations must support it. That is not what we want here
21:15:13 <gregwhitworth> RESOLUTION: Kill it with fire
21:15:33 <gregwhitworth> SteveZ: We need to make this public
21:15:45 <gregwhitworth> RESOLUTION: Kill CSS ZOOM WITH FIRE
21:17:58 <gregwhitworth> smfr: I don't have much use case on uses other than 1
21:18:33 <dbaron> Florian: only specify or remove -- don't keep without a spec
21:18:57 <fantasai> RESOLVED: Rescind previous resolution
21:19:22 <ChrisL> RESOLVED: Rescind previous resolution
21:19:28 <ChrisL> recursion ftw!
21:19:59 <gregwhitworth> smfr: please provide some more use cases so we can make a better decision
21:20:30 <gregwhitworth> ratan: We started down this path, based on our implementation of webkit's implementation
21:20:54 <gregwhitworth> smfr: I can look at our bug database for why we did this
21:21:32 <gregwhitworth> ratan: well now this is becoming a spec
21:22:46 <fantasai> plinss: Basically, we don't have a resolution to "kill" anything unless we have a resolution to remove it from future releases of a browser. And we don't have that, because smfr is not convinced.
21:23:22 <gregwhitworth> dbaron: gives examples as to how standardizing for making better font rendering is complex
21:23:29 <fantasai> s/plinss:/plinss,/
21:25:17 <gregwhitworth> plinss: I would like to close on this subject
21:25:41 <gregwhitworth> iank: We can add a use counter into blink that keeps track of what is used
21:26:36 <gregwhitworth> ratan: So Simon are saying you would like to go the other way around and standardize it?
21:27:16 <gregwhitworth> smfr: I need data in order to provide whether we're willing to actually kill it or not
21:27:36 <gregwhitworth> plinss: Do you think this is data you can have by the F2F
21:27:43 <Florian> Florian has joined #css
21:29:26 <gregwhitworth> fantasai: I can say that I'm not for there being stuff in multiple browsers and not standardized
21:29:45 <gregwhitworth> plinss: We may not be able to standardize everything
21:29:59 <gregwhitworth> fantasai: that is not stuff that the web depends on
21:31:12 <gregwhitworth> florian: Does Servo need to implement this? If so we need to standardize this
21:31:23 <gregwhitworth> smfr: I think we should come back to this tomorrow
21:31:34 <gregwhitworth> ratan: Ok, I'll have more data tomorrow
21:32:13 <gregwhitworth> Topic: Scroll Snap Point Behaviors
21:33:33 <gregwhitworth> smfr: [explains snap points]
21:34:02 <gregwhitworth> smfr: if you set a coordinate, it will start snapping in it's scrollable ancestor
21:34:49 <gregwhitworth> smfr: I'm arguing for something like elements to come back
21:35:05 <gregwhitworth> smfr: the layout changes can make the element scrollable or not
21:35:34 <gregwhitworth> smfr: That can make surprising issues for authors when they thought an element should be snappable but changes cause the snap ancestor to change
21:36:29 <gregwhitworth> dbaron: are you saying that if something has overflow: auto is a scrolling container
21:36:42 <gregwhitworth> smfr: yes, I think that's undesirable as well
21:36:56 <gregwhitworth> smfr: I think there needs to be a prop on scrollable container
21:37:16 <gregwhitworth> smfr: This would allow it to capture scroll-snap-destiation
21:37:34 <gregwhitworth> smfr: what I'm asking is for the author to be explicity about what they want to snap to
21:38:04 <gregwhitworth> ratan: the scroller is the one providing offset positions in the scrollable area
21:38:18 <gregwhitworth> ratan: in that case there was no dependancy on content
21:38:38 <gregwhitworth> ratan: some of the first comments we heard was the argument for elements
21:39:02 <gregwhitworth> ratan: we didn't make too much of it, there would need to be a symetrical handshake between the element and the scrollable container
21:39:38 <gregwhitworth> ratan: it's analagous to how breaks work, and why we have different types of breaks
21:40:11 <gregwhitworth> ratan: I might have a use case where an element can cross a scoller and snap to a different scroller
21:40:17 <gregwhitworth> fantasia: that doesn't make any sense
21:40:22 <gregwhitworth> smfr: yeah I agree
21:40:34 <shane> s/fantasia/fantasai/
21:41:03 <gregwhitworth> fantasai: maybe if you want overflow hidden,you might need to jump scrollers
21:41:32 <gregwhitworth> fantasai: if we had overflow: clip we wouldn't need that
21:41:50 <gregwhitworth> ratan: the use case Simon presents, and I remove the overflow: scroll, now I'm screwed
21:42:02 <gregwhitworth> fantasai: right
21:42:21 <gregwhitworth> ratan: there needs to be some type of ident for there to be a correlation between the scroll container and the element
21:42:21 <fantasai> <fantasai insert explanation here>
21:42:40 <gregwhitworth> ratan: is this something that you've proposed
21:42:48 <gregwhitworth> smfr: possibly bringing elements back
21:42:58 <gregwhitworth> ratan: what happens when I remove it?
21:43:05 <gregwhitworth> smfr: that's fine, that seems like author intent
21:43:22 <gregwhitworth> fantasia: what is the usecase of repeat with scroll points?
21:43:44 <gregwhitworth> smfr: you have a lot of images that are the same size and you want it to snap at the same point
21:44:19 <gregwhitworth> fantasai: I think you're like to run into issues if you have to resize the images
21:44:50 <gregwhitworth> iank: the argument for repeat is if you are lazy loading the images you can use the repeat for this
21:45:17 <gregwhitworth> fantasai: can't you use the border of the box
21:45:21 <gregwhitworth> iank: not in all issues
21:46:03 <fantasai> s/issues/cases, what if still loading/
21:46:09 <fantasai> fantasai: In that case you have nothing to scroll anyway
21:46:20 <gregwhitworth> smfr: does anyone object to bringing back elements keyword
21:46:33 <dbaron> dbaron: Maybe scroll-snap-points-{x,y}'s Applies To line could change to "All Elements", so that the elements value can be used on things that aren't scroll containers and can thus capture scroll-snap-destination on descendants
21:47:00 <gregwhitworth> fantasai: I'm becoming less and less convinced of this
21:47:19 <fantasai> s/this/this -- not snap-points, I think that's good, but the design of this...
21:47:32 <gregwhitworth> ratan: another use case of this, if you want to read and simulate reading this, that's possible scroll repeate every 90%
21:47:38 <fantasai> fantasai^: e.g. nobody's given ma a good use case for repeat()
21:47:41 <dbaron> (I think people agreed with my suggestion about the Applies To.)
21:48:56 <gregwhitworth> fantasai: I remember scroll-snap-type should be on each point and not on the container itself
21:49:18 <fantasai> s/remember/remember someone raising an issue that/
21:49:18 <gregwhitworth> fantasai: that seems to make a lot of sense to me
21:49:32 <gregwhitworth> bcampbell: is it a mandatory stop?
21:49:46 <gregwhitworth> smfr: yes it is a mandatory snap
21:50:19 <fantasai> smfr: exact details up to UA, e.g. might want to account for speed at which you're swiping
21:50:19 <gregwhitworth> smfr: the spec is vague about the physics when interacting with the snap point
21:51:11 <gregwhitworth> bcampbell: I was thinking of this from a an accessible standpoint, that if your view is very small because you're so zoomed in that may be painful
21:51:35 <gregwhitworth> bcampbell: I'm not sure if that will be really bad though
21:51:52 <gregwhitworth> fantasai: I don't think it does good in a responsive way
21:52:46 <gregwhitworth> fantasai: at times the snap points aren't hit because of the expectation of the size of the screen based on the content, not all viewports are the same size
21:53:19 <gregwhitworth> fantasai: I think you should move away from the coordinate system, you should just be focused on the box, so that it won't matter the size of the screens
21:53:33 <gregwhitworth> smfr: that's a fair assessment
21:53:48 <gregwhitworth> florian: I think we should try to handle when the screen is smaller than the author expected
21:53:52 <leaverou> fantasai++
21:54:07 <gregwhitworth> smfr: Is Microsoft willing to do some spec ediitng?
21:54:09 <gregwhitworth> ratan: yes
21:54:11 <fantasai> s/just be focused on the box/think about alignment of a box to another box/
21:54:54 <leaverou> the way this is proposed makes it exceedingly difficult to use. Authors want snapping to boxes, they'll just end up using JS all the time to apply the snap points, which kinda defeats the purpose a bit.
21:54:57 <gregwhitworth> Bert_: if I set them on the outer element with repeat, will it align to a set snap point
21:55:23 <fantasai> fantasai^: For example, if I have a photo album, I might be like "of course I want a mandatory stop in the middle of each photo, you shouldn't land with a photo not centered in the middle of the screen". And that works great if the screen is wider than the photos. But if you have a smaller screen than a photo, it means you can't ever scroll to the parts of the photo that don't fit when it is centered.
21:55:26 <gregwhitworth> tabatkins: you would setup your layout however you want, and then you would apply the snap point to that box
21:57:22 <gregwhitworth> RESOLUTION: Bring back elements for snap points. Once it is specificed, it will be the box that traps all snap points
21:57:43 <smfr> smfr has joined #css
21:57:44 <fantasai> Meeting adjourned.
21:57:47 <Bert_> s/if I set them on the outer element with repeat,/if I set them on the outer element with repeat, and use 'break-before: <something>' on a child,/
22:06:25 <Florian> Florian has joined #css
22:11:28 <adenilson> adenilson has joined #css
22:51:34 <adenilson> adenilson has joined #css
23:29:41 <adenilson_> adenilson_ has joined #css
23:34:50 <adenilson> adenilson has joined #css
23:52:12 <adenilson> adenilson has joined #css