/irc-logs / w3c / #css / 2011-03-09 / end

Options:

# Session Start: Wed Mar 09 00:00:00 2011
# Session Ident: #css
# [00:07] <fantasai> Topic: Tokyo Workshop
# [00:08] <plinss_> http://wiki.csswg.org/planning/tokyo-workshop-2011
# [00:08] * Joins: howcome (howcome@63.245.220.224)
# [00:08] <fantasai> howcome: http://wiki.csswg.org/spec/css-multicol
# [00:09] <fantasai> Koji: There is a group in Japan supported by Japanese government trying to host forum or workshop
# [00:09] <fantasai> Koji: I'm the liaison to the CSSWG
# [00:10] <fantasai> My name is Jay [?]
# [00:10] <fantasai> Jay: I am going to make a presentation for the upcoming Tokyo workshop
# [00:10] <kojiishi> Jay Kishigami
# [00:11] <fantasai> http://wiki.csswg.org/planning/tokyo-workshop-2011
# [00:11] <fantasai> Jay: This is a good opportunity to discuss with Japanese publishers and other users of vertical writing.
# [00:11] <fantasai> Jay: But it's not only in Japan, but also in other countries.
# [00:11] <fantasai> Jay: Old Korean was written in vertically
# [00:11] <fantasai> Jay: And also Chinese write in vertical
# [00:12] <fantasai> Jay: Chinese, Japanese, and Mongolian all currently write in vertical
# [00:12] <kojiishi> Newspapers in Korea were in vertical up until 1996 or so
# [00:12] <fantasai> Jay: Maybe this community discuss the real requirements
# [00:12] <fantasai> Jay: Publishers and software vendors are very interested in ths workshop
# [00:13] <fantasai> Jay: Maybe some presentation from Asian layout implementers and device vendors
# [00:13] * Quits: johnjan (qw3birc@128.30.52.28) (Ping timeout)
# [00:13] <kojiishi> You can find Korean newspaper archives by date at http://dna.naver.com
# [00:13] <fantasai> Jay: authors
# [00:13] <fantasai> Jay: I just wanted to confirm dates for workshop
# [00:13] <fantasai> Jay: Before or after
# [00:13] <fantasai> Jay: I heard that fantasai cannot attend before, but others are better before
# [00:14] <fantasai> Jay: before is also good if items come up for WG discussion, can be discussed at F2F after
# [00:14] <fantasai> Jay: Is there any objections or comments on the date?
# [00:14] * Joins: bradk (bradk@63.245.220.224)
# [00:14] <fantasai> glazou: How many days do you plan to have the workshop?
# [00:14] <fantasai> Koji: I don't think we have finalized this yet
# [00:14] <fantasai> glazou: I think one day is probably enough
# [00:15] <fantasai> glazou: Since we are meeting W-F for CSSWG F2F
# [00:15] <fantasai> glazou: So Tuesday is best especially for people travelling from far away
# [00:16] <fantasai> Bert: How many people should come to the workshop?
# [00:17] * Quits: hober (ted@174.143.153.77) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [00:17] <fantasai> Koji: It depends if you want a small group, then we can have such a meeting, or if you want to have a bigger meeting we can do that.
# [00:17] <fantasai> glazou: We can have both.
# [00:17] <fantasai> glazou: Most of the WG will be present.
# [00:17] * Joins: hober (ted@63.245.220.224)
# [00:17] <fantasai> glazou: We can have panels with questions where WG interact with audience, split into tables for lunch
# [00:17] <fantasai> glazou: The only problem in smaller groups is your last line, the language
# [00:18] <fantasai> Jay: Atm we have two solutions for the language.
# [00:18] <fantasai> Jay: one is to have basic language be English
# [00:18] <fantasai> Jay: But for some people they're not comfortable to speak English
# [00:18] <fantasai> Jay: So we can have simultaneous language
# [00:18] <fantasai> glazou: Japanese is probably best for main language, but we need English :)
# [00:19] <fantasai> Jay: So proposal is May 31st Tuesday from 9 or 10am through the evening, with lunch session
# [00:19] <fantasai> Jay: We can have tables with discussions at the tables
# [00:19] <fantasai> glazou: That's doable if we have one person per table able to translate between English and japanese
# [00:19] <fantasai> glazou: That's the only trouble we have
# [00:20] <fantasai> Peter: One other thought about the dates is that we could push our meeting back by a day or shorten it by a day
# [00:20] <fantasai> jdaggett: I think we definitely shouldn't shorten our meeting
# [00:21] <fantasai> plinss: We could also push back our meeting by a day, T-S
# [00:22] <fantasai> fantasai and Steve can't make Tuesday
# [00:22] <fantasai> ?: Tab, can you host on Saturday?
# [00:23] <fantasai> Tab: difficult, since Google employees won't be there
# [00:23] <fantasai> jdaggett: We could host on Saturday
# [00:23] <Bert> (So how big will the ftf be, again 25, or less?)
# [00:25] <TabAtkins_> TabAtkins_:
# [00:25] <TabAtkins_> ScribeNick: TabAtkins_
# [00:25] <TabAtkins_> jdaggett: I'm concerned that if it's only publishing/gov people, we (CSS) aren't really capturing the main audience for this, which is people designing for the web.
# [00:26] <TabAtkins_> jdaggett: It's good to consider the use-cases the publishers have, but that tends to be a relaitvely limited set of uses compared to everyone designing webpages.
# [00:26] <TabAtkins_> Jay: The participants here may be from the publishing area, but will include the web designers.
# [00:26] <mollydotcom> i'd like to jump in on that too
# [00:26] <mollydotcom> if I may?
# [00:27] <TabAtkins_> Jay: Maybe the signage designers would be able to offer useful feedback as well
# [00:27] * TabAtkins_ go ahead, Molly.
# [00:27] <mollydotcom> John's concerns are very real, and of course this is an ongoing issue
# [00:27] <TabAtkins_> jdaggett: We're designing CSS here, and the focus is on designing CSS, not necessarily on how Japanese test works.
# [00:27] <mollydotcom> as the person who acts as developer liaisons, we have to engage designers more
# [00:28] <mollydotcom> but Japanese text is part of that too - designers designing Japanese sites need the technology
# [00:28] <TabAtkins_> Jay: The goal of this workshop is understanding how to handle vertical text.
# [00:28] <TabAtkins_> [reading Molly's comments]
# [00:28] <mollydotcom> I'm just repeating my old mantra: Engage designers somehow
# [00:28] <TabAtkins_> jdaggett: It would be useful to have a workshop on CSS and how Japanese fits into that context, rather than how publishing works in Japan.
# [00:29] <mollydotcom> It's very difficult, not our fault, but it's necessary
# [00:29] <TabAtkins_> Koji: I think we tried to make the participant list take into account input from the WG, including you.
# [00:29] <mollydotcom> +1 That's the point, is it not? John. At least as I see it
# [00:30] <TabAtkins_> jdaggett: I think it seems that this is trying to be everything to everyone, and it needs some clear themes. What are the problems we're trying to discuss.
# [00:30] <TabAtkins_> jdaggett: My concern is that people are just going to get up and talk about things that they think are important.
# [00:30] * mollydotcom says isn't that what happens anyway?
# [00:30] <TabAtkins_> Markus: So you want to frame it as "How can we help", action items that the WG can take away to work on.
# [00:30] <TabAtkins_> jdaggett: Right; we need to think about it in terms of CSS and the web, not just about the difficulties of publishing.
# [00:31] <TabAtkins_> plinss_: I think CSS is becoming more and more important in publishing.
# [00:31] <TabAtkins_> jdaggett: Right, but we need to ensure that it's both about the web and publishing.
# [00:32] <fantasai> Markus: If you explain what is the delta between what you see on the Web and what you would want to see
# [00:32] <TabAtkins_> Markus: I think it's easiest to phrase things as a delta between what currently exists and what is lacking that is needed.
# [00:32] <mollydotcom> I agree - but any focus on publishing and not the Web pisses off a lot of developers and designers. Who is using CSS more today?
# [00:32] <TabAtkins_> Jay: We want to intentionally produce just such a productive and tangible result from the discussions.
# [00:32] <fantasai> Markus: Every time you have a speaker, elicit a summary so we can walk away with an understanding of what we need to work on.
# [00:33] <TabAtkins_> Jay: Though, perhaps the older publishing people won't fully grasp what is "CSS".
# [00:33] <TabAtkins_> Jay: So some interpretation may be required.
# [00:33] * Joins: myakura (myakura@123.224.162.182)
# [00:33] <mollydotcom> it sounds unfocused to me
# [00:33] <fantasai> Steve: Are you looking at this as a meeting as a way for CSSWG to present what we're doing and get comments and questions back,
# [00:33] <mollydotcom> what is the end goal?
# [00:34] <mollydotcom> in one sentence
# [00:34] <fantasai> Steve: Or are we sitting through presentations where japanese people explain what they need?
# [00:34] <fantasai> Steve: I don't have a particular preference, but from the CSS viewpoint it seems to make more sene for us to present what we are doing, since that's what we are expert in
# [00:34] <fantasai> Steve: But it would also be relevant to hear what other people think we /should/ be doing
# [00:35] <hyatt> "what they need" is already described really well by the amazing http://www.w3.org/TR/jlreq/ document
# [00:35] * Quits: myakura (myakura@123.224.162.182) (Client exited)
# [00:35] <fantasai> Koji: Is there anyone who can give an overview of what's going on in CSSWG?
# [00:35] <mollydotcom> How about focus sessions on each then? "Hear from the CSS WG" and "Hear from the attendees" which could be very compelling if well described
# [00:35] <fantasai> fantasai: you? :)
# [00:35] <fantasai> tab reads out comments from IRC
# [00:37] <Bert> fantasai: Could hve two days, one in Japanese, one with the WG in English
# [00:37] * Zakim excuses himself; his presence no longer seems to be needed
# [00:37] * Parts: Zakim (rrs-bridgg@128.30.52.169)
# [00:38] <glazou> hyatt: yes that document is amazing
# [00:38] <hyatt> glazou: that's really what we've been using in webkit to guide our implementation
# [00:38] <fantasai> fantasai: Japanese can use the first day to interact with and learn from each other, and organize what they want to present to us, ask us, request from us
# [00:38] <glazou> hyatt: how suprising :-)
# [00:39] <fantasai> Koji: Could have first day Japanese learning, second day presenting to WG
# [00:40] <fantasai> Jay: So could have second day be workshop, with English support, first day be preparation for/by/in Japanese
# [00:40] <fantasai> Jay reads out name of government org that will be co-organizing with W3C
# [00:41] <fantasai> glazou: When do you think the organizing committee is going to release a schedule for the day?
# [00:41] <fantasai> Jay: Need to coordinate with Japanese government and W3C
# [00:41] <fantasai> Koji: SVGWG is also interested in participating in this forum
# [00:42] <fantasai> Steve: They have their F2F the next week
# [00:42] <fantasai> Steve: I think Chris favored having the workshop beforehand as well
# [00:43] <fantasai> Steve: He also talked about having a joint SVG-CSS meeting
# [00:43] <fantasai> Koji: Should be able to get back to everyone within 2-3 weeks
# [00:44] <fantasai> Steve: Asap, so people can get airline tickets
# [00:44] * Quits: hyatt (hyatt@98.200.13.42) (Quit: hyatt)
# [00:45] <fantasai> RESOLVED: Tokyo workshop tentatively scheduled 31st and 1st, 31st as Japanese-only, 1st also in English with CSSWG; CSSWG F2F moved to Thursday-Saturday June 2-4
# [00:45] <fantasai> Topic: CSS3 Line Grid
# [00:45] <fantasai> plinss: anything to discuss here?
# [00:46] <fantasai> John: I don't think we should be discussing things where we don't have anything written down. I think that should be a prereq for discussing at an F2F
# [00:46] <fantasai> jdaggett: I'm a little confused why we're talking about this as a separate spec
# [00:46] <fantasai> jdaggett: This was in a previous CSS3 Text draft
# [00:46] <fantasai> jdaggett: I think it's peculiar to be creating modules here
# [00:47] * Joins: philcupp (pcupp@63.245.220.224)
# [00:47] <fantasai> fantasai recaps history of CSS3 Text
# [00:47] <fantasai> jdaggett: Given everything we have on our plate here, I think it's a little premature to work on a spec here
# [00:47] <fantasai> jdaggett: Were there implementers on the CSSWG who wanted to implement this?
# [00:48] <fantasai> Koji: Apple
# [00:48] <fantasai> fantasai: We need 2 implementers to take on a module
# [00:48] * Joins: arno (arno@192.150.10.200)
# [00:48] <fantasai> Koji: CSS3 Text was born 12-13 yrs ago as International Text Layout spec from stuff at Microsoft
# [00:48] * Joins: szilles (chatzilla@63.245.220.224)
# [00:49] <fantasai> Koji: The Japanese portion of that spec was mostly written by me, brought from MS Word features
# [00:49] <fantasai> Koji: Line grid one of the features Word implemented in 97 and tried to bring into IE
# [00:49] <fantasai> Koji: Nobody has been showing much interest since IE
# [00:49] <fantasai> Koji: Not sure what happend after, but it was decided to split up
# [00:49] <fantasai> jdaggett: What needs to happen first is Apple need to say they're interested in this
# [00:50] <fantasai> jdaggett: And then we can assess whether this is something we want to take on
# [00:50] <fantasai> jdaggett: We have a very full charter
# [00:50] <fantasai> jdaggett: Seems like something that should be starting after we finish CSS3 Text and CSS3 Writing Modes
# [00:50] <fantasai> jdaggett: Talking about it now seems premature
# [00:50] <fantasai> Alex: We started that set of specs in IE6 time to reflect what we had in IE and what we wanted to have in IE
# [00:51] <fantasai> Alex: line-grid itself is largely driven by Japanese publishing but it is also line alignment that typography, in particular multicol, that is used in desktop publishing
# [00:51] <fantasai> Alex: We are glad that somebody else is interested
# [00:51] <fantasai> Alex: We had a hard time last 12 years in promoting this
# [00:51] <fantasai> Alex: We should create a spec that a new implementer like us can agree on
# [00:52] <fantasai> Alex: Not sure what we do if Apple goes to implement line grid without a spec
# [00:52] <fantasai> jdaggett: If both Apple and Microsoft are interested, then we should have them write down what they're interested in implementing
# [00:52] <fantasai> jdaggett: Let's have a written proposal that describes what they're interested in
# [00:53] <fantasai> Simon: for the record, we weren't aware of this, so we need to talk with hyatt and find out more
# [00:53] <fantasai> Koji: ...
# [00:53] <fantasai> jdaggett: So we can talk about it then
# [00:53] <fantasai> Alex: What do you propose for start making changes to the spec
# [00:53] <fantasai> jdaggett: first, I think we should have a written proposal of what we want to take on,
# [00:54] <fantasai> jdaggett: second, group reviews this and decides whether this is something we want to take on
# [00:54] <fantasai> jdaggett: It's largely a matterof editor's time, but also discussions at F2F and telecons, so impacts groups time
# [00:54] <Bert> s/Koji: .../Koji: I prioritice writing mode and text higher, but expect to get to line grid in a few months./
# [00:54] <fantasai> Koji: It's not a new spec, it already exists in 2003 CR
# [00:55] <fantasai> jdaggett: So point to the spec sections
# [00:55] <fantasai> http://www.w3.org/TR/2003/CR-css3-text-20030514/#document-grid
# [00:55] <fantasai> jdaggett: Do you want all of this?
# [00:56] <fantasai> jdaggett: What is the exact set of features from that spec that you are talking about?
# [00:56] <fantasai> Koji: My approach was to write an editor's draft and ask people for review
# [00:57] <fantasai> jdaggett: Usually people write a rough draft of what they want
# [00:57] <fantasai> Steve: I think there are two points going around here.
# [00:58] <fantasai> Steve: One is, we get regularly beat up from W3CM about having too many irons in the fire and not finishing anything
# [00:58] <fantasai> Steve: We did a priority review at the last charter, and concluded this was not at all a priority
# [00:58] <fantasai> Steve: Since then priorities have changed, especially due to EPUB
# [00:58] <fantasai> Steve: So one issue is what are we giving up to work on this
# [00:59] <fantasai> Steve: Second is, if we are going to work on this, is how to go about doing it.
# [00:59] <fantasai> Steve: Adobe and Microsoft both put proposals on the table to discuss
# [00:59] <fantasai> Arron: You mean a proposal other than the current spec?
# [00:59] <fantasai> Steve: Could just be updated copy of old spec
# [01:00] <fantasai> jdaggett: I also think along with the proposal, an indication of what set of features implementers are interested in implementing from that proposal, is also important.
# [01:00] <fantasai> jdaggett: My concern is that you and Elika are editors of the CSS3 Text spec
# [01:00] <fantasai> jdaggett: And I don't see that as being stable, there's a lot of work remaining there.
# [01:01] <fantasai> jdaggett: My concern is that we shouldn't be talking about priorities until we get through whatever has to happen for that
# [01:01] <fantasai> Koji: So when the time arrives I should copy from 2003 CR and put on my own site?
# [01:02] <fantasai> jdaggett: Just put it on dev.w3.org
# [01:02] <fantasai> fantasai: I think that was all he was asking for.
# [01:02] <fantasai> Bert: Putting it in the charter is a separate matter, but dev.w3.org is available.
# [01:02] <fantasai> Topic: Compositing
# [01:03] <fantasai> plinss: SVGWG has published Last Call of their Compositing spec.
# [01:03] <fantasai> s/has/will/
# [01:03] <fantasai> s/ed//
# [01:03] <fantasai> plinss: They plan to set a 4-week LC period, until april 7
# [01:03] <fantasai> plinss: They are asking us if that's sufficient time
# [01:03] <plinss_> http://dev.w3.org/SVG/modules/compositing/master/
# [01:04] <fantasai> plinss: Ok, nobody seems to be asking for more time.
# [01:05] <fantasai> plinss: That's most of what we preplanned out for today. Also have the elephant in the room of CSS2.1 issues
# [01:05] <fantasai> plinss: Daniel and I suggest tackling those
# [01:05] * Bert would like to see Daniel and Peter tackle an elephant. :-)
# [01:06] * mollydotcom laughs at that visual
# [01:09] * Joins: myakura (d2e8220d@64.62.228.82)
# [01:23] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Ping timeout)
# [01:23] <fantasai> Topic: CSS2.1
# [01:24] <fantasai> plinss: Plan for rest of day is to work on CSS2.1 issues.
# [01:24] <fantasai> plinss: If people want to leave, feel free to leave. We are not working on anything else today.
# [01:24] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
# [01:24] <fantasai> plinss: One quick thing to discuss, over lunch we talked about keeping the editorial issues we don't want to deal with now
# [01:25] <fantasai> plinss: but that we think are valid
# [01:25] <fantasai> plinss: Several options are making a CSS2.1.1 or CSS2.1
# [01:25] <fantasai> plinss: or slip them in between PR and REC
# [01:26] <fantasai> plinss: Advantage is that we can tell people that we accept their issue just not right now and it will show up in a future revision
# [01:26] <fantasai> Arron: My concern with the last one is that we accidentally introduce a substantive change.
# [01:26] <fantasai> plinss: Other thoughts?
# [01:27] <mollydotcom> this is to ensure that we can shelf 2.1 or does it still remain in limbo
# [01:27] * Joins: sgalineau (sylvaing@63.245.220.224)
# [01:27] * Joins: johnjan (qw3birc@128.30.52.28)
# [01:27] <fantasai> dbaron: So, it's somewhat dangerous from an editing perspective to branch if you're going to make substantial changes to both halves of a branch
# [01:27] <dbaron> ...and then want to merge them
# [01:28] <fantasai> fantasai: I don't think the merge is going to be that difficult, because CSS2.1 has short lines and we aren't making that many changes at this point.
# [01:29] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
# [01:29] <fantasai> plinss: So what are we going to do?
# [01:29] <fantasai> fantasai: I don't care, as long as I have some place to put the edits so I never have to look at these emails again.
# [01:29] <mollydotcom> hahaha
# [01:31] <plinss_> http://wiki.csswg.org/spec/css2.1/anton-lc-2010
# [01:31] <fantasai> dbaron: Should consider which branch is going to get served off the server, if you're going to branch
# [01:31] <mollydotcom> it's been suggested from the design community to add an intermediary css2.1.1 or somesuch. I don't know if that helps or hurts us, but that's the general sentiment
# [01:32] * Joins: markus (mmielke@63.245.220.224)
# [01:32] <fantasai> plinss: I'm looking for resolution to accept the recommendations on the wiki page where Arron and fantasai analyzed Anton's comments.
# [01:32] * Quits: mihara (mihara@63.245.220.224) (Quit: Leaving)
# [01:33] <fantasai> arron: Stuff we didn't have a no-change conclusion on has been filed in the wiki
# [01:33] <fantasai> as issues
# [01:33] * Parts: mollydotcom (mollyh@173.164.174.193)
# [01:35] <johnjan> looks like IRC may not be working.
# [01:36] <fantasai> fantasai reviews the wiki doc
# [01:37] <johnjan> ah... it is working. it's just very very quiet there.
# [01:42] <glazou> johnjan: you're at the airport ?
# [01:42] <johnjan> yeah
# [01:43] <glazou> san jose ?
# [01:43] <johnjan> yes
# [01:43] <glazou> have a good trip !
# [01:43] <johnjan> having a beer while the CSSWG discusses 2.1!
# [01:43] <glazou> tss tss :-)
# [01:47] <fantasai> CL3 could add a more explicit reference to other section, but there's a link already
# [01:54] <dbaron> http://dbaron.org/css/test/2011/css21-issue-280 is a testcase for issue 280
# [01:58] <fantasai> fantasai: I basically have three levels of suggestion: 1. Change now 2. Change in errata 3. Editorial for some undetermined future revision. (and of course 0. No change)
# [01:59] <TabAtkins_> plinss_: First open issue is 179.
# [01:59] <TabAtkins_> dbaron: Has an action to Bert.
# [01:59] <TabAtkins_> dbaron: So what do we need to do?
# [01:59] <TabAtkins_> plinss_: Do we need to make this change?
# [01:59] <TabAtkins_> fantasai: Yes, it's currently wrong. It's an example, but it's wrong.
# [02:00] <TabAtkins_> RESOLVED: Accept the edit for 179.
# [02:00] <TabAtkins_> plinss_: Issue 225
# [02:01] * Quits: hober (ted@63.245.220.224) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [02:01] <TabAtkins_> dbaron: I don't understand "the top of the parent box" in this proposal.
# [02:02] <TabAtkins_> dbaron: In the text he's quoting, the conditions for top and bottom are different, and I think they need to be.
# [02:02] <TabAtkins_> arronei: I think the current text is fine, personally.
# [02:03] <TabAtkins_> dbaron: This proposal looks like a substantive change.
# [02:03] * Joins: stearns_ (stearns@192.150.22.5)
# [02:04] <TabAtkins_> dbaron: I don't understand why this is saying "top of the parent box" instead of using the same language for top and bottom in each list item.
# [02:05] <TabAtkins_> dbaron: What's the parent box?
# [02:05] <TabAtkins_> arronei: It should be the top border edge of ???
# [02:05] <TabAtkins_> dbaron: If it has a previous sibling, the top of the parent isn't what you want.
# [02:05] * Quits: stearns (stearns@192.150.22.5) (Ping timeout)
# [02:05] * stearns_ is now known as stearns
# [02:05] <TabAtkins_> dbaron: And a lot of this section is dealing with situations where the first child may be outside of the element's own height, because margins are collapsing through that first child.
# [02:07] <TabAtkins_> dbaron: Anton is correct that the current spec is wrong.
# [02:08] <TabAtkins_> dbaron: It was written at a time when we assumed there was no in-flow content that would inhibit margin collapsing ??? [maybe never mind, the text may be right]
# [02:09] * Quits: Jay (jay@63.245.220.224) (Connection reset by peer)
# [02:09] <TabAtkins_> dbaron: Never mind, I don't see anything that needs changing here. Certainly don't see what's wrong with the second sentence.
# [02:09] <TabAtkins_> plinss_: So, do we think the spec is fine?
# [02:10] <TabAtkins_> dbaron: Yeah, I think so.
# [02:10] <TabAtkins_> RESOLVED: No change for issue 225.
# [02:10] <TabAtkins_> plinss_: Issue 226
# [02:10] <TabAtkins_> fantasai: I need to write text.
# [02:11] <TabAtkins_> plinss_: Do we agree that this is a necessary change?
# [02:11] <TabAtkins_> fantasai: Don't remember.
# [02:11] <johnjan> http://wiki.csswg.org/spec/css2.1#issue-226
# [02:11] <TabAtkins_> arronei: let's look at it and see.
# [02:12] * Quits: homata__ (homata@58.158.182.50) (Ping timeout)
# [02:13] * Joins: Jay (jay@63.245.220.224)
# [02:14] <TabAtkins_> RESOLVED: 226 is editorial, deferred to CSS3. No change to CSS2.
# [02:14] <TabAtkins_> plinss_: 229.
# [02:14] <TabAtkins_> dbaron: This is a case where no impls match the spec, I think.
# [02:15] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20magenta%22%3E%0A%20%20%3Cdiv%20style%3D%27float%3A%20left%3B%20border%3A%20solid%20green%3B%20%27%3EA%3C%2Fdiv%3E%20aaaa%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20blue%3B%20margin%3A%20-2em%22%3E%0A%20%20%3Civ%20style%3D%22float%3A%20left%3B%20border%3A%20solid%20yellow%3B%20%22%3EB%3C%2Fdiv%3E%20bbbbbbb%0A%3C%2Fdiv%3E
# [02:15] <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20magenta%22%3E%0A%20%20%3Cdiv%20style%3D%27float%3A%20left%3B%20border%3A%20solid%20green%3B%20%27%3EA%3C%2Fdiv%3E%20aaaa%0A%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%20blue%3B%20margin%3A%20-2em%22%3E%0A%20%20%3Civ%20style%3D%22float%3A%20left%3B%20border%3A%20solid%20yellow%3B%20%22%3EB%3C%2Fdiv%3E%20bbbbbbb%0A%3C%2Fdiv%3E
# [02:17] <TabAtkins_> fantasai: The "aaa"s don't move to make room for the "bbbb".
# [02:17] <johnjan> if the tests are right, looks like everyone is interop, but no one is compliant.
# [02:17] <TabAtkins_> dbaron: If there's a float between two blocks, does the placeholder get wrapped?
# [02:18] <TabAtkins_> fantasai: No, placeholders only get created for tables.
# [02:18] <TabAtkins_> dbaron: But I thought we needed it for containing block?
# [02:18] <TabAtkins_> dbaron: The reason the spec is wrong is the wording we used to work around the fact that the float's placeholder isn't in a block.
# [02:19] <fantasai> fantasai: ????
# [02:20] <TabAtkins_> dbaron: There is some wording about "the float can't be below the bottom of the previous block"
# [02:20] <TabAtkins_> dbaron: Either the person who wrote that assumed that the previous block is clearly the lowest block, or they assumed that you should also check all the previous blocks, but no implementor picked up on that.
# [02:21] <TabAtkins_> dbaron: In some ways the spec is maybe better, but we have no implementations of that, because nobody ever pointed out this issue before #229.
# [02:21] <TabAtkins_> Bert: I wrote those rules 15 years ago, and I definitely didn't want floats to move up when their containing block moved up.
# [02:21] <TabAtkins_> Bert: The intention was definitely to check for the lowest thing of *everything* that came before.
# [02:22] <TabAtkins_> Bert: I imagined keeping a running track of what is currently the lowest element.
# [02:22] <TabAtkins_> fantasai: I think most impls do that, but also move it up if you have a negative margin.
# [02:22] <TabAtkins_> dbaron: We do the same thing for floats, we just don't do it for blocks. We track the to pof the last float.
# [02:24] <TabAtkins_> dbaron: In rule 4, we already have this condition...
# [02:24] <TabAtkins_> dbaron: It helps, because we already have the hypothetical that we need.
# [02:26] <TabAtkins_> dbaron: [something about rule 5, strike the "block or"]
# [02:26] <TabAtkins_> dbaron: And then in rule 6, you'd only count the linebox containing the float, and not lineboxes earlier than that one.
# [02:27] <TabAtkins_> dbaron: [something about negative margins]
# [02:28] <TabAtkins_> [unminuted discussion]
# [02:28] <TabAtkins_> plinss_: I think at this point we should lean toward undefined.
# [02:28] <TabAtkins_> fantasai: We can't undefine the whole floats section!
# [02:28] <TabAtkins_> fantasai: And fixing this is probably about as much effort as carefully undefining just the behavior we're talking about.
# [02:29] <TabAtkins_> arronei: I'm up for a note. We have no testcases.
# [02:31] <TabAtkins_> fantasai: What are you going to do? Report that we resolved this by noting that the spec is in error?
# [02:31] <TabAtkins_> plinss_: I like David's suggestion - the spec is correct. In the future we'll create a testcase to identify impl issues, and address them at that time (possibly with spec issues).
# [02:32] * fantasai suspects there might be a web compat behavior
# [02:32] <TabAtkins_> plinss_: If we can do this by simply saying the interaction with negative margins is undefined, that's fine too.
# [02:32] <TabAtkins_> dbaron: I think that is making too much undefined.
# [02:33] * Quits: smfr (smfr@63.245.220.224) (Quit: smfr)
# [02:35] <TabAtkins_> dbaron: We deifnitely want to limit it to negative vertical marings in the containing block prior to that float.
# [02:35] <dbaron> s/marings/margins/
# [02:35] <TabAtkins_> plinss_: Objections?
# [02:35] <fantasai> If, within the BFC, there is a negative margin such that it moves the float up from the position it would be at were the negative margin(s) set to zero,
# [02:36] <TabAtkins_> arronei: I'm concerned there may be more interactions, but I'm okay.
# [02:36] <fantasai> the position of the float is undefined
# [02:36] <johnjan> agree with fantasai's proposal.
# [02:36] <johnjan> that seems to describe interop behavior.
# [02:37] <fantasai> If, within the BFC, there is a negative margin such that the floats position is above the position it would be at were all such negative margins set to zero, the position of hte float is undefined.
# [02:37] <TabAtkins_> RESOLVED: Accept fantasai's edits for issue 229.
# [02:37] <TabAtkins_> plinss_: Issue 239.
# [02:38] <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Oct/0750.html
# [02:39] <fantasai> add "in-flow vertical" to margin above
# [02:39] <dbaron> was 239 the right number? Issue is currently marked closed.
# [02:39] <dbaron> johnjan, ^
# [02:40] <TabAtkins_> plinss_: Issue 242.
# [02:40] <dbaron> re-resolved to accept proposal for 241 in case we didn't accept it already
# [02:41] <johnjan> checking my list
# [02:42] <johnjan> 239 is the correct issue. I didn't think we closed on Body propogating to HTML based on Alex's comments.
# [02:42] <johnjan> if we did, then my mistake.
# [02:42] * Joins: Kazutaka0 (yamamoto_k@63.245.220.224)
# [02:44] * Quits: dsinger (dsinger@17.72.146.85) (Ping timeout)
# [02:46] * Quits: tantek (tantek@63.245.220.240) (Quit: tantek)
# [02:47] <TabAtkins_> RESOLVED: Defer 273 to future version, editorial.
# [02:47] <TabAtkins_> plinss_: issue 274.
# [02:47] <TabAtkins_> fantasai: 274 is related to the earlier one we discussed.
# [02:48] <TabAtkins_> plinss_: Did we undefine this one implicitly?
# [02:48] <TabAtkins_> fantasai: No.
# [02:48] <TabAtkins_> dbaron: [something about lineboxes next to floats]
# [02:50] <TabAtkins_> dbaron: Lineboxes are not shortened by a float that occurs after them.
# [02:50] <dbaron> which we could note can only occur under the undefined behavior we just added
# [02:51] <TabAtkins_> RESOLVED: Accept dbaron's edit for 274.
# [02:51] <TabAtkins_> plinss_: Issue 274.
# [02:51] <TabAtkins_> plinss_: Issue 275
# [02:51] * Quits: markus (mmielke@63.245.220.224) (Quit: markus)
# [02:52] <TabAtkins_> dbaron: This is saying that if you're in a 500px wide block, and you have a 490px wide float, and you're trying to place a word next to that float, which is more than 10px wide.
# [02:52] * Quits: jdaggett (jdaggett@63.245.220.224) (Quit: jdaggett)
# [02:52] <TabAtkins_> dbaron: It doesn't fit, so you push that linebox down until it's past the float, or there aren't any floats next to you and you just have an overflow.
# [02:52] * Quits: myakura (d2e8220d@64.62.228.82) (Client exited)
# [02:52] <fantasai> Bert: But do you move the line box, or do you move the word?
# [02:53] <fantasai> Bert: and have empty line boxes all the way down?
# [02:53] <TabAtkins_> dbaron: i remember discussing this in a meeting when tantek was on macIE.
# [02:53] <TabAtkins_> dbaron: I think this was an intentional decision (to allow the gap to be a non-integral multiple of line-height)
# [02:53] <TabAtkins_> dbaron: So the issue is that 9.4.2 says that lineboxes are stacked with no vertical separation.
# [02:54] <TabAtkins_> dbaron: I'll say that 9.5 overrides 9.4.2 and we can just live with it.
# [02:54] <TabAtkins_> dbaron: Or we can say in 9.4.2 "except as described in 9.5".
# [02:55] <TabAtkins_> Bert: Kind of ugly, because it can mess up the vertical rhythm.
# [02:55] <TabAtkins_> TabAtkins_: Many things can do that; we shouldn't worry about that until we have a spec that can solve it properly.
# [02:55] <TabAtkins_> plinss_: So what's the resolution? Fix, or leave spec as it is?
# [02:56] * Quits: Kazutaka0 (yamamoto_k@63.245.220.224) (Quit: CHOCOA)
# [02:56] <TabAtkins_> plinss_: There are many places where one piece of prose overrides another. Let's just leave it.
# [02:56] <johnjan> leave as is.
# [02:57] <johnjan> note that 9.5 overrides 9.4.2
# [02:57] <johnjan> on the list
# [02:57] <TabAtkins_> RESOLVED: No change for issue 275.
# [02:58] * Quits: stearns (stearns@192.150.22.5) (Quit: stearns)
# [02:59] <dbaron> Bert: "(except as specified elsewhere)"
# [02:59] <dbaron> RESOLVED: accept Bert's proposal for 275.
# [03:00] <TabAtkins_> plinss_: Issue 276
# [03:00] <TabAtkins_> dbaron: I'm okay with the proposal.
# [03:00] <TabAtkins_> fantasai: It's in CSS Selectors, though it's not better defined there.
# [03:01] <johnjan> that's OK, selectors has time to get it right.
# [03:01] <TabAtkins_> fantasai: I think we should add a note that the precise behavior is undefined, and may be defined in a future version.
# [03:01] <dbaron> johnjan, not really, since it's ahead of 2.1...
# [03:01] <johnjan> good point...
# [03:01] <TabAtkins_> RESOLVED: Note that :first-letter, :first-line are undefined, to resolve issue 276.
# [03:02] <TabAtkins_> plinss_: Issue 277.
# [03:02] <TabAtkins_> arronei: This is a terminology issue. We should get it right, but it's editorial.
# [03:03] <TabAtkins_> dbaron: Though it affects DOM APIs...
# [03:03] <dbaron> I was just correcting "may confuse conversations" to "may or may have confused conversations or DOM APIs"
# [03:03] <dbaron> since CSSOM misuses declaration
# [03:08] <bradk> A rule set (also called "rule") consists of a selector followed by a set of rules (also called "declaration blocks").
# [03:08] <TabAtkins_> RESOLVED: Defer issue 276 for errata.
# [03:09] <johnjan> 277, right?
# [03:09] * Joins: tantek (tantek@66.87.7.91)
# [03:09] <plinss_> s/276/277/
# [03:09] <plinss_> right
# [03:10] <TabAtkins_> plinss_: Issue 278.
# [03:10] <TabAtkins_> dbaron: This is saying we should exlicitly say "margin box" to be clearer? Seems good.
# [03:10] <dbaron> RESOLVED: accept proposal for 278
# [03:10] <TabAtkins_> RESOLVED: Accept edit for 278.
# [03:10] <TabAtkins_> plinss_: Issue 279.
# [03:12] <johnjan> http://lists.w3.org/Archives/Public/www-style/2010Sep/0130.html
# [03:13] <TabAtkins_> RESOLVED: Accept edit for 279.
# [03:13] <TabAtkins_> plinss_: Issue 280.
# [03:14] <TabAtkins_> dbaron: I believe 280 is an error in the spec, where the impls got it right and the spec is wrong.
# [03:14] <dbaron> http://dbaron.org/css/test/2011/css21-issue-280
# [03:14] * Quits: sgalineau (sylvaing@63.245.220.224) (Ping timeout)
# [03:14] <TabAtkins_> dbaron: The question is whether fuschia starts within or below the purple box.
# [03:15] <TabAtkins_> fantasai: We have full interop.
# [03:15] <TabAtkins_> dbaron: ...which disagrees with the spec.
# [03:15] <TabAtkins_> dbaron: I think the problem is that the spec can be taken more literally than intended.
# [03:15] <TabAtkins_> dbaron: The spec says that [omg rule 3].
# [03:15] <TabAtkins_> dbaron: But this neglects the possibility that the right-floating box may be at the same vertical postion as the left float, but be entirely to its left.
# [03:16] <TabAtkins_> dbaron: Which is this testcase.
# [03:17] <TabAtkins_> dbaron: The change is to make the spec say "when they overlap in vertical position".
# [03:17] <TabAtkins_> dbaron: But the spec literally says something wider.
# [03:17] <fantasai> s/wider/to the right/
# [03:18] <fantasai> dbaron: so the implementations implemented what Bert meant to say, and Anton has noticed that this is not what was actually said
# [03:18] <TabAtkins_> dbaron: "next to it" works.
# [03:18] <dbaron> Bert proposed "next to it"
# [03:19] <TabAtkins_> RESOLVED: Change "to the right of it" into "next to it".
# [03:19] <TabAtkins_> glazou: Issue 281.
# [03:19] <johnjan> no change necessary for 2.1 here.... errata
# [03:20] <TabAtkins_> fantasai: I think we should fix this. It's just wrong.
# [03:20] <TabAtkins_> dbaron: You could change it to "not a position derived from the line-height".
# [03:20] <dbaron> maybe change "not the 'line-height'" to "not a position derived from the 'line-height'"
# [03:21] <dbaron> fantasai: or just replace the clause with "and has nothing to do with the 'line-height'"
# [03:21] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
# [03:22] * Quits: bradk (bradk@63.245.220.224) (Quit: Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/ )
# [03:22] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
# [03:22] <TabAtkins_> RESOLVED: Accept fantasai's edit for 281.
# [03:22] <johnjan> I can buy that
# [03:23] <fantasai> Meeting closed.
# [03:23] <Bert> Still not on the plane, johnjan?
# [03:23] * Quits: plinss_ (plinss@63.245.220.224) (Quit: plinss_)
# [03:23] * Quits: szilles (chatzilla@63.245.220.224) (Ping timeout)
# [03:23] * Quits: mmielke (mmielke@63.245.220.224) (Ping timeout)
# [03:23] * Quits: shonda (shonda@63.245.220.224) (Quit: Leaving...)
# [03:24] * Quits: dbaron (dbaron@63.245.220.240) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [03:24] * Quits: shan (qw3birc@128.30.52.28) (Quit: Page closed)
# [03:24] * Quits: johnjan (qw3birc@128.30.52.28) (Quit: Page closed)
# [03:24] * Bert rrsagent, draft minutes
# [03:24] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
# [03:25] <Bert> Meeting: CSS ftf day 2
# [03:25] <Bert> Chair: Peter/Daniel
# [03:25] * Bert rrsagent, draft minutes
# [03:25] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/08-css-minutes.html Bert
# [03:25] * Quits: philcupp (pcupp@63.245.220.224) (Ping timeout)
# [03:26] * Quits: Jay (jay@63.245.220.224) (Ping timeout)
# [03:26] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Quit: CHOCOA)
# [03:27] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
# [03:28] * Quits: Arron (arronei@63.245.220.224) (Ping timeout)
# [03:28] * Joins: dsinger (dsinger@17.73.147.178)
# [03:29] * Quits: alexmog (qw3birc@128.30.52.28) (Ping timeout)
# [03:37] * Joins: jdaggett (jdaggett@70.36.214.37)
# [03:56] * Quits: tantek (tantek@66.87.7.91) (Quit: tantek)
# [04:03] * Quits: kennyluck (kennyluck@128.30.52.169) (Quit: kennyluck)
# [05:17] * Joins: glazou (glazou@69.198.183.141)
# [05:19] * Quits: glazou (glazou@69.198.183.141) (Quit: glazou)
# [05:23] * Joins: TabAtkins_ (tabatkins@76.253.3.102)
# [05:39] * Joins: plinss_ (plinss@72.254.93.81)
# [05:50] * Joins: Arron (arronei@209.118.182.194)
# [05:57] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [05:57] * Joins: plinss_ (plinss@72.254.93.81)
# [06:07] * Joins: mmielke (mmielke@209.118.182.194)
# [06:08] * Quits: mmielke (mmielke@209.118.182.194) (Quit: mmielke)
# [06:13] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [06:32] * Joins: plinss_ (plinss@72.254.93.81)
# [06:53] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [06:57] * Quits: Arron (arronei@209.118.182.194) (Ping timeout)
# [07:01] * Joins: plinss_ (plinss@72.254.93.81)
# [07:23] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [07:24] * Joins: plinss_ (plinss@72.254.93.81)
# [07:59] * Joins: kennyluck (kennyluck@128.30.52.169)
# [08:13] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [08:21] * Joins: plinss_ (plinss@72.254.93.81)
# [08:41] * Joins: philcupp (pcupp@209.118.182.194)
# [08:42] * Quits: Xaxio (Xaxio@75.28.47.214) (Quit: KVIrc 4.0.2 Insomnia http://www.kvirc.net/)
# [08:42] * Joins: Xaxio (Xaxio@75.28.47.214)
# [08:44] * Quits: jdaggett (jdaggett@70.36.214.37) (Quit: jdaggett)
# [08:53] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [09:04] * Quits: philcupp (pcupp@209.118.182.194) (Ping timeout)
# [09:22] * Quits: TabAtkins_ (tabatkins@76.253.3.102) (Ping timeout)
# [09:23] * Joins: TabAtkins_ (tabatkins@76.253.3.102)
# [09:42] * Joins: shepazu (schepers@128.30.52.169)
# [09:51] * Quits: TabAtkins_ (tabatkins@76.253.3.102) (Ping timeout)
# [09:54] * Joins: TabAtkins_ (tabatkins@76.253.3.102)
# [09:57] * Joins: plinss_ (plinss@72.254.93.81)
# [10:02] * Joins: Ms2ger (Ms2ger@91.181.2.129)
# [10:04] * Quits: shepazu (schepers@128.30.52.169) (Ping timeout)
# [10:13] * Joins: homata (homata@58.158.182.50)
# [10:23] * Quits: plinss_ (plinss@72.254.93.81) (Ping timeout)
# [10:23] * Quits: TabAtkins_ (tabatkins@76.253.3.102) (Ping timeout)
# [12:10] * Quits: arronei (arronei@131.107.0.87) (Ping timeout)
# [12:16] * Joins: arronei (arronei@131.107.0.94)
# [12:22] * Quits: homata (homata@58.158.182.50) (Quit: Leaving...)
# [12:54] * Joins: myakura (myakura@123.224.162.182)
# [13:01] * Joins: anne (annevk@83.85.115.123)
# [13:50] * Quits: myakura (myakura@123.224.162.182) (Client exited)
# [14:30] * Joins: jdaggett (jdaggett@70.36.214.37)
# [14:34] * Quits: karl (karlcow@128.30.54.58) (Quit: Freedom - to walk free and own no superior.)
# [15:28] * Joins: philcupp (pcupp@209.118.182.202)
# [15:32] * Quits: philcupp (pcupp@209.118.182.202) (Quit: philcupp)
# [16:17] * Joins: plinss_ (plinss@72.254.82.99)
# [16:29] * Quits: plinss_ (plinss@72.254.82.99) (Connection reset by peer)
# [16:30] * Joins: plinss_ (plinss@72.254.82.99)
# [16:33] * Quits: plinss_ (plinss@72.254.82.99) (Ping timeout)
# [16:52] * Joins: plinss_ (plinss@72.254.82.99)
# [17:08] * Quits: plinss_ (plinss@72.254.82.99) (Quit: plinss_)
# [17:10] * Joins: Martijnc (Martijnc@91.176.100.249)
# [17:15] * Joins: dsinger_ (dsinger@12.175.88.195)
# [17:17] * Quits: dsinger (dsinger@17.73.147.178) (Ping timeout)
# [17:18] * Quits: dsinger_ (dsinger@12.175.88.195) (Ping timeout)
# [17:37] * Quits: jdaggett (jdaggett@70.36.214.37) (Quit: jdaggett)
# [17:49] * Joins: dbaron (dbaron@63.245.220.240)
# [17:52] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
# [17:54] * Joins: dsinger (dsinger@17.72.146.124)
# [17:58] * Joins: Arron (arronei@63.245.220.224)
# [17:59] * Joins: stearns (stearns@192.150.22.5)
# [18:01] <stearns> Does the F2F pre-empt the weekly conference call, or should I hop on the phone?
# [18:02] * Joins: plinss_ (plinss@63.245.220.224)
# [18:05] * Joins: shonda (shonda@63.245.220.224)
# [18:05] * Joins: jdaggett (jdaggett@63.245.220.224)
# [18:06] * dsinger I hope it pre-empts!
# [18:06] * Joins: dbaron (dbaron@63.245.220.240)
# [18:06] <anne> stearns, dsinger, it pre-empts
# [18:06] * Joins: glazou (glazou@63.245.220.224)
# [18:07] * dsinger by the way, maybe the IRC chat topic could reflect what the current major topic is during the face to face? (e.g. "CSS vertical text" etc.)?
# [18:07] * Joins: shan (qw3birc@128.30.52.28)
# [18:07] * dbaron suspects if we tried that it would be out-of-date 90% of the time
# [18:09] * Joins: cslye (cslye@192.150.19.4)
# [18:10] * Bert rrsagent, pointer?
# [18:10] * RRSAgent See http://www.w3.org/2011/03/08-css-irc#T17-06-00
# [18:10] * Bert rrsagent, bye
# [18:10] <RRSAgent> I'm staying, Bert; no access has been specified for the meeting record
# [18:10] <dbaron> RRSAgent, make logs public
# [18:10] <RRSAgent> I have made the request, dbaron
# [18:10] * Bert rrsagent, make logs public
# [18:10] * RRSAgent I have made the request, Bert
# [18:10] * Bert rrsagent, bye
# [18:10] <RRSAgent> I see no action items
# [18:10] * Parts: RRSAgent (rrs-loggee@128.30.52.169)
# [18:11] * Joins: RRSAgent (rrs-loggee@128.30.52.169)
# [18:11] <RRSAgent> logging to http://www.w3.org/2011/03/09-css-irc
# [18:11] <dbaron> RRSAgent, this meeting spans midnight
# [18:11] <RRSAgent> ok, dbaron; I will not start a new log at midnight
# [18:11] * Bert rrsagent, this meeting spans midnight
# [18:11] <RRSAgent> ok, Bert; I will not start a new log at midnight
# [18:11] <Bert> meeting: CSS ftf day 3
# [18:11] <Bert> chair: peter/daniel
# [18:11] * Bert rrsagent, make minutes
# [18:11] <RRSAgent> I have made the request to generate http://www.w3.org/2011/03/09-css-minutes.html Bert
# [18:11] * Bert rrsagent, make logs public
# [18:11] * RRSAgent I have made the request, Bert
# [18:12] * Joins: bradk (bradk@63.245.220.224)
# [18:13] * Joins: smfr (smfr@63.245.220.224)
# [18:13] * Joins: sylvaing (sylvaing@63.245.220.224)
# [18:14] <jdaggett> topic: css3 fonts
# [18:14] <jdaggett> http://dev.w3.org/csswg/css3-fonts
# [18:14] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
# [18:15] * Joins: hober (ted@63.245.220.224)
# [18:16] <fantasai> ScribeNick: fantasai
# [18:17] <fantasai> jdaggett: There are some recent edits that I wanted to go over, based on comments that were made at previous F2F and on www-style
# [18:17] <fantasai> jdaggett: We'll go through those, then at the end there's some discussion that needs to happen wrt WOFF.
# [18:17] * Joins: alexmog (qw3birc@128.30.52.28)
# [18:17] <fantasai> jdaggett: Overview: css3-fonts expands font properties from CSS2.1 and adds definition for @font-face which allows fonts to be downloaded, and add supports for OpenType font features, which are exposed via font-variant
# [18:18] * Joins: howcome (howcome@63.245.220.224)
# [18:18] <fantasai> jdaggett: Font features are ways of selecting alternate glyphs or alternate ways of showing text using data that's contained in OT fonts.
# [18:18] <fantasai> jdaggett: Covers superscripts subscripts, alternate glyphs, ligatures, etc.
# [18:18] * Joins: szilles (chatzilla@63.245.220.224)
# [18:19] <fantasai> jdaggett: It let's you select which (of multiple variant glyphs for given set of codepoints) is chosen
# [18:19] <fantasai> jdaggett shows stylistic()
# [18:19] <fantasai> jdaggett: Because the argument to stylistic() is specific to the font, a lot of people in the group felt we needed a way to associate that value with the font that had that feature.
# [18:20] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-feature-values
# [18:20] <fantasai> jdaggett: Because of that, we added the @font-feature-values rule
# [18:20] <fantasai> jdaggett: For each of the font-specific alternate types, you define a set of name-value pairs for a given font
# [18:20] <fantasai> jdaggett explains the rest of @font-feature-values
# [18:21] <fantasai> basically, you create an @-rule associated with a font name
# [18:21] <fantasai> and then within that block you define name-value pairs
# [18:21] <fantasai> the same name can be used in multiple @-rules, associating different values with the same name depending on the font
# [18:22] <fantasai> then in the declaration, stylistic() takes the name, and maps to the appropriate value depending on the font actually in use
# [18:24] <fantasai> howcome: Do we need the comma between the name-value pairs?
# [18:24] <fantasai> fantasai: technically, no
# [18:24] <fantasai> jdaggett: I think it makes it easier to read
# [18:26] <fantasai> jdaggett: I had swash: delicate 1, flowing 2; but since the cascading behavior is different from what you'd expect from that, WG wanted to change the syntax
# [18:26] <fantasai> fantasai: The cascading behavior is as if "swash" was an element name, and the name-value pairs were property-value declarations.
# [18:27] <fantasai> fantasai: There was another proposal that made this clearer (by adopting element { property: value; } syntax) at the expense of adding more braces
# [18:27] * fantasai wonders where molly is
# [18:28] <fantasai> jdaggett shows more examples from the spec that illustrate the cascading behavior, which collects all name-value mappings across style sheets (redeclaring same name overrides, just like property-value declarations)
# [18:29] * Joins: johnjan (qw3birc@128.30.52.28)
# [18:29] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
# [18:31] <fantasai> jdaggett shows some other func() font feature notations that use @font-feature-values rule
# [18:32] <fantasai> more discussion of comma
# [18:32] <fantasai> howcome thinks it's unnecessary typing
# [18:33] <fantasai> fantasai notes that counter properties don't use commas
# [18:35] <fantasai> dbaron notes that he always gets that wrong even though he implemented it
# [18:35] <fantasai> howcome: commas used to be used to denote alternates
# [18:35] <fantasai> Tab: But that's not true anymore
# [18:35] <fantasai> Tab: e.g. text-shadow, background
# [18:35] <fantasai> Some discussion of syntax
# [18:36] <fantasai> howcome feels it's unclear that the name-value pairs are additive, suggests being more verbose and using separate @ rules for each pair
# [18:36] <fantasai> jdaggett notes that this is possible if that's wanted
# [18:36] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [18:36] <fantasai> several feel that's excessive typing and don't want to require it
# [18:37] * Joins: arno (arno@192.150.10.200)
# [18:38] <fantasai> jdaggett shows the Greek coin example
# [18:39] * Joins: bz (bzbarsky@71.184.125.56)
# [18:39] <bradk> http://www.tktype.com/chartwell.php
# [18:41] <fantasai> jdaggett notes for the future that having selectors for picking out patterns to alter the font-features of would be nicer than having to use spans
# [18:41] <fantasai> but this example is rare enough that for now this doesn't seem to be a problem for us to solve
# [18:43] <fantasai> some questions about how OT features work
# [18:43] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
# [18:43] <fantasai> jdaggett explains
# [18:44] <fantasai> jdaggett reviews some updates to the font-feature-settings syntax
# [18:45] <fantasai> jdaggett: There's a set of registered OpenType features.
# [18:45] <fantasai> jdaggett: All of them will be CSS identifiers
# [18:45] <fantasai> jdaggett: It's technically possible to define an OpenType feature that, e.g. starts with a 3
# [18:45] <fantasai> jdaggett: For those cases that we want to escape, you can add the optional ot- prefix
# [18:46] <fantasai> jdaggett: For these tags I haven't put in any syntax definitions
# [18:47] <fantasai> jdaggett explains the escaping mechanism e.g. 3cap feature would have to be written as ot-3cap
# [18:47] <fantasai> jdaggett: For boolean features, just placing the feature name will set it to 1 (on)
# [18:48] <Bert> (ot-3cap and \3cap are thus the same.)
# [18:48] <fantasai> jdaggett: Also the author can be explicit with functional notation, wihch allows integers, but can also use "on" and "off"
# [18:49] <fantasai> dbaron: You don't need the ot- prefix for escaping, since you can just escape the number
# [18:49] <fantasai> Tab: Why aren't we just using quoted strings?
# [18:49] <dbaron> ot-3cap and \33cap are the same
# [18:49] <dbaron> er
# [18:49] <dbaron> ot-3cap and \33 cap are the same
# [18:49] <Bert> (Correction: ot-3cap and \33 cap are thus the same.)
# [18:50] * glazou wonders where is Molly...
# [18:50] <fantasai> jdaggett^: There was also the question of e.g. attr() function, which could conflict with an OT feature
# [18:51] <fantasai> jdaggett: You're not just giving the feature name, you have to give a value, too.
# [18:51] <dbaron> Arron suggests: "3pix" 1
# [18:52] <Arron> "3pix" 1
# [18:53] <fantasai> fantasai asks what would happen if a font format defined features that took string values
# [18:53] <fantasai> plinss: use a comma to separate mapping pairs
# [18:53] <dbaron> e.g., font-feature-settings: "smcp", "swsh" 2
# [18:53] <fantasai> jdaggett: for this, I think commas don't make sense
# [18:54] <bradk> "c2sc" 1, "3piX" 1
# [18:54] <fantasai> Steve: It would be nice if the pairing notation was the same in both places
# [18:54] <fantasai> jdaggett: For the name value pairs we are always defining a name and a value
# [18:54] <fantasai> jdaggett: For this in most cases you just want the tag name
# [18:55] <fantasai> jdaggett: So you wwant "smcp", "swsh" 2
# [18:55] <fantasai> plinss: The comma separates features settings, so that you can distinguish between a feature name and a value
# [18:56] <fantasai> steve says something, several people disagree
# [18:56] <dbaron> Steves asks whether given @swash flowing 1;, you could do font-feature-settings: swsh(flowing) or font-feature-settings: "swsh" flowing
# [18:57] <fantasai> jdaggett: So what if I say "iatl" for which we have no feature settings
# [18:57] <fantasai> dbaron: That seems like extra code to support the non-recommended way of doing something
# [18:57] <dbaron> s/iatl/ital/
# [18:58] <fantasai> Steve: I just want to make sure we make a conscious decision.
# [18:58] <dbaron> jdaggett: That means the author has to know which CSS property maps to which opentype feature name.
# [18:59] <fantasai> jdaggett: I just want to make sure everyone wants to have a non-functional notation, which is different from above
# [19:00] * Quits: glazou (glazou@63.245.220.224) (Client exited)
# [19:00] <fantasai> several: Yes. Those are CSS-defined. This is an open-ended set of potentially non-identifiers.
# [19:01] <fantasai> Luke: It's not clear that this is impossible to parse, it's just that you are introducing a whole bunch of these ..
# [19:01] <fantasai> Luke: We can't have a nice enum of whatever this type is
# [19:02] <fantasai> Luke: Instead of a simple arbitrary string, you have this extra syntax thing
# [19:02] <fantasai> fantasai: You have to parse arbitrary idents for counters anyway
# [19:03] * Joins: hyatt (hyatt@98.200.13.42)
# [19:04] <fantasai> Simon: I think you should figure out a way of not using ot-, or use it all the time. Having it be optional is weird
# [19:04] <jdaggett> alt 1: font-feature-settings: smcp, swsh 2;
# [19:04] <jdaggett> alt 2: font-feature-settings: "smcp", "swsh" 2;
# [19:05] <jdaggett> alt 3: font-feature-settings: smcp swsh(2);
# [19:05] <smfr> alt 2 and alt 3 may require ot- prefixes
# [19:06] <fantasai> s/2/1/
# [19:06] <jdaggett> alt 4: font-feature-settings: ot-smcp, ot-swsh(2)
# [19:07] <fantasai> this sets smcp to 1 and swsh 2
# [19:08] <fantasai> Steve: I don't understand why each of the pieces are being proposed
# [19:08] * fantasai notes that font family names are not required to be quoted, even though they could be anything
# [19:09] <fantasai> howcome: If it's just a low-level feature as an escape hatch in the baseline, why is the syntax that important?
# [19:09] <fantasai> glazou: It's about finding the most elegant syntax that avoids problems for the future
# [19:09] * Joins: stearns_ (stearns@192.150.22.5)
# [19:09] * Joins: glazou (glazou@63.245.220.224)
# [19:11] * Parts: stearns_ (stearns@192.150.22.5)
# [19:11] <fantasai> fantasai: Font families are either idents or quoted strings
# [19:11] * Joins: macpherson (macpherson@74.125.122.49)
# [19:11] <fantasai> fantasai: Why not do that here, where both 1 and 2 are possible?
# [19:11] * Joins: stearns_ (stearns@192.150.22.5)
# [19:11] <fantasai> Arron: I like that
# [19:11] * Quits: stearns (stearns@192.150.22.5) (Ping timeout)
# [19:11] * stearns_ is now known as stearns
# [19:11] <fantasai> plinss is concerned about this
# [19:12] <fantasai> dbaron: We have the future-proofing problem for counters and everal other things already
# [19:12] <fantasai> plinss: With strings you avoid potential conflicts with expansions in either CSS or the fonts
# [19:12] <Bert> +1 to fantasai (let author use quotes or not, as fits best)
# [19:12] * Joins: Jay (jay@63.245.220.224)
# [19:12] <fantasai> plinss: Also this avoids authors being confused about whether they need to quote something or not
# [19:13] <fantasai> alt 5: either 1 or 2 is valid
# [19:13] <fantasai> plinss: It's safer to always require it to be quoted.
# [19:14] <fantasai> plinss: This is an obscure rarely-used feature. It's simpler and easier to maintain if you always have to quote it
# [19:14] <fantasai> plinss: This avoids any potential problems ever.
# [19:14] <fantasai> jdaggett: I define on and off to be 1 and zero
# [19:14] <fantasai> plinss: That's fine.
# [19:15] <fantasai> jdaggett: And you're ok with assumption of 1 as default value
# [19:15] <fantasai> plinss: Yes, no problem. Those are all very clean CSS ways of doing things.
# [19:15] <fantasai> plinss: Our default design should be to avoid any possible conflicts with future CSS keywords
# [19:16] <fantasai> plinss: For something obscure like this, we really have no good reason to go against that.
# [19:16] <Bert> (The "ot-" prefix should probably be on the property name, not on the values...)
# [19:16] <fantasai> plinss: The ot- prefix is very complex because you parse an ident then have to reparse to break it down, I don't want to introduce that, especially not for something obscure like this
# [19:18] <fantasai> Bert: The quotes are redundant. They're parseable without.
# [19:19] <fantasai> Bert: And if you put this in an attribute, e.g. in HTML you have to double-quote.
# [19:19] <fantasai> Bert: That's why we didn't put quotes in font-family
# [19:19] * Joins: cslye_ (cslye@63.245.220.224)
# [19:19] <fantasai> Tab: The issue here is that once you go beyond idents, you have to start escaping, and that's very confusing for authors.
# [19:20] * Quits: cslye_ (cslye@63.245.220.224) (Client exited)
# [19:20] * Joins: cslye_ (cslye@192.150.19.4)
# [19:20] <fantasai> Tab: Very few people understand escaping rules
# [19:20] <fantasai> Bert argues for arbitrary unquoted strings
# [19:21] <fantasai> vehement disagreement
# [19:21] * Quits: cslye (cslye@192.150.19.4) (Ping timeout)
# [19:21] * cslye_ is now known as cslye
# [19:22] <fantasai> jdaggett: I will write up the proposal and post to the mailing list
# [19:22] <fantasai> fantasai: I would like to do something that gets a WD published.
# [19:22] <jdaggett> http://dev.w3.org/csswg/css3-fonts/#vertical-position-prop
# [19:23] <fantasai> RESOLVED: jdaggett will write up alt 2 into the spec, mark as open issue whether quotes are required
# [19:23] <fantasai> jdaggett moves on to vertical-position
# [19:24] <fantasai> jdaggett explains how superscripts and subscripts are currently implemented: the vertical alignment is adjusted, and the font size shrunk down
# [19:24] <fantasai> jdaggett: This has some problems. The typographic color is affected, since a typographic superscript or subscript is not used
# [19:24] <fantasai> jdaggett: And because of the vertical alignment, the line height is affected
# [19:25] <fantasai> jdaggett: So we have this feature
# [19:25] * Quits: bz (bzbarsky@71.184.125.56) (Quit: Leaving)
# [19:25] <fantasai> jdaggett: This property behaves as a shorthand, resetting font-size and vertical-align (to inherit and initial)
# [19:25] <fantasai> jdaggett: You effectively null out those property definitions
# [19:25] <fantasai> jdaggett: For older clients that don't support this feature, they will still use the default adjustement to font size
# [19:26] <fantasai> jdaggett: shows example
# [19:26] <fantasai> dbaron: There's also the second fallback case, of where the font doesn't support it
# [19:27] <fantasai> jdaggett: For that we put in synthesizing rules
# [19:27] <fantasai> Alex: Doesn't this still use smaller size
# [19:28] <fantasai> jdaggett: Yes. If those glyphs are missing, you don't get them. But you at least get a superscript. And you don't affect the line height.
# [19:29] <fantasai> dbaron: This seems to be the first time we have a shorthand that sets both inherited and non-inherited properties together. I'm a little concerned about that.
# [19:29] <fantasai> dbaron: Also, I'd like something that works for the default UA style sheet
# [19:30] <stearns> if only the old styling is used (vertical-align: sub) does a new implementation use the new synthesizing rules that do not affect line height?
# [19:30] <fantasai> steve explains his proposal
# [19:30] <fantasai> dbaron: Third proposal --
# [19:30] <fantasai> dbaron: Make vertical-position a non-inherited non-shorthand property
# [19:31] <fantasai> dbaron: Then say that any text inside an element with vertical-position set
# [19:31] <fantasai> dbaron: you ignore the vertical-align value on the element that had vertical-position set
# [19:31] <fantasai> dbaron: And you recompute the font size based on the ratio of the font-size of the element with vertical-position set to its parent
# [19:32] <fantasai> dbaron: if you have nested vertical-position, you ignore it on the nested one
# [19:33] <fantasai> dbaron: Then you can use it in a UA style sheet, and if the author nests superscripts you no-op it
# [19:33] <fantasai> fantasai, Steve: But the point was to have nested subscripts to work
# [19:33] <dbaron> It still doesn't really work with nested subscripts.
# [19:33] <fantasai> jdaggett: In your (Steve)'s proposal, the line height is affected
# [19:34] <fantasai> Steve: My thinking is that I have a subscript, and if my font has subscript characters, I want to use them
# [19:34] <fantasai> Steve: If it doesn't have a character in the font, then I'd like reasonable fallback
# [19:34] <fantasai> Steve: So my goal is to think about what would the fallback require, and then say how I can then go back and enable the font feature to be used
# [19:34] <fantasai> Steve: and in fact mixed with fallback
# [19:34] <fantasai> Steve: Say my subscript is 1a, and the font only has 1 as a subscript
# [19:35] <fantasai> jdaggett: My concern is that you're still affecting the line height
# [19:35] <fantasai> Steve: How do I make sure there's enough room for the subscript if we don't adjust the line-height?
# [19:36] <fantasai> jdaggett: The whole point of the font's glyphs is that they're designed to fit in with the rest of the text so you don't need to change the line height
# [19:37] <fantasai> Simon: Do fonts have glyphs for all their characters as superscripts?
# [19:37] <Bert> (Something like: 'vertical-position: superscript', IF the font has superscript glyphs AND the the elt has 'vertical-align: super', sets a hypothetical inherited 'font-size-multiply' property to (parent-size/own-size) and ignores 'vertical-align')
# [19:37] <fantasai> jdaggett: No. Usually only a small subset. If the glyph is missing, the UA synthesizes whatever is missing
# [19:39] <fantasai> some confused discussion
# [19:40] <fantasai> howcome: Why couldn't we key off 'vertical-align' and just have a setting that says "be smart"
# [19:42] <Bert> ('vertical-position: smart' means, if 'vertical-align' and 'font-size' are set in certain ways and the font has the necessary glyphs, then ignore the properties and use those glyphs.)
# [19:43] <Bert> Fantasai: keep the computed values, but change the used values.
# [19:44] <TabAtkins_> dbaron: You need to worry both about children that are nested sub/supers, and children that aren't.
# [19:45] <TabAtkins_> fantasai: [draws some superscripted]
# [19:45] <TabAtkins_> fantasai: You have the baseline of the element
# [19:46] <TabAtkins_> fantasai: And pick one of the baselines in this box. There's a different concept between what baseline you're aligning the text to, and what you expose as the text's "baseline" outside.
# [19:46] <TabAtkins_> fantasai: So text has an "alphabetic" and a "superscript" baseline.
# [19:47] <TabAtkins_> fantasai: When this feature is turned on, for the children, rather than aligning the children's alphabetic to the parent's alphabetic, align the children's alphabetic to the parent's superscript baseline.
# [19:47] <TabAtkins_> fantasai: And font-size is still inherited, so it'll shrink down as you drop, but the used value of font-size is based on the parent, so they'll be the right size when they're rendered.
# [19:48] <TabAtkins_> szilles: So what jdaggett is concerned about it, what is the line-height for the text?
# [19:48] <TabAtkins_> fantasai: The used value of the font-size is based on the parent. It *looks* like you're shifting up, but you're really just using a different glyph.
# [19:48] <TabAtkins_> fantasai: It's only when you start nesting that you'll mess with the line-height.
# [19:49] <TabAtkins_> dbaron: I think there's a second related problem here.
# [19:49] <TabAtkins_> dbaron: It's that we're using "font-size:smaller", which isn't what we want.
# [19:49] <stearns> If you don't have the OpenType glyphs, the synthesized version can run into line height problems as well
# [19:49] <TabAtkins_> dbaron: jdaggett says there's a metric that says not only where the superscript baseline is, but how large it is too.
# [19:49] * TabAtkins_ stearns, no, the synthesized characters will have the correct line-height, too.
# [19:50] <TabAtkins_> dbaron: if font-size had keywords for "superscript size", etc.
# [19:50] <TabAtkins_> Bert: MathML has a concept of a "script size".
# [19:51] <TabAtkins_> dbaron: If you combine the superscript baseline of a font with the superscript size, will you get something within the bounds of the font, so you don't bump the lineheight?
# [19:51] <TabAtkins_> jdaggett: It *should*, but not guaranteed.
# [19:51] <TabAtkins_> dbaron: We can ignore the problem of alternate glyphs for a moment, and just look at the sub/sup problem with synthesized/font-size stuff...
# [19:52] <TabAtkins_> dbaron: Then we'll solve the linebox problem, but not the weight problem.
# [19:52] <TabAtkins_> dbaron: And perhaps the alternate glyphs oslution will fall out of what we come up with.
# [19:52] <TabAtkins_> dbaron: This depends on the superscript characters actually matching the reported superscript metrics, or else this all falls apart.
# [19:53] <TabAtkins_> szilles: There are two categories: 1) fonts that behave like David wants them to behave, and 2) fonts that don't.
# [19:53] <TabAtkins_> szilles: Which group should we design towards? Either one may be broken in some case.
# [19:54] <TabAtkins_> cslye: I've looked at some Adobe fonts, and it looks like they're all "broken" - they use the same superscript baseline, which means they probably don't match the character size.
# [19:55] <TabAtkins_> szilles: I propose that we record an issue for this.
# [19:57] * Bert notices that jdaggett dressed appropriately for this discussion, in a ATypI 2009 t-shirt. :-)
# [19:57] <TabAtkins_> jdaggett: My problem is that most of these proposals are fairly hairy.
# [19:58] * TabAtkins_ declares minuting bankruptcy.
# [19:58] <TabAtkins_> szilles: [suggestion about making font-size and vertical-align compute to two values, one for normal text and one for sub/super text]
# [19:59] <TabAtkins_> jdaggett: I suggest I just put in a grave note about this being hairy, so we have some text about this in a WD.
# [19:59] <TabAtkins_> szilles: I recommend that the note point out that this is trying to solve the "line-heights get changed by sub/superscript" problem.
# [20:00] <TabAtkins_> szilles: Also that this being a shorthand "messes up" inheritance.
# [20:01] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [20:04] * Quits: arno (arno@192.150.10.200) (Quit: Leaving.)
# [20:11] * Quits: sylvaing (sylvaing@63.245.220.224) (Quit: sylvaing)
# [20:18] <fantasai> jdaggett: Next topic is font matching algorithm
# [20:18] <fantasai> jdaggett: This isn't totally completed
# [20:18] <fantasai> jdaggett: There are things that still need to be investigated, will talk about that later
# [20:18] <fantasai> jdaggett:
# [20:18] <fantasai> jdaggett: This is the world we live in today. *shows lsides of four 'u's*
# [20:19] <fantasai> jdaggett: You see normal, italic, obld, and bold italic
# [20:19] <fantasai> jdaggett: The way we're going is this way *shows slide of lots of 'u's with multiple weights, some of which have italics, and some of which have narrow*
# [20:19] <fantasai> jdaggett: This is the design of the Univers font
# [20:20] <fantasai> jdaggett: If you go back and look at CSS2.1 algorithm, it says 'first match on this, then match on this'
# [20:20] <fantasai> jdaggett: It's not fully describing the process that needs to happen
# [20:20] <fantasai> jdaggett: For each of the axes within this family, you're narrowing until you have only one choice
# [20:20] <fantasai> jdaggett: e.g. if you have font-stretch: normal, then you narrow to normal stretches
# [20:21] <fantasai> jdaggett: Then if you say font-style: normal, you filter out the italic faces
# [20:21] <fantasai> jdaggett: And if you say normal weight, then you select the normal weight within that
# [20:21] <fantasai> jdaggett: if you select condensed italic bold, then you narrow like this *demonstrates by highlighting characters*
# [20:22] <fantasai> jdaggett: Sometimes if the appropriate weight or italics is missing, the UA synthesizes them
# [20:22] <fantasai> jdaggett: But in the font world you can have families like this *shows a slide of 'u's that fill in only random parts of the font weight/stretch/italic chart*
# [20:22] <fantasai> jdaggett: I tried to make the rules as simple and straightforward as possible
# [20:23] <fantasai> jdaggett: DirectWrite does some fancy grouping, where it takes fonts that have families that specify a style in the family name
# [20:24] <fantasai> jdaggett: And it will remove the style names and create its own families
# [20:24] <fantasai> jdaggett: Both IE9 and FF4 put in hacks to work around,
# [20:24] <fantasai> jdaggett: if an author says I want "Gill Sans", which is typically available on OS X
# [20:24] <fantasai> jdaggett: Via DirectWrite you would wind up wth a family that had only Gill Sans Ultra Bold
# [20:25] <fantasai> jdaggett: Instead of saying very vague terms about you match this and then you match that...
# [20:25] <fantasai> jdaggett: ...
# [20:25] <fantasai> jdaggett projects the algo
# [20:25] <fantasai> howcome: Are we going to have to change our implementations?
# [20:26] <fantasai> jdaggett: Where there wer ambiguities in the original spec, you may need to change your implementation. I think for the common cases it will not be necessary.
# [20:26] <fantasai> jdaggett: For most families that exist on most platforms, it's a very simple choice. And those choices will not be affected.
# [20:26] <fantasai> jdaggett: The choices that will be affected are when someone creates an incongruous family via @font-face
# [20:27] <fantasai> jdaggett: Right now the choices in such cases that result in random choices
# [20:27] <fantasai> howcome: It would be good if we could have test cases
# [20:27] <fantasai> jdaggett: That's the intention. To put in rules here so that I can write tests and point to what they're testing.
# [20:28] <fantasai> jdaggett: jkew pointed out the first line in rule 4
# [20:28] <fantasai> jdaggett: Not all of the faces in a family will have the same character
# [20:29] <fantasai> jdaggett: There's a question of, do you first say "what are all the faces that have a specific glyph" and then match after that
# [20:29] * Joins: bradk (bradk@63.245.220.224)
# [20:29] <fantasai> jdaggett: UAs typically select a face and then find out whether the glyph is there or not.
# [20:29] <fantasai> jdaggett: But you have problems, e.g. Arial has some faces (e.g. italic) that don't have all the characters in other faces
# [20:29] * Joins: sylvaing (sylvaing@63.245.220.224)
# [20:30] <dbaron> so UAs typically select the face, and then if the glyph isn't present in that face, they fall back to the next *family*
# [20:30] <fantasai> jdaggett: So you might select bold italic, and since the glyph isn't there, you fall back to a different font instead of falling back to another variant of Arial that has the glyph
# [20:30] <fantasai> jdaggett: I put rules here that you select font-stretch similar to the way you'd select the weight
# [20:30] <fantasai> Steve: So sort of the nearest reasonable value
# [20:30] <fantasai> jdaggett: yes, but not precisely
# [20:31] <fantasai> jdaggett: Here, for example, the normal face is the family to the left
# [20:31] <fantasai> jdaggett: You can specify style values that are in between some of these families
# [20:31] <fantasai> jdaggett: The rule I wrote up in the text is to always go away from 'normal'
# [20:31] <fantasai> jdaggett: So it may not be the next closest nearest neighbor
# [20:31] <fantasai> jdaggett: We might end up picking something further away
# [20:31] <fantasai> Steve: that's true in weights as well
# [20:32] <fantasai> Arron: You're trying to show visual change
# [20:32] <fantasai> jdaggett: right
# [20:32] <fantasai> jdaggett: I also put in rules that you don't synthesize
# [20:32] <fantasai> jdaggett: That's marked as an issue
# [20:32] <fantasai> jdaggett: I would prefer that we keep synthesis as effects, and not part of the selection process
# [20:34] <fantasai> jdaggett: If you have a font style choice of italic and there's no italic, per CSS rules you technically should be falling back
# [20:34] <fantasai> jdaggett: But in implementations today you don't do that, so these rules match reality
# [20:35] <fantasai> jdaggett: We have 'normal' 'italic' and 'oblique'
# [20:35] <fantasai> jdaggett: But typically, whether there is italic or oblique depends on the kind of font
# [20:35] <fantasai> jdaggett: Current UAs don't distinguish italic and oblique
# [20:35] <fantasai> jdaggett: So what I've written here is that UAs are allowed to do this, but for @font-face rules they must distinguish
# [20:37] <fantasai> ...
# [20:37] <fantasai> jdaggett: There was some confusion over this where some people were interpreting oblique as the synthesized face, but that's not the case.
# [20:37] <fantasai> Bert: This is a change from CSS2.1
# [20:37] <fantasai> jdaggett: It's a change from the wording of the CSS2.1 spec, but not from implementations
# [20:38] <fantasai> jdaggett: In implementations, you couldn't specify italics and get normal.
# [20:38] <fantasai> howcome: It would be good to get a list of changes.
# [20:38] <dbaron> (relative to CSS 2.1)
# [20:39] <fantasai> jdaggett points out sentence that uses actual value of font-size instead of computed, that it should be removed
# [20:39] <fantasai> Bert thought it was removed already from 2.1, dbaron suggests maybe we forgot this occurrence
# [20:41] <Bert> (15.7 "font-size" in CSS 2.1 says "On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.On all other properties, 'em' and 'ex' length values refer to the computed font size of the current element. On the 'font-size' property, these length units refer to the computed font size of the parent element.")
# [20:41] <fantasai> jdaggett: I also changed the behavior for small-caps, since this is no longer a separate font face with a different name, but part of the main font family, and UAs don't associate unrelated fonts via "small caps" in the name
# [20:41] * Bert sorry for the double paste
# [20:42] <fantasai> jdaggett notes that the system font fallback is very UA-defined, might involve multiple fonts, might depend on codepoint or encoding or language, so has clarified that
# [20:43] <fantasai> jdaggett also added a last resort representation for missing glyphs
# [20:43] <fantasai> jdaggett: This leads to character handling issues
# [20:43] <fantasai> jdaggett: In Unicode you're not dealing with just a single character, but a cluster
# [20:43] <fantasai> jdaggett: It could be something very simple like an a with an umlaut
# [20:43] <fantasai> jdaggett: the exact way that we match this hasn't been defined, and we need to define this out more
# [20:44] <fantasai> jdaggett: I haven't put this in here, but I think what we need to do is map the entire grapheme cluster together
# [20:44] <fantasai> jdaggett: and if we don't have a font that matches all of those, then go back and do character-by-character
# [20:44] <fantasai> jdaggett: The thing that's bad right now is that CSS2.1 requires that you use combining characters from the first font even though the base character is from a different font
# [20:44] <fantasai> jdaggett: I added also that PUAs don't fall back to the system font fallback
# [20:45] * Joins: sgalineau (sylvaing@63.245.220.224)
# [20:45] * fantasai thinks this is a good idea for generic fonts and system fallback -- skip right to missing glyph
# [20:46] <fantasai> jdaggett also added an escape clause for U+FFFD
# [20:46] <fantasai> jdaggett: Another issue is how to deal with variation selectors
# [20:46] * Quits: sylvaing (sylvaing@63.245.220.224) (Ping timeout)
# [20:46] <fantasai> jdaggett: The idea of a variation selector is that for a given Unicode code point, you want to be able to specify a particular representation for that character
# [20:46] <fantasai> jdaggett: There are a lot of ambiguities here
# [20:47] <fantasai> jdaggett: There are a lot of debates within people designing Unicode about whether these should be separate characters, or glyphs that are variations of a single character
# [20:47] <fantasai> jdaggett: The variation selector was to indicate that if possible, you should display a particular character with a particular variation
# [20:47] <fantasai> jdaggett: This comes up a lot in Chinese and Japanese where over time the glyph representation has changed
# [20:47] <fantasai> jdaggett: In particular for people's names or place names, they're registered one way, an dyou want to be able to capture that.
# [20:48] <fantasai> jdaggett: You want to specify with a Unicode codepoint what the ideal representation you're looking for is.
# [20:48] <fantasai> jdaggett: So that I can show it on my screen with my fonts, and mail it to you and you can't see it because you don't have that ofnt, but you send it to someone else and they can see it
# [20:48] * Quits: stearns (stearns@192.150.22.5) (Client exited)
# [20:48] <fantasai> jdaggett: There's a question here of how you do fallback.
# [20:49] * Joins: stearns (stearns@192.150.22.5)
# [20:49] <fantasai> jdaggett: If you say "I want to display in this font", and a character with a variation selector whose glyph doesn't exist in that font shows up, what do you do?
# [20:49] <fantasai> jdaggett shows an example
# [20:52] * Joins: arno (arno@192.150.10.200)
# [20:53] * Quits: smfr (smfr@63.245.220.224) (Quit: smfr)
# [20:53] <fantasai> in this case there are several variants that are different
# [20:53] <fantasai> and several variants that are the same
# [20:54] <fantasai> jdaggett: So do you want to fall back to a different font? Or show the default glyph? What if the default glyph is the same as the variant glyph?
# [20:54] <fantasai> Steve: This would be a good topic for the workshop in June
# [20:55] <fantasai> jdaggett: I think you would need to talk to people designing fonts.
# [20:55] * fantasai thinks Unicode should have required glyphs that nobody can find a difference for to be unified
# [20:56] <fantasai> jdaggett: If you go across fonts, you're not guaranteed to get something right
# [20:56] <fantasai> jdaggett shows some more examples
# [20:57] <fantasai> jdaggett: Here we're using a gothic font.
# [20:57] <fantasai> jdaggett: The second line uses a variation selector, takes the glyph from another font
# [20:57] <fantasai> (serif font)
# [20:57] <fantasai> jdaggett: This one it's not subtle, the variation is a structural difference.
# [20:58] <fantasai> jdaggett: But for an author to go from this, to this, it's a little incongruous
# [20:58] <fantasai> jdaggett: My point is that nothing is cut and dry here.
# [20:58] <fantasai> jdaggett: There are authors who would rather have the exact glyph
# [20:58] <fantasai> jdaggett: And there are authors that would rather have the font match
# [20:59] * Quits: anne (annevk@83.85.115.123) (Quit: anne)
# [20:59] <fantasai> kojiishi: IVS is primarily for place name and people name
# [20:59] <fantasai> kojiishi: Using the wrong variant is very impolite
# [20:59] * Quits: sgalineau (sylvaing@63.245.220.224) (Quit: sgalineau)
# [20:59] <fantasai> kojiishi: especially for peoples' names
# [21:00] <fantasai> some argument between Koji and John about intended behavior of IVS
# [21:02] <fantasai> jdaggett: If you fall back to a font that has slightly different style, then you may not be able to pick out stylistic differences, particularly if face is gothic face
# [21:02] <fantasai> Steve: What I've heard you say so far is there are reasonable cases for saying that you want to preserve font integrity and perhaps do what we would do today
# [21:02] <fantasai> Steve: Let's just deal with IVS
# [21:03] <fantasai> Steve: There are two options. 1. treat as request for specific thing, and fall back if not there.
# [21:03] <fantasai> Steve: 2. Use this thing if it's there, otherwise use the thing this is a variation of
# [21:03] <fantasai> Steve: You've given good examples where one of those approaches is the one that's desired and others where the other approach is desired
# [21:04] <fantasai> Steve: That suggests to me that have a property to control that would be a useful way for author to say which is more important.
# [21:04] <fantasai> jdaggett: To define that fallback occurs to the system font, and have to analyze the cmap to find this, that UAs are required to find this font on the system, that's a lot of wrk
# [21:04] <fantasai> work
# [21:05] <fantasai> jdaggett: There's how fallback works within fonts, and another of system font fallback
# [21:05] <fantasai> jdaggett: We don't specify system font fallback
# [21:05] <fantasai> jdaggett: Is that something that prevents UA from doing something intelligent? No. Just undefined.
# [21:05] <fantasai> Steve: What occurs to me is that if I make the property have the default value of today's behavior
# [21:06] <fantasai> jdaggett: The default behavior in FF4 is, if we have a font in the font list that supports the default character, then we will use the default character if the variation selector is not defined.
# [21:06] <fantasai> jdaggett: This requires the author to specify a font that has the variation they want.
# [21:06] <fantasai> jdaggett: Practically, they have to do this anyway because the system font is unlikely to have the variation they want
# [21:06] * Joins: macpherson_ (macpherson@63.245.220.224)
# [21:07] <fantasai> Steve: My proposal is the property does today's behavior by default.
# [21:07] <fantasai> jdaggett: There is no defined behavior today.
# [21:07] <fantasai> Steve: This will not be the first time we define default by defining what is
# [21:07] <fantasai> Steve: Could use property to trigger more refined behavior
# [21:08] <fantasai> Steve: Could search for IVS, and if it's not there redo search for default glyph
# [21:08] * Quits: macpherson (macpherson@74.125.122.49) (Ping timeout)
# [21:08] * macpherson_ is now known as macpherson
# [21:08] <fantasai> Steve: I don't think this is that complicated
# [21:09] <fantasai> jdaggett: It is, doing this as system font fallback is complicated
# [21:09] <fantasai> fantasai: So don't define it for system font
# [21:09] <fantasai> jdaggett explains that this doesn't work
# [21:10] <fantasai> Steve: You go looking through sequence of listed fonts, and if you find an IVS you use it.
# [21:10] <fantasai> Steve: If you don't find it, you start over for the base character, and that one hits the system font fallback
# [21:11] <fantasai> jdaggett: But koji says Unicode people want to get the IVS if it's there in the system font
# [21:11] <fantasai> plinss: Time.
# [21:11] <fantasai> jdaggett: There are a lot of issues here, and I don't think there's a simple answer here.
# [21:12] <fantasai> jdaggett: There's a lot of complexity here and we can't decide one way or the other
# [21:12] <fantasai> Steve: I would like for us to make IVS work, and avoid code points or other subterfuges that would have even worse side-effects.
# [21:12] <fantasai> kojiishi: If you modify the spec to include normalized shapes for font fallback?
# [21:13] <fantasai> kojiishi: What's the philosophy behind dealing with grapheme clusters?
# [21:13] <fantasai> jdaggett: The behavior for grapheme clusters will be distinct from IVS
# [21:13] <fantasai> jdaggett: Because of the internal structure of the way the selectors are defined, there has to be more with what goes on
# [21:13] <fantasai> jdaggett: They should try to work similarly, but you have a whole bunch of variation selectors that point at the default.
# [21:14] <fantasai> jdaggett: So the way this works is going to be slightly different.
# [21:15] <fantasai> fantasai: Can we file a bug against Unicode?
# [21:15] <fantasai> fantasai: Request that new variation selectors can only be registered if the registrant can explain how their glyph is different from all the other glyphs
# [21:16] <fantasai> jdaggett: If a UA is getting a font from the server, by default it will not take fonts that are on a different server.
# [21:16] <fantasai> jdaggett: This prevents people from using a font from another site on their site
# [21:16] <fantasai> jdaggett: Helps fulfil requirements on some font licenses
# [21:16] <fantasai> jdaggett: There's a large issue if this should be by default requiring same-origin
# [21:17] <fantasai> jdaggett: In <canvas> if you display an image from a different server, it taints the canvas and disables APIs that would read information from the canvas
# [21:17] <fantasai> jdaggett: There are problems related to same-origins
# [21:17] <fantasai> jdaggett: If it's loaded cross-domain, it will tain the canvas
# [21:18] <fantasai> jdaggett: But it's really... there are some people that would suggest not allowing cross-domain use unless it's explicitly marked as cross-domain
# [21:18] <fantasai> jdaggett: Most resources on the Web are not
# [21:18] <fantasai> jdaggett: We can't go back and retroactively reset those
# [21:18] <fantasai> jdaggett: because much of the Web has been built on that
# [21:18] <fantasai> jdaggett: The spec as written includes this restriction
# [21:19] <fantasai> jdaggett: So there's this kind of dependencies that are all jumbled up
# [21:19] <fantasai> jdaggett: The CSS3 Fonts spec defines what a same-origin restriction is
# [21:19] <fantasai> jdaggett: Since it needs to be defined with the loading mechanism, which is @font-face
# [21:19] <fantasai> jdaggett: Apple and Opera have objected and want to have instead a different mechanism
# [21:19] <fantasai> jdaggett: Where the mechanism is opt-in instead of opt-out
# [21:19] <fantasai> jdaggett: Where the server would say that this resource is restricted to the same domain
# [21:20] <fantasai> jdaggett: Then you could say the same thing for images, say that the images can't be used cross-origin
# [21:20] <fantasai> jdaggett: This would allow server admins to not e.g. sniff referrer tags
# [21:20] <fantasai> jdaggett: The WOFF team has decided that we're going to mark that aspect as at-risk, and there's a potential for dropping this restriction and this other mechanism can come in and replace it
# [21:21] <fantasai> jdaggett: I don't know if that will work
# [21:21] <fantasai> howcome: I think you've presented it in a fair manner.
# [21:21] <fantasai> howcome: From Opera's perspective, our concern is the Web architecture
# [21:21] <fantasai> howcome: We would like one mechanism that can be used for the whole Web, and not just specific to @font-face
# [21:21] <fantasai> howcome: I don't have a strong opinion, but some others in Opera do
# [21:21] <fantasai> howcome: Anne has written up a proposal for a From-Origin spec
# [21:22] <fantasai> howcome: I don't think this should be in a font-specific spec, but in a generic spec that is not tilted towards a particular media type
# [21:22] <fantasai> howcome: I also think the default value should be the same throughout the Web
# [21:22] <fantasai> jdaggett: I don't think it's in-scope for this WG
# [21:23] <fantasai> jdaggett: to tackle that question
# [21:23] <fantasai> jdaggett: But we have to reference this issue somehow
# [21:23] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [21:23] <fantasai> dbaron: Lunch has now be cut to 40 min because we have a hard stop for end of lunch because of QA at 1pm
# [21:24] <fantasai> plinss: This is an important issue, being discussed at other leves, WebApps and TAG are looking at this
# [21:24] <fantasai> jdaggett: How do I get my spec not stuck in limbo for 3 years?
# [21:24] <fantasai> plinss: Mark the feature at-risk.
# [21:25] <Bert> (I don't think we should say anything about specific mechanisms in CSS, even if we *do* have a good idea of what the mechanism might eventually be; just drop appendix A.)
# [21:26] <fantasai> jdaggett: Would like to resolve publishing another WD
# [21:26] * Quits: plinss_ (plinss@63.245.220.224) (Quit: plinss_)
# [21:26] * Quits: Martijnc (Martijnc@91.176.100.249) (Quit: Martijnc)
# [21:27] <fantasai> RESOLVED: Publish updated WD, with changes marked above (adding issue notes), and list of font matching changes from 2.1
# [21:27] <fantasai> whew!
# [21:27] <fantasai> dbaron: Q&A session after lunch, will have a remote video link, but only Mozilla employees
# [21:27] <johnjan> that was amazing to watch on IRC
# [21:27] * Parts: cslye (cslye@192.150.19.4)
# [21:27] * fantasai has no idea what that would mean
# [21:27] <fantasai> :)
# [21:28] <fantasai> <br type="lunch">
# [21:30] * Quits: TabAtkins_ (tabatkins@63.245.220.224) (Ping timeout)
# [21:44] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
# [21:51] * Joins: glazou (glazou@63.245.220.224)
# [22:02] * Quits: glazou (glazou@63.245.220.224) (Quit: glazou)
# [22:03] * Quits: macpherson (macpherson@63.245.220.224) (Quit: macpherson)
# [22:05] * Quits: Kazutaka (yamamoto_k@63.245.220.224) (Ping timeout)
# [22:05] * Quits: shonda (shonda@63.245.220.224) (Ping timeout)
# [22:05] * Quits: hober (ted@63.245.220.224) (Ping timeout)
# [22:05] * Quits: dbaron (dbaron@63.245.220.240) (Ping timeout)
# [22:07] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
# [22:07] * Quits: szilles (chatzilla@63.245.220.224) (Ping timeout)
# [22:10] * Joins: hober (ted@63.245.220.224)
# [22:13] * Joins: dbaron (dbaron@63.245.220.240)
# [22:15] * Joins: howcome (howcome@63.245.220.224)
# [22:29] * Joins: smfr (smfr@63.245.220.224)
# [22:38] * Quits: howcome (howcome@63.245.220.224) (Ping timeout)
# [22:40] * Quits: Ms2ger (Ms2ger@91.181.2.129) (Quit: nn)
# [22:50] * Quits: hober (ted@63.245.220.224) (Quit: ERC Version 5.3 (IRC client for Emacs))
# [22:53] * Quits: Jay (jay@63.245.220.224) (Connection reset by peer)
# [22:58] * Joins: macpherson (macpherson@63.245.220.224)
# [22:58] <Bert> (About sending to www-style, as Tab recommended: www-style was the busiest mailing list in W3C in 2010. Only public-html gets close...)
# [22:58] * Quits: macpherson (macpherson@63.245.220.224) (Client exited)
# [22:59] * Joins: plinss_ (plinss@63.245.220.224)
# [22:59] * Joins: macpherson (macpherson@74.125.122.49)
# [23:00] * Joins: glazou (glazou@63.245.220.224)
# [23:02] * Joins: bradk (bradk@63.245.220.224)
# [23:03] * Joins: hober (ted@174.143.153.77)
# [23:04] <fantasai> Topic: CSS2.1
# [23:05] <plinss_> http://wiki.csswg.org/spec/css2.1#issue-242
# [23:05] * Joins: Jay (jay@63.245.220.224)
# [23:06] <plinss_> http://lists.w3.org/Archives/Public/www-style/2011Mar/0179.html
# [23:06] * Joins: TabAtkins_ (tabatkins@63.245.220.224)
# [23:06] * Joins: Kazutaka (yamamoto_k@63.245.220.224)
# [23:07] <fantasai> "(es) (even if either side is empty)
# [23:07] <fantasai> "
# [23:07] * Joins: arno1 (arno@192.150.10.200)
# [23:07] * Quits: dsinger (dsinger@17.72.146.124) (Ping timeout)
# [23:08] <dbaron> (and any block-level siblings that are consecutive or separated by only ignorable whitespace or out-of-flow elements)
# [23:09] <dbaron> probably s/by only/only by/
# [23:09] <fantasai> s#or#and/or#
# [23:09] <fantasai> :)
# [23:10] * Quits: arno (arno@192.150.10.200) (Ping timeout)
# [23:10] <dbaron> are broken around the block-level box (and any block-level siblings that are consecutive or separated only by ignorable whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box.
# [23:11] <dbaron> are broken around the block-level box (and any block-level siblings that are consecutive or separated only by collapsible whitespace and/or out-of-flow elements), splitting the inline box into two boxes (even if either side is empty), one on each side of the block-level box.
# [23:11] <fantasai> RESOLVED: proposal above accepted
# [23:13] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-243http://lists.w3.org/Archives/Public/www-style/2011Mar/0180.html
# [23:13] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-243
# [23:13] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Mar/0180.html
# [23:15] <fantasai> RESOLVED: Proposal accepted.
# [23:16] <fantasai> http://wiki.csswg.org/spec/css2.1#issue-227
# [23:17] * Quits: jdaggett (jdaggett@63.245.220.224) (Connection reset by peer)
# [23:17] <fantasai> RESOLVED: fix error
# [23:17] * Joins: jdaggett (jdaggett@63.245.220.224)
# [23:18] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-238
# [23:20] <fantasai> RESOLVED: defer to CSS3 Fonts
# [23:20] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-246
# [23:22] <fantasai> RESOLVED: defer to css3
# [23:22] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-249
# [23:25] <fantasai> RESOLVED: next editorial revision
# [23:25] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-251
# [23:25] <fantasai> RESOLVED: errata
# [23:25] <dbaron> http://wiki.csswg.org/spec/css2.1#issue-258
# [23:26] <fantasai> RESOLVED: Add note
# [23:27] <fantasai> s/add/revise/
# [23:28] <fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0074.html
# [23:29] <plinss_> Note that COMMENT tokens cannot occur within other tokens:
# [23:29] <plinss_> thus, "url(/*x*/pic.png)" denotes the URI "/*x*/pic.png",
# [23:29] <plinss_> not "pic.png".
# [23:29] <fantasai> CSS2.1 issues all resolved.
# [23:29] <fantasai> s/issues/LC issues/
# [23:29] * Joins: sylvaing (sylvaing@63.245.220.224)
# [23:29] <johnjan> w00t
# [23:30] <fantasai> plinss: Next is responding to all these emails and writing the disposition of comments
# [23:30] <johnjan> Arron has one test case to discuss. IT's the last one though.
# [23:31] <fantasai> block-in-inline-relpos-000
# [23:31] <Arron> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/block-in-inline-relpos-002.htm
# [23:32] <dbaron> When an inline box contains an in-flow block-level box, the inline box (and its inline ancestors within the same line box) are broken around the block-level box, dividing the inline box into two pieces (even if either side is empty). The line boxes before the break and after the break are enclosed in anonymous block boxes, and the block-level box becomes a sibling of those anonymous boxes. When such an inline box is affected by relative positioning, the relati
# [23:32] <dbaron> ve positioning also affects the block-level box contained in the inline box.
# [23:32] <dbaron> in 9.2.1.1
# [23:40] <fantasai> discussion of block-in-inline-relpos-002 and why it's failing and on which impls its failing
# [23:41] * Quits: homata_ (homata_@58.158.182.50) (Client exited)
# [23:41] * Joins: homata_ (homata_@58.158.182.50)
# [23:43] <fantasai> Arron: Opera and WebKit fail because they don't move the block at all
# [23:43] <fantasai> Arron: IE moves the floats
# [23:47] <fantasai> dbaron and arron investigate
# [23:48] <fantasai> fantasai thinks we should just make it undefined, and then spec whatever we have interop on later
# [23:48] <hyatt> that's hard in webkit
# [23:48] <hyatt> for our implementation to do
# [23:48] <hyatt> since the block isn't contained inside the inline from a tree perspective
# [23:49] <hyatt> so we lose the knowledge of the relative positioning
# [23:49] <hyatt> other things won't work either like opacity
# [23:49] <hyatt> i don't know maybe other browsers just hacked only relpositioning to work
# [23:49] <hyatt> and didn't handle cases like opacity
# [23:49] * Joins: shonda (shonda@63.245.220.224)
# [23:50] <fantasai> fantasai: Let's make whether floats inside the relpos are translated be undefined
# [23:51] * Quits: bradk (bradk@63.245.220.224) (Quit: Computer has gone to sleep)
# [23:52] <fantasai> ...
# [23:53] <fantasai> dbaron: This might be the only test in the test suite that's testing this other really important concept that FF3.6 got wrong
# [23:53] <fantasai> dbaron: Concept that if you have inlines, block, inlines, block, inlines you do two splits
# [23:53] <johnjan> if we edited the test to only be that one part, would there be two passes?
# [23:55] <fantasai> fantasai: This test uses out-of-flows, not inlines, in the middle of that sandwich
# [23:56] <fantasai> dbaron: So the clarifying edit we made earlier this morning makes this testcase invalid
# [23:57] <fantasai> fantasai: Didn't you change this testcase, it was originally matching the other interpretation
# [23:58] <Arron> http://test.csswg.org/suites/css2.1/20110111/html4/block-in-inline-relpos-002.htm
# [23:58] <fantasai> Arron: We have two passes on the old version of the test
# [23:59] <fantasai> fantasai: dbaron, wrt our implementation, when bz and I split nsBlockFrame, changing this behavior call fall out of that refactoring. I don't think it will be hard.
# [23:59] <fantasai> RESOLVED: Revert test, no changes to spec for block-in-inline-relpos
# Session Close: Thu Mar 10 00:00:00 2011

The end :)