- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 07 Dec 2012 14:58:40 -0800
- 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 ======
Present:
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
conflict?
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
+SteveZ
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
+arronei
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:
http://dev.w3.org/csswg/css3-flexbox/#changes
The relevant diffs are:
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
http://dvcs.w3.org/hg/csswg/diff/284a967553ae/css3-flexbox/Overview.src.html
The last change is the trickiest one, and we'd really like Rossen and
Alex Mogilevsky to review it. The thread begins at
http://lists.w3.org/Archives/Public/www-style/2012Oct/0781.html
We also rejected two change requests:
http://lists.w3.org/Archives/Public/www-style/2012Nov/0460.html
See http://lists.w3.org/Archives/Public/www-style/2012Nov/0462.html
http://lists.w3.org/Archives/Public/www-style/2012Nov/0010.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
interoperable
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
insensitivity.
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
idents
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:
http://www.w3.org/TR/html5/links.html#case-sensitivity
<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:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-5353782642
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
consistency
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