/irc-logs / w3c / #css / 2015-05-18 / end

Options:

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

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn