- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 04 Oct 2012 08:11:39 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Test the Web Forward registration is now open for Paris (26-27 Oct 2012)
http://testtwfparis.eventbrite.com/
- RESOLVED: the three profiles (TV, Mobile, Print) will be moved to Notes
- Discussed case-sensitivity of user identifiers
- Discussed splitting transform-origin into x/y/z sub-properties
- Discussed making fixedpos elements always form stacking contexts
- Discussed position of text decoration over font size changes
- Reminder: @supports going to LC next week unless ppl find blocking issues.
So don't forget to review!!
====== Full minutes below ======
Present:
César Acebal
Rossen Atanassov
Tab Atkins
Ryan Betts
Bert Bos
Arron Eicholz
Katie Ellison
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
John Jansen
Edward O'Connor
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Steve Zilles
Regrets:
David Baron
Rebecca Hauck
Peter Linss
Lea Verou
<RRSAgent> Logging to http://www.w3.org/2012/10/03-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2012Oct/0052.html
Scribe: antonp
Test the Web Forward
--------------------
<stearns> http://testtwfparis.eventbrite.com/#
stearns: Registration of the event is now open; please evangelize!
TV/Mobile/Print Profiles
------------------------
glazou: Bert raised this, but he's not on the call
glazou: Bert suggests moving these specs to Note status, since they're
going nowhere. I think it's reasonable
Tab: I agree
fantasai: I strongly agree
fantasai: We have to update all the references, though
glazou: a Note is informational. It's not a Rec track document
Rossen: What does it take to put a doc on the Rec track again?
glazou: it can come back, but with the usual administrative overhead
of any other REC track doc
glazou: we're not changing the contents of the doc
sylvaing: will the URL change?
glazou: I will discuss with Bert. We still want the same URLs, but
perhaps they could redirect elsewhere or else a notice
describing the move
fantasai: I don't think it'll be a problem. Switching the snapshots
from REC-track to NOTE wasn't a problem.
glazou: No objections?
RESOLVED: the three docs (TV, Mobile, Print Profile) will be moved to Notes
Case sensitivity of user-defined identifiers
--------------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0535.html
TabAtkins: a blocking issue remains on the drafts
[Tab explains the issue]
TabAtkins: At a minimum, Need to make User-Defined Identifiers (UDIs)
ASCII case-insensitive, the same as Language-Defined
Identifiers (LDIs)
[Tab explains]
fantasai: Unicode provides case-folding algorithms
fantasai: Option 1: ASCII-only folding; confusing for users
TabAtkins: but it's consistent with how HTML works
TabAtkins: getElementById method, IDs are case-insensitive
TabAtkins: in the ASCII range
TabAtins: it's a legacy constraint
TabAtkins: they do show up in UDIs
TabAtkins: Option 2: Latin-based case insensitivity
TabAtkins: Option 3: some hybrid
glazou: When you refer to Latin, do you refer to the space or to the
characters. They're not the same
fantasai: we could do the full set of Latin characters, but not any
other script
glazou: so the space; é is one single glyph
glazou: we should be aware that é can be formed in several different ways
fantasai: there's lots of discussion recently; not sure we can close
the issue; I18N needs to comment
fantasai: would be a good F2F issue for joint groups
glazou: needs more investigation than only CSSWG; touches many areas
ACTION: TabAtkins to e-mail I18N
glazou: would like dbaron and howcome to be involved
ACTION: glazou to schedule a joint meeting with I18N
<trackbot> Created ACTION-510
<Zakim> +Bert
<Zakim> +krit
Anti-aliasing on Mac
--------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0014.html
* fantasai thinks this is a topic that requires jdaggett
TabAtkins: it's font-hinting, not anti-aliasing
TabAtkins: native font engine makes the characters fatter than they
appear elsewhere eg Win/ Linux
* sylvaing has always been told Macs ignore font hinting instruction
TabAtkins: in some situations we can't do proper hinting, eg in rotated
text or 3D
TabAtkins: Switching between the two causes a drastic visual change
TabAtkins: I need to figure out what other folks are doing for the Mac
TabAtkins: Should this be an issue for the WG?
TabAtkins: Which solutions have others come up with?
TabAtkins: I'd like to know
Leif: I started looked into it, but haven't got feedback yet
TabAtkins: OK, I'll take it up again next week
Bert: I understand there's a problem, but are you looking for a solution
from WG?
TabAtkins: Don't know; would like to hear from other implementers to
understand whether this is something our team can fix on
our own with a proprietary extension, or whether it's a WG
issue
smfr: Apple is aware of the problem; not sure it's accurate to say that
hinting is the difference. Involves gamma correction amongst
other causes. We've experimented with some APIs but we haven't
got improvements in all cases
smfr: I don't think there's an implementation solution for this.
Implies that maybe we need a CSS thing to fix this
TabAtkins: I'll hold up on this topic for the moment
text-decoration
---------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Aug/0379.html
<glazou> data:text/html,<!doctype html><s>foo<font size=7>bar</font>baz</s>
glazou: raised by Aryeh Gregor
fantasai: the strike-through will be skimming along the bottom of the
glyphs instead of going through them; this is because we
dictate only one position for the strike-through
fantasai: Aryeh's solution is to put the underline wherever it's
supposed to be... but that leads to jumping around.
Can cause lots of jitter in cases where the font size
change is small, or only the font face changes.
I don't think it's a good solution
fantasai: Best suggestion I could come up with: pick one position,
and that position has to stay constant, unless an element's
preferred position would be outside a 0.3em tolerance.
fantasai: although if we only care about common cases, just small
font size changes or immediate nesting like in Aryeh's
case, the position-averaging recommendation in the spec
would be enough. It's only large font-size mixes that
need something like what I suggested.
glazou asks about word processors
fantasai: MS Word changes the position of the underline with every
change in font styling and vertical align switches
glazou: yep, I just tried in Word on Mac
SteveZ: I support your position that the underline ought to be
calculated for the whole stretch... but how much is the
strikethrough problem an issue in reality
fantasai: for people trying to use HTML as a word-processor format,
it's a problem
fantasai: because WYSWYG editing results in two nested elements, and
it's a problem if the outer element is carrying the line
and font size changes on the inner one
glazou: the usual rendering for DEL is strike-through
glazou: it's probably not too uncommon
TabAtkins: Suggestion is reasonable
SteveZ: It'll be hard to get interop, so bugs would be filed
fantasai: I don't think the threshold would handle vertical alignment
though. I think you'd have to ignore vertical alignment
when doing these things
fantasai: One of the problems with an overline is that if the font-size
increases then the overline looks like a strike-through
fantasai: need intelligent averaging
fantasai: the problematic case seems to be immediate nesting; that
case is solved by averaging
glazou: What about overline? The original usecase?
fantasai: the overline looks like a strike-through, which is a problem
glazou: what do you want to overline? the whole element, or the
characters inside?
glazou: Is there one overline for the whole thing, above the highest
thing? Or one per sub-element?
fantasai: neither. If the elements don't change size much; you want a
common line. If there is, then the line should break
glazou: I tend to agree with the proposal
TabAtkins: yes
fantasai: So, how do you implement and test the proposal?
TabAtkins: I don't see the problem. [...]
SteveZ: Must define it with an understanding that there can be hanging
fonts
TabAtkins: definition should be relative to the baseline, so that in a
centred font the line would go through the centre
SteveZ: this is a trigger that says that we'll break sequences of
lines when the difference is bigger than a threshold
<stearns> I think any automatic behavior is going to be inadequate.
underline-offset and underline-weight, etc. would be the
way to solve this
<fantasai> stearns, a fixed offset won't help here
smfr: I haven't looked into this much
glazou: do folks want a week more to look into this
<fantasai> ACTION fantasai: write this up, with examples
glazou: topic deferred to next week.
stacking contexts for position:fixed
------------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Oct/0000.html
sylvaing: should position:fixed elements create a stacking context?
sylvaing: Microsoft are unconvinced about compat; reluctant to make a
change
* fantasai notes that this is a request to change for CSS2.1
TabAtkins: on mobile this happens, because fixpos is hard on mobile
and this simplifies it
Tabatkins: easier to optimize scrolling on our mobile browser, if
stacking context formed.
sylvaing: I'd like to see what makes you believe that. And are the
sites in question designed for mobile web or for *webkit*
mobile web?
sylvaing: fixpos is a mess, so people relying on it doesn't tell us
too much
TabAtkins: the scrolling people tell me this change would help
smfr: I implemented it on iOS and on desktop Safari. The proposed
change makes implementation much easier
sylvain: so because it helps Webkit, we should adopt this change for CSS?
smfr: well, yes... we didn't find any big compat problem. Google
also did some research and didn't find compat problem either
smfr: I think it's a reasonable change
TabAtkins: It's bizarre to interleave into a fixpos element
TabAtkins: we think it's a reasonable change
<SimonSapin> +1 for this change, it makes implementation (and thus my
job) much easier. But I don’t know about web compat.
krit: is this change in current versions of chrome?
smfr: no desktop Chrome or Safari has released this yet.
TabAtkins: we've got Canary builds with this thing in
smfr: the sites that were broken are mostly Google properties
TabAtkins: and in those sites we didn't /need/ the behaviour which
was breaking; it was accidental and we could work around
the breakage
glazou: I haven't heard general agreement about this change
sylvaing: need more research
TabAtkins: I'll provide examples
Rossen: The overall intention doesn't seem crazy. But I would like
to know what the damage would be across both mobile /and/
desktop
<lstorset> +1
Rossen: please provide examples
Rossen: then we can make a group decision
TabAtkins: this change would also affect stickypos
antonp: Does the stacking context section of CSS2.1 explicitly
distinguish between abspos and fixedpos?
antonp: fixedpos is considered abspos in most parts of CSS2.1
TabAtkins: issue is that abspos doesn't create a stacking context
necessarily
TabAtkins: The issue is fixpos with z-index:auto - we want /that/
to form a stacking context
* Bert : thanks for that q Anton, now the issue finally makes sense :-)
transform-origin-x/y
--------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Sep/0549.html
krit: Boris noted that apparently WebKit implements transform-origin-x
and transform-origin-y properties. Should these be in the spec,
perhaps?
TabAtkins: I think it's a reasonable set of properties
smfr: we should be consistent with properties which reference points
and offsets, which don't have separate x/y properties
fantasai: in the case of background-position, where we have keywords,
it's hard to split it out
fantasai: especially if we accept to add logical keywords, which i18n
has been requesting for a long time and which we deferred
to level 4
fantasai: transform-origin properties don't accept keywords so don't
suffer from the awkward issues
<sylvaing> x/y/z longhands is kind of natural for animations
TabAtkins: We don't want to do logical coordinates for transform-origin.
Unlikely.
TabAtkins: so, webkit already does this
Bert: What is the use case? Yet more properties.. are they useful?
?: Easier to animate when split up
fantasai: I can see wanting to animate axes separately for transforms
fantasai: Definitely would want that to be easier
fantasai: but for transform-origin, seems unlikely to be popular
Sylvain: Could be fun to transform the origin, but yeah, not as common
sylvaing: Are there other places where we'd want to split this
smfr: perspective-origin
glazou: is there any objection from vendors?
sylvaing: do we do this only for origin? Why not other properties?
TabAtkins: it's definitely the only place in /transforms/
smfr: no, there's perspective origin
<smfr> http://www.webkit.org/blog-files/3d-transforms/perspective-by-example.html
Bert: what's that for
TabAtkins: If you want to spin around the DOM structure:
a) move the perspective origin (camera) or
b) move everything else.
TabAtkins: (a) is easy
* fantasai defers to dbaron on this issue
* fantasai is not qualified to comment on behalf of Mozilla
* sylvaing is not qualified to comment on behalf of Mozilla either
glazou: the possibilities opened seem to be cool, but I need more than
that to make a resolution
fantasai: I'd like to defer until dbaron has commented
fantasai: Wrt animations, seems more important to make transform itself
easier to animate, rather than split up transform-origin
glazou: OK, perhaps defer to F2F
Reminders
---------
glazou: 5 mins left. Anything else?
fantasai: Prioritization of specs
glazou: I started aggregating the data. Today I got the answer from W3C.
I didn't finish (I was sick for a while)
glazou: I'm still missing a few people
glazou: you know who you are ;-)
fantasai: Reminder that we're planning to take css3-conditional to LC
next week
Meeting closed.
Received on Thursday, 4 October 2012 15:12:20 UTC