SV_MEETING_TITLE -- 25 Apr 2012

<alexmog_> zalim, aaaa is me

<krit> Zakim: aabb is me

<plinss> http://www.w3.org/2006/tools/wiki/Zakim_Tips

<glazou> you mean "Zaki, tips?" don't work ?

<scribe> ScribeNick: antonp

glazou: Topic: extra items for today
... item: long thread about tooltip, there's an author expectation about being able to design tooltips in CSS
... simple feature, has some issues but we should tackle it

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

glazou: Topic: add Alan Stearns as co-editor to Regions and Exclusions
... No objections

<glazou> http://www.w3.org/mid/585D0AE0-087B-4607-9121-C3CBC088E806@adobe.com

RESOLUTION: add Alan as co-editor to those 2 specs

add Ryan as co-editor to device adaptations spec

glazou: No objections

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

RESOLUTION: Ryan is now co-editor of that spec

Regions/Exclusions: request to publish new WD

glazou: 4 months since last WDs

dbaron: last time around we had a discussion about a note. Has it been revised as agreed

alan: I believe so,... but not sure which particular note you're referring to
... going through action items, bugzilla, mailing list: we're up to date, and notes exist in spec for everything being tracked as of today

glazou: other comments?

bert: request for notes:

<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Dec/0411.html is the note I was thinking of

<glazou> stearns: add me to ACK section of Exclusions?

bert: we should move out the things we /don't/ want

eg the idea of elements being a region

scribe: need a note saying that regions won't becreated like that

stearns: that wasn't the resolution
... we never decided to disallow it; just discourage it

glazou: don't want to disallow either

bert: I want to disallow
... no redundant elements should exist in a web document

alan: we understand the issue, and want to find ways around creating elements, and even if there was an alternative in css to create wrappers, we still don't want to disallow

glazou: is a religious discussion! Even if valuable, it can be a comment to the new WD... it's not blocking a new WD

bert: but it's no longer a FPWD so want to act now

glazou: need a consensus, and I'm not hearing one

alan: I can add a bug to track, and a note to the spec

dbaron: in the case of exclusions, there wasn't even a consensus that we wanted to work on the thing
... that's why we wanted notes in the spec
... there were conditions to publishing the spec, and those conditions weren't met

alan: I'll look back at the conditions, and try to update the Exclusions draft
... with the missing notes
... but I need to know exactly what needs addressing

<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Dec/0411.html

krit: can we say it's still under discussion?

glazou: I'm not sure the assertion in dbaron's post is correct

florian: I agree with dbaron's note

alan: we want to clarify that Exclusions are not dependent on abspos elements

dbaron: OK it's not dependent on abspos, but practically that's how you use it
... not just a question of the examples in the spec; it's about the ways one would use it practically

alan: would you be ok with publishing a new WD of exclusions if there was a bugzilla item and a note in the spec referencing it?

dbaron: that's what we agreed to as a compromise last time, and it didn't happen
... I don't want to say yes conditionally; I want to see it don

alan: I'll work on it today

glazou: ok, that defers the discussion on exclusions. Go to email with it
... and now, Regions?

bert: @regions rule: there are alternatives
... pseudo-elements
... hierarchy notation could also avoid needing @-rules
... at last F2F somebody presented hierarchies
... they can be employed to avoid using an @-rule

<jdaggett> note: tab presented about hierarchies...

bert: don't know if these alternatives are necessary tghe final answer, but think we should investigate alternatives
... would like a note mentioning at least the pseudos alternative

glazou: hierarchies wouldn't solve the problem, since it doesn't select boxes

fantasai: you'd need pseuod-elements to refer to the region

florianr: hierarchies can be used on top

glazou: yes, but the main thing is the pseudos
... I prefer the @-rule; it's simpler, things are better located in the same place, less repetition

fantasai: hierarchies solves the same problem in general, so perhaps we should solve regions with the general solution
... the problem about being able to group rules applies equally to regions and other selectors

glazou: hierarchies is a /very/ early draft; should we be relying on it so early?

alex: do we need to have an issue in the bug list about syntax?

<Bert> @region ::first-line { Y {...} } is the same as Y::first-line {...}

glazou: bert, would you be happy with a note saying alternative to an @-rule is to use a pseudo?

bert: perhaps with more detail, but yes

glazou: conditional on the note, can we publish WD?

bert: concerned about use of elements
... I'm reluctant about current situation

alan: there's a link to page templates draft in the doc, and the draft has removed all language linking regions to elements
... they're still there in the examples, but there's nothing about elements in the normative text

bert: yes, but the first example is exactly an element

glazou: it's only an example!

bert: people look at the examples when they look at specs

tab: examples still serve well as author guidelines; we should have best practice

<glazou> hi ChrisL

glazou: we change our message on whether specs are tutorials or not every year...

alan: I just want to publish a WD on a 6-month old spec with the recent changes, and bury the old draft

glazou: I want to close on this
... objections?
... Actions: note about elements, to satisfy Bert; and a note about possibly replacing @-rules with a technique involving pseudo-elements and possibly hierarchies

<ChrisL> +1 to publish

bert: subject to those conditions, I'm OK

RESOLUTION: Publish new WD for regions

glazou: Alan to make changes to Exclusions to satisfy dbaron, and then we revisit

<glazou> http://lists.w3.org/Archives/Public/www-style/2012Apr/0499.html

Item 2, fonts, syntax of font feature settings

jdaggett: tags were at least 4 chars in length, didn't mention about less than 4, or type of chars
... change proposal is to tighten that up

<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0548.html

jdaggett: Jonathan Kew brought up concern that we're locking down on OpenType.
... but all along we've discussed including in F2F in March last year: OpenType is where it's at
... don't think that by pinging this to the OpenType format we're not restricting ourselves

tab: ???

<SteveZ> +1 for John's comments

<bradk> By the way, I think the examples in the regions specs are fine, because they are simple and focus exclusively on the concepts they are trying to illustrate, without forcing you to read and understand some other spec about pseudo-element generation. And JavaScript generation of regular elements such as DIVs is a reasonable way to use regions.

jdaggett: we're not limiting this to defined/registered tags

tab: does the UA need to understand it, or is it a straight path to the underlying system

jdaggett: it's a straight path

tab: ok I withdraw my comment

<Zakim> ChrisL, you wanted to ask about OT and Graphite

ChrisL: I think it's a good restriction, reminds me of the restriction on lnaguage tags, which were 2, and were then extensible to 3 chars etc
... by making it clear and specific, we actually allow ourselves to expand the possiblities later
... .... fucntional syntax proposed
... jdaggett: Graphite has problem that there's no structure; there are fonts which ship with ?? numeric value like 1001
... apps are forced to support this through font-specific UI
... not a good pattern
... restricting to 4-char tags isn't a big burden for fonts
... encouraging them to move to set of registered tags in opentype is good; brings consistency
... you mean binary-encoded 1001?

jdaggett: yeah
... Right now we can't express that in this syntax at all
... I don't think that's a bad thing

fantasai: in CSS we don't hard-code anything about particular formats we integrate with
... eg png images
... I don't see benefit of resitrcitions to authors here

<ChrisL> elika, yes we do. we normatively reference opentype, no?

fantasai: prevents experimentation due to our syntax restrictions
... I see problems with this change. I'm against

jdaggett: theoritically yes, but practically there's no tech out there right now which has this problem
... look at AAT as an aexample of something that might be different, but nothing's coming into existence

<ChrisL> it like thoretically, we need link type="text/css" but in practice ....

jdaggett: without syntax checking, there's no way of guiding authors along
... an author that's creating an implementation and experimenting with a new font format, is not a blocking thing
... want to make sure that real UAs do the right thing
... so fantasai's point is true theoretically but not in practice

ChrisL: in practice there's only CSS even tho in theory there are other stylesheet langs
... we reference OpenType a lot, we've already tended towards it; that's what people are calling for right now and can use right now

<Bert> (q+ to say that there is no "OpenType" in the name of the property

fantasai: We're not saying you can't use a different format, but if you're using other tech it makes sense for CSS to trigger its abilities without being restricted by our syntax

<dbaron> I think it's the first time that that CSS value correctness (whether it's a parse error) depends on something that's inside the contents of a string, which feels a little weird to me

fantasai: we're preventing people from implementing new font engines without violating our spec

jdaggett: what you said is wrong

<kennyluck> +1 to dbaron's comment

<ChrisL> john is saying what i was trying to say. the high level things are font format agnostic. its only the low-level espaces that are opentype specific

jdaggett: there's nothing in the spec that says you cant implement to another format; it's only the low-level syntax that you can't access

<Zakim> Bert, you wanted to say that there is no "OpenType" in the name of the property

bert: I agree with fantasai, we shouldn't restrict to OpenType

<ChrisL> we are not restricting "for ever"

<stearns> and we're only restricting a tiny section of the overall functionality

<ChrisL> nobody said 'for ever" except for bert

Tab: we can always issue updates... not restricting us forever

<glazou> then SteveZ

dbaron: feels weird to make parse-time validity dependent on what's inside a string; no precedent

<fantasai> Tab, I don't think the CSSWG should be required to issue updates to its syntax because some other layout team wants to use a font tech other than OpenType

szilles: Benefit for user is they get early checking of errors that could have strange effects if they ran through to the clients
... it's good to catch things early
... Second point: This is a low-level feature, it's largely designed with OpenType in mind. jdaggett's point is that if there;s a different format then the syntax is inappropriate and the vendor could always create an experimental feature to deal with it
... it's not locking out; it's just recognizing that our particular syntax is OT-oriented
... there are reasons for orienting towards a particular format

jdaggett: We've talked about this before; in March F2F last year I said: wrap a functional notation around all of these tags, eg "ot-"

<ChrisL> we talked about this several times before. but we keep revisiting with no real new information

jdaggett: but it's redundant,
... underneath you're passing to OT anyway

<glazou> Zakim:

<Zakim> ChrisL, you wanted to suggest a new type which is a subset of string

<fantasai> ChrisL, we haven't. Not this specific issue.

ChrisL: re dbaron's point about string checking
... Make a new type for 4-char ASCII string?
... Wouldn't impact implementations, only specs themselves

dbaron: I don't think that makes a difference
... there's still value in it

plinss: ot- prefix or functional notation does satisfy the parsing thing that dbaron is mentioning
... If we have an OT-specific functional notation that leaves us room to move later, eg the 4-char restriction

jdaggett: theoretically yes, but in practice no

plinss: we need to be explicit whether this is OT-specific or generic

jdaggett: We don't need individual property names for different font technology; it's overkill

tab: reason we went with strings, .....something about escaping.....
... ot- is easier to type than quote symbols
... automatically gets round the namespacing issue

jdaggett: we were encouraged to use strings

tab: unrestricted items prevent us from expanding, unless done very carefully

,... prefixes help avoid that difficulty

plinss: I slightly prefer the functional notation and solves the bare ident problem
... I'm not arguing strongly for it; just throwing it out there

glazou: no consensus at the moment

jdaggett: every time we talk about this we go full circle
... we're wasting time on the telecon
... if you want to object, do it on the list!

glazou: let's move on

<ChrisL> sigh.

<ChrisL> I am in favour too, plus it is what is implemented

dbaron: I'm in favour of jdaggett's proposal

Straw poll!

florianr: abstain

glazou: for

plinss: for, but preference for a bit tighter

arron: abstain

dbaron: for

brian: abstain

ryan: abstain

alan: for

<glenn> glenn abstain

glenn: abstain

hober: abstain:@

jdaggett: for

antonp: abstain

alex: abstain

szilles: for

krit: abstain

fantasai: against but can live with

<fantasai> but I can live with it

bert: against

<bradk> (I was abstain)

dstorey: abstain

JohnJansen: abstain

tab: for

koji: abstain

ChrisL: for
... if most people don't care; that means stay with current proposal

<JohnJansen> s/jjanson/johnjansen

bert: I can live with it

<ChrisL> yay

glazou: we can all live with it

<jdaggett> thanks!

glenn: proposal is accepted

<ChrisL> minuted resolution please

RESOLUTION: proposal is accepted

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

<glazou> http://lists.w3.org/Archives/Public/www-style/2012Apr/0650.html

Publish new WD about writing modes

fantasai: I need to make more edits to address jdaggett's comments
... UTR50 (?) updated a few days ago, I need to update references

<Zakim> Bert, you wanted to ask if we know anything about UTR-50 schedule

jdaggett: it's the set of three paragraphs and that's it

bert: is UTR-50 updated?

jdaggett: there's supposed to be a discussion at the Unicode meeting

bert: are there any predictions about the outcome of the meeting?

fantasai: people working on it are aligning
... our spec will be more stable because we'll reference the concept being described in the the other spec
... and even if the other spec changes, our reference will still remain correct
... we can resolve to publish pending jdaggett's approval of the edits?

<stearns> probably no time to come back around to this, but the text dbaron wanted to see in the exclusions draft is already there, in issue 1

szilles: I send a request to clarify something about text-combine that I was unclear about
... Koji also had issues

fantasai: I'll make sure the issues are tracked

glazou: provided the changes are made, shall we release new WD? Objections?

RESOLUTION: make changes and then publish new WD

Tab: I request that WD should review the DoC of values+units

fantasai: I will add additional info

glazou: Bye everyone

fantasai/glazou: do I have to do something to close the minuting?

<fantasai> antonp: nope

cool

<fantasai> RRSAgent: make minutes

- DRAFT -

SV_MEETING_TITLE

25 Apr 2012

Attendees

Contents

add Ryan as co-editor to device adaptations spec

Regions/Exclusions: request to publish new WD

Item 2, fonts, syntax of font feature settings

Publish new WD about writing modes

Summary of Action Items

Scribe.perl diagnostic output