IRC log of css on 2013-06-06

Timestamps are in UTC.

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