W3C home > Mailing lists > Public > www-style@w3.org > May 2013

[CSSWG] Minutes Telecon 2013-05-08

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 08 May 2013 22:54:45 -0700
Message-ID: <518B3A25.5080001@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - RESOLVED: Publish Box Alignment WD
   - Discussed issue of synthesizing obliques in vertical text
     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
   - 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
   - Reviewed open issues in CSS3 Text Decoration Disposition of Comments

====== Full minutes below ======


   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


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

   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
   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
   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
   fantasai: I don't agree with that
   rossen: I don't agree with that
   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.


   plinss: Next topic, CSS2.1 issues
   fantasai: we had an issue open on the computed value of percentage
             heights that can't be resolved
   fantasai: proposed wording in comment #2
   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
   Rossen: No more head/foot!
   * sgalineau bikeshed: shrink;
   * florian claps slowly

Text Decoration
ScribeNick: TabAtkins

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

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:29 UTC