W3C home > Mailing lists > Public > www-style@w3.org > July 2008

[CSSWG] Minutes and Resolutions 2008-07-02

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 02 Jul 2008 13:04:36 -0700
Message-ID: <486BDF54.7060108@inkedblade.net>
To: www-style@w3.org


   David Baron
   Bert Bos
   Giorgi Chavchanidze
   Arron Eicholz
   Elika Etemad (co-scribe)
   Ming Gao (co-scribe)
   Sylvain Galineau
   Daniel Glazman (chair)
   Peter Linss
   Alex Mogilevsky
   Saloni Mira Rai
   David Singer
   Steve Zilles


   - Discussed charter and http://csswg.inkedblade.net/planning/charter-2008
   - Media Queries has outstanding comments
   - CSSWG to advocate separation of content and style and not using generated
     content for actual document content
   - Status update on CSS Variables and Selectors
   - Discussed some CSS2.1 issues, no conclusion yet

Full minutes below.

<Ming> scribenick: Ming

Update on new CSS charter

   daniel: looked at wiki; agreement is by end of the week, it will be closed.
   fantasai: two things outstanding, will ping the author
   daniel: has integrated Bert's comments on CSS Variables into the wiki
   daniel: won't stop working on a module, just if someone is against it
   daniel: advocates should integrate comments to wiki if possible, but
           we won't start another long discussion for that
   <dsinger> there certainly should not be a presumption that we are in
             agreement, in order to work on something...
   bert: a general question: in addition to the integrating into wiki,
         what about other comments
   dbaron: what about the previous agreement on advocates on documents?
   peter: I have that list, I'l integrat them into the wiki
   daniel: talk to advocates about your comments
   david s: working draft is where we need consensus, not at the charter
   steve: have comments at both stages are appropriate?
   daniel: yes.
   daniel: maximum amount of info on the documents
   steve: confused. thought we agree on shortening the deliverable list
          and provide a catalog in the scope section
   daniel: sorry, I mean the specifications
   daniel: anyone to add to the charter now?
   peter: interest group for the test suite, does that need to be documented
          in the charter?
   daniel: no
   daniel: wiki is done, so the charter is to be resubmitted
   steve: are we redefining the deliverable list?
   peter: on the list, are those ready to move to Rec.
   david s: need to have test suite to these deliverables. had some discussion
   fantasai: what about things that could make to CR?
   peter: will have them in scope section
   fantasai: border work, etc; won't be able publish a working draft?
   daniel: correct.
   <Bert> http://www.w3.org/Style/Group/2008/proposed-charter.html
   david s: not able to publishing working draft, is a circular problem. ie.
            won't able to work on the specification without publishing drafts
   fantasai: page media should be in the deliverable list; almost ready to
             publish a last call
   daniel: had discussed last week; won't able to extend too long; no problem
           just adding one item, e.g. page media.
   steve: what about Marquee, needed for Mobile Profile
   steve: observing an issue working with OMA on Marquee
   saloni: what is being dropped?
   fantasai: everything except on the top list
   steve: move page media up?
   daniel: no objection; yes.
   david s: need to inform the mobile group if they have a dependency on

Media Queries Disposition of Comments

   <glazou> http://dev.w3.org/csswg/css3-mediaqueries/disposition.html
   daniel: everyone get a chance to review the disposition (see the link)
   steve: sent comments last Tuesday
   David B: several issues: one of which is related to some changes there.
   daniel: so the action item for anne or howcome.
   <fantasai> dbaron and fantasai had substantive comments
   steve/fantasai/bert: we have comments
   steve: sent to anne, our comments?
   david b: some of them will require discussion.
   david b: ws is obvious, but the error handling would need discussion
   daniel: need Anne in the next call.

CSS Variables Issues

   daniel: this is implemented in Safari.
   daniel: need further improvement.
   daniel: adding a new API to handle the issue
   daniel: got a lot of feedbacks and enhancements

<fantasai> ScribeNick: fantasai

   daniel: one issue is scope of variable definition
   daniel: scoped to single style sheet? cross @import boundaries?
   daniel: document-global?
   daniel: working on a new editor's draft
   daniel: we keep crossing @import boundaries
   daniel: important for having e.g. a corporate style sheet with variables
           for corporate colors
   daniel: leaning towards document-global, still have to discuss it
   fantasai's preference would be to cross @import, but not document-global
   Steve: I understand the need for global variable settings, but that would
          seem to be at the document level or @import..
   Steve: I would be more concerned that style sheets further down the line
          get unexpected variable definitions
   Steve: standard modularization problems
   daniel: still working on document, hyatt is implementing as he writes
           (as always)
   daniel: expect feedback on anything we do

Accessibility of Generated Content

   daniel: more and more websites use generated content to insert real
           content in websites
   daniel: e.g. wikipedia
   daniel: all geolocation information in wikipedia is inserted using GC
   daniel: it's a perversion of the system, it's not something we can forbid
   daniel: but it deserves a nice warning in CSS2.1 spec to say that this is
           bad practice
   daniel: it also deserves let's say a blog entry about it
   daniel: and if we can tell the Web Standards Project about
   peter: why is it bad for accessibility?
   daniel: because information is not in the document tree
   fantasai: CSS is supposed to be optional
   fantasai: for enhancement, not for content
   fantasai: what if I load a page in Lynx? I'd miss half the content
   daniel: separation of content and style
   steve: you also might replace the style for accessibility reasons, which
          would also make the content inaccessible
   fantasai suggests Bert write the entry
   ACTION: glazman get Bert and his accessibility friend in contact
   ACTION: Bert write blog entry on generated content, accesibility, and
           separation of content and style

Generated Content on <br>

   daniel: the specification has an example of <br> being defiend as
           br:before { content: '\A'; }
   daniel: in fact the behavior of <br> is completely undefined in HTML,
           so each implementation has a different interpretation of <br>
   daniel: so GC on <br> is not predictable
   daniel: for a text editor br:before { content: <paragrah symbol> } would
           be extremely useful
   daniel: it would make sense to define better the behavior of <br>
   <dsinger> isn't line break what Unicode calls newline function
   fantasai: I agree with bz, who suggested br { content: '\A' }
   <dbaron> that doesn't solve Daniel's problem
   <fantasai> br { content: 'P\A'; }
   daniel: we should normalize interpretation of <br>
   <dbaron> ok, right, but the author has to re-specify the part that's in
            the UA style sheet
   <fantasai> if :before isn't replaced by 'content' then it should work
   <Saloni> br is treated as a replaced element correct? would the
            definition br { content'\A'} be in line with this?
   peter: I think inserting a line feed with GC is a hack
   peter: I felt we should have a line-breaking property
   Bert: we tried that. It didn't work with existing implementations
   Bert: <br><br> creates two line breaks
   Bert: could argue that <br><br> creating two line breaks was stupid,
         but it was what Netscape did a long time ago
   <dsinger> that is what two Unicode newlines do, though...
   fantasai: I think it's a good to define at some point, but not going
             to solve today


   daniel: I have a few things to add to document, but I'm more concerned
           about test suite
   daniel: test suite is huge, lots of test in many contexts
   daniel lists various cases
   daniel: it's probably too long
   daniel: I think it's trying to test everything in all cases, and we'll
           never be able to do that
   dbaron: we have implementation reports, we just need to update them to
           the latest implementations
   dbaron: I think it'll be much easier to fill them out and push them out
   dbaron: than to redefine anything
   dbaron: I believe I published an updated implementation report template
           for the current test suite
   daniel: If we can have implementation reports from Mozilla, Opera,
           Microsoft, etc
   daniel: that would help
   dbaron: someone should dig up the template URL and send it around
   <fantasai> http://www.w3.org/Style/CSS/Test/CSS3/Selectors/20060307/implementreportTEMPLATE.html
   daniel: once charter is done I should have more time to work on this
   daniel: and I will fix the remaining items so this can move forward
   <dbaron> I think it took me 1-2 hours to do an implementation report,
            including going through all the versions of the tests.
   <dbaron> It helps to have an implementation that preserves focus after
            using the browser's "back" feature.

CSS3 Color

   ACTION: peter talk with HCG about publishing css3-color


   <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-35 is open, but
     needs time for discussion
   <fantasai> http://csswg.inkedblade.net/spec/css2.1#issue-45 is open
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Jun/0177.html
     this is a request for clarification
   dbaron: works for me
   <dsinger> no opinion...sorry...
   <glazou> no opinion is an opinion dsinger :)
   ACTION everone get an opinion on proposal for issue 45 for next week

   fantasai: question is should page-break-* apply to <br> ?
   fantasai: page-break-before/after currently only apply to block-level
   everyone is bothered by <br> not behaving like a normal CSS element
   <dsinger> apropos the BR discussion, Google found this: The global
             structure of an HTML document
   <dsinger> Generally, block-level elements begin on new lines, inline
             elements do not. For information about white space, line breaks,
             and block formatting, ...
   fantasai: the only way to do this is to special-case the HTML <br> element
             in CSS2.1
   fantasai doesn't want to do this
   alex: we already do that for 'clear'
   dbaron: the HTML notion of inline vs block is different from the CSS notion
   glazou: <br> is part of the inline group of elements in the DTD
   glazman: should we have a joint discussion with HTMLWG about <br> at TPAC?
   Bert, peter: don't see what they would have to say about it
   Bert, peter: we're not discussing usage in markup
   ACTION: peter add <br> to Cambridge F2F agenda
   <dbaron> I'm not sure whether <br> is that critical an issue...
   * fantasai agrees with dbaron

   fantasai: Grammar and syntax people, please look at

Meeting closed.
Received on Wednesday, 2 July 2008 20:05:15 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:38 UTC