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

[CSSWG] Minutes and Resolutions Oslo F2F 2010 Monday: CSS2.1, CSSWG Charter, Viewport

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 31 Aug 2010 05:27:17 -0700
Message-ID: <4C7CF525.9070605@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Please start a new thread for replies, unless you are correcting the minutes.

CSS2.1 Issues

   ACTION Everyone: Review proposals for:
     121 http://lists.w3.org/Archives/Public/www-style/2010Aug/0411.html
     140 http://lists.w3.org/Archives/Public/www-style/2010Aug/0435.html
     158, 159 margin collapsing

   RESOLVED: Bert's proposal accepted for 129

   RESOLVED: Leave issue 144 officially undefined, add a note that it
             will be resolved in css3.

   RESOLVED: Proposal accepted for CSS2.1 Issue 172: caption width
             influences table width as if contained in a table-spanning cell.
             fantasai to tweak proposal as noted in minutes to be more clear

   Discussed CSS2.1 Issue 187 (bidi effects of atomic inline-level elements):
     agreed in principal with proposal but need clearer wording. [Tuesday]

   RESOLVED: Add a note about marker box stacking level for outside markers
             being undefined in 2.1 for CSS2.1 Issue 191.

   RESOLVED: For CSS2.1 Issue 192, accept change for first issue, accept
             s/further content/content after the float/ and s/it/that content/
             for the second issue, third issue is invalid.

   RESOLVED: Proposal accepted for CSS2.1 Issue 194

   RESOLVED: For CSS2.1 Issue 195, proposal accepted with "even if either
             side is empty" appended. [see minutes Tuesday]

   RESOLVED: For CSS2.1 Issue 196, fix range of identifiers to include
             NBSP and exclude the control characters immediately below it.

   RESOLVED: For CSS2.1 Issue 197, clarify spec that when 'clear' is applied
             to a run-in, it applies to the run-in itself if it displays as
             a block, and it applies to the block the run-in runs into if it
             displays as an inline.

   RESOLVED: For CSS2.1 Issue 198, clarify spec to say that run-in effectively
             causes a reordering of the source tree insofar as the formatting
             model is concerned, and the contents of the run-in are moved along
             with it. (This does not affect e.g. selectors, etc.)

   RESOLVED: Proposal accepted for CSs2.1 Issue 201 with "table wrapper box"
             as the term for the outer table box.

   RESOLVED: CSS2.1 Issues list is FROZEN in preparation for LCWD.

   RESOLVED: CSS2.1 to progress from LC directly to PR if it meets exit criteria

CSS2.1 Test Suite

   Discussed Release Candidate criteria, what happens to tests that are wrong,
   making implementation reports, and how we are measuring test coverage of
   the spec.

   Test suite RC scheduled for September 15th; test errors must be fixed
   before RC. Implementation reports due 1 month after RC publication.

CSSWG Charter

   Current charter: http://www.w3.org/Style/2008/css-charter
   Old planning document: http://wiki.csswg.org/planning/charter-2008

   Reviewed contents of old charter, since we plan to copy most of it over.

   Reviewed current and expected status of modules, who is planning to work
   on what, and what priority they should have within the WG.

   RESOLVED: Move css3-marquee and css-mobile to low priority, send
             OMA liaison about this

   First cut of 2010 module priorities (may be shuffled around later):

   High Priority -> Maintenance:
     CSS Color Level 3
     CSS Namespaces
     CSS Styling Attributes
     Selectors Level 3

   High priority:
     CSS Snapshots
     CSS Backgrounds and Borders Level 3
     CSS UI Level 3
     CSS Fonts Level 3
     CSS Image Values Level 3
     CSS Multi-column Layout
     CSS Transforms
     CSS Transitions
     CSS Values and Units
     Media Queries

   Medium Priority:
     CSS Box Model Level 3
     CSS Device Adaptation
     CSS Flexbox
     CSS Lists
     CSS Paged Media Level 3
     CSS Ruby
     CSS Template Layout
     CSS Text Level 3
     CSS Transforms 3D
     CSS Writing Modes Level 3
     CSS Variables
     CSSOM View

   Low Priority:
     CSS Backgrounds and Borders Level 4
     CSS Filter Effects (applying SVG filters to CSS layouts)
     CSS Grid Positioning
     CSS Line Layout
     CSS Scoped Style Sheets
     CSS UI Level 4
     CSS Tables
     Selectors Level 3 Revision 1 (just adding OM and serialization)
     Selectors Level 4

Viewport Meta and CSS Syntax

   Reviewed Rune's proposal for an @viewport rule to set the size of the
   inital containing block independently of the viewport itself.

   Comments included
     - Pages designed to accommodate varying device sizes are often
       broken by the behavior in the viewport meta proposal.
     - Many use cases can be solved by using max-width/height on the
       root element to determine an appropriate viewport size, so UAs
       should try to use that instead. However, this technique has
       trouble with fixed positioning.
     - Interaction with Media Queries must be defined, perhaps similar
       to @page { size: ... }.
     - @viewport has ways of indicating a preferred fixed size, but
       does not allow a range of valid sizes from which the UA could
       choose the most appropriate for its device.
     - A guiding principle would be to specify only those things that
       would break web content if a UA decides to do it differently.
       This avoids overspecifying things that should be within the UA's

   RESOLVED: CSS Device Adaptation added to charter at medium priority,
             Rune to edit along with someone from Apple

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

   César Acebal
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Arron Eicholz
   Elika Etemad
   Daniel Glazman
   John Jansen
   Hĺkon Wium Lie
   Chris Lilley (late)
   Alex Mogilevsky
   David Singer
   Steve Zilles (late)

<RRSAgent> logging to http://www.w3.org/2010/08/23-CSS-irc

CSS2.1 Issues
Scribe: TabAtkins

   glazou: There are a few open issues with editorial work.  I'd like to
           browse through them to see if they're ready.
   glazou: First is issue 26 on bert
   Bert: For 26, I did do the edit, but it's not verified yet.
   Bert: Same for 53.
   Bert: For 56, not done yet.
   Bert: 60, edited.
   Bert: 69, edited.
   Bert: 71, edited.
   Bert: 73, edited
   Bert: 84, edited
   Bert: 85, edited
   dbaron: 101, not done.
   glazou: Anyone else who can pick up 101?
   arronei: I can do a few testcases.
   dbaron: I wrote a few tests.  They're not submitted to the testsuite.
   glazou: please send those tests to arronei
   Issue 101 is reassigned to Arron.
   <dbaron> Figuring out what the text should be is the hard part...
   Bert: 107, edited.
   Bert: 109, not done yet.
   Bert: Not sure if it can be done this week, but certainly next week.
   glazou: So by the time of the next conf call?
   Bert: Yes.
   Bert: 110 relies on 109.
   Bert: 111, edited.
   glazou: Was john daggett supposed to be here?
   howcome: Yeah, we're missing jdaggett and szilles.
   glazou: Okay, we need John for those testcases.
   * dbaron notes jdaggett's flight landed at 7:24
   Bert: 114, edited.
   Bert: 115, edited.
   Bert: 117, edited.
   Bert: 118, edited.
   Bert: 119, edited.
   Bert: 120, not done yet.
   glazou: Can you get it by the conf call?
   Bert: Yes.

   Bert: 121, I sent a proposal.
   glazou: Did anyone review that?
   Bert: I just sent it 2 days ago, so maybe people haven't seen it yete.
   <dbaron> is there a url?
   glazou: Action on everyone: review the proposal by next conf call.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0411.html

   Bert: 122, not done yet.
   glazou: You already have the dbaron proposal for that, so same ETA?
   Bert: Yes.
   Bert: 127, edited.
   Bert: 128, edited.

   glazou: Open issue now, about backup in tokenizer - 129.
   Bert: I sent a proposal to the list about that last week.
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Aug/0417.html
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Aug/0368.html
   glazou: Has anyone tested this in an implementation?
   Bert: I wrote one to test it.
   dbaron: The only real change is that we change how we handle bad urls.
   dbaron: I think that we made the change in Moz a few weeks ago when
           the group decided to make the change in priciple.
   glazou: No objection?  Good.
   RESOLVED: Accept Bert's proposal for 129.
   <dbaron> I changed Gecko to match the new url() tokenization in
     https://bugzilla.mozilla.org/show_bug.cgi?id=569646 which has been
     on trunk since June 3.

   Bert: 131, I think I've already done it.
   fantasai: I need to go through all of them and make sure.
   <fantasai> and then update the issues list
   glazou: Issue 134.
   arronei: Done.
   Bert: 137, not done yet.
   Bert: 138, not done yet.
   Bert: 139, haven't done yet, but should be very easy.

   Bert: 140, sent a proposal yesterday.
   <Bert> http://lists.w3.org/Archives/Public/www-style/2010Aug/0435.html
   glazou: Everyone, review this so we can decide on it next call.

   Bert: 141, edited.
   Bert: 142, edited.
   Bert: 143, not done yet, but should be easy.
   glazou: 144, text-decoration and visibility.  iirc, we didn't finish
           the discussion and deferred it to the ftf.
   glazou: I think you said that all browsers have interop, which doesn't
           match the new proposal.
   arronei: Yeah, they all do the same thing - drawing the decoration in
            the invisible area.
   glazou: So we can either change the spec or tell all the implementors
           to change.  Your choice.
   glazou: I don't think decorations actually matter to authors very much.
   dbaron: I know we intentionally changed the image underlining, and I
           want to keep that.
   dbaron: So I want to keep the spec, and change Moz's impl.
   dbaron: Doing so would let us unify the quirks/standards impl for
   dbaron: I think webkit has a similar distinction.
   glazou: howcome, opinion?
   johnjansen: We'd prefer not to change our impl.
   dstorey: Is it a minor change?
   glazou: Yeah, should be.
   fantasai: What if you use visibility:collapse?
   dbaron: You don't draw the collapsed cell at all.  It's quite different.
   howcome: If we have interop, we should just keep that.
   dbaron: I think the interop behavior is a complete disaster.
   dbaron: And the quirksmode behavior is better than standards mode.
   glazou: Proposal - leave it undefined in 2.1 and leave a note, define
           it properly in css3.
   RESOLVED: Leave issue 144 officially undefined, add a note that it
             will be resolved in css3.
   arronei: I'll remove the tests.
   dbaron: The issue is that the spec was unclear about whether text
           decorations were based on the visibility of the text or
           the visibility of the element with text-decoration.
   fantasai: The spec is not clear, but the rest of the model that it
             outlined in the spec is more consistent with one impl
             than the other.
   glazou: Also, we discussed both underlined text, and about underlining images.
   fantasai: The image underlining issue is taken care of.
   glazou: What about impls?
   arronei: It's inconsistent.
   glazou: So the only ambiguity is about underlining text in a
           visibility:hidden element?
   fantasai: Yeah.

   Bert: 145, not done yet.  I can get it by next call.
   Bert: 146, not done yet.
   Bert: 147, not done yet.
   Bert: 148, not done yet.

   Bert: 149, not done yet.
   Bert: I disagree with the resolution.
   glazou: I think Moz already implemented that.
   dbaron: I think other impls have it coming now.
   <dbaron> I think other impls have done it for a while
   glazou: The decision was made during a conf call, and recorded in the
           minutes.  You should be reading the minutes and objecting as
           soon as possible afterwards if you miss a call.
   dsinger: I think we might want a note that some user agents start off
            at a zoom factor other than 1.
   howcome: Where in this decision does it say that this only applies to
            screen media?
   fantasai: It doesn't need to do so explicitly.  There is a recommendation
             that high-res devices should set the in or other physical
             unit to the true physical size, while low-res devices are
             recommended to use the px as the anchor unit.
   jdaggett: I think we should go ahead and draft up some revised text for that.
   [minuter's note: what's "that"?]
   glazou: dsinger, can you send a suggestion for the note you want?
   glazou: If howcome and others have comments, please make them as soon as

   Bert: 150, edited.
   Bert: 151, not done yet.  I can get it done by next conf call.
   Bert: 152, edited.
   Bert: 153, not done yet.  Next conf call.
   arronei: 154, now that jdaggett and I are both here we can talk about it.
            Next conf call.
   Bert: 155, not done yet, but should be trivial.
   jdaggett: 156, the edit has been put in, but I think some of the
             surrounding statements need to be cleaned up to match.
   jdaggett: Is that a new issue or just wrap it up in the current one?
             I also haven't written a new test case.
   glazou: Not a new issue.
   jdaggett: Ok, I'll make a proposal for further edits tomorrow.
   <fantasai> jdaggett, I think the edits didn't make it in 100% as there
              was a sentence "Once the family's weights..." in the proposal
              that didn't make it in for 156

   Bert: 157, not done yet.
   Fantasai: issue 158
   Tab: Proposal for 8.3.1 cleared up some minor collapse issues
   Tab: Anything I've already is probably invalid at this point
   Fantasai: I've seen some proposals from Anton that I can put together
             so we can sit down and talk it through
   Glazou: Do we need to make some time
   Tab: Yes, we'll talk by ourselves tonight and then need some time
   Glazou: We'll do our best
   Glazou: Deferred until discussed
   glazou: Issue 159.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0015.html
   fantasai: That's what my 8.3.1 rewrite was for.
   TabAtkins: And I think arronei reviewed it and said it was good.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
   dbaron: Link to the latest proposal?
   dbaron: I need more time to review it to make sure it's good.
   glazou: We'll discuss it on the first conf call after the meeting.
   ACTION everyone: review the 8.3.1 proposal
   <tantek> FWIW - I reviewed http://lists.w3.org/Archives/Public/www-style/2010Aug/0391.html
            and it looks good to me (fantasai's v3 of Clarifying 8.3.1
            Collapsing Margins)

   Bert: 160, not done yet.
   Bert: 161, not done yet.
   Bert: 163, edited.
   Bert: 164, edited.
   Bert: 166, edited.
   Bert: 167, edited.
   Bert: 168, edited.
   Bert: 169, edited.
   Bert: 170, not done yet.
   Bert: 171, edited.
   glazou: Open to the WG, 172 - table caption and content overflows.
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0404.html
   fantasai: Issue is that the caption overflows in non-useful ways when
             the table is small.
   fantasai: My proposal was to make the caption act like a cell for purpose
             of table width.
   dbaron: Does any impl do that?
   fantasai: Yes, Konqueror, and some older browsers, I think ie6.
   fantasai: This changes the computed final width of the table, essentially
             providing a minimum width for it.
   fantasai: So when you lay out a table, you calculate the actual width,
             and then use min(that, computed width).  I'm proposing
             using the caption width also.
   dbaron: It might be worth noting that this only applies to top/bottom captions.
   fantasai: We can note that, sounds like a good idea.
   Tantek asks for a testcase
   <fantasai> Tantek: http://test.csswg.org/source/contributors/csswg-issues/incoming/css2.1/table-caption-004.xht
   fantasai: This proposal will require revising the table-caption-004 test.
   dbaron: If the caption is large enough to make the page scroll, this
          change will make the entire table stretch off the page.
   glazou: Will this break anything?
   dbaron: table captions are used so rarely that I don't think it will
           affect anything significant.
   tantek: If I rewrite the test case to use <table>, I think IEMac5.2
           matches your proposal.
   fantasai: Right, a lot of the older generation of browsers do that.
   glazou: Can we reach a decision here?
   dbaron: I'm okay with it.  I'm not super happy when the caption is
           extra wide, but shrug.
   dbaron: Probably in the case that the caption width has a small fixed
           width, we should make it so that the table can be larger than
           that and the caption stays small.
   <gsnedders> glazou: Okay, I'll probably join then
   RESOLVED: Accept fantasai's proposal for 172.
   ACTION: fantasai Add note mentioned above and ignore prefwidth when caption
           has computed width

   <br duration=15min>
+Chris Lilley

   glazou: Issue 173
   fantasai: I need to work on that.
   glazou: Is it still workable?
   fantasai: I've emailed back and forth with henri.
   fantasai: He says "I want carriage returns inserted wherever to be whitespace."
   fantasai: I said "What kind of whitespace?"
   fantasai: He didn't know. Thought it should be normalized as a line break
             in pre
   fantasai: But that would make DOM text and generated content text behave
             inconsistently, because CR is ignored in generated content
   fantasai: I think I'll still need a while to do this.
   fantasai: A couple of hours.
   fantasai: Maybe can do it before we end here, if not, then by the next
             conf call.
   glazou: Send it by next Wednesday, so we have a week to review it before
           the conf call.
   glazou: Otherwise it's undefined in 2.1
   chrisl: Does this have any effect on test suites?
   arronei: yeah, we'll need more tests
   ACTION Elika: Send a proposal by next wednesday.
   <trackbot> Created ACTION-248

   Bert: 174, 175 edited.
   Bert: 176, edited.
   Bert: 177, edited
   TabAtkins: 178, I was crazy.  Mark as invalid.
   Bert: 179, edited.
   Bert: 180, editd.
   fantasai: 181, I don't think it needs to be addressed right now.
   Bert: 182, edited.
   glazou: new open issue, 183 - handling of malformed media types
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Aug/0025.html
   glazou: We seem to be saying two different things here about what to
           do with the malformed queries.
   chrisl: It should be possible for us to just match up with what MQ says now.
   dbaron: What's the mismatch?  Is it just that we have 2.1 say that
           unknown identifiers don't match anything, but aren't parse errors?
   fantasai: So 2.1 says to ignore unknown media types, but do you ignore
             malformed ones or throw the whole at-rule away?
   dbaron: I think we ignore.
   fantasai: I don't think anything is said that media types have to be
   <dbaron> The appendix G grammar says it has to be an identifier in 2.1
   <dbaron> but it doesn't seem to say that outside the appendix G grammar
   dbaron: Does this affect any impls?
   dbaron: Anyone that doesn't implement MQ that are currently maintained?
   dbaron: Because this change only affects impls that do 2.1 and not MQ.
   fantasai: I think some of the printers may.
   <fantasai> fantasai: But they probably want to implement MQ as awell
   glazou: Can't we just say that MQ supercedes 2.1 here?
   fantasai: That's in the snapshot, but it's still not clear what an
             "unknown media type" is.
   dbaron: Since we're making Appendix G informative, we should add a
           note that media types must be identifiers, and non-identifiers
           make the whole thing invalid.
   dbaron: We should probably go through Appendix G and check for similar
           occurences like that.
   dsinger: Is there a difference between an unknown and an invalid type?
   fantasai: If it's not an identifier, it's invalid and throw it away.
   <fantasai> "@media and @import rules with unknown media types are
               treated as if the unknown media types are not present. "
   <fantasai> "@media and @import rules with unknown media types (as
              identifiers) are treated as if the unknown media types
              are not present."
   <fantasai> ?
   <fantasai> plus "If an @media rule contains a malformed media type
              (not an identifier) then the statement is invalid"
   <fantasai> s/as identifiers/that are nonetheless valid identifiers/
   <fantasai> Note: Media Queries supercedes this error handling.
   RESOLVED: Accept the change above for issue 183.
   Action Bert: Make the above edit for issue 183.
   <trackbot> Created ACTION-249
   ACTION dbaron: Find normative statement in appendix G that should
                  now be written elsewhere.
   <trackbot> Created ACTION-250

   Bert: 184, edited
   Bert: 185, not done yet.
   glazou: We already closed 186.
   fantasai: 187 - The spec is confusing in this case.  it's inconsistent
             about normal bidi working.  I can write an email about that tonight.
   fantasai: I may need some time for this Tuesday or Wednesday.
   johnjansen: dbaron, can you do that appendix G trawling by next conf call?
   dbaron: Maybe.
   glazou: If we get the issue list closed down, perhaps we can have a
           firm roadmap for 2.1 by next conf call.
   Bert: 188, edited.
   Bert: 189, edited.
   Bert: 190, not done yet.
   glazou: 191, define stacking level of marker box.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Dec/0093.html
   fantasai: I think arronei and I talked about this, and wanted to make
             it undefined in 2.1, since you can't move the marker box anyway.
             Also, there are some significant details that may be affected
             by implementations, so we want to wait to see what implementations
             do and then spec that behavior in CSS3.
   fantasai: We shouldn't put a recommendation in 2.1, but we might put a
             note saying it's undefined or leave it out completely.
   glazou: I prefer marking it undefined.
   RESOLVED: Add a note about marker box stacking level for outside markers
             being undefined in 2.1.
   ACTION fantasai: Propose note for issue 191 making marker box stacking
                    level undefined.
   <trackbot> Created ACTION-251

   <glazou> http://lists.w3.org/Archives/Public/www-style/2009Oct/0027.html
   dbaron: Anton's proposal for issue 1 looks fine.
   dbaron: I don't think we want to make the second change.
   dsinger: I think the "further" lacks a referent.
   <fantasai> dbaron proposes s/further content/content after the float/
   <fantasai> and s/it/that content/
   TabAtkins: And the third issue is invalid - Bert gave an example where
              the content may have to be reflowed onto multiple lines.
   RESOLVED: Accept change for first issue, accept dbarons' change for
             the second issue, third issue is invalid.

   Bert: I've done the edits for 193.
   fantasai: I haven't written the tests yet.
   fantasai: I can do them this week.

   glazou: 194 is open to the working group - text-indent shouldn't apply
           to non-first-lines of an element.
   fantasai: The issue is that if you have a block split by another block,
             thus generating anonymous blocks, you don't want the two
             halves of the paragraph indented.
   <dbaron> http://lists.w3.org/Archives/Public/www-style/2010Aug/0207.html
   dbaron: Proposed text seems fine.
   RESOLVED: Accept the proposal in the issue list for 194.

   glazou: Issue 195, clarifiction needed for inline boxes containing block boxes.
   fantasai: The behavior Boris proposes is currently implemented in Gecko.
   glazou: Do we all agree about the clarification needed?  Any objections?
   fantasai: Looks like we have Opera and Firefox.
   dbaron: And Chromium seems to do the same thing too.
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0156.html
   TabAtkins: IE8 doesn't generate the second half.
   glazou: Fantasai, write up proposal.
   ACTION fantasai: Write up a proposal for issue 195.
   <trackbot> Created ACTION-252

   glazou: Issue 196 - grammar and prose disagree on nbsp inside identifiers.
   dsinger: Do we have impl experience?
   fantasai: In the test, if it's underlined you accept nbsp in an identifier.
   dsinger: Safari is underlining, firefox is not.
   dbaron: Prose says nbsp isn't allowed, grammar says it is.
   glazou: We always say that prose is higher than the grammar.
   ChrisL: Is there a reason to be more restrictive?
   fantasai: Usually we use the prose to be more restrictive because the
             grammar cannot express the restrictions easily, but here there
             doesn't seem to be any reason for the difference.
   RESOLVED: Change prose to match the grammar.
   dbaron: The prose/grammar mismatch goes all the way back to CSS1.
   ACTION bert: Fix the prose for issue 196 to match the grammar.
   <trackbot> Created ACTION-253

<br type=lunch duration=1h/>
Scribe: fantasai
   Resuming from CSS2.1 Issue 186
   dbaron has pointed out that one of the ranges includes a bunch of
          control characters
   fantasai: So there were two related issues, one is that the range
             given started at A1 instead of A0. We resolved to include A0
   fantasai: The other issue is that the range in between the two
             formulations of the range used to not be characters
   fantasai: but now are control characters
   fantasai: The spec relied on them not being characters when defining
             the range
   fantasai: They should instead be explicitly excluded
   RESOLVED: Range should be worded such that these characters are excluded

   CSS2.1 Issue 197
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Feb/0156.html
   <glazou> http://www.w3.org/mid/20100808112430.GA23693@bowman.infotech.monash.edu.au
   <glazou> http://www.w3.org/mid/4B513652.9020709@mit.edu
   fantasai: I think what that's saying is that the 'clear' applies to the
             run-in if it becomes a block box, otherwise it applies to the
             parent block that it's been injected into
   dbaron: Do run-ins get injected into the next block box if there is a
           float in between? Because that would make clear very interesting
           on run-ins
   <Arron> http://test.csswg.org/suites/css2.1/20100815/html4/run-in-float-between-001.htm
   <Arron> http://test.csswg.org/suites/css2.1/20100815/html4/run-in-clear-001.htm
   Molly: Why would you put a float between the header and the beginning
          of a section?
   dbaron: Suppose you have an article about an image, you might want to
           float it to the side
   dbaron: Then someone comes and wants to make the headings all run-ins
   <dbaron> (And do run-ins run in to a first child of the following block
            if the first child is also a block?)
   fantasai and glazou give more examples where it makes sense
   Group refers to internal editor's draft of the spec, since edits for some
      other issues made significant changes to this section:
   <dbaron> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
   the wg studies the run-in-clear-001 testcases, which has very poor wording!
   Agreed on what the spec is intending to say and that it needs to be clarified
   ACTION: fantasai and Bert, clarify spec for CSS2.1 197
   <trackbot> Created ACTION-254

   <glazou> issue 198 now
   <glazou> http://lists.w3.org/Archives/Public/www-style/2010Jan/0376.htm
   dbaron: So this isn't as complicated as it looks.
   dbaron: We just need to make sure the spec defines clear in terms of the
           box tree instead of the element tree.
   dbaron: But that means we need to get the spec to admit that there is
           a box tree.
   fantasai: The question here is whether you take floats out-of-flow
             before or after you process run-ins
   Tab: The definition of clearance is based on the element tree, so it's
        asking the <div> to clear the float here, even though the float
        would be inside the clearing box
   dbaron: We could fix this by adding a parenthetical to the float rules
           talking about floats inside the clearaing element to explicitly
           include the contents of run-in elements
   <dbaron> Inside "The 'clear' property does not consider floats inside
            the element itself or in other block formatting contexts." in 9.5.2
   <dbaron> to something like "The 'clear' property does not consider floats
            inside the element itself (including floats inside a
            'display:run-in' element that runs in to the element) or in
            other block formatting contexts."
   dsinger: Is it completely clear what "inside" means in that section?
   everyone: no
   bert: So what if you have a float in between the run-in and the block also?
   <dbaron> We also need to fix the float positioning rules in 9.5.1
   <dbaron> because they also go by source order.
   <dbaron> and if the float not in the run-in has 'clear' on it then you
            have an explicit contradiction
   <dbaron> we need a box tree
   discussion of float placement rules
   steve: So instead of saying that the float is inside the element that
          the float is inside a run-in rendered inside the principal box.
   dbaron: how does that help?
   dbaron: .. old problem. Doesn't help the new problem.
   dbaron: The new problem is if you have
   dbaron: The floats are both left
     floatA, floatB { float: left; }
     floatB, block { clear: left; }
   dbaron: The definition of clear on floats says that floatB has to be
           below floatA
   dbaron: Because it has to clear any elements earlier *in the source document*
   dbaron: The definition of clear on blocks says that the block has to
           be below floatB
   dbaron: And the float positioning rules say that floatA has to be even
           with the top of the block that contains, i.e. at or below the
           top of the block
   steve: So say for a run-in, that combines with the following block,
          it is considered a reordering in the source docuent
   <dbaron> so if "below" is "greater than", then floatB < floatA,
            block < floatB, and floatA <= block, which is a problem
   tab: The more and more we try to patch the definitions here, the more
        of a mess it's going to get
   tab: Maybe we can patch it here in 2.1 and make a CSS3 Box Tree module
   ChrisL: We don't have to expose the box tree to the dom or anything,
           but we need to be clear about how it works
   Bert: Another option is to say that floats inside the runin disable the runin
   steve: What if I'm using float to get an initial drop-cap?
   steve: We should go with run-in reordering the source tree in certain
          circumstances, and limit the circumstances where this occurs
   steve: for layout purposes only
   dbaron: We'd have to go through the whole spec and decide which instances
           would use the actual source order and which would use the virtual
           source order
   dbaron: Which is what we mean by defining the box tree
   alex: You'd also need to update Appendix E
   fantasai: so for chapter 8 and above you pretend the source has been reordered
   <dsinger_> but ... what happens if you need to be able to say something
              on the run-in that applies *without* this re-ordering, because
              then you would not be able to?
   steve: the def of run-in box says that it's rendered as if it were an
          inline element in the next block box
   steve: you could just clarify that the contents, including floats and
          abspos, are included in this move
   steve: you might need a note that you need an apparent reordering of
          the source
   "the run-in box becomes the first inline box of the block box"
   <Bert> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
   <TabAtkins> http://www.w3.org/Style/Group/css2-src/visuren.html#run-in
   steve: So we need a note to clarify
   ACTION: Steve write note to clarify that run-in's contents are reordered
           by rule 2 in 9.2.3
   RESOLVED: Add note to be written by Steve for CSS2.1 issue 198 to
             clarify that runin effectively causes a reordering of the
             source tree as far as all of the layout rules are concerned

   <fantasai> so line boxes should be created for inline-level content and
              potentially marker boxes
   <fantasai> collapsed-away whitespace does not create a line box
   jdaggett: so you have a line box with no text in it. What font metrics
             do you use for it?
   dbaron: known problem
   Bert: We need to pick a font for finding the 'ex' unit
   jdaggett: We don't have a font-finding algorithm that works without text
   several you want to check against the first available font
   steve: match against the empty string. Every font will match
   <TabAtkins> http://lists.w3.org/Archives/Public/www-style/2010May/0698.html
   discussion of the phantom line boxes in 9.4.2
   fantasai: You need the phantom line boxes to handle abspos static positioning
   fantasai: but you need to ignore it for margin collapsing
   <ChrisL> calling it 'potential' line box (which later resolves to no
            line box, or a real line box, may be better than 'phantom'
   ACTION: Tab propose text for CSS2.1 Issue 199
   <trackbot> Created ACTION-255
   <Arron> I feel that potential is a better term than phantom

Scribe: Molly Holzschlag
   Daniel: Last issue on the radar, then we will decide to stop on these
           issue or not
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2010Aug/0401.html
              and http://lists.w3.org/Archives/Public/www-style/2010Aug/0403.html
   fantasai: I suggest the term table-wrapper-box
   RESOLVED: Accept proposal for CSS2.1 Issue 201 with "table wrapper box"
             as the term

   szilles and fantasai discussing vertical-align
   szilles: undefined is fine

CSS2.1 Spec Progress

   Daniel: CSS 2.1 issues freeze
   Daniel: stop registering issues now
   David: As long as we keep a list of them
   dsinger_: Will likely end up in errata or moved to CSS3
   fantasai: We are publishing a last call working draft, we are required
             to accept comments. For this round of editing, there's no
             reason why we shouldn't close down, publish, and consider
             anything else last call issues
   fantasai: they will have four weeks to comment
   RESOLVED: CSS 2.1 issues: FROZEN
   (no objections, very strong support)

   Glazou: if we have interop shown by reports, we go directly to pr
   (no objections)
   Glazou: Everything relies on implementation reports - completion of
           test suites, so let's discuss
   RESOLVED: LC->PR if we have exit criteria for 2.1

CSS2.1 Test Suite

   Glazou: What remains on the radar with the test suite and when are we
           able to say it's ready?
   Fantasai: we have to have "no suspected" issues, when that's complete
             I can publish a Release Candidate
   jdaggett - there are tests that don't pass in any browsers
   dbaron: a bunch of people did respond to the tests in that list
   jdaggett: I've actively try to go to people I thought would care but
             I fear they will comment
   Glazou: at some point we have to freeze things
   Glazou: Browser vendors: you want css2.1 published but your teams have
           not evaluated the tests, have not already implemeted, even if
           we are going to CR/PR
   Glazou: if you want it published, we rely on your implementations.
           The entire thing is in your hands, not the WGs
   Fantasai: If there's a problem with the test
   Fantasai: Email the list, and then we will take a look at the test
   Fantasai: If we can't resolve the issue there we will push it to the WG
   Fantasai: The review process is documented on the wiki
   Glazou: Not an issue with the spec
   Glazou: suggest 1 Oct. for test suite
   Deadlines: Edits should be done for next conference call
   Bert: I'll be able to do my edits
   dsinger, fantasai: discussing automation of tests
+jgraham and gsnedders
   gsnedders: Opera can help provide some help with that too
   jdaggett, dbaron: discussing tests and windows limitations
   Jdaggett: there are some tests that don't pass on any windows
             implementation but do pass on other platforms
   jdaggett: for font tests this will be hard. Bold and non-bold versus
Scribe: fantasai
   jdaggett: On windows you only have bold and not bold
   jdaggett: you need to test on e.g. MacOS to get the full range of testing
   jdaggett: Windows will allow trivial passes
   glazou: The test suite isn't supposed to demonstrate interop, it's
           supposed to demonstrate implementability
   glazou: The tests aren't conformance tests, they're spec implementability
   steve: You're testing for interoperable implementability
   jdaggett: When I say font-weight 100, it should pick the 100 weight font
             not the 400 weight font
   jdaggett: but on Windows you only get the 400 weight font
   dsinger_: The problem is what if you have two sections of the spec that
             can be implemented, but not at the same time
   steve: The requirement is that there exist at least 2 impls
   dbaron: You can also get sections of the spec that fail in all windows
           implementations, and you need to find non-Windows implementations
           to get passes

   glazou: Next step is writing the implementation reports..
   dbaron: Arron, can you share that list of which tests pass on which browsers?
   JohnJansen: No, we can't
   ChrisL: The full data is a matrix in a spreadsheet that shows which
           tests pass in which versions of which browsers.
   <ChrisL> And I would like to talk to Microsoft managers to get the
            relevant parts of that released to the working group. It
            will get us out of CR earlier
   JohnJansen: It's a very expensive process
   glazou: For Selectors, hixie and I had to write the implementation
           reports ourselves
   glazou: It's always the case that some Members put in more resources
           into the WG on some things than others
   ChrisL: We wouldn't be asking MS to provide the data if you didn't
           already have it.
   dbaron: I don't consider it worth my time to go through the test suite.
   dbaron: But if you provide a set of tests that we fail, then I will
           review those tests.
   dbaron: So could you share the list of tests that fail in at least
           one browser?
   Arron: I've shared the lists of tests that don't pass in any browser,
          and those that I think are invalid
   Arron: Once we decide the test suite is solid, and we're getting there
          with Gérard reviewing a lot of the tests,
   Arron: Then when you run the tests you can look more closely at the
          tests you fail
   howcome: dbaron has 2 points I would like to emphasize
   howcome: One is that the tests are too many and give us too little apiece
   howcome: We've all found ourselves in situations doing work on behalf
            of other browsers.
   howcome: And you have done that -- all the tests you've contributed
   glazou: It's perfectly normal.
   glazou: Microsoft wants 2.1 to be released ASAP, because you rely on it.
   glazou: Contributing the results of the tests will speed up the process.
           Not contributing it will slow us down.
   glazou: It's in your interest to contribute the results.
   Steve: The issue isn't the test results, the issue is the implementation
   <ChrisL> I would like to see Arron's list of 'tests passed by no windows
            browser' on the wiki, then remove tests that are passed on
            other platforms
   Steve: So we're not asking for a contribution of test results, we're
          asking for contribution of to the implementation reports
   Arron: These are only the HTML test results, not the XHTML tests
   dbaron: So there could be additional tests that don't pass in any browser.
   JohnJansen: We shared a lot of the data we have. The list of suspected
               invalid tests, and the list of tests that don't pass
   howcome: Can you provide the list of tests that fail in any one browser?
   glazou: A few years ago the only company interested in print was YesLogic.
   glazou: And afterward HP
   glazou: But not the other vendors were interested in print
   glazou: But we contributed time to working on those specs
   JohnJansen: The tests we contributed are available to anyone to run
   JohnJansen: We're not hiding anything.
   Arron: It's our time and money that we've put into creating the test results
   dsinger_: I'm grateful if he gives me the data, I don't think I can ask
             him to do that work for me and save me that time and money.
   JohnJansen: I wouldn't want you to trust our results either.
   dsinger_: Can we keep a page on the wiki of tests that are suspected
             to be wrong?
   ACTION: fantasai make said wiki page
   <trackbot> Created ACTION-256

   fantasai: People can start on implementation reports now. I can even
             throw out a beta 4 on Monday
   fantasai: Whenever I publish a release now I list all tests that have changed
   fantasai: So between releases you'd only have a handful of test results
             you might need to run
   glazou: I am requesting browser vendors to start implementation reports now.
   Arron: It takes 16 hours to run the tests by hand
   dsinger asks about automating them
   fantasai and Arron say it will take much longer to automate them
   dsinger_: How good is the coverage of the test suite
   gsnedders: Automating the tests isn't just a one time thing, because
              everyone would want to run them as regression tracking
   gsnedders: if they're manual, they won't be run very often
   gsnedders: Automating the tests won't just save time once
   jdaggett: For CSS3 modules do we have to follow this pattern?
   fantasai: For CSS3 modules, we're recommending self-describing reftests,
             so you can run the test manually as well as automated.
   fantasai: (We didn't have the reftest format when we started CSS2.1 testing.)
   glazou: If we don't get your implementation reports, things are going
           to slow down.
   glazou: It relies on you.
   glazou: The sooner we get it, the better.
   <fantasai> gsnedders++
   <glazou> gsnedders: exactly.

   dsinger_: Coverage?
   dbaron: There's questions of how you measure test coverage
   dbaron: you'd have to measure e.g. code coverage
   fantasai: What we have is the following:
   fantasai: We have all of the tests indexed by which sections they claim
             to test, and that index includes the title and other metadata
             detailing exactly what the test is trying to test.
   fantasai: We also have Gérard Talbot, who is reviewing the test suite
             now, and is noting any gaping holes in our test coverage and
             helping us write tests to fill those gaps.
   dbaron: The spec has lots and lots of interactions among features, many
           of which are not obvious
   dbaron: We don't have good coverage of those interactions.
   dbaron: There are sentences in the spec that require hundreds or
           thousands of tests just for that sentence. And we don't have
           that coverage.

   glazou: Anything else on the test suite and the roadmap?
   glazou: I remind you that the goal is still PR before the end of the year.
   glazou: This is important for both the WG and the W3C itself.
   glazou: We started this roughly ten years ago
   ChrisL: If the CSS2.1 can get to PR by the end of the year, there's
           still a chance that SVG 1.1 Second Edition can normatively point
           to CSS2.1.
   ChrisL: I'd like that to happen.
   glazou: if we move 2.1 to PR, Selectors can move to REC, we solve a
           lot of dependencies.
   JohnJansen: If we got to PR by the end of the year, does that put REC
               at the end of January?
   scheduled charter discussion for after the break

<tantek> note to ChrisL - http://dev.w3.org/csswg/css3-color/ has been
          updated per your request to make edits to Dependencies section,
          replacing "predefined" with color keywords, and removal of n/a
          rules in suggested style sheet that were using dropped attr()

CSSWG Charter

   <glazou> Next topic is WG Charter
   glazou: Current charter ends at the end of November
   glazou: We need to discuss the charter itself, goals, deliverables, scope, etc.
   glazou: Make sure everyone in the WG agrees
   <glazou> http://www.w3.org/Style/2008/css-charter (current charter)
   <fantasai> http://wiki.csswg.org/planning/charter-2008
              (planning document for above)
   WG reviews the Scope section of CSS Charter
   Everyone happy with 1.0
   Now looking at 1.1 -- list of modules
   glazou: I think we need to shuffle soem of these items
   glazou: We should preserve CSS2.1?
   ChrisL: How about a 2 month extension to the current charter, then move
           it into maintenance
   Tantek: And consider 2.1 Errata as the work item
   Going through the list one at a time:
     expect PR by end of year
   CSS3 Backgrounds and Borders
     CR within 1.5 months, have implementations, need test suite, no PR
     by end of year, likely to REC within next period
   CSS3 Color
     PR by end of this year
   CSS Mobile Profile
     nobody here cares
     <glazou> http://www.w3.org/TR/css-mobile/
     It's in CR right now
     No testing done
     Tantek, Bert: To exit CR, you need two complete implementations.
     dsinger: Send OMA a liaison asking if they have finished it
     dbaron: It depends on specs not in CR
     fantasai: css3-marquee is in CR right now
     nobody here interested in pushing to PR
     ask OMA
   RESOLVED: Move css3-marquee and css-mobile to low priority, send
             OMA liaison about this
   CSS Namespaces
     Almost ready for PR, waiting for a pass on one test
     remains high priority
   CSS Object Model View
     ask anne later
     <dbaron> I'd say cssom-view is medium priority, but anyway...
   CSS Paged Media Level 3
     needs a lot more work to get to LC, then back to CR
     high priority for several industries, but we are low on resources b/c
     the editors are booked with other things
     assigned medium priority right now
   CSS Snapshot 2007
     rename to CSS Snapshots
     keep high priority
     fantasai proposes to create 2010 Snapshot by adding Media Queries
   CSS Variables
     drop to low priority -- hasn't changed in 2 years
     dbaron: Some of what stopped variables' progress is a misunderstanding
     dbaron: We wanted more data on it, to show that we're going in the
             right direction
     dbaron: rather than using up core bits of syntax wrongly
     dbaron: That got interpreted as we don't want it
     howcome: There's also complexity -- e.g. dom access to variables
              is more complicated than constants
     howcome: It's not just a question of signing up an editor
     Daniel: I could do the editorial work, i but I need implementors
             who want to do this.
     CSS Variables dropped to medium
   Media Queries
     remains high priority
     -> maintenance mode
   Need to create a new list for maintenance
   glazou: Selectors 4?
     dbaron, Tantek: Put it on low or medium priority
     fantasai, Tab: We have items to work on, but it's not a high priority
     moved to low priority
     dbaron: HTML5 defines when CSS3 Selectors and CSS3 UI selectors apply to HTML
     dbaron: But does not introduce new ones IIRC
     <TabAtkins> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#pseudo-classes
   CSS3 UI
     added as high priority, edited by Tantek
   CSS3 Basic Box Model
     stays at medium priority
   CSS3 Fonts
     high priority
     jdaggett aiming for LC by end of the year
     hopefully REC by end of next year
   CSS3 Generated and Replaced Content
     low priority
     Tab Atkins as editor
   CSS Grid Positioning
     low priority
     jdaggett: I think there's a dependency from vertical text on Grid
     fantasai disagrees
   glazou: kept in charter, low priority
   CSS Marquee
     Tab: That's only for mobile phones
     Bert: That's indeed only for mobiel phones, the desktop browsers didn't want it
     <ChrisL2> ask OMA
     Bert: Maybe send in same liaison to OMA
       low priority
   <Peter> WebKit implements a large part of it in Chrome/Safari
   CSS Multi-column Layout -
     high priority
   CSSOM - ask Anne
   CSS Ruby -
   fantasai: medium priority; Mozilla is implementing
   CSS Template Layout -
   Tab: keep at medium
   CSS Transforms -
     high priority
   CSS Transitions -
     high priority
   CSS Values and Units
     fantasai: medium priority
     glazou: low
     dbaron: high
     dbaron: I'd like to see it in CR by the end of next year
     howcome doesn't want to finish it
     howcome: What happens if e.g. grid module needs a new unit?
     jdaggett: rev the module
     fantasai: or define it in the grid module
      -> high priority
   CSS3 Extended Box Module
     discuss low or dropped?
   CSS Flexbox
     medium priority
     howcome: We have 2 implementations
     dbaron and fantasai are skeptical of whether it's ready for CR
     fantasai: I think it should be at least medium priority, but it's
               not ready for CR
     fantasai: Much of it is underdefined
     ChrisL: high priority since we have implementations
     jdaggett: We have a lot of high priority items
     JohnJansen: So what's the definition of high priority?
     glazou: We need to list everything we want to work on
     glazou: The high priority ones are the ones that we need to be in
             a good state, that the AC reps will check on
     GCPM -> medium
   CSS Lists
     medium, editor Tab Atkins
   CSS Tables
     glazou: Any work done on Tables?
     dbaron: Lots of work 2 years ago, but nothing since really
     Alex: That was Markus. The work being done was trying to define
           existing behavior
     dbaron: I would go for low priority, and keep it on the list. It's
             very similar to 2.1 maintenance -- it's an issue we deferred
             it because it was difficult, but it's 2.1 level work
     dbaron, alex: if someone comes to work on it, should be able to
   CSS3 Text and CSS3 Text Layout
     medium priority
     needed for EPUB in Japan
   glazou: Anything else not in the list?
   Tantek: CSS4 UI
     glazou: We can just write CSS UI under high priority, and not list the level
   dbaron: We should add Transforms 3D to the list
     dsinger: add it to low priority
     dbaron: We're implementing 3D, so we're getting to 2 implementations
     dbaron: suggest medium for 3D
   howcome: CSS Backgrounds and Borders Level 4
   jdaggett: Line Layout module?
     jdaggett: I'd like to have something that's clearer on how text with
               different baselines is aligned
     CSS Line Layout -> low priority
     dbaron: The current draft is Michel Suignard's draft from 2001
     dbaron: Plus a half-finished pile of edits I made to make it match 2.1 better
     dbaron: And then some new features, we may or may not want
   Tab: CSS3 Images
     fantasai: we probably want that high priority
   Bert: Speech?
     dbaron: There's an incubator group working on speech
     dbaron: Not sure if they'd be interested in this
     kept off
   dbaron: Scoping?
     dbaron: HTML5 has scoped style sheets. We might want to put it back
             in the charter in case we need to work on it
     dbaron: It's probably a feature at risk in HTMl5
   fantasai: style attribute, high priority

   ChrisL: Other things to talk about from the old charter
   ChrisL: We should produce a report on the old charter, what we accomplished
           on the high priority list
   Chris: how close they get to REC
   ChrisL: Wrt liaisons, CDF closed
   ChrisL: Also, I suggest having two groups, one where we have dependencies
           and one where we don't
   Dependencies - HTML, SVG, WebApps, Webfonts
   ChrisL: And add MathML
   Daniel: Make maintenance list with 2.1 and Selectors, say that any other
           documents that go to REC will switch to maintenance
   ACTION: Bert, glazou, CHrisL, Peter - draft charter 2010

   <fantasai> http://wiki.csswg.org/planning/charter-2010
   <fantasai> Everyone, please update your specs' status!

   Discussed changing telecon times once a month to allow people in other
     countries to join
   ChrisL: Also, is 1 hr/wk enough?
   glazou: I think what we have now is a good compromise
   dsinger: I suggest we put 5-minute decision-and-cut items at the front
            of the agenda
   dsinger: and put technical discussions after that
   <smfr> +1
   glazou: It's very difficult for us co-chairmen to know if we're about
           to close on something
   glazou: Sometimes we seem close to consensus, and then the discussion
           goes *rollercoaster sign*
   dbaron: Might be a little extreme, but.. try and put things on the agenda
   dbaron: ask people to respond by email if they have additional points
           to discuss
   glazou: Once 2.1 is out, things are going to change.
   dbaron: It will encourage people to read the agenda before the telecon
           and figure out what they think about things
   glazou: I think the past few months the agenda was a collection of
           potential discussion topics, but reality it was 2.1, period.
   alexmog: If we defer things for months, people working on css3 would
            take their own direction
   glazou: we don't have unlimited resources, sorry
   glazou: we do our best
   5 minutes break, then viewport discussion

Viewport Meta and CSS Syntax

   Rune introduces himself
   working at opera 10+ years
   Oyvind introduces himself
   Andreas: I'm Andreas, I lead our developer relations
   Andreas: I'm just here to listen
   <smfr> apologies, i won't be able to dial in for the viewport discussino
   <smfr> http://ajaxian.com/archives/the-css3-song

   Rune: I wrote an internal spec to explain how we implement the viewport
         meta tag that Safari implements
   Rune: I've also written a propsoed CSS syntax for that functionality
   Rune: Here's the URL to the proposal
   <dbaron> http://people.opera.com/rune/TR/ED-css-viewport-20100806/
   Rune: Not ging to go over proposal in detail, just have a couple of slides
   Rune: Problem is that in mobile browsers you have a very narrow viewport.
   Rune: If you format the page with the viewport as the ICB, most
         documents on the Web will look really bad
   Rune: What mobile browsers now do is use a different ICB, more like
         a desktop width
   Rune: Since the desktop width is being used, if page authors want to
         make pages specifically for smaller screens, they need to override
         that desktop width that the browser uses
   Rune: The current status is that Apple introduced a viewport meta tag
   Rune: Several browser vendors have made their own implementation
   Rune: Here's an example, you can specify a device width and set the zoom scale

   Bert: You set the initial zoom. That's the reader's business, not the author
   Bert: It's the wrong way around. If I want a specific width, I should
         just set this.

   Tantek: I strongly agree with your problem statement.
   Tantek: But what does this get you that max-width on the root element
           does not?
   fantasai: (or min-width?)
   Tantek: I think the meta tag idea was just dumb
   Tantek: If the author has set a max-width, the device didn't need to zoom
           out any more
   Tantek: There's no need for the meta tag
   Tantek: This was bad design by someone who did not understand how CSS works.
   Tantek: I'm addressing your third point -- the need for the author saying
           that a document is made to fit for smaller screen sizes
   dbaron: I think that's not entirely true.
   dbaron: Another problem that come up with pages that use this is pages
           that have a lot of text.
   dbaron: You really just want to read the text. You don't want to zoom out,
           and then zoom in to read the text.
   dbaron: It doesn't matter how wide the page is. You want the font size to
           be readable on the device.
   dbaron: In some cases you have a layout that works for anything from 150
           to 400 pixels
   dbaron: e.g. i want to read a newspaper article on a mobile phone
   dbaron: I just want the text readable. I don't necessarily want to set
           a max-width.
   Tantek: I agree that dbaron's use case is valid. But it's not the problem
           solved by viewport meta tag, which *is* solved by max-width.
   Tantek: I would like to see better guidance, with the UA understanding
           and using and trusting max-width on the root element.
   Tantek: That solves the common use case.
   Alex: fixed positioning is also not fixed by max-width

   glazou: Let's hear out the rest of the presentation, and we'll discuss
           that afterwards
   Rune: Proposed syntax is to standardize the viewport meta functionality
         in CSS syntax
   Rune: Proposal is an @viewport block similar to @page block
   Rune: Properties include width, hieght, minimum-scale, maximum-scale, etc.
   glazou: I suggest changing "initial-scale" to "zoom"
   Rune: Issues include fixed positioning
   Rune: Fixed positioning is defined relative to the viewport
   Rune: with a containing block that matches the ICB
   Rune: The actual viewport here won't be the same as the ICB
   alexmog: That's why we have this concept of a virtual viewport
   Rune explains how the small viewport moves around the virtual viewport,
      and then pushing it beyond that boundary causes the content to jump
   Rune: My propose defines an extra viewport. I'm not sure if it's a good
         idea to call it the viewport or not.
   Rune: Other issues are, is this out-of-scope for CSSWG?
   Rune: e.g. the scaling values
   glazou: I think it's in scope, just question of whether we want to work on it
   Rune: You can also argue that aturhos should make pages that look good
         on all devices in the first place
   Bert: The problem with this it that it breaks all pages that are designed
         to work on mobile browsers
   Bert: On my pages, my mobile browser worked fine, honored media queries, etc.
   Bert: But on Safari it doesn't work.
   Bert: I had to add this extra thing to make them readable.
   Bert: The ones that used to be readable on devices, no longer are readable.

   glazou: What is the interaction with Media Queries?
   Rune: The width and height media queries will match the ICB
   glazou: So what is the parsing order?
   fantasai: Paged media has the same problem with @page { size: ... },
             see spec text there
   fantasai: I share dbaron and bert's concerns about universal design
   dbaron: I tried to design a page for iPhone both on landscape and
           portrait mode, and failed
   dbaron: The logic of the implementation in Safari is somehow wrong
   Andreas: Does it behave differently if load it in portrait mode first
            vs landscape mode first?
+smfr over phone
   Tantek: I said that for the fixed width use case, the author can width
           or max-width today.
   Simon: I filed a bug on Apple, we just need to fix that.
   Tantek: For the device-width case, I do believe it belongs in CSS
   Tantek: I'll state for the record I proposed @viewport in 2004, and
           it was rejected :)
   Simon: I've been looking at feedback on the mailing list
   Simon: A problem is that a lot of the specs refer to a viewport
   Simon: This proposeal introduces 2 viewports, and you need to specify
          which viewport is being talked about
   Simon: And also the interaction between the 2 viewports needs to be specified.
   Rune: Yeah, I'm not sure if "viewport" is the right name
   Rune: esp. fixed positioning
   Simon: Fixed positioning is really difficult
   Simon: It gets really weird, especially with scaling
   Simon: Another concern I have is, I'm worried that we're settling on
          an implementation detail
   Simon: Some of them do real scrolling behavior, others do panning
   Simon: I'm worried that this is trying to specify something that
          different UAs will want to do differently.
   Tantek: There's wording around the way that overflow is specified in
           CSS that provides a lot of flexibility in how UAs do "scrolling"
   Tantek: I would like to see similar flexibility in this case as well.
   Tantek: So I think it's possible to address your concern.
   dbaron: So, with regards to how much of this to specify
   dbaron: I think one of the criteria of how much to specify is what's
           going to break web content if someone else decides to go do
           it differently.
   dbaron: I think for some of the things you mentioned in CSSOM View,
           there's only one way that'll make e.g. events work right
           wrt clientX, etc.
   dbaron: You have to go with the assumptions the pages are making
   Simon: Another thing is what authors need
   Simon: e.g. some use cases need getClientRects to be relative to
          the visual viewport
   Rune: I think in most cases you want things relative to the layout viewport
   Rune: I see the visual viewport as a peephole over the layout viewport
   Simon: I would survey current mobile browsers and see what they do
          in terms of scrolling, clientrects, etc.
   Rune: I have a comment about the scale values.
   Rune: The constraining procedure that has been taken from the Apple
   Rune: they alter the effect of the width and height values
   <tantek> for the record - my original thoughts on styling the viewport (from
     1998!) http://lists.w3.org/Archives/Public/www-style/1998Sep/0063.html
     and my proposal for @viewport with width and height properties from 2004:
   fantasai: One concern I have is that this proposal seems to allow only
             for specifying a fixed width and height.
   fantasai: I would like to see the ability to specify a range. Perhaps my
             layout is valid anywhere from 150px to 400px. Requiring the UA
             to display at exactly 320px is not going to give me the best
             display for the reader.
   Tantek: We could put this in CSS4 UI
   fantasai: or make a new module
   Rune: If we remove the CSS syntax, what I have is the viewport meta tag
   Tantek: How soon would you implement this?
   Rune: Well, we have to support the meta tag. We don't have any pressing
         reason to support @viewport
   Rune: It doesn't take too much time to implement it, but that depends
         on internal priorities
   howcome: I think the approach makes sense
   howcome: The big question is WebKit, what are they going to do
   dsinger: We're happy to discuss it
   glazou: My personal opinion is that it should be its own module.
   glazou: Should we add it to the scope of the new charter?
   howcome: Yes
   Tantek: Feels like something good to whiteboard during a break
   glazou: Should we add that to the charter?
   fantasai: yes
   what to call it?
   CSS Viewport?
   CSS Device Adaptation?
   steve: put it in the charter for IPR commitments
   Tantek: I think there's a level of urgency here
   Steve: So the answer is, IPR commitments apply only to things that become REC.
   Steve: There are two points where you can issue a call for exclusions.
          first one is FPWD, and the other is CR
   fantasai: So, Rune, will you edit the spec?
   Rune is hesitant
   RESOLVED: CSS Device Adaptation added to charter at medium priority,
             Rune to edit along with someone from Apple
Meeting closed.
Received on Wednesday, 1 September 2010 03:11:32 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:50 UTC