- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jan 2014 01:46:15 -0800
- To: "www-style@w3.org" <www-style@w3.org>
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