W3C home > Mailing lists > Public > www-style@w3.org > June 2009

[CSSWG] Minutes 2009-06-04 Part III: CSS2.1 Grammar Issues, IPTV liaison

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 16 Jun 2009 23:40:11 -0700
Message-ID: <4A388FCB.6010900@inkedblade.net>
To: www-style@w3.org
CSS 2.1 grammar issue
---------------------

   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-71
   fantasai: Bert said this was already clearly defined in 2.1 but the
             resolution was to change 2.1
   fantasai: the resolution we had was that if you see something that
             looks like an @rule within a declaration block you have
             to parse it as if it was an @rule
   Bert: this means that the rule that was in the spec doesn't apply
         and that implementations have to change
   Bert: i believe we decided that nested @rules have to come at the end
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2008Sep/0076.html
   Bert: otherwise CSS 2.1 parsers would not skip the @rules
   Bert: margin boxes inside @page
   Bert: the CSS 2 spec is more stable
   anne: for forward compatible parsing it would be better if @rules
         were parsed correctly
   Bert: it would be better if @rules where not nested at all
   fantasai: change definition of @page to allow atrules
   fantasai: or make it general that it can be done everywhere
   ChrisL: i think it should be general
   glazou: I agree
   anne: I also agree
   <ChrisL> better to make the general change, otherwise we always have
            to explain why @page is special
   dbaron: do these @top-... things take other properties than content?
   fantasai: yes
   dbaron: your compat issues would go away if you remove the @ and
           add a semi colon
   <dbaron> top-left: { content: "foo"; };
   dbaron: actually, I was suggesting making the block a value of a property
   <fantasai> from the minutes last time:
   <fantasai>   fantasai: The problem isn't where does the @rule end,
   <fantasai>             it's does the @rule end the declaration.
   <fantasai>   property: value; @key { ... } property2: value;
   <fantasai>   fantasai: The question isn't whether @key { ... } stays together,
   <fantasai>             it's whether it's considered part of the property2
   <fantasai>             declaration or not
   Bert: in @page they're not; they're declarations
   glazou: do you have a proposal Bert?
   Bert: as far as I can see it already ignores @rules
   Bert: we recently updated this text
   Bert: statements cannot start with a property
   Bert: @page contains declarations
   Bert: people didn't want a mixture of declarations and atrules
   dbaron: it seems a problem if we extend beyond the room forward
           compatible parsing rules give
   dbaron: we need either need more room or take better care of what is provided
   Arron: proposals?
   Bert: my proposal was from January '09
   <Bert> http://lists.w3.org/Archives/Public/www-style/2009Jan/0173.html

   [proposals on whiteboard; insert possible photo here]

   <fantasai> 1. @margin-box rules must end in semicolon.
                 (Print impl must change)
   <fantasai> 2. @margin-box rule smust come after all declarations in @page.
                 (Print impl must change)
   <fantasai> 3. @page takes a new mixed declarations+@rules construct
                 (Impl must change invalid parsing inside @page)
   <fantasai> 4. All declaration blocks can parse @rules that take the
                 place of a declaration.
               (All impl must change invalid parsing in all declarations blocks.)

   dbaron: I'm gonna say it's too late for 4
   fantasai: 4 was our last resolution
   Bert: we can define a new construct but we still need implementations to align
   Bert: my proposal grammatically allows mixing of atrules and declarations
         but atrules have to come after declarations
   Bert: that is compatible with existing implementations, but maybe not good
         for @page
   howcome: number 3 is just a grammar thing?
   Bert: it would introduce a block in the grammar
   fantasai: the implementations that implement @page have to change
   [some resentment over the design of @page]
   [also some support]
   fantasai: least disruptive solution would be 3
   howcome: yes
   glazou: yes
   Bert: really?
   fantasai: we could make a rule that atrules have to come after declarations
   fantasai: but implementations that support nested atrules will have to keep
             their support in the current way
   fantasai: it's non-conforming for an @margin- rule to come before declarations
   fantasai: in a conforming CSS file you'd parse it ok regardless of your
             implementation, but for non-conforming files you keep the current
             behavior
   Bert: I think less disruptive would be to take the atrules out of @page
   fantasai: there's deployed implementations and content
   howcome: yeah, I think that train has left
   fantasai: my proposal is 3 -- @page can take a mix of atrules and
            declarations + margin boxes must come after declarations
   anne: please don't bother authors for eternity with a silly conformance
         requirement because of some two year compat issue
   fantasai: So my proposal is a combination of 2 and 3
   <fantasai> 4 is our previous resolution
   <fantasai> 1 and 2 mess with existing implementations and content the most
   <fantasai> 3 is probably the least disruptive
   <fantasai> if we combine it with a recommendation that authors keep their
              @margin-box rules at the end of the @page rule
   <fantasai> then they get backwards compatibility with current implementations

   dbaron: I think just 3
   anne: 3
   sylvaing: 3 + 2 as note
   Arron: 3 + 2 as note
   SteveZ: 3 + 2
   glazou: just 3
   jdaggett: pass
   Bert: 1
   (second best, prefers something else)
   alexmog: pass
   howcome: pass
   fantasai: 3 + 2 as actual req
   ChrisL: 3 + 2 as ...
   <fantasai> 3 passes
   <fantasai> 2 passes as well, but should it be a note, a recommendation,
              or a requirement?
   dbaron: note
   sylvaing: note
   SteveZ: rec
   glazou: abstain
   Bert: req
   anne: note
   jdaggett: abstain
   alexmog: abstain
   howcome: abstain
   fantasai: rec/req
   Arron: note
   ChrisL: rec
   4 note
   4 rec/req
   glazou: move to rec
   dbaron: put it in as PR
   RESOLVED: 3 + 2 = 5
   RESOLVED: @page takes a new construct that mixes declarations and @rules
             (2.1 and css3-page)
   RESOLVED: css3-page RECOMMENDS that @margin-box rules come after all
             declarations in the page context

IPTV
----

ScribeNick: howcome
   <dbaron> Is this the group in question?  http://www.itu.int/ITU-T/IPTV/
   <Bert> http://www.itu.int/ITU-T/studygroups/com16/index.asp
   <dbaron> http://www.itu.int/ITU-T/studygroups/com16/sg16-q13.html
   Daniel: We received a liaison statement from the ITU and Bert sent a
           few comments about it
   daniel: we receved draft document, bert has commented
   dsinger: they're trying to describe a limited environment, but I'm not
            sure which one
   stevez: do we want to authorize any subset?
   <anne> profiles are teh evil
   dsinger: we already have a TV subset, no?
   Bert: webtv was the driver for that, we still have the draft
   Bert: one of my suggestions was to only have one TV draft
   <dsinger> sounds like a good idea.  profile proliferation (profileration?)
             is not good
   Daniel: would we reference or publish a document?
   Bert: in the past, W3C has published
   Bert: the proposed subset for TV is quite similar to the mobile subset
         we already have
   Daniel: lists numerous differences....
   Various: similarities and differences are discussed
   * dsinger that is too far away from the mike (tho I still agree)
   Chris: we should say: we're interested in your work, but you should
          reference our documents, not copy for them.
   SteveZ: I'd like to have a discussion on principles on subsetting. There
           should be as few as possible
   Chris: it would be good to have CSS on many devices
   SteveZ; maybe...
   <microphones moved>
   Chris: we shouldn't put them off, but find out what they want to do with it
   Chris: I'm concerned that they modify our definitions
   Anne: spending time educating them may not be worthwhile
   Bert: I understand that they want a definition...
   dbaron: if they're defining a profile, they're not interested in
           interoperating with the web
   howcome/Anne: Opera implement CSS on various set-top boxes. We don't
                 really like profiles.
   howcome: if they need a profile, we can offer CSS1, CSS Mobile, or CSS 2.1
   <dsinger> so, our response.
   <dsinger> We're not sure whether you are
   <dsinger> a) defining a limited implementation of web services, suitable
                for deployment on small devices like set-tops or TVs, but
                handling general web content
   <dsinger> b) or defining a restricted environment for restricted purposes,
                such as displaying menus or other TV-specific content
   <dsinger> Our comments are rather tentative, and are based on the assumption
             that it's (b).
   <dsinger> We're unhappy about the fact that your spec. copies our document,
             and we'd prefer that you reference it, and (if a subset is needed)
             you identify the sections that you adopt.  It's important to us
             (and implementors) that there not be differences between an 'IPTV'
             implementation and a 'W3C' implementation, and if you copy our
             specification and we later, for example, fix an error, that could
             occur.  Even simple re-phrasing can result in subtle, awkward,
             difference
   <dsinger> This is effectively defining a new profile, and we are hesitant
             to define many, and would prefer to do this collaboratively.
   <dsinger> It is important to analyze such a restricted profile from two
             directions:
   <dsinger> * is what is chosen to be included consistent, and complete, and
               implementable, or is there important functionality missing?
   <dsinger> * what are the consequences of the missing material?  what
               functionality and interop is lost?
   Bert: this makes sense
   Daniel: "unhappy" is too strong
   <dsinger> in particular, given general web content, and two browsers, one
             implementing IPTV CSS and the other W3C CSS, what happens when
             features in W3C but not IPTV are used in that content?
   15:32 -!- MoZ [chatzilla@82.230.92.154] has joined #css
   fantasai: we are "concerned"...
   Chris: we are heartbroken...
   Bert: they're expecting us to be stable -- what do we tell them?
   John: CSS 2.1 is relatively stable...
   dsinger: CSS3 is also on the way. It's difficult to answer them before we
            know what they're trying to do.
   <dsinger> if they want a subset for a restricted purpose, we don't know
             what that purpose is...
   fantasai: they should also look at the snapshot...
   <fantasai> http://www.w3.org/TR/css-beijing/
   <fantasai> It explains a lot of important things about our specs and
              their relative stability/obsolescence
   dsinger: ahh
   <Bert> liaison statement: http://www.w3.org/Style/Group/2009/ls047-16.doc
   dsinger: should I draft a response you can look at tomorrow morning?
            What else should be in there? Beijing draft?
   fantasai: yes
   howcome: we should say why we don't like profiles: we like interoperability
   SteveZ: we don't like ghettos
   SteveZ: one thing to ask for is a set of requirements
   Bert/Chris will add general text about W3C to be added to the reply

   offtopic:
     <Bert> http://www.w3.org/Style/Group/meetings.html
     DanielG: 2010 meeetings: one meeting will be in the bay area on 22-24 march,
              2010 -- can Apple host?
     DanielG: we need projector, network, room for 15 people
     dsinger: I can't book a room until 6 months before, but in principle I agree.

   various discussions: what format should we use for our reply?
   several people note that many organizations ignore the content of email,
   only pay attention to attachments
   * dsinger a zip archive with an HTML page and a stylesheet
   * dsinger using features of CSS they chose not to include... :-)
   <phone hung up>
   <sylvaing> cessation of hostilities #2

meeting adjourned
Received on Wednesday, 17 June 2009 07:48:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT