W3C home > Mailing lists > Public > www-style@w3.org > September 2013

[CSSWG] Minutes Telecon 2013-09-04

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 04 Sep 2013 16:33:15 -0700
Message-ID: <5227C33B.9010408@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:
   - RESOLVED: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more
               restrictive in what it takes, per Tab's proposal.
               (No changes to Fonts.)
   - RESOLVED: Fonts Level 3 to CR
   - RESOLVED: Cascade L3 to CR
   - RESOLVED: TCY doesn't disable font-variant: full-width. Revisit if
               fonts start to become popular that would benefit from this
               extra interaction.
   - Discussed improving gradient stop color fixup rules for better transitions
       http://lists.w3.org/Archives/Public/www-style/2013Aug/0296.html
   - Discussed handling Media Queries 3 errata

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

Present:
   Glenn Adams
   Rossen Atanassov
   Tab Atkins (late)
   David Baron
   Bert Bos
   Dave Cramer (Hachette)
   John Daggett
   Jason Erenkrantz
   Elika Etemad
   Simon Fraser
   Daniel Glazman
   Rebecca Hauck
   Dael Jackson
   Brian Kardell
   Brad Kemper (late)
   Philippe Le Hégaret
   Chris Lilley
   Peter Linss
   Edward O'Connor
   Florian Rivoal
   Anton Prowse
   Simon Sapin
   Dirk Schulze
   Alan Stearns
   Leif Arne Storset
   Lea Verou

<RRSAgent> logging to http://www.w3.org/2013/09/04-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Sep/0061.html
Scribe: fantasai

plinss: Any additions to the agenda?

CSS3 Fonts
----------

   Topic: Unicode-Range Parsing
   SimonSapin: In the Syntax spec, some changes from CSS2.1
   SimonSapin: Tried to match Fonts spec, do parsing/normalization of
               unicode-range in tokenizer
   SimonSapin: But fonts spec changed
   SimonSapin: So want to revert changes, and do what CSS2.1 does for
               UNICODE-RANGE
   SimonSapin: Tab prefers to do parsing in Syntax, have UNICODE-RANGE
               return pair of integers rather than string

   fantasai: Well, I know we have implementations of the 2.1 tokenization
   SimonSapin: They're not testable
   dbaron: Some cases can be tested via obscure counter-reset/increment
           declarations
   dbaron: But don't think it's worth worrying about
   <dbaron> http://dbaron.org/css/test/2013/urange-token shows detecting
            UNICODE-RANGE with counter-increment

   dbaron: 2 questions - what is the desired behavior, and which spec?
   dbaron: So first, what's the desired behavior
   jdaggett: Desired behavior in terms of ... ?
   dbaron: What are the differences in behavior that we're discussing?
   SimonSapin: Fonts spec changed details of UNICODE-RANGE parsing in last WD
   SimonSapin: e.g. ranges beyond Unicode used to be clipped, but are
               now invalid
   jdaggett: How does that impact Syntax?
   SimonSapin: Because Syntax defines tokenization
   SimonSapin: Syntax used to do clipping in the tokenizer

   jdaggett: Only opposition is Tab, and he's not on the call atm
   SimonSapin: What came out of ML discussion with Tab, was compromise
   SimonSapin: Tokenizer would have pair of integers
   SimonSapin: Leave to fonts what to do with integers, depending on whether
               increasing/decreasing etc.
   SimonSapin: Just two integers given back
   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Sep/0019.html

   jdaggett: impact of what we're talking about is whether parser takes
             something as UNICODE-RANGE or not
   jdaggett: Cases where author will want to use that syntax somewhere
             else is almost never
   SimonSapin: Proposal is to remove section in Syntax that defines
               unicode-range range restrictions
   SimonSapin: ie. removing this section:
      https://dvcs.w3.org/hg/csswg/raw-file/aa1b58939f73/css-syntax/Overview.html#set-the-unicode-ranges-range
   * fantasai is biased towards Simon's position over Tab's

   plinss: Does this impact Fonts, which is going ot CR?
   TabAtkins: Could remove stuff from Fonts spec, because covered by Syntax
   fantasai: Don't think we should be removing anything from Fonts spec,
             Syntax is kindof early stages, would like Fonts to be complete
             as of now.
   jdaggett agrees
   ChrisL: Don't want Fonts spec to change
   ChrisL: Given it's going to CR

   TabAtkins: UNICODE-RANGE in CSS2.1 accepts syntax that will never be
              needed/used
   TabAtkins: Would like those cases to not parse as UNICODE-RANGE.
   TabAtkins: But fine with range-restrictions staying in Fonts spec
   ...
   TabAtkins: I would like to kill U+1?3
   TabAtkins: Want to make that invalid at the tokenization level
   <SimonSapin> examples of bad syntax: U+1?3, U+1?-30

   <fantasai> I think the second one is already invalid in 2.1
   <SimonSapin> fantasai, it is valid in 2.1
   <SimonSapin> 2.1’s definition: u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?

   plinss: Any other comments?
   fantasai: No changes to Fonts spec, right?
   Right.
   fantasai: So only question is whether UNICODE-RANGE token uses the 2.1
             syntax or Syntax syntax
   jdaggett: [talks about splitting definitions across specs]
   fantasai: If we're changing definition of UNICODE-RANGE, we need to
             errata 2.1
   fantasai: Can't have two different definitions depending which spec
             you read

   plinss: Anyone objecting to Tab's change?
   TabAtkins: Simon's proposal was to accept 2.1 syntax, and have Font's
              processing make things invalid.
   SimonSapin: I'm fine with Tab's proposal as well
   fantasai: Only thing that bothers me is that we have implementations
             on the 2.1 tokenization
   fantasai: They'd have to go back and change
   TabAtkins: It's (for the most part) author-undetectable
   Bert: I'd like to see the regex first, if that's ok
   TabAtkins: Ok, I will send to ML
   RESOLVED: UNICODE-RANGE token changed (in Syntax & CSS2.1) to be more
             restrictive in what it takes, per Tab's proposal.
             No changes to Fonts.
   <SimonSapin> Bert, TabAtkins: regexp equivalent of the proposed change
                to unicode-range:
   u\+[?]{1,6}
   u\+[0-9a-f]{1}[?]{0,5}
   u\+[0-9a-f]{2}[?]{0,4}
   u\+[0-9a-f]{3}[?]{0,3}
   u\+[0-9a-f]{4}[?]{0,2}
   u\+[0-9a-f]{5}[?]{0,1}
   u\+[0-9a-f]{6}
   u\+[0-9a-f]{1,6}-[0-9a-f]{1,6}
   <TabAtkins> SimonSapin, Bert: Yeah, I was drawing up a slightly different
               one, but it's functionally identical, and yours is somewhat
               clearer.

   <jdaggett> http://dev.w3.org/csswg/css-fonts/doc-20130711-LCWD.html
   plinss: Fonts to CR?
   jdaggett: There was one outstanding issue on 'ordinals', but that got
             cleared up over ML with examples/pics.
   jdaggett: Question is, do we need another LC or go to CR?
   jdaggett: I don't think there's a huge impact on implementations from
             any of these changes.
   jdaggett: Most significant change is removing 'auto' value
   fantasai: I don't think we need to go through another LC, changes
             aren't very major.
   ChrisL: Spec is currently listing everything as major changes, most
           are minor
   ChrisL: But several are substantial [lists]
   ChrisL: Reorder feature precedence, 'auto', etc.
   ChrisL: All these need to be addressed, and argue that they are minor
   ChrisL: I'd rather not do another LC
   jdaggett: Auto value was never implemented
   jdaggett: Not part of CSS2 spec
   jdaggett: Only removing a single value, that was never implemented

   [process discussion]
   <dbaron> I think ChrisL was saying that we need to argue that the
            changes weren't substantive in order to go from LC to CR.
   <dbaron> (for minutes)
   <ChrisL> 
http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=cr-tr
   <ChrisL> quote "Some reasons for declining a transition request
   <ChrisL> The technical report has been substantively modified since
            the previous transition. In this case, the document is returned
            to the Working Group for further work."

   jdaggett: So I should revise Changes section to not list changes as major
   jdaggett: Could also add an "impact" statement, to describe what the
             impact is on implementations
   jdaggett: For most of these, no impact, because there aren't implementations

   [discussion of how to style DoC]
   [more discussion of handling DoC]
   ChrisL: I'm trying to be pre-emptively awkward here, to make the
           transition call go smoothly
   plinss: I get your point Chris, and but for this point, i don't think
           this is worth taking up group time
   plinss: I'd rather take up 10 min of transition call time than 10 min
           of CSSWG telecon time

   plinss: Any objections to CR?
   SteveZ: Sent email this morning on 'ordinal' issue
   SteveZ: I have no text that's there, just want to point out that there's
           an aspect of ordinals that is in the OT definition, that really
           no longer applies
   SteveZ: The original conception of 'ordinal' feature was that you could
           mark a paragraph, and it would ordinal everything that was number
           followed by letters
   SteveZ: Problem was that writing rules for all languages was troublessome
   SteveZ: So you need to apply  the feature around just the numbers
   SteveZ: as the example shows
   SteveZ: Might want to say that in the text
   jdaggett: Don't think it's necessary
   jdaggett: I can add to the sentence within the example, just to indicate
             that it's not applied to the paragraph
   SteveZ: That sounds good to me
   SteveZ: Just want a warning to not apply it to the whole paragraph

   jdaggett: Any objections to CR?
   fantasai: No, let's do it!
   <ChrisL> none at all
   RESOLVED: Fonts Level 3 to CR
   ACTION ChrisL Send transition request
   <trackbot> Created ACTION-576

CSS Cascade L3
--------------

   http://dev.w3.org/csswg/css-cascade/issues-lc-2013
   fantasai summarizes all the comments
   <glazou> go ahead!
   RESOLVED: Cascade L3 to CR

CSS Writing Modes L3
--------------------

   Topic: text-combine-horizontal and font features
   * fantasai sent email to jdaggett on this just now
   fantasai: [summarizes discussion]
     Since full-width glyphs don't compress well, we are trying to avoid
     using them in TCY (by transforming out from full-width codepoints, etc.).
     Currently the spec says that 'font-variant: full-width' is ignored
     for this reason. jdaggett says that there aren't any fonts that use
     different glyph shapes for 'font-variant: full-width', so nobody
     would use it in vertical text, so there's no need to have this
     feature interaction. I'm fine with that, as long as we're open to
     reconsidering if we end up with fonts that do use different glyphs
     for 'font-variant: full-width'.
   jdaggett: I'm fine with that

   SteveZ: Can I raise a related issue?
   jdaggett: Can you raise it on the list?
   plinss: Will it impact this discussion?
   SteveZ: Don't know
   SteveZ: When I contacted Adobe font people about compression issue,
           they basically said "don't do that"
   SteveZ: So I had a private conversation with Koji, who said "but we
           have to do that, because the WebKit based publication guide
           wants to be able to ensure that all their text fits within
           an em-square for body text"
   SteveZ: Issue I'm concerned about is making the default for text-combine
           do the compression
   SteveZ: Rather than have a property to turn it on
   SteveZ: Which would remove many of the cases that we seem to be stumbling
           over

   jdaggett: This issue is exactly what we discussed 1.5 years ago.
   jdaggett: We had a property to control it
   jdaggett: But seemed overkill to me
   jdaggett: Maybe post to the list, what you want
   jdaggett: We've added this property, and then took it out, and now
             you're leaning towards bringing it back

   SteveZ: What I want is not have the default be compression
   fantasai: reason default is compression for CSS and not for InDesign
             is that in InDesign author can see and tweak the result and
             will adjust it; in CSS author doesn't see it and doesn't
             know exactly where lines will break, etc.
   fantasai: It's very important for publishers not to have overlap.
             Can't manually check with CSS.  So better to force 1em
             compression so they can guarantee there's no conflict.

   jdaggett: I'd like to capture the resolution that for now we take out
             the automatic disabling of full-width variants
   fantasai: As long as we are ok to reopen if we wind up with fonts that
             would benefit, I'm ok with that.
   RESOLVED: TCY doesn't disable font-variant: full-width. Revisit if
             fonts start to become popular that would benefit from this
             extra interaction.

CSS Image Values L3
-------------------

   Swapping order of color stop fixup
   TabAtkins: Gradients require color stops to be in order
   TabAtkins: If not, push later ones to position of next position
   TabAtkins: Rules for fixup right now they work, but result in weirdness
              for animations.
   <smfr> http://lists.w3.org/Archives/Public/www-style/2013Aug/0296.html

   TabAtkins: Step 2-3 requires layout infos
   TabAtkins: Back when doing gradients, Shane suggested changing this
   TabAtkins: I think we shot this down because fatigued with gradient
              changes.
   TabAtkins: But should revisit
   TabAtkins: Small change
   TabAtkins: Rendering change is fairly minor
   TabAtkins: And not likely to be many cases affected
   TabAtkins: So suggest swapping order of steps, so that can transition
              gradients without requiring layout.

   Lea: Any specific examples that would change?
   <TabAtkins> http://dev.w3.org/csswg/css-images/#color-stop-syntax
   <TabAtkins> linear-gradient(red 100px, blue 0px, white, yellow 200px)
   <TabAtkins> currently, fixup moved the blue one first, then figures
               out the white position, so you get

   florian: If we do this, should go into L3
   krit: We don't order when we have transitions?
   krit: Asking, you asked to move the ordering step to the last possible
   krit: When you have transitions, you do not order the color stops
   TabAtkins: Correct
   TabAtkins: You position first/last stops and interpolate
   TabAtkins: Then at layout time do the stop fixup
   krit: Ok, I'm fine with this

   <TabAtkins> so currently, you end up with
               red 100px, blue 100px, white 150px, yellow 200px.
   <TabAtkins> With my change, you'd end up with
               red 100px, blue 0px, white 100px, yellow 200px
   <TabAtkins> and at layout, it'd be fixed up to
               red 100px, blue 100px, white 100px, yellow 200px.
   <TabAtkins> but you'd do transitions with the prior one

   Leif: Given implications of this, I think I'd like some time to review
   TabAtkins: Ok
   plinss: Come to back to this for F2F

MediaQueries 3 Errata
---------------------

   dbaron: There was a thread, someone pointed out obvious mistake in 2 places
   dbaron: Mistake is in REC errata
   florian: I've updated MQ4, asked plh to update errata
   plh: Haven't processed email yet, but should be done today
   florian: Ok, thanks!

   florian: As for folding them into MQ and publishing updated REC, we
            thought to wait awhile to do that.
   florian: Maybe we'll run into more issues
   florian: Maybe wait until end of year
   fantasai: Maybe aim for TPAC
   fantasai: Put it on TPAC agenda, assign any relevant action items then

plinss: F2F next week, please add your items to agenda so we can use
         time productively!
Meeting closed.
Received on Wednesday, 4 September 2013 23:33:44 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 September 2013 23:33:45 UTC