<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
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
<dbaron> <br duration="900s">
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
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
<br type=lunch>
<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
<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.
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
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.
<dbaron> <br data-duration="900s">
[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
<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> }
<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.
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.
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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/plh/glazou/ Succeeded: s/glenn/glazou/ Succeeded: s/epub/epub way/ Succeeded: 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./ Succeeded: s/need/want/ Succeeded: s/plh/plinss/ Succeeded: s/4/3&4/ Succeeded: s/[???]/synthesizing italics by slanting/ Succeeded: s/precluse/preclude/ Succeeded: s/Conditional required/conditional mandatory/ Succeeded: s/??/Kazutaka/ Succeeded: s/??/Kazutaka/ Succeeded: 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/ Succeeded: s/match/map/ Succeeded: s/you you/you in Tucson you/ Succeeded: s/jet:/jet: we don't write/ Succeeded: s/2/@/ Succeeded: s/Than/Then/ Succeeded: s/changed/resolved on/ Succeeded: s/to/to do/ Succeeded: s/Reduces ossibilities/makes futre syntax to have to be defined slightly differently/ Succeeded: s/futre/future/ Succeeded: s/recent/recent -- something we were fiddling with to quite late in CSS 2.1/ Succeeded: s/two/two small/ Succeeded: s/something about whitespace and ident/something about whitespace and ident in WebKit/ Succeeded: s/Yes./Yes. Both./ Succeeded: s/jdaggett/djovey/ Succeeded: s/djovey/jdovey/ Found ScribeNick: fantasai Found ScribeNick: Bert Found ScribeNick: fantasai Inferring Scribes: fantasai, Bert Scribes: fantasai, Bert ScribeNicks: fantasai, Bert 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 Thierry Michel Taro Yamamoto (Adobe) WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 06 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/06-css-minutes.html People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]