W3C home > Mailing lists > Public > www-style@w3.org > December 2012

Re: [CSSWG] Minutes Telecon 2012-12-07

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 07 Dec 2012 14:58:40 -0800
Message-ID: <50C274A0.6030803@inkedblade.net>
To: www-style@w3.org
On 12/07/2012 02:24 PM, fantasai wrote:
> Summary:
>    - discussed February F2F logistics
>    - objection to publishing CSS3 Text LC before next F2F
>    - RESOLVED: Publish CSS3 Fonts WD
>    - RESOLVED: No exceptional zeroing of negative margins for flex items.
>    - RESOLVED: Min/max clamping step of resolving flexible lengths does
>                not pass cross-size limits through aspect ratio into main
>                size flex computations.
>    - Various Flexbox clarifications reviewed:
>        http://dvcs.w3.org/hg/csswg/diff/2dfe9b0d813f/css3-flexbox/Overview.src.html
>        http://dvcs.w3.org/hg/csswg/diff/c963d3ec23b8/css3-flexbox/Overview.src.html
>        http://dvcs.w3.org/hg/csswg/diff/9d29cc6d8a95/css3-flexbox/Overview.src.html
>    - Issue on handling aspect ratio during main size computations still
>      being worked out:
>        http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
>        http://dvcs.w3.org/hg/csswg/diff/284a967553ae/css3-flexbox/Overview.src.html
>    - Discussed case-sensitivity of CSS identifiers. i18n recommends
>      case-folding. Anne recommends ascii-folding.
>      Points brought up:
>        - Some implementations seem to do some form of Unicode case-insensitivity
>          for class name matching. Some do ASCII-only.
>        - HTML spec requires ASCII-folding only for its case-insensitivity
>        - ASCII-folding is easier to implement correctly
>        - ASCII-folding is really weird for non-English languages with case
>          Previous uses of case-insensitivity were ASCII-only idents,
>          where this wasn't a usability issue.
>      No conclusions yet.

Forgot the actual minutes.

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

   Glenn Adams
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Arron Eicholz
   Elika Etemad
   Daniel Glazman
   Molly Holzschlag
   Koji Ishii
   Brad Kemper
   Peter Linss
   Alexis Menard
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2012/12/05-css-irc
* antonp will have to drop off the call after the flexbox discussion
Scribe: Leif

Administrative / F2F

   glazou: extra items?
   glazou: nothing

   glazou: Need report about Tucson from Molly
   molly: Request last meeting was to shift it a day.
   molly: Didn't work out too well.
   molly: Feb being a big month, the best option is (as a suggestion)
          to move one week forward, to 11th
   molly: can have it downtown at the Marriott, walkable to campus and bars
   molly: for those that stay an extra day, can go to biosphere etc.
   glazou: problem: w3c workshop about ebooks in NYC from 11-13th
   florian: shifting it 1 day was preference, but no-one completely
            against keeping
   molly: The block I had for Marriott is not available anymore, but still
           have the Biosphere
   <dbaron> Earlier this week, I created a problem for myself that week
            (the following week) because we'd said last week that we
            were committed to the week we'd chosen.
   molly: Big q is whether people … Daniel, you're the only one with a
   glazou: Alan will probably also attend
   dbaron: I got a jury duty postponed to that week
   molly: Don't have to do it, only if we want that model
   molly: General feeling is not to move right now, stick to dates
   molly: partly biosphere, part downtown, 4-7 Feb
   molly: or any combination
   molly: not going to do anything about moving to next week
   molly: We may have to be in separate hotels
   molly: Housing is only problem
   molly: Resolve to keep dates? Part of problem was adding Thurs, that's
          when they start running out of rooms
   molly: checking out 7th is ok
   glazou: that's enough
   molly: someone wanted to move it forward
   SimonSapin: ok for me
   molly: PLEASE use wiki planning page, put your name in there
   molly: in notes section, put special needs, spouse, children etc.
   molly: once I get this all done, have to start working on catering
   molly: Next week I'll come back with hotel to begin reserving
   glazou, molly: thanks

   <krit> I want to mention that next monday (12/10) is a FXTF call.
          Agenda and times posted on the public-fx mailing list.

CSS3 Text

   glazou: jdaggett objected to LC, we thought merited time conf time
   jdaggett: bunch of issues I posted
   jdaggett: some have solutions, some just require a bit more head-scratching
   jdaggett: figure out what is needed now
   jdaggett: text-justify: what it is and why it's needed. is it the best
             way to accomplish this?
   jdaggett: It's a bit underdefined
   jdaggett: In San Diego I said we need use cases
   jdaggett: an example was added, but doesn't expalin UC.
   jdaggett: Set a string in multiple scripts, but doesn't show you why
   florian: Wouldn't put it that way, but I share some concern.
   florian: when introduced, it was overly specific
   florian: good for justification
   florian: Gives implementors flexibility, but so flexible that it is
            somewhat meaningless
   florian: can conform without making sense
   jdaggett: A number of specific issues were filed not just -justify
   jdaggett: until we go through those [noise]
   jdaggett: posted to the list
   jdaggett: filed in tracker
   jdaggett: linked from spec
   glazou: So we have quite a strong objection
   florian: I don't object as strongly, but I agree with the concerns
   glazou: So we need to solve these issues before going to LC
   jdaggett: I'm not sure these issues are so high prio that we need to
             push through on calls before the next F2F
   jdaggett: better to do it then
   glazou: letter-spacing does not need conf call time?
   jdaggett: That's an issue that is easier to resolve, so could talk about it
   jdaggett: or later
   glazou: later
   glazou: more time for flexbox

   fantasai: What about text-decoration?
   fantasai: It's in a separate spec; does that go to LC?
   glazou: I think fantasai is asking whether you also object to that
   jdaggett: Not looked at it, not on agenda
   ACTION jdaggett look at text-decoration spec and object or agree to LC
   <trackbot> Created ACTION-526

Publish WD CSS3 Fonts

   <jdaggett> http://dev.w3.org/csswg/css3-fonts/#recent-changes
   jdaggett: number of significant changes
   jdaggett: FontLoader events
   jdaggett: changes to syntax of @font-feature-values
   jdaggett: to OM
   jdaggett: and a few others
   jdaggett: I think FontLoader object will go through changes as people comment
   jdaggett: Need to make sure it's completely accurate, but it's been reviewed by a number of people. We can publish
   glazou: Prev. WD from end of Aug
   glazou: No objections.
   <glenn> sounds good
   RESOLVED: Publish WD CSS3 Fonts

CSS Flexbox issues

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012OctDec/0251.html

       There have been several issues filed against Flexbox since the CR.
       We wanted to make sure everyone gets a chance to review them and
       make sure the changes are correct. (And then of course we'll need
       to publish an update.)
       The changes are summarized in:
       The relevant diffs are:
       The last change is the trickiest one, and we'd really like Rossen and
       Alex Mogilevsky to review it. The thread begins at
       We also rejected two change requests:
           See http://lists.w3.org/Archives/Public/www-style/2012Nov/0462.html
           See http://lists.w3.org/Archives/Public/www-style/2012Dec/0041.html
       and would like the CSSWG to review and, if everyone agrees, ratify that.

   glazou: Many of the confidential messages you sent deserve to be public

   fantasai summarizes
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Nov/0460.html
   fantasai: 1. special case negative margins and clamp them to zero
   fantasai: could be nonsensical, but Tab and I want to just let them do it
   fantasai: maybe author wanted something weird
   fantasai: we propose not changing it
   florian: Wouldn't happen by accident, might as well give them that.
   RESOLVED: No change.

   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Nov/0010.html
   fantasai: 2. Should an image a max-height constraint affect the max-width
             constraint when there's an aspect ratio
   fantasai: we say no
   fantasai: specifying the flex is kind of like specifying the width
   Rossen: That makes sense.
   SteveZ: In other places we try to preserve aspect ratio.
   fantasai: We consider the aspect ratio when calculating the hypothetical
             size earlier (see last issue), just not here.
   SteveZ: And I suspect that's the best you can do in this circumstance
   SteveZ: even without flexbox if I set a width I can destroy aspect ratio.
   SteveZ: Seems strange to consider flexing a fixed width
   fantasai: Not a fixed width, but flex: 1 is kind of like 100%
   fantasai: if that's the only thing in the box.
   * glenn thinks that if AR is specified, then should take priority
   RESOLVED: No change.

   fantasai: The changes, 3 are minor, the last still being discussed on
             mailing list

   <fantasai> http://dvcs.w3.org/hg/csswg/diff/2dfe9b0d813f/css3-flexbox/Overview.src.html
   fantasai: First minor one: When deciding whether to use stretch
   fantasai: you check the cross-size property, only stretch if auto
   fantasai: What happens if it's specified as a percentage and can't be
             resolved, and is therefore *treated* as auto?
   fantasai: We clarified that you check the computed cross-size prop,
             which means you get auto behavior and no stretching
   fantasai: We're open to doing things different, but this was the
             simplest thing to define, to just check the computed size
   glazou: move on?

   <fantasai> http://dvcs.w3.org/hg/csswg/diff/c963d3ec23b8/css3-flexbox/Overview.src.html
   fantasai: Fixed an error; just needs review from people who care.

   <fantasai> http://dvcs.w3.org/hg/csswg/diff/9d29cc6d8a95/css3-flexbox/Overview.src.html
   fantasai: Float property is ignored for flex layout, but can affect
             computed display.
   fantasai: Clarified that it still takes effect and can influence
             what becomes a flex item.

   fantasai: Last issue
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
   <fantasai> http://dvcs.w3.org/hg/csswg/diff/284a967553ae/css3-flexbox/Overview.src.html
   fantasai: Would like Rossen and Alex Mogilevksy to review
   fantasai: Does it match IE, or different and better
   fantasai: Some discussion on list about the change; need to make sure
             we address Kenny's comments.
   Rossen: We will review, maybe today
   fantasai: Aim to close this next week.

Case-sensitivity of CSS Identifiers

   ?: Is Tab on the call?
   glazou: No, in Hawaii, poor him
   glazou: So what do we do?
   florian: Please remind me of conclusion of last discussion
   florian: which options did we eliminate?
   plinss: At TPAC we deferred to i18n
   plinss: they came back and said to do case folding
   florian: Main arg. for not doing that is that in other places, like HTML,
            they do ASCII case insensitivity.
   jdaggett: They said to do full case-insensitivity
   florian: Hard to do
   florian: Nothing says which language a stylesheet is in
   fantasai: Unicode has a set of default rules to use when you don't know
             the language. We already use these for text-transform when the
             language is unknown.
   Bert: Which of the two case-folding algorithms from Unicode did i18n recomend?
   Bert: The simple one is better than full
   florian: Other than language sensitivity, what is the difference?
   fantasai: I have to look into that to be sure, but
   fantasai: IIRC, there are two sets: one that preserves the length of the
             string, one that doesn't
   Bert: the German sharp s
   Bert: wouldn't be folded in the simple algo.
   florian: No particular reason for us to care about string length changing.
   fantasai: Agreed
   fantasai: Two axes: constant string length or language sensitivity
   fantasai: def. don't want to be language sensitive
   florian: Don't know the implications, but from conceptual standpoint,
            makes sense
   jdaggett: The big problem is that you're making a distinction for …
   ( identifiers, i18n mailing list … )

   florian: Slowly moving towards full unicode
   jdaggett: I don't see that happening
   SteveZ: HTML is pretty solidly set on not doing that
   dbaron: Defined lots of things as ASCII case sensitive, mostly when
           comparing to things that are ASCII

   glazou: More to say? we haven't solved it
   florian: Should determine what's standing between us and conclusion
   <tantek> are there URLs to specific alternatives being considered?
   plinss: Not hearing strong arguments against doing Unicode case folding

   <jdaggett> annevk had a pretty strong argument on the i18n list
   <dbaron> http://www.w3.org/mid/CADnb78gbNqHBtnxqhukZnZFO8Z4bjJJC2mC3JdVW7WqT6D7aLQ@mail.gmail.com
   <glazou> http://lists.w3.org/Archives/Public/www-international/2012OctDec/0109.html
   jdaggett: That one?
   glazou: yeah that one
   <jdaggett> yes
   fantasai: What is case insensitive in HTML?
   <glenn> @name/@id comparison?
   krit: tags and attributes
   florian: is the pasted mail the only argument? Not particularly strong
   fantasai: Traditionally, you can't make up your own tags or attributes;
             they're all ascii
   <Ms2ger> getElementsByClassName in quirks mode
   <tantek> disagreed, I think Anne's position of "look at the platform
            holistically" is the right position.
   florian: Unless particular problems, support full Unicode
   glazou: dbaron, you pointed out anne's answer, but what about you?
   * tantek agrees with Annevk's answer.
   dbaron: Agree, but probably not as strongly
   florian: Anne's point is weakened by what fantasai just said
   florian: when mostly talking about ascii things, difference is not great.
   florian: Now that we are considering that, we shouldn't feel constrained

   * Ms2ger wonders what the TAG would say
   <tantek> Ms2ger - this might be a good case where it makes sense to be
            consistent with HTML first, and then raise it to TAG to look
            at from a "platform holistically" perspective.

   krit: XML-based languages are case sensitive
   krit: CSS is used for those as well
   <Bert> (In HTML I think all tokens defined by HTML are case-insensitive
           except for entity names.)
   krit: Not sure it actually matters for us
   plinss: only matter for elements and selectors
   plinss: this is only about identifiers, user identifiers specifically
   florian: Consistency is already broken
   <tantek> more important to be consistent with HTML than XML
   SteveZ: Don't need to make it worse
   florian: But might win something on another front
   <tantek> "on another front" sounds hypothetical, and thus discardable
   SteveZ: No strong opinions, but anne's solution more likely to be
   SteveZ: Trying to track bugs for edge cases is bigger pain than the
           value of being insensitive, and interop would suffer
   <tantek> excellent summary SteveZ

   glazou: Full unicode solves only edge cases?
   <jdaggett> yes, exactly what daniel just said...
   SteveZ: … [missed]
   florian: For French, full case insensitivity doesn't help.
   Florian: ... people tend not to type uppercase accented characters with
            French keyboards
   glazou: If we don't implement case insensitivity, what does it mean for
           the architecture of the Web?
   glazou: will we be inconsistent?
   <glenn> this looks like a good subject for a TAG finding
   fantasai: We'll be consistent, and non-ASCII langs can't use case
   florian: Practical for French, but not eg. Norwegian
   fantasai: Leif's name would be fully insensitive, Håkon's would be
             excerpt the å
   florian: Nobody can type the upper case in French keyboards
   fantasai: I don't have trouble?
   florian: Not É on regular keyboard
   glazou: only Windows keyboards!
   florian: Huge number of people don't know how to type it
   <tantek> rathole?
   fantasai: Weird thing, but not relevant
   florian: only a theoretical problem
   florian: but if it's common enough, we're not buying anything

   plinss: back to www-international, a test case shows IE, Opera Chrome
           being interop on Unicode case-insensitive comparison of class
   plinss: Argument that we don't do it isn't valid, it is done
   dbaron: version of Firefox?
   <plinss> http://lists.w3.org/Archives/Public/www-international/2012OctDec/0110.html
   dbaron: We changed it to ASCII case-insensitive recently
   <plinss> http://www.inter-locale.com/test/css-case-sensitive-test.html
   <Ms2ger> "A quick survey of browsers on my desktop computer using the
             following page shows that IE9, Opera, Safari, and Chrome are
             already non-ASCII case-insensitive (only FF seems to be
             ASCII-only case-insensitive):"
   dbaron: Oh, he said only Firefox
   plinss: Given those results, I don't think Anne's point holds a lot of water

   <SimonSapin> relevant HTML5 spec:
   <SimonSapin> "Classes from the class attribute of HTML elements in
                documents that are in quirks mode must be treated as ASCII
                case-insensitive for the purposes of selector matching."
   <SimonSapin> "Everything else (attribute values on HTML elements,
                IDs and classes in no-quirks mode and limited-quirks mode,
                and element names, attribute names, and attribute values
                in XML documents) must be treated as case-sensitive for
                the purposes of selector matching."
   <glenn> historical reference for interest:

   dbaron: Talking of other parts of the platform
   plinss: Here you have CSS and HTML
   plinss: pretty good part of the platform!
   dbaron: What is this testing?
   glazou: Class names
   dbaron: Testing exactly one thing
   florian: If we don't actually have consistency, we don't actually have
            something to be consistent with
   dbaron: Well, what's the right thing?
   florian: i18n said full unicode
   glazou: Old browsers do what majority of browsers do
   glazou: spec is what browsers do
   glazou: IE, Opera, Chrome already do the same thing
   florian: Not user-defined identifiers
   florian: take a poll?

   <Bert> q+ to ask: Mac and Windows have case-insensitive file systems,
          what algo do they use?
   Bert: Most ppl are used to Windows, what do they do?
   florian: in what context?
   Bert: File names
   Bert: UNIX doesn't do case folding, Mac and Windows do
   florian: Most people don't type names
   florian: they click
   florian: A bunch of places to do case folding. Looking for consistency
            in web platform, makes sense, not further.

   glazou: Not sure poll is useful
   glazou: More discussion is needed.
   florian: We've been talking about it for a while without many new points
   florian: Do we know why we're postponing?
   plinss: We've asked i18n, and they gave an answer, and we have a test
           that shows consistency
   dbaron: but only testing one thing
   plinss: Shows consistency between html and css
   dbaron: "Consistency across the platform" should mean more than just
           one thing
   <tantek> could the advocates of each position update their documentation
            of their positions with the new data, and then provide the URLs
            to the documentation of their positions?
   <tantek> I'm skeptical about a last minute test being shown and being
            asked to immediately accept it.
   glazou: Can we write more tests, or ping i18n group?
   glazou: if majority do one thing, let's make a decision.
   glazou: I will ping i18n group and ask for more tests
   glazou: then revisit issue
   fantasai: Want dbaron to list things to test
   dbaron: yes, but not off top of head
   ACTION dbaron List types of tests needed for case insensitivity
   <trackbot> Created ACTION-527
   ACTION glazou Contact i18n
   <trackbot> Created ACTION-528

   SimonSapin: Tests that we linked are in quirks mode
   SimonSapin: standards mode might be different.
   fantasai: Class names are matched case sensitively in standards mode
   fantasai: need to use quirks mode for this test
   florian: My impression is that tests are worth doing, but we don't have
   glazou: Let's see.

Text Decoration

   jdaggett: text decoration spec has two issues listed in spec
   <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10
   jdaggett: a set of issues listed in the tracker under CSS3 Text that
             are actually about decoration
   jdaggett: only a placeholder in spec
   jdaggett: Needs resolving
   * scribe can't hear
   jdaggett: There's no introduction
   fantasai: Yes, needs intro
   fantasai: First issue is CSS Color errata not published yet; not an issue
             with this spec
   fantasai: Second is a reminder to add an example.
   jdaggett: also issues in tracker
   <fantasai> None of the issues in tracker are against text-decoration

Conf Calls

   glazou: Last and first are 26 Dec and 2 January
   glazou: Let's see if people are around, cancel if necessary

<fantasai> jdaggett: There are no substantial issues against text-decoration
<fantasai> jdaggett: Unless you have some you haven't raised
Received on Friday, 7 December 2012 22:59:12 UTC

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