IRC log of css on 2008-03-27

Timestamps are in UTC.

00:00:27 [fantasai]
00:00:38 [fantasai]
Molly: How can I explain to developers specificity if it isn't clear to me in the spec?
00:00:47 [fantasai]
Molly: I'd like to submit radical idea for this group
00:00:59 [fantasai]
Molly: There are some people here who have writing and explaining skills
00:01:11 [fantasai]
Molly: I see there's a problem in splitting the information
00:01:32 [fantasai]
Molly: But there could be someone who's an editor who checks that the language comes out in a way that makes sense
00:01:45 [fantasai]
Molly: And clarifies the sections of the spec that make sense to implementors but not to designers and developers
00:01:56 [fantasai]
Jason: Consistency across specifications is another issue
00:02:25 [fantasai]
Jason: some are very dense, others are entertaining but fluff
00:02:45 [fantasai]
Molly: I admire Richard for his work on i18n site
00:02:57 [fantasai]
Molly: The specs don't necessarily change, but the detailed articles change
00:03:03 [fantasai]
Molly: There's a process for improving them
00:03:14 [glazou]
ack tantek
00:03:15 [fantasai]
Tantek: I think that this kind of separation is a really bad idea for a number of reasons
00:03:29 [fantasai]
Tantek: Every spec I see at W3C that has primer vs spec is so complicated
00:03:43 [fantasai]
Tantek: It sends the wrong message: this is so complicated that they couldn't write it all in one spec
00:03:55 [fantasai]
Tantek: integrating information across two different URLs is so difficult
00:04:08 [fantasai]
Tantek: Even if the section numbering is the same, the cognitive load is so much more heavy
00:04:19 [fantasai]
Tantek: Any time you have 2 pieces of related text and you separate them
00:04:29 [SteveZ]
q Chris
00:04:30 [fantasai]
Tantek: The more you separate them, the greater chance that they become inconsistent
00:04:40 [fantasai]
Tantek: And you fall into the problem where they contradict each other.
00:04:53 [fantasai]
Tantek: If the goal is to have more consistent, non conflicting specs
00:05:02 [fantasai]
Tantek: then we don't want to split the specs
00:05:38 [fantasai]
Molly: I'm not saying we split the specs, but having someone else going through and helping to clarify and explain the confusing and complicated parts
00:05:51 [fantasai]
Tantek: marking things informative/normative -- great.
00:06:14 [fantasai]
Tantek: That makes it clear. Separating it makes it unclear.
00:06:33 [fantasai]
Tantek: The parts of CSS2 that are least interoperable are the ones where key pieces are separated.
00:06:56 [SteveZ]
00:07:13 [fantasai]
Molly: Consistent style, poor language and description, these are problems in our spec that we should fix
00:07:52 [fantasai]
Tantek: CSS1 is much more coherent. In CSS2, things are split up into different chapters that cross-reference each other.
00:09:00 [fantasai]
Steve: 3 points
00:09:27 [fantasai]
Steve: I disagree with Tantek on the split primer and spec issue because at least what I've found is that you can read the primer as a user and stop there until you get much more sophisticated
00:09:44 [fantasai]
Steve: It's much easier to get an overview in the primer
00:09:54 [fantasai]
Steve: I really think that whole thing is a red herring
00:10:03 [glazou]
anne: I would
00:10:06 [fantasai]
STeve: Do we need additional information beyond the normative part of the spec to get it across.
00:10:10 [fantasai]
00:10:23 [anne]
(personally, I think that if someone would like to write a primer, he should just go for it)
00:10:27 [fantasai]
Steve: We're discussing how to present this info rather than whether we need it
00:10:28 [anne]
(or she)
00:10:45 [fantasai]
Steve: A wiki mechanism would be able to provide background material
00:11:02 [fantasai]
Steve: wouldn't require publication procedures, and it can be an ongoing process of adding to it and editing it
00:11:11 [fantasai]
Steve: a place to point to people for understanding the spec
00:11:17 [molly]
00:11:21 [fantasai]
00:11:27 [alexmog]
this is (1) code (2) comments (3) documentation. (1) and (2) should stay together. (3) is a bonus
00:12:42 [jason_cranfordtea]
00:12:45 [fantasai]
Molly: As the author of over 35 books and many many articles,
00:13:11 [fantasai]
Molly: The books and articles have done very little because what happens is,
00:13:19 [fantasai]
Molly: The publishing industry is not working the way we do.
00:13:42 [fantasai]
Molly: If I have a book from 7 years ago that advocates techniques from 7 years ago and its still selling, the publishers won't take them down
00:13:47 [fantasai]
Molly: no matter how much we beg that they do
00:14:10 [fantasai]
Molly: We have a continual rality that the books and resources out there are going to go stale while .. moves forward
00:14:22 [fantasai]
Molly: THere's a huge gap between what we're doing, web standards doing, what companies are doing etc
00:14:32 [fantasai]
Molly: When it comes to specifications themselves as they are written and understood.
00:14:53 [fantasai]
Molly: When I sit down as an educator and I get to a passage that I can't understand, then I'm disempowered and I'm not going to reach the people who need to be reached.
00:15:22 [fantasai]
Molly: books are not reliable venues
00:15:39 [fantasai]
Molly: If you ask industry what is the authoritative group on web tech, they say W3C.
00:15:51 [fantasai]
Molly: We have some ethical duty that what we're putting out in the spec makes sens to people on some level.
00:16:24 [hyatt_]
wonders how opera got a 100/100 on acid3 when we're still finding bugs in the test. ;)
00:16:58 [anne]
hyatt_, no idea
00:17:02 [anne]
what bug?
00:17:03 [fantasai]
Jason: As the author of only 11 books..
00:17:11 [fantasai]
Jason: I'd disagree with Molly to a certain extent.
00:17:20 [fantasai]
Jason: I think that the books have the greatest influence on the design community.
00:17:31 [fantasai]
Jason: Any office I go to, they have all these web design books on their desk
00:17:42 [fantasai]
Jason: They keep them there and they reference thme and they have websites they go to
00:17:50 [plinss]
ack SteveZ
00:17:50 [fantasai]
Jason: None of them know the w3c or go to w3c
00:17:54 [plinss]
ack molly
00:17:58 [fantasai]
Molly and Jason distinguish developers and designers
00:18:09 [fantasai]
Jason: If you ask designers who decides how the web works, they'll say Microsoft
00:18:21 [fantasai]
Jason: They deal more with pracitaclities of what's going to get my design on the web.
00:18:43 [fantasai]
Jason: I do see a trend with more designers wanting to learn more about how to get from their prettypictures to getting it to work online.
00:18:56 [fantasai]
Jason: I totally udnerstand where you're coming from, it would be nice if we could be a repository for this knowledge
00:19:08 [fantasai]
Jason: BUt they're very different audiences that have very different needs.
00:19:38 [glazou]
00:19:41 [fantasai]
Chris: It would be highly useful to have a few more examples and explanatory text, these were alternatives considered and rejected because
00:19:49 [fantasai]
Molly: This discussion is why we're here.
00:21:00 [molly]
Fantasai: I agree w/ Tantek that splitting specs, I see more examples and explanatory is what makes our specs more readable than XML and something we should continue to do - not pulling them out into another document
00:21:10 [plinss]
ack fantasai
00:21:13 [plinss]
acl jason
00:21:19 [plinss]
ack jason
00:21:52 [molly]
Fantasai: Molly's got a point, there are places where this can be made more understandable to somebody who is not as technical as we are, but still happens
00:22:10 [molly]
Fantasai: Making the specs we have now more clear is a good idea, but splitting things up, no.
00:23:01 [plinss]
ack glazou
00:25:13 [fantasai]
Fantasai: We shouldn't be trying to make it easy for the designers to read, but remove the barriers, make it possible if they put the effort to try hard
00:25:21 [SteveZ]
00:25:41 [fantasai]
Peter: Putting more examples of why we put something in the spec would also make implementors more excited about implementing it
00:25:46 [anne]
tantek, != dbaron I think
00:25:57 [dbaron]
anne, I already told him
00:25:58 [tantek]
anne, yes, corrected. thanks.
00:26:08 [fantasai]
Steve: So.. we shouldn't think of creating a separate document for the implementor audience
00:26:17 [fantasai]
Steve: THat we probably don't need a separate document for the developer audience
00:26:38 [fantasai]
Steve: And there's a possibility of doing separate things for designer audience, but it's also worthwhile in the development of our specs
00:26:53 [fantasai]
Steve: to make them more readable by adding more example and non-normative sections that explain intent
00:27:37 [fantasai]
Steve: My concern is that in the interest of getting the spec out...
00:27:51 [fantasai]
Steve: There are pieces of the spec that are so hard to write in any form that they're bottlenecks in the schedule
00:28:04 [fantasai]
Steve: So while I support the goals, I wonder whether we're writing the best conclusion
00:28:31 [fantasai]
[Fantasai from previous: one of the reasons CSS specs are more understandable than XML is because they have explanatory text and examples]
00:28:44 [dbaron]
Do we need group policies on any of this, or can we leave it up to editors?
00:29:53 [fantasai]
Topic: At-risk Features
00:30:43 [fantasai]
Daniel: I just want to encourage us to use this more often as needed.
00:30:54 [fantasai]
Topic: Discussion Level
00:31:03 [fantasai]
Daniel: I would like us to keep the discussions at the technical leve.
00:31:17 [fantasai]
Daniel: We are not marketers, lawyers, etc.
00:31:24 [fantasai]
Daniel: We all want to push CSS forward. Let's do it.
00:31:28 [fantasai]
Topic: New Members
00:31:42 [fantasai]
Daniel: Last time we saw a representative from Dreamweaver was 8-9 years ago
00:31:53 [fantasai]
Daniel: They are still important in CSS editing
00:32:10 [fantasai]
Daniel: Microsoft has a nice CSS editor, but ExpressionWeb has not participated at all
00:32:25 [fantasai]
Daniel: It would be nice for these people to come and express the POV of editors
00:32:37 [fantasai]
Daniel: We want to increase critical mass.
00:32:46 [fantasai]
Daniel: Another point, we all know CSS is very powerful
00:32:53 [fantasai]
Daniel: especially the cascade, constraints, etc.
00:33:11 [fantasai]
Daniel: But CSS is very bad at allowing editors to provide one-click effects
00:33:23 [fantasai]
Daniel: Having the POV of WYSYWG editors would ehlp
00:33:27 [fantasai]
00:33:43 [fantasai]
Daniel: Usually they detect bugs in rednering engines because they are more in touch with authors.
00:34:11 [fantasai]
Alex: So we should bring more people?
00:34:22 [fantasai]
Daniel: invite them to come in from time to time if they have things to bring to the table
00:34:41 [fantasai]
Alex: We have bosses who are members of working groups but never participate
00:34:49 [fantasai]
Daniel: Good Standing status is individual
00:34:56 [fantasai]
Daniel: not company-wide
00:35:17 [fantasai]
Daniel: we have members who have never shown up to anything.
00:35:22 [fantasai]
Daniel: Peter and I are willing to review that
00:35:36 [fantasai]
Daniel: I understand that these people won't be members of wg all the time
00:36:01 [fantasai]
Alex: Some of these people might show up from time to time, but they won't be here
00:36:09 [fantasai]
Peter: That's ok, we still want their feedback
00:37:34 [chris]
For the purposes of Good Standing, the regular representative and the substitute are considered the same participant.
00:37:45 [molly]
See process spec
00:37:52 [chris]
00:38:30 [molly]
Peter: Quick call for any agenda items for next two days
00:38:42 [molly]
Daniel: One last one...
00:38:47 [dbaron]
plinss, css3-color
00:38:57 [molly]
Daniel: We have too many documents that reached last call without a test suite
00:39:19 [molly]
Daniel: Would like to see documents, even a template for links to the coverage report and test suite so we can fill that gap as soon as possible
00:39:48 [molly]
Peter: Provide links to test suites - once we have a harness, we should post links to where the test should be
00:39:54 [molly]
Anne: No, no, please no
00:40:55 [chris]
Yes, please, yes
00:41:10 [chris]
Kudos to Davis for adding tests while editing CSS3 Color
00:41:54 [tantek]
Thanks very much to David Baron for both updating CSS3 Color and adding tests.
00:42:24 [molly]
discussion: management of specs and tests
00:43:02 [molly]
Peter: Bring the two together a little bit so they make sense
00:43:26 [anne]
It was later clarified that single link to the test suite was intended. I have no problem with that.
00:43:50 [chris]
ok, good. glad we cleared that up
00:44:08 [molly]
Steve: The role of last call was supposedly a statement that there are no outstanding issues, and it's putting it to the community - the gap between last call and CR should be driving a lot test creation because it's now in theory stable enough to do that investment
00:44:31 [molly]
Steve: And also, the issue processing that David describe works there as well
00:44:34 [Bert]
The CR Exit Criteria have a sentence that refers to the test suite by name,that could be a link, that is almost zero work.
00:44:44 [chris]
00:44:44 [molly]
Peter: Shouldn't have to wait for last call for that however
00:45:19 [molly]
Agenda Items:
00:45:38 [molly]
Bert: First item mentions topics that haven't found a place yet
00:45:55 [molly]
Fantasai: We need a significant time to discuss syntax
00:46:04 [molly]
David: Do those need discussion or proposals
00:46:13 [molly]
Fantasai: Discussions, because we have alternate proposals
00:47:37 [molly]
Alex: Vertical tables
00:48:14 [molly]
Peter: I think we're done for the day!
00:48:22 [molly]
Peter, thank you, dinner at 7
00:49:54 [chris]
rrsagent, make minutes
00:49:54 [RRSAgent]
I have made the request to generate chris
00:51:54 [dsinger_]
bye guys, thanks for the transcript
00:52:03 [dsinger_]
much apreciated
00:52:27 [anne]
bye dsinger_
00:59:33 [hyatt]
hyatt has joined #css
01:04:38 [hyatt]
hyatt has joined #css
01:16:46 [anne]
anne has joined #css
04:12:15 [tantek]
tantek has joined #css
05:03:03 [tantek_]
tantek_ has joined #css
05:34:30 [Arron]
Arron has joined #CSS
05:35:14 [dbaron]
dbaron has joined #css
05:39:25 [tantek]
tantek has joined #css
05:46:26 [alexmog]
alexmog has joined #css
07:11:58 [mjs]
mjs has joined #css
07:24:26 [mjs_]
mjs_ has joined #css
07:44:16 [alexmog]
alexmog has joined #css
07:54:53 [bjoern]
bjoern has joined #css
16:17:56 [RRSAgent]
RRSAgent has joined #css
16:17:56 [RRSAgent]
logging to
16:18:01 [MoZ]
MoZ has joined #css
16:18:04 [dbaron]
RRSAgent, make logs public
16:18:08 [Zakim]
Zakim has joined #css
16:18:10 [dbaron]
Meeting: CSS Working Group Meeting, San Diego, CA
16:18:29 [dbaron]
Chair: Daniel Glazman, Peter Linss
16:18:37 [dbaron]
ScribeNick: jason_cranfordtea
16:18:47 [tantek]
16:19:11 [jason_cranfordtea]
Elika: asks if we are ready to begin posting public minutes?
16:19:19 [jason_cranfordtea]
General consensus is yes
16:19:23 [jason_cranfordtea]
Result is yes
16:19:32 [fantasai]
RESOLVED: Minutes will be public starting from now
16:20:06 [fantasai]
Topic: Next F2F
16:20:47 [jason_cranfordtea]
Alex: proposes sites for next Ftf
16:21:10 [jason_cranfordtea]
Cabridge, UK
16:21:15 [jason_cranfordtea]
Moscow, Russia
16:21:25 [jason_cranfordtea]
Redmond, WA, US
16:21:30 [jason_cranfordtea]
Discussion by group
16:22:09 [jason_cranfordtea]
RESOLVED: Cambridge, UK is first choice
16:22:28 [jason_cranfordtea]
Alex discusses dates
16:22:32 [jason_cranfordtea]
24th of July
16:22:36 [jason_cranfordtea]
or anytime in August
16:22:51 [jason_cranfordtea]
group discussion
16:22:55 [glazou]
I prefer august
16:23:06 [glazou]
Steve available only 3rd week of august
16:25:26 [jason_cranfordtea]
August 20 -22nd (Wednesday-Friday)
16:25:45 [jason_cranfordtea]
RESOLVED: August 20 -22nd (Wednesday-Friday) Tentative
16:26:56 [jason_cranfordtea]
Topic: Plenary Meeting for Fal
16:27:53 [jason_cranfordtea]
Proposed: October 20th-25th
16:28:06 [jason_cranfordtea]
Group discussion
16:29:17 [jason_cranfordtea]
Preference for Monday Tuesday
16:29:22 [glazou]
glazou has joined #css
16:29:30 [jason_cranfordtea]
SWteve: Can we meet Sunday?
16:30:12 [jason_cranfordtea]
Peter: Are there other groups we want at the planary?
16:30:56 [glazou]
16:31:54 [Bert]
For Oct ftf: SZ has conflict with AB (Th/Fr), ask for extra day on Sun? joint with SVG (filters)? joint with UWA (layout)?
16:32:13 [jason_cranfordtea]
Discussion about needed Apple participation to discuss their proposals
16:33:44 [jason_cranfordtea]
Steve will talk to contacts at Apple
16:34:05 [jason_cranfordtea]
Discussion about talking to Internationalization Group
16:34:44 [jason_cranfordtea]
Avoid overlap with Internationalization Group
16:35:28 [jason_cranfordtea]
Peter will but in reuest for previous Sunday meeting
16:35:40 [jason_cranfordtea]
TOPIC: Next year's conferences
16:36:14 [jason_cranfordtea]
Bert: talks about meeting next summer as cross between technical plenary and Web conference
16:37:07 [jason_cranfordtea]
Steve: ALA wants to do a co-event with W3C in Balonia (sp?) Italy for Web designers
16:37:39 [jason_cranfordtea]
Steve: event target Europe rather than US designers
16:38:03 [jason_cranfordtea]
"An Event Apart"
16:38:26 [jason_cranfordtea]
16:39:26 [jason_cranfordtea]
This even would be similar but for Europe
16:40:21 [dbaron]
16:40:28 [jason_cranfordtea]
Bert: In principal, are we interested in participating?
16:41:16 [fantasai]
Bert: We can have an F2F at the same place the week before/after
16:41:39 [jason_cranfordtea]
Molly: Opposed to being too closly aligned with any specific conference
16:42:20 [jason_cranfordtea]
Steve: wants to take discussion off-line for W3C input.
16:44:05 [Arron]
Jason: Agrees that there should not be any perception that we are aligned with any other conference
16:44:39 [jason_cranfordtea]
Jason: But does see benefit in showing that we are involved in the wider Web community
16:46:09 [glazou]
Bert and I don't live far away, we can make it for the conf if necessary
16:46:47 [glazou]
now, I don't feel confortable with aligning a CSS WG ftf meeting with a conf, we don't have to give a marketing stamp to a privately held conf IMHO
16:47:19 [jason_cranfordtea]
TOPIC: Mobile Profile ready to move to CR?
16:47:35 [jason_cranfordtea]
Bert: Can we publish?
16:47:44 [jason_cranfordtea]
Elika: No problem
16:48:35 [jason_cranfordtea]
Group discussion about current status
16:48:43 [jason_cranfordtea]
Bert: there is a test suite
16:49:12 [jason_cranfordtea]
Tantek: concern over bgs
16:49:40 [jason_cranfordtea]
Steve: Q for Tantek: are they CSS bugs or just bugs?
16:49:59 [jason_cranfordtea]
Tantek: Simple dumb bugs in test, NOT in CSS
16:50:59 [jason_cranfordtea]
Elika: People running test will complain, so we can catch that way
16:51:07 [jason_cranfordtea]
Tantek: opposite happening
16:51:38 [jason_cranfordtea]
Tantek: if marquee properies are not ready, not ready for CR
16:53:03 [jason_cranfordtea]
Danial: Do we have an agreement on the Mobile CSS profile?
16:53:20 [jason_cranfordtea]
Tantek: I do not see stuff that in the test suite but not in the profile
16:53:21 [Bert]
The MWTS WG's harness for the CSS Mobile Profile:
16:53:48 [jason_cranfordtea]
Bert: There is nothing in the profile that we do not have agreement
16:53:59 [jason_cranfordtea]
Bert: but marquee is in WD
16:54:19 [jason_cranfordtea]
Elika: Some items need more review
16:54:34 [jason_cranfordtea]
Elika: rewriting of vocab
16:55:00 [jason_cranfordtea]
Elika: spllit marquee and overflow to move Mobile profile forward
16:55:16 [jason_cranfordtea]
Elika: Box model needs more review
16:56:41 [jason_cranfordtea]
Elika: Suggestion create CSS overflow Level 3
16:58:03 [jason_cranfordtea]
Discussion about specifics of splitting out overflow
16:58:36 [jason_cranfordtea]
Elika: we need results
16:58:50 [jason_cranfordtea]
Q: Can we move Mobile forward to CR?
16:59:07 [jason_cranfordtea]
Tantek: Wants list of at risk to move forward to CR
17:00:46 [jason_cranfordtea]
RESOLVED: Mobile profile can move to CR as long as marquee and overflow are tagged as at-risk
17:01:24 [jason_cranfordtea]
Steve: They are at risk because their current document status of overflow and marquee would not allow the CR doc to go to PR
17:01:54 [anne]
ACTION to Bert to inform Svante of this decision
17:02:03 [jason_cranfordtea]
ACTION ITEM: Inform Svante to make decided upon edits
17:02:38 [jason_cranfordtea]
ACTION: Bert Inform Svante to make decided upon edits
17:02:38 [trackbot-ng]
Created ACTION-13 - Inform Svante to make decided upon edits [on Bert Bos - due 2008-04-03].
17:03:10 [SteveZ]
SteveZ has joined #css
17:03:31 [jason_cranfordtea]
ACTION: Jason delete first action
17:03:32 [trackbot-ng]
Created ACTION-14 - Delete first action [on Jason Cranford Teague - due 2008-04-03].
17:04:35 [dbaron]
Topic: Media queries
17:04:45 [jason_cranfordtea]
TOPIC: Are Media quarries ready to move to CR
17:05:47 [jason_cranfordtea]
Anne: discusses current status and tests
17:06:11 [jason_cranfordtea]
Anne: test need to be updated because of incomplete parsing rules
17:06:20 [jason_cranfordtea]
Davis: This is the second CR?
17:06:50 [jason_cranfordtea]
Anne: first in 2002. This is 3rd CR with further clarifications
17:07:42 [jason_cranfordtea]
Discussion of font size and root element
17:07:56 [jason_cranfordtea]
Decide to use default font
17:08:37 [dbaron]
em and ex units in media queries need to be relative to initial values of font properties (not values on root element, since style sheets can change those)
17:09:27 [jason_cranfordtea]
ACTION: Anne update media quarries - syntax, grammar, changes to parsing rules of HTML 4, grid feature
17:09:27 [trackbot-ng]
Created ACTION-15 - Update media quarries - syntax, grammar, changes to parsing rules of HTML 4, grid feature [on Anne van Kesteren - due 2008-04-03].
17:09:41 [fantasai]
(and 'em' 'ex' definition)
17:10:03 [anne]
scribenick: anne
17:10:33 [anne]
Topic: CSS Website Update
17:13:40 [anne]
Jason: Bert, Elika and I discussed updating the site some time ago. More organized, user friendly for different audiences.
17:14:00 [anne]
... Make it easy to find what you're looking for.
17:14:09 [anne]
Peter: PHP can be used and MySQL.
17:14:33 [anne]
Jason: Structured the page around primary tasks.
17:14:49 [anne]
... Specifications will be the primary focus.
17:15:10 [anne]
... CSS 2, errata, CSS 3, current work, and validation.
17:15:16 [anne]
... Profiles are also linked.
17:15:38 [anne]
... May want to change the profile links.
17:16:16 [anne]
... Also have links for contributing, tests, etc.
17:16:32 [anne]
... A search box, next to the navigation.
17:17:00 [anne]
... Also a list of languages that the site has been translated into.
17:17:10 [anne]
... (Initially hidden if we don't get the translations.)
17:17:31 [anne]
... "What is CSS?" block to give people a quick introduction.
17:17:54 [anne]
Daniel: Was it not on the lefthand side of the screen?
17:18:02 [anne]
Elike: it is the first in the source
17:18:12 [anne]
Jason: it will be given more visual prominence
17:18:44 [anne]
Jason: for a smaller screen the "What is CSS?" block will be on top
17:18:53 [anne]
Jason: it will be using media queries
17:19:30 [anne]
Elika: it will be using some cutting-edge features
17:20:28 [anne]
Daniel: since only Opera and Safari do media queries, maybe it's not good enough to base on that
17:20:55 [anne]
Jason: the non-mediaquery browsers will get the "What is CSS?" block on top
17:21:03 [anne]
... which seems acceptable.
17:21:51 [anne]
... Below the "What is CSS?" block we have a "What's new?" and "The world of CSS"
17:22:20 [anne]
... News stories, about us, etc. "The world of CSS" contains pointers to books, articles, etc. outside the W3C/CSS WG
17:22:32 [anne]
... Might want to break it down further.
17:22:44 [anne]
Molly: so this is clearly identified as "elsewhere"
17:22:46 [anne]
Jason: yes
17:23:17 [anne]
Jason: we don't have a CMS in place. Though now PHP / MySQL seems possible maybe there are options.
17:23:50 [anne]
Jason: could use WordPress
17:24:21 [anne]
Elike: I'd like to move the blog to WordPress
17:24:28 [anne]
Bert: what's wrong with Emacs?
17:24:33 [anne]
17:24:40 [anne]
Ming: Vi!
17:24:49 [anne]
[more laughter]
17:25:07 [anne]
Peter: I'd like a real CMS.
17:25:22 [anne]
Jason: Yeah, that's possible. We can use WordPress for all of that.
17:25:51 [anne]
Tantek: WordPress does have more IT-requirements unfortunately.
17:26:03 [tantek]
as anything with a database backend does
17:26:06 [anne]
Elika: We can wait a little bit with WordPress.
17:26:26 [anne]
Elika: should be ok to switch later
17:27:41 [anne]
Jason: we may want to add an image. Definitely need contact informatoin.
17:27:49 [anne]
17:28:15 [anne]
Jason: [goes through secondary pages]
17:28:41 [anne]
Jason: charter, about, contact, etc.
17:29:18 [anne]
Jason: "mood": flowing, transparent, layered, professional, informed (in a spiral)
17:30:28 [anne]
Steve: maybe add stylish
17:31:33 [anne]
Jason: new CSS logo idea
17:32:19 [anne]
Jason: uses "Futura"
17:32:48 [anne]
Jason: also used on the first moonlanding
17:34:19 [anne]
Jason: uses transparancy so it can be used on all kinds of colored backgrounds
17:36:23 [anne]
[some discussion on logo details; scribe hopes it's not too relevant for future generations]
17:46:15 [anne]
[new angle: use the logo or do a contest for designers]
17:46:32 [anne]
[part of the WG seems slightly bored]
17:49:03 [anne]
RESOLVED: we're doing a contest for the CSS logo
17:49:26 [fantasai]
RESOLVED: use logo with no missing squares as placeholder
17:49:50 [fantasai]
so we don't have to hold up the web site redesign waiting for the log
17:49:51 [fantasai]
17:50:14 [anne]
Topic: CSS Website colors
17:50:23 [anne]
[muted or vibrent]
17:50:30 [anne]
Steve: I don't like the green
17:50:43 [anne]
[some votes for muted]
17:51:10 [anne]
Topic: CSS Website Fonts
17:51:13 [anne]
17:51:26 [anne]
Jason: no image replacements, as pure CSS as a possibly can
17:52:12 [molly]
VI dammit
17:53:38 [anne]
Daniel: what about fonts on Linux?
17:53:42 [anne]
Molly: depends on the build
17:53:45 [anne]
Jason: I'll look into that
17:54:27 [anne]
... Georgia have a slightly older feel. Might replace Futura with Georgia
17:55:52 [anne]
... I think it comes down to font size, paragraph width
17:56:05 [anne]
... We'll be using lots of max- and min-width[s]
17:56:35 [anne]
Bert: can Gill Sants be mixed with Futura
17:56:39 [anne]
Jason: yes
17:56:52 [anne]
Jason: for the paragraph font I can use Gill Sants
17:57:16 [anne]
Bert: on the website we mostly use sans-serif
17:59:07 [anne]
Steve: Future and Trebuchet have different lengths
17:59:20 [anne]
Jason: I think for Future Medium and Trebuchet MS Bold this is ok
18:01:38 [anne]
Topic: site design
18:03:12 [anne]
[presents vibrant / muted]
18:03:23 [jason_cranfordtea]
jason_cranfordtea has joined #css
18:06:34 [jason_cranfordtea]
jason_cranfordtea has joined #css
18:07:08 [anne]
Jason: I'll provide weekly feedback
18:11:03 [anne]
Peter: check accessibility guidelines
18:12:18 [anne]
Daniel: one of the key entry points of the W3C is the validator
18:12:32 [anne]
Daniel: having information from the CSS group on the validator page would be good
18:13:31 [anne]
Jason: feel free to e-mail feedback
18:14:04 [jason_cranfordtea]
jason_cranfordtea has joined #css
18:32:25 [Zakim]
Zakim has left #css
18:32:52 [jason_cranfordtea]
jason_cranfordtea has joined #css
18:33:37 [Zakim]
Zakim has joined #css
18:34:00 [anne]
18:34:05 [dbaron]
18:35:18 [molly]
scribe: molly
18:35:27 [molly]
Topic: Box Module
18:36:52 [molly]
Bert: I took the text from 2.1. This is very complicated stuff, I'd like people to look it over and see if it works. Request anyone who understands height/width calculations to specifically look at the text
18:37:02 [Bert]
18:38:02 [molly]
Bert: So marquee split off / overflow
18:38:20 [molly]
Fantasai: properties stable
18:39:03 [molly]
Anne: There are at least four user agents that have implemented overflow-x overflow-y
18:41:33 [molly]
Bert: we need to be sure that overflow x/y are going to stay
18:41:40 [molly]
Anne: Web sites depend on them, they stay
18:41:48 [molly]
Bert: Okay, we'll put them in and find a way to make it work
18:44:11 [molly]
Alex: we treat x and y as width and height and we treat x as horizontal
18:45:01 [molly]
Alex: Top Left Width Height are physical
18:45:09 [molly]
Fantasai: We could introduce the stop and end properties
18:45:49 [fantasai]
start and end properties for margin/border/padding/etc
18:48:18 [molly]
Bert: Percentage on height property - auto if no defined height?
18:51:12 [fantasai]
Elika: Must be undefined because of table interactions
18:53:15 [molly]
David: For min/max height the same undefined way
18:53:32 [molly]
David and then when we go define it for height, min/max will pick up the definitions
18:54:36 [molly]
Bert: Intrinsic sizing
18:54:49 [molly]
Bert: there were some open sections - David?
18:55:04 [molly]
Bert: Section 10
18:55:43 [molly]
Bert: I think I've made a mistake somewhere, I'll check it out
18:55:50 [molly]
David: I'll need to look over this
18:56:02 [molly]
Bert: Are you going to give me more text about float and clear?
18:56:05 [molly]
David: On my list
18:56:13 [molly]
Bert: Box sizing wasn't handled yet
18:56:19 [molly]
Fantasai: I had a proposal there
18:56:52 [fantasai] discusses box-sizing
18:57:05 [fantasai] is my proposal
18:59:06 [molly]
Bert: Box sizing already exists
18:59:12 [molly]
David: You can have both
19:04:19 [Bert]
Jason: Is there a precedent for a "mode" keyword in a value?
19:04:38 [Bert]
Fantasai: Yes, text-indent with hanging.
19:04:56 [Bert]
Steve: It's more similar to shorthands.
19:05:18 [Bert]
Molly: Is the order of the keywords important?
19:05:22 [Bert]
severl: no
19:05:29 [Bert]
19:06:24 [Bert]
Fantasai: Point is that this works well with cascading.
19:06:56 [Bert]
Steve: What is the computed value?
19:07:11 [Bert]
Fantasai: it includes the keyword, thus length + keyword
19:08:27 [Bert]
David: This is useful for authors. The alternative is setting box-sizing globally. Anything else is confusing.
19:08:58 [Bert]
Jason: Can still override it later for a specific element, by using width again without a keyword.
19:09:31 [Bert]
Tantek: But it does change a fundamental assumption of how properties work.
19:09:37 [Bert]
David: What does?
19:10:51 [Bert]
[people trying to understand each other...]
19:11:16 [dbaron]
width: 50% border-box;
19:11:16 [dbaron]
width: 50% content-box;
19:11:16 [dbaron]
width: 50%; /* uses box-sizing */
19:11:44 [Bert]
Elike gives example:
19:12:07 [Bert]
.class1 {width: border-box: 50%}
19:12:21 [Bert]
.class2 {width: 40%}
19:13:14 [Bert]
class 1 gets border box even if box-sizing property is set differently.
19:14:06 [Bert]
And class2 gets what box-sizing set, without the need to set box-sizing in class1, which may potentially influence class2 as well.
19:14:25 [Bert]
Jason: What is the alternative?
19:14:47 [Bert]
Steve: Alternative is to be careful with box-sizing; basically set it everywhere you set width.
19:15:25 [Bert]
David: It's pretty easy to support both box-sizing and Elika's proposal.
19:17:21 [Bert]
Steve: So there is a value without a name that indicates neither border-box nor content-box, but means "use border-sizing"
19:17:53 [Bert]
Molly: This is difficult to understand for designers.
19:18:36 [Bert]
Anne: What about replaced images with 'width: border-box auto'?
19:19:10 [Bert]
Anne: There was an unwanted interaction between setting box-sizng globally and replaced images.
19:19:46 [tantek]
after discussing with David I understand what he is proposing and what David Baron is proposing makes sense to me.
19:20:05 [Bert]
Alex: The proposal affects the CSSOM. Currently width is a single value.
19:20:29 [Bert]
Anne: Width is already a string-valued property.
19:21:04 [Bert]
Alex: How about a proeprty 'border-box-width'?
19:22:15 [Bert]
Molly: How does all this work with cascading?
19:22:50 [Bert]
Fantasai: My proposal is designed specifically for help with cascading.
19:23:08 [Bert]
[More people not understanding each other]
19:23:33 [Bert]
[The important thing to remember is David's three lines above]
19:24:46 [Bert]
Steve: I would prefer thata there were an explicit keyword 'box-sizing' as well.
19:24:55 [tantek]
as long as we make it work the same way that border-color and color work, I think it's fine.
19:25:07 [tantek]
there is an explicit keyword currentcolor
19:25:07 [Bert]
Anne: But backwards compatibility with scripts that rely on there being just a number...
19:26:49 [Bert]
David: But it's slitghtly different from color/currentcolor, because color didn't have an explict value at all, while width still has a length as value.
19:27:25 [Bert]
[Fantasai explains difference between het keyword solution nd Alex's extra property solution]
19:27:31 [Bert]
19:27:37 [dbaron]
The situation that "required" currentColor was worse because it was a situation where border-top: medium solid gave 'border-top-color' (a property) a value that couldn't be specified.
19:27:40 [Bert]
19:28:01 [Bert]
19:29:10 [Bert]
Tantek: Designers usually want to use border-box on both width and height. Also an extra property is more difficult to use than an extra value.
19:29:40 [Bert]
Alex: Seems a redundant solution either way.
19:30:39 [Bert]
Tantek: there are cases where people normally think about boxer-box (forms...) and where they normally think about content-box.
19:31:41 [Bert]
Jason: It makes sense in some cases to specify the content width, in others the border width.
19:31:56 [Bert]
David: Currently designers hve to do the math.
19:32:05 [Bert]
19:32:24 [Bert]
Steve: What does getComputerStyle return?
19:32:39 [Bert]
David: Always the content width, I think.
19:32:48 [tantek]
my point about the extra property was stating that we don't need border-box-width and border-box-height vs. just box-sizing
19:33:08 [tantek]
about "extra property is more difficult" - adding extra properties is an unnecessary complexity
19:33:23 [Bert]
David: getComputedStyle has to work on used value.
19:33:29 [dbaron]
used content-box value
19:33:44 [Bert]
Steve: Should not break existing scripts.
19:34:58 [Bert]
Jason: Confused about border box width vs border width. I refer to visual width, usually.
19:35:10 [Bert]
[The terminology is from CSS1]
19:35:45 [Bert]
[Some discussion about need for padding-box as well, Tantek claims no.]
19:36:27 [Bert]
David: Can accept the proposal and still ask for better names.
19:36:52 [Bert]
Peter: Shoudl be consistent names between box-sizing and width keywords.
19:37:25 [Bert]
Molly: Nomenclature is very important. Designers don't use the CSS1 terminology.
19:38:48 [Bert]
Strawpoll: 8 in favour
19:39:24 [glazou]
daniel, tantek, david, jason, steve, arron, elika, peter
19:39:29 [anne]
19:39:38 [glazou]
1 abstain, molly
19:40:01 [glazou]
1 against, no answer
19:40:19 [glazou]
correction, 1 no anwer is Bert
19:40:23 [glazou]
1 against Alex
19:40:27 [fantasai]
RESOLVED: applies to min/max-width/height
19:40:27 [glazou]
==== LUNCH ====
19:40:28 [Bert]
Peter: Also applies to min-wifdth?
19:40:32 [fantasai]
RESOLVED: Names must be consistent with box-sizing
19:40:33 [Bert]
several: yes
19:40:37 [dbaron]
applies to min-width, max-width, width, min-height, max-height, and height
19:40:48 [dbaron]
and does not change the behavior of auto, fit-content, min-content, and max-content, and none
19:40:53 [Bert]
19:42:25 [anne]
yeah, so box-sizing:border-box works in Opera
19:42:31 [anne]
without prefix
19:42:38 [anne]
(padding-box doesn't)
19:42:42 [anne]
(nor margin-box)
20:22:27 [jason_cranfordtea]
jason_cranfordtea has joined #css
20:40:41 [SteveZ]
SteveZ has joined #css
20:40:59 [mjs]
mjs has joined #css
20:45:13 [SteveZ2]
SteveZ2 has joined #css
20:45:40 [tantek]
Any other issues on box model?
20:45:43 [glazou]
ScribeNick: tantek
20:45:46 [tantek]
Bert: Vertical centering
20:45:54 [tantek]
Tantek: agreed.
20:46:05 [tantek]
Elika: possible to extend vertical align to other boxes?
20:46:37 [tantek]
Jason: we have text-align and we have vertical-align
20:46:52 [tantek]
Jason: text-align center I can never figure out when it is going to center
20:47:11 [tantek]
Elika: depends on whether your image is inline or block
20:47:28 [tantek]
Elika: there are 2 centering discussions to have. 1 is horizontal alignment.
20:47:46 [tantek]
Elika: ... that is having a property to do horizontal centering rather than relying on margin:auto
20:47:56 [tantek]
Elika: ... and 2. there is vertical alignment/centering
20:48:11 [tantek]
Jason: maybe I need box align vertical and box align horizontal
20:48:39 [tantek]
Jaosn: I want a way to say center this box vertically in the page and horizontally in the page
20:48:44 [Bert]
I was wrong. The applies-to of vertical align doesn't say it applies to blocks. So we *can* generalize vertical-align.
20:48:53 [tantek]
correction: Jason: I want a way to say center this box vertically in the page and horizontally in the page
20:49:30 [tantek]
Elika: centering absolutely positioned elements is different than centering in flow elements
20:50:01 [tantek]
Alex: GCPM (page) floats and float-offset covers some of these scenarios
20:50:10 [tantek]
GCPM = generated content paged media
20:50:33 [tantek]
Elika: if we extend vertical-align to boxes other than table cells I think it will be awesome
20:50:45 [tantek]
Steve Zilles: it's not clear that's what you want
20:52:01 [tantek]
Tantek: I think if you try to extend vertical-align to apply to blocks you will run into TONS of compat problems - existing pages that happen to set vertical-align on blocks, and having that all of a sudden do something will break those pages.
20:52:40 [alexmog]
3 issues
20:52:40 [tantek]
Steve: it is unfortunate that vertical-align applies in table cells both to the alignment of the cell and the alignment of lines in the cell
20:52:40 [alexmog]
1)Horizontal center for blocks: block-align:center
20:52:40 [alexmog]
2)Vertical align for blocks: block-vertcial-align:middle
20:52:40 [alexmog]
3)Centering and overflow: shift or still center?
20:52:49 [tantek]
Alex: there are three problems that are related
20:53:02 [tantek]
Alex: 1)Horizontal center for blocks: ‘block-align:center’
20:53:11 [tantek]
Alex: 2)Vertical align for blocks: ‘block-vertcial-align:middle’
20:53:17 [tantek]
Alex: 3)Centering and overflow: shift or still center?
20:53:20 [fantasai]
20:53:53 [Bert]
(XSL uses display-align:
20:53:55 [fantasai]
20:54:21 [tantek]
Elika: if you want to design an alignment property, here are the issues you need to apply
20:55:15 [tantek]
Steve: so how do we make progress on this?
20:55:17 [fantasai]
Markus started a discussion about an alignment property to standardize on syntax to implement <CENTER>. The property affects the alignment of boxes, not of text within the boxes, and it inherits. Unsettled details include:
20:55:21 [fantasai]
20:55:24 [fantasai]
Whether the property affects the element's alignment within its parent or its descendants' alignment within itself. Proposed that it should affect the element.
20:55:27 [fantasai]
20:55:29 [fantasai]
What alignment possibilities are represented as values. Proposed that the left/center/right/start/end set be adopted.
20:55:32 [fantasai]
20:55:35 [fantasai]
One set: left | center | right
20:55:37 [fantasai]
20:55:40 [fantasai]
Another set: left | center | right | start | end
20:55:42 [fantasai]
20:55:45 [fantasai]
A more complex set that includes top and bottom values that apply in vertical layout. (Such a set should allow specifying e.g. both top and left at the same time, where one takes effect in vertical text and the other in horizontal text.)
20:55:49 [fantasai]
20:55:51 [fantasai]
Any of the above sets with percentages as an added possibility.
20:55:54 [fantasai]
20:55:56 [fantasai]
What the property is named. alignment is the working name. An alternative would be horizontal-align, to be consistent with vertical-align.
20:55:59 [fantasai]
20:56:02 [fantasai]
Whether alignment triggered by this property is “true” alignment, or if it only affects blocks smaller than their containing block.
20:56:05 [fantasai]
20:56:07 [fantasai]
If the property triggers “true” alignment, then a value that triggers current behavior must be the default. The disadvantage of this is that most authors will not realize use of this property can cause their content to become inaccessible in some window configurations.
20:56:12 [fantasai]
20:56:15 [fantasai]
If the property does not trigger “true” alignment, then an additional keyword (or several keywords) could be defined to trigger true alignment (e.g. alignment: left vs. alignment: true left). In this case both alignment behaviors are possible, and the default behavior emphasizes accessibility.
20:56:20 [fantasai]
20:56:22 [fantasai]
How this alignment interacts with the current margin calculations. Possibilities include:
20:56:25 [fantasai]
20:56:28 [fantasai]
alignment trumps auto margins: auto margins are set to zero and then the box is aligned as specified.
20:56:31 [fantasai]
20:56:33 [fantasai]
alignment defers to auto margins: it only affects blocks without auto side margins. (Note that the default margin is '0'.)
20:56:36 [fantasai]
20:56:39 [fantasai]
How alignment interacts with specified margins
20:56:41 [fantasai]
20:56:44 [fantasai]
alignment replaces specified side margins with auto as appropriate to effect specified alignment
20:56:47 [fantasai]
20:56:49 [fantasai]
alignment shifts the margin box, leaving specified margins intact
20:56:59 [tantek]
Bert: I would like to see a decision on how to do vertical centering alignment.
20:57:31 [tantek]
Tantek: I suggest something visual
20:57:51 [tantek]
Elika: I suggest something that works like vertical-align on table cells but applies to blocks
20:58:40 [glazou]
the new property would align vertically the contents of the cell, but w/o relationship to other cells
20:58:47 [tantek]
Alex: whatever applies to vertical align should have some symmetry for horizontal align
20:59:05 [tantek]
Alex: perhaps a shorthand property block-align for handling both
20:59:24 [tantek]
Bert: yes, it is possible but it is a mess, quite complex
20:59:57 [tantek]
Alex: combinations of <center> element, text-align, and margin:auto causes as much complexity already as if we would have to do a block-align property
21:00:32 [tantek]
David: the easy solution is that margin:auto wins
21:00:45 [tantek]
Alex: we solve this with an additional set of hidden margins
21:01:18 [tantek]
David: you center the margin box within its containing block
21:01:42 [tantek]
Steve: that gives you the most control so you can adjust the item that is being centered
21:01:58 [dbaron]
margin:auto wins isn't quite adequate, actually, since it's really like a second set of margins that handles the case when neither margin is 'auto'
21:02:20 [tantek]
Alex: I like property that has specific effect
21:02:30 [tantek]
Alex: the <center> element is pretty weird in that sense
21:03:22 [tantek]
Tantek: I reraise request for someone drawing something visual
21:03:33 [tantek]
Tantek: while we discuss alignment, centering etc.
21:03:44 [tantek]
(Steve Zilles gets up to the whiteboard)
21:04:40 [tantek]
Anne: <center> element appears to apply to children but not itself. <center> element doesn't center itself, but centers its children.
21:04:54 [tantek]
Steve: write example on whiteboard:
21:04:58 [fantasai]
Elika: Can do that with center > * { block-align: center; }
21:05:06 [tantek]
21:05:21 [tantek]
div { height: 200px; width: 200px }
21:05:27 [tantek]
p { block-align:center }
21:05:55 [tantek]
Anne: the HTML <center> element centers its descendants
21:05:59 [Bert]
Daniel: How to center the content of a block if that content is only text?
21:06:03 [anne]!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%20center%20{%20border%3Adotted%201px%3Bwidth%3A200px%20}%0A%20div%20{%20width%3A50%25%3B%20border%3Asolid%20}%0A%3C%2Fstyle%3E%0A%3Ccenter%3E%3E%3Cdiv%3E%3Cdiv%3Ex%3C%2Fdiv%3E%3C%2Fdiv%3E%3C%2Fcenter%3E
21:06:14 [Bert]
s/center/center vertically/
21:06:37 [tantek]
(laughter at the URL in IRC)
21:07:10 [tantek]
Steve: are we talking about horizontal or vertical
21:07:13 [tantek]
Peter: yes.
21:07:17 [tantek]
21:07:27 [tantek]
David: call it (holds up a coin) heads means horizontal
21:07:39 [tantek]
David: the toss is heads - horizontal
21:09:01 [tantek]
Steve: it is too difficult to discuss both at the same time, thus it is easier to discuss one at a time.
21:10:08 [tantek]
Steve: if auto margins worked, we wouldn't be discussing this.
21:10:14 [tantek]
David: the one element case is a case where you can
21:10:31 [tantek]
Steve: the problem is when the container is smaller than its parent
21:10:43 [tantek]
correction: Steve: the problem is when the container is smaller than its child
21:10:55 [tantek]
Bert: currently you are unable to align things
21:11:18 [anne]
(<div align=center> is equivalent to <center> in centering behavior)
21:11:18 [tantek]
Daniel: if you center the block then it's easy, you center the block inside its parent
21:11:37 [tantek]
Elika: do it like background
21:12:03 [tantek]
Elika: if we want true center alignment, the author should have to make a conscious choice of what happens when it overflows.
21:12:21 [tantek]
Tantek: Jason what do you think?
21:12:25 [tantek]
Jason: I'm thinking.
21:12:29 [tantek]
Alex: you should have both options
21:12:39 [tantek]
Tantek: I disagree, only options for which there are known use cases.
21:12:50 [tantek]
David: everybody wants one thing out of this property and it is different for each person.
21:13:01 [tantek]
Bert: I didn't actually want to discuss this. I was asking about vertical alignment
21:14:03 [tantek]
Jason: What is happening with these two boxes?
21:17:22 [tantek]
Anne hooks up his laptop to the projector to show examples
21:17:46 [fantasai]
Anne: The job of the center element is not to center itself, but to center its descendants
21:19:22 [fantasai]
Anne: text is also centered, but that should be left to text-align
21:19:24 [tantek]
Anne: shows example that all block descendants of <center> are centered
21:19:38 [tantek]
Anne: inline text is also centered, but that's already handled by text-align
21:21:22 [tantek]
Anne: also, <div align="center"> works the same as <center>
21:22:06 [tantek]
Bert: is the requirement to reproduce this?
21:22:57 [tantek]
Anne: authors are used to this behavior, and thus perhaps it would be good to have an equivalent for <center> in CSS
21:23:17 [tantek]
Bert: this seems like it affects too many things at once
21:23:45 [tantek]
Anne: this can be handled by simply defining a UA style sheet rule for the <center> element
21:23:51 [tantek]
Bert: should it be inherited?
21:24:29 [tantek]
David: what authors want is to just center align everything, and thus is is easier if you just make it inherit
21:24:40 [tantek]
Elika: it is hard to undo inheritance
21:24:50 [tantek]
David: it is harder to undo universal selectors if you are forced to use them
21:25:27 [tantek]
Steve: if you have to override it then you have to fix all child siblings
21:25:39 [glazou]
you can use #topmost { block-align: center } and #topmost * { b-align: inherit } and the property does not apply to all decendance
21:25:56 [tantek]
Bert: it does seem we want a separate property
21:26:06 [tantek]
Steve: we are going to need it for vertical
21:26:15 [tantek]
Steve: and not having the same thing for horizontal would be confusing
21:26:27 [tantek]
Bert: are there any other values?
21:26:30 [tantek]
Anne: left and right
21:26:42 [tantek]
Bert: that's handled by margin auto
21:26:48 [tantek]
Tantek: unintuitive and hard to teach people
21:27:12 [tantek]
Bert: do we need start and end?
21:27:17 [tantek]
Daniel: yes
21:27:27 [fantasai]
left | right | center | start | end
21:27:29 [fantasai]
default is start
21:27:37 [tantek]
Tantek: I thought the start end thing was orthogonal, that that applied to lots of properties
21:27:47 [tantek]
Jason: sounds like to me we need something like clear for alignment
21:27:57 [tantek]
Jason: so that you could assign an element to stop aligning
21:28:09 [tantek]
Anne: that would be block-align:initial
21:28:15 [tantek]
David: if it inherits
21:28:29 [tantek]
Peter: what happens if there is a sibling to the inner div (in the example on the whiteboard)
21:29:43 [Bert]
'block-align: left; margin-left: auto' is that left or right aligned? Currently it is right.
21:30:32 [tantek]
if it is not inherited, we couldn't use this to handle div align=center
21:30:43 [tantek]
David: if it is not inherited, we couldn't use this to handle div align=center
21:30:51 [tantek]
David: it would be too inefficient
21:30:59 [tantek]
David: we need to use the fast mechanism of inheritance for this
21:31:04 [tantek]
Tantek: I tend to agree with David
21:32:25 [tantek]
Alex: you can control them separately
21:32:34 [tantek]
Anne: the question is you have a block box
21:32:39 [tantek]
Anne: h1 and div that are siblings
21:32:47 [tantek]
Anne: if you want to align the h1 to the left
21:32:49 [tantek]
Anne: and the div to the right
21:33:04 [tantek]
Anne: that would not work with block-align that only works to its children
21:33:11 [tantek]
Steve: the same problem will arise vertically.
21:34:01 [tantek]
Steve: maybe we should give up on horizontal as unnecessary to solve at this point and look at vertical
21:34:15 [tantek]
Anne: I think it is clear because of the way div align="center" works
21:34:30 [tantek]
Steve: it may not match the way we want to go in the future
21:34:51 [tantek]
Steve: if we are going to introduce block align vertical we should try to make it compatible with block align horizontal
21:35:06 [tantek]
Arron: are we comfortable with how block align works here and now talk about vertical
21:35:07 [dbaron]
For what it's worth, we have 6 different lists of values of the align attribute in HTML.
21:36:09 [tantek]
David: what is it there that you can't do with margin auto?
21:36:21 [tantek]
Bert: it works only when the containing block is wide enough
21:36:31 [tantek]
Elika: you can do that, you just need a shrinkwrap keyword
21:37:09 [tantek]
Anne: given that this is the behavior that authors are used, I'm not sure what the harm is in giving them a CSS way to do the same thing
21:37:18 [tantek]
Anne: I think all use cases have been addressed, have been done.
21:37:22 [tantek]
Alex: I agree there
21:37:34 [tantek]
Peter: I want blockquotes centered, but text left aligned
21:37:48 [tantek]
Anne: that can be done with margin auto
21:38:26 [tantek]
David: I need to see the example
21:40:44 [tantek]
(Anne updates example on screen)
21:43:02 [anne]
Steve: block-align would apply to children, be inherited, and margin would allow you to override it on children
21:43:17 [tantek]
Peter: the only thing that bugs me about this is that if we are using margin auto to force the behavior of block alignment then why are we doing block-align
21:43:30 [tantek]
David: margin auto is for one element. block alignment for all descendants of that element.
21:44:28 [tantek]
Jason: I can see the case for both, where I want it centered all the way down, and I can see it needing it specifically on specific elements. There needs to be a better way than margin auto
21:44:39 [tantek]
Jason: because margin auto is not an intuitive way to do it
21:44:53 [tantek]
Jason: to me it is very simple: block align horizontal - I want it centered.
21:46:02 [tantek]
David: the distinction is one element vs. subtree thing
21:46:15 [tantek]
Peter: as long as you handle overflow situations, I'm ok with that distinction
21:46:26 [tantek]
Jason: again it gets back to the intuitiveness of margin auto - that's the problem.
21:46:53 [Zakim]
Zakim has left #css
21:47:09 [tantek]
Steve: I have some text that is left aligned, then a nested blockquote which is centered, and then an attribution on the right.
21:49:57 [fantasai]
Elika: Use case: centering shrink-wrapped table with margins
21:50:06 [fantasai]
Elika: when lots of content, still have some spacing on sides
21:50:17 [fantasai]
Elika: when small content, table is still centered, not left-aligned
21:50:33 [tantek]
Tantek: you could make it work with block-align applying to the element itself
21:52:03 [tantek]
(lots of discussion of block-align applying to the block itself, or children, or both, and/or inheriting)
21:53:12 [tantek]
Alex: we already have two ways to center, I'm not sure we have justification for a 3rd way
21:53:18 [tantek]
Peter: the HTML way is deprecated
21:53:26 [tantek]
Peter: we don't want new documents to use it
21:53:44 [tantek]
Anne: yes, and therefore having a CSS way would solve that
21:53:50 [tantek]
Steve: your point is valid.
21:54:33 [tantek]
Anne: given that all implementers would like to implement this property, child-block-align, we could all do prefixed versions -ms-child-block-align, -moz-child-block-align etc., or we would just all agree on one and do it the same.
21:55:13 [tantek]
Tantek: sounds like you (Anne) want to write up a child-block-align proposal with a URL
21:55:25 [tantek]
Elika: I think Anne is right, but it doesn't solve all the use cases
21:55:31 [tantek]
Anne: we couldn't think of one that it doesn't.
21:55:48 [tantek]
Steve: it doesn't do that one (blockquote and cite)
21:55:54 [tantek]
Elika: it doesn't solve mine.
21:57:22 [tantek]
Peter: we have taken an hour and a half so far
21:57:29 [tantek]
Tantek: are going to talk vertical now?
21:57:33 [tantek]
Bert: that's what I wanted to talk about
21:57:45 [tantek]
Steve: I want to express a straw poll
21:58:00 [tantek]
Steve: at least three of us say that block-align applies to the margin box
21:58:06 [tantek]
Steve: anyone disagree with that?
21:58:10 [tantek]
21:58:18 [tantek]
Steve: ok, resolution, it is the margin box that is positioned
21:58:28 [tantek]
Elika: it looks like we need two properties to address this
21:58:53 [tantek]
Elika: one, make current uses cases accessible, and two the centered, shrinkwrapped table case
21:59:03 [tantek]
Tantek: we are still talking horizontal right?
21:59:09 [tantek]
Steve: yes we are still talking horizontal
21:59:28 [tantek]
Tantek: someone needs to write up a proposal
22:00:32 [fantasai]
ACTION Elika write centering proposal for 2 properties
22:00:58 [tantek]
ACTION: Elika write block-align centering proposal
22:00:59 [trackbot-ng]
Created ACTION-16 - Write block-align centering proposal [on Elika Etemad - due 2008-04-03].
22:01:19 [Bert]
(See for an ilustration where centering with auto margins doesn't work.)
22:01:47 [tantek]
ACTION: Elika write child-block-align centering proposal
22:01:47 [trackbot-ng]
Created ACTION-17 - Write child-block-align centering proposal [on Elika Etemad - due 2008-04-03].
22:02:06 [tantek]
Bert: I did integrate and update Markus's proposal into the box model module
22:02:48 [tantek]
break before we switch to vertical
22:02:51 [anne]
22:02:51 [anne]
22:03:03 [anne]
22:03:04 [tantek]
Peter: 15-20 min break
22:03:24 [Bert]
Alignment property in current Box Module:
22:33:37 [tantek]
resume meeting
22:33:49 [tantek]
Elika goes to the whiteboard to start discussion of vertical alignment
22:36:21 [tantek]
discussion of vertical margins vs. horizontal margins
22:37:52 [tantek]
discussion of vertical text layout applying to this situation - and noting that it is orthogonal and an issue that needs to be more broadly discussed
22:38:41 [Bert]
[Questions about margin collapsing: is 'block-align: top' the default or 'block-align: auto'? I.e., does 'top' cause collapsing margins?]
22:39:10 [tantek]
David: I don't see the use case for introducing block-vertical-align:top as something distinct from the default behavior now
22:39:35 [tantek]
Alex: if you set this on the body, and you want the behavior of the child element to be same as the float, you would expect margin collapse
22:39:53 [tantek]
David: floats are going to be hard for this. does block-vertical-align affect floats
22:40:09 [tantek]
David: if the block has a first child that is a float?
22:40:10 [tantek]
Alex: layout everything and then ...
22:40:15 [Bert]
'block-align: top; margin-top: 1em'
22:40:22 [tantek]
David: maybe if there is a new block formatting context
22:41:11 [dbaron]
nasty case is floats protruding into block
22:41:22 [tantek]
Steve: what happens with floats from the block above protruding into the next vertical block?
22:41:23 [dbaron]
because layout and then slide around doesn't work
22:41:56 [tantek]
Alex: I think if you say it is a new block formatting context, everything becomes simpler.
22:41:59 [tantek]
David: yes
22:42:41 [tantek]
Alex: so we need 4 different values
22:42:52 [tantek]
Steve: why does creating a new block formatting context solve the problem?
22:43:03 [tantek]
David: float protrusion is ignored across block formatting contexts
22:43:25 [tantek]
David: the whole block simply doesn't overlap the float
22:43:30 [tantek]
Steve: it's like an implicit clear
22:43:40 [tantek]
Elika: no, you might end up with things next to each other
22:43:49 [tantek]
Steve: then it's like table
22:43:51 [tantek]
David: yes
22:45:34 [tantek]
Elika: people will use this to turn off margin collapsing
22:47:54 [tantek]
Bert: I just had a strange idea, instead of a new property block-align, add display value centered-block
22:48:15 [tantek]
David: what if you want to center an inline-block or table etc.
22:48:30 [tantek]
Steve: I can't support that either because I think it overloads display too much
22:48:32 [dbaron]
table cell
22:48:49 [tantek]
Steve: so we had, Alex wanted four values
22:48:59 [tantek]
Alex: anything other than "none" introduces a block formatting context
22:49:07 [tantek]
Alex: we do normal layout in that context
22:50:06 [tantek]
Alex: if the distance between the top margin of the first child and the bottom margin of the last child is smaller than the vertical space within the element, then we can align to bottom or middle.
22:50:10 [tantek]
Bert: if it is more...
22:50:21 [tantek]
Alex: if it is more, then we get into the issue of centering something that doesn't fit
22:50:27 [tantek]
Bert: the question is which side does the overflow go on
22:51:07 [tantek]
Steve: the only way we can introduce this property is if the default is "do what we do today"
22:51:31 [tantek]
Tantek: I'm asking for a picture at this point
22:52:18 [tantek]
Alex goes to whiteboard
22:52:26 [tantek]
Alex draws example of what he just said above
22:52:36 [tantek]
Steve: so we include the margins as part of the chunk that is aligned?
22:52:39 [tantek]
Alex, others: yes
22:53:23 [tantek]
Alex draws a float
22:53:27 [fantasai]
Insert above Steve's "the only way" comment: Elika: How does this interact with vertical-align on table cells? I think you need the default to be 'auto' which means honor vertical-align on table cells
22:54:14 [tantek]
Bert: does this apply to table cells?
22:54:30 [tantek]
Alex: it should apply to everything
22:54:41 [tantek]
and if both are applied, I'm not sure
22:54:54 [tantek]
Alex: if both are applied, the new property wins
22:55:01 [tantek]
Bert: similar case, advanced layout, how do you center something in a grid cell?
22:55:06 [tantek]
Bert: is that vertical-align or a new property
22:55:19 [tantek]
Elika: the advantage of vertical-align is a baseline value which you might want
22:55:28 [tantek]
Alex: you have to have a baseline for that
22:55:37 [tantek]
Alex: as long as you can define what a baseline is for a group of cells
22:55:49 [tantek]
Alex: in advanced layout that would be an interesting challenge
22:55:55 [tantek]
Alex: no that is not going to work
22:58:07 [tantek]
Bert: I don't know any designer that doesn't want baseline alignment.
22:58:16 [tantek]
Elika: you don't need to use advanced layout for that
22:58:28 [tantek]
Bert: may or may not
22:58:40 [tantek]
Elika: in Jason's layout you may want to have them align
22:59:27 [fantasai]
s/for that/for tabular data or name-value pairs/
23:00:42 [tantek]
Bert: who is going to write up the vertical case?
23:00:51 [tantek]
Steve: the hard part of the vertical case is what it is that we do today
23:01:34 [tantek]
Action: Alex write up the four value proposal for vertical alignment for the block-align property.
23:01:34 [trackbot-ng]
Created ACTION-18 - Write up the four value proposal for vertical alignment for the block-align property. [on Alex Mogilevsky - due 2008-04-03].
23:02:26 [tantek]
Peter: next subject
23:02:39 [tantek]
Peter: page break
23:03:53 [glazou]
ScribeNick: Bert
23:04:16 [Bert]
Elika explains page-break-inside issue
23:07:56 [Bert]
Some use cases...
23:08:29 [glazou]
Elika discusses the need for inheritance of 'page-break-*: avoid'
23:08:39 [Bert]
Argues for not inheriting the property.
23:10:08 [Bert]
Steve: XSL adds a strength to its "keeps" (which are like page break avoid)
23:10:34 [Bert]
Peter: Could als have additive strength: every child can add to the strength.
23:10:55 [Bert]
Steve: yes, then you break ate the lowest strength brek point by preference.
23:11:36 [Bert]
Alex: We are willing to reverse the CSS 2.1 implementation.
23:12:02 [Bert]
David: How de we get in this situation?
23:12:23 [Bert]
David: with different implementations doing inheritance or not.
23:13:08 [fantasai]
23:13:16 [fantasai]
23:13:58 [Bert]
23:14:29 [Bert]
Fantasai: Could add a strength factor later.
23:16:49 [fantasai]
I did not say that
23:16:52 [Bert]
Alex: It is probabbly not possible to find the bext break point without a O(n^2 ) algorithm.
23:16:59 [fantasai]
Fantasai: Could make nested avoids stronger later
23:17:37 [Bert]
Alex: An explicit property is probably better than a complicated algorithm.
23:18:34 [Bert]
Alex: Our plan is to ignore the proeprties when no page break is allowed and find a page break then.
23:19:27 [Bert]
Alex: Maybe not try to solve that problem now.
23:19:34 [Bert]
Fanatasai: But leave possibility open.
23:19:45 [anne]!DOCTYPE%20html%3E%0D%0A%3Cstyle%3E%20%23x%20%7B%20page-break-inside%3Aavoid%20%7D%20%3C%2Fstyle%3E%0D%0A...%3Cdiv%20id%3Dx%3E%20%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0D%0A%3Cscript%3E%20w(getComputedStyle(document.getElementById(%22y%22)%2C%22%22).pageBreakInside)%20%3C%2Fscript%3E shows that Opera does inherit page-break-inside:avoid at least for getComputedStyle purposes
23:20:41 [Bert]
Alex: Even if we define this better, there will not be perfect interop. We would also need line height more interoperable.
23:21:23 [Bert]
Alex: I expect we will not do the strength. Would prefer to honor a 'allow' value.
23:21:48 [Bert]
Steve: XSL is implemented and works, with strengths.
23:21:52 [dbaron]
It's nice to see that 13.3.3 and 13.3.4 say page-break-before and page-break-after both apply on both sides of the box
23:22:33 [Bert]
Peter: So we make minimal change in CSS 2.1 and do more later.
23:25:00 [Bert]
David: This change requires a new last calll.
23:26:02 [Bert]
Peter: We can go to last call and only accept comments on the specific change.
23:26:34 [Bert]
Fantasai: But white space in tables might also require a last call.
23:27:01 [fantasai]
* In CSS2.1 make page-break-inside not inherit anymore, but still
23:27:01 [fantasai]
discourage breaks inside its descendants: basically avoid breaking
23:27:01 [fantasai]
at a break point with a page-break-inside: avoid ancestor (rather
23:27:02 [fantasai]
than direct parent).
23:27:47 [fantasai]
-- 'page-break-inside' no longer inherits
23:27:47 [fantasai]
-- 13.3.3 rule D says
23:27:47 [fantasai]
Rule D: In addition, breaking at (2) is allowed only if the
23:27:47 [fantasai]
'page-break-inside' property is 'auto' <INS> and no ancestor
23:27:47 [fantasai]
has a 'page-break-inside' property of 'avoid'.</INS>
23:28:50 [Bert]
Steve: I'm opposed to the change.
23:30:49 [Bert]
Bert: I'd rather not change either.
23:32:13 [Bert]
Steve: A last call cannot be restricted to just one change, must accept comments on everything.
23:34:58 [Bert]
Anne: The test case doesn't seem to test what Elika proposes.
23:36:13 [fantasai]
Elika: It does
23:36:31 [Bert]
ACTION: Elika and Anne to review test case for page break inside and report back with a recommendation to the group about how to move on
23:36:32 [trackbot-ng]
Created ACTION-19 - And Anne to review test case for page break inside and report back with a recommendation to the group about how to move on [on Elika Etemad - due 2008-04-03].
23:37:05 [Bert]
Topic: Syntax
23:38:19 [Bert]
Fantasai: Concerned about difference in white space syntax of nth-child() and calc().
23:38:59 [Bert]
Fantasai: Want consistency: either both need space or neither.
23:39:16 [Bert]
Anne: Principle should be that space is irrelevant.
23:39:43 [Bert]
David: Except where it s needed, between two idents, e.g.
23:40:09 [Bert]
[Example of 2n-1 being a DIMEN token]
23:41:17 [Bert]
Anne/David: and if we ban numbers or non-letters from units...
23:41:47 [fantasai]
David: but allow underscores (for vendor extensions)
23:42:22 [Bert]
[but "n-1" is an ident and will remain an ident]
23:42:29 [glazou]
23:43:44 [Bert]
Peter: Can we change an+b to an,b ?
23:44:01 [Bert]
Daniel: too late for that.
23:44:17 [glazou]
23:44:20 [Bert]
23:44:47 [Bert]
Daniel: and the "n" and "+" help to show which number does what.
23:45:35 [Bert]
[Spec has no exmaples with white space]
23:45:47 [Bert]
Daniel: Even so, people will write with white space.
23:46:33 [Bert]
David: No space between a and n is fine, looks similar to a unit.
23:47:04 [Bert]
Tantek: no space between sign and number either.
23:47:26 [Bert]
Dabiel: I think people will put a space between + and b.
23:47:34 [Bert]
23:48:33 [Bert]
Daniel: We should consider user's point of view. Either way is not so difficult to implement.
23:49:17 [Bert]
Daniel: "7n + 3" looks very intuitive, is used in many other places that people now.
23:49:32 [Bert]
Peter: And "2n + -3" ?
23:49:55 [Bert]
several: should be forbidden.
23:51:29 [Bert]
Alex: Can we allow spaces as well as no spaces and define what "n-1" means separately?
23:51:35 [fantasai]
23:53:40 [Bert]
[More dicussion about what is spaces are required in calc()]
23:53:46 [Bert]
23:55:09 [Bert]
Peter: I don't think designers will understnd that spaces are not required in nth-child but *are* required in calc()
23:55:32 [molly]
molly has joined #css
23:56:28 [Bert]
Daniel: We will get some comments on this no matter what.
23:56:37 [Bert]
Steve: Yes, but only it is shipped.
23:57:19 [Bert]
Steve: Why not make nth-child argument an expression?
23:57:38 [Bert]
Steve: ... with exception of an, which must remain together.
23:58:00 [Bert]
s/an/the "an" part/
23:58:02 [fantasai]
23:58:40 [fantasai]
23:59:12 [Bert]
David's proposal (link 0111 above) allows space except between a nd n.
23:59:25 [tantek]
in the interest of progress I'm ok deferring to David's proposal.