- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 08 May 2013 22:54:45 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish Box Alignment WD
- Discussed issue of synthesizing obliques in vertical text
http://lists.w3.org/Archives/Public/www-style/2013May/0153.html
This was a controversial topic and missing key people; no conclusion yet.
- RESOLVED: Accepted proposal for fixing computed value of unresolvable
percentage heights in CSS2.1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
- Discussion of whether and how table cells form pseudo-stacking
contexts deferred to F2F for whiteboardability.
- RESOLVED: Accept start/end proposal for both axes as described in
http://lists.w3.org/Archives/Public/www-style/2013Apr/0265.html
- Reviewed open issues in CSS3 Text Decoration Disposition of Comments
http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
John Daggett
Jim Dovey
Tantek Çelik (via IRC)
Elika Etemad
Simon Fraser
Sylvain Galineau
Dael Jackson
Dean Jackson
Peter Linss
Anton Prowse
Florian Rivoal
Alan Stearns
Nick Van den Bleeken
Lea Verou
jerenkrantz
<jdaggett> greetings!
<Ms2ger> Isn't it really late or really early for you?
<jdaggett> really late...
<jdaggett> must... keep... eyes... open...
<RRSAgent> logging to http://www.w3.org/2013/05/08-css-irc
<stearns> I'll be listening on the phone but probably only providing
input in IRC
ScribeNick: fantasai
Agenda: http://lists.w3.org/Archives/Public/www-style/2013May/0178.html
Box Alignment Publication
-------------------------
plinss: follow-up from last week, publishing Box Alignment?
plinss: Did anyone read/review it? Ready to publish?
* dbaron meant to read it but didn't have a chance
jdaggett: FPWD or WD?
plinss: WD
RESOLVED: Publish Box Alignment WD
Tokyo F2F
---------
<jdaggett> http://wiki.csswg.org/planning/tokyo-2013
jdaggett: Looking for input from WG if need any more logistical info
jdaggett: If you have questions, etc.
Rossen: More explanation of hotels?
...
fantasai: Google Maps will give walking directions
CSS3 Fonts: Synthesized Oblique in Vertical Text
------------------------------------------------
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013May/0153.html
jdaggett: Definition of synthetic oblique doesn't say which way to slant
jdaggett: Particularly in vertical text case, is complicated due to
mixed orientation
jdaggett: Multiple possibilities
<jdaggett> http://koji.ec/archives/7
jdaggett: Most significant options are 6 and 8
jdaggett: Most browsers slant towards the right when making synthetic
italics
jdaggett: 8 is what WebKit does, 6 is what IE10 does
jdaggett: There is a tradition of obliquing in Japanese that is closer
to 6, however in case of font-style property, doesn't make
sense to try to shoehorn this into obliquing
+Dino
jdaggett: Should have property that handles explicit obliquing.
jdaggett: Should handle not just shearing, but rotating glyphs
jdaggett: Koji also brought up Arabic and Hebrew in original email
jdaggett: Very interesting cases, because not clear whether should
slant to left or to right
jdaggett: When making Hebrew versions of Adobe publishing fonts, faces
with both slants were made
jdaggett: Not an easy problem to tackle
jdaggett: Would prefer not to tackle things in Fonts spec in current state
jdaggett: I think we should just define what browsers do now, and not
try and do what IE behavior is.
jdaggett: Because the font-style property is about font selection, it's
not a font effect property
jdaggett: Only case when you get a synthetic oblique is when there's
not a real oblique defined
jdaggett: So should try to define behavior that only happens in fallback case
jdaggett: I proposed wording that says synthetic oblique always goes
to the right, which is what browsers do today except IE in
the vertical case
+TabAtkins
fantasai: There's a problem here, wish Koji was on the call to explain
it better.
fantasai: Problem is when you have Roman characters that don't have
italics
fantasai: And you try to synthesize it with this method, slanting to
the right
fantasai: What you get is number 7
fantasai: When you are slanting rotated text to the right, you are
skewing to the right, which creates wiggly text
<stearns> isn't it slanting to the end edge more than the right?
<fantasai> stearns, no, it's slanting to line-left, because in Hebrew
we synthesize right slant
<dino> fwiw, we have a bug in WebKit on this that I'm trying to fix.
We apply a horizontal skew, no matter what (which we think is
wrong). I'm happy for us to decide what the correct result
should be.
jdaggett: Synthetic face means you make synthetic glyphs that are
slanted to the right similar to what a real oblique face
would look like
jdaggett: and you lay out upright or rotated runs using those glyphs
dino: Have a bug in WebKit on this that publishers complain about
dino: When we apply skew always in horizontal direction, and get many
complaints that this is incorrect
dino: Our only workaround is to say use a font that doesn't synthesize
obliques
dino: But current behavior is wrong
dino: we do 7 at the moment when synthesizing italics
<stearns> I'm all for describing current browser behavior for this error
condition. I don't think we should be spending time trying to
make this work precisely correctly, because it's an error to
have faux italic in all cases
jdaggett: font-style is one of the properties that determines face
selection within a family
jdaggett: The only time that obliquing occurs is when there is no italic face
jdaggett: Already right there have this differentiation that causes
problems if publishers want 6 in all cases
dino: Don't understand what they want 6, because changes Japanese text slant
dino: 6 slants Japanese text vertically
fantasai: which is what word processors do
rossen: We align with word processors in this case
jdaggett: Think there is an inherent assumption that only Japanese fonts
with no associated Latin italic glyphs are used
jdaggett: Once you mix font families with true italics, you get an odd
mixture depending upon the orientation specified
jdaggett: For example when Arial is specified for a given element
independent of the script used, very common on the web
(e.g. Facebook)
jdaggett: For Latin glyphs a real italic face will be used (i.e. Arial
Italic) but Japanese displayed with a fallback font
jdaggett: will typically be rendered with a synthesized oblique
dino: Think Japanese publishers want 8
<stearns> heh
dino: Definitely don't want 7
plinss: So specify #8, maybe add controls for obliquing direction in
future
fantasai: I don't agree with that
rossen: I don't agree with that
+koji
fantasai: 8 is not a real option, because it uses true italics. What
happens when everything is synthesized? The result is not
in this list
<dino> I believe John is saying #8, but where it was synthesized
oblique (unlike in the diagram)
dbaron: Why does synthetic obliquing have to happen before rotation?
fantasai brings up case of obliquing vert glyphs
jdaggett: If you want it to look good, get an italic font.
jdaggett: Italics isn't used in japanese. Obliquing is used, but it's
an effect like stroking or outlines
rossen: Last time I was talking to Koji in Tucson, his opinion, when
describing differences between 6 and 8, was that the feedback
he's getting is half ppl asking for 6 for compat with word
processors, other half asking for 8 mainly in EPUB space
rossen: I think this discussion would benefit from having Koji plugged
in before we take any decisions
Koji: 6 is not for compat with word processors, but also necessary for ...
Koji: 8 ... 8 also has special requirements
e.g. should not synthesize certain characters
Koji: Had to write a patch to limit synthesizing for special characters
Koji: Many issues before you go with 8
jdaggett: If you want complexity, need to spec it out
jdaggett: It's a font selection property, need to look at how that works
in context
fantasai: What Koji is saying is that getting 8 right is complex,
whereas getting 6 is straightforward. If we want to avoid
complexity, we should go with 6
* dbaron doesn't see why 6 is simpler than 8
* sgalineau not sure what 'word processors' really means. are there
several independent WPs in Japan that do agree or do we
mean Word and things that copy it?
<fantasai> dbaron, 8 is more complex because there are additional
requirements to make that behavior work for Japanese
[...]
Discuss taking this offline or to F2F
plinss: If you can come up with something, come to group. Otherwise go
to F2F
jdaggett: That holds up LC by a month
plinss: Understood. Work something out over email then.
dino: If helps any, can get iBooks Japanese team to get feedback
jdaggett: Problem I'm having here is that we need to specify something,
and need to specify it in terms of font style
jdaggett: The whole mechanism, how does it work
jdaggett: Given existing mechanism, one makes sense other doesn't
<TabAtkins> I thought we were taking this offline!
<TabAtkins> >_<
<Rossen> yes, and you're on that line now...
* stearns would be OK with specifying a random slant for every glyph,
so that people wouldn't use faux italic :)
fantasai: Want to make it simple? Say that in the synthesized font the
regular glyphs are slanted to the right, and there exist vert
glyphs for each codepoint that slant down.
jdaggett: We need a concrete proposal
jdaggett: that says how font-style works
koji: If fantasai and I come up with proposal, it's ok?
jdovey: If Koji can put in writing what the exceptions are for Japanese,
what problems are with 8, that would make this conversation go
a lot more smoothly if we were to defer to next call or email
or wherever
jdovey: Getting across what issues are for vertically oriented languages
seems to be the real problem right now.
CSS2.1
------
plinss: Next topic, CSS2.1 issues
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392
fantasai: we had an issue open on the computed value of percentage
heights that can't be resolved
fantasai: proposed wording in comment #2
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15392#c2
fantasai: Do we accept or not?
dbaron: fine with me
RESOLVED: Accepted
Discussed table pseudo-stacking contexts -> F2F for diagrammability
dbaron: But I might be in favor of reverting the previous resolution
on tables and leaving things the way they are.
Flow-Relative Directions
------------------------
TabAtkins: Want to see if Block-axis logical names proposal makes
people happy
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Apr/0265.html
TabAtkins: Proposal is to use 'start' and 'end' in both axes, and
when necessary to disambiguate, use e.g. 'block-start' /
'inline-start', or 'row-start' / 'column-start'.
TabAtkins: Would also simplify spec text referring to start/before corner
dbaron: Would existing margin-start/margin-end prefixed implementations
become margin-inline-start/ margin-inline-end?
fantasai: Yes, and that gives you very useful shorthands margin-inline
and margin-block.
plinss: Concern about using as values, being ambiguous
TabAtkins: It is actually one of the best advantages of this proposal
TabAtkins: Because some properties (e.g. alignment) don't have to map
before=>start etc., since property applies to different
axes depending on context.
TabAtkins: Just say start, it is correct always
glenn: Only negative in that is that start/end/before/after are used
to refer to edges as well
glenn: If you use start-edge and end-edge, it's ambiguous
TabAtkins: If you need to distinguish, use "block-start edge" and
"block-end edge".
glenn: Not objecting, just pointing this out
plinss: Just to be clear, it's the spec author choosing whether to use
start vs. block-start, not page author
TabAtkins: Yes.
TabAtkins: Brad and Simon noted approval in the thread
plinss: Any objections?
Rossen: No, let's take it. This one actually sounds pretty good.
RESOLVED: Accept start/end proposal for both axes as described in
http://lists.w3.org/Archives/Public/www-style/2013Apr/0265.html
Rossen: No more head/foot!
* sgalineau bikeshed: shrink;
* florian claps slowly
Text Decoration
---------------
ScribeNick: TabAtkins
fantasai: Issue 15
http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-15
fantasai: Question is whether text-shadow color is the color of the ink,
or the color of currentcolor.
fantasai: Moz does one, WK does the other.
fantasai: I don't know if there's a good answer to this.
fantasai: If using the ink color, then if using a red underline, the
underline's shadow will be red, even if the text is blue.
fantasai: Which can bring some interesting effects.
fantasai: But I'm curious about patterned fills.
TabAtkins: Does that apply to currentcolor stuff too?
fantasai: No, only the ink case.
leaverou: If we choose to use currentcolor, is there any way to
emulate the behavior of the browses that shadow the ink?
fantasai: No.
leaverou: So maybe choose that, since authors can explicitly hook into
the currentcolor behavior.
plinss: Does it make sense to allow for hooks in the future to control
the color of the shadow of decoration and text independently?
fantasai: That's enough of an edge case that I don't think we'll get
there for 25 years. ^_^
plinss: I think it's odd to have a default that you can't create manually,
but I don't feel too strongly.
-jdaggett
<fantasai> oh, man, we just lost jdaggett, and need him for the next issue :(
dbaron: I tend to think the reason to use Gecko, is if people use
text-shadow to apply a slight blur to text.
leaverou: I can see shadowing the ink useful for that - I've done it myself.
plinss: Gecko's behavior is to use the ink color for the shadow?
dbaron: Yes.
plinss: So it makes sense when using the shadow for something that's
not actually a shadow.
plinss: Anyone think it's problematic to implement?
TabAtkins: No idea, but I'm willing to accept it and see if anyone
complains afterwards internally.
fantasai: Briefly explaining the rest of the list.
http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-6
fantasai: Issue 6 requires someone with an understanding of font metrics
to read through it and comment.
fantasai: jdaggett or someone at Adobe would be helpful - someone with
experience in underlining metrics.
fantasai: Related issues: 11, 12, 13
fantasai: What do you consider when you are setting the underline
thickness/position?
fantasai: 12 is about whether we should consider descendants, or just
set thickness from the element itself.
fantasai: 13 is the same, but for position.
fantasai: 11 is about, when we do any consideration of descendants,
do we do it per-line or across all lines in the element?
fantasai: So that's what's on the table - if you have an interest,
please take a look at them and we can talk about them later.
Meeting closed.
Received on Thursday, 9 May 2013 05:55:22 UTC