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

[CSSWG] Minutes Telecon 2013-08-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 15 Aug 2013 13:42:12 -0700
Message-ID: <520D3D24.5060101@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - CSSWG TPAC attendees should add to
       http://wiki.csswg.org/planning/tpac-2013
     Still investigating whether we'll meet on Sunday.
   - RESOLVED: CSS escapes for surrogates produce u+fffd instead.
   - RESOLVED: Switch Syntax to using the term "codepoint" instead of "character".
   - RESOLVED: Publish CSS Syntax L3 to replace /TR/css3-syntax
   - RESOLVED: Add a dense/sparse keyword to grid-auto-flow, defaulting to sparse.
   - Discussed starting informal Grid Layout task force calls
   - Discussed interaction of text-align and text-align-last, aligning on
     a shorthand-longhand relationship, details to be worked out on-list
     so that we can extend with first-line controls in the future.
   - RESOLVED: Add Tab as editor to Font Load Events.
   - Discussed how to define canonical serialization order of longhands
     for a shorthand in the propdef tables.

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


Present:
   Rossen Atanassov
   Tab Atkins
   Shezan Baig
   David Baron
   Bert Bos
   Elika Etemad
   Simon Fraser
   John Jansen
   Brad Kemper (via IRC)
   Chris Lilley
   Peter Linss
   Edward O'Connor
   Chris Palmer
   Anton Prowse
   Matt Rakow
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Steve Zilles

Agenda: http://lists.w3.org/Archives/Public/www-style/2013Aug/0198.html
IRC Log: http://www.w3.org/2013/08/14-css-irc
Scribe: Tab Atkins

<SimonSapin> TabAtkins: should we just publish Syntax? The remaining issues seem minor
<TabAtkins> SimonSapin: I'm down with this.
<TabAtkins> Let's see if we can get a resolution today.
<TabAtkins> Or maybe we already did?  Let me go check the f2f minutes.
<SimonSapin> AFAIR we were waiting on dbaron’s feedback, which he gave
<TabAtkins> Oh, and we were waiting for the "CSS Stylesheets" section.

TPAC
----

   plinss: sylvaing wanted to know who was showing up at TPAC.
   plinss: There's a wiki page for this already.
   <plinss> http://wiki.csswg.org/planning/tpac-2013

   fantasai: Are we doing a Sunday meeting day?
   plinss: Not known yet - need to find out if we can get the space.
   fantasai: Are we wanting to?
   Bert: When is the TTWF event? Sat or Sun?
   fantasai: Saturday.
   plinss: Opinions on meeting the extra day?
   florian: It's usually useful.
   Rossen: Should be fine.
   plinss: Okay, I'll see if we can get the room.
   plinss: If the organizers can't find space, is there anyone with resources
           in that area?
   ...
   plinss: I'll take that as a no.

   * florian as a quick note, weekends are not great for regular members,
             but they tend to actually be better than week days for
             invited experts

Counter Styles
--------------

   plinss: LC period is expiring for Counter Styles.  Where we at?
   TabAtkins: I can get up the DoC this week.
   plinss: Any feedback?
   TabAtkins: Not really, just from r12a.

CSS Syntax L3
-------------

   Topic: CSS surrogate
   SimonSapin: When you have a hex CSS escape, we turn that into the
               corresponding codepoint.
   SimonSapin: We currently have a special case for 0 because we want to
               avoid NUL characters, so it's replaced by the replacement
               char.
   SimonSapin: Something else that's problematic is surrogate codepoints,
               which are used for utf-16.
   SimonSapin: These characters are not used outside of utf-16.
   <ChrisL> surrogates are not characters
   <ChrisL> assuming we have a proper definition for characters, like Unicode
            codepoint and not, say, grapheme cluster
   SimonSapin: If you have two escape sequences for surrogates next to
               each other, impls will interpret those as a single codepoint
               (whatever they mean).
   SimonSapin: This is the wrong thing to do.
   ChrisL: Why is that wrong?
   SimonSapin: Because you already have a mechanism for inputting high
               codepoints.
   SimonSapin: The fact that two surrogates produce a character is a feature
               of UTF-16, not unicode.
   SimonSapin: So suggestion is to use replacement char for surrogate escapes
               as well.
   ChrisL: I agree.
   ChrisL: This ties into the other thread, which talks about how "character"
           and "codepoint".
   TabAtkins: Someone from Moz said they'd be okay with making this change,
              and I think we'd be fine on Blink too, so I'm okay with this
              change.
   RESOLVED: CSS escapes for surrogates produce u+fffd instead.
   <ChrisL> ok so this is not really about surrogate escapes. Its about
            'half surrogates'

   SimonSapin: In Syntax, we use the word "character", which isn't precisely
               defined.
   SimonSapin: We mean codepoints.
   SimonSapin: What we could do is use the word "codepoints", and avoid the
               word "character".
   SimonSapin: Or we could define in the beginning that for this spec, the
               word "character" means "codepoints".
   SimonSapin: CSS Text already does something similar, where "character"
               means "grapheme cluster".
   florian: We've had problems with that.  Using "characters" is more elegant,
            but it's less clear.

   ChrisL: The real problem is that CSS Text defines "character" as something
            wrong.
   ChrisL: Gives us problems elsewhere.
   fantasai: It's not wrong. "Character" is ambiguous in English.
   ChrisL: I don't care about English in all its varied uses, I care about
           what technical specs have worked out for "character" to mean.
   ChrisL: And what the unicode consortium has defined for it.
   TabAtkins: I'm fine with just saying "codepoint" everywhere in Syntax.
   dbaron: I think part of the reason CSS Text did what it did was to make
           the spec readable.
   ChrisL: But it doesn't, that's the problem.
   <SimonSapin> Unicode has 4 different definitions of "character"
   <SimonSapin> one of which is "abstract character"

   ChrisL: If you redefine an ambiguous term differently in multiple specs,
           it's hard to combine them when reading.
   fantasai: We got feedback that "grapheme cluster" is confusing and hard
             to read, which is why I used "character".
   ChrisL: I understand that, but it still ends up with a different definition.
   dbaron: I think the solution is to use hyperlinks.
   ChrisL: That helps.
   ChrisL: But people have multiple specs open, they look at things and
           combine stuff, etc.
   ChrisL: It's a problem if they see the same word in two specs that mean
           different things.

   plinss: So if Text doesn't use "character", what should it use?
   ChrisL: A different term that's easier than "grapheme cluster".  Maybe
           "cluster" or something.
   ChrisL: And the parsing spec uses "character" to mean what it means in
           Unicode.
   <fantasai> "user-perceived characters"
   <fantasai> http://www.unicode.org/reports/tr29/#Introduction
   fantasai: That's what the definition of "grapheme cluster" is based on.
   <fantasai> "It is important to recognize that what the user thinks of
               as a "character"—a basic unit of a writing system for a
               language—may not be just a single Unicode code point. Instead,
               that basic unit may be made up of multiple Unicode code points.
               To avoid ambiguity with the computer use of the term character,
               this is called a user-perceived character."
   <fantasai> -- http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
   <florian> I agree that not using the word character the way it is currently
             used in css text makes for awkward sentences, but I think I'd
             take that over technical confusion due to inconsistent use of
             the word
   <SimonSapin> ChrisL, so what’s a character?
   ChrisL: I guess we can talk about that at the meeting.
   [stuff]
   TabAtkins: Could we move the Text bikeshedding to the mailing lilst.
   ChrisL: Sure.
   <fantasai> text issue on character :
              http://lists.w3.org/Archives/Public/www-style/2013Jul/0702.html

   ChrisL: So is a half-surrogate a codepoint?
   TabAtkins: Yes.  But in some places, if we receive those codepoints we
              won't emit them.
   SimonSapin: You can still get some bad codepoints via the OM.
   SimonSapin: By setting a JS string.
   RESOLVED: Switch Syntax to using the term "codepoint".
   <ChrisL> and "codepoint" will be hyperlinked to some unicode-referenced
            definition?

   SimonSapin: After these changes, can we publish Syntax?
   plinss: What level?
   TabAtkins: We haven't published our first WD yet.
   dbaron: Technically we already have a WD for Syntax.
   TabAtkins: Yeah, but in practice it's just a spec with the same name.
   TabAtkins: I'm fine as publishing either as WD or FPWD, based on what
              W3M says.
   <dbaron> I think I said I was happy with publishing a few months ago.
   RESOLVED: Publish Syntax as WD or FPWD, depending.
   <ChrisL> um, if it was published with the same name and same patent policy
            then its a previous fpwd surely
   <SimonSapin> ChrisL, we did the Great Renaming so it’s css-syntax-3 now,
                but css3-syntax should redirect to it
   <ChrisL> yeah I think new shortnames is orthogonal there

   <SimonSapin> terminology question: U+005F is a "code point" (not codepoint)
                and hex 5F is its "number"?

CSS Grid Layout
---------------

   Topic: grid auto-flow
   Rossen: I think we needed to revisit was about you, Tab.
   Rossen: We wanted to have grid-auto-flow to be sparse.
   Rossen: The current spec describes a sparse model, and our impl does it.
   Rossen: The couple of ideas that were floating around were:
   Rossen: Stick with the sparse model, and then if there's demand from
           impls or apps for the dense model, enable it through some switch.
   TabAtkins: That's exactly what I want.
   Rossen: Any particular reason why you wanted the dense model?
   TabAtkins: I know that there are JS libraries that do dense packing,
              and cite dense-ness as a benefit over other sparse packings.
   Rossen: A use-case I can think of is, say, an image page that just wants
           lots of images up without holes.
   Tab: It's really simple to implement; you just reset the grid cursor
        to the beginning after each auto placement.
   Rossen, Stearns: It's one way of doing dense packing.
   Rossen: I'm okay with that.
   <stearns> ok by me
   TabAtkins: Naming ideas? grid-auto-flow-type? -strategy? -pack? -packing?
   Rossen: Why not just throw it into the value of grid-auto-flow?
   TabAtkins: Ah, I guess that's okay.
   RESOLVED: Add a dense/sparse keyword to grid-auto-flow, defaulting to
             sparse.

   Topic: abspos static position for
   fantasai: I wanted to see where impls were at in abspos-in-flexbox, and
             see if we wanted to stick with that.  Also, cross-check with
             Grid and see what it's doing.
   fantasai: Because we want flexbox and grid to be consistent when possible.
   fantasai: If their behaviors are different, maybe switch one to the other's
             behavior.
   florian: This sounds like a f2f topic?
   Rossen: Or maybe before that - start in the list for technical details.
   plinss: Rossen, in Tokyo you talked about doing a small grid meetup?
   Rossen: I think we discussed that.  We had a round of discussion where
           we resolved a bunch of things.
   Rossen: Do we need to make something official? Or are you just getting
           a sense of where we are?
   plinss: The latter.
   plinss: If there's some group of people we need to get together before
           Paris.
   Rossen: Yeah, at least a conference call.

CSS3 Text
---------

   plinss: Are we in a place to make progress on Text issues?
   fantasai: I think mainly waiting for Bert right now.
   fantasai: The last time we discussed I think we had mostly consensus on
             the letter-spacing change, but Bert wasn't happy with it.
   fantasai: Bert's responded this morning, but I haven't had a chance to
             respond back.

   fantasai: There's also the text-align proposal.
   fantasai: About text-align and text-align-last properties.
   <fantasai> http://wiki.csswg.org/topics/text-align-last-shorthand
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jun/0263.html
   fantasai: One way to deal with it is to make text-align a shorthand that
             resets text-align-last.
   fantasai: This also lets us make it easier to set common combinations.
   fantasai: Another way is to do what IE does, where text-align-last only
             has effect if text-align:justify.
   fantasai: That solves it in some cases, but not others.
   fantasai: I think the shorthand approach is easiest for authors, and it
             *looks* like it should be a shorthand.

   SteveZ: If I set text-align:justify, it does what the latin solution is.
           I'd need text-justify:distribute to get the japanese behavior,
           correct?
   fantasai: No, distribute vs auto for text-justify determines the relative
             priority of gaps between letters and CJK characters.
   fantasai: In auto, you don't put spaces between Latin letters, and do
             between CJK.  "distribute" puts spaces in all of them.
   fantasai: You'd say: "text-align:justify-all; text-justify:distribute;"
   fantasai: Or "text-align: justify; text-justify: distribute"
   fantasai: text-align-last:auto means "use whatever text-align says to use"
             generally, but for "text-align:justify", if "text-justify:distribute",
             then text-align-last defaults to "justify"; otherwise, it defaults
             to "start".
   fantasai: Because when the distribute style is used, it's usually used
             in combination with justifying all lines.
   fantasai: So we special-cased that to make it easier.

   SteveZ: There was something about Bert's 15-values proposal that I kinda
           linked.
   SteveZ: There were first, middle, and last lines.  Right now text-align
           only covers first/middle and last.
   SteveZ: Bert was saying there's another case for the middle lines
           specifically.
   SteveZ: There's an application in poetry for that one, where you
           left-justify the first and right-justify the remainder.
   SteveZ: If you set it up to specify first/last/other in that order,
           and default behavior appropriately, you can get a lot of Bert's
           combos relatively simply.
   fantasai: Right - I think independent values combined together is the
             right way to do that.
   fantasai: And we could shorthand it later - text-align-first/last/other?
   SteveZ: That's why I thought going the shorthand route was a good way
           to go.
   Bert: Problem with using multiple keywords is that using two keywords
         isn't very clear.
   Bert: "justify center" means, I guess, everything is justified but the
         last is centered...
   Bert: But "left right" means first line left, rest right.
   Bert: I used single keywords to avoid inconsistency.
   fantasai: Right. I think if we did multiple keywords, say that 2 of
             them cover first/middle and last.
   fantasai: And have some new keywords for targetting only first.
   SteveZ: or my suggestion is that the middle lines are aligned as the
           first, unless you specify the third one.

   Bert: You still have the problem of single-line paragraphs - is that
         first or last line?
   fantasai: I think first line wins over last, and last wins over "other".
   florian: Doesn't seem too bad.

   fantasai: So everyone who's spoken so far seems to think the shorthand
             makes sense, and we need some list discussion for details.
   fantasai: Does anyone have a different opinion?

   Bert: I think shorthand is okay. If we can avoid having three properties,
         even better.
   fantasai: Because of existing content for text-align-last, we need to
             support that property.
   fantasai: We can change the interaction of the two properties because
             of how content usually orders the properties.
   TabAtkins: They order it as if it's a shorthand already.

   <dbaron> Is this a new feature for level 3?
   fantasai: I think that on the list we should get an idea of where we're
             going, and then have the first-line adjustment in level 4.
   fantasai: Keep level 3 with the current feature set.
   florian: But have it forwards-compatible with what we want.
   <dbaron> I don't have a strong opinion; it feels odd to introduce half
            a model, but I'd also rather see this spec move forward.

   fantasai: Rossen, that okay with you?
   Rossen: Yeah, I mean...
   Rossen: I think there's no strong objection on our end.
   Rossen: Our results last time we talked about this were fairly minimal
           in adoption.
   Rossen: I don't think the Word guys are using the combo of properties
           that we feared they might be using.
   Rossen: I'm not sure what it will mean for us to support the legacy
           behavior.
   fantasai: Based on the usage data we've seen, the content will keep
             working with this change.
   fantasai: It's only if you do text-align-last first, followed by text-align,
             that you'll see a behavior change, and we don't see people
             doing that.
   SteveZ: Maybe a warning in level 3 about this behavior change?
   fantasai: Sure.

   Rossen: I'd prefer to see the syntax before resolving.
   fantasai: k

Font Load Events
----------------

   TabAtkins: We (blink) want to implement font load events, but the spec
              hasn't been updated to reflect Tokyo consensus.  Can I take
              over as editor?
   RESOLVED: Add Tab as editor to Font Load Events.

Canonical Order for Shorthands
------------------------------
Scribe: fantasai

   ScribeNick: fantasai
   TabAtkins: For CSSOM, when expanding shorthands, we need to know order
              in which they are serialized
   TabAtkins: For many shorthands, it's obvious
   TabAtkins: For others, like 'border', it's complex
   TabAtkins: We're thinking of using the 'Canonical Order' line for
              serializing values to also specify order of longhands
   dbaron: What do you mean by ...?
   TabAtkins: If you tweak something such that no longer can represent as
              a shorthand, need to convert to longhand

   dbaron: But shorthands still need the current meaning of Canonical Order
   dbaron: It currently controls how you serialize a single property value
   dbaron: In this case, the property value of the shorthand
   dbaron: e.g. specifies that 'border' is expanded as 'medium solid green',
           not 'green medium solid'
   dbaron: You still need that info for shorthands
   dbaron: Are you saying that we stick both types of info in the same line?
   florian: Think he's saying that they're both the same info
   dbaron: I think you should do research -- I don't want people going to
           change existing interop for the convenience of spec authors.

Meeting closed.
Received on Thursday, 15 August 2013 20:42:40 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 15 August 2013 20:42:41 UTC