W3C home > Mailing lists > Public > www-style@w3.org > April 2012

[CSSWG] Minutes and Resolutions Telecon 2012-04-25

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 26 Apr 2012 01:04:44 -0700
Message-ID: <4F99019C.7070208@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - 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
   - 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

====== Full minutes below ======

   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


ScribeNick: antonp


   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
   <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
   <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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:58 UTC