Cascading Style Sheets (CSS) Working Group Teleconference -- 06 Jun 2013

<dbaron> trackbot, start meeting

<trackbot> Date: 06 June 2013

<dbaron> Meeting: Cascading Style Sheets (CSS) Working Group Face-to-Face, Tokyo, Japan

<jdaggett> but yes please for this afternoon

<fantasai> ScribeNick: fantasai

Round of intros

plh, W3C

fantasai, Mozilla

<plh> Slides: http://www.w3.org/2013/Talks/0606-css-plh/#/

Ivan Herman, W3C

glazou, Disruptive Innovations, csswg co-chair

Simon Sapin, Mozilla

Jet Villegas, Mozilla

Rossen Atanassov, Microsoft

Alan Stearns, Adobe

whatever, scribe gives up

<glazou> lol

plinss: jdaggett can't be here this morning, ishida can't be here this afternoon

CSSWG Priorities

plh projects title slide

next slides lists RECs and dates

<jdaggett> link?

<plh> http://www.w3.org/2013/Talks/0606-css-plh/#/

<jdaggett> thx

plh: Only 6 RECs

Last 12 months: 1 REC (MQ), 2 CRS (flexbox, conditional rules)

18 WDs updated

FPWD x 5

Bugs: last 12 months

plh: Huge controversy over these, staring with Opera suggesting to remove prefixes

Transforms, bugs from 11 to 6

transitions from 29 to 25

animations from 45 to 20

glazou corrects the record

<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)

plh: Decided to move faster, but this is the result
... Only 5 bugs fixed for Transforms, 4 for Transitions, 25 for Animations
... Animations is more than 50% better

dbaron: some metrics are a little funny. Went through bugs, most deferred to next level

plh: Why not in LC?

dbaron: Because 2 left

plh: Fact is, drafts still not in LC despite controversylast year
... If we look at priorities from December 2011, these are top 3 drafts: css3-background, css3-ui, css3-values
... Still in this cycle
... Think css3-background still held up on implementation issues and tests
... css3-ui went backwards rather than forwad
... css3-values went forward
... One metric, not only one
... Last fall, CSS chairs committed a survey
... In terms of priorities, top 5 were flexbox, transforms, animations, conditional rules, transitions
... Coremob profile
... 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
... Normative references HTML5.0
... Fonts, Images, Values, Selectors 4, CSSOM, CSSOM View, css3-ui, Style Attr, Fullscreen (?)
... Some of this can be tweaked
... But some, e.g. View Module, can't break the dependency
... Style Attributes

fantasai: Style Attributes stuck on one failed test

plh: Is it important test?

fantasai: No.

plh: Then send a PR request soon

glazou: Whatever you do, browser vendors will implement and ship it. What's the point of breaking the dependency?
... Browser vendors will implement, ship, try for workable interop, and the spec describing the behavior of the current market will not be available
... I find it a little bit sad
... We had this discussion in AC form, chairs, wrt what is a normative reference
... I said a spec like HTML5, which is based on living standard, needs an intermediate status between informative and normative
... That is another way of solving your issue
... If I take that list, to finish everything including tests, is enough work for this WG for the entire year
... You want us to do everything by 2014?
... Each member of this WG has individual strategy and priority. if I read your slides, I think you forget it.

dbaron: Another problem is that REC track doesn't reflect how industry really works
... Talk of reforming REC track for a while

plh: Several ways to approach this. One is to remove dependencies from HTml5
... Third question is what does it mean to be normative ref for HTML5
... Some of those references, perhaps part referenced by HTMl5 is perfectly stable and implemented

<glazou> sgalineau, let me get the lash

fantasai: you could solve most of this is to allow REC to normatively reference CR, treating PR like transitional phase just like LC.
... This is relatively minor change to the process, would solve the problem.

plh talks about stability

dbaron: This is a discussion in the TAG list
... I think the way W3C manages normative references is broken

plh: Do believe this has process problems

<glazou> sgalineau, sure :-)

plh: If I look at F2F agenda, this is list of things that were on the agenda

<glazou> sylvaing, and I will make sure plh understands that, no worries

plh projects some questions

1. Are we getting the right balance between day-to-day borwser implementers needs and what's needed?

2. What's happening with Fall 2012 Priorities?

3. Will CSS prevent HTML5 from moving to REC by 2014?

4. What is WG expectation for its next Charter?

plh: Last, main question we have,
... This group needs to be rechartered, what's the expecations?

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.
... browser vendors are the deciders in this WG

glenn: We have input from others

TabAtkins: input, yes, but ultimately what browsers implement is what we spec

glazou: 2nd point, TTA and Flexbox were highest priorities during most of our conference calls during 12 last months

plh: Only 6 bugs?

glazou: Do you have any idea how complex these bugs are?
... Take a look. Don't rant.
... 3rd point, well, the day the HTMLWG pings us to tell us they need that spec to be a REC, maybe it will change
... I told HTMLWG and W3C more than a year ago that we have problems with normative refs of HTML5. No response.
... WG expectation, I don't know. We did not discuss next charter yet
... Mine is to reduce the nubmer of specs we're working on
... Priorities can change a lot, and strategies can change a lot, over 2 years.
... E.g. Firefox was not in mobile space before. now they are working a lot on apis
... If I knew what was going to happen in CSS world 2 years from now, would be billionnaire
... 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.
... Date of 2014 has been set by HTMLWG without looking at the dependencies.
... After choosing date, look at dependencies. It is not fair.

TabAtkins: Even if we ignore dependencies, there is no way HTML5 can hit REC in 2014 without bending rules.
... You're going to need like a million tests. it's not going to happen in 1.5 years.

glazou: They lowered expectations.

TabAtkins: By honestly reaching REC like everyone else does, will need to lower what it means to be REC.
... Doesn't make a difference if we are a process-holdup. They have a process-holdup anyway.

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.
... Think it's impractical perspective
... Would encourage us to not take that we work in a vacuum
... 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.

glazou: One of the largest users is Ebooks. And we have an acceptable cooperation with IDPF
... I think not perfect, but acceptable cooperation.
... They send us requests, they discuss CSS on their group.

Bert: You and I are working on it, but not rest of WG

[discussion of css3-page, css4-page]

glazou: Where is HTMLWG to discuss with us their needs?

glenn: Problem is communication

glazou: I find it easier to ping users, outside W3C, than to ping some other committees.

[discussion about cross-wg communication and HTML5 date]

plh: If you tell me none of those specs reach REC by 2014, that's one kind of input
...

dbaron: Why do members care about pushing to REC?
... Doesn't have any benefit for us
...

TabAtkins: REC and interop don't have a strong correlation

plh: That's one reason, other people have other reasons

dbaron: It's the reason why people here do the work.

plh: You're trying to get the documents perfect before REC. You won't get there.

glazou: Documents that don't move now are blocked on difficult technical issues (other than style attr)
... Open issues for TTA are really complex
... Question of availability of people. Only a few experts on each topic.
... Even if a large group, made of subgroups. You seem to forget that.

<jdaggett> i do think we lack the ability to prioritize some specs

<jdaggett> we seem to work as a group on whatever individual members are interested in working on

Bert: Why don't we finish things we promised to finish 5 years ago?

glazou: Ask them! (gestures to WG)

<jdaggett> and that effectively crowds out work on other things

glazou:

TabAtkins: Can't go to PR without testing everything in the spec

glenn: No, don't need to test everything in the spec

TabAtkins: Then I have no idea what you mean by test suite.

plh: I've never seen browser vendor that has full test suite for everything they implement

<jdaggett> why don't you need to test what's in the spec?!? that makes no sense

plh:

dbaron: Philippe admits that REC doesn't need to be perfect

<jdaggett> existing browsers have lots of legacy stuff

dbaron: One problem we have with process is that we want to maintain specs, and continue to maintain them as ppl bring up issues
... Problem with process is that it's much harder to update a REC

<jdaggett> but the quality of testing efforts is vastly improved over the past five years

plh: Don't see why
... Just need to have a test for each change
... You are setting a bar for REC that is way too high

dbaron: You act as though publishing a doc is trivial thing
... Publishing CR requires editor to spend days pinging various people for permission
... It's not worht a week of my time to get document published on /TR

glazou: Pages of spec:

12 pages for CSS1

258 for CSS21

4000 for CSS3

glazou: It's a lot of work

Bert: Seems like we always want things to be in flux

TabAtkins: Want to always be refinining / correcting things.
... 100% stability is an illusion

[discussion of bureaucracy]

[and how to allocate resources to it]

glazou: 2 passing implementations for each testable assertion
... That's the way it should be. Otherwise test suite has no value.
... I understand HTML5 has different requirements. And I agree with Tab that that test suite has no value. It's just marketing.

/just/pure/

scribe:

jet: Sounds like W3C wants REC documents
... Group says cost to REC is too high, and CR is good enough
... Perhaps the product expected of this group should change

plh: If I go to AC and say CR is the new REC, AC will not happy

Bert: We used to have no testing requirement
... process changed

glazou: So process can change. These people are telling you process needs to change.

plh: You're saying we should have no test suite requirement, other say they want more testing requirement
...

glazou: HTML has lower expectation because want to release fast, because marketing impact and press, releasing HTML5

<dbaron> LC of css3-conditional took 28 days from publication request (November 15) to publication (December 13)

<dbaron> so it's not just CRs

glazou: You lowered the bar to meet that date

dbaron, that was largely because I didn't notice that the document wasn't published when it was requested to be published

dbaron, and so wasn't able to follow up and get it published the next day

scribe:

jdovey describes IDPF process, which is fast and loose

<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

liam: Pragmatic, and on programming end pragmatism is imporant. But e.g. governmental standards requirements are different

glazou: These 4 questions
... To answer these 4 questions, we need to know what you want.
... What does W3M want about the priorities?
... What do you think we should do wrt dependencies

dbaron: Why does W3M have to make those decisions

glazou: Don't say they make decisions, just want their input.

plh: ...

r12a: IDPF has been really keen on vertical text and ruby
... Ruby CSS module is way off the bottom of the scale in terms of work being done
... I know that's partly because ppl don't ahve time to work on it
... But what's the process the WG has, for discussing with IDPF, and allowing them to raise what they want

glazou: Question I discussed with Markus Gylling
... We don't have a real process
... We discuss technical issues sometimes, but not really how can we answer, address improtant requests from their point of view.
... E.g. ruby, which is best example
... We have no one
... 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

ivan: digital publishing interest group ...
... Not chartered to develop sepcs, but may come up with priorities and requirements, and maybe find ppl to do the work here.

r12a: What is the process for CSSWG for re-evaluating priorities and discussing stakeholder requirements?
...

dbaron: Need to communicate that we don't have resources, and let them work on it if they want to put those resources in.

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.

glazou: Strategy of the market changes

Ivan: Whole issue of membership fee etc.
... Let's say 3-4 ppl form task group within this wg to develop technolgy XYZ
... Do you have structure of task forces?
... What's the decision procedure?

glazou: We have FXTF with SVGWG

Ivan: Can they work on it and push to REC?

glazou: Sure

jdovey: What happens if TF comes back to WG and 80% WG says they don't like it?

<jdaggett> um, i don't think task forces are magic, you need people capable of actual tackling issues with developing something

dbaron: Need to get feedback earlier

<jdaggett> the epub way of coming up with a laundry list of "we needs" is actually very disruptive

Ivan: We have a community not browser vendors, willing to do work, will they be shot down because browsers don't care?

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

jdovey: talks about implementing ? in WebKit and politicking and sitting on the patch and stuff.
... We keep running into roadblocks

dbaron: I think you can't say you want something in 6 months and then not put the work into it
... to really do it right

<jdaggett> maybe because shoving code for a feature into webkit before ironing out the spec is not a constructive approach...!

dbaron: Having a patch in WebKit is different from having a standard that can be interoperably implemented and everyone agrees with

jdovey talks about JLREQ requirements

and trying to implement those

jdovey: [..., ruby, ...]

dbaron: Don't see how you can implement a requirements document.
... If you want a technical spec, need to describe what the technology is

jdovey: Desribes how characters should be laid out

dbaron: Gives requirements, not a model

<jdaggett> and you have to make that fit into existing features!!!!!!!!!!!!!!!!!

plh: Current charter is coming to expiration

<jdaggett> example: webkit's crazy two-path text handling structure

plh: Could say, perfectly happy way we are working
... You guys are doing the work
... I cannot just say, this is what you will do, you have no choice. You'll walk away if I do that.
... Think you need to figure out what you want to achieve
... 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

dbaron: he's talking about how WG members are appointed by their AC reps
... Which is mostly an administrative fiction

plh: Ok, I don't want to hold this group further. You guys have work to do

dino: what was the point of this discussion?
... Not trying to be rude, really want to know

plh: Just wantto make sure you understand what you're doing and are happy with how you're operating
... And if ppl come to me with complaints, I will rediret them to you saying your'e doing this intentionally :)

<jdaggett> i think lots of folks will always be dissatisfied because their individual feature request isn't satisfied

<jdaggett> しょがない

<glazou> http://www.quickmeme.com/meme/3uqllg/

<glazou> sylvaing, please upload the URL above to w3cmemes

Syntax

TabAtkins: Rewriting from grammar approach to parser approach

<jerenkrantz> http://dev.w3.org/csswg/css-syntax/

TabAtkins: grammar tried to match everything, not just well-formed things, and was too complicated and didn't quite handle everything anyway
... Tokenizer, then Parser
... Includes hooks for other specs to include a certain type of thing
... I would like to review some things with group, then ask for FPWD
... Probably as correct as 2.1 at this point
... WebKit uses augmented grammar to parse, and it's horribly broken.
... Wanted to go over changes from 2.1
... First batch of changes are about parsing
... 2.1 defined some interesting rules for detecting @charset
... Brought into line with charset handlign in rest of platform

<dbaron> we're reviewing http://dev.w3.org/csswg/css-syntax/#changes as of 4ce7b66b553a

r12a: Does that mean it doesn't handle UTF16

TabAtkins: Can use UTF16 by having BOM, but won't recognize @charset

fantasai: How interoperable is this, compared to 2.1?

TabAtkins: Dropping some obscure encodings probably ok, since implementations' don't support them
... Wrt web-compat, shoudl be just fine
... dropping things like EBCDIC

liam: Did you check for corporate intranet stuff?

TabAtkins: I think likelihood of EBCDIC is close to zero

r12a: I thought same thing wrt bidi things, but ppl came back with supercomputers and stuff in Hebrew that were using old encoding systems

Bert: It was there. You're trying to remove it?

TabAtkins: Browsers didn't recognize it?

Bert: You can't remove thing
... This is supposed to be stable

<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.

Bert: We promised not to make versions to CSS, just to add things
... Don't think we should remove features just because not used on the Web
... Remove features when they're wrong.

[discussion of changes]

Bert: Not an argument to keep on making mistakes

r12a: When HTML5 did some charset stuff, wanted to do it to stop people using non-UTF-8
... Is that your motivation?

TabAtkins: Highly sympathetic to moving to UTF-8, but main issue is making this much simpler

glazou: If all style sheets were UTF-8, would be much easier for authoring environments

dbaron: Checking for UTF-16 rules were widely tested
... We changed recently. Ran into no web-compat problems, but ran into certification problems.

SimonSapin: Would like to point out that this is only about @charset. Can do anything you want with HTTP headers
... Also, relevant part of CSS2.1 gives a table of byte patterns. Allows UAs to remove some, or to add some

dbaron: Sorry, what I said is opposite.
... When we implemented what this draft sayse, and this caused us to start passing th GCF certification suite
... It has a test of a UTF-16 file that claims an encoding name that doesn't exist

r12a: What did you say was the first step in detecting charset?
... Thought we changed so that BOM is first

<dbaron> the thing I was just describing was https://bugzilla.mozilla.org/show_bug.cgi?id=859706 being fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=796882

TabAtkins: BOM is checked first by decoding algorithm, before @charset
... this list finds the fallback encoding
...

r12a: Do you forbid use of @charset in UTF-16 documents?

TabAtkins: No, you just ignore it

<dbaron> er, actually, the encoding name does exist but it's an alias for UTF-16BE, while the file is UTF-16LE

TabAtkins: Never invalid to put @charset

plinss: What if UTF-16 without BOM but with @charset?

TabAtkins: Defer to encoding standard...

r12a: you can do it, but say you shouldn't

TabAtkins: Specifying anything other than ascii-compatible encoding is not useful

r12a: Since already defined, why not keep them?
... I share bert's unease here
... I agree it would be great to move to UTF-8 everywhere

TabAtkins: If implementations get bug reports on things should ask for standard to be updated

plinss: Would prefer to include this table
... I know there are implementations that implement that entire table, because i made one

TabAtkins: Gecko doesn't anymore, don't think WebKit does either

dbaron: Gecko only implemented ascii-compatible cases and UTF-16 cases.

<glazou> WeasyPrint implements that table

dbaron: never did UTF-32 or EBCDIC
... Might've done UTF-32 long ago, but that cod eripped out a long time ago
... ripped out support for UTF-32 entirely

TabAtkins: My preferred approach is to keep it as-is right now. if there's a problem, we'll see bug reports
... Alter as necessary

plinss: Not really happy with that approach. Break it and see who complains?

TabAtkins: Don't want to include rows that browsers don't implement it

plinss: But some that are significant

TabAtkins: Leave this in, with an issue maybe?
... Issue that we may need to add additional charset encoding patterns?

plinss: Maybe add onto that that we're explicitly requesting feedback on this

<SimonSapin> WeasyPrint implements part of that table because I didn’t know any better. Some cursing was involved.

plinss: Agree we probably don't need EBCDIC, and a private browser could implement that for an intranet
... But more concerned wrt UTF-16 issues
... Web is huge. Small percentage is still a lot of pages

TabAtkins: encoding will detect

plinss: Shouldn't be sniff it
... If there's a document that doesn't have BOM and has @charset, shouldn't be sniffing it. Should use @charset

SimonSapin: Can also rely on HTTP headers

plinss: We have problems e.g. in our test suite, file sthat work on the server, but not locally
... CSS should not, don't think that we require style sheet to be served over HTTP

<Bert> (The issue can ask which @charset lines can be deprecated.)

TabAtkins: Step 3&4, where you take charset from encoding document. Should that only work for same-origin?

r12a: Value of 4 is ppl who don't understand charsets or setting http headers
...

TabAtkins: So, take charset from referring document only if it's same-origin. Yay/nay?
... Ok, I'll say yes for now, object later

Bert: what's issue?

TabAtkins: Sometimes if you can force a document into a different encoding, can extract info from it
... This would prevent that kind of thing

Bert: What could you do with a style sheet in wrong encoding?

TabAtkins: Don't have specific example, but this kind of problem has been an issue in other technologies

Bert: But you're only changing your own document, not someone else's

dbaron: Suppose has wiki, where input CSS that shoudl be sanitized
... Could have fun encoding , maybe UTF-7 or Shift-JIS or something, that can create cross-site scripting vulnerabilities
... Encode control characters for programming languages as benign ascii chars

TabAtkins: Can't give a specific attack scenario, just know there's problems in other languages

Bert: Concerned about people putting stylesheet on one server, seems to work, then moves it to other server, doesn't work.

TabAtkins: If you have a charset problem, use UTF-8

<dbaron> dbaron: Either way I'd prefer to leave an issue in there until we're confident it's stable.

<dbaron> (w.r.t. the same-origin thing)

RESOLUTION: Make it same-origin, leave issue

<jdaggett> anyone in the room now?

<jerenkrantz> only a few

<jerenkrantz> (i am)

<jdaggett> tab or dbaron?

<jerenkrantz> nope - they are still eating

<jdaggett> ok, thx

<TabAtkins> jdaggett: Yo.

<jdaggett> hey, did you see the note about taro?

<jdaggett> he'll be coming at 1

<jdaggett> remember him? he was at kyoto f2f

<TabAtkins> I don't remember him, but sure.

<TabAtkins> Hm, I wonder how I should meet him.

<jdaggett> he'll be at reception at 1

<TabAtkins> jdaggett: Okay, that works. I'll be downstairs then.

<jdaggett> can you just tell the reception to expect him

<jdaggett> cool, thanks!

<TabAtkins> jdaggett: Have you been to the shabu-shabu place?

<jdaggett> nope

<jdaggett> were you able to reserve?

<jdaggett> glazou: can we wait for taro to start the fonts discussion?

<glazou> jdaggett, supposed to arrive when ?

<jdaggett> 1pm

<jdaggett> i think tab is downstairs waiting at reception for him

<glazou> no tab is right next to me, reminding him now

<TabAtkins> jdaggett: Yeah, I reserved it last night.

<jdaggett> cool!

<TabAtkins> jdaggett: Just wanting to make sure I can get to it easily. ^_^

<jdaggett> it's pretty close when i looked on the map

<TabAtkins> did the full unlimited shabu-shabu, drinks, and sushi meal. ^_^

<TabAtkins> Yeah, real close.

<jdaggett> wow!

<jdaggett> that's time-limited to 2 hrs...

<TabAtkins> Yeah.

<TabAtkins> Okay, running downstairs.

<jdaggett> cool

<jdaggett> is shane there today?

<jdaggett> need to hook up the zakim connection again

<glazou> waiting for shane and tab now

<jdaggett> r12a: are you here for the fonts discussion?

<dbaron> shane went to look for Tab, so we can't set up the call now :-P

<dbaron> and r12a is here

<r12a> yep

<jdaggett> cool

<glazou> shane back

<jdaggett> phone bridge magic?

<glazou> shane is casting a spell on the telephone right now

<jdaggett> ok, waiting for shane magic...

<Bert> ScribeNick: Bert

Fonts

<jdaggett> heh

<jdaggett> sorry in advance, i'm in the visitor's room with a tv on in the background...

<jdaggett> tab and taro arrive yet?

<stearns> not yet

<jdaggett> hmm, he says he's stuck on the third floor

<jdaggett> can't come up to the 26th floor

<jdaggett> argh

<Rossen> both are here now

<dbaron> jdaggett, taro is here

jdaggett: italic in vertical:
... I recommend that Koji come to the mic
... Background is that in Japanese there is no real tradioton of italic.
... UAs just oblique synthetically.
... When 'font-style: italic' on vertical text, what should it do?
... If you have a normal italic font, you just use it.
... Should the slant be different in vertical?

<jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png

jdaggett: Example [see URL]
... This is the options.
... figure 2 is normal italics.

<dbaron> jdaggett, we dropped off

jdaggett: Some in Japan have [lost phone]

<TabAtkins> One sec while we reconnect.

<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png

<jdaggett> argh

<fantasai> Murakami-san's take: http://lists.w3.org/Archives/Public/www-style/2013May/0405.html

[Trying to reconnect to Zakim]

<jdaggett> http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png

[example on screen]

<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png

jdaggett: Koji and Elika propose figure 3

<dbaron> current fonts spec has #2, Koji and Elika propose #3

<scribe> [new image on screen]

<dbaron> (move jdaggett's last URL to here)

jdaggett: Mixture of 2 with a real italics font.
... I don't say which is better.
... Slope down to the right in 3
... All kinds of arguments possible about what is better in diff. cases.
... But there is no tradiotn of italic in Japanese.
... But Koji brought up that there is tradition of obliquing

<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0032/harrypotter-7-193.png

[example on screen]

jdaggett: This is oblque to the left.
... Koji found this.
... There should not be a distinction between real italics and synthetic case.
... Bad inconsistency.
... If we want oblique in eneral then we need better control.
... We are still fighting arouhnd the edges.
... Comments? Koji,Taro?

Koji: Not agaisst your opitinion
... I want consistent for sideways characters, that's were moset italic will be.

Taro: Why you don't agree?
... Historically there haven't been any slanted Japanese
... Limited to display type, headlines etc. One line only.
... We have Times Roman and it has italic.
... It is possible to apply automatic transform, slanting.
... Not in Japanese context.
... Two notions.
... There is no [missed]

Koji: Progessionls say there is no italic, but authors stll want it.

jdaggett: Give them the option if they want something like Harryt Potter example.
... It has down slant on the left.
... Authors cannot do that.
... Putting behavior in general behavior doens't give authors the control.

Koji: I discussed with authors.
... They udnerstand.
... They stil prefer synthetic italics.
... Too many points too discuss.
... Do them one by one.
... 1st is synthesize or not?
... 2nd is which direction.

jdaggett: Spec now says synth happens based on whether there is italic or not.
... Whether synth italic is good or not is separate matter.
... If we have to have synth italic, and we do, then it has to be consistent with real italic.

. Not based on horiz or vertical or other factors.

scribe: I dont' agree with the way your quoting me.
... We have font-syyle in CSS and it allows synthesize.
... We have to continue that.

Taro: If proper true slanting operations for Japanese is not defined,
... I have to object allowing synthesizing italics by slanting
... It will make it easier for user to get accustomed to current deteriorated situation.,
... People will continue current and that is not good thing.
... In Harry Potter case,
... Where slanting neessary, we should do that,
... But we have no correct diefitionn yet.
... Once defined and documented,
... Yes allow some kind of algorithm,
... Slanting may be necessary.
... Without knowing wjhat Japanese slanting shuld bem it is very risky to link between existing and cjose slantoing operation.
... Look at ROmand and japanese char
... Maby metrics differemt.
... You have beedn accustomied to switching italic and roman.
... Always assumed that you will find an italicfont.
... That doesnt exist in japanese world.
... My recomendation is to do nothing.
... That is best becase there is no italic in japanese.
... Doing something is OK, but please define what the shearing oepration should be,
... Oherwise popel will just be happy with the current stats eand think is is fine.
... That will not guarntee good graphic and visual effect.

r12a: Asking for clarifiction:
... In Harry Potter is is down to the left,
... What would happin in horizontal?

Koji: No, it would be to the right.

jdaggett: This is a pblished example.
... Koji and Elika proposed slanting down to the right.

Koji: I'm proposing the number 3, jdaggett propose 2

[Harry Potter is 1]

Koji: Japanese authors want 1 if combined with ltin text, otherwise 3.
... I asked publishers what they want.
... After discussion they said 3 works best for now.
... Until we get more precise control.

jdaggett: 3 introcudes inconstency when there are real italics.

koji: Japnese font will not have real italics.

jdaggett: But western author miing text will get 3, that does not look right.
... [Confusion over which number 3]
... [Looking at tategaki image]
... That will look bad.

Koji: There is no single way to solve all issues.
... Not in level 3.

<dbaron> in http://koji.ec/wp-content/uploads/2013/05/italics-vertical2.png , #1 is skewY(-10deg) for Japanese, #2 is skewX(-10deg) for Japanese, #3 is skewY(+10deg) for Japanese (note +- and XY changes)

Koji: Latin upright use case is less important.

jdaggett: Japanese italic is difficult to find.

fantasai: The examples are not real italcis, they re some diffirent feature.
... Fndamental question is direcion of shearing.
... [drawing on whiteboard]

liam: q for Koji:
... We often say that dureing standards and it comes back to bite us.
... "until we have more control"
... We're often stuck with that.
... Don't preclude anythign in the futre.

Koji: Yes, with more control authors will be happy.
... But even now they ar ehapy with 3.

Taro: Do not agree.

<dbaron> in http://lists.w3.org/Archives/Public/www-archive/2013May/att-0027/synthetic-italics-tategaki.png , #1 has skewX(-10deg) for ja and en, #2 has skewY(+10deg) for ja and en, #3 skewY(+10deg) for ja and skewX(-10deg) for en

Taro: Hary Potter exmaple is not italic. It is slanted, yes.
... Iv'e done slanting myself.
... [fantasai tries to draw. Taro doesn't'thnk the drawing is right]
... It is necessary to align line direction and angle.
... Japanese phototypesetting at slanted line.
... Possible, I know.
... Sometimes people ant that, but it is not italic.

Rossen: For mcirosoft, I'm not an expert in this area.
... From talking to Office team:
... Feedback was that we had italics in word for 20 years.
... Since MS Gothic.
... Regardless of how good or bad, there is adoption of it.
... People ar eusing italic in vertical.
... How mny make it to the Web I'm not sure.
... If nedded I can find examples.
... Expected that these document will become HTML.

jdaggett: How many are using th feature?

Rossen: I don
... t have data

jdaggett: There were certain assumption made a long time ago.
... The initial Word model was simple.
... Should not look at that backwards compt.

Koji: Used for 20 years.

jdaggett: How often?

Rossen: As often as anybody wants to use italic in vertical.

Taro: Adobe Indesign since 10 years ignores italic in Japnese script.
... It seems to be a script property.
... Adobe's Japanese fonts have italic glyphs for Latin.
... You can do tru italic with Adobe fonts.
... But not to any Japanses font.
... Only if glyphs included in the font.
... IS this really a font property?
... Western context OK.
... OK with font property there.
... You can assume that Times Roman has italic.
... But no such assumption in japanese context.

Koji: So we're back to synthesize or not.
... Make a spexil rule for japanese to not synthesize if font not available?

r12a: Only Japanses or CJK?

Taro: Any script that have no italic semantics.

Koji: In Unicode often difficult to know script.
... Should not depend on codepoints for scripts.
... If we can resolve this, than we candecide how to synthesize (if we decide to synth).

fantasai: What do Koreans do?

jdaggett: Easy way is to use an italic font. But I'm interested in the fallback case.

r12a: Russina also a pb.
... Shapes in italic very different from romanan.
... Slanting won't work.

<stearns> +1 to less faux italic magic

dbaron: Spec says *may* synth, isn't it?

jdaggett: Yes, but users will expect it.

<dbaron> jdaggett: but all UA's do it, so users expect it

Koji: Yes, spec says that. I want consistency *when* the UA synthseses.

glenn: conditional mandatory spec text

jdaggett: UAs do that, but users should have way to turn it off.

glazou: I think we have to resolve and move on

jdaggett: Strawpoll and move on.
... Let me get the example.
... Tategaki figure

[Tategaki figure now on screen]

<jdaggett> proposals:

[vertical2 now also on screen]

<jdaggett> 1. synthetic italics follow actual italics (glyphs slanted to the right independent of orientation/vertical/horizontal)

<jdaggett> 2. synthetic italics in the vertical case are slanted down to the right

["LETTERS 123" on the left, "Italics 123" on the right]

<dbaron> proposal 1 == tategaki example #1

<dbaron> proposal 2 == tategaki example #2

jdaggett: red #1 is prposal 1

<jdaggett> red #2 is proposal 2

dean: 1 and 2 talk about latin text, rotated or upright?

jdaggett: Proposal is to follow actual italic.
... [scribe confused]

<glazou> …[not only the scribe...]

dbaron: So apply to all italci tetx, incl latin and ideog?

<Rossen> jdaggett, can we use Koji's example? it is so much easier

jdaggett: I think we had no disagreement.

Koji: Your prop is red 1 and sideways 2?
... My prop is red 2 and sideways 3

jdaggett: Fine
... Synth italic and real italics are going to be different in Koji's propoosal.

<Rossen> [Koji to jdaggett mapping]

Koji: Depends on which consistency you want.
... Your picture shows more consistency with upright letetrs.
... Mine more against baseline.

glazou: There are other vertical writing systems, such as Mongolian.
... Will tjis apply there?

jdaggett: Yes, but hose systems do not have tradition of italics.
... So less need for authors.

glazou: I have a set of Mongolian fonts with italics in front of me.

[People gathering arounf glaxou]

r12a: Maybe becaus eit is basically rtl system.

<dbaron> #1 has skewX(-10deg), #2 has skewY(+10deg)

Koji: [...] best beahvour in CSS and acceptable.
... If one face is not available...

glazou: I want to make sure proposals are fit for other writing systems.

jdaggett: Only the synthetic case.
... If user uses italic font, he gets it.

<stearns> jdovey: ding ding ding

dbaron: We shoul;dn't hold up LC over a fallback case.

fantasai: If you use Koji style, you will break connecions in Mongolian [scribe not sure]
... Mongolian glyphs sudeways
... If Mongilian were to be defined in terms of upright,as jdaggett wants, than this would break connections.

jdaggett: There is no use case for that.
... The examples you brought up. There is no [...] italic context.
... Thin air, no real use case.

Koji: No, it exists.

glazou: strwapoll.

Option 1 = red 1

Option 2 = red 2

TabL abstain

koji 2

ivan: ab

glazou: abs

SimonSapin: abs

Jet red 1

taro: 1

Rossen: sen 2

Alan 1

Rebecca: abs

dean 1

dirk: abs

rik: abs

leif: abs

<dbaron> (dirk and Taro would have voted for the third drawing for the whiteboard, which has no synthesis in vertical Japanese)

Kazutaka: 2

liam: 1

justin: 2

shane: abs

jim: abs

bert: abs

r12a: abs in favor of futher evidence, as westerneer prefer 1

plins: abs

dbaron: abs

glen: 1

fantasai: 2
... problems not as often .

[6 to 5 in favor of 1]

<Rossen> 13 abs

jdaggett: 1

<dbaron> [7 to 5 in favor of 1]

[discussion about live with and object...]

jdaggett: Weak consensu os to do something because we do not have a real property to allow obiquing.
... Not do this as a substitute for doing somethjing else.

glazou: So leave it undef?

jdaggett: No, go with 1, because 2 is relly advocating for a new feature.

Koji: No, then we have to define for Ruby, etc.
... Those conflict.

jdaggett: [missed]

glazou: We have 7 to 5, so option 1 or leave undef.

jdaggett: Either is fine.
... But not option 2

[hands up for udnefined]

[Some hands up]

RESOLUTION: Leave undefined.

jdaggett: Netx issue.
... fantasai 's issue on sub/superscript

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0285.html

<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.

jdaggett: What to do about text decorations in superscript variant glyphs.

<jdaggett> http://lists.w3.org/Archives/Public/www-archive/2013May/att-0025/superscript-underline.png

jdaggett: Let me explain the example.

[Looking at e-mail msg]

[Looking at image]

jdaggett: Different kinds of sub & super
... Using HTML, font shrink and vertical align
... Second uses Unicode codepoints for super and sub
... 3rd is suing feature in draft.
... What an undelrine looksk like
... 2nd has underline just to superr

<fantasai> https://coreldraw.com/cfs-filesystemfile.ashx/__key/CommunityServer.Components.PostAttachments/00.00.17.55.90/workaround.jpg

jdaggett: Difference in baseline
... Metrics same as surronfing text for Unicode superscript glyphs.
... FOnt has metrics for syntheseis
... This pb exists with Unicode code points already.
... My point is that we don't need to do anythign special.
... You get what you get in 2nd example.
... You don't get detailed control.

fantasai: The one we want is what matches the HTML example.
... Thatos what people want.
... Take info from font, and use that to position underline.

jdaggett: That doenst match where the glyphs are.
... Cannot have magic.
... Fallback won't work.
... etrics are different.

fantasai: But it will match synthesized glyps.

jdaggett: No, not close enough.

fantasai: he bottom examples don't look right at all.
... We can get closer.

jdaggett: Just wrong in a different way.
... Adobe's font all have same metrics.
... Aling will be differne tbase don font.

<jdaggett> http://dev.w3.org/csswg/css-fonts/#font-variant-position-prop

[looking at figure 22]

jdaggett: Showis diff ebtween real superscript on left and synth version in middle.
... Baseline is not the same.
... Will have unerline in middle. Not look right.
... We hav ebeen trying to come with magic for a year and a half.
... Text decoration same issue coming back all over again.
... We kust don't have it, it i snot available.

Leif: Can the font p[rovide metrics?

fantasai: Yes, they could.

jdaggett: Not the right answer. The metrics are meant fo rthe synth case.
... Example 22 shows that synth superscript is larger.
... Designer made it so.
... Metrics work with synth.
... Not so well fo rthe designed glyphs.
... Which is what you propose to use them for.

<fantasai> I still think it's better to use those metrics than to use the base size metrics

jdaggett: Complex content [...]
... It is not meant as complet ereplacement for HTML mark-up.
... There are limitations, noted in the spec.

fantasai: I'd like to edit text deco spec to say we use font metrics in font.

jdaggett: What are doing?

<fantasai> glenn: I agree

jdaggett: The metrics don't match what you want to sue them for.

glenn: If the font *doe* have metrics, they should be used.
... Agreed?

jdaggett: The metrics are used for synthesis.
... If you resize,
... The metrics don't matchs the actual glyphs.
... Sure, if you design a font with metrics, but that is a big "if."
... Not common practice.
... Other comments or questions?

Leif: Seems fantasai 's suggestion works in exmaple 22, but maybe not for subscript.
... Maybe not in gemeral.

fantasai: Metrics of base size is not any better, propbably worse.

Leif: I don't really know how fantasai 's uggestion will turn out for subscripts.
... Better result more often than not?

glenn: If font designed specs a sub or super feature, but without glyphs, you suggest we synthesize?

jdaggett: Spec ahs wording about that.
... We do include wording for fallback, we will synthesize.
... If user adds elements or images, or sub-spans, then they should use the HTML way.
... We pretty much resolved on the feature not being a complete replacement for HTML mark-up, and it shuldn't be one.

glenn: Is there consistency among UAs for fallback?

jdaggett: Nobody implemented it, no cmparison to make.
... Gecko has impl ebhind a flag, but without the fallback behavior.

glenn: Mark fallback at risk?

jdaggett: Why?

glenn: Lack of implem experience.

jdaggett: No strong case, spec is just not finsihed yet.

glenn: No early implementers either.

glazou: Can the people discussing now find a compromise?

jdaggett: What do ypu want me to compromise on?
... There si nothing.

fantasai: Cannot live with John's option.

jdaggett: You're propisng magic, not a real proposal.

plinss: If metrics available, use them, but seems there are none.

jdaggett: Based on what research?

plinss: Metrics are for something else, acoording to jdaggett
... So if the metrics don't exist, [...]

<glazou> Rossen, and jdaggett a longsword ?-)

fantasai: But if they exists it will be right, and otherwise they will be slighty off.

plinss: Fine with a note in text decoration about if there are metrics.

fantasai: We have to put the underline somewhere.
... Which metrics do you use.

<Rossen> glazou, Nooo just a swiss knife

fantasai: Just because Unicode glyohs have this pb, doesn't mean we have to copy the pb.

liam: Proposal:
... WebFonts WG has liasion with ISO Opentype
... Chair of WG.
... Ask them about a new metric.
... Not invent something ourslelves.

jdaggett: Shors delay, are you joking?

liam: If we have to wait for a new feature, that would be long. But not long to ask the question.

jdaggett: We have been trhought this.

Liam: In that case redraw suggestion.

plinss: Still useful to talk to Opentype.

glenn: Truetype has different tables.

<dbaron> glenn: ... bsln (Truetype) vs BASE (OpenType)

glenn: Are we too specific to OpenType.

jdaggett: [missed]

<dbaron> jdaggett: superscript metrics are in OS2 table

glenn: Asking because you also mention baseline offsets.
... Just wondering...
... You and Elika get together.

glazou: strawpoll.

<fantasai> fantasai: Proposal is for when superscripts or subscripts are decorated, use superscript/subscript metrics to position decoration

plinss: Are you taling about synth *and* non-synth case?

<dbaron> jdaggett: The text underline follows the surrounding glyphs (for both in the synthesized case and the actual glyphs case)

<fantasai> fantasai: jdaggett's proposal is that instead, use the metrics of full-size glyphs

jdaggett: Yes, behave same way, nortmal baseline, not shifted.

TabAtkins: [pointing to figures]

dbaron: we're talking about what happens with the new feature for using font features, not using vertical-align.

fantasai: That means underline the whole thing as the full size chars,

<dbaron> fantasai: in the example, jdaggett wants the OpenType version to match the Unicode version rather than the HTML ersion

fantasai: People do not undelrine the degree char, but they do underline superscripts.

TabAtkins: jdaggett 's proposal is the lower half of the current projected screen.

[7 hands for jdaggett proposal]

[7 for fantasai 's proposal]

[rest abstain]

<glazou> [8 hands for jdaggett proposal]

[plus 1 for jdaggett , jdaggett himself]

jet: Does this hold up LC on fonts?

fantasai: No, it is an issue for text decoration.

jet: We should really resolve this, cannot keep on fighting.

plinss: If is not on fonts, let's leave it open issue on text deco and move on with fonts.

[break 15 mins]

<jdaggett> ooops, sorry

<glazou> jdaggett, about to start again

[glazou and fantasai discuss which issue to treat next]

<jdaggett> not hearing you...

<jdaggett> is your phone muted?

<glazou> wait

<glazou> OM representation of @font-feature-values rule

font feature at-rule in OM

<jdaggett> http://dev.w3.org/csswg/css-fonts/#om-fontfeaturevalues

jdaggett: [looking for URL]
... fantasai posted that it should be different, ensued a thread. Tab prposed a subclass of grtouping rule.
... And then make each feature block another subclass.
... I'd like to gauge group's opinion.
... Whos is interested in implementong?

glazou: comments?

<fantasai> Heres the comment http://lists.w3.org/Archives/Public/www-style/2013May/0580.html

dbaron: Mixed feelings
... If it looks like an 2rule it should behave like an at rule. On other hand an awful lot of pieces to make.

fantasai: I know Tab has comments, wait for him to come back into the room.

jdaggett: Let me look for Tab's stuff.

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0596.html

jdaggett: Follow on from that is that grouping rule often [missed]

<jdaggett> example

<jdaggett> @font-feature-values Bongo {

<jdaggett> @swash {

<jdaggett> swishy : 1;

SimonSapin: Independent of whether descriptors or declarations are involved

<jdaggett> wavvy-gravy: 2;

<jdaggett> }

dbaron: Hesitant to reopne discussion, but makes me wonder if there is too many levels of nesting.

<dbaron> @font-feature-values Bongo { @swash swishy 1; @swash wavvy-gravy 2; }

dbaron: Why in that example, not like this [see above]

jdaggett: That was original proposal, but we switched to more at-rule-like version.

fantasai: Both are at-rules.

plinss: Don't see why not a group rule.
... But don't want ot separate i/f classes
... for each class.

TabAtkins: I proposed to map them.
... Should be on m-list.
... Just expose the at-swatch as properties of feature-values
... js-maps
... Or maybe a string
... they'll merge

plinss: Makes sense.

fantasai: [question]

jdaggett: [bad sound]

<fantasai> fantasai: Didn't you have a simplifying proposal, that we could expand later?

jdaggett: My proposal is at-rule with nothing in it.

TabAtkins: [explains proposal]

fantasai: could go with that, and than make a css3 font extensions spec.
... Needs more work.

dbaron: We're not ready to conclude that yet.

jdaggett: font load events is not the approriate place.

dbaron: What Tab described sounds fine.

[tab writes on wboard]

dbaron: TAG is going to review APIs.
... Tab's propal fits what TAG expects.

<TabAtkins> interface CSSFontFeatureValuesRule { attribute Maplike<DOMString, DOMString> swash; ... }

glazou: example with Bongo, what would be value text?

<TabAtkins> (Maplike is proposed for WebIDL.)

glazou: from @swatch to closing brace.

<dbaron> Tab's proposal is in http://lists.w3.org/Archives/Public/www-style/2013May/0781.html

glazou: That is painful for editor.

[two people talking]

jdaggett: When I asked you in Tucson you said it was no pb.
... tab, is it writable?

TabAtkins: Yes

<glazou> I said I could live with it, I did not say it is perfect

plinss: values are always potential list of numbers?

jdaggett: Yes

plinss: Then lets not make everything a string when it can be a primitive in JS.
... So an arry of numbers.

<dbaron> plinss: should be a map of string -> number or string -> array of number

jdaggett: yeah

tab: no pb
... Any objections to my proposal?

glazou: I like it better.

dbaron: Is this ready in next month or so?

<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0781.html

TabAtkins: Cameron is going to add map-likek thing.
... Porposed a few weeks ago.

<jdaggett> interface CSSFontFeatureValuesRule {

<jdaggett> attribute Arraylike<DOMString> familyList; /* An array of family

<jdaggett> name strings. */

<jdaggett> attribute Maplike<DOMString, DOMString> swash; /* A map of feature

<jdaggett> names -> feature values */

TabAtkins: Cannot be string, ...

<jdaggett> attribute Maplike<DOMString, DOMString> styleset; /* Ditto */

<jdaggett> attribute Maplike<DOMString, DOMString> ornaments; /* Ditto */

<jdaggett> ...

<jdaggett> }

plinss: [missed]

<glazou> fine by me

<glazou> better than just one large string

tab: Yes, could just manually put it all in by hand, but ideally use IDL.

glazou: Resolve on Tab proposal?

jdaggett: Is that the one in IRC?

plinss: without string.

jdaggett: Others are interested in implem,enting it?

dbaron: you, tab?

TabAtkins: maybe, probabaly not, working on syntax...

dbaron: fine with proposal, worried that nobody implements it.

plinss: what is dbaron's q precisely?

dbaron: New IDL concept, or add a lot of hand writing JS
... Maybe 2 months of work.

plinss: You have to do that soon anyway.

jet: we don't write hand-written bindings nowadays.

TabAtkins: More verbose.

plinss: WebIDL is on its way up.

dbaron: I think we can resolve.

RESOLUTION: Tab;'s proposal for OM

<plinss> FWIW: WebIDL replacement: https://github.com/w3ctag/jsidl

jdaggett: next issue is
... feauture value blocks in spec,
... fantasai says they should just be called at-rules.
... But I think they are different.
... User defined identifiers.
... The way they compound is an issue.
... I tink it is important to day this is different form other at-rules, with descriptors.

Tab: That is just about terminology.

<fantasai> whttp://www.w3.org/TR/CSS21/syndata.html#at-rules

<jerenkrantz> is the resolved proposal the one from: http://lists.w3.org/Archives/Public/www-style/2013May/0781.html ?

Tab: It starts with an @-keyword, all at-rules ar edifferent already. so it is just an at-rule.

<fantasai> " At-rules start with an at-keyword, an '@' character followed immediately by an identifier (for example, '@import', '@page').

<fantasai> An at-rule consists of everything up to and including the next semicolon (;) or the next block, whichever comes first. "

glenn: Confusing for users to try and distinguihs them.

<stearns> jerenkrantz: yes, with a change from string to numbers (as far as I understood)

fantasai: CSS 2 calls it an at-rule when it starts with an at-keyword.

jdaggett: Yes, parses like an at-rule.
... Shoild we not call it something else?

<jerenkrantz> stearns: Thanks.

TabAtkins: Within the spec, call it what you want.
... Whatever makes sense. But technically it is an at-rue.

fantasai: Must be clear that it parses like one.

TabAtkins: ; But "font feaure value block" or whatever is fine.
... It expresses the concept.

jdaggett: So I need to say somewhre thet at-feature-value blocks aare at-ules.
... issue on font load postpone to tomoorow?

fantasai: Other issue is override.

jdaggett: Tomoorow, too?

fantasai: sure

jdaggett: Then that is it for fonts for now.

Syntax

TabAtkins: tokeinzation changes
... To match HTML, NUL chars are converted into replacement chars.
... Don't know why HTML does it, but at least it means CSS inside HTML is same as CSS in a file.

fantasai: Replacement char is valid identidier char, could be weird.

TabAtkins: Nobody puts NUL in a style sheet....

RESOLUTION: NUL gets turned into Replacement char.

tab: non-ascii range

SimonSapin: We already resolved on that.

glenn: Isn't the name non-ascii wrong then?

TabAtkins: No it now it includes *all* non-ascii.
... comments
... tokenizer never emits them.

plinss: What about comments between idents?

TabAtkins: Yes, serialzier forces an empty comment there.

plinss: OK, but does it change parsing behavior anywhere?

[tab draws on whiteboard]

tab: It should just be an internal simplifvation

Bert: Not sure what you mean.

<dbaron> Bert: there is no tokenization process

<dbaron> [argument between Bert and Tab/peterl/etc.]

bert: [worried about how people interpret "not emit"]

TabAtkins: It describes hwo you serialize.

glazou: We said in the paast that one way to preserve comments was to preserve them combined at the end.
... Important for editors.
... comments should be in original position, but cnnot always be done.

<dbaron> RESOLVED: loosen the rules describing the way comments are serialized

<dbaron> http://dbaron.org/css/test/2013/urange-token

TabAtkins: CSS 2 defines unicode range tokens in lazy way

fantasai: The difference is detectable.

dbaron: By means of counter increment.

fantasai: No real reason to not keep the same.
... Do not chnage the token.
... nder your rules some old are not longer valid, and it is detecatable.

tab: No, not detectable.
... U+2?3?4?

fantasai: We have to do range chaecking.

TabAtkins: No, [describes three cases]

dbaron: css3-fonts doesn't say it gets thrown out.

jdaggett: what gets thrown out?

<dbaron> U+400-3ff

dbaron: fonts spec not clear

<dbaron> unicode-range: U+100-1ff, U+400-3ff

dbaron: Is [above] a syntax error?
... Is that empty range or invalid and throw away whole line?

[tab and fantasai disagree on previous discussions]

TabAtkins: Invalidate whole descriptor.

dbaron: Is it just an empty range or invalid?

jdaggett: Wording to say that range has to contain valid chars.

dbaron: No implementation conformacne requirement.

<fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0564.html

jdaggett: you say wording is unclear.

dbaron: I can send comment about that, later.

TabAtkins: The only relevance of my change os for mixture of digits and digits.
... CSS 2.1 created invalid range, which was then thrown away.
... Fnal behavoir is the same..

fantasai: why chage. Let's not do tokenaztion changes.

TabAtkins: Easier to parse.

bert: depnds on parsing suystem.

tab: In mine token is always correct.

TabAtkins: Unicode range token only valid in one property.

plinss: Then I'm not so bothered.

Bert: But why change it.

fantasai: Current is fine.

dbaron: I don't believe the change is undetectable.

<fantasai> Gecko implements the 2.1 definition

Tab: Maybe in future.

<dbaron> I also don't mind the change.

plinss: That's is why it gets important.

TabAtkins: But I have to write more text to accept the old syntax.

glenn: Font family quoted string that is empty: seems not prohibited.

dbaron: You might have a font with that name.

glenn: Far fetched, but itis an answer...

TabAtkins: Not a sybtax question, question for fonts.

plinss: Whether you can test the unicode range syntax difference now is not the question.
... You're change maybe gives us more flexibility to not add white space in future properties.

fantasai: Not really, some unicode rabges end in digits, so not helpful.

dbaron: No, not helpful, there are too many different kinds of unicode range tokens. Often require a space anyway.

plinss: Then the change is irrelevant.

<dbaron> I agree the change is safe, and I agree it's pointless.

plinss: bert: But why chage it if is not broken?

[3 hands for tab's proposal 2 against]

TabAtkins: bad_url token and bad_string token.

plinss: What we talked about yesterday?

TabAtkins: Yes.

liam: Current UAs.

TabAtkins: Our parsing is wrong I believe.

glenn: doesn't seem right.
... Wouldn't call it valid.

plinss: It is not gray. We know when to throw a property away.

TabAtkins: New attribute matching operatore are imported into tokenizer.

Bert: The new attribute operatores are not tokens, they are two tokens.

Tab: But selectors defiend them as tokens.

Bert: No, selectors defiend how to parse selecotrs, not how to parse css.

plinss: Don't agree with bert's argument, but accept the point.
... 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

TabAtkins: : makes future syntax to have to be defined slightly differently, yes.

plinss: There is an impact.

<dbaron> TabAtkins: it doesn't reduce possibilities, but it might complicate grammars in the future

plinss: there is a general pont about selecor syntax leaking into rest of syntax.

TabAtkins: "||" is used in selectors 4
... Made it into a token.
... Because it clashes with namespace selectors.

plinss: Are we giving up too much to avoid 2-token look-ahead?

TabAtkins: I don't know.
... I heard 1-token was nice.

plinss: How important is it. You build it and forget about it.

dbaron: It is slower.

<dbaron> dbaron: There's a small performance cost to more lookahead, and I don't think it's worth it.

dbaron: I tend to think more lookahead is slower.

TabAtkins: I added a comma token.
... There was a colon and a semicolon already.

[Discussion about where COMMA is used. It is used in other modules, not in syntax itself]

TabAtkins: numebrs include sign, scie notation is allowed

<TabAtkins> url(foo bar)

TabAtkins: bad uri

<TabAtkins> bad-url("url(foo ")

(I don't see why we need tokenizer for number)

<jdaggett> can someone stitch up the phone again?

<TabAtkins> url(foo bar[baz)

<dbaron> jdaggett, shans is working on it

<jdaggett> thx

TabAtkins: this case [above] will be different.

<jdaggett> cool, thanks!!

TabAtkins: this is unlikely to have any bad effects.
... Have no bug reports.

fantasai: You're parsing invalid stuff anyway.

dbaron: It is about parens *after* the piece that already makes it invalid.

<fantasai> fantasai^: So if someone found a problem with your behavior, they'd be fixing their style sheet, not filing a bug

plinss: I want the token to close according to error recovery rules. Respect paren matching.

dbaron: this is recent -- something we were fiddling with to quite late in CSS 2.1, but it simplifes.
... Matches some implementations.

<fantasai> dbaron^: We've fiddled with this multiple times during 2.1 cycle

Bert: I don't udnerstand yet...

[dbaron explains]

<dbaron> url(foo bar[)

<dbaron> url(foo "bar[)

<dbaron> peterl: ok, I'm happy with it too

[discussion about where the error recovery picks up]

<fantasai> Ok, this makes sense to me seeing this example

Bert: I don't care about error recovery, si I'm fine, but be aware that you change the measning of existing style sheets.

Tab: Yes, we had no bug reports, so don't think it is a problem.
... CSS 2 grammar doens't cover all inputs.
... Error recovery not defined.
... So I'm defining error recovery.

dbaron: I'd like to review this more.

<dbaron> dbaron: Did you fix the cases where CSS 2.1 didn't allow CDO and CDC in some places?

dbaron: What about CDO CDC?

Bert: As long as it is only about error recovery for CDO/CDC in more places, fine with me.

<fantasai> ScribeNick: fantasai

An+B notation

TabAtkins: The notation is incompatible with CSS tokenization
... For example, 5n-3 tokenizes as a dimension
... But we need to split it up into 5, n, -, 3
... Implementations right now have to guess where it ends ... so far easy because of close-parens
... Then reserialize and reparse
... Wanted to redefine an+b in terms of CSS tokens
... I can get it almost identical to defined behavior
... But there are two small changes

dbaron: Think the WS change is not small

TabAtkins: First change is that +n or +n+2 ok
... but + n not ok
... Similarly -n vs. - n
... Issue is that when you tokenize these, +n becomes 2 tokens
... so does + n
... -n and - n tokenize differently
... Property grammars ignore white space
... So can't distinguish

<Bert> fantasai: I don't think ths needs to change.

dbaron: Tab just made up this idea of property grammars

TabAtkins: propdef grammars don't talk about ws

dbaron: I don't want to change the space rules here

TabAtkins asks how parsers work

dbaron says Gecko has a flag about whether ws is paid attention to

In WebKit, apparently WS tokens are omitted automatically when you ask for a token

fantasai: how can be possible in selectors?

<dbaron> div*p

Bert: Also numbers, numbers with a sign can't have space between number and sign

side discussion of NUMBER tokens

dino: White space is gone by the time you try to parse things

TabAtkins: How do you parse calc() and selectors then?

krit: ... something about whitespace and ident in WebKit

RESOLUTION: No spacing changes in An+B syntax

TabAtkins: +n-\33
... parses as "+" "n-3"
... which looks like An+B
... So, change to allow escaping in cases where the tokenization derives from idents
... Which probably matches implementations

Bert: So escaping before reparsing?

TabAtkins: no reparsing

<jerenkrantz> RRSAgent: make minutes

TabAtkins: escaping was handled much earlier in parsing process
... Disallowing it would create a major layering violation
... By the time you care about whether something is an+b, you've lost the original representation

plinss: So this scenario produces a valid ident, with content "n-3" as the string
... How does that become an an+b?

dbaron: Spec says if you have ident "-n-" followed by digits, then it's valid an+b
... I think this is far saner than the route we went down with URL, where we made it a separate token

TabAtkins: All three of these are equivalent, except they tokenize completely different

n - 3

n- 3

n -3

n-3

discussion of parsing mechanics among Bert, plinss, and Tab

<dbaron> [discussion of something else between fantasai and glazou]

RESOLUTION: escaping in An+B falls out of tokenization

TabAtkins: That's all the syntax changes that we've reviewed now
... So, can I publish yet?

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
... I'm worried because I think once we have FPWD, people will only look at this, not at CSS2.1
... So if we don't fix something now, it will b ehard to fix later
... And I'm worried because it was originally reverse-engineered from the worst implemenation (WebKit)

TabAtkins: I won't deny that.

Bert: I can't understand this draft, apart from the railroad diagrams. Can you put more of those, or put grammar rules?

TabAtkins: I think I have diagrams for everything in the spec

fantasai: does your spec define what a style rule is, what a declaration is, what these things mean?

TabAtkins: yes

SimonSapin: No, it doesn't

fantasai: I think we need to add such a section, since this part of 2.1 logically belongs here.

<Bert> (Seems all the production rules have diagrams.)

plinss: You asked for FPWD, but there's an existing css3-syntax draft

<jdaggett> what is peter saying? he's speaking in "peter quiet voice" again...

fantasai: From process POV, no. But effectively yes.

plinss: Just making sure that we plan to replace what's out there and is 10 years old

TabAtkins: yes
... (to fantasai) Maybe I'll expand the Description of CSS's Syntax section

SimonSapin: And make it normative

fantasai: We need something that defines how to interpret a CSS style sheet.

Regions/Shapes/Exclusions

stearns: Events and Fragmentation
... In fragmented flows, comes up in regions, but also issue in other types of fragmentation...

stearns has drawn some boxes

There is a big box, which represents the thing that contains the fragmentainers.

Inside are two fragmentainers, FC1 and FC2

stearns: These could be regions, pages, column boxes, whatever
... Crucial thing is that fragmented flow has an article, which contains a paragraph, and there's a break at some point in the paragraph

(represented by boxes A and P)

stearns: Issue is when you click in one of the fragments of the P
... The fragmentainer never hears about it
... The event goes out from P to A to the outer box, skips FC boxes

SimonSapin: Are the two FC boxes generated from the same element?

dbaron: In overflow fragments, yes, but not in Regions

dino: You said it doesn't matter, but is FC1 or FC2 regions, or columns... is A a child of that?

stearns: In overflow fragments A would not be a child of either container, would be a child of outer box

dbaron: In overflow fragments not that distinction, just the one level

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

Bert: Could have :hover on the outer box

stearns: I want the container to change
... Only when it's hovered inside, not when the other fragment is hovered inside
... And in Regions these can be different elements

dino: In A have one region element you're flowing into. Events don't get seen by region element

<Bert> (DIV:hover::slot(fc2) {... highlight... }.)

stearns: No

dino: you can't write a rule that says ::region:hover

stearns: right, and I want to

dino: me too

stearns: Regions has an API that allows you to determine which region got clicked.
... Doesn't work for hover but works for click events

<Bert> (Forget what I just said.)

stearns: That workaround only works for events, doesn't work for :hover styling
... But that workaround also doesn't work for fragmented elements

<stearns> http://wiki.csswg.org/spec/css3-regions/user-event-handling

stearns: There are two proposals for handling this
... First is for fragmented flows in general
... When you have event bubbling in a fragmentation context
... Event goes up through the chain as normal to the fragmentation root
... The thing that contains the content that is fragmented
... At that point, the fragment container is inserted in the bubbling
... And the bubbling continues with whatever contains the fragment container, up through the hierarchy.

dbaron: Are you talking about event bubbling because you want to change :hover, or because you want to change what event handlers get?

stearns: Yes. Both.

jdaggett: Issue on columns as well

stearns: Once we get to point of having addressable columns, can be done for columns
... If you want to know what page an even twas on, would have page inserted in event/style loop
... I'm actually not sure whether bubbling for CSS :hover is actually defined anywhere
... I assume it does the same

dbaron: It's not really bubbling, but it's defined

http://dev.w3.org/csswg/selectors4/#the-hover-pseudo

"The parent of an element that is :hover is also in that state. "

<jdaggett> was there a question?

<jdaggett> i'm muted...

stearns: One way to solve this, is, in a fragmentation context, insert the fragmentainer at the appropriate spot
... One more thing in the appropriate spot

dino: If it's a region, then does it bounce back to the ancestor chain or go up the region's ancestors?

stearns: Goes up the region's ancestors

This essentially circumvents the element's own ancestor chain

TabAtkins: Problem you're describing is virtually identical to problem with Shadow DOM and events
... Shadow DOM can rearrange content in a similar way
... Regions is slightly more general issue, but can be safely generalized under this as well
... Don't know precise details of what we do, but if you want details will have to ask Dmitry, who just went home

stearns: Shadow DOM describes it as DOM manipulation
... follow reordered DOM hierarchy

TabAtkins: After reordering and following up
... Things that aren't in the Shadow DOM have no way of telling that the event passed through the Shadow DOM

stearns: That's very important to shadow DOM, not so important here.

TabAtkins: Could break things if you add pseudos you didn't expect

stearns: It will continue to multicol element, just one added stop
... regions ...

fantasai: In case of regions, you might wind up not hitting your ancestors, because going up region's ancestor chain now.
... whereas other cases, you always walk up all your ancestors, just might make extra stops along the way

stearns: If you go through email thread linked from wiki
... Went through number of iterations tryng to figure out how to preserve event bubbling chain
... or dealing with this osmehow
... everything got way too messy
... Once you've put content into this fragmented flow, makes more sense to me for events to follow region's ancestor chain

fantasai: Depends on what you're trying to do
... 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

dino: Think it's very confusing to go up region chain
... If you wrote selector parent-element > child-content
... Expect that selector to apply
... wrote parent-element:hover > child-content to work
... But break that expectation

stearns: ...
... But named flow, taking boxes from parent, putting them over here
... these boxes should be ones responding to user events because you made that disassociation

dbaron: I find it really weird to have events not follow the DOM
... They're a DOM structure
... And I think separation of content and presentation makes it really weird for box-tree structure to mess with DOM structure

stearns: Have a response to hover styling?

dbaron: I think hover styling is separate from events

TabAtkins: Can be easier to handle :hover going two directions up the tree, than events going up the tree
... Could do complicated thing now with pseudo-classes, rather than events

<dbaron> dean: what happens with elementFromPoint()?

<dbaron> dbaron: it depends if there's content at that point in the region -- you get the most deeply nested thing

dino: Want to understand why :hover and events could be different

dbaron: :hover is a CSS concept

dino: Base don mouse events

dbaron: That's changed over time. It happens to be true now

plinss: We have whole dichotomy of things like mouse events, that deal with geometry of presentation
... These fire at the DOM tree, kindof broken

dbaron: We could have another type of mouse event that doesn't bubble, but that you fire at everything in that geometry
... We do sortof have that for mousover and mouseout

stearns: Another solution is to add a mode to pointer-events property
... So you could say for e.g. relpos'd box, events will follow box tree

Rossen: Going through iterations, another idea for adding region as a separate target

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

TabAtkins: element with fragment parent, goes to fragment parent rather than real parent?

stearns: Goes to whatever's displayed underneath it, which in fragment case would be fragmentainer

dino: One option is following DOM tree
... second is following box tree
... Third is following painting order

stearns: Second solution is not doing the middle event
... Right now pointer-events can be normal, they go up the DOM tree
... Can say pointer-events: none;, which ignores pointer events
... Switch would trigger just painting order
... You'd get the relpos box and whatever is underneath it

TabAtkins: So third one is elementsFromPoint() and walk that list

plinss: Where are you setting this switch?

The target of the element will decide on the path of the event

<jdaggett> followup on the subscript/superscript metric discussion, here's the example from hamburg:

<jdaggett> http://people.mozilla.org/~jdaggett/tests/subsupermetrics.png

dino: If you did something like this, set it on ancestor, does ???
... Doing propagation based on painting order is quite complicated, because implementations might forget exactly the order for perf reasons

<jdaggett> rssagent, make minutes

some concerns about implementation all around

TabAtkins: We have elementsFromPoint() already, regardless need to be able to get at that list

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference
06 Jun 2013

Attendees

Contents

CSSWG Priorities

Syntax

Fonts

font feature at-rule in OM

Syntax

Regions/Shapes/Exclusions

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference 06 Jun 2013

Attendees

Contents

CSSWG Priorities

Syntax

Fonts

font feature at-rule in OM

Syntax

Regions/Shapes/Exclusions

Summary of Action Items

Scribe.perl diagnostic output

Cascading Style Sheets (CSS) Working Group Teleconference
06 Jun 2013