- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 15 Aug 2013 13:42:12 -0700
- 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