[CSSWG] Minutes and Resolutions Telecon 2011-11-30

Summary:
   - Reviewed state of CSS3 Speech LC comments and progress toward CR
   - New draft of JLREQ: http://lists.w3.org/Archives/Public/www-style/2011Nov/0735.html
     Apparently no diffs are available at this time.
   - RESOLVED: radial-gradient( [<shape> || <size> ] [at <position>]?, <color-stops> )
   - RESOLVED: Publish new WD of CSS3 Images
   - RESOLVED: split predefined counter styles into a separate spec

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

Present:
   Tab Atkins
   David Baron
   Kimberly Blessing
   Bert Bos
   Tantek Çelik
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vicent Hardy
   Koji Ishii
   John Jansen
   Håkon Wium Lie
   Peter Linss
   Divya Manian
   Anotn Prowse
   Florian Rivoal
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/11/30-css-irc
ScribeNick: TabAtkins

Unicode TR50 update
-------------------

   jdaggett: There was an item on Ed and Sylvain to report back.
   smfr: Ted can't make it today.
   jdaggett: But he said he would have an update by next week.
   sylvaing: And I'm a bit busy with the next preview, but I'm hoping
             to have it soon.
   plinss: Okay, defer to next week.

Remaining CSS3 Speech issues
----------------------------

   <danielweck> http://wiki.csswg.org/spec/css3-speech#issue-1
   danielweck: This issue is contentious.
   danielweck: Last I heard form the commenter was 29 Sep.
   danielweck: I've sent two heads-up.
   <danielweck> http://www.w3.org/TR/css3-speech/#cue-props
   danielweck: As far as I understand, the normative text regarding the
               use of decibels - I agreed we have an issue with normative
               vs informative text here.
   danielweck: However, because of the lack of further discussion from the
               commenter, I'm not entirely sure what the correct position
               is regarding which statements are normative.
   danielweck: There are some problems with the informative statements
               we're making about the decibel levels from the output of
               speech synthesizers, so we need to remove that.
   danielweck: So two question.
   danielweck: One, what do we do if we don't get feedback?
   danielweck: Two, in terms of the process, what happens if we decide to
               mark this particular issue part of the syntax at-risk?
               Not the entire property, just the decibel part.
   danielweck: Does that require going back to WD, or what?  How fixable are we?
   fantasai: I'd say to do your best to address the person's feedback.
             Then record in the disposition of comments the comments and
             the changes you've made, and record that you haven't gotten
             a response from them.
   fantasai: You've given them plenty of time and reminders.  If they
             don't respond by the time we take the DoC to the director,
             he can still review their comments and check that you've
             addressed them.
   fantasai: Regarding marking something as at-risk, you can do that now.
             It doesn't require going back to WD.

   <danielweck> http://wiki.csswg.org/spec/css3-speech#issue-18
   danielweck: Second issue, issue 18.  Not a blocking issue, just waiting
               for confirmation.
   danielweck: I don't think they'd raise an objection if we completed
               without a confirmation.
   danielweck: So in terms of timeframe, what's a reasonable or typical
               timeframe when writing the call for implementation?
   fantasai: The timeframe for CR is generally taken as a minimum.  Usually
             a six-month minimum, but usually it takes longer than that to
             get the testsuite and the impl reports, etc.
   fantasai: With regards to the transition, the comment period has closed.
             If you don't get a response at all in a week or two, I think
             it's fair to say that's long enough to either respond or
             request additional time for investigation.
   danielweck: Okay.

   danielweck: My status as a contributor to the spec in the coming year -
               we want to work with the spec through CR, including making
               the testsuite, etc.
   danielweck: But I'm not entirely sure who'll be handling the impl reports,
               liaising with browsers, etc.
   fantasai: I think that's fine.  We should probably ask the epub folks to
             look for somebody to own the testsuite.
   danielweck: I'm in the epub and that's our plan too.

New draft of Japanese Text Layout spec
--------------------------------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Nov/0735.html
   plinss: If you have any interest, please look at it and give feedback.
           They're looking for comments by the end of the year.
   jdaggett: Is there a list of changes?
   florianr: Agreed, it's a long document.
   [several]: No clue what the changes are.
   jdaggett: I sent a message to Richard asking for that.
   kojiishi: I talked to Richard and not sure how that went.
   plinss: Perhaps reply online?
   szilles: Even a diff against the old one, since it's structured the same.

Radial Gradient Readability
---------------------------

   <fantasai> http://wiki.csswg.org/ideas/radial-gradient-readability
   fantasai: At TPAC Tab and I decided to investigate the issue of making
             radial gradient syntax more readable, and more extnesible as
             a side-effect.
   fantasai: We worked with other WG members to come up with a syntax which
             we posted to the blog, per our action item.
   fantasai: We got some feedback, it was somewhat mixed.
   fantasai: One of the things we noted was that the proposed syntax used
             the "to" keyword to distinguish the size from the position,
             but that seemed confusing/awkward to people.
   fantasai: So we tweaked the proposed syntax a bit to remove that.
             The new version is up on the wiki.
   fantasai: It's simpler than before.
   fantasai: The only thing needed is to distinguish the size from the
              position, but only one of them needs a special marker to
              resolve the parsing/reading ambiguity.
   fantasai: So the proposal is
               radial-gradient( [<shape> || <size> ] [at <position>]?, <color-stops> )
   fantasai: In the old syntax, you couldn't specify *just* an explicit size,
             because of the parsing ambiguity.  Now everything is optional.
             It's also clearer from the keyword that the values after "at"
             are a position.
   fantasai: An example would be "radial-gradient(5em circle at top left, ...)"
   jdaggett: You just put this proposal on the wiki today?
   fantasai: I put the latest version up yesterday, and rearranged the text
             today.

   florianr: The polls were inconclusive.  I support the readability initiative,
             but if it's not a big change, I'm not sure it's worthwhile, given
             the cost of syntax changing.
   howcome: I have a comment in general on replacing commas with keywords,
            such as "as" in attr().  I don't think it's worthwhile if we
            already have something working.  But I don't have a comment on
            gradients specifically.
   kimberly: I think the old syntax is only really useful with generating
             tools; it's too hard to write by hand.  The newer syntax can
             actually be remembered.
   florianr: I agree that it's more readable, but I'm not convinced it's
             particular more rememberable to be more writeable.
   sylvaing: Readability isn't just reading a stylesheet, it's also
             "does it make sense?".  If you see the gradient and some
             possible forms for it, can you pick the right one?

   glazou: We already have four syntaxes in the wild.  This will be a fifth
           one.  Will impls drop the old ones rapidly?
   glazou: For editting tools, this will be hell.
   smfr: Webkit won't change its prefixed syntax.
   sylvaing: And MS might even keep its prefixed one around for a while,
             since it's compatible with existing content.
   divya: [didn't capture it well]
   dbaron: I heard people comparing it to "the old syntax", but there's not
           one single old syntax.
   dbaron: I think the stuff that led to this change was several feature
           additions, and if we keep the "old syntax", we should reverse
           those feature changes as well.
   Tab: that's the explicit sizing

   plinss: There's been discussion of prefixes around.  The *entire reason*
           we have prefixes is so we don't have to worry about legacy content
           here.  So I'm not going to accept any arguments about not changing
           something because there is prefixed content.
   sylvaing: There is a *lot* of content out there already in a particular
             syntax.
   dbaron: I don't think relevant topics should be ruled out-of-order.
   plinss clarifies that the issue of currently-prefixed content being deployed
     is irrelevant, not that there isn't any concern about legacy here.

   Bert:  Would it help to pull the <shape> out of the parentheses and put it
          in the function name? radial-gradient(...) vs circle-gradient(...).
   TabAtkins: The shape is the *least* confusing part of the syntax.  Pulling it out wouldn't actually help.

   fantasai: This isn't just about radial gradients, or just about
             *today's* radial gradients.  This "more readable" or "more CSS-y"
             syntax also lets us expand this more easily in the future,
             such as adding in the features present in the original webkit
             gradients that we couldn't figure out a sane syntax for.
   fantasai: This also applies for more than radial gradients.  The attr()
             function is an example.  It originally took only one argument.
             Now it takes 3.  Perhaps it will take 4 in future (a selector
             for which children to take the attr from?).  As more args get
             added, it becomes more confusing and less extensible even at
             a parsing level.
   fantasai: What we're trying to do here is to take the CSS value syntax
             and the fundamental properties we use to develop that, and
             move that into functions as well, since we seem to have a
             good handle on extensibility in normal properties.
   fantasai: If we stick with comma-separated, this limits our ability to
             extend not only radial gradients, but also other functions in
             the future.
   howcome: The current syntax still uses commas, though, right?
   fantasai: Yes, but in the traditional CSS meaning, separating a list of
             similar values.
   florianr: I'm receptive to fantasai's argument regarding extensibility.
             I have nothing against it.
   florianr: So for the sake of extensibility, I'm rather in favor of this
             wiki proposal.
   florianr: For readability, I'm less convinced in this particular case.
   florianr: Regarding prefixing, I agree we shouldn't consider it forbidden
             to change prefixed things.  But we also shouldn't pretend the
             cost is zero.

   glazou: Agree, and clarify what I said earlier.  I said it's hell for
           editors, but [something I missed].
   glazou: smfr said that webkit won't drop its prefix, so what will you do,
           use a second prefix?
   glazou: Unfortunately, because this is so successful, it has left the
           field of "experimental feature".
   fantasai: No, webkit is not going to use a second prefix.  They'll switch
             to the new syntax when they drop prefixes.
   <sylvaing> if I'm hearing this right, it sounds like prefixes are meant
              to enable us to fix success
   * tantek thinks there will be an overlap time when both prefixed and
            unprefixed versions are implemented.
   fantasai: So there will be no new prefixed versions.  They'll just
             implement the new syntax, unprefixed.
   glazou: Is that the case for everyone?
   fantasai: For Moz, yes.
   sylvaing: For MS, yes.
   florianr: Opera hasn't made a decision, but will likely do the same.
   plinss: Prefixes become more painful the longer we keep them around.
           So the best solution to the entire prefix mess is for us to do
           our job and move things quickly.
   * tantek agrees with Peter.
   fantasai: So in that vein, Tab and I propose to resolve on this syntax
             and publish a WD.
   jdaggett: I want to reiterate that this syntax was just put up on the wiki
             yesterday?
   TabAtkins: Yes, but it's identical to the old syntax except for the removal
              of "to", because the blog post comments pretty consistently
              found it confusing.
   <divya> agreed with fantasai for new syntax
   <divya> agreed
   plinss: There are some general objections, but nothing specific to this.
           I hear general consensus.
   RESOLVED: Accept the new gradient syntax on the wiki.
   RESOLVED: Publish a new WD of Image Values.

CSS3 Lists
----------
ScribeNick: fantasai

   TabAtkins: I've been resolving issues or logging them on CSS3 Lists
   TabAtkins: If ppl who have issues want to bring them up, bring them up.
              I'll respond; not leading right now.
   howcome: I reviewed this over several months now, and I do think it has
            basically the toolkit it's offering authors is good.
   howcome: They can create their own counter styles, and use them as if
            they were native to CSS.
   howcome: I think Tab's done a great job of expressing commonly expressed
            list types
   howcome: The draft has 2 parts I don't think fit in there.
   howcome: First is pre-defined counter styles
   howcome: They may or may not be correct
   howcome: They may or not be used.
   howcome: I believe most will not be used
   howcome: And there may or may not be thousands of other list styles we
            should have in there.
   howcome: I propose for now that we don't do pre-defined counter styles
   howcome: So that's for Chapter 10
   howcome: We can keep it in an informative appendix, or have W3C host a
            stylesheet authors could @import
   jdaggett: I think that's a really good idea.
   jdaggett: I like that idea because it allows for shared usage, allows ...
             implementations
   jdaggett: Also makes it so the definitions are malleable
   jdaggett: There's a lot less burden to adding things.
   * scribe can't hear
   jdaggett: ... haven't totally verified the correctness of
   florianr: I think there was a clear benefit to coming up with all these
             styles initially, to ensure the generic mechanism can represent
             them all
   florianr: But I agree that it's overhead to verify that they're right,
             to implement, to test, etc.
   florianr: For not much benefit, since they can be written in a stylesheet
   florianr: I would keep them as an example of how to do it
   glazou: Hosting the stylesheet at W3C will generate a lot of traffic,
           and W3C pays for that.
   glazou: Validator for instance already generates a lot of traffic.
   glazou: it's very expensive
   howcome: We host the Core Stylesheets, and bandwidth was more expensive then.
   * fantasai notes that almost nobody uses the Core Stylesheets
   jdaggett: Requiring it means we have to verify that it's right.
   TabAtkins: Proposal: we take Chapter 10, maybe 11 etc, put them into a
              separate spec
   TabAtkins: They could remain informative, or be normative. Either way the
              status of the predefined styles won't hinder or affect the
              status of the overall Lists spec
   jdaggett: I would be fine moving these out to a different spec
   jdaggett: I think the proposal we were talking about would be better here [...]
   jdaggett: This is where we're defining the counter styles
   TabAtkins: The problem with keeping them here is that it's harder to rev
              the entire Lists spec than to rev a separate Lists document.
   glazou: I have compromise. There's a tool we never use: W3C Note
   glazou: They are much simpler than specs, almost informative.
   glazou: We could release somethng there, it's visible and usable
   <dbaron> Today that would be called a "Working Group Note", I think.
   glazou: Maybe not 100% correct, but if you find a mistake, please help us.
   <dbaron> Also, we should keep the CSS2 styles in the spec.
   florianr: But it would be just informative for authors, not asking UA
             styles to implement them.
   howcome: I think we could make rapid progress on Lists if this issue goes away
   dbaron: Which parts of Chapter 11 are you removing?
   <tantek> CSS2.1
   TabAtkins: Everything except the CSS2.1 styles
   TabAtkins: But parts about the longhand chinese styles would go with
              Chapter 10, and Chapter 12 as well
   dbaron: 2.1 had one of the CJK styles, and I think we should keep the
           stuff that was in 2.1 in CSS3 Lists
   howcome: I agree, but Tab can express it up to 1000 with @counter-style
   florianr: I'm not convinced the predefined styles need to go with the new
             things.
   jdaggett: Why don't we resolve to take them out, and then figure out how
             to parcel them out at a later point
   dbaron: I'd still like to know what we're taking out and what we're keeping
   TabAtkins: I would keep the ones defined in 2.1, defining them in
              @counter-style is possible and easy
   TabAtkins lists styles in 2.1
   TabAtkins notes they're very badly specified in 2.1
   <jdaggett> we're talking about moving out section 10, 11, 12 but keeping
              things from 2.1
   TabAtkins: In 2.0 we had ideographic, not in 2.1
   dbaron: The stuff in 2.0 is widely implemented, we should keep it.
   fantasai: It's also required for EPUB
   howcome: I don't think we should do that, we took them out of 2.1
   howcome: We found a better way for ppl to create these types themselves.
   dbaron: *Can* they create them themselves?
   [...]
   <tantek> hence keep stuff that was in 2.1 rather than 2.0
   TabAtkins: The chinese-informal styles can be expressed using hacks around
              fallback. I put an example of how to do it
   TabAtkins: I can do it up to 999 by creating 11 counter styles
   TabAtkins: Might be able to drop it to 3 styles
   TabAtkins: I could copy-paste it, wouldn't expect an average author to do.
   florianr: Can we say we remove everything except what was in 2.1 and maybe
             in addition to that what was in 2.0 and is also interoperably
             implemented?
   * fantasai still hasn't gotten to speak :(
   <glazou> howcome: http://weasyprint.org/
   fantasai: Why are we making millions of authors copy-paste some arcane magic
             incantation they don't understand in order to get their list numbered
             correctly just because their numbering didn't make it into CSS2.1?
             To avoid carrying around maybe 1KB extra data in the UA?
   <tantek> millions of authors? are there that many that want/need the extra
            features?
   howcome: They can just @import the styles
   fantasai: nobody's going to @import the styles. They already use data URLs
             for images to avoid the extra network traffic.
   [...]
   * tantek agrees with Håkon, fancy list-styles are similar to fancy fonts.
   <glazou> tantek: I disagree, numbering is part of culture, it should just work
   <tantek> glazou - that's a reasonable distinction.
   howcome: The problem we'll have is we're surely going to find errors in
            that list, and if we hard-code it into the UA we're going to be
            stuck with those errors.
   florianr: People will rely on it being wrong
   fantasai: Nobody will rely on it being wrong. They'll just rely on it being
             correct and occasionally be disappointed.
   [various people start to drop off the call as it's over time]

   <jdaggett> the problem with predefined lists is that
   <jdaggett> 1) we have to assure the list is correct
   <jdaggett> 2) we need to decide the priority
   <jdaggett> and that's hard because stylistic variations occur
   <jdaggett> which is more important?

   [more discussion about splitting the spec]
   TabAtkins: I can take either way.
   <fantasai> FWIW, I have no objection to pulling them into a separate spec
   <fantasai> just to foisting the entire responsibility onto the authors
   howcome: If we put it in a new spec, it shouldn't be necessarily predefined
   <dbaron> I thought this was the main thing in the lists spec.
   <tantek> I'm in favor of whatever helps the editor move more quickly.
   <dbaron> I tend towards agreeing with fantasai; I also need to leave.
   plinss: I'm hearing no objection to splitting out the predefined counter
           styles into a separate spec
   howcome: this resolves a bunch of my objections
   RESOLVED: split predefined counter styles into a separate spec

Meeting closed.

Received on Wednesday, 30 November 2011 23:44:50 UTC