[CSSWG] MInutes Seattle F2F Mon 2014-01-27 AM II: Syntax, Shapes, Serialization

Syntax
------

   - Discussed feedback from i18n, particularly request to change @charset
     parsing; failed to record a resolution, but there seemed to be consensus
     on not changing from 2.1.

   - Discussed limiting @charset handling to first 1024 bytes; nobody has a
     problem with this. Also discussed white space within labels, since that's
     the only thing that could result in such a case.

   - Discussed shifting environment encoding definitions from Syntax to
     Cascade.

Shapes and Serialization
------------------------

   - Discussed serialization rules for <basic-shape>
   - RESOLVED: Shapes to LC pending fantasai's review due tomorrow morning

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

Syntax
------
Scribe: fantasai

   SimonSapin: Editorial feedback from i18n
   SimonSapin: some discussion about changing the @charset behavior
   SimonSapin: Tab and I agree it's not a good idea
   TabAtkins: Henri also agrees it's not a good idea
   plinss: What is the proposed changed?
   TabAtkins: That actual CSS syntax would trigger behavior. Currently only
              very restricted set
   fantasai: How different from CSS2.1?
   florian: Not different, same restrictions
   plinss: I agree with that
   fantasai: me, too. Don't see a reason to change it from what was in 2.1
   <SimonSapin> Starts here: http://lists.w3.org/Archives/Public/www-style/2014Jan/0060.html
   florian: Argument for was that people would not understand the restricted
            subset, might do something not quite right
   florian: But we don't want people to use this anyway, want only for
            legacy documents. Everything else should use UTF-8
   fantasai: Don't see any reason not to use UTF-8 for CSS files, really. :)

   SimonSapin: Did make one change based on Henri's feedback
   SimonSapin: Since we trip white space in encoding name between quotes
   SimonSapin: The series of @charset is unbounded, which is bad because
               want to set encoding asap
   SimonSapin: In HTML, encoding has to be within first 1024 bytes
   TabAtkins: This is only relevant if you want to put tons of spaces
              between first quote and charset name.
   TabAtkins: Which nobody will do.
   plinss: Why do we trim white space there anyway?
   TabAtkins: encoding spec says so
   TabAtkins: ... waitaminute. We don't currently allow spaces there.
   [discussion of fixing this]
   dbaron: If implementations don't allow spaces, then let's not allow spaces
   dbaron: If nobody's checked, let's check first.

   fantasai: Do you have a DoC prepared?
   No.

   SimonSapin: We introduced concept of environment encoding
   SimonSapin: Idea is that specs that use CSS should define that
   SimonSapin: Meantime, I defined for HTML, @import, xml, etc.
   SimonSapin: HTML one has moved to HTML spec. Want to move @important
               one to Cascade
   SimonSapin: Can we move things between CR?
   fantasai: I think this particular case it's OK, because doesn't affect
             interpretation of either spec in isolation or both together.
   glazou: Adding technical info to a CR is problematic
   fantasai: But in this case it doesn't invalidate anyone's review

   dbaron: One other question, this "environment encoding" concept. Is
           there something that encourages future consumers to just set
           it to UTF-8?
   dbaron: I think this concept only exists because of legacy
   dbaron: If that's the case, it's good for the spec to say that, so
           that people who don't have a legacy problem don't copy this.
   dbaron: And give some advice on what the spec should say
   SimonSapin: Already say that if environment encoding is not explicitly
               defined, it's UTF-8.
   SimonSapin: Could add that new things should not define anything else
   glazou: So, Chris says it's ok if we can make a good argument for the
           move if it's not tied in with other things.
   SimonSapin: no problem
   ACTION SimonSapin prepare disposition of comments, complete Syntax
                     edits for tomorrow
   <trackbot> Created ACTION-605

   <TabAtkins> Okay, confirmed, Chrome at least allows plenty of whitespace
               in the label name.
   <Ms2ger> boo
   <fantasai> TabAtkins, check another implementation?
   <TabAtkins> So yeah, I'll change Syntax back to allowing "anything but
               0x22" there.
   <TabAtkins> fantasai, yeah, let me download FF.
   <TabAtkins> Yes, FF also allows lots of spaces in encoding labels.

glazou: Suggest Shapes for 20min, then flexbox
* fantasai is skeptical of flexbox before lunch

Shapes
------

   astearns: We had LC for shapes
   astearns: comments ended up changing computed value of shape-outside
   astearns: I think the way shape functions are serialized should be
             defined better
   astearns: computed value of position doesn't really correspond to syntax
             that go into the declared value
   <astearns> http://lists.w3.org/Archives/Public/www-style/2014Jan/0277.html
   astearns: so I set up a list of rules that I've linked to here
   astearns: for how to serialize position
   astearns: It's a set of rules, rather than algo
   astearns: think that's better
   astearns: if people are good with this, then last thing before next LC
             for shapes
   krit: serialization is used for getComputedStyle as well as .style

   dbaron: This is about the <position> syntax that takes 2/4 values?
   dbaron: One of my longstanding prefs wrt serialization is that when we
           expand the syntax of CSS, we should prefer serializing to the
           more longstanding syntax than the new syntax
   dbaron: because if you want to round-trip into a context that gets
           consumed by other tools, want it to be most compatible possible
   astearns: Current rules prefer keywords to percentages/lengths
   astearns: if you introduce new keywords... might not end up as you want
   fantasai: Would suggest we prefer percentages, probably easier for OM people

   astearns: case is e.g. calc(100% - 10px), will be serialized as right 10px
   glazou: I prefer that, author is more likely to have entered it that way
   peterl: one thing that concerns me about these serialization things is
           that we're encouraging the UA to not preserve the input
   plinss: I'm concerned that if you serialize and round-trip exactly what
           came in, should that ever be considered wrong/
   [various on not preserving input string]

   dbaron: We've been adding more preservation of author input, for our own
           developer tools.
   dbaron: In many cases, we don't expose that to the web
   dbaron: mostly it's for color syntaxes atm
   florian: I think we can't require preservation everywhere
   plinss: ...
   florian: At least some implementations will not preserve the input
   florian: Also, it's valuable that everyone has the same output
   florian: Since not everyone preserves the input ..
   astearns: ...
   astearns: If you say left top, other person says top left, would be nice
             to have consistent serialization

   florian: Leaning towards dbaron's approach, for Web content normalize
            more, but for developer tools expose more things
   plinss: I accept that there are utilities for having a normalized
           serialization
   plinss: for manipulation via script (which we should avoid by having a
           better OM)
   plinss: But I'd like to avoid having 2 output paths for serialization
   plinss: Asking for normalized version, and other asking for getting
           absolutely / partially preserved / normalized value /whatever

   krit: I think it's important to have a constant output for same input
         across all browsers. This is the first thing we should agree on,
         because not the case today

   SteveZ: I think you need to take the audience into consideration
   SteveZ: JS writers would prefer canonicalized output
   SteveZ: Another is developers, who would like to see what they wrote,
           because that's what they're trying to debug
   SteveZ: We're not trying to solve the developer recovering their input
   SteveZ: is what I think plinss was saying

   fantasai: I think that we should focus the existing OM on the first
             problem (JS writer)
   fantasai: Create a different OM to solve the second problem, that's
             designed to solve that second problem, and simply won't be
             implemented if impl won't preserve the info
   florian: [says mostly the same thing]
   krit: Adding new values, not very compatible.

   glazou: We're being too broad, suggest we refocus on Shapes
   astearns: So canonical form for shape serialization is the problem
   astearns: so question is, is the email post there what we want
   dbaron: ...
   astearns: Think the text could be used for multi-component values elsewhere
   dbaron: Think we should keep it with Shapes, might want to make calls
           on keyword vs. length based on which is older in other cases
   RESOLVED: Shapes to LC pending fantasai's review due tomorrow morning

Flexbox
-------
Scribe: krit

   <fantasai> http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
   TabAtkins: going to issue list
   fantasai: did we solve 23?
   fantasai: looks open
   glazou: not closed
   <fantasai> http://dev.w3.org/csswg/css-flexbox/#changes
   TabAtkins: nothing to discuss
   plinss: do we want to resolve on something?
   fantasai: possibly later today

Received on Thursday, 30 January 2014 13:41:50 UTC