- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 16 Jun 2009 23:40:11 -0700
- 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 UTC