/irc-logs / w3c / #css / 2013-06-06 / end

Options:

# Session Start: Thu Jun 06 00:00:00 2013
# Session Ident: #css
# [00:07] * Joins: r12a (rishida@public.cloak)
# [00:19] * Quits: rhauck (~Adium@public.cloak) (Client closed connection)
# [00:24] * Joins: glenn (~gadams@public.cloak)
# [00:26] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [00:33] * Joins: sgalineau (~sgalineau@public.cloak)
# [00:37] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [00:46] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [00:47] * Joins: Tav (~tbah@public.cloak)
# [01:01] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [01:13] * Joins: SimonSapin (~simon@public.cloak)
# [01:24] * Quits: Tav (~tbah@public.cloak) ("Leaving")
# [01:24] * Joins: Tav (~tbah@public.cloak)
# [01:24] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [01:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [01:36] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [01:51] * Joins: dbaron (~dbaron@public.cloak)
# [01:52] * Joins: glenn (~gadams@public.cloak)
# [01:58] * Joins: krit (~krit@public.cloak)
# [01:59] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [02:01] * Joins: Kazutaka (~Kazutaka@public.cloak)
# [02:01] * Joins: Rossen (~Rossen@public.cloak)
# [02:03] * Joins: lmclister (~lmclister@public.cloak)
# [02:03] * Joins: cabanier (~cabanier@public.cloak)
# [02:07] * Joins: myakura (~myakura@public.cloak)
# [02:09] * dbaron RRSAgent, pointer?
# [02:09] * RRSAgent See http://www.w3.org/2013/06/06-css-irc#T00-07-04
# [02:09] <dbaron> trackbot, start meeting
# [02:09] * Quits: darktears (~darktears@public.cloak) (Client closed connection)
# [02:09] * trackbot is preparing a teleconference.
# [02:09] <trackbot> RRSAgent, make logs member
# [02:09] <RRSAgent> I have made the request, trackbot
# [02:09] * Joins: Zakim (zakim@public.cloak)
# [02:09] <trackbot> Zakim, this will be Style_CSS FP
# [02:09] <trackbot> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
# [02:09] <trackbot> Date: 06 June 2013
# [02:09] <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
# [02:09] <dbaron> Zakim, remind us in 9 hours to go home
# [02:09] <Zakim> ok, dbaron
# [02:09] * Joins: rhauck (~Adium@public.cloak)
# [02:10] <dbaron> RRSAgent, make logs public
# [02:10] <RRSAgent> I have made the request, dbaron
# [02:11] <dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Face-to-Face, Tokyo, Japan
# [02:11] * Joins: SimonSapin (~simon@public.cloak)
# [02:12] * Joins: glazou (~glazou@public.cloak)
# [02:14] * dbaron wonders if anyone (jdaggett?) needs a phone connection today
# [02:14] * Joins: ivan (ivan@public.cloak)
# [02:14] * jdaggett i'm okay for this morning
# [02:14] <jdaggett> but yes please for this afternoon
# [02:15] * heycam|away is now known as heycam
# [02:17] <fantasai> ScribeNick: fantasai
# [02:17] * Joins: plh (plehegar@public.cloak)
# [02:17] * Joins: leif (~lastorset@public.cloak)
# [02:18] * sgalineau so how many tables and chairs showed up today?
# [02:18] <fantasai> Round of intros
# [02:19] <fantasai> plh, W3C
# [02:19] <fantasai> fantasai, Mozilla
# [02:19] <plh> Slides: http://www.w3.org/2013/Talks/0606-css-plh/#/
# [02:19] <fantasai> Ivan Herman, W3C
# [02:19] <fantasai> glazou, Disruptive Innovations, csswg co-chair
# [02:19] <fantasai> Simon Sapin, Mozilla
# [02:19] <fantasai> Jet Villegas, Mozilla
# [02:19] <fantasai> Rossen Atanassov, Microsoft
# [02:19] <fantasai> Alan Stearns, Adobe
# [02:19] <fantasai> whatever, scribe gives up
# [02:20] * Joins: rhauck1 (~Adium@public.cloak)
# [02:20] <glazou> lol
# [02:20] <fantasai> plinss: jdaggett can't be here this morning, ishida can't be here this afternoon
# [02:20] * jdaggett and there I was about to be amazed that you could spell everyone's name correctly on the fly...
# [02:21] * fantasai does have to fill in the attendance list every week, so spelling is not so much the problem for our regulars ;)
# [02:21] * Joins: jdovey (~jdovey@public.cloak)
# [02:21] <fantasai> Topic: CSSWG Priorities
# [02:21] <fantasai> plh projects title slide
# [02:22] <fantasai> next slides lists RECs and dates
# [02:22] <jdaggett> link?
# [02:22] <plh> http://www.w3.org/2013/Talks/0606-css-plh/#/
# [02:22] <jdaggett> thx
# [02:22] <fantasai> plh: Only 6 RECs
# [02:23] <fantasai> Last 12 months: 1 REC (MQ), 2 CRS (flexbox, conditional rules)
# [02:23] <fantasai> 18 WDs updated
# [02:23] <fantasai> FPWD x 5
# [02:23] * Joins: liam (liam@public.cloak)
# [02:23] <fantasai> Bugs: last 12 months
# [02:23] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [02:24] <fantasai> plh: Huge controversy over these, staring with Opera suggesting to remove prefixes
# [02:24] <fantasai> Transforms, bugs from 11 to 6
# [02:24] * Joins: shans__ (~shans@public.cloak)
# [02:24] <fantasai> transitions from 29 to 25
# [02:24] <fantasai> animations from 45 to 20
# [02:24] <fantasai> glazou corrects the record
# [02:24] * sgalineau yay Animations!
# [02:24] <dbaron> Present: Phillipe Le Hegaret (W3C), Elika Etemad (Mozilla), Ivan Herman (W3C), Daniel Glazman (Disuptive Innovations), Simon Sapin (Mozilla), Jet Villegas (Mozilla), Rebecca Hauck (Adobe), Rossen Atanassov (Microsoft), Larry MacLister (Adobe), Alan Stearns (Adobe), Israel Noto (Adobe), Dean Jackson (Apple), Dirk Schultze (Adobe), Rik Cabanier (Adobe), Masataka Yakura, Leif Arne Storset (Opera), Kazutaka Yamamoto(NTT), Koji Ishii (Rakuten), Liam Quin (W3C), Just
# [02:24] <dbaron> in Erenkrantz (Bloomberg), Cameron MacCormack (Mozilla), Shane Stevens (Google), Jim Dovey (Kobo), Bert Bos (W3C), Richard Ishida (W3C), Peter Linss (HP), David Baron (Mozilla), Glenn Adams (Cox), Tab Atkins (Google)
# [02:24] <fantasai> plh: Decided to move faster, but this is the result
# [02:24] <fantasai> plh: Only 5 bugs fixed for Transforms, 4 for Transitions, 25 for Animations
# [02:24] * glazou polishes his ax to fight plh
# [02:24] <fantasai> plh: Animations is more than 50% better
# [02:25] <fantasai> dbaron: some metrics are a little funny. Went through bugs, most deferred to next level
# [02:25] * sgalineau would disagree with this statement
# [02:25] <fantasai> plh: Why not in LC?
# [02:25] <fantasai> dbaron: Because 2 left
# [02:25] * sgalineau all bugs are not equal; some of the animations bugs left are still around because they're hard
# [02:26] <fantasai> plh: Fact is, drafts still not in LC despite controversylast year
# [02:26] <fantasai> plh: If we look at priorities from December 2011, these are top 3 drafts: css3-background, css3-ui, css3-values
# [02:26] <fantasai> plh: Still in this cycle
# [02:26] <fantasai> plh: Think css3-background still held up on implementation issues and tests
# [02:26] <fantasai> plh: css3-ui went backwards rather than forwad
# [02:26] <fantasai> plh: css3-values went forward
# [02:26] <fantasai> plh: One metric, not only one
# [02:27] <fantasai> plh: Last fall, CSS chairs committed a survey
# [02:27] <fantasai> plh: In terms of priorities, top 5 were flexbox, transforms, animations, conditional rules, transitions
# [02:28] <fantasai> plh: Coremob profile
# [02:28] <fantasai> plh: CSS2.1, MQ, Selectors 3, Color, Flexbox, Transforms, Animations, Transitions, CSS3 Text, CSS3 Fonts, CSS3-backgrounds and Borders, CSS3 Images, CSS3 Values, CSS Device Adaptation, CSSOM
# [02:29] <fantasai> plh: Normative references HTML5.0
# [02:29] <fantasai> plh: Fonts, Images, Values, Selectors 4, CSSOM, CSSOM View, css3-ui, Style Attr, Fullscreen (?)
# [02:32] <fantasai> plh: Some of this can be tweaked
# [02:32] <fantasai> plh: But some, e.g. View Module, can't break the dependency
# [02:32] <fantasai> plh: Style Attributes
# [02:32] <fantasai> fantasai: Style Attributes stuck on one failed test
# [02:32] <fantasai> plh: Is it important test?
# [02:32] <fantasai> fantasai: No.
# [02:32] <fantasai> plh: Then send a PR request soon
# [02:33] <fantasai> glazou: Whatever you do, browser vendors will implement and ship it. What's the point of breaking the dependency?
# [02:33] <fantasai> glazou: Browser vendors will implement, ship, try for workable interop, and the spec describing the behavior of the current market will not be available
# [02:33] <fantasai> glazou: I find it a little bit sad
# [02:33] <fantasai> glazou: We had this discussion in AC form, chairs, wrt what is a normative reference
# [02:34] <fantasai> glazou: I said a spec like HTML5, which is based on living standard, needs an intermediate status between informative and normative
# [02:34] <fantasai> glazou: That is another way of solving your issue
# [02:34] <fantasai> glazou: If I take that list, to finish everything including tests, is enough work for this WG for the entire year
# [02:34] <fantasai> glazou: You want us to do everything by 2014?
# [02:35] <fantasai> glazou: Each member of this WG has individual strategy and priority. if I read your slides, I think you forget it.
# [02:35] <fantasai> dbaron: Another problem is that REC track doesn't reflect how industry really works
# [02:35] <fantasai> dbaron: Talk of reforming REC track for a while
# [02:35] <fantasai> plh: Several ways to approach this. One is to remove dependencies from HTml5
# [02:36] * sgalineau accepts blame for underestimating remaining animations work.
# [02:36] <fantasai> plh: Third question is what does it mean to be normative ref for HTML5
# [02:36] <fantasai> plh: Some of those references, perhaps part referenced by HTMl5 is perfectly stable and implemented
# [02:36] * Joins: Koji (~Koji@public.cloak)
# [02:37] <glazou> sgalineau, let me get the lash
# [02:37] <fantasai> fantasai: you could solve most of this is to allow REC to normatively reference CR, treating PR like transitional phase just like LC.
# [02:37] <fantasai> fantasai: This is relatively minor change to the process, would solve the problem.
# [02:37] <fantasai> plh talks about stability
# [02:38] <fantasai> dbaron: This is a discussion in the TAG list
# [02:38] <fantasai> dbaron: I think the way W3C manages normative references is broken
# [02:38] * sgalineau glazou, i accept blame but it's not like i did nothing either. same for dbaron. i think we made a decent effort to pick those back up from where they were….it sounds like we were lazy or something
# [02:38] <fantasai> plh: Do believe this has process problems
# [02:38] <glazou> sgalineau, sure :-)
# [02:38] <fantasai> plh: If I look at F2F agenda, this is list of things that were on the agenda
# [02:38] <glazou> sylvaing, and I will make sure plh understands that, no worries
# [02:39] <fantasai> plh projects some questions
# [02:39] <fantasai> 1. Are we getting the right balance between day-to-day borwser implementers needs and what's needed?
# [02:40] <fantasai> 2. What's happening with Fall 2012 Priorities?
# [02:40] <fantasai> 3. Will CSS prevent HTML5 from moving to REC by 2014?
# [02:40] <fantasai> 4. What is WG expectation for its next Charter?
# [02:40] <fantasai> plh: Last, main question we have,
# [02:40] <fantasai> plh: This group needs to be rechartered, what's the expecations?
# [02:41] <fantasai> glazou: First one, you should define better what's needed. What's needed for who? This WG? Other WGs? The Press? I don't care about the Press. We make technology for billions of people. I don't care about their opinion. We should make sure everythign works.
# [02:41] <fantasai> plh: browser vendors are the deciders in this WG
# [02:41] <fantasai> s/plh/glazou/
# [02:42] <fantasai> glenn: We have input from others
# [02:42] <fantasai> TabAtkins: input, yes, but ultimately what browsers implement is what we spec
# [02:42] <fantasai> glazou: 2nd point, TTA and Flexbox were highest priorities during most of our conference calls during 12 last months
# [02:42] <fantasai> plh: Only 6 bugs?
# [02:42] <fantasai> glazou: Do you have any idea how complex these bugs are?
# [02:43] <fantasai> glazou: Take a look. Don't rant.
# [02:43] <fantasai> glazou: 3rd point, well, the day the HTMLWG pings us to tell us they need that spec to be a REC, maybe it will change
# [02:43] <fantasai> glazou: I told HTMLWG and W3C more than a year ago that we have problems with normative refs of HTML5. No response.
# [02:43] <fantasai> glazou: WG expectation, I don't know. We did not discuss next charter yet
# [02:43] * stearns notes that the interaction between TTA and !important was a big topic yesterday
# [02:43] <fantasai> glazou: Mine is to reduce the nubmer of specs we're working on
# [02:44] <fantasai> glazou: Priorities can change a lot, and strategies can change a lot, over 2 years.
# [02:44] <fantasai> glazou: E.g. Firefox was not in mobile space before. now they are working a lot on apis
# [02:44] <fantasai> glazou: If I knew what was going to happen in CSS world 2 years from now, would be billionnaire
# [02:44] <fantasai> glazou: So, do some cleanup, try to serve best CSS and the Web, help the HTMLWG if we can. But don't know if we can solve everything.
# [02:45] <fantasai> glazou: Date of 2014 has been set by HTMLWG without looking at the dependencies.
# [02:45] <fantasai> glazou: After choosing date, look at dependencies. It is not fair.
# [02:45] <fantasai> TabAtkins: Even if we ignore dependencies, there is no way HTML5 can hit REC in 2014 without bending rules.
# [02:45] <fantasai> TabAtkins: You're going to need like a million tests. it's not going to happen in 1.5 years.
# [02:45] <fantasai> glazou: They lowered expectations.
# [02:46] <fantasai> TabAtkins: By honestly reaching REC like everyone else does, will need to lower what it means to be REC.
# [02:46] <fantasai> TabAtkins: Doesn't make a difference if we are a process-holdup. They have a process-holdup anyway.
# [02:47] <fantasai> glenn: I don't agree with Daniel's characterization of how this group should work. Should take into account people who are using our specs, including ppl who normatively reference our specs.
# [02:47] <fantasai> glenn: Think it's impractical perspective
# [02:47] <fantasai> glenn: Would encourage us to not take that we work in a vacuum
# [02:48] <fantasai> glenn: Of course, since volunteer activity, depends on people putting their energy into specs customers care about. Should request customers to bring resources to WG if what we do isn't funded.
# [02:48] <fantasai> glazou: One of the largest users is Ebooks. And we have an acceptable cooperation with IDPF
# [02:48] <fantasai> glazou: I think not perfect, but acceptable cooperation.
# [02:48] <fantasai> glazou: They send us requests, they discuss CSS on their group.
# [02:49] <fantasai> Bert: You and I are working on it, but not rest of WG
# [02:49] <fantasai> [discussion of css3-page, css4-page]
# [02:49] <fantasai> glazou: Where is HTMLWG to discuss with us their needs?
# [02:49] <fantasai> glenn: Problem is communication
# [02:50] <fantasai> glenn: I find it easier to ping users, outside W3C, than to ping some other committees.
# [02:50] <fantasai> s/glenn/glazou/
# [02:52] <fantasai> [discussion about cross-wg communication and HTML5 date]
# [02:52] <fantasai> plh: If you tell me none of those specs reach REC by 2014, that's one kind of input
# [02:53] <fantasai> ...
# [02:53] <fantasai> dbaron: Why do members care about pushing to REC?
# [02:53] <fantasai> dbaron: Doesn't have any benefit for us
# [02:54] <fantasai> ...
# [02:54] <fantasai> TabAtkins: REC and interop don't have a strong correlation
# [02:54] <fantasai> plh: That's one reason, other people have other reasons
# [02:54] <fantasai> dbaron: It's the reason why people here do the work.
# [02:55] <fantasai> plh: You're trying to get the documents perfect before REC. You won't get there.
# [02:55] <fantasai> glazou: Documents that don't move now are blocked on difficult technical issues (other than style attr)
# [02:55] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [02:55] <fantasai> glazou: Open issues for TTA are really complex
# [02:56] * Quits: myakura (~myakura@public.cloak) ("http://www.kiwiirc.com/ - A hand crafted IRC client")
# [02:56] <fantasai> glazou: Question of availability of people. Only a few experts on each topic.
# [02:56] <fantasai> glazou: Even if a large group, made of subgroups. You seem to forget that.
# [02:56] <jdaggett> i do think we lack the ability to prioritize some specs
# [02:57] <jdaggett> we seem to work as a group on whatever individual members are interested in working on
# [02:57] <fantasai> Bert: Why don't we finish things we promised to finish 5 years ago?
# [02:57] <fantasai> glazou: Ask them! (gestures to WG)
# [02:58] <jdaggett> and that effectively crowds out work on other things
# [02:58] <fantasai> ...
# [02:58] <fantasai> TabAtkins: Can't go to PR without testing everything in the spec
# [02:58] * Joins: myakura (~480ee730@public.cloak)
# [02:58] <fantasai> glenn: No, don't need to test everything in the spec
# [02:58] <fantasai> TabAtkins: Then I have no idea what you mean by test suite.
# [02:59] <fantasai> plh: I've never seen browser vendor that has full test suite for everything they implement
# [02:59] <jdaggett> why don't you need to test what's in the spec?!? that makes no sense
# [02:59] <fantasai> ...
# [02:59] <fantasai> dbaron: Philippe admits that REC doesn't need to be perfect
# [03:00] <jdaggett> existing browsers have lots of legacy stuff
# [03:00] <fantasai> dbaron: One problem we have with process is that we want to maintain specs, and continue to maintain them as ppl bring up issues
# [03:00] <fantasai> dbaron: Problem with process is that it's much harder to update a REC
# [03:00] <jdaggett> but the quality of testing efforts is vastly improved over the past five years
# [03:00] <fantasai> plh: Don't see why
# [03:01] * TabAtkins jdaggett, should we have you called in?
# [03:01] <fantasai> plh: Just need to have a test for each change
# [03:01] <fantasai> plh: You are setting a bar for REC that is way too high
# [03:01] <fantasai> dbaron: You act as though publishing a doc is trivial thing
# [03:01] * jdaggett TabAtkins, no i'm cool...
# [03:01] <fantasai> dbaron: Publishing CR requires editor to spend days pinging various people for permission
# [03:01] * TabAtkins kk. We have the process worked out now. ^_^
# [03:01] <fantasai> dbaron: It's not worht a week of my time to get document published on /TR
# [03:02] <fantasai> glazou: Pages of spec:
# [03:02] <fantasai> 12 pages for CSS1
# [03:02] <fantasai> 258 for CSS21
# [03:02] <fantasai> 4000 for CSS3
# [03:03] <fantasai> glazou: It's a lot of work
# [03:03] <fantasai> Bert: Seems like we always want things to be in flux
# [03:04] <fantasai> TabAtkins: Want to always be refinining / correcting things.
# [03:04] <fantasai> TabAtkins: 100% stability is an illusion
# [03:04] <fantasai> [discussion of bureaucracy]
# [03:04] <fantasai> [and how to allocate resources to it]
# [03:06] <fantasai> glazou: 2 passing implementations for each testable assertion
# [03:06] <fantasai> glazou: That's the way it should be. Otherwise test suite has no value.
# [03:06] <fantasai> glazou: I understand HTML5 has different requirements. And I agree with Tab that that test suite has no value. It's just marketing.
# [03:06] <fantasai> /just/pure/
# [03:07] <fantasai> ...
# [03:07] <fantasai> jet: Sounds like W3C wants REC documents
# [03:08] <fantasai> jet: Group says cost to REC is too high, and CR is good enough
# [03:08] <fantasai> jet: Perhaps the product expected of this group should change
# [03:08] <fantasai> plh: If I go to AC and say CR is the new REC, AC will not happy
# [03:09] <fantasai> Bert: We used to have no testing requirement
# [03:09] <fantasai> Bert: process changed
# [03:09] <fantasai> glazou: So process can change. These people are telling you process needs to change.
# [03:10] <fantasai> plh: You're saying we should have no test suite requirement, other say they want more testing requirement
# [03:12] <fantasai> ..
# [03:12] <fantasai> glazou: HTML has lower expectation because want to release fast, because marketing impact and press, releasing HTML5
# [03:12] <dbaron> LC of css3-conditional took 28 days from publication request (November 15) to publication (December 13)
# [03:12] <dbaron> so it's not just CRs
# [03:12] <fantasai> glazou: You lowered the bar to meet that date
# [03:12] <fantasai> dbaron, that was largely because I didn't notice that the document wasn't published when it was requested to be published
# [03:12] <fantasai> dbaron, and so wasn't able to follow up and get it published the next day
# [03:12] <fantasai> ...
# [03:13] <fantasai> jdovey describes IDPF process, which is fast and loose
# [03:13] <dbaron> it didn't help that there was a 5 day delay from 15th to when it was supposed to be published, and then a week from noticing that it wasn't published to it actually being published
# [03:14] <fantasai> liam: Pragmatic, and on programming end pragmatism is imporant. But e.g. governmental standards requirements are different
# [03:14] * Joins: isra (~inoto@public.cloak)
# [03:14] * sgalineau my mom told me to watch out for fast and loose standard orgs
# [03:14] <fantasai> glazou: These 4 questions
# [03:14] <fantasai> glazou: To answer these 4 questions, we need to know what you want.
# [03:14] <fantasai> glazou: What does W3M want about the priorities?
# [03:14] <fantasai> glazou: What do you think we should do wrt dependencies
# [03:14] <fantasai> dbaron: Why does W3M have to make those decisions
# [03:15] <fantasai> glazou: Don't say they make decisions, just want their input.
# [03:15] <fantasai> plh: ...
# [03:16] <fantasai> r12a: IDPF has been really keen on vertical text and ruby
# [03:16] <fantasai> r12a: Ruby CSS module is way off the bottom of the scale in terms of work being done
# [03:16] <fantasai> r12a: I know that's partly because ppl don't ahve time to work on it
# [03:16] <fantasai> r12a: But what's the process the WG has, for discussing with IDPF, and allowing them to raise what they want
# [03:16] <fantasai> glazou: Question I discussed with Markus Gylling
# [03:16] <fantasai> glazou: We don't have a real process
# [03:17] <fantasai> glazou: We discuss technical issues sometimes, but not really how can we answer, address improtant requests from their point of view.
# [03:17] <fantasai> glazou: E.g. ruby, which is best example
# [03:17] <fantasai> glazou: We have no one
# [03:17] <fantasai> glazou: When we tell them we have no resources to work on that right now, they say they'll wait. Members unwilling ot join this group
# [03:18] <fantasai> ivan: digital publishing interest group ...
# [03:18] <fantasai> ivan: Not chartered to develop sepcs, but may come up with priorities and requirements, and maybe find ppl to do the work here.
# [03:18] <fantasai> r12a: What is the process for CSSWG for re-evaluating priorities and discussing stakeholder requirements?
# [03:20] <fantasai> ...
# [03:21] <fantasai> dbaron: Need to communicate that we don't have resources, and let them work on it if they want to put those resources in.
# [03:21] <fantasai> Bert: ...
# [03:21] <fantasai> glazou: Strategy of the market changes
# [03:21] <fantasai> Ivan: Whole issue of membership fee etc.
# [03:21] <fantasai> Ivan: Let's say 3-4 ppl form task group within this wg to develop technolgy XYZ
# [03:21] <fantasai> Ivan: Do you have structure of task forces?
# [03:22] <fantasai> Ivan: What's the decision procedure?
# [03:22] <fantasai> glazou: We have FXTF with SVGWG
# [03:22] <fantasai> Ivan: Can they work on it and push to REC?
# [03:22] <fantasai> glazou: Sure
# [03:23] <fantasai> jdovey: What happens if TF comes back to WG and 80% WG says they don't like it?
# [03:23] <jdaggett> um, i don't think task forces are magic, you need people capable of actual tackling issues with developing something
# [03:23] <fantasai> dbaron: Need to get feedback earlier
# [03:23] * fantasai agrees with jdovey
# [03:23] * fantasai meant, jdaggett there...
# [03:23] <jdaggett> the epub of coming up with a laundry list of "we needs" is actually very disruptive
# [03:23] <jdaggett> s/epub/epub way/
# [03:23] <fantasai> Ivan: We have a community not browser vendors, willing to do work, will they be shot down because browsers don't care?
# [03:23] <Bert> s/Bert: .../Bert: Daniel and David refer to new requirements that we don't have resources for. But in many cases people are just waiting for things that we already had in our charter./
# [03:24] <fantasai> dbaron: If you have a need for something in 6 monts, but don't care about quality for stability of long term, that's an issue
# [03:24] <fantasai> jdovey: talks about implementing ? in WebKit and politicking and sitting on the patch and stuff.
# [03:25] <fantasai> jdovey: We keep running into roadblocks
# [03:25] <fantasai> dbaron: I think you can't say you want something in 6 months and then not put the work into it
# [03:25] <fantasai> dbaron: to really do it right
# [03:25] <jdaggett> maybe because shoving code for a feature into webkit before ironing out the spec is not a constructive approach...!
# [03:25] <fantasai> dbaron: Having a patch in WebKit is different from having a standard that can be interoperably implemented and everyone agrees with
# [03:25] <fantasai> jdovey talks about JLREQ requirements
# [03:26] <fantasai> and trying to implement those
# [03:26] <fantasai> jdovey: [..., ruby, ...]
# [03:26] <fantasai> dbaron: Don't see how you can implement a requirements document.
# [03:26] <fantasai> dbaron: If you want a technical spec, need to describe what the technology is
# [03:27] <fantasai> jdovey: Desribes how characters should be laid out
# [03:27] <fantasai> dbaron: Gives requirements, not a model
# [03:27] <jdaggett> and you have to make that fit into existing features!!!!!!!!!!!!!!!!!
# [03:27] <fantasai> plh: Current charter is coming to expiration
# [03:27] <jdaggett> example: webkit's crazy two-path text handling structure
# [03:27] <fantasai> plh: Could say, perfectly happy way we are working
# [03:28] <fantasai> plh: You guys are doing the work
# [03:28] <fantasai> plh: I cannot just say, this is what you will do, you have no choice. You'll walk away if I do that.
# [03:28] * Joins: SimonSapin1 (~simon@public.cloak)
# [03:28] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [03:28] <fantasai> plh: Think you need to figure out what you need to achieve
# [03:28] * SimonSapin1 is now known as SimonSapin
# [03:28] <fantasai> s/need/want/
# [03:29] <fantasai> plh: If the group's believe they're doing what they want to achieve, and AC doesn't agree, then AC has to figure out how to appoint to the WG
# [03:29] <fantasai> dbaron: he's talking about how WG members are appointed by their AC reps
# [03:29] <fantasai> dbaron: Which is mostly an administrative fiction
# [03:29] <fantasai> plh: Ok, I don't want to hold this group further. You guys have work to do
# [03:30] <dbaron> <br duration="900s">
# [03:30] <fantasai> dino: what was the point of this discussion?
# [03:30] <fantasai> dino: Not trying to be rude, really want to know
# [03:31] <fantasai> plh: Just wantto make sure you understand what you're doing and are happy with how you're operating
# [03:31] <fantasai> plh: And if ppl come to me with complaints, I will rediret them to you saying your'e doing this intentionally :)
# [03:33] * Quits: isra (~inoto@public.cloak) ("Leaving.")
# [03:33] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [03:34] * Joins: cabanier (~cabanier@public.cloak)
# [03:35] <jdaggett> i think lots of folks will always be dissatisfied because their individual feature request isn't satisfied
# [03:35] * TabAtkins dbaron, you'll probably like this: http://www.businessinsider.com/22-maps-that-show-the-deepest-linguistic-conflicts-in-america-2013-6
# [03:35] <jdaggett> しょがない
# [03:37] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [03:37] <dbaron> Present+ Thierry Michel
# [03:48] * Joins: Rossen (~Rossen@public.cloak)
# [03:52] * krit TabAtkins is having fun with practical <replicate>
# [03:55] <glazou> http://www.quickmeme.com/meme/3uqllg/
# [03:56] <glazou> sylvaing, please upload the URL above to w3cmemes
# [03:57] * Joins: isra (~inoto@public.cloak)
# [04:01] <fantasai> Topic: Syntax
# [04:01] <fantasai> TabAtkins: Rewriting from grammar approach to parser approach
# [04:01] <jerenkrantz> http://dev.w3.org/csswg/css-syntax/
# [04:01] <fantasai> TabAtkins: grammar tried to match everything, not just well-formed things, and was too complicated and didn't quite handle everything anyway
# [04:02] <fantasai> TabAtkins: Tokenizer, then Parser
# [04:02] <fantasai> TabAtkins: Includes hooks for other specs to include a certain type of thing
# [04:02] <fantasai> TabAtkins: I would like to review some things with group, then ask for FPWD
# [04:02] <fantasai> TabAtkins: Probably as correct as 2.1 at this point
# [04:03] <fantasai> TabAtkins: WebKit uses augmented grammar to parse, and it's horribly broken.
# [04:03] <fantasai> TabAtkins: Wanted to go over changes from 2.1
# [04:03] <fantasai> TabAtkins: First batch of changes are about parsing
# [04:04] <fantasai> TabAtkins: 2.1 defined some interesting rules for detecting @charset
# [04:04] <fantasai> TabAtkins: Brought into line with charset handlign in rest of platform
# [04:04] <dbaron> we're reviewing http://dev.w3.org/csswg/css-syntax/#changes as of 4ce7b66b553a
# [04:04] <fantasai> r12a: Does that mean it doesn't handle UTF16
# [04:05] <fantasai> TabAtkins: Can use UTF16 by having BOM, but won't recognize @charset
# [04:05] <fantasai> fantasai: How interoperable is this, compared to 2.1?
# [04:05] <fantasai> TabAtkins: Dropping some obscure encodings probably ok, since implementations' don't support them
# [04:06] <fantasai> TabAtkins: Wrt web-compat, shoudl be just fine
# [04:06] <fantasai> TabAtkins: dropping things like EBCDIC
# [04:06] <fantasai> liam: Did you check for corporate intranet stuff?
# [04:06] <fantasai> TabAtkins: I think likelihood of EBCDIC is close to zero
# [04:06] <MikeSmith> RRSAgent, make mintues
# [04:06] <RRSAgent> I'm logging. I don't understand 'make mintues', MikeSmith. Try /msg RRSAgent help
# [04:06] <MikeSmith> RRSAgent, make minutes
# [04:06] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html MikeSmith
# [04:06] <fantasai> r12a: I thought same thing wrt bidi things, but ppl came back with supercomputers and stuff in Hebrew that were using old encoding systems
# [04:06] * Joins: jet (~junglecode@public.cloak)
# [04:07] <fantasai> Bert: It was there. You're trying to remove it?
# [04:07] <fantasai> TabAtkins: Browsers didn't recognize it?
# [04:07] <fantasai> Bert: You can't remove thing
# [04:07] <fantasai> Bert: This is supposed to be stable
# [04:07] <jerenkrantz> FWIW, IBM keeps ensuring that EBCDIC support is working in httpd. Someone at IBM would be able to give an idea of its reach.
# [04:08] <fantasai> Bert: We promised not to make versions to CSS, just to add things
# [04:08] <fantasai> Bert: Don't think we should remove features just because not used on the Web
# [04:08] <fantasai> Bert: Remove features when they're wrong.
# [04:09] <fantasai> [discussion of changes]
# [04:09] <fantasai> Bert: Not an argument to keep on making mistakes
# [04:09] <fantasai> r12a: When HTML5 did some charset stuff, wanted to do it to stop people using non-UTF-8
# [04:09] <fantasai> r12a: Is that your motivation?
# [04:09] <fantasai> TabAtkins: Highly sympathetic to moving to UTF-8, but main issue is making this much simpler
# [04:10] <fantasai> glazou: If all style sheets were UTF-8, would be much easier for authoring environments
# [04:10] <SimonSapin> q+
# [04:10] * Zakim sees SimonSapin on the speaker queue
# [04:11] <fantasai> dbaron: Checking for UTF-16 rules were widely tested
# [04:11] <fantasai> dbaron: We changed recently. Ran into no web-compat problems, but ran into certification problems.
# [04:11] <glazou> ack SimonSapin
# [04:11] * Zakim sees no one on the speaker queue
# [04:11] <fantasai> SimonSapin: Would like to point out that this is only about @charset. Can do anything you want with HTTP headers
# [04:12] <fantasai> SimonSapin: Also, relevant part of CSS2.1 gives a table of byte patterns. Allows UAs to remove some, or to add some
# [04:12] <fantasai> dbaron: Sorry, what I said is opposite.
# [04:12] <fantasai> dbaron: When we implemented what this draft sayse, and this caused us to start passing th GCF certification suite
# [04:13] <fantasai> dbaron: It has a test of a UTF-16 file that claims an encoding name that doesn't exist
# [04:13] <fantasai> r12a: What did you say was the first step in detecting charset?
# [04:13] <fantasai> r12a: Thought we changed so that BOM is first
# [04:14] <dbaron> the thing I was just describing was https://bugzilla.mozilla.org/show_bug.cgi?id=859706 being fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=796882
# [04:14] <fantasai> TabAtkins: BOM is checked first by decoding algorithm, before @charset
# [04:14] <fantasai> TabAtkins: this list finds the fallback encoding
# [04:15] <fantasai> ...
# [04:15] <fantasai> r12a: Do you forbid use of @charset in UTF-16 documents?
# [04:15] <fantasai> TabAtkins: No, you just ignore it
# [04:15] <dbaron> er, actually, the encoding name does exist but it's an alias for UTF-16BE, while the file is UTF-16LE
# [04:15] <fantasai> TabAtkins: Never invalid to put @charset
# [04:15] <fantasai> plh: What if UTF-16 without BOM but with @charset?
# [04:15] <fantasai> TabAtkins: Defer to encoding standard...
# [04:16] <fantasai> r12a: you can do it, but say you shouldn't
# [04:17] <fantasai> s/plh/plinss/
# [04:17] <fantasai> TabAtkins: Specifying anything other than ascii-compatible encoding is not useful
# [04:17] <fantasai> r12a: Since already defined, why not keep them?
# [04:17] <fantasai> r12a: I share bert's unease here
# [04:17] <fantasai> r12a: I agree it would be great to move to UTF-8 everywhere
# [04:18] <fantasai> TabAtkins: If implementations get bug reports on things should ask for standard to be updated
# [04:18] <fantasai> plinss: Would prefer to include this table
# [04:18] <fantasai> plinss: I know there are implementations that implement that entire table, because i made one
# [04:19] <fantasai> TabAtkins: Gecko doesn't anymore, don't think WebKit does either
# [04:19] <fantasai> dbaron: Gecko only implemented ascii-compatible cases and UTF-16 cases.
# [04:19] <glazou> WeasyPrint implements that table
# [04:19] <fantasai> dbaron: never did UTF-32 or EBCDIC
# [04:19] <fantasai> dbaron: Might've done UTF-32 long ago, but that cod eripped out a long time ago
# [04:19] <fantasai> dbaron: ripped out support for UTF-32 entirely
# [04:20] <fantasai> TabAtkins: My preferred approach is to keep it as-is right now. if there's a problem, we'll see bug reports
# [04:20] <fantasai> TabAtkins: Alter as necessary
# [04:20] <fantasai> plinss: Not really happy with that approach. Break it and see who complains?
# [04:20] <fantasai> TabAtkins: Don't want to include rows that browsers don't implement it
# [04:21] <fantasai> plinss: But some that are significant
# [04:21] * fantasai defers to dbaron on this issue
# [04:21] <fantasai> TabAtkins: Leave this in, with an issue maybe?
# [04:21] <fantasai> TabAtkins: Issue that we may need to add additional charset encoding patterns?
# [04:21] <fantasai> plinss: Maybe add onto that that we're explicitly requesting feedback on this
# [04:21] * Joins: tlr (roessler@public.cloak)
# [04:22] <SimonSapin> WeasyPrint implements part of that table because I didn’t know any better. Some cursing was involved.
# [04:22] <fantasai> plinss: Agree we probably don't need EBCDIC, and a private browser could implement that for an intranet
# [04:22] <fantasai> plinss: But more concerned wrt UTF-16 issues
# [04:22] <fantasai> plinss: Web is huge. Small percentage is still a lot of pages
# [04:22] <fantasai> TabAtkins: encoding will detect
# [04:23] <fantasai> plinss: Shouldn't be sniff it
# [04:23] <fantasai> plinss: If there's a document that doesn't have BOM and has @charset, shouldn't be sniffing it. Should use @charset
# [04:23] <fantasai> SimonSapin: Can also rely on HTTP headers
# [04:24] <fantasai> plinss: We have problems e.g. in our test suite, file sthat work on the server, but not locally
# [04:24] <fantasai> plinss: CSS should not, don't think that we require style sheet to be served over HTTP
# [04:25] <Bert> (The issue can ask which @charset lines can be deprecated.)
# [04:26] <fantasai> TabAtkins: Step 4, where you take charset from encoding document. Should that only work for same-origin?
# [04:27] <fantasai> s/4/3&4/
# [04:27] <fantasai> r12a: Value of 4 is ppl who don't understand charsets or setting http headers
# [04:28] <fantasai> ...
# [04:28] <fantasai> TabAtkins: So, take charset from referring document only if it's same-origin. Yay/nay?
# [04:28] <fantasai> TabAtkins: Ok, I'll say yes for now, object later
# [04:28] <fantasai> Bert: what's issue?
# [04:28] <fantasai> TabAtkins: Sometimes if you can force a document into a different encoding, can extract info from it
# [04:29] <fantasai> TabAtkins: This would prevent that kind of thing
# [04:29] <fantasai> Bert: What could you do with a style sheet in wrong encoding?
# [04:29] <fantasai> TabAtkins: Don't have specific example, but this kind of problem has been an issue in other technologies
# [04:30] <fantasai> Bert: But you're only changing your own document, not someone else's
# [04:30] <fantasai> dbaron: Suppose has wiki, where input CSS that shoudl be sanitized
# [04:30] <fantasai> dbaron: Could have fun encoding , maybe UTF-7 or Shift-JIS or something, that can create cross-site scripting vulnerabilities
# [04:31] <fantasai> dbaron: Encode control characters for programming languages as benign ascii chars
# [04:31] <fantasai> TabAtkins: Can't give a specific attack scenario, just know there's problems in other languages
# [04:32] * Joins: arno (~arnog@public.cloak)
# [04:32] <fantasai> Bert: Concerned about people putting stylesheet on one server, seems to work, then moves it to other server, doesn't work.
# [04:32] * liam tries to imagine a world in which there were vulnerabilities in a CMS such as Wordpress
# [04:32] <fantasai> TabAtkins: If you have a charset problem, use UTF-8
# [04:33] <dbaron> dbaron: Either way I'd prefer to leave an issue in there until we're confident it's stable.
# [04:33] <dbaron> (w.r.t. the same-origin thing)
# [04:33] <fantasai> RESOLVED: Make it same-origin, leave issue
# [04:35] <fantasai> <br type=lunch>
# [04:37] * Quits: isra (~inoto@public.cloak) ("Leaving.")
# [04:37] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [04:37] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [04:38] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [04:38] * heycam is now known as heycam|away
# [04:40] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [04:43] * Quits: leif (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [04:51] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [04:52] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [04:53] * leaverou is now known as leaverou_away
# [05:11] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [05:14] * Quits: cabanier (~cabanier@public.cloak) (Ping timeout: 180 seconds)
# [05:21] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [05:21] * Quits: jdaggett (~jdaggett@public.cloak) (Ping timeout: 180 seconds)
# [05:22] * Joins: jdaggett (~jdaggett@public.cloak)
# [05:25] <jdaggett> anyone in the room now?
# [05:25] <jerenkrantz> only a few
# [05:25] <jerenkrantz> (i am)
# [05:25] <jdaggett> tab or dbaron?
# [05:25] <jerenkrantz> nope - they are still eating
# [05:26] <jdaggett> ok, thx
# [05:28] <TabAtkins> jdaggett: Yo.
# [05:29] <jdaggett> hey, did you see the note about taro?
# [05:29] <jdaggett> he'll be coming at 1
# [05:29] * Quits: glazou (~glazou@public.cloak) (glazou)
# [05:29] <jdaggett> remember him? he was at kyoto f2f
# [05:33] <TabAtkins> I don't remember him, but sure.
# [05:33] <TabAtkins> Hm, I wonder how I should meet him.
# [05:37] <jdaggett> he'll be at reception at 1
# [05:37] <TabAtkins> jdaggett: Okay, that works. I'll be downstairs then.
# [05:37] <jdaggett> can you just tell the reception to expect him
# [05:37] <jdaggett> cool, thanks!
# [05:38] * Joins: leif (~lastorset@public.cloak)
# [05:43] * Quits: plh (plehegar@public.cloak) (Ping timeout: 180 seconds)
# [05:44] * Joins: rhauck (~Adium@public.cloak)
# [05:47] <TabAtkins> jdaggett: Have you been to the shabu-shabu place?
# [05:47] <jdaggett> nope
# [05:47] * Joins: glazou (~glazou@public.cloak)
# [05:47] <jdaggett> were you able to reserve?
# [05:52] * Joins: rhauck1 (~Adium@public.cloak)
# [05:52] <jdaggett> glazou: can we wait for taro to start the fonts discussion?
# [05:52] <glazou> jdaggett, supposed to arrive when ?
# [05:52] <jdaggett> 1pm
# [05:52] <jdaggett> i think tab is downstairs waiting at reception for him
# [05:53] <glazou> no tab is right next to me, reminding him now
# [05:53] <TabAtkins> jdaggett: Yeah, I reserved it last night.
# [05:54] <jdaggett> cool!
# [05:54] <TabAtkins> jdaggett: Just wanting to make sure I can get to it easily. ^_^
# [05:54] <jdaggett> it's pretty close when i looked on the map
# [05:54] <TabAtkins> did the full unlimited shabu-shabu, drinks, and sushi meal. ^_^
# [05:54] <TabAtkins> Yeah, real close.
# [05:54] <jdaggett> wow!
# [05:54] <jdaggett> that's time-limited to 2 hrs...
# [05:54] <TabAtkins> Yeah.
# [05:55] <TabAtkins> Okay, running downstairs.
# [05:55] <jdaggett> cool
# [05:57] * Joins: plh (plehegar@public.cloak)
# [05:57] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [05:58] <jdaggett> is shane there today?
# [05:58] <jdaggett> need to hook up the zakim connection again
# [06:03] * dbaron Zakim, room for 5 for 300 minutes?
# [06:03] <Zakim> ok, dbaron; conference Team_(css)04:03Z scheduled with code 26631 (CONF1) for 300 minutes until 0903Z
# [06:03] * Joins: r12a (rishida@public.cloak)
# [06:03] <glazou> waiting for shane and tab now
# [06:03] <jdaggett> r12a: are you here for the fonts discussion?
# [06:04] <dbaron> shane went to look for Tab, so we can't set up the call now :-P
# [06:04] <dbaron> and r12a is here
# [06:04] <r12a> yep
# [06:04] <jdaggett> cool
# [06:04] * Joins: lmclister (~lmclister@public.cloak)
# [06:04] <glazou> shane back
# [06:04] <jdaggett> phone bridge magic?
# [06:05] <glazou> shane is casting a spell on the telephone right now
# [06:06] * Joins: myakura (~480ee730@public.cloak)
# [06:07] <Zakim> Team_(css)04:03Z has now started
# [06:07] <Zakim> +[IPcaller]
# [06:07] <jdaggett> zakim, ipcaller is me
# [06:07] <Zakim> +jdaggett; got it
# [06:07] <jdaggett> ok, waiting for shane magic...
# [06:07] * Joins: Rossen (~Rossen@public.cloak)
# [06:07] * liam zakim, who would be on the phone if we were connected?
# [06:07] * Zakim I don't understand your question, liam.
# [06:08] <Bert> ScribeNick: Bert
# [06:08] <Bert> Topic: Fonts
# [06:08] * glazou sees that google conferencing system can't beat jdaggett's skype+polycom
# [06:09] <jdaggett> heh
# [06:09] <jdaggett> sorry in advance, i'm in the visitor's room with a tv on in the background...
# [06:10] <jdaggett> tab and taro arrive yet?
# [06:10] <stearns> not yet
# [06:11] <jdaggett> hmm, he says he's stuck on the third floor
# [06:11] <jdaggett> can't come up to the 26th floor
# [06:11] <jdaggett> argh
# [06:11] <Zakim> +??P0
# [06:12] <Rossen> both are here now
# [06:12] <dbaron> jdaggett, taro is here
# [06:12] <dbaron> Zakim, ??P0 is Meeting_Room
# [06:12] <Zakim> +Meeting_Room; got it
# [06:13] <Bert> jdaggett: italic in vertical:
# [06:13] <Bert> ... I recommend that Koji come to the mic
# [06:13] * Joins: shans__ (~shans@public.cloak)
# [06:13] <Bert> ... Background is that in Japanese there is no real tradioton of italic.
# [06:14] <Bert> ... UAs just oblique synthetically.
# [06:14] * glazou invited expert for this item is Taro Yamamoto
# [06:14] <Bert> ... When 'font-style: italic' on vertical text, what should it do?
# [06:14] <Bert> ... If you have a normal italic font, you just use it.
# [06:14] <Bert> ... Should the slant be different in vertical?
# [06:14] <jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png
# [06:15] <Bert> ... Example [see URL]
# [06:15] <Bert> ... This is the options.
# [06:15] <Zakim> -Meeting_Room
# [06:15] <Bert> ... figure 2 is normal italics.
# [06:15] <dbaron> jdaggett, we dropped off
# [06:16] <Bert> ... Some in Japan have [lost phone]
# [06:16] <TabAtkins> One sec while we reconnect.
# [06:16] <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png
# [06:16] <jdaggett> argh
# [06:16] * liam zakim, who is on the phone?
# [06:16] * Zakim sees on the phone: jdaggett
# [06:17] <Zakim> +??P0
# [06:17] <dbaron> Zakim, ??P0 is glazou
# [06:17] <Zakim> +glazou; got it
# [06:17] <fantasai> Murakami-san's take: http://lists.w3.org/Archives/Public/www-style/2013May/0405.html
# [06:18] * liam zakim, code?
# [06:18] * Zakim saw 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org) given for the conference code, liam
# [06:18] <Bert> [Trying to reconnect to Zakim]
# [06:18] <Zakim> +??P2
# [06:18] <Zakim> -glazou
# [06:18] <dbaron> Zakim, ??P2 is Meeting_Room
# [06:18] <Zakim> +Meeting_Room; got it
# [06:18] <jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png
# [06:19] <Bert> [example on screen]
# [06:19] * Joins: dino (~dino@public.cloak)
# [06:19] <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png
# [06:19] <Bert> jdaggett: Koji and Elika propose figure 3
# [06:19] <dbaron> current fonts spec has #2, Koji and Elika propose #3
# [06:19] * Joins: jdovey (~jdovey@public.cloak)
# [06:19] <Bert> [new image on screen]
# [06:19] <dbaron> (move jdaggett's last URL to here)
# [06:19] <Bert> jdaggett: Mixture of 2 with a real italics font.
# [06:20] <Bert> ... I don't say which is better.
# [06:20] <Bert> ... Slope down to the right in 3
# [06:20] <Bert> ... All kinds of arguments possible about what is better in diff. cases.
# [06:20] <Bert> ... But there is no tradiotn of italic in Japanese.
# [06:21] <Bert> ... But Koji brought up that there is tradition of obliquing
# [06:21] <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0032/harrypotter-7-193.png
# [06:21] <Bert> [example on screen]
# [06:21] <Bert> jdaggett: This is oblque to the left.
# [06:22] <Bert> ... Koji found this.
# [06:22] <Bert> ... There should not be a distinction between real italics and synthetic case.
# [06:22] <Bert> ... Bad inconsistency.
# [06:22] <Bert> ... If we want oblique in eneral then we need better control.
# [06:23] <Bert> ... We are still fighting arouhnd the edges.
# [06:23] <Bert> ... Comments? Koji,Taro?
# [06:23] <Bert> Koji: Not agaisst your opitinion
# [06:23] <Bert> ... I want consistent for sideways characters, that's were moset italic will be.
# [06:24] <Bert> Taro: Why you don't agree?
# [06:24] <Bert> ... Historically there haven't been any slanted Japanese
# [06:24] <Bert> ... Limited to display type, headlines etc. One line only.
# [06:24] <Bert> ... We have Times Roman and it has italic.
# [06:25] <Bert> ... It is possible to apply automatic transform, slanting.
# [06:25] <Bert> ... Not in Japanese context.
# [06:25] <Bert> ... Two notions.
# [06:25] <Bert> ... There is no [missed]
# [06:25] <Bert> Koji: Progessionls say there is no italic, but authors stll want it.
# [06:26] <Bert> jdaggett: Give them the option if they want something like Harryt Potter example.
# [06:26] <Bert> ... It has down slant on the left.
# [06:26] <Bert> ... Authors cannot do that.
# [06:26] <Bert> ... Putting behavior in general behavior doens't give authors the control.
# [06:27] <Bert> Koji: I discussed with authors.
# [06:27] <Bert> ... They udnerstand.
# [06:27] <Bert> ... They stil prefer synthetic italics.
# [06:27] <Bert> ... Too many points too discuss.
# [06:27] <Bert> .. Do them one by one.
# [06:27] <Bert> ... 1st is synthesize or not?
# [06:27] <Bert> ... 2nd is which direction.
# [06:28] <Bert> jdaggett: Spec now says synth happens based on whether there is italic or not.
# [06:28] <Bert> ... Whether synth italic is good or not is separate matter.
# [06:28] <Bert> ... If we have to have synth italic, and we do, then it has to be consistent with real italic.
# [06:28] <Bert> . Not based on horiz or vertical or other factors.
# [06:29] <r12a> q+
# [06:29] * Zakim sees r12a on the speaker queue
# [06:29] <Bert> ... I dont' agree with the way your quoting me.
# [06:29] <Bert> ... We have font-syyle in CSS and it allows synthesize.
# [06:29] <Bert> ... We have to continue that.
# [06:29] <Bert> Taro: If proper true slanting operations for Japanese is not defined,
# [06:30] <Bert> ... I have to object allowing [???]
# [06:30] <Bert> ... It will make it easier for user to get accustomed to current deteriorated situation.,
# [06:30] <Koji> s/[???]/synthesizing italics by slanting/
# [06:30] <Bert> ... People will continue current and that is not good thing.
# [06:30] <Bert> ... In Harry Potter case,
# [06:31] <Bert> ... Where slanting neessary, we should do that,
# [06:31] <Bert> ... But we have no correct diefitionn yet.
# [06:31] <Bert> ... Once defined and documented,
# [06:31] <Bert> ... Yes allow some kind of algorithm,
# [06:31] <Bert> ... Slanting may be necessary.
# [06:31] <Bert> ... Without knowing wjhat Japanese slanting shuld bem it is very risky to link between existing and cjose slantoing operation.
# [06:32] <Bert> ... Look at ROmand and japanese char
# [06:32] <Bert> ... Maby metrics differemt.
# [06:32] <Bert> ... You have beedn accustomied to switching italic and roman.
# [06:32] <Bert> ... Always assumed that you will find an italicfont.
# [06:32] <Bert> ... That doesnt exist in japanese world.
# [06:33] <Bert> ... My recomendation is to do nothing.
# [06:33] <Bert> ... That is best becase there is no italic in japanese.
# [06:33] <Bert> ... Doing something is OK, but please define what the shearing oepration should be,
# [06:33] <Bert> ... Oherwise popel will just be happy with the current stats eand think is is fine.
# [06:33] <Bert> ... That will not guarntee good graphic and visual effect.
# [06:34] <dbaron> ack r12a
# [06:34] * Zakim sees no one on the speaker queue
# [06:34] <Bert> r12a: Asking for clarifiction:
# [06:34] <Bert> ... In Harry Potter is is down to the left,
# [06:34] <Bert> ... What would happin in horizontal?
# [06:34] <Bert> Koji: No, it would be to the right.
# [06:34] <Bert> jdaggett: This is a pblished example.
# [06:34] <Bert> .. Koji and Elika proposed slanting down to the right.
# [06:35] <Bert> Koji: I'm proposing the number 3, jdaggett propose 2
# [06:35] <Bert> [Harry Potter is 1]
# [06:35] <Bert> Koji: Japanese authors want 1 if combined with ltin text, otherwise 3.
# [06:36] <Bert> ... I asked publishers what they want.
# [06:36] <Bert> ... After discussion they said 3 works best for now.
# [06:36] <Bert> ... Until we get more precise control.
# [06:36] <Bert> jdaggett: 3 introcudes inconstency when there are real italics.
# [06:36] <Bert> koji: Japnese font will not have real italics.
# [06:37] <Bert> jdaggett: But western author miing text will get 3, that does not look right.
# [06:37] <Bert> ... [Confusion over which number 3]
# [06:38] <Bert> ... [Looking at tategaki image]
# [06:38] <Bert> ... That will look bad.
# [06:38] <Bert> Koji: There is no single way to solve all issues.
# [06:38] <Bert> ... Not in level 3.
# [06:38] <dbaron> in http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png , #1 is skewY(-10deg) for Japanese, #2 is skewX(-10deg) for Japanese, #3 is skewY(+10deg) for Japanese (note +- and XY changes)
# [06:38] <Bert> ... Latin upright use case is less important.
# [06:39] <Bert> jdaggett: Japanese italic is difficult to find.
# [06:39] <Bert> fantasai: The examples are not real italcis, they re some diffirent feature.
# [06:39] <Bert> ... Fndamental question is direcion of shearing.
# [06:39] <Bert> ... [drawing on whiteboard]
# [06:40] <Bert> liam: q for Koji:
# [06:40] <Bert> ... We often say that dureing standards and it comes back to bite us.
# [06:40] <Bert> ... "until we have more control"
# [06:40] <Bert> ... We're often stuck with that.
# [06:40] <Bert> ... Don't precluse anythign in the futre.
# [06:41] <Bert> Koji: Yes, with more control authors will be happy.
# [06:41] <Bert> ... But even now they ar ehapy with 3.
# [06:41] <Bert> Taro: Do not agree.
# [06:41] <dbaron> in http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png , #1 has skewX(-10deg) for ja and en, #2 has skewY(+10deg) for ja and en, #3 skewY(+10deg) for ja and skewX(-10deg) for en
# [06:41] <liam> s/precluse/preclude/
# [06:41] <Bert> ... Hary Potter exmaple is not italic. It is slanted, yes.
# [06:41] <Bert> ... Iv'e done slanting myself.
# [06:42] <Bert> ... [fantasai tries to draw. Taro doesn't'thnk the drawing is right]
# [06:42] <Bert> ... It is necessary to align line direction and angle.
# [06:42] <Bert> ... Japanese phototypesetting at slanted line.
# [06:43] <Bert> ... Possible, I know.
# [06:43] <Bert> ... Sometimes people ant that, but it is not italic.
# [06:43] <Bert> Rossen: For mcirosoft, I'm not an expert in this area.
# [06:43] <Bert> ... From talking to Office team:
# [06:43] <Bert> .. Feedback was that we had italics in word for 20 years.
# [06:44] <Bert> .. Since MS Gothic.
# [06:44] <Bert> ... Regardless of how good or bad, there is adoption of it.
# [06:44] <Bert> ... People ar eusing italic in vertical.
# [06:44] <Bert> ... How mny make it to the Web I'm not sure.
# [06:44] <Bert> ... If nedded I can find examples.
# [06:44] <dbaron> Present+ Taro Yamamoto (Adobe)
# [06:44] <Bert> ... Expected that these document will become HTML.
# [06:45] <Bert> jdaggett: How many are using th feature?
# [06:45] <Bert> Rossen: I don
# [06:45] <Bert> ... t have data
# [06:45] <Bert> jdaggett: There were certain assumption made a long time ago.
# [06:45] * Quits: dino (~dino@public.cloak) (Client closed connection)
# [06:45] <Bert> ... The initial Word model was simple.
# [06:45] <Bert> ... Should not look at that backwards compt.
# [06:45] <Bert> Koji: Used for 20 years.
# [06:45] <Bert> jdaggett: How often?
# [06:46] <Bert> Rossen: As often as anybody wants to use italic in vertical.
# [06:46] <Bert> Taro: Adobe Indesign since 10 years ignores italic in Japnese script.
# [06:46] <Bert> ... It seems to be a script property.
# [06:46] <Bert> ... Adobe's Japanese fonts have italic glyphs for Latin.
# [06:47] <Bert> ... You can do tru italic with Adobe fonts.
# [06:47] <Bert> ... But not to any Japanses font.
# [06:47] <Bert> ... Only if glyphs included in the font.
# [06:47] <Bert> ... IS this really a font property?
# [06:47] <Bert> ... Western context OK.
# [06:47] <Bert> ... OK with font property there.
# [06:48] <Bert> ... You can assume that Times Roman has italic.
# [06:48] <Bert> ... But no such assumption in japanese context.
# [06:48] <Bert> Koji: So we're back to synthesize or not.
# [06:48] <Bert> ... Make a spexil rule for japanese to not synthesize if font not available?
# [06:49] <Bert> r12a: Only Japanses or CJK?
# [06:49] <Bert> Taro: Any script that have no italic semantics.
# [06:49] <Bert> Koji: In Unicode often difficult to know script.
# [06:49] <Bert> ...Should not depend on codepoints for scripts.
# [06:50] <Bert> ... If we can resolve this, than we candecide how to synthesize (if we decide to synth).
# [06:50] <Bert> fantasai: What do Koreans do?
# [06:50] <Bert> jdaggett: Easy way is to use an italic font. But I'm interested in the fallback case.
# [06:51] <Bert> r12a: Russina also a pb.
# [06:51] <Bert> ... Shapes in italic very different from romanan.
# [06:51] <Bert> .. Slanting won't work.
# [06:51] <stearns> +1 to less faux italic magic
# [06:51] <Bert> dbaron: Spec says *may* synth, isn't it?
# [06:52] <Bert> jdaggett: Yes, but users will expect it.
# [06:52] <dbaron> jdaggett: but all UA's do it, so users expect it
# [06:52] <Bert> Koji: Yes, spec says that. I want consistency *when* the UA synthseses.
# [06:52] <Bert> glenn: Conditional required spec text
# [06:53] <Bert> jdaggett: UAs do that, but users should have way to turn it off.
# [06:53] <glenn> s/Conditional required/conditional mandatory/
# [06:53] <Bert> glazou: I think we have to resolve and move on
# [06:53] <Bert> jdaggett: Strawpoll and move on.
# [06:54] <Bert> ... Let me get the example.
# [06:54] * Joins: sgalineau (~sgalineau@public.cloak)
# [06:54] <Bert> ... Tategaki figure
# [06:54] <Bert> [Tategaki figure now on screen]
# [06:54] <jdaggett> proposals:
# [06:55] <Bert> [vertical2 now also on screen]
# [06:55] <jdaggett> 1. synthetic italics follow actual italics (glyphs slanted to the right independent of orientation/vertical/horizontal)
# [06:55] * Joins: dino (~dino@public.cloak)
# [06:56] <jdaggett> 2. synthetic italics in the vertical case are slanted down to the right
# [06:56] * Quits: sgalineau (~sgalineau@public.cloak) ("Textual IRC Client: www.textualapp.com")
# [06:56] * Joins: isra (~inoto@public.cloak)
# [06:56] * Joins: kawabata (~kawabata@public.cloak)
# [06:56] <Bert> ["LETTERS 123" on the left, "Italics 123" on the right]
# [06:57] * fantasai wishes we had consistent numbering system
# [06:57] <dbaron> proposal 1 == tategaki example #1
# [06:57] <dbaron> proposal 2 == tategaki example #2
# [06:57] <Bert> jdaggett: red #1 is prposal 1
# [06:57] <jdaggett> red #2 is proposal 2
# [06:58] <Bert> dean: 1 and 2 talk about latin text, rotated or upright?
# [06:58] <Bert> jdaggett: Proposal is to follow actual italic.
# [06:58] <Bert> ... [scribe confused]
# [06:58] <glazou> …[not only the scribe...]
# [06:59] <Bert> dbaron: So apply to all italci tetx, incl latin and ideog?
# [06:59] <Rossen> jdaggett, can we use Koji's example? it is so much easier
# [06:59] <Bert> jdaggett: I think we had no disagreement.
# [06:59] <Bert> Koji: Your prop is red 1 and sideways 2?
# [07:00] <Bert> .. My prop is red 2 and sideways 3
# [07:00] <Bert> jdaggett: Fine
# [07:00] <Bert> ... Synth italic and real italics are going to be different in Koji's propoosal.
# [07:00] <Rossen> [Koji to jdaggett mapping]
# [07:00] <Bert> Koji: Depends on which consistency you want.
# [07:01] <Bert> ... Your picture shows more consistency with upright letetrs.
# [07:01] <Bert> ... Mine more against baseline.
# [07:01] <Bert> glazou: There are other vertical writing systems, such as Mongolian.
# [07:01] <Bert> ... Will tjis apply there?
# [07:02] <Bert> jdaggett: Yes, but hose systems do not have tradition of italics.
# [07:02] <Bert> ... So less need for authors.
# [07:02] <Bert> glazou: I have a set of Mongolian fonts with italics in front of me.
# [07:02] <Bert> [People gathering arounf glaxou]
# [07:02] * Rossen notes that we've supported Mongolian since IE8
# [07:02] <Bert> r12a: Maybe becaus eit is basically rtl system.
# [07:03] * Rossen italics was allowed
# [07:03] <dbaron> #1 has skewX(-10deg), #2 has skewY(+10deg)
# [07:03] <Bert> Koji: [...] best beahvour in CSS and acceptable.
# [07:03] <Bert> ... If one face is not available...
# [07:03] * jdovey thinks this problem cannot be addressed with current CSS capabilities
# [07:04] <Bert> glazou: I want to make sure proposals are fit for other writing systems.
# [07:04] <Bert> jdaggett: Only the synthetic case.
# [07:04] <Bert> .. If user uses italic font, he gets it.
# [07:04] <stearns> jdovey: ding ding ding
# [07:04] <Bert> dbaron: We shoul;dn't hold up LC over a fallback case.
# [07:05] <Bert> fantasai: If you use Koji style, you will break connecions in Mongolian [scribe not sure]
# [07:05] <Bert> ... Mongolian glyphs sudeways
# [07:05] * jdovey If anything, make a note on the spec (or a WG Note) describing the issue and asking for input to CSS Text 4
# [07:05] <Bert> ... If Mongilian were to be defined in terms of upright,as jdaggett wants, than this would break connections.
# [07:05] <Bert> jdaggett: There is no use case for that.
# [07:06] <Bert> ... The examples you brought up. There is no [...] italic context.
# [07:06] <Bert> .. Thin air, no real use case.
# [07:06] <Bert> Koji: No, it exists.
# [07:06] <Bert> glazou: strwapoll.
# [07:07] <Bert> Option 1 = red 1
# [07:07] <Bert> Option 2 = red 2
# [07:07] <Bert> TabL abstain
# [07:07] <Bert> koji 2
# [07:08] <Bert> ivan: ab
# [07:08] <Bert> glazou: abs
# [07:08] <Bert> SimonSapin: abs
# [07:08] <Bert> Jet red 1
# [07:09] <Bert> taro: 1
# [07:09] <Bert> Rossen: sen 2
# [07:09] <Bert> Alan 1
# [07:09] <Bert> Rebecca: abs
# [07:09] <Bert> dean 1
# [07:10] <Bert> dirk: abs
# [07:10] <Bert> rik: abs
# [07:10] <Bert> leif: abs
# [07:10] <dbaron> (dirk and Taro would have voted for the third drawing for the whiteboard, which has no synthesis in vertical Japanese)
# [07:10] <Bert> ??: 2
# [07:10] <leif> s/??/Kazutaka
# [07:10] <Koji> s/??/Kazutaka/
# [07:10] <Bert> liam: 1
# [07:11] <Bert> justin: 2
# [07:11] <Bert> shane: abs
# [07:11] <Bert> jim: abs
# [07:11] <Bert> bert: abs
# [07:11] <Bert> r12a: abs in favor of futher evidence, as westerneer prefer 1
# [07:11] <Bert> plins: abs
# [07:11] <Bert> dbaron: abs
# [07:11] <Bert> glen: 1
# [07:12] <Bert> fantasai: 2
# [07:12] <Bert> ... problems not as often .
# [07:12] <Bert> [6 to 5 in favor of 1]
# [07:13] <Rossen> 13 abs
# [07:13] <Bert> jdaggett: 1
# [07:13] <dbaron> [7 to 5 in favor of 1]
# [07:14] <Bert> [discussion about live with and object...]
# [07:14] <Bert> jdaggett: Weak consensu os to do something because we do not have a real property to allow obiquing.
# [07:14] <Bert> ... Not do this as a substitute for doing somethjing else.
# [07:15] <Bert> glazou: So leave it undef?
# [07:15] <Bert> jdaggett: No, go with 1, because 2 is relly advocating for a new feature.
# [07:15] <Bert> Koji: No, then we have to define for Ruby, etc.
# [07:15] <Bert> ... Those conflict.
# [07:15] <Bert> jdaggett: [missed]
# [07:15] * Quits: isra (~inoto@public.cloak) ("Leaving.")
# [07:16] <Bert> glazou: We have 7 to 5, so option 1 or leave undef.
# [07:16] <Bert> jdaggett: Either is fine.
# [07:16] <Bert> ... But not option 2
# [07:16] <Bert> [hands up for udnefined]
# [07:16] <Bert> [Some hands up]
# [07:16] <Bert> RESOLVED: Leave undefined.
# [07:17] <Bert> jdaggett: Netx issue.
# [07:17] <Bert> ... fantasai 's issue on sub/superscript
# [07:17] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0285.html
# [07:17] <fantasai> My concerns with 1 are that there are cases that break with it, even though it is typographically better. Since the correct solution is to use an italic font, this fallback case should just be the option that works adequately in the most cases. And #2 does that: it doesn't create overlapping problems, it doesn't break multi-glyph constructs, and it doesn't break cursive scripts or fonts.
# [07:18] <Bert> ... What to do about text decorations in superscript variant glyphs.
# [07:18] <jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0025/superscript-underline.png
# [07:18] <Bert> ... Let me explain the example.
# [07:18] <Bert> [Looking at e-mail msg]
# [07:18] <Bert> [Looking at image]
# [07:18] <Bert> jdaggett: Different kinds of sub & super
# [07:19] <Bert> ... Using HTML, font shrink and vertical align
# [07:19] <Bert> .. Second uses Unicode codepoints for super and sub
# [07:19] <Bert> ... 3rd is suing feature in draft.
# [07:19] <Bert> ... What an undelrine looksk like
# [07:19] <Bert> ... 2nd has underline just to superr
# [07:20] <fantasai> https://coreldraw.com/cfs-filesystemfile.ashx/__key/CommunityServer.Components.PostAttachments/00.00.17.55.90/workaround.jpg
# [07:20] <Bert> .. Difference in baseline
# [07:20] <Bert> ... Metrics same as surronfing text for Unicode superscript glyphs.
# [07:20] <Bert> ... FOnt has metrics for syntheseis
# [07:21] <Bert> ... This pb exists with Unicode code points already.
# [07:21] <Bert> ... My point is that we don't need to do anythign special.
# [07:21] <Bert> ... You get what you get in 2nd example.
# [07:21] <Bert> ... You don't get detailed control.
# [07:21] <Bert> fantasai: The one we want is what matches the HTML example.
# [07:21] <Bert> .. Thatos what people want.
# [07:22] <Bert> ... Take info from font, and use that to position underline.
# [07:22] <Bert> jdaggett: That doenst match where the glyphs are.
# [07:22] <Bert> ... Cannot have magic.
# [07:22] <Bert> ... Fallback won't work.
# [07:22] <Bert> ... etrics are different.
# [07:22] <Bert> fantasai: But it will match synthesized glyps.
# [07:22] <Bert> jdaggett: No, not close enough.
# [07:23] <Bert> fantasai: he bottom examples don't look right at all.
# [07:23] <Bert> ... We can get closer.
# [07:23] <Bert> jdaggett: Just wrong in a different way.
# [07:23] <Bert> ... Adobe's font all have same metrics.
# [07:23] <Bert> ... Aling will be differne tbase don font.
# [07:23] <jdaggett> http://dev.w3.org/csswg/css-fonts/#font-variant-position-prop
# [07:24] * Parts: glazou (~glazou@public.cloak) (glazou)
# [07:24] <Bert> [looking at figure 22]
# [07:24] <Bert> jdaggett: Showis diff ebtween real superscript on left and synth version in middle.
# [07:24] <Bert> ... Baseline is not the same.
# [07:24] <Bert> ... Will have unerline in middle. Not look right.
# [07:25] <Bert> .. We hav ebeen trying to come with magic for a year and a half.
# [07:25] <Bert> ... Text decoration same issue coming back all over again.
# [07:25] <Bert> ... We kust don't have it, it i snot available.
# [07:25] <Bert> Leif: Can the font p[rovide metrics?
# [07:25] <Bert> fantasai: Yes, they could.
# [07:26] <Bert> jdaggett: Not the right answer. The metrics are meant fo rthe synth case.
# [07:26] <Bert> ... Example 22 shows that synth superscript is larger.
# [07:26] <Bert> ... Designer made it so.
# [07:26] <Bert> ... Metrics work with synth.
# [07:27] <Bert> ... Not so well fo rthe designed glyphs.
# [07:27] <Bert> ... Which is what you propose to use them for.
# [07:27] <fantasai> I still think it's better to use those metrics than to use the base size metrics
# [07:27] <Bert> ... Complex content [...]
# [07:27] <Bert> ... It is not meant as complet ereplacement for HTML mark-up.
# [07:28] <Bert> ... There are limitations, noted in the spec.
# [07:28] <Bert> fantasai: I'd like to edit text deco spec to say we use font metrics in font.
# [07:28] <Bert> jdaggett: What are doing?
# [07:28] <fantasai> glenn: I agree
# [07:28] <Bert> ... The metrics don't match what you want to sue them for.
# [07:29] <Bert> glenn: If the font *doe* have metrics, they should be used.
# [07:29] <Bert> ... Agreed?
# [07:29] <Bert> jdaggett: The metrics are used for synthesis.
# [07:29] <Bert> ... If you resize,
# [07:30] <Bert> ... The metrics don't matchs the actual glyphs.
# [07:30] <Bert> ... Sure, if you design a font with metrics, but that is a big "if."
# [07:30] <Bert> .. Not common practice.
# [07:30] <Bert> ... Other comments or questions?
# [07:31] * Joins: glazou (~glazou@public.cloak)
# [07:31] <Bert> Leif: Seems fantasai 's suggestion works in exmaple 22, but maybe not for subscript.
# [07:31] <Bert> ... Maybe not in gemeral.
# [07:31] <Bert> fantasai: Metrics of base size is not any better, propbably worse.
# [07:32] <Bert> Leif: I don't really know how fantasai 's uggestion will turn out for subscripts.
# [07:32] <Bert> ... Better result more often than not?
# [07:32] <Bert> glenn: If font designed specs a sub or super feature, but without glyphs, you suggest we synthesize?
# [07:33] <Bert> jdaggett: Spec ahs wording about that.
# [07:33] <Bert> ... We do include wording for fallback, we will synthesize.
# [07:33] <Bert> ... If user adds elements or images, or sub-spans, then they should use the HTML way.
# [07:34] <Bert> ... We pretty much resolved on the feature not being a complete replacement for HTML mark-up, and it shuldn't be one.
# [07:34] <Bert> glenn: Is there consistency among UAs for fallback?
# [07:34] <Bert> jdaggett: Nobody implemented it, no cmparison to make.
# [07:34] * fantasai notes that it's possible to use this feature for all these cases if you know what tags you're dealing with
# [07:34] * fantasai so it would work fine for most HTML
# [07:34] <Bert> ... Gecko has impl ebhind a flag, but without the fallback behavior.
# [07:35] <Bert> glenn: Mark fallback at risk?
# [07:35] <Bert> jdaggett: Why?
# [07:35] <Bert> glenn: Lack of implem experience.
# [07:35] <Bert> jdaggett: No strong case, spec is just not finsihed yet.
# [07:36] <Bert> glenn: No early implementers either.
# [07:36] <Bert> glazou: Can the people discussing now find a compromise?
# [07:36] <Bert> jdaggett: What do ypu want me to compromise on?
# [07:36] <Bert> ... There si nothing.
# [07:37] <Bert> fantasai: Cannot live with John's option.
# [07:37] <Bert> jdaggett: You're propisng magic, not a real proposal.
# [07:37] * glazou suggest letting fantasai and jdaggett in a locked room, survivor wins
# [07:38] <Bert> plinss: If metrics available, use them, but seems there are none.
# [07:38] * Rossen +1 on glazou suggestion but fantasai should have an axe
# [07:38] <Bert> jdaggett: Based on what research?
# [07:38] <Bert> plinss: Metrics are for something else, acoording to jdaggett
# [07:39] <Bert> ... So if the metrics don't exist, [...]
# [07:39] <glazou> Rossen, and jdaggett a longsword ?-)
# [07:39] <Bert> fantasai: But if they exists it will be right, and otherwise they will be slighty off.
# [07:39] <Bert> plinss: Fine with a note in text decoration about if there are metrics.
# [07:39] <Bert> fantasai: We have to put the underline somewhere.
# [07:39] <Bert> ... Which metrics do you use.
# [07:40] * Quits: ivan (ivan@public.cloak)
# [07:40] <Rossen> glazou, Nooo just a swiss knife
# [07:40] * Quits: r12a (rishida@public.cloak) (Client closed connection)
# [07:40] <Bert> ... Just because Unicode glyohs have this pb, doesn't mean we have to copy the pb.
# [07:40] <Bert> liam: Proposal:
# [07:40] <Bert> ... WebFonts WG has liasion with ISO Opentype
# [07:40] <Bert> ... Chair of WG.
# [07:40] <Bert> ... Ask them about a new metric.
# [07:41] <Bert> ... Not invent something ourslelves.
# [07:41] <Bert> jdaggett: Shors delay, are you joking?
# [07:41] <Bert> liam: If we have to wait for a new feature, that would be long. But not long to ask the question.
# [07:41] <Bert> jdaggett: We have been trhought this.
# [07:42] <Bert> Liam: In that case redraw suggestion.
# [07:42] <Bert> plinss: Still useful to talk to Opentype.
# [07:42] <Bert> glenn: Truetype has different tables.
# [07:43] <dbaron> glenn: ... bsln (Truetype) vs BASE (OpenType)
# [07:43] <Bert> ... Are we too specific to OpenType.
# [07:43] <Bert> jdaggett: [missed]
# [07:43] <dbaron> jdaggett: superscript metrics are in OS2 table
# [07:43] <Bert> glenn: Asking because you also mention baseline offsets.
# [07:43] <Bert> ... Just wondering...
# [07:43] <Bert> ... You and Elika get together.
# [07:44] <Bert> glazou: strawpoll.
# [07:44] <fantasai> fantasai: Proposal is for when superscripts or subscripts are decorated, use superscript/subscript metrics to position decoration
# [07:45] <Bert> plinss: Are you taling about synth *and* non-synth case?
# [07:45] <dbaron> jdaggett: The text underline follows the surrounding glyphs (for both in the synthesized case and the actual glyphs case)
# [07:45] <fantasai> fantasai: jdaggett's proposal is that instead, use the metrics of full-size glyphs
# [07:45] <Bert> jdaggett: Yes, behave same way, nortmal baseline, not shifted.
# [07:45] <Bert> TabAtkins: [pointing to figures]
# [07:45] <Bert> dbaron: jdaggett only refers to Unicode codepoints, not to the HTML version.
# [07:46] <Bert> fantasai: That means underline the whole thing as the full size chars,
# [07:46] <dbaron> fantasai: in the example, jdaggett wants the OpenType version to match the Unicode version rather than the HTML ersion
# [07:46] <Bert> fantasai: People do not undelrine the degree char, but they do underline superscripts.
# [07:47] <Bert> TabAtkins: jdaggett 's proposal is the lower half of the current projected screen.
# [07:47] <Bert> [7 hands for jdaggett proposal]
# [07:48] <Bert> [7 for fantasai 's proposal]
# [07:48] <Bert> [rest abstain]
# [07:48] <glazou> [8 hands for jdaggett proposal]
# [07:48] <Bert> [plus 1 for jdaggett , jdaggett himself]
# [07:48] <dbaron> s/jdaggett only refers to Unicode codepoints, not to the HTML version/we're talking about what happens with the new feature for using font features, not using vertical-align/
# [07:49] <Bert> jet: Does this hold up LC on fonts?
# [07:49] <Bert> fantasai: No, it is an issue for text decoration.
# [07:49] <Bert> jet: We should really resolve this, cannot keep on fighting.
# [07:50] <Bert> plinss: If is not on fonts, let's leave it open issue on text deco and move on with fonts.
# [07:50] <dbaron> <br data-duration="900s">
# [07:50] <Bert> [break 15 mins]
# [07:51] * jdaggett runs off to the ...
# [07:57] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [08:03] * Joins: Rossen (~Rossen@public.cloak)
# [08:04] <plinss> zakim, mute jdaggett
# [08:04] <Zakim> jdaggett should now be muted
# [08:05] <jdaggett> ooops, sorry
# [08:10] <glazou> jdaggett, about to start again
# [08:12] <glazou> Zakim, unmute jdaggett
# [08:12] <Zakim> jdaggett should no longer be muted
# [08:12] <plinss> zakim, unmute jdaggett
# [08:12] <Zakim> jdaggett was not muted, plinss
# [08:12] <Bert> [glazou and fantasai discuss which issue to treat next]
# [08:12] <jdaggett> not hearing you...
# [08:12] <jdaggett> zakim, who is on the phone?
# [08:12] <Zakim> On the phone I see jdaggett, Meeting_Room
# [08:12] <jdaggett> is your phone muted?
# [08:12] <glazou> Zakim, unmute Meeting_Room
# [08:12] <Zakim> Meeting_Room was not muted, glazou
# [08:13] <glazou> wait
# [08:13] <glazou> OM representation of @font-feature-values rule
# [08:13] <Bert> Topic: font feature at-rule in OM
# [08:14] <jdaggett> http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues
# [08:14] <Bert> jdaggett: [looking for URL]
# [08:14] <Bert> ... fantasai posted that it should be different, ensued a thread. Tab prposed a subclass of grtouping rule.
# [08:15] <Bert> ... And then make each feature block another subclass.
# [08:15] <Bert> ... I'd like to gauge group's opinion.
# [08:15] <Bert> ... Whos is interested in implementong?
# [08:15] <Bert> glazou: comments?
# [08:15] <fantasai> Heres the comment http://lists.w3.org/Archives/Public/www-style/2013May/0580.html
# [08:16] <Bert> dbaron: Mixed feelings
# [08:16] <Bert> ... If it looks like an 2rule it should behave like an at rule. On other hand an awful lot of pieces to make.
# [08:16] <Bert> fantasai: I know Tab has comments, wait for him to come back into the room.
# [08:17] <Bert> jdaggett: Let me look for Tab's stuff.
# [08:17] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0596.html
# [08:17] <Bert> jdaggett: Follow on from that is that grouping rule often [missed]
# [08:17] <jdaggett> example
# [08:18] <jdaggett> @font-feature-values Bongo {
# [08:18] <jdaggett> @swash {
# [08:18] <jdaggett> swishy : 1;
# [08:18] <Bert> SimonSapin: Independent of whether descriptors or declarations are involved
# [08:18] <jdaggett> wavvy-gravy: 2;
# [08:18] <jdaggett> }
# [08:18] <jdaggett> }
# [08:18] <Bert> dbaron: Hesitant to reopne discussion, but makes me wonder if there is too many levels of nesting.
# [08:18] <dbaron> @font-feature-values Bongo { @swash swishy 1; @swash wavvy-gravy 2; }
# [08:19] <Bert> ... Why in that example, not like this [see above]
# [08:19] <Bert> jdaggett: That was original proposal, but we switched to more at-rule-like version.
# [08:19] <Bert> fantasai: Both are at-rules.
# [08:19] <Bert> plinss: Don't see why not a group rule.
# [08:19] <Bert> ... But don't want ot separate i/f classes
# [08:19] * plh notes for John that Tab is back in the room
# [08:19] <Bert> ... for each class.
# [08:20] <Bert> TabAtkins: I proposed to match them.
# [08:20] <Bert> ... Should be on m-list.
# [08:20] <jdaggett> s/match/map/
# [08:20] <Bert> ... Just expose the at-swatch as properties of feature-values
# [08:20] <Bert> ... js-maps
# [08:20] <Bert> ... Or maybe a string
# [08:20] <Bert> ... they'll merge
# [08:21] <Bert> plinss: Makes sense.
# [08:21] <Bert> fantasai: [question]
# [08:21] <Bert> jdaggett: [bad sound]
# [08:21] <fantasai> fantasai: Didn't you have a simplifying proposal, that we could expand later?
# [08:21] <Bert> ... My proposal is at-rule with nothing in it.
# [08:21] <Bert> TabAtkins: [explains proposal]
# [08:22] <Bert> fantasai: could go with that, and than make a css3 font extensions spec.
# [08:22] <Bert> ... Needs more work.
# [08:22] <Bert> dbaron: We're not ready to conclude that yet.
# [08:22] <Bert> jdaggett: font load events is not the approriate place.
# [08:22] <Bert> dbaron: What Tab described sounds fine.
# [08:22] <Bert> [tab writes on wboard]
# [08:23] <Bert> dbaron: TAG is going to review APIs.
# [08:23] <Bert> ... Tab's propal fits what TAG expects.
# [08:23] <TabAtkins> interface CSSFontFeatureValuesRule { attribute Maplike<DOMString, DOMString> swash; ... }
# [08:23] <Bert> glazou: example with Bongo, what would be value text?
# [08:23] <TabAtkins> (Maplike is proposed for WebIDL.)
# [08:23] <Bert> ... from @swatch to closing brace.
# [08:24] <dbaron> Tab's proposal is in http://lists.w3.org/Archives/Public/www-style/2013May/0781.html
# [08:24] <Bert> ... That is painful for editor.
# [08:24] <Bert> [two people talking]
# [08:24] <Bert> jdaggett: When I asked you you said it was no pb.
# [08:24] <stearns> s/you you/you in Tucson you/
# [08:24] <Bert> jdaggett: tab, is it writable?
# [08:24] <Bert> TabAtkins: Yes
# [08:25] <glazou> I said I could live with it, I did not say it is perfect
# [08:25] <Bert> plinss: values are always potential list of numbers?
# [08:25] <Bert> jdaggett: Yes
# [08:25] <Bert> plinss: Then lets not make everything a string when it can be a primitive in JS.
# [08:25] <Bert> ... So an arry of numbers.
# [08:25] <dbaron> plinss: should be a map of string -> number or string -> array of number
# [08:25] <Bert> jdaggett: yeah
# [08:25] <Bert> tab: no pb
# [08:26] <Bert> ... Any objections to my proposal?
# [08:26] <Bert> glazou: I like it better.
# [08:26] <Bert> dbaron: Is this ready in next month or so?
# [08:26] <jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0781.html
# [08:26] <Bert> TabAtkins: Cameron is going to add map-likek thing.
# [08:26] <Bert> ... Porposed a few weeks ago.
# [08:26] <jdaggett> interface CSSFontFeatureValuesRule {
# [08:26] <jdaggett> attribute Arraylike<DOMString> familyList; /* An array of family
# [08:26] <jdaggett> name strings. */
# [08:26] <jdaggett> attribute Maplike<DOMString, DOMString> swash; /* A map of feature
# [08:26] <jdaggett> names -> feature values */
# [08:26] <Bert> ... Cannot be string, ...
# [08:26] <jdaggett> attribute Maplike<DOMString, DOMString> styleset; /* Ditto */
# [08:26] <jdaggett> attribute Maplike<DOMString, DOMString> ornaments; /* Ditto */
# [08:26] <jdaggett> ...
# [08:26] <jdaggett> }
# [08:26] <Bert> plinss: [missed]
# [08:26] <glazou> fine by me
# [08:27] <glazou> better than just one large string
# [08:27] * Joins: cabanier (~cabanier@public.cloak)
# [08:27] <Bert> tab: Yes, could just manually put it all in by hand, but ideally use IDL.
# [08:27] <Bert> glazou: Resolve on Tab proposal?
# [08:27] <Bert> jdaggett: Is that the one in IRC?
# [08:27] <Bert> plinss: without string.
# [08:28] <Bert> jdaggett: Others are interested in implem,enting it?
# [08:28] <Bert> dbaron: you, tab?
# [08:28] <Bert> TabAtkins: maybe, probabaly not, working on syntax...
# [08:28] <Bert> dbaron: fine with proposal, worried that nobody implements it.
# [08:29] * Joins: Ms2ger (~Ms2ger@public.cloak)
# [08:29] <Bert> plinss: what is dbaron's q precisely?
# [08:29] <Bert> dbaron: New IDL concept, or add a lot of hand writing JS
# [08:29] <Bert> ... Maybe 2 months of work.
# [08:29] <Bert> plinss: You have to do that soon anyway.
# [08:29] <Bert> jet: hand-written bindings nowadays.
# [08:30] <Bert> TabAtkins: More verbose.
# [08:30] <Bert> plinss: WebIDL is on its way up.
# [08:30] <dbaron> s/jet:/jet: we don't write/
# [08:30] * Ms2ger RRSAgent, pointer?
# [08:30] * RRSAgent See http://www.w3.org/2013/06/06-css-irc#T06-30-02
# [08:30] <Bert> dbaron: I think we can resolve.
# [08:30] <Bert> RESOLVED: Tab;'s proposal for OM
# [08:30] <plinss> FWIW: WebIDL replacement: https://github.com/w3ctag/jsidl
# [08:31] <Bert> jdaggett: next issue is
# [08:31] <Bert> ... feauture value blocks in spec,
# [08:31] <Bert> ... fantasai says they should just be called at-rules.
# [08:31] <Bert> ... But I think they are different.
# [08:31] <Bert> ... User defined identifiers.
# [08:31] <Bert> ... The way they compound is an issue.
# [08:32] <Bert> ... I tink it is important to day this is different form other at-rules, with descriptors.
# [08:32] <Bert> Tab: That is just about terminology.
# [08:32] <fantasai> whttp://www.w3.org/TR/CSS21/syndata.html#at-rules
# [08:32] <jerenkrantz> is the resolved proposal the one from: http://lists.w3.org/Archives/Public/www-style/2013May/0781.html ?
# [08:32] <Bert> ... It starts with an 2-keyword, all at-rules ar edifferent already. so it is just an at-rule.
# [08:32] <fantasai> " At-rules start with an at-keyword, an '@' character followed immediately by an identifier (for example, '@import', '@page').
# [08:32] <fantasai> An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first. "
# [08:32] <Bert> s/2/@/
# [08:33] <Bert> glenn: Confusing for users to try and distinguihs them.
# [08:33] <stearns> jerenkrantz: yes, with a change from string to numbers (as far as I understood)
# [08:33] <Bert> fantasai: CSS 2 calls it an at-rule when it starts with an at-keyword.
# [08:33] <Bert> jdaggett: Yes, parses like an at-rule.
# [08:33] * fantasai if it looks like an at-rule, parses like an at-rule, it is an at-rule.
# [08:33] <Bert> ... Shoild we not call it something else?
# [08:33] <jerenkrantz> stearns: Thanks.
# [08:33] <Bert> TabAtkins: Within the spec, call it what you want.
# [08:34] <Bert> ... Whatever makes sense. But technically it is an at-rue.
# [08:34] <Bert> fantasai: Must be clear that it parses like one.
# [08:34] <Bert> TabAtkins: ; But "font feaure value block" or whatever is fine.
# [08:34] <Bert> ... It expresses the concept.
# [08:34] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:34] <Bert> jdaggett: So I need to say somewhre thet at-feature-value blocks aare at-ules.
# [08:35] <Bert> jdaggett: issue on font load postpone to tomoorow?
# [08:35] <Bert> fantasai: Other issue is override.
# [08:35] <Bert> jdaggett: Tomoorow, too?
# [08:35] <Bert> fantasai: sure
# [08:36] <Bert> jdaggett: Than that is it for fonts for now.
# [08:36] <Bert> s/Than/Then/
# [08:36] <Bert> Topic: Syntax
# [08:36] <Bert> TabAtkins: tokeinzation changes
# [08:37] <Bert> ... To match HTML, NUL chars are converted into replacement chars.
# [08:37] <Bert> ... Don't know why HTML does it, but at least it means CSS inside HTML is same as CSS in a file.
# [08:37] <Bert> fantasai: Replacement char is valid identidier char, could be weird.
# [08:37] <Bert> TabAtkins: Nobody puts NUL in a style sheet....
# [08:38] * fantasai probably would have turned it into a space, less intrusive
# [08:38] <Bert> RESOLVED: NUL gets turned into Replacement char.
# [08:38] <Bert> tab: non-ascii range
# [08:38] <Bert> SimonSapin: We already changed that.
# [08:39] <Bert> glenn: Isn't the name non-ascii wrong then?
# [08:39] <SimonSapin> s/changed/resolved on/
# [08:39] <Bert> TabAtkins: No it now it includes *all* non-ascii.
# [08:39] <Bert> TabAtkins: comments
# [08:39] <Bert> ... tokenizer never emits them.
# [08:40] <Bert> plinss: What about comments between idents?
# [08:40] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [08:40] * Quits: Rossen (~Rossen@public.cloak) ("Page closed")
# [08:40] <Bert> TabAtkins: Yes, serialzier forces an empty comment there.
# [08:40] * Joins: zcorpan (~zcorpan@public.cloak)
# [08:40] <Bert> plinss: OK, but does it change parsing behavior anywhere?
# [08:41] <Bert> [tab draws on whiteboard]
# [08:41] * Joins: r12a (rishida@public.cloak)
# [08:41] * Joins: Tav (~tbah@public.cloak)
# [08:41] <Bert> tab: It should just be an internal simplifvation
# [08:42] <Bert> Bert: Not sure what you mean.
# [08:43] * krit Another !/**/important syntax discusion
# [08:43] <dbaron> Bert: there is no tokenization process
# [08:44] <dbaron> [argument between Bert and Tab/peterl/etc.]
# [08:44] * Joins: ivan (ivan@public.cloak)
# [08:44] <Bert> bert: [worried about how people interpret "not emit"]
# [08:45] <Bert> TabAtkins: It describes hwo you serialize.
# [08:45] * Joins: Rossen (~Rossen@public.cloak)
# [08:45] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [08:45] * Joins: cabanier (~cabanier@public.cloak)
# [08:45] <Bert> glazou: We said in the paast that one way to preserve comments was to preserve them combined at the end.
# [08:45] <Bert> ... Important for editors.
# [08:46] <Bert> glazou: comments should be in original position, but cnnot always be done.
# [08:46] <dbaron> RESOLVED: loosen the rules describing the way comments are serialized
# [08:47] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [08:47] <dbaron> http://dbaron.org/css/test/2013/urange-token
# [08:48] <Bert> TabAtkins: CSS 2 defines unicode range tokens in lazy way
# [08:48] <Bert> fantasai: The difference is detectable.
# [08:48] <Bert> dbaron: By means of counter increment.
# [08:48] <Bert> fantasai: No real reason to not keep the same.
# [08:49] <Bert> ... Do not chnage the token.
# [08:49] <Bert> ... nder your rules some old are not longer valid, and it is detecatable.
# [08:49] <Bert> tab: No, not detectable.
# [08:49] <Bert> ... U+2?3?4?
# [08:50] <Bert> fantasai: We have to range chaecking.
# [08:50] <Bert> s/to/to do/
# [08:50] <Bert> TabAtkins: No, [describes three cases]
# [08:50] <Bert> dbaron: css3-fonts doesn't say it gets thrown out.
# [08:51] <Bert> jdaggett: what gets thrown out?
# [08:51] <dbaron> U+400-3ff
# [08:51] <Bert> dbaron: fonts spec not clear
# [08:51] <dbaron> unicode-range: U+100-1ff, U+400-3ff
# [08:51] <Bert> ... Is [above] a syntax error?
# [08:51] <Bert> ... Is that empty range or invalid and throw away whole line?
# [08:52] <Bert> [tab and fantasai disagree on previous discussions]
# [08:52] <Bert> TabAtkins: Invalidate whole descriptor.
# [08:52] <Bert> dbaron: Is it just an empty range or invalid?
# [08:52] <Bert> jdaggett: Wording to say that range has to contain valid chars.
# [08:52] <Bert> dbaron: No implementation conformacne requirement.
# [08:53] <fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0564.html
# [08:53] <Bert> jdaggett: you say wording is unclear.
# [08:53] <Bert> dbaron: I can send comment about that, later.
# [08:53] <Bert> TabAtkins: The only relevance of my change os for mixture of digits and digits.
# [08:54] <Bert> ... CSS 2.1 created invalid range, which was then thrown away.
# [08:54] * Quits: ivan (ivan@public.cloak)
# [08:54] <Bert> ... Fnal behavoir is the same..
# [08:54] <Bert> fantasai: why chage. Let's not do tokenaztion changes.
# [08:55] <Bert> TabAtkins: Easier to parse.
# [08:55] <Bert> bert: depnds on parsing suystem.
# [08:55] <Bert> tab: In mine token is always correct.
# [08:55] <Bert> TabAtkins: Unicode range token only valid in one property.
# [08:56] <Bert> plinss: Then I'm not so bothered.
# [08:56] <Bert> Bert: But why change it.
# [08:56] <Bert> fantasai: Current is fine.
# [08:56] <Bert> dbaron: I don't believe the change is undetectable.
# [08:57] <fantasai> Gecko implements the 2.1 definition
# [08:57] <Bert> Tab: Maybe in future.
# [08:57] <dbaron> I also don't mind the change.
# [08:57] <Bert> plinss: That's is why it gets important.
# [08:57] <Bert> TabAtkins: But I have to write more text to accept the old syntax.
# [08:58] <Bert> glenn: Font family quoted string that is empty: seems not prohibited.
# [08:58] <Bert> dbaron: You might have a font with that name.
# [08:58] * fantasai doesn't like changing things like this just because someone felt like it, should only change it if there's a real benefit to it imho
# [08:58] <Bert> glenn: Far fetched, but itis an answer...
# [08:59] <Bert> TabAtkins: Not a sybtax question, question for fonts.
# [08:59] <Bert> plinss: Whether you can test the unicode range syntax difference now is not the question.
# [09:00] <Bert> ... You're change maybe gives us more flexibility to not add white space in future properties.
# [09:00] <Bert> fantasai: Not really, some unicode rabges end in digits, so not helpful.
# [09:00] <Bert> dbaron: No, not helpful, there are too many different kinds of unicode range tokens. Often require a space anyway.
# [09:00] <Bert> plinss: Then the change is irrelevant.
# [09:01] <dbaron> I agree the change is safe, and I agree it's pointless.
# [09:01] <Bert> ... bert: But why chage it if is not broken?
# [09:02] <Bert> [3 hands for tab's proposal 2 against]
# [09:02] <Bert> TabAtkins: bad_url token and bad_string token.
# [09:03] <Bert> plinss: What we talked about yesterday?
# [09:03] <Bert> TabAtkins: Yes.
# [09:03] <Bert> liam: Current UAs.
# [09:03] <Bert> TabAtkins: Our parsing is wrong I believe.
# [09:04] <Bert> glenn: doesn't seem right.
# [09:04] <Bert> ... Wouldn't call it valid.
# [09:04] <Bert> plinss: It is not gray. We know when to throw a property away.
# [09:05] <Bert> TabAtkins: New attribute matching operatore are imported into tokenizer.
# [09:06] * Quits: r12a (rishida@public.cloak) (Ping timeout: 180 seconds)
# [09:07] <Bert> Bert: The new attribute operatores are not tokens, they are two tokens.
# [09:07] <Bert> Tab: But selectors defiend them as tokens.
# [09:08] <Bert> Bert: No, selectors defiend how to parse selecotrs, not how to parse css.
# [09:09] <Bert> plinss: Don't agree with bert's argument, but accept the point.
# [09:09] <Bert> ... They will always be atoken if we take tab's proposal, and we remove the possibility of useing them as as part of differnet symntax
# [09:09] <Bert> TabAtkins: : Reduces ossibilities, yes.
# [09:10] <Bert> plinss: There is an impact.
# [09:10] <dbaron> TabAtkins: it doesn't reduce possibilities, but it might complicate grammars in the future
# [09:10] <Bert> s/Reduces ossibilities/makes futre syntax to have to be defined slightly differently/
# [09:10] <Ms2ger> s/futre/future/
# [09:10] <Bert> plinss: there is a general pont about selecor syntax leaking into rest of syntax.
# [09:11] <Bert> TabAtkins: "||" is used in selectors 4
# [09:11] <Bert> ... Made it into a token.
# [09:11] <Bert> ... Because it clashes with namespace selectors.
# [09:11] <Bert> plinss: Are we giving up too much to avoid 2-token look-ahead?
# [09:12] <Bert> TabAtkins: I don't know.
# [09:12] <Bert> ... I heard 1-token was nice.
# [09:12] <Bert> plinss: How important is it. You build it and forget about it.
# [09:12] <Bert> dbaron: It is slower.
# [09:13] <dbaron> dbaron: There's a small performance cost to more lookahead, and I don't think it's worth it.
# [09:13] <Bert> ... I tend to think more lookahead is slower.
# [09:14] <Bert> TabAtkins: I added a comma token.
# [09:14] <Bert> ... There was a colon and a semicolon already.
# [09:16] <Bert> [Discussion about where COMMA is used. It is used in other modules, not in syntax itself]
# [09:17] <Bert> TabAtkins: numebrs include sign, scie notation is allowed
# [09:17] <TabAtkins> url(foo bar)
# [09:17] <Bert> TabAtkins: bad uri
# [09:17] <TabAtkins> bad-url("url(foo ")
# [09:17] * Joins: justin (~justin@public.cloak)
# [09:17] <Zakim> -Meeting_Room
# [09:18] * Quits: justin (~justin@public.cloak) ("Page closed")
# [09:18] <Bert> (I don't see why we need tokenizer for number)
# [09:18] <jdaggett> can someone stitch up the phone again?
# [09:18] <TabAtkins> url(foo bar[baz)
# [09:18] <dbaron> jdaggett, shans is working on it
# [09:18] <jdaggett> thx
# [09:18] <Bert> TabAtkins: this case [above] will be different.
# [09:19] <Zakim> +??P0
# [09:19] * dbaron Zakim, ??P0 is Meeting_Room
# [09:19] * Zakim +Meeting_Room; got it
# [09:19] <jdaggett> cool, thanks!!
# [09:19] <Bert> ... this is unlikely to have any bad effects.
# [09:19] <Bert> ... Have no bug reports.
# [09:19] <Bert> fantasai: You're parsing invalid stuff anyway.
# [09:20] <Bert> dbaron: It is about parens *after* the piece that already makes it invalid.
# [09:20] <fantasai> fantasai^: So if someone found a problem with your behavior, they'd be fixing their style sheet, not filing a bug
# [09:20] <Bert> plinss: I want the token to close according to error recovery rules. Respect paren matching.
# [09:21] <Bert> dbaron: this is recent, but it simplifes.
# [09:21] <Bert> ... Matches some implementations.
# [09:21] <fantasai> dbaron^: We've fiddled with this multiple times during 2.1 cycle
# [09:21] <dbaron> s/recent/recent -- something we were fiddling with to quite late in CSS 2.1/
# [09:22] <Bert> Bert: I don't udnerstand yet...
# [09:22] <Bert> [dbaron explains]
# [09:24] <dbaron> url(foo bar[)
# [09:24] <dbaron> url(foo "bar[)
# [09:25] <dbaron> peterl: ok, I'm happy with it too
# [09:28] <Bert> [discussion about where the error recovery picks up]
# [09:28] <fantasai> Ok, this makes sense to me seeing this example
# [09:29] <Bert> Bert: I don't care about error recovery, si I'm fine, but be aware that you change the measning of existing style sheets.
# [09:29] <Bert> Tab: Yes, we had no bug reports, so don't think it is a problem.
# [09:29] <Bert> tab: CSS 2 grammar doens't cover all inputs.
# [09:30] <Bert> ... Error recovery not defined.
# [09:30] <Bert> ... So I'm defining error recovery.
# [09:30] <Bert> dbaron: I'd like to review this more.
# [09:30] <dbaron> dbaron: Did you fix the cases where CSS 2.1 didn't allow CDO and CDC in some places?
# [09:30] <Bert> ... What about CDO CDC?
# [09:32] <Bert> Bert: As long as it is only about error recovery for CDO/CDC in more places, fine with me.
# [09:32] <fantasai> ScribeNick: fantasai
# [09:32] <fantasai> An+B notation
# [09:32] <fantasai> TabAtkins: The notation is incompatible with CSS tokenization
# [09:33] <fantasai> TabAtkins: For example, 5n-3 tokenizes as a dimension
# [09:33] <fantasai> TabAtkins: But we need to split it up into 5, n, -, 3
# [09:33] <fantasai> TabAtkins: Implementations right now have to guess where it ends ... so far easy because of close-parens
# [09:33] <fantasai> TabAtkins: Then reserialize and reparse
# [09:34] <fantasai> TabAtkins: Wanted to redefine an+b in terms of CSS tokens
# [09:34] <fantasai> TabAtkins: I can get it almost identical to defined behavior
# [09:34] <fantasai> TabAtkins: But there are two changes
# [09:34] <fantasai> s/two/two small/
# [09:34] <fantasai> dbaron: Think the WS change is not small
# [09:34] <fantasai> TabAtkins: First change is that +n or +n+2 ok
# [09:34] <fantasai> TabAtkins: but + n not ok
# [09:35] <fantasai> TabAtkins: Similarly -n vs. - n
# [09:35] <fantasai> TabAtkins: Issue is that when you tokenize these, +n becomes 2 tokens
# [09:35] <fantasai> TabAtkins: so does + n
# [09:35] <fantasai> TabAtkins: -n and - n tokenize differently
# [09:35] <fantasai> TabAtkins: Property grammars ignore white space
# [09:36] <fantasai> TabAtkins: So can't distinguish
# [09:36] <Bert> fantasai: I don't think ths needs to change.
# [09:36] <fantasai> dbaron: Tab just made up this idea of property grammars
# [09:36] <fantasai> TabAtkins: propdef grammars don't talk about ws
# [09:36] <fantasai> dbaron: I don't want to change the space rules here
# [09:37] <fantasai> TabAtkins asks how parsers work
# [09:37] <fantasai> dbaron says Gecko has a flag about whether ws is paid attention to
# [09:38] <fantasai> In WebKit, apparently WS tokens are omitted automatically when you ask for a token
# [09:38] <fantasai> fantasai: how can be possible in selectors?
# [09:38] <dbaron> div*p
# [09:38] <fantasai> Bert: Also numbers, numbers with a sign can't have space between number and sign
# [09:39] <fantasai> side discussion of NUMBER tokens
# [09:40] <fantasai> dino: White space is gone by the time you try to parse things
# [09:40] <fantasai> TabAtkins: How do you parse calc() and selectors then?
# [09:40] <fantasai> krit: ... something about whitespace and ident
# [09:41] <fantasai> RESOLVED: No spacing changes in An+B syntax
# [09:41] <krit> s/something about whitespace and ident/something about whitespace and ident in WebKit/
# [09:42] <fantasai> TabAtkins: +n-\33
# [09:42] <fantasai> TabAtkins: parses as "+" "n-3"
# [09:42] <fantasai> TabAtkins: which looks like An+B
# [09:43] <fantasai> TabAtkins: So, change to allow escaping in cases where the tokenization derives from idents
# [09:43] <fantasai> TabAtkins: Which probably matches implementations
# [09:43] <fantasai> Bert: So escaping before reparsing?
# [09:43] <fantasai> TabAtkins: no reparsing
# [09:44] <jerenkrantz> RRSAgent: make minutes
# [09:44] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html jerenkrantz
# [09:44] <fantasai> TabAtkins: escaping was handled much earlier in parsing process
# [09:44] <fantasai> TabAtkins: Disallowing it would create a major layering violation
# [09:44] <fantasai> TabAtkins: By the time you care about whether something is an+b, you've lost the original representation
# [09:45] <fantasai> plinss: So this scenario produces a valid ident, with content "n-3" as the string
# [09:45] <fantasai> plinss: How does that become an an+b?
# [09:45] <fantasai> dbaron: Spec says if you have ident "-n-" followed by digits, then it's valid an+b
# [09:45] <fantasai> dbaron: I think this is far saner than the route we went down with URL, where we made it a separate token
# [09:46] <fantasai> TabAtkins: All three of these are equivalent, except they tokenize completely different
# [09:46] <fantasai> n - 3
# [09:46] <fantasai> n- 3
# [09:46] <fantasai> n -3
# [09:46] <fantasai> n-3
# [09:46] <fantasai> discussion of parsing mechanics among Bert, plinss, and Tab
# [09:49] <dbaron> [discussion of something else between fantasai and glazou]
# [09:49] * fantasai we were discussing something else off-topic
# [09:49] * glazou suggest switching to RPN
# [09:50] <fantasai> RESOLVED: escaping in An+B falls out of tokenization
# [09:50] <fantasai> TabAtkins: That's all the syntax changes that we've reviewed now
# [09:51] <fantasai> TabAtkins: So, can I publish yet?
# [09:51] <fantasai> dbaron: I think the efforts here are worthwhile, but I would like to review the bracket-matching part before FPWD. I haven't had time yet
# [09:52] <fantasai> dbaron: I'm worried because I think once we have FPWD, people will only look at this, not at CSS2.1
# [09:52] <fantasai> dbaron: So if we don't fix something now, it will b ehard to fix later
# [09:52] <fantasai> dbaron: And I'm worried because it was originally reverse-engineered from the worst implemenation (WebKit)
# [09:52] <fantasai> TabAtkins: I won't deny that.
# [09:53] <fantasai> Bert: I can't understand this draft, apart from the railroad diagrams. Can you put more of those, or put grammar rules?
# [09:53] <fantasai> TabAtkins: I think I have diagrams for everything in the spec
# [09:54] <fantasai> fantasai: does your spec define what a style rule is, what a declaration is, what these things mean?
# [09:54] <fantasai> TabAtkins: yes
# [09:54] <fantasai> SimonSapin: No, it doesn't
# [09:54] <fantasai> fantasai: I think we need to add such a section, since this part of 2.1 logically belongs here.
# [09:55] <Bert> (Seems all the production rules have diagrams.)
# [09:55] <fantasai> plinss: You asked for FPWD, but there's an existing css3-syntax draft
# [09:55] <jdaggett> what is peter saying? he's speaking in "peter quiet voice" again...
# [09:55] <fantasai> fantasai: From process POV, no. But effectively yes.
# [09:55] <fantasai> plinss: Just making sure that we plan to replace what's out there and is 10 years old
# [09:55] <fantasai> TabAtkins: yes
# [09:56] <fantasai> TabAtkins: (to fantasai) Maybe I'll expand the Description of CSS's Syntax section
# [09:56] <fantasai> SimonSapin: And make it normative
# [09:56] <fantasai> fantasai: We need something that defines how to interpret a CSS style sheet.
# [09:57] <fantasai> Topic: Regions/Shapes/Exclusions
# [09:57] <fantasai> stearns: Events and Fragmentation
# [09:57] <fantasai> stearns: In fragmented flows, comes up in regions, but also issue in other types of fragmentation...
# [09:57] <fantasai> stearns has drawn some boxes
# [09:58] <fantasai> There is a big box, which represents the thing that contains the fragmentainers.
# [09:58] <fantasai> Inside are two fragmentainers, FC1 and FC2
# [09:58] <fantasai> stearns: These could be regions, pages, column boxes, whatever
# [09:58] <fantasai> stearns: Crucial thing is that fragmented flow has an article, which contains a paragraph, and there's a break at some point in the paragraph
# [09:58] <fantasai> (represented by boxes A and P)
# [09:59] <fantasai> stearns: Issue is when you click in one of the fragments of the P
# [09:59] <fantasai> stearns: The fragmentainer never hears about it
# [09:59] * glazou stearns just introduced the µtimbl unit for the 'speech-rate' property
# [09:59] <fantasai> stearns: The event goes out from P to A to the outer box, skips FC boxes
# [09:59] <fantasai> SimonSapin: Are the two FC boxes generated from the same element?
# [10:00] <fantasai> dbaron: In overflow fragments, yes, but not in Regions
# [10:00] <fantasai> dino: You said it doesn't matter, but is FC1 or FC2 regions, or columns... is A a child of that?
# [10:00] <fantasai> stearns: In overflow fragments A would not be a child of either container, would be a child of outer box
# [10:00] <fantasai> dbaron: In overflow fragments not that distinction, just the one level
# [10:01] <fantasai> stearns: If I said :nth-fragment(2):hover, I want that fragment container to respond to hovering over this part of the paragraph, and not respond to hovering over the other part of the paragraph
# [10:01] <fantasai> Bert: Could have :hover on the outer box
# [10:01] <fantasai> stearns: I want the container to change
# [10:02] <fantasai> stearns: Only when it's hovered inside, not when the other fragment is hovered inside
# [10:02] <fantasai> stearns: And in Regions these can be different elements
# [10:02] <fantasai> dino: In A have one region element you're flowing into. Events don't get seen by region element
# [10:02] <Bert> (DIV:hover::slot(fc2) {... highlight... }.)
# [10:02] <fantasai> stearns: No
# [10:03] <fantasai> dino: you can't write a rule that says ::region:hover
# [10:03] <fantasai> stearns: right, and I want to
# [10:03] <fantasai> dino: me too
# [10:03] <fantasai> stearns: Regions has an API that allows you to determine which region got clicked.
# [10:03] <fantasai> stearns: Doesn't work for hover but works for click events
# [10:03] <Bert> (Forget what I just said.)
# [10:03] * fantasai needs a tissue, anyone help?
# [10:03] <fantasai> stearns: That workaround only works for events, doesn't work for :hover styling
# [10:04] <fantasai> stearns: But that workaround also doesn't work for fragmented elements
# [10:04] <stearns> http://wiki.csswg.org/spec/css3-regions/user-event-handling
# [10:04] <fantasai> stearns: There are two proposals for handling this
# [10:04] <fantasai> stearns: First is for fragmented flows in general
# [10:05] <fantasai> stearns: When you have event bubbling in a fragmentation context
# [10:05] * plh starts wondering if it's safe for him to see next to the window at the 30th floor of a building, while being in a CSS f2f meeting...
# [10:05] <fantasai> stearns: Event goes up through the chain as normal to the fragmentation root
# [10:05] * plh s/see/sit/
# [10:05] <fantasai> stearns: The thing that contains the content that is fragmented
# [10:05] <fantasai> stearns: At that point, the fragment container is inserted in the bubbling
# [10:05] <fantasai> stearns: And the bubbling continues with whatever contains the fragment container, up through the hierarchy.
# [10:06] <fantasai> dbaron: Are you talking about event bubbling because you want to change :hover, or because you want to change what event handlers get?
# [10:06] <fantasai> stearns: Yes.
# [10:06] <fantasai> jdaggett: Issue on columns as well
# [10:06] <SimonSapin> s/Yes./Yes. Both./
# [10:06] <fantasai> stearns: Once we get to point of having addressable columns, can be done for columns
# [10:06] <Zakim> -jdaggett
# [10:06] <fantasai> stearns: If you want to know what page an even twas on, would have page inserted in event/style loop
# [10:07] <TabAtkins> s/jdaggett/djovey/
# [10:07] <fantasai> stearns: I'm actually not sure whether bubbling for CSS :hover is actually defined anywhere
# [10:07] <TabAtkins> s/djovey/jdovey/
# [10:07] <fantasai> stearns: I assume it does the same
# [10:07] <fantasai> dbaron: It's not really bubbling, but it's defined
# [10:07] <Zakim> +[IPcaller]
# [10:07] <jdaggett> zakim, ipcaller is me
# [10:07] <Zakim> +jdaggett; got it
# [10:07] <fantasai> http://dev.w3.org/csswg/selectors4/#the-hover-pseudo
# [10:07] <fantasai> "The parent of an element that is :hover is also in that state. "
# [10:08] <jdaggett> was there a question?
# [10:08] <jdaggett> i'm muted...
# [10:08] <fantasai> stearns: One way to solve this, is, in a fragmentation context, insert the fragmentainer at the appropriate spot
# [10:08] <fantasai> stearns: One more thing in the appropriate spot
# [10:08] <fantasai> dino: If it's a region, then does it bounce back to the ancestor chain or go up the region's ancestors?
# [10:08] <fantasai> stearns: Goes up the region's ancestors
# [10:09] <fantasai> This essentially circumvents the element's own ancestor chain
# [10:09] <fantasai> TabAtkins: Problem you're describing is virtually identical to problem with Shadow DOM and events
# [10:09] <fantasai> TabAtkins: Shadow DOM can rearrange content in a similar way
# [10:09] <fantasai> TabAtkins: Regions is slightly more general issue, but can be safely generalized under this as well
# [10:09] <fantasai> TabAtkins: Don't know precise details of what we do, but if you want details will have to ask Dmitry, who just went home
# [10:10] <fantasai> stearns: Shadow DOM describes it as DOM manipulation
# [10:10] <fantasai> stearns: follow reordered DOM hierarchy
# [10:10] <fantasai> TabAtkins: After reordering and following up
# [10:10] <fantasai> TabAtkins: Things that aren't in the Shadow DOM have no way of telling that the event passed through the Shadow DOM
# [10:10] <fantasai> stearns: That's very important to shadow DOM, not so important here.
# [10:11] <fantasai> TabAtkins: Could break things if you add pseudos you didn't expect
# [10:11] <fantasai> stearns: It will continue to multicol element, just one added stop
# [10:11] <MikeSmith> RRSAgent, make minutes
# [10:11] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html MikeSmith
# [10:11] <fantasai> ... regions ...
# [10:12] <fantasai> fantasai: In case of regions, you might wind up not hitting your ancestors, because going up region's ancestor chain now.
# [10:12] <fantasai> fantasai: whereas other cases, you always walk up all your ancestors, just might make extra stops along the way
# [10:12] <fantasai> stearns: If you go through email thread linked from wiki
# [10:13] <fantasai> stearns: Went through number of iterations tryng to figure out how to preserve event bubbling chain
# [10:13] <fantasai> stearns: or dealing with this osmehow
# [10:13] <fantasai> stearns: everything got way too messy
# [10:13] <fantasai> stearns: Once you've put content into this fragmented flow, makes more sense to me for events to follow region's ancestor chain
# [10:14] <fantasai> fantasai: Depends on what you're trying to do
# [10:14] <fantasai> fantasai: Depends on how much you're scrambling the tree, and how much you are handling events locally vs. talking to things higher in the document tree
# [10:14] <fantasai> dino: Think it's very confusing to go up region chain
# [10:15] <fantasai> dino: If you wrote selector parent-element > child-content
# [10:15] <fantasai> dino: Expect that selector to apply
# [10:15] <fantasai> dino: wrote parent-element:hover > child-content to work
# [10:15] <fantasai> dino: But break that expectation
# [10:15] <fantasai> stearns: ...
# [10:15] <fantasai> stearns: But named flow, taking boxes from parent, putting them over here
# [10:16] <fantasai> stearns: these boxes should be ones responding to user events because you made that disassociation
# [10:16] <fantasai> dbaron: I find it really weird to have events not follow the DOM
# [10:16] <fantasai> dbaron: They're a DOM structure
# [10:16] <fantasai> dbaron: And I think separation of content and presentation makes it really weird for box-tree structure to mess with DOM structure
# [10:16] <fantasai> stearns: Have a response to hover styling?
# [10:16] <fantasai> dbaron: I think hover styling is separate from events
# [10:16] <fantasai> TabAtkins: Can be easier to handle :hover going two directions up the tree, than events going up the tree
# [10:17] <fantasai> TabAtkins: Could do complicated thing now with pseudo-classes, rather than events
# [10:17] <dbaron> dean: what happens with elementFromPoint()?
# [10:17] <dbaron> dbaron: it depends if there's content at that point in the region -- you get the most deeply nested thing
# [10:18] <fantasai> dino: Want to understand why :hover and events could be different
# [10:18] <fantasai> dbaron: :hover is a CSS concept
# [10:18] <fantasai> dino: Base don mouse events
# [10:18] <fantasai> dbaron: That's changed over time. It happens to be true now
# [10:18] <fantasai> plinss: We have whole dichotomy of things like mouse events, that deal with geometry of presentation
# [10:19] <fantasai> plinss: These fire at the DOM tree, kindof broken
# [10:19] <fantasai> dbaron: We could have another type of mouse event that doesn't bubble, but that you fire at everything in that geometry
# [10:19] <fantasai> dbaron: We do sortof have that for mousover and mouseout
# [10:19] <fantasai> stearns: Another solution is to add a mode to pointer-events property
# [10:19] <fantasai> stearns: So you could say for e.g. relpos'd box, events will follow box tree
# [10:20] <fantasai> Rossen: Going through iterations, another idea for adding region as a separate target
# [10:20] <fantasai> stearns: Other mode, other solution is to have this switch, where for certain elements that you choose, you have the event just run through the visual layers
# [10:20] * fantasai likes Rossen's idea best
# [10:20] <fantasai> TabAtkins: element with fragment parent, goes to fragment parent rather than real parent?
# [10:21] <fantasai> stearns: Goes to whatever's displayed underneath it, which in fragment case would be fragmentainer
# [10:21] <fantasai> dino: One option is following DOM tree
# [10:21] <fantasai> dino: second is following box tree
# [10:21] <fantasai> dino: Third is following painting order
# [10:21] <fantasai> stearns: Second solution is not doing the middle event
# [10:21] <fantasai> stearns: Right now pointer-events can be normal, they go up the DOM tree
# [10:21] <fantasai> stearns: Can say pointer-events: none;, which ignores pointer events
# [10:22] <fantasai> stearns: Switch would trigger just painting order
# [10:22] <fantasai> stearns: You'd get the relpos box and whatever is underneath it
# [10:22] <fantasai> TabAtkins: So third one is elementsFromPoint() and walk that list
# [10:23] <fantasai> plinss: Where are you setting this switch?
# [10:23] <fantasai> The target of the element will decide on the path of the event
# [10:23] <jdaggett> followup on the subscript/superscript metric discussion, here's the example from hamburg:
# [10:23] <jdaggett> http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png
# [10:23] <fantasai> dino: If you did something like this, set it on ancestor, does ???
# [10:24] <fantasai> dino: Doing propagation based on painting order is quite complicated, because implementations might forget exactly the order for perf reasons
# [10:24] <jdaggett> rssagent, make minutes
# [10:24] <fantasai> some concerns about implementation all around
# [10:25] <fantasai> TabAtkins: We have elementsFromPoint() already, regardless need to be able to get at that list
# [10:25] <leif> rrsagent, make minutes
# [10:25] <RRSAgent> I have made the request to generate http://www.w3.org/2013/06/06-css-minutes.html leif
# [10:25] <fantasai> stearns: For pointer-events: none, still need to have that info as well; that requires one answer, this case needs the whole stack
# [10:25] * leif ftfy jdaggett
# [10:26] * Joins: ivan (ivan@public.cloak)
# [10:26] <fantasai> TabAtkins: For the case that shoudl hop through the fragment order, should that just be a generic box order movement?
# [10:26] <fantasai> TabAtkins: Anything else outside fragmentation would also affect that
# [10:26] <fantasai> stearns writes out options
# [10:26] <fantasai> 1) Fragment container insertion
# [10:26] <fantasai> 2) Painting order switch
# [10:26] * jdaggett leif, thx
# [10:27] <fantasai> stearns: for #1, issue of where to put the fragmentation container in the order
# [10:27] <fantasai> stearns: Painting orde rswitch is more general, works for other positioning things as well, also works for any type of fragment conatiner
# [10:27] <fantasai> TabAtkins: Do have to define that the event path includes fragment containers
# [10:27] <fantasai> TabAtkins: So can't lean on that concept entirely
# [10:28] <fantasai> fantasai: We don't have those eyt
# [10:28] <fantasai> s/eyt/yet/
# [10:28] <fantasai> TabAtkins: So, suggesting go with paint order one for now, possibly also introduce box tree
# [10:28] <fantasai> plinss: what's diff between paint order and box tree?
# [10:28] <fantasai> TabAtkins: paint order just go through layers under that point
# [10:28] <fantasai> TabAtkins: box tree would jump from element to its containing block, not hit things underneath it necessarily
# [10:29] <fantasai> Rossen: ...
# [10:29] <fantasai> Rossen; Final transformed position, thus actual behind element is the furthermost ?
# [10:29] <fantasai> Rossen: Subtle difference, but makes a difference once you factor in transforms
# [10:29] <fantasai> Rossen: and relpos I guess
# [10:29] <fantasai> TabAtkins: Fine with leaving out box-tree
# [10:30] <fantasai> asking about who implements elementsFromPoint()
# [10:30] <fantasai> krit: Suggested couple months ago, not sure that anyone implements it
# [10:30] <fantasai> dbaron: Dont' see it in CSSOm or CSSOM View
# [10:30] * heycam|away is now known as heycam
# [10:31] <fantasai> ...
# [10:32] <Bert> (Other issue: If '::foo' is a region, then '::foo:hover' would be the expected synntax to select it in hover state... but that syntax is not allowed by css3-selectors.)
# [10:33] <fantasai> stearns: So if I'm reading the room correctly, people leaning towards pointer-event switch
# [10:34] <fantasai> Bert raises issue against Selectors 4
# [10:34] <fantasai> ::first-line:hover e.g. makes sense, and would work
# [10:34] <fantasai> ::first-line:nth-child() doesn't make sense
# [10:35] <fantasai> fantasai points out that each pseudo-element has to define what it accepts
# [10:35] <fantasai> Bert points out that we need to define which selectors are invalid (cause selector to be thrown out) and which simply don't match anything
# [10:35] <fantasai> </aside>
# [10:35] * glazou would say that ::first-line:nth-child() is not a problem since a visual line has no children so it selects nothing… we don't need to make it invalid
# [10:36] <fantasai> dbaron: This is pretty scary, don't think we should make a change without checking with WebAPI folks
# [10:37] <fantasai> RESOLVED: Work on pointer-events: elements-from-point solution
# [10:37] <fantasai> that will walk the elementsFromPoint chain instead of the ancestor chain
# [10:37] <fantasai> stearns: One of the issues...
# [10:37] <fantasai> stearns: Shapes specification
# [10:37] <fantasai> stearns: Whether we should allow shapes from rendered content
# [10:38] <fantasai> stearns: Think we should, but would like to push it to level 2
# [10:38] <plinss> http://www.w3.org/mid/CDD64C22.3AD08%25stearns@adobe.com
# [10:38] <fantasai> stearns: CSS Shapes atm defines getting shape from an image, and from shapes from basic shape syntax, and I think that is sufficient for first level
# [10:38] <fantasai> stearns: already pushed off SVG elements. Would like to push off rendered content for now.
# [10:38] <fantasai> dbaron: what is it?
# [10:38] <Rossen> http://lists.w3.org/Archives/Public/www-style/2013May/0389.html
# [10:38] <fantasai> stearns: E.g. you have an A rendered large, or repeated background, etc.
# [10:39] <fantasai> stearns: I think it's useful thing to do, but very complicated
# [10:39] <fantasai> Rossen: Think original motivation for that was around time when we were proposing shapes to begin with. One of the use cases was a type of article that becomes a shape
# [10:39] <fantasai> Rossen: extracting shape from rendered text
# [10:39] <fantasai> Rossen: drop-cap, with tight-wrap around it
# [10:40] <fantasai> Rossen: That was original motivation. Agree it's advanced feature for current level of spec
# [10:40] <fantasai> Rossen: If we want to move spec quicker and have big bang for our money
# [10:40] <fantasai> Rossen: Having simpler shapes, easy to define
# [10:40] <fantasai> Rossen: That would hold implementations for quite some time.
# [10:40] <fantasai> fantasai: Makes sense to me. I would prioritize SVG shapes over this feature.
# [10:40] <fantasai> TabAtkins: me too
# [10:41] <fantasai> stearns: Any objections to moving this over?
# [10:41] <fantasai> plinss: Images?
# [10:41] <fantasai> stearns: No, they stay. That's biggest ask aside from SVG
# [10:42] <fantasai> dino: At what resolution do you derive the shape?
# [10:42] <fantasai> ...
# [10:42] <fantasai> stearns: We'll solve that as we get to it
# [10:42] <fantasai> ...
# [10:42] <fantasai> dino: You might have an image that's displayed 100x100 but it's 10000x10000 image, as you zoom you see more pixels, shape might change and suddenly impact layout
# [10:43] <fantasai> TabAtkins: other changes due to not aligning to pixel boundaries too
# [10:43] <fantasai> dino: Need to define exactly the operation you use, masking whatever
# [10:43] <fantasai> stearns: agree
# [10:44] <fantasai> liam: Could get almost effect of text-wrapping around A, by making path in SVG and wrapping around it
# [10:44] <fantasai> stearns: could make polygon with basic shape syntax
# [10:44] <fantasai> stearns: Aren't guaranteed to get the glyph you're expecting, though
# [10:44] <fantasai> stearns: Other issue, in spec, that says ...
# [10:45] <fantasai> krit: ???
# [10:45] <fantasai> RESOLVED: Move contours from rendered content to next level
# [10:45] <fantasai> stearns: Issue on spec on shapes from images
# [10:46] <fantasai> stearns: Security concern of being able to determine contours of alpha channel of image
# [10:46] <fantasai> TabAtkins: Could extract cross-domain info
# [10:46] <fantasai> TabAtkins: Reasonably efficient attack, too
# [10:47] <fantasai> plinss: Imagine image you're putting in page is bar graph of your account balances of your bank
# [10:47] <fantasai> Same-origin or CORS
# [10:47] <fantasai> TabAtkins: Work with Anne, he'll tell you what to do correctly.
# [10:48] <dbaron> annevk is working on http://fetch.spec.whatwg.org/ which makes these things easier to define
# [10:48] <TabAtkins> krit: Same-origin may not protect you if open redirectors are used.
# [10:48] <TabAtkins> TabAtkins: That is always a concern for *everything* that's SOR.
# [10:49] <TabAtkins> dino: I'm not sure SOR is enough.
# [10:49] <fantasai> ScribeNick: TabAtkins
# [10:49] <TabAtkins> dino: [describes an attack that I didn't understand]
# [10:49] <TabAtkins> stearns: You're assuming that a site is wrapping content around a secure image.
# [10:50] <TabAtkins> dino: I'll describe the scenario better in the mail list.
# [10:50] <TabAtkins> krit: For SVG images, that's one of the reasons SVG images aren't allowed to reference images from another domain.
# [10:51] * jdaggett gotta go, hospital dindin time...
# [10:51] <Zakim> -jdaggett
# [10:52] <TabAtkins> TabAtkins: The SVG issue is different. That's about beinga ble to detect when an image is viewed, by including an external ref in that image.
# [10:52] <TabAtkins> krit: It's a different attack, but same scenario.
# [10:52] <TabAtkins> [please describe the attack better]
# [10:52] <TabAtkins> stearns: New topic. The idea is that we should add floats to exclusions, so we have one way of wrapping things around each other.
# [10:53] <TabAtkins> stearns: I propose we dont'. Floats work within the wrapping context, and are their own crazy thing.
# [10:53] * Quits: ivan (ivan@public.cloak)
# [10:53] <TabAtkins> TabAtkins: Does that mean we lose the "exclusions can auto-avoid each other" switch?
# [10:53] <TabAtkins> stearns: No, this is unrelated.
# [10:53] <TabAtkins> Rossen: The two things are kind of joined...
# [10:54] <TabAtkins> stearns: No, they're disjoint. They work differently - it's defined in the spec.
# [10:54] <TabAtkins> Rossen: INline content at the same level as the float will avoid both floats and exclusions, but exclusions penetrate much higher.
# [10:54] * Bert thinks rossen said s/kind of joined/disjoint/
# [10:54] <TabAtkins> Rossen: So they really are disjoint in terms of geometry, and in the stack they have different behavior.
# [10:55] <TabAtkins> Rossen: So keeping them separate is way easier. From an impl point of view, I approached keeping them together with floats, but it started becoming a mess quickly.
# [10:55] <TabAtkins> Bert: Is this just an impl issue?
# [10:56] <TabAtkins> stearns: No, spec issue. The spec says how to construct the wrapping context.
# [10:56] <TabAtkins> stearns: The spec defines that floats create areas that content avoid.
# [10:56] <TabAtkins> stearns: Question is to keep that, or to try and fully harmonize floats with exclusions so they act identically (rather than just similarly).
# [10:57] <TabAtkins> Rossen: It will hypothetically allow you to have an impl with just exclusions, no floats.
# [10:57] <TabAtkins> Bert: If you can explain how they'd behave differently, it would be appreciated.
# [10:57] <TabAtkins> stearns: In the wrapping behavior, they behave the same, for a single flaot and a single exclusion.
# [10:58] <TabAtkins> RESOLVED: Close the flaot/exclusion harmonizing issue.
# [10:59] <TabAtkins> Topic: Syntax editor
# [10:59] <TabAtkins> TabAtkins: I propose adding Simon as Syntax co-editor.
# [10:59] <TabAtkins> RESOLVED: Simon Sapin is Syntax co-editor.
# [11:00] * fantasai is so hungry
# [11:00] * Quits: myakura (~480ee730@public.cloak) ("http://www.mibbit.com ajax IRC Client")
# [11:00] <TabAtkins> RESOLVED: Exclusion wrapping context does not include floats. (Clarifying two resolutions ago.)
# [11:00] * Ms2ger passes fantasai a bar of chocolate
# [11:00] * fantasai hopes it's dark chocolate, because cough suppressant would be nice too
# [11:00] * Quits: jet (~junglecode@public.cloak) (jet)
# [11:01] * dbaron wonders why fantasai didn't consume enough food at the free lunch offering arbitrary quantities of food
# [11:01] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [11:01] * jdovey has some Tylenol, if that's useful?
# [11:01] * fantasai is too small?
# [11:02] <TabAtkins> Meeting closed for the day.
# [11:02] * Joins: lmclister (~lmclister@public.cloak)
# [11:03] * fantasai http://www.candyblog.net/blog/item/a_bit_of_medicine
# [11:04] * Quits: jdovey (~jdovey@public.cloak) (jdovey)
# [11:05] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [11:05] * Quits: rhauck1 (~Adium@public.cloak) (Client closed connection)
# [11:05] * Quits: krit (~krit@public.cloak) ("Leaving.")
# [11:05] * Quits: Rossen (~Rossen@public.cloak) (Ping timeout: 180 seconds)
# [11:06] * Quits: Kazutaka (~Kazutaka@public.cloak) ("Page closed")
# [11:07] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [11:07] * fantasai feels very disoriented now
# [11:07] * Quits: dino (~dino@public.cloak) (dino)
# [11:08] <Zakim> disconnecting the lone participant, Meeting_Room, in Team_(css)04:03Z
# [11:08] <Zakim> Team_(css)04:03Z has ended
# [11:08] <Zakim> Attendees were jdaggett, Meeting_Room, glazou
# [11:08] * Joins: leif1 (~lastorset@public.cloak)
# [11:08] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [11:08] * Quits: jdaggett (~jdaggett@public.cloak) (jdaggett)
# [11:09] * Quits: plh (plehegar@public.cloak) ("Leaving")
# [11:09] * Quits: glazou (~glazou@public.cloak) (glazou)
# [11:09] <Zakim> dbaron, you asked to be reminded at this time to go home
# [11:10] <Ms2ger> Heh
# [11:10] <fantasai> lol
# [11:13] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [11:13] * Quits: shans__ (~shans@public.cloak) (Ping timeout: 180 seconds)
# [11:13] <Ms2ger> fantasai, go and have some dinner ;)
# [11:14] * Quits: SimonSapin (~simon@public.cloak) ("Leaving.")
# [11:15] * Quits: leif1 (~lastorset@public.cloak) (Ping timeout: 180 seconds)
# [11:16] * Quits: Koji (~Koji@public.cloak) (Ping timeout: 180 seconds)
# [11:17] * Quits: liam (liam@public.cloak) (Ping timeout: 180 seconds)
# [11:20] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [11:27] <fantasai> Ms2ger: That seems to have worked
# [11:28] * fantasai is now in possession of a stack of chocolate
# [11:28] * fantasai concludes Ms2ger has excellent network-transfer skills
# [11:30] <Ms2ger> :)
# [12:03] * heycam is now known as heycam|away
# [12:19] * Quits: MikeSmith (~MikeSmith@public.cloak) ("leaving")
# [12:55] * Joins: darktears (~darktears@public.cloak)
# [13:30] * Zakim excuses himself; his presence no longer seems to be needed
# [13:30] * Parts: Zakim (zakim@public.cloak) (Zakim)
# [13:32] * Joins: dino (~dino@public.cloak)
# [14:23] * Quits: Bert (bbos@public.cloak) (Ping timeout: 180 seconds)
# [14:51] * Joins: dbaron (~dbaron@public.cloak)
# [14:52] * Joins: lmclister (~lmclister@public.cloak)
# [15:00] * Joins: glenn (~gadams@public.cloak)
# [15:01] * Joins: rhauck (~Adium@public.cloak)
# [15:04] * Joins: rhauck1 (~Adium@public.cloak)
# [15:06] * Joins: liam (liam@public.cloak)
# [15:09] * Quits: rhauck (~Adium@public.cloak) (Ping timeout: 180 seconds)
# [15:13] * Joins: cabanier (~cabanier@public.cloak)
# [15:20] * Joins: SimonSapin (~simon@public.cloak)
# [15:24] * Quits: lmclister (~lmclister@public.cloak) (lmclister)
# [15:24] * Quits: rhauck1 (~Adium@public.cloak) ("Leaving.")
# [15:34] * Quits: dbaron (~dbaron@public.cloak) (Ping timeout: 180 seconds)
# [15:45] * Joins: leif (~lastorset@public.cloak)
# [15:50] * Joins: isra (~inoto@public.cloak)
# [15:52] * Quits: isra (~inoto@public.cloak) ("Leaving.")
# [15:53] * Quits: SimonSapin (~simon@public.cloak) (Ping timeout: 180 seconds)
# [15:58] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [15:58] * Joins: leif1 (~lastorset@public.cloak)
# [16:02] * Joins: leif (~lastorset@public.cloak)
# [16:03] * Quits: leif1 (~lastorset@public.cloak) ("Leaving.")
# [16:05] * Quits: leif (~lastorset@public.cloak) ("Leaving.")
# [16:30] * Quits: cabanier (~cabanier@public.cloak) ("Leaving.")
# [16:39] * Quits: Tav (~tbah@public.cloak) (Ping timeout: 180 seconds)
# [16:42] * Joins: arno (~arnog@public.cloak)
# [17:04] * Quits: dino (~dino@public.cloak) (Client closed connection)
# [17:07] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [17:12] * Quits: glenn (~gadams@public.cloak) (Client closed connection)
# [17:21] * Joins: Bert (bbos@public.cloak)
# [17:33] * Joins: arno (~arnog@public.cloak)
# [18:42] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:43] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [18:43] * Joins: zcorpan (~zcorpan@public.cloak)
# [18:50] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [19:01] * Joins: arno1 (~arnog@public.cloak)
# [19:01] * Quits: arno1 (~arnog@public.cloak) ("Leaving.")
# [19:04] * Joins: arno1 (~arnog@public.cloak)
# [19:06] * Quits: arno (~arnog@public.cloak) (Ping timeout: 180 seconds)
# [19:13] * Quits: kawabata (~kawabata@public.cloak) (Ping timeout: 180 seconds)
# [19:48] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [19:50] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [20:05] * Joins: arronei_ (~arronei@public.cloak)
# [20:05] * Quits: arno1 (~arnog@public.cloak) ("Leaving.")
# [20:06] * Joins: arno (~arnog@public.cloak)
# [20:08] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [20:09] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:12] * Joins: arno (~arnog@public.cloak)
# [20:15] * Joins: arronei (~arronei@public.cloak)
# [20:18] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:19] * Joins: arronei_ (~arronei@public.cloak)
# [20:24] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:24] * Joins: arronei (~arronei@public.cloak)
# [20:26] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:26] * Joins: arronei_ (~arronei@public.cloak)
# [20:31] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:31] * Joins: arronei (~arronei@public.cloak)
# [20:33] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:38] * Joins: arronei_ (~arronei@public.cloak)
# [20:42] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:43] * Joins: arronei (~arronei@public.cloak)
# [20:45] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:45] * Joins: arronei_ (~arronei@public.cloak)
# [20:49] * Joins: ivan (ivan@public.cloak)
# [20:50] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:50] * Joins: arronei (~arronei@public.cloak)
# [20:50] * Quits: ivan (ivan@public.cloak)
# [20:52] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [20:52] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:52] * Joins: arronei_ (~arronei@public.cloak)
# [20:57] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [20:57] * Joins: arronei (~arronei@public.cloak)
# [21:00] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [21:04] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [21:06] * Joins: arronei (~arronei@public.cloak)
# [21:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [21:23] * Joins: cabanier (~cabanier@public.cloak)
# [21:39] * Joins: arno (~arnog@public.cloak)
# [21:46] * Joins: arronei_ (~arronei@public.cloak)
# [21:50] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [21:58] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# [22:00] * Joins: arronei (~arronei@public.cloak)
# [22:02] * Joins: ivan (ivan@public.cloak)
# [22:02] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [22:03] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:04] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:05] * Joins: zcorpan_ (~zcorpan@public.cloak)
# [22:06] * Joins: nvdbleek (~nvdbleek@public.cloak)
# [22:06] * Quits: zcorpan (~zcorpan@public.cloak) (Client closed connection)
# [22:07] * Joins: arronei_ (~arronei@public.cloak)
# [22:09] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:09] * Quits: zcorpan_ (~zcorpan@public.cloak) (Client closed connection)
# [22:10] * Joins: arronei (~arronei@public.cloak)
# [22:10] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:14] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:14] * Joins: arronei_ (~arronei@public.cloak)
# [22:15] * Joins: nikos1 (~Thunderbird@public.cloak)
# [22:16] * Joins: krit (~krit@public.cloak)
# [22:17] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:17] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [22:17] * Joins: arronei (~arronei@public.cloak)
# [22:21] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:22] * Joins: arronei_ (~arronei@public.cloak)
# [22:23] * Quits: nikos1 (~Thunderbird@public.cloak) (nikos1)
# [22:24] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:24] * Joins: arronei (~arronei@public.cloak)
# [22:25] * Joins: arno (~arnog@public.cloak)
# [22:29] * Quits: arronei_ (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:31] * Quits: arronei (~arronei@public.cloak) (Ping timeout: 180 seconds)
# [22:33] * Quits: Ms2ger (~Ms2ger@public.cloak) ("nn")
# [22:41] * Joins: zcorpan (~zcorpan@public.cloak)
# [22:53] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [22:57] * Quits: nvdbleek (~nvdbleek@public.cloak) (nvdbleek)
# [23:17] * Joins: zcorpan (~zcorpan@public.cloak)
# [23:20] * Joins: Tav (~tbah@public.cloak)
# [23:39] * Quits: zcorpan (~zcorpan@public.cloak) (Ping timeout: 180 seconds)
# [23:39] * Joins: r12a (rishida@public.cloak)
# [23:40] * Quits: ivan (ivan@public.cloak)
# [23:41] * Joins: ivan (ivan@public.cloak)
# [23:45] * Quits: ivan (ivan@public.cloak)
# [23:55] * Joins: lmclister (~lmclister@public.cloak)
# [23:59] * Quits: arno (~arnog@public.cloak) ("Leaving.")
# Session Close: Fri Jun 07 00:00:00 2013

The end :)