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

[CSSWG] Minutes Telecon 2013-06-26

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 03 Jul 2013 01:28:04 -0700
Message-ID: <51D3E094.1010501@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: em is computed font-size; ex, ch measure actual value font metrics
   - RESOLVED: Publish Fonts LC after solving @font-feature-values OM dependency
               on as-yet-unspecced WebIDL features
   - Discussed turning text-align into shorthand including text-align-last;
     Rossen to collect data on existing usage.
   - Discussed having letter-spacing: <length> not disable inter-letter justification

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

   Rossen Atanassov
   Tab Atkins
   Shezan Baig
   David Baron
   John Daggett
   Tantek «elik
   Justin Erenkrantz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   Koji Ishii
   Dael Jackson
   Brian Kardell
   Brad Kemper
   Philippe Le Hťgaret
   Peter Linss
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Nick Van den Bleeken
   Steve Zilles

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jun/0606.html
<RRSAgent> http://www.w3.org/2013/06/26-css-irc
Scribe: SimonSapin


   glazou: extra items?
   <dbaron> May be worth mentioning that TPAC registration is open:

Fonts LC

   jdaggett: had lots of comments
   jdaggett: 2 issues
   jdaggett: OM of @font-feature-values, waiting on a new piece of WebIDL
   jdaggett: as is Varibales
   jdaggett: Second issue: font-size-adjust vs. em/ex/ch units
   jdaggett: ask for LC next tuesday, resolve issues during LC period

   fantasai: would like to resolve unit issue now
   glazou: are you ok for LC if we do that?
   fantasai: yes
   glazou: other opinions?
   glazou: being heavy user of the OM Iím worried about that issue
   glazou: LC means almost finished, dealing with issue after LC is weird
   glazou: but donít want to block
   jdaggett: relies on MapÖ struct, not defined yet in WebIDL
   TabAtkins: heycam promised it this week
   glazou: within a week we should resolve issues?
   jdaggett: yes
   glazou: Then I withdraw my concern
   glazou: Other opinions?
   RESOLVED: Fonts LC after resolving the 2 issues

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013May/0517.html
   fantasai: issue in computing ch/em/ex unit with font-size-adjust
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0590.html
   fantasai: proposal is: ex/ch computed against the used font size, with metrics
   fantasai: accounting for font-size-adjust and other things/substitutions
   fantasai: we really want to match the glyphs; need font data anyway, might
             as well account for everything we can
   fantasai: em could go either way, either use the used size like ex, or
             just use the computed font-size
   fantasai: computed might not be a probles, some fonts go outside of the
             used em-box anyway
   dbaron: would prefer to stick with what 2.1 says: em is computed font-size

   TabAtkins: Ö used-value time units Ö ?
   dbaron: you need font data for ex
   dbaron: want to respond to downloadable font, but keep the units
   dbaron: The computed value just changes when the font loads.
   * Rossen agrees with dbaron
   florian: could you clarify why?
   dbaron: complicating the space of computed value is a huge complexity
   dbaron: changing all properties with length units
   dbaron: lot of implementation work
   * tantek agrees regarding the complexity problem that dbaron mentioned.
   TabAtkins: happy with this if you are
   SimonSapin: we already rejected making vh/vw used-value-time for the same
   fantasai: not quite the same reasons
   TabAtkins: viewport units decision was clearer because of dependency on
   TabAtkins: depending on downloaded resources is a greyer area

   fantasai: summary: 2 points to resolve on
   fantasai: 1. em units remain = to computed font-size
   <SimonSapin> I agree
   <bkardell> I agree
   fantasai: 2. ex/ch units relative to the metrics of the 1st available font
   <SteveZ> +1
   fantasai: used value of that metric
   jdaggett: requires update to css-values
   fantasai: yes, will do
   SimonSapin: ML comment: ex has no character for input to font matching algo
   jdaggett: thatís in css-fonts now, css-values only need to use that
   glazou: do we all agree of the two parts? objections?
   RESOLVED: adopt fantasaiís proposal

   glazou: provided the other issue is resolved, Fonts go to LC
   jdaggett: defer the ... issue to next week

CSS3 Text

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0263.html
   fantasai: interaction of text-align and text-align-last
   fantasai: 1 rule to justify the last line, other rule to center all
   fantasai: [explains as in the email]
   * glazou agrees 100% with fantasai 's suggestion
   fantasai: people expect text-align-list to be a longhand of text-align,
             itís not
   fantasai: making it a shorthand can break existing content if the shorthand
             is set just after
   fantasai: so, backward-compat concern, since text-align-last shipped in IE6
   Rossen: want to know the syntax to run queries against db of existing content
   Rossen: expect usage to not be none, but will check
   glazou: only engine shipping it?
   fantasai: Mozilla too, very recently
   fantasai: It's only a back-compat problem in one particular order

   SteveZ: concern with Chinise/Japanese typically use text-align-last: justify
   SteveZ: having it apply only with 'justify' makes sense when you turn
           it off and specify 'center' afterwards
   SteveZ: much more frequent than you might think
   fantasai: proposal to add a justify-all value to make this easy
   SteveZ: people on this call are not the ones actually using it
   stearns: use case to set text-align-last justify when text-align is not
   fantasai: not sure
   SteveZ: chinese typically all
   stearns: IE solution to have it only apply when text-align is justify
            makes sense
   stearns: Donít the complexity of this proposal if we standardize on IEís behavior
   glazou: two proposals here, what do people think?
   Rossen: when would you use it? other than text-align: justify
   florian: sounds at least unusual
   stearns: use case unusual, not sure properties are really separate
   stearns: letter-spacing eg. changes justification
   stearns: this wouldnít be the only case of depending on another property
            having another value
   * fantasai occasionally writes with start alignment, but end-aligns the last line
   * fantasai on whiteboards and things
   * glazou yes but fantasai is the human counter-example we needed in the csswg ;-)

   Rossen: prefer backwards compat
   Rossen: if we were starting fresh then we should have just one property
           with an optional value for "last line"
   Rossen: so what are we doing with this property?
   glazou: depencencies between properties are weird, but backward compat
           is valuable too
   Rossen: But, we have two shipping implementations that use two properties
   Rossen: weíre certainly gonna keep supporting what we have
   Rossen: the property is not new
   Rossen: it would have been better to specify this as a value, but itís
           been out for years
   <BradK> I like 'text-align: justify all' that would override
           'text-align-last: <whatever>'.

   glazou: decide that we are waiting for your numbers?
   glazou: if there is little usage, there is an impact
   SteveZ: how do you define "little"? relative to language, Ö
   Rossen: also, what kind of data to mine
   Rossen: gonna do it against web content, but expect more usage in Word
           docs converted to HTML
   koji: As far as I tested Word 2010, it export to HTML doesn't use this property
   koji:  it uses other MS extensions
   <fantasai> It uses 'text-justify: distribute-all-lines'
   fantasai: which is not in any spec of ours
   Rossen: yeah, we have this one
   <koji> Word 2013 uses "text-align:justify;text-justify:distribute-all-lines"

   glazou: what do we do?
   florian: if triggered by text-align: justify, donít we have what we want?
   glazou: donít know what to do, itís up to implementers
   dbaron: people worried about compat should check
   Rossen: Word docs are harder to mine
   SteveZ: Word does not use this
   Rossen: 2013 yes, previous versions unknown
   <bkardell> is it plausible that corp IT environments that standardized
              on IE way back might have this?  You wouldnt be able to mine
              that either, right?
   Rossen: by next week will have data
   glazou: defer resolution to next week?
   Rossen: ok with that
   Rossen: we are not gonna back out this property

   glazou: this data only breaking if translating to HTML?
   Rossen: with Sharepoint presenting everything as HTML, itís not that rare
   fantasai: issue only if the order is text-align-last then text-align
   fantasai: If Word is emitting text-align first, then there is no problem
   glazou: letís wait for the data, revisit next week

   Topic: Allowing 'letter-spacing: <length>' to justify
   <glazou> http://lists.w3.org/Archives/Public/www-style/2013May/0280.html
   fantasai: current rules prevent justification when letter-spacing is not
   fantasai: avoid this we allow justification for length, and have normal
             compute to 0
   jdaggett asks clarification
   fantasai: no letter-spacing value would constrain justification
   jdaggett: justification should just be additional spacing, not proportional
   jdaggett: only apply to text-justify: distribute, right?
   fantasai: also 'auto', in CJK text
   <stearns> +1 to fantasai's solution

   glazou: comments?
   <liam> [I can't call in because of noise here but note that letterspacing
           should not normally be used for justification in non-newspaper
           texts even in English (and obviously never for German)]
   <SimonSapin> liam, so there should be a way to prevent letter spacing
                as justification?
   <liam> the default should be, do not use letter spacing for justification
   <liam> it considerably reduces comprehension when letterspacing is uneven
   <fantasai> liam, the default is already to allow letter-spacing for justification
   <liam> then that's broken, but at the very least there needs to be a way
          to disable it
   SteveZ: if I set letter-spacing:0 I do not get letter spacing for justify
   fantasai: currently yes, but there are documents that require otherwise
   fantasai: letter-spacing: 0 currently does not allow justification per spec,
             but implementations don't follow
   stearns: proposal: set "0 fixed" to disable justification
   SteveZ: just a question of existing impl or deeper?
   fantasai: both

   <BradK> Would letter-spacing be a minimal value for justification?
   <stearns> BradK: yes, it would set a minimum, but could be increased by justification
   * krit What happened to the Text TF ?
   <BradK> Alan, that seems reasonable.

   fantasai: we donít have a way to ???
   fantasai: current rules prevent justification if you also have tracking
   fantasai: this would allow tracking and also allow justification
   fantasai: which the current spec does not allow
   fantasai: more consistent with word-spacing
   fantasai: solving problems + gain consistency
   fantasai: losing ability to disable justification in letter spacing,
             but could add a keyword for that

   SteveZ: bothered by letter-spacing applying to CJK
   fantasai: why?
   SteveZ: because CJK are different from letters, hiragana makes it messy
   fantasai: we donít want a separate property for each script
   SteveZ: part of the problem is making it work in a situation where
           letter spacing was not intended to work
   fantasai: not sure this makes sense
   fantasai: some want to distribute space
   fantasai: in other cases they donít

   <bkardell> maybe we can punt this back to the list until next week and
              move on with other items?
   * fantasai it's been on the list for a long time, nobody has commented
   * liam has been meaning to follow up on the list, sorry

   SteveZ: concern: making letter-spacing work for CJK will have bad
           side-effects where itís unexpected
   fantasai: it has always worked
   fantasai: issue is whether using letter-spacing prop disables justification
   SteveZ: latin users would expect to disable justification
   SteveZ: thatís why mixing them is a problem
   * liam agrees Japanese (and probably C & K) very different from Latin script
          for letter spacing. Letter spacing disabled should not disable
          justification in latin scripts but obviously should for cjk

   TabAtkins: given that word-spacing does not disable justification,
              donít understand why you expect that
   SteveZ: letter-spacing is much less frequently used
   SteveZ: precise adjustments, donít want justification in that context
   fantasai: would like to solve the problem we have here, and add control
             for disabling justification or not later
   SteveZ: users that expect justification disabled are surprised
   fantasai: implementations donít do justification between latin letters

   <liam> [sample use case, long legal contract all in caps/small-caps with
   <tantek> re: use-cases for suppressing letter-spacing and/or justification
   <BradK> If people don't want justification with their letter-spacing,
           they can just use text-align to turn off justification
   fantasai: we don't have content that sets letter-spacing: 0; to turn off
             justification between Latin letters because implementations don't
             justify between Latin letters currently.
   fantasai: but we do have content that specifies letter-spacing:0 and
             expects CJK text to justify
   glazou: defer to email
   fantasai: are people gonna participate? been open on the list for a long time
   <tantek> sounds like some actions
   SteveZ: yes, will discuss on email

Meeting closed.
Received on Wednesday, 3 July 2013 08:28:32 UTC

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