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

[CSSWG] Minutes Telecon 2013-07-03

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 03 Jul 2013 14:08:08 -0700
Message-ID: <51D492B8.20305@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - krit requests review of CSSMatrix interface for FPWD

   - RESOLVED: text-combine compression is UA-defined, however UAs
               MUST transform full-width chars/glyphs before
               compressing them. Spec will include jdaggett's sample
               algorithm as an example for UAs to follow.

   - RESOLVED: text-decoration line thickness and position undefined in L3
               (replaces previous resolution at Tokyo F2F)

   - RESOLVED: undefined in L3 whether text and decorations are composited
               before shadowing or not

   - RESOLVED: Drop text-underline-position: alphabetic

   - RESOLVED: Take CSS3 Text Decoration to CR

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

   Glenn Adams
   Tab Atkins
   David Baron
   Justin Erenkrantz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Dael Jackson
   Koji Ishii
   Peter Linss
   Edward O'Connor (late)
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Leif Arne Storset
   Nick Van den Bleeken
   Lea Verou
   Steve Zilles

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jul/0061.html
<RRSAgent> logging to http://www.w3.org/2013/07/03-css-irc
Scribe: SimonSapin

CSSMatrix review

   <krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
   krit: SVGMatrix is 2D. With transforms, we need 3D
   krit: discussed having a CSSMatrix interface, unified between specs
   krit: asking for FPWD. Concerns/discussion to the ML

CSS3 Text

   plinss: follow up on text-align-last
   fantasai: Rossen is not on the call, defer

CSS3 Writing Modes

   fantasai: ML discussion with jdagget
   fantasai: jdaggettís proposal for exact rules of resizing. Spec says UA-defined
   fantasai: Propose to put his algo as an example, and examples of things
             that could go wrong
   fantasai: but leave normative text as UA-defined, leave leeway
   fantasai: UA could give better results than this exact algorithm
   fantasai: Koji and I want to allow better results
   fantasai: Want to make sure itís at least "good". Think having an example
             algo is a good way to do that.

   florian: how to add controls in future levels on UA-defined behavior?
   fantasai: Plan is to have a text-compression mode switch, where the
             default is 'auto'
   florian: some switches might match auto in some UAs
   fantasai: yes
   florian: worried about "do what you want auto", if one UA is dominant,
            hopefully itís not too broken
   florian: content will depend on the de-facto meaning of auto
   fantasai: seems unlikely

   fantasai: if we have an example in the spec, most UAs will follow that
             unless they try to do better
   fantasai: example is not complicated
   florian: would be nice to have tests for this non-normative description
   fantasai: We can have "may" tests.
   fantasai: tests specific to OpenType, specific fonts
   fantasai: If the spec has clear examples, implementations will follow
             that better than a normative generalization in the spec.

   SteveZ: concern: dealing with 2 things. auto is used to do the right
           thing for the normal case, bunch of features separately
   SteveZ: example: full-size latin letter different than latin letters,
           without markup
   SteveZ: there, clear algorithm
   SteveZ: here, auto is you can do possibly better than this
   SteveZ: different use of auto, usually it means something specific, not
           do something UA-dependent.
   SteveZ: not sure you really want 'auto'
   fantasai: it is automagic
   SteveZ: users complain without the magic
   SteveZ: people want to do what the users expect
   SteveZ: to way to have this is normative text and test cases
   SteveZ: examples are nice but Ö we trip over automagic

   fantasai: I donít expect lock-in in this case
   fantasai: If you do a good job, no need to match against anything else.
   fantasai: If it looks bad, author will just not use the feature there.
   fantasai: There's no way to tweak the resulting layout for one implementation.
   fantasai: You either enable it or don't.
   fantasai: no effect on the rest of the layout
   SteveZ: still uncomfortable about undefined automagic
   koji: discussing rendering quality, doesnít matter much
   florian: little uncomfortable, but can go with this

   plinss: jdaggett seems to have concerns with this. Can you summarize?
   fantasai: Heís concerned that implementations will do worse because
             normatively, it's allowed.
   fantasai: We'll add examples of "donít do this"
   plinss: Normative restrictions? "Can do better, but donít do this"
   fantasai: I'm ok with that.
   florian: limited normative requirements
   plinss: problem is defining "better"

   plinss: objections?
   fantasai: proposal is: normative prose says "UA-defined how the compression
             happens, but must transform full-width to half-width or proportional
             before compression"
   fantasai: then add jdaggett's example algo
   fantasai: and suggestions to do better
   fantasai: This requires transforming at least full-width.
   fantasai: and we have an example of what people expect.
   fantasai: a UA can do simpler--e.g. only graphic compression, no glyph
   fantasai; Or can do smarter--e.g. dealing with cases where glyphs are only
             partly missing--
   fantasai: But normatively require donít do this, that looks bad.
   RESOLVED: accepted the above proposal

CSS3 Text Decoration

   plinss: issue: making line positioning undefined
   fantasai: discussed at F2F
   fantasai: CSS21 says "position and thickness is undefined. May consider
             font info of the descendant that you are underlining, but not
             required. But must have one non-broken line"
   fantasai: 2 interpretations of "on one line"
   fantasai: either way, allowed to consider the descedants

   fantasai: in L3, we tightened up the prose --
   fantasai: Aryeh had raised a concern when strike-through doesnít go
             through the text, e.g. if striking through element contains
             element sizing the font larger.
   fantasai: spec says how to calculate, what to consider or not,
             eg. skip vertical-align'd content

   fantasai: dbaron against. Says it's complicated, and concerned that e.g.
             a bunch of links that should be the same, if one contains some
             subscript, its underline will be offset from the others by a
             a few px.
   fantasai: F2F proposal was to just use the underlining element's settings.
   fantasai: But this works poorly for Aryeh's case
   fantasai: And it's really bad if you don't align to alphabetic baseline
   fantasai: e.g. in vertical text, default is to use central baseline
   fantasai: underline can cut through the text, when element contains text
             that's bigger
   fantasai: I think this is worse than a few px off
   fantasai: donít want to require this behavior in CSS
   fantasai: underline should be on one side of the text alway IMO, not cut
             through it

   fantasai: For this level, no consensus on exactly what we want, so propose
             to leave undefined like 2.1
   fantasai: Deal with it in L4.
   dbaron: fine with me, with explanation why
   fantasai: ok, specifics?
   dbaron: the two rationales that you just said
   plinss: opinions?
   RESOLVED: text-decoration line thickness and position undefined in L3
   <SteveZ> What can we do to resolve this in Level 4

   fantasai: 2 more issues
   fantasai: shadows. Text underlined, separate shadow? Or composite together
             and shadow that?
   fantasai: Looks different with semi-transparant shadow color.
   fantasai: I think we want the shadow to be drawn at once, combined
   dbaron: thatís a lot more impl. work
   dbaron: I donít know that we define it for overlapping glyphs, but
           should be the same
   smfr: Within the same text run, one shadow
   smfr: accross spans maybe not
   smfr: for the underline, looks nicer if painted as one
   leaverou: I think composited shadows make more sense, but can also be
             achieved with filters
   dbaron: I think this should be left undefined at this level
   fantasai: ok with that

   leaverou: what do browsers do?
   dbaron: (missed)
   leaverou: what if letters overlap?
   dbaron: not sure, depends on whether they have the same font
   leaverou: overlapping letters are more important, authors do that with
             negative letter-spacing

   florian: how expensive is it? maybe only composit if necessary?
   dbaron: donít know
   fantasai: text-decoration always overlaps text Ö ok maybe not

   dbaron: sort of decision where the group makes a resolution that
           requires impl. to throw out code and start again
   dbaron: needs more consideration that 3 min on a telecon
   dbaron: should research what impl. do
   <SteveZ> +1 for David's point
   dbaron: if we have interop on one thing and add "should" on something
           else, are we ever gonna get it?
   dbaron: If there's a should, then it encourages implementations to work
           towards that. If we already have interop on the opposite, then
           it encourages *less* interop.
   Rossen: Anyone have a quick test case?
   krit: need images from different browsers
   SteveZ: how soon do we need an answer?
   SteveZ: leave it undefined at the moment, and come back later
   SteveZ: what does Illustrator do?
   krit: have to check
   SteveZ: need testing before deciding anything

   <leaverou> very quick testcase I just made: http://dabblet.com/gist/5920266
   <dbaron> leaverou, you should also try (a) mixed LTR and RTL text within
            the same element and (b) an element boundary with a color change
            (c) an element boundary without a color change
   <leaverou> yes dbaron, it was a one minute thing :)
   <krit> SteveZ, you can just specify shadow on the text group in illustrator

   plinss: do we want to go to CR or wait on this?
   SteveZ: can we add "should" and mark it at-risk?
   florian: typically not at-risk for changing our minds, rather for lack
            of impl
   florian: if we put the should, it encourages ppl to follow it. If we
            have interop, itís bad to break it
   SteveZ: can we get research by next week?
   leaverou: looks like every browser overlaps ???
   florian: old Opera makes the overlapped letters darker
   dbaron: Gecko on Linux does not overlap
   dbaron: might depend on platform-specific text rendering
   florian: Presto doing it wrong, but not relevant anymore

Scribe: fantasai
   plinss: path forward?
   plinss: leave it undefined?
   smfr: think we have to leave it undefined
   fantasai: works for me
   rossen: it's ok
   plinss: ok, undefined in L3
   RESOLVED: undefined in L3 whether text and decorations are composited
             before shadowing or not

   <dbaron> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013#issue-6
   <koji> http://lists.w3.org/Archives/Public/www-style/2013May/0139.html
   fantasai: dbaron raised an issue on whether alphabetic is needed for
             text-underline-position. I don't know, so have no oinion.
   dbaron: who thinks it is necessary?
   szilles: my response is, what are we objecting to in alphabetic?
   dbaron: Wasn't clear to me how to implement this stuff
   dbaron: or which value matched existing implementations
   dbaron: also there's issues with using font metrics for underlining
   dbaron: if you use the underlining metrics from the font, which value
           of text-underline-position is it?
   dbaron: if you have a CJK font, which underline are you using?
   szilles: CJK fonts usually have two sets of metrics
   szilles: You can choose the dominant baseline in a table based
   fantasai: I thought fonts had various baselines, but only one underline
             position metric
   szilles: you may be right. I think in CJK fonts, underlines are lower
            than alphabetic, because CJK characters descend lower than
            alphabetic baseline

   szilles: feedback from Adobe Typography was, use the font baseline if
            it's there.
   dbaron: So question then is, which value in CSS spec corresponds to use
           the font metrics?
   dbaron: My problem with this spec is, it's hard for me to understand
           how to implement
   szilles: I understand. Happy to work with fantasai to fix that.
   koji: spec says alphabetic is based on font emtrics

   fantasai: [describes original intention of values, which had nothing to do
              with whether to use font metrics]
   fantasai: intention of alphabetic was "put the line near the alphabetic
             baseline"; intention of "under" was "put the line under the text"
   fantasai: If you're ignoring font metrics, spec is very simple to implement.
   fantasai: If you're using font metrics, then have problem that fonts aren't
             clear on what their metrics represent
   fantasai: Because some fonts think the underline metric represents the
             alphabetic position, and others think it represents the
             accounting position.

   fantasai: Webkit, for example, doesn't use font metrics. Just picks a
             position below the alphabetic line.
   szilles: bad typography
   szilles: [... some issue of font metrics ...]
   szilles: So dbaron's point was, how do I implement what's there?
   dbaron: Part of reason to drop alphabetic is that there's nothing left
           in spec that's unclear.
   szilles: But doesn't auto ask for alphabetic position?
   szilles: I'm not attached to alphabetic value, want auto to do something
   dbaron: auto is vague enough that we can just keep our current implementation

   florian: Is it bad to disallow looking at font metrics for non-auto values?
   szilles: Yes, that is bad.
   dbaron: also, what is the use case for alphabetic?
   szilles: seems to be same as auto
   dbaron: for the cases where you would want it, at least
   szilles: So, you're reasonably happy with current definition of auto
   szilles: ...

   dbaron: alphabetic is same thing as auto in cases where you want it,
           but also unclear how to use font metrics
   fantasai: Current spec has blanket statement for using font metrics
             wherever appropriate
   szilles: Can we come up with a definition of appropriate?
   fantasai: Don't really want to do that...
   fantasai: "appropriate" allows, e.g. blacklisting metrics of bad fonts,
             which Gecko does currently
             (don't want to e.g. try to spec the backlist)
   fantasai: Maybe drop alphabetic, and tackle that in L4 if someone wants
             to define it for OpenType.

   plinss: What does it mean for vertical text
   fantasai: vertical text has an alphabetic baseline; should be defined
             in writing modes (if not, bug in writing modes)
   fantasai: text decoration spec is in terms of over/under (relative)
             directions, so no issue here
   szilles: should auto do the right thing in vertical text?
   fantasai: Interesting question. If you have sideways Latin in vertical
             orientation, want the underline to look just like in horiziontal
   fantasai: but if typeset upright, want to shift it over
   fantasai: similar problem to CJK in horizontal, want to make sure it
             shifts down enough
   fantasai: so maybe add examples to the spec showing things UA needs to

   plinss: So, do we want to drop alphabetic?
   fantasai: think so
   szilles: now that I understand dbaron's issues, makes sense to me
   RESOLVED: Drop alphabetic

   plinss: Move to CR?
   fantasai: Have to make edits, but that does close all the issues
   fantasai: Will probably take a month and a half to schedule CR telecon,
             so can go ahead with that and have edits done by then. :)
   szilles: My understanding of our decisions today was, take conservative
            approach, don't define anything new
   fantasai: Yep, so no need for another LC
   RESOLVED: Take CSS3 Text Decoration to CR
Received on Wednesday, 3 July 2013 21:08:36 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:29 UTC