- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 31 Aug 2010 05:27:17 -0700
- 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:
CSS2.1
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 GCPM
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
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
jurisdiction.
RESOLVED: CSS Device Adaptation added to charter at medium priority,
Rune to edit along with someone from Apple
====== Full minutes below ======
Present:
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.
+jdaggett
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
text-decoration.
dbaron: I think webkit has a similar distinction.
glazou: howcome, opinion?
johnjansen: We'd prefer not to change our impl.
<alexmog>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!doctype%20html%3E%0D%0A%3Cspan%20style%3D%22color%3Ablue%3B%20%20text-decoration%3A%20underline%3B%0D%0A%22%3E01%0D%0A%3Cspan%20style%3D%22color%3Ared%3B%20%20%20text-decoration%3A%20underline%3B%20%0D%0Avisibility%3Ahidden%3B%22%3E11%0D%0A%3Cspan%20style%3D%22color%3Agreen%3B%20text-decoration%3A%20none%3B%20%0D%0Avisibility%3Avisible%3B%22%3E21%0D%0A
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
possible.
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
identifiers
<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
http://wiki.csswg.org/spec/css2.1#issue-197
<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
<runin><floatA/></runin>
<floatB/>
<block></block>
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
http://www.w3.org/TR/CSS21/visuren.html#run-in
"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
http://wiki.csswg.org/spec/css2.1#issue-199
<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
http://lists.w3.org/Archives/Public/www-style/2010May/0698.html
...
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
bolder/lighter
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
tests
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
reports
<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.
* gsnedders "YOUR WORKING GROUP NEEDS YOU!"
<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?
Yes.
scheduled charter discussion for after the break
<br/>
<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()
function.
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:
CSS2.1
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
Selectors
-> 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?
dropped.
CSS Flexbox
medium priority
CSS GCPM
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
<br/>
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.
-smfr
Rune: I have a comment about the scale values.
Rune: The constraining procedure that has been taken from the Apple
implementations
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:
http://lists.w3.org/Archives/Public/www-style/2004May/0294.html
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