<glazou> hello, finally made it :-)

<dcramer> 413.325.1307 is Dave Cramer from Hachette

<SimonSapin> How do I tell Zakim about a room with two people?

<SimonSapin> [Mozilla] has SimonSapin

<bkardell> 520.280.3584 is bkardell

<fantasai> ScribeNick: fantasai

<antonp> ScribeNick: antonp

<fantasai> ScribeNick: fantasai

plinss: Any additions to the agenda

Unicode-Range

SimonSapin: In the Syntax spec, some changes from CSS2.1
... Tried to match Fonts spec, do parsing/normalization of unicode-range in tokenizer
... But fonts spec changed
... So want to revert changes, and do what CSS2.1 does for UNICODE-RANGE
... Tab prefers to do parsing in Syntax, have unicode-range return pair of integers rather than string

fantasai: Well, I know we have implementations of the 2.1 tokenization

SimonSapin: They're not testable

dbaron: Some cases can be tested via obscure counter-reset/increment declarations
... But don't think it's worth worrying about
... 2 questions - what is the desired behavior, and which spec?
... So first, what's the desired behavior

jdaggett: Desired behavior in terms of ... ?

dbaron: What are the differences in behavior that we're discussing

SimonSapin: Fonts spec changed details of UNICODE-RANGE parsing in last WD
... e.g. ranges beyond Unicode used to be clipped, but are now invalid

jdaggett: How does that impact Syntax?

SimonSapin: Because Syntax defines tokenization

<SimonSapin> SimonSapin: Syntax used to do clipping in the tokenizer

jdaggett: Only opposition is Tab, and he's not on the call atm

SimonSapin: What came out of ML discussion was Tab, was compromise
... Tokenizer would have pair of integers
... Leave to fonts what to do with integers, depending on whether increasing/decreasing etc.
... Just two integers given back

jdaggett: impact of what we're talking about is whether parser takes something as UNICODE-RANGE or not

<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Sep/0019.html

jdaggett: Cases where author will want to use that syntax somewhere else is almost never

SimonSapin: Proposal is to remove part of syntax that defines unicode-range range restrictions

plinss: Does this impact Fonts, which is going ot CR?

<SimonSapin> SimonSapin: ie. removing this section: https://dvcs.w3.org/hg/csswg/raw-file/aa1b58939f73/css-syntax/Overview.html#set-the-unicode-ranges-range

TabAtkins: Could remove stuff from Fonts spec, because covered by Syntax

fantasai: Don't think we should be removing anything from Fonts spec, Syntax is kindof early stages, would like Fonts to be complete as of now.

jdaggett agrees

ChrisL: Don't want Fonts spec to change
... Given it's going to CR

TabAtkins: UNICODE-RANGE in CSS2.1 accepts syntax that will never be needed/used
... Would like those cases to not parse as UNICODE-RANGE.
... But fine with range-restrictions staying in Fonts spec
...
... I would like to kill U+1?3

<SimonSapin> examples of bad syntax: U+1?3, U+1?-30

TabAtkins: Want to make that invalid at the tokenization level

SimonSapin, I think the second one is already invalid in 2.1

<SimonSapin> fantasai, it is valid in 2.1

plinss: Any other comments?

<SimonSapin> 2.1’s definition: u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?

fantasai: No changes to Fonts spec, right?

right

fantasai: So only question is whether UNICODE-RANGE uses the 2.1 syntax or Syntax syntax

jdaggett: [talks about splitting definitions across specs]

fantasai: If we're changing definition fo UNICODE-RANGE, we need to errata 2.1
... Can't have two different definitions depending which spec you read

plinss: Anyone objecting to Tab's change?

TabAtkins: Simon's proposal was to accept 2.1 syntax, and have Font's processing make things invalid

SimonSapin: I'm fine with Tab's proposal as well

fantasai: Only thing that bothers me is that we have implementations on the 2.1 tokenization
... They'd have to go back and change

TabAtkins: It's (for the most part) author-undetectable

Bert: I'd like to see the regex first, if that's ok

TabAtkins: Ok, I will send to ML

RESOLUTION: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more restrictive in what it takes, per Tab's proposal

No changes to Fonts

<jdaggett> http://dev.w3.org/csswg/css-fonts/doc-20130711-LCWD.html

plinss: Fonts to CR?

jdaggett: There was one outstanding issue on 'ordinals', but that got cleared up over ML with examples/pics
... Question is, do we need another LC or go to CR?
... I don't think there's a huge impact on implementations from any of these changes
... Most significant change is removing 'auto' value

fantasai: I don't think we need to go through another LC, changes aren't very major

ChrisL: Spec is currently listing everything as major changes, most are minor
... But several are substantial [lists]
... Reorder feature precedence, 'auto', etc.
... All these need to be addressed, and argue that they are minor
... I'd rather not do another LC

jdaggett: Auto value was never implemented
... Not part of CSS2 spec
... Only removing a single value, that was never implemented

<dbaron> I think ChrisL was saying that we need to argue that the changes weren't substantive in order to go from LC to CR.

<dbaron> (for minutes)

[process discussion]

<ChrisL> http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr

jdaggett: So I should revise Changes section to not list changes as major

<ChrisL> quote "Some reasons for declining a transition request

<ChrisL> The technical report has been substantively modified since the previous transition. In this case, the document is returned to the Working Group for further work."

jdaggett: Could also add an "impact" statement, to describe what the impact is on implementations
... For most of these, no impact, because there aren't implementations

[discussion of how to style DoC]

[more discussion of handling DoC]

ChrisL: I'm trying to be pre-emptively awkward here, to make the transition call go smoothly

plinss: I get your point Chris, and but for this point, i don't think this is worth taking up group time
... I'd rather take up 10 min of transition call time than 10 min of CSSWG telecon time
... Any objections to CR?

SteveZ: Sent email this morning on 'ordinal' issue

<ChrisL> ok. socan we have a minuted decision to request CR followed by a transition request email

SteveZ: I have no text that's there, just want to point out that there's an aspect of ordinals that is in the OT definition, that really no longer applies

<ChrisL> I can help draft the transition request if that would help

SteveZ: The original conception of 'ordinal' feature was that you could mark a paragraph, and it would ordinal everything that was number followed by letters
... Problem was that writing rules for all languages was troublessome
... So you need to apply the feature around just the numbers
... as the example shows
... Might want to say that in the text

jdaggett: Don't think it's necessary
... I can add to the sentence within the example, just to indicate that it's not applied to the paragraph

SteveZ: That sounds good to me
... Just want a warning to not apply it to the whole paragraph

jdaggett: Any objections to CR?

fantasai: No, let's do it!

<ChrisL> none at all

RESOLUTION: Fonts Level 3 to CR

ACTION ChrisL Send transition request

<trackbot> Created ACTION-576 - Send transition request [on Chris Lilley - due 2013-09-11].

CSS Cascade

http://dev.w3.org/csswg/css-cascade/issues-lc-2013

fantasai summarizes all the comments

<glazou> go ahead!

RESOLUTION: Cascade L3 to CR

text-combine-horizontal and font features

fantasai: [summarizes discussion]

jdaggett: I'm fine with that

SteveZ: Can I raise a related issue?

jdaggett: Can you raise it on the list?

plinss: Will it impact this discussion?

SteveZ: Don't know
... When I contacted Adobe font people about compression issue, they basically said "don't do that"
... So I had a private conversation with Koji, who said 'but we have to do that, because the WebKit based publication guide wants to be able to ensure that all their text fits within an em-square for body text'
... Issue I'm concerned about is making the default for text-combine do the compression
... Rather than have a property to turn it on
... Which would remove many of the cases that we seem to be stumbling over

jdaggett: This issue is exactly what we discussed 1.5 years ago.
... We had a property to control it
... But seemed overkill to me
... Maybe post to the list, what you want
... We've added this property, and then took it out, and now you're leaning towards bringing it back

SteveZ: What I want is not have the default be compression

<dbaron> fantasai: reason default is compression for CSS and not for indesign is that in indesign author can see and tweak the result and will adjust it; in CSS author doesn't see it and doesn't know exactly where lines will break, etc.

<dbaron> fantasai: important for publishers not to have overlap. Can't manually check with CSS. So better to force 1em compression so they can guarantee there's no conflict.

This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Prefer/Tab prefers/
Succeeded: s/substantial/substantive/
Found ScribeNick: fantasai
WARNING: No scribe lines found matching ScribeNick pattern: <fantasai> ...
Found ScribeNick: antonp
WARNING: No scribe lines found matching ScribeNick pattern: <antonp> ...
Found ScribeNick: fantasai
Inferring Scribes: fantasai, antonp
Scribes: fantasai, antonp
ScribeNicks: fantasai, antonp

WARNING: No "Present: ... " found!
Possibly Present: Apple Bert BradK ChrisL IPcaller Lea MaRakow Microsoft Mozilla Ms2ger P18 P32 P40 P98 Plh Rossen_ ScribeNick SimonSapin Stearns SteveZ TabAtkins aaaa aabb aacc aadd aaee aaff aahh aaii aajj aakk aall antonp bkardell css dael darktears dbaron dcramer fantasai florian glazou glenn hober israelh jdaggett jerenkrantz joined krit krit1 leif lmclister oyvind plinss rhauck rhauck1 smfr tantek trackbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 04 Sep 2013
Guessing minutes URL: http://www.w3.org/2013/09/04-css-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.