- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 05 Aug 2009 11:06:27 -0700
- To: www-style@w3.org
Summary:
- RESOLVED: Accepted proposal for item 1 of agenda [Administrative]
http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0042.html
- RESOLVED: Proposal accepted for CSS2.1 Issue 129 (Backup in Tokenizer)
http://wiki.csswg.org/spec/css2.1#issue-129
- RESOLVED: For CSS2.1 Issue 30, remove 'default' and 'initial' from
example list, remove 'e.g.', and add a sentence that says 'initial'
and 'default' are reserved as keywords for future use and must also
be quoted when used as font names.
http://wiki.csswg.org/spec/css2.1#issue-130
- RESOLVED: For CSS2.1 Issue 133, say that 'height' is undefined for
row groups.
http://wiki.csswg.org/spec/css2.1#issue-133
- RESOLVED: CSS2.1 Issue 134 (percentage offsets for relpos in
auto-height containers) closed No Change.
http://wiki.csswg.org/spec/css2.1#issue-134
====== Full minutes below ======
Present:
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Sylvain Galineau
Daniel Glazman
Dave Hyatt
Brad Kemper
Chris Lilley
Peter Linss
Alex Mogilevsky
David Singer
Øyvind Stenhaug (Opera Software) via IRC
<RRSAgent> logging to http://www.w3.org/2009/08/05-CSS-irc
ScribeNick: fantasai
Agenda: http://lists.w3.org/Archives/Member/w3c-css-wg/2009JulSep/0042.html
Administrative
--------------
RESOLVED: Proposal accepted for item 1 of agenda.
CSS2.1 Issues
-------------
<glazou> http://wiki.csswg.org/spec/css2.1#issue-120
<dbaron> this is issue 8 in the email
fantasai: I'm not suggesting we solve the issue on the call, but that
we decide how to approach it
fantasai: whether we want to audit the entire spec to make sure the
explicit lists are everywhere they need to be and in sync
fantasai: or whether we want to remove explicit lists and define
special display types in terms of blocks
Bert: I think it's easier to have explicit lists, make sure we think
about where the exceptions are
Daniel: I think it's easier to have just a sentence saying
table-captions are like blocks, much fewer edits
dbaron: Need to be careful, it's like a block inside but not outside
fantasai: There are many places in the spec that mention blocks in
passing, we can't have explicit lists everywhere
fantasai: Maybe at the top of the section, "blocks in these cases
means ..."
dbaron and Bert discuss lineboxes and baselines
fantasai: It's not as simple as a sentence fix here. Basically we
need to audit the spec, because we have a lot of this
kind of problem
fantasai: Question here is which approach should the person auditing
the spec take
ChrisL asks what the proposals are
fantasai: First is to audit the spec and make sure there explicit
lists whereever we talk about blocks, and make sure
those lists are in sync
<dbaron> I think we should leave it to the editor to propose an
appropriate fix.
<hyatt> same. up to the editor imo.
<dbaron> "letting the editor decide" == doesn't need to make the
decision while we wait
fantasai: Second is to audit the spec to just talk about blocks,
and then in the definition for table-caption etc. define
those to behave exactly like blocks except ... and list
the exceptions
Several in favor of second option, Bert in favor of first (?),
dbaron and hyatt want editor to decide
dbaron: I think the solution here is to reword the sentence to
define a block's baseline
dbaron: So maybe Bert's suggestion to rename to line box's baseline
is good
<dbaron> (rename and make it a definition)
ACTION: Bert and fantasai solve this issue
<glazou> http://wiki.csswg.org/spec/css2.1#issue-129
dbaron explains the issue
The way url() is defined in the tokenizer, if something starts to
match url() but doesn't end
Then the tokenizer has to go back and retokenize as something else,
which is not what anyone does.
dbaron: And we have prose that contradicts this, at least for the
URL case
<dbaron> I think
Bert doesn't want to change the grammar
Others don't want to change implementations
dbaron: What the spec says is that given
<style>
/*
p { color: red; }
h1 { color: red; }
</style>
implementations should treat /* as an invalid selector
<Bert> Currently, "/*" is two DELIMs, we can still use it for
something. After Zack's change, "/*" becomes reserved.
<dbaron> Bert, we can't use it for something, since it starts a comment
<dbaron> Bert, if we used it, we wouldn't be able to have comments
anywhere later in the style sheet
Peter: I think it's extremely dangerous to use /* as a delimiter for
anything other than comments
Bert: The grammar is the most stable part of the spec, we should not
touch that
ChrisL: If the grammar is stable, but a portion of it has not been
implemented and nobody wants to implement it, then it may be
stable but it's wrong
dbaron: We also have prose that contradicts the grammar very clearly
<dbaron> "User agents must close all open constructs (for example:
blocks, parentheses, brackets, rules, strings, and comments)
at the end of the style sheet. For example: "
fantasai: Prose trumps grammar. I think we should fix the grammar.
<plinss> http://lists.w3.org/Archives/Public/www-style/2009Jun/att-0164/unterm-css.html
* fantasai thinks that's a very clever testcase
<dbaron> I think we've already fixed Firefox on the trunk
Firefox backtracks the middle two, but not the first and the last
Sylvain: We backtrack the first and last, but not the middle two
<hyatt> lol
* ChrisL sees the basis for another conditional hack
<plinss> Safari does not backtrack for any
<sgalineau> IE7 did not backtrack anywhere
Opera?
<oyvinds> 9.64 backtracks the last three, but my internal build none
Daniel: We should fix this
<dbaron> I guess I have a fix to fix the backtracking in my own tree
that's not checked in yet.
<dbaron> I'll have to figure out which patch that is. :-)
Brad: No sense in keeping it inconsistent among UAs
<sgalineau> Opera 10 Beta is same as 9.64
Daniel: I'm happy with the proposal
Bert doesn't have a problem with the proposal itself, just doesn't
want to change the grammar
Straw Poll to accept proposal
Daniel: yes
Bert: No, but won't block
Brad: fix it, don't care how
Sylvain: change it
<hyatt> yup
Alex, Arron: change
fantasai: in favor
<hyatt> in favor yes
dbaron: in favor
Peter: yes
<ChrisL> fix as proposed
<dbaron> Ah, yes, I've had this patch to rewrite url() parsing in my
tree for ages that I should really do something about...
dsinger: whatever hyatt says :)
Daniel: Vast majority for yes.
RESOLVED: Proposal accepted for CSS 2.1 issue 129
<glazou> http://wiki.csswg.org/spec/css2.1#issue-130
dbaron: I think this is as intended
fantasai: No, it's a problem. The example lists keywords that don't
exist. So the example is inconsistent with the normative prose
Sylvain: We're just reserving them for future use
fantasai: But if we want to do that, we have to do it normatively, not
in an example
Bert: We edited the spec to include those keywords because we noticed
they're defined in later specs, but not listed
dbaron: I don't think it should be an example, it should just be that
list (because for font-family, it's exhaustive)
* dsinger why don't we recommend quoting font names?
* dsinger like always
* fantasai too late
fantasai asks about font shorthand
<dbaron> font shorthand requires size and family, and only lh and
family after size, because the syntax for family is so broad
ChrisL: Making the list normative is good, but should probably also
call those keywords out explicitly
<fantasai> I suggest removing those keywords from the example list,
removing 'e.g.', and adding a sentence that says "'initial'
and 'default' are reserved as keywords for future use and
must also be quoted"
RESOLVED: Proposal accepted with "when used as font names" appended
* dsinger can we reserve a form that cannot possibly be (part of) a
font-name, for future keywords?
<dsinger> and if a font with that name is desired, they must be
quoted. yes.
* Bert to dsinger: we would probably have to use a functional notation
foo() in that case...
<glazou> http://wiki.csswg.org/spec/css2.1#issue-133
dbaron: this is only one out of many issues for table heights/widths
and we wanted to postpone them
* glazou already needed aspirin before the call and the topics
discussed did not help :-)
fantasai: If it's not defined, we should say it's not defined
fantasai: we don't say that row-group heights are undefined, just
tables and rows
Bert: Add a sentence in 17.5.3 saying that height is undefined for
row groups
RESOLVED: Accepted, Bert to word and edit
<glazou> http://wiki.csswg.org/spec/css2.1#issue-134
Brad: Is there any reason why we can't use percentage offsets on relpos
children of an auto-height block?
dbaron: It's probably ok, though I'm a little concerned if there's
overflow set... though I guess it's not a problem even then,
just weird behavior
Brad: Is it going to break anything if people implement it this way?
fantasai: Apparently IE6 did it, so probably not
Brad: unless they're doing two things and assuming IE does it but
others don't
Bert: I don't see why it can't work
<hyatt> seems fine
RESOLVED: Close no change
* oyvinds notes that hyatt mentioned a cyclic situation related to
showing of scrollbars in that thread, might need to specify what
happens at least?
Meeting closed.
Received on Wednesday, 5 August 2009 19:07:05 UTC