<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
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
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
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!
<some light arguing>
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
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/??/stearns/ Succeeded: s/concensus/consensus/ Succeeded: s/working on/publishing/ Succeeded: s/??/krit/ Succeeded: s/bare item/bare ident/ Succeeded: s/derek/krit/ Succeeded: s/against/against but can live with/ Succeeded: s/jjanson/JohnJansen/ FAILED: s/jjanson/johnjansen/ Succeeded: s/TR 50/UTR-50/ Found ScribeNick: antonp Inferring Scribes: antonp WARNING: No "Present: ... " found! Possibly Present: Bert Brian_Leroux CSSWG_LogBot ChrisL Hixie JohnJansen Liam Microsoft Ms2ger P11 P24 P26 P30 P31 P36 P43 P61 P7 ScribeNick SimonSapin SteveZ TabAtkins_ Wes- aaaa aabb aacc alan alex alexmog alexmog_ antonp arron arronei_ bradk brian css danielfilho dbaron decadance drublic dstorey dstorey1 ed fantasai florian florian_ florianr glazou glenn gsnedders hober https isherman jdaggett jet joined kennyluck koji kojiishi krijnh krit ksweeney logbot miketaylr myakura naitik_ nimbu note oyvind paul___irish pjrm plinss rbetts ryan shans shepazu stearns sylvaing_away szilles tab tantek trackbot vhardy wes 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 WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 Guessing minutes URL: http://www.w3.org/2012/04/25-css-minutes.html People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]