- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 26 Apr 2012 01:04:44 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Alan Stearns added as co-editor of Regions and Exclusions
- RESOLVED: Ryan Betts added as co-editor of Device Adaptations
- RESOLVED: Publish new WD of Regions
- RESOLVED: jdaggett's proposal to restrict syntax of font-feature-settings
to well-formed OpenType tags accepted
http://lists.w3.org/Archives/Public/www-style/2012Apr/0499.html
- RESOLVED: make changes requested by jdaggett and to update references to UTR50,
and publish new WD of Writing Modes
- ACTION everyone: Review open issues on CSS3 Values and Units Disposition of Comments
http://dev.w3.org/csswg/css3-values/issues-lc-2012
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
David Baron
Ryan Betts (Adobe)
Bert Bos
Tantek Çelik
John Daggett
Arron Eicholz
Elika Etemad
Daniel Glazman
Koji Ishii
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Alex Mogilevsky
Edward O'Connor
Anton Prowse
Florian Rivoal
Dirk Schulze
Alan Stearns
David Storey
Steve Zilles
http://www.w3.org/2012/04/25-css-irc
ScribeNick: antonp
Administrative
--------------
Topic: extra items for today
glazou: long thread about tooltip, there's an author expectation about
being able to design tooltips in CSS
glazou: simple feature, has some issues but we should tackle it
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012AprJun/0099.html
Topic: add Alan Stearns as co-editor to Regions and Exclusions
glazou: No objections
<glazou> http://www.w3.org/mid/585D0AE0-087B-4607-9121-C3CBC088E806@adobe.com
RESOLVED: add Alan as co-editor to those 2 specs
Topic: 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
RESOLVED: Ryan is now co-editor of that spec
* fantasai would like to add the display: flexbox bikeshed to the agenda,
since if we want to change that we need to do a search/replace
on the spec
<TabAtkins> fantasai, yeah, I thought we wanted to talk about the alignment
spec too.
Publishing Regions/Exclusions
-----------------------------
Topic: 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?
<dbaron> http://lists.w3.org/Archives/Public/www-style/2011Dec/0411.html
is the note I was thinking of
alan: I believe so,... but not sure which particular note you're referring to
alan: 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?
<glazou> stearns: add me to ACK section of Exclusions?
bert: request for notes:
bert: we should move out the things we /don't/ want
bert: e.g. the idea of elements being a region
bert: need a note saying that regions won't be created like that
stearns: that wasn't the resolution
stearns: we never decided to disallow it; just discourage it
glazou: don't want to disallow either
bert: I want to disallow
bert: 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
dbaron: that's why we wanted notes in the spec
dbaron: 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
alan: with the missing notes
alan: 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
dbaron: 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
dbaron: I don't want to say yes conditionally again; I want to see it done
alan: I'll work on it today
glazou: ok, that defers the discussion on exclusions. Go to email with it
glazou: and now, Regions?
bert: @regions rule: there are alternatives
bert: pseudo-elements
bert: hierarchy notation could also avoid needing @-rules
bert: at last F2F somebody presented hierarchies
bert: they can be employed to avoid using an @-rule
<jdaggett> note: tab presented about hierarchies...
bert: don't know if these alternatives are necessary in the final answer,
but think we should investigate alternatives
bert: 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 pseudo-elements to refer to the region in any case
florianr: hierarchies can be used on top
glazou: yes, but the main thing is the pseudos
glazou: 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
fantasai: 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
bert: 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
alan: 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; they should use best practices
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
glazou: objections?
glazou: 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
RESOLVED: Publish new WD for regions
glazou: Alan to make changes to Exclusions to satisfy dbaron, and then we revisit
<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.
Syntax of font-feature-settings
-------------------------------
<glazou> http://lists.w3.org/Archives/Public/www-style/2012Apr/0499.html
jdaggett: in previous definition, tags could be no more than 4 chars in
length, didn't mention about less than 4, or type of chars
(ASCII or not)
jdaggett: change proposal is to tighten that up
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Apr/0548.html
<ChrisL> q+ to ask about OT and Graphite
jdaggett: Jonathan Kew brought up concern that we're locking down on OpenType.
jdaggett: but all along we've discussed including in F2F in March last year:
OpenType is where it's at
jdaggett: Just by tying this to the OpenType format, we're not restricting
ourselves in regards to supporting future font technologies
tab: that makes sense since a user agent is just looking the tag up in a
registry anyways
<SteveZ> +1 for John's comments
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
ChrisL: I think it's a good restriction, reminds me of the restriction on
language tags, which were 2, and were then extensible to 3 chars etc
ChrisL: by making it clear and specific, we actually allow ourselves
to expand the possibilities later
ChrisL: .... functional syntax proposed
jdaggett: Graphite has problem that there's no structure; font features
are identified by 4-byte tags, just like OpenType
jdaggett: but there are Graphite fonts which ship with simple numeric
values like 1001 rather than some form of alphabetic tag
jdaggett: apps are forced to support this through font-specific UI
jdaggett: not a good pattern
jdaggett: restricting to 4-char tags isn't a big burden for fonts
jdaggett: Graphite fonts should be encouraged to use the set of registered
tags in OpenType; brings consistency across fonts
ChrisL: you mean binary-encoded 1001?
jdaggett: yeah
jdaggett: Right now we can't express that in this syntax at all
jdaggett: I don't think that's a bad thing
fantasai: in CSS we don't hard-code anything about particular formats
we integrate with, e.g. png images
fantasai: I don't see benefit of restrictions to authors here
<ChrisL> elika, yes we do. we normatively reference opentype, no?
fantasai: prevents experimentation due to our syntax restrictions
fantasai: I see problems with this change. I'm against
jdaggett: theoretically yes, but in practice there's no other font
technology right now which has this problem
jdaggett: look at AAT (Apple Advanced Typography) as an example of
something that might be different, but that's not going
to become a cross-platform, widely supported format anytime
soon
<ChrisL> it's like theoretically, we need link type="text/css" but in practice ....
jdaggett: without syntax checking, there's no way of guiding authors along
jdaggett: an author that's creating an implementation and experimenting
with a new font format, is not a blocking thing
jdaggett: want to make sure that real UAs do the right thing
jdaggett: so fantasai's point is true theoretically but not in practice
ChrisL: in practice there's only CSS even though in theory there are other
stylesheet langs
ChrisL: 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 defining things like font-variant in terms of OpenType,
yes, but we're not saying you can't translate those same features
to a different font format.
fantasai: It doesn't make sense for CSS restricted its syntax to OpenType
<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
<kennyluck> +1 to dbaron's comment
fantasai: we're preventing people from implementing new font engines
without violating our spec
jdaggett: what you said is wrong, this isn't restricting the use of other
font technologies
<ChrisL> john is saying what i was trying to say. the high level things
are font format agnostic. its only the low-level spaces that
are opentype specific
jdaggett: there's nothing in the spec that says you can't 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 nam
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
<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
dbaron: feels weird to make parse-time validity dependent on what's inside
a string; no precedent
szilles: Benefit for user is they get early checking of errors that could
have strange effects if they ran through to the clients
szilles: it's good to catch things early
szilles: 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
szilles: it's not locking out; it's just recognizing that our particular
syntax is OT-oriented
szilles: 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 or add a
format prefix eg "ot-
jdaggett: but it's redundant,
jdaggett: underneath you're passing to OT anyway
<ChrisL> we talked about this several times before. but we keep revisiting
with no real new information
<fantasai> ChrisL, we haven't. Not this specific issue.
ChrisL: re dbaron's point about string checking
ChrisL: Make a new type for 4-char ASCII string?
ChrisL: Wouldn't impact implementations, only specs themselves
dbaron: I don't think that makes a difference
plinss: ot- prefix or functional notation does satisfy the parsing thing
that dbaron is mentioning
plinss: 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 is that authors don't need to worry about
CSS escaping rules that apply to identifiers
tab: but if it's just ascii tags, ot- is easier to type than quote symbols
tab: automatically gets round the namespacing issue
jdaggett: we were encouraged to use strings
tab: unrestricted items prevent us from expanding, unless done very carefully
tab: prefixes help avoid that difficulty
plinss: I slightly prefer the functional notation and solves the bare ident problem
plinss: 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
jdaggett: we're wasting time on the telecon
jdaggett: if you want to object, do it on the list!
* fantasai didn't see the point in repeating what jkew said
<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: abstain
hober: abstain:@
jdaggett: for
antonp: abstain
alex: abstain
szilles: for
krit: abstain
fantasai: against
<fantasai> but I can live with it
bert: against
dstorey: abstain
jjanson: abstain
tab: for
koji: abstain
ChrisL: for
ChrisL: 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
RESOLVED: proposal is accepted
<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
Publish new WD about writing modes
----------------------------------
<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
jdaggett: my comments were just about section 5.1.1, it's just three paragraphs
and that's it
fantasai: also UTR50 updated a few days ago, I need to update references
<Zakim> Bert, you wanted to ask if we know anything about TR 50 schedule
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
fantasai: our spec will be more stable because we'll reference the concept
being described in the UTR50
fantasai: and even if the other spec changes in terms of its data, our
reference will still remain correct
fantasai: we can resolve to publish pending jdaggett's approval of the edits?
szilles: I send a request to clarify something about text-combine that I
was unclear about
szilles: Koji also had issues
jdaggett: I don't think we need to resolve text-combine issues to publish a WD
fantasai: I'll make sure the issues are tracked
glazou: provided the changes are made, shall we release new WD? Objections?
RESOLVED: make changes and then publish new WD
Values and Units
----------------
Tab: I request that WD should review the DoC of values+units
fantasai: I will add additional info
Meeting closed.
Received on Thursday, 26 April 2012 08:05:21 UTC