- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 28 Feb 2013 16:28:45 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Add Dael to CSSWG
- RESOLVED: Accept jdaggett's proposal
http://lists.w3.org/Archives/Public/www-style/2013Feb/0432.html
- Discussed interaction of MQ and @page 'size', and similar situation with
@viewport sizing.
- RESOLVED: Accept Simon's fix to page names so they work on first page
of document
- Discussed painting order of page-margin boxes
- RESOLVED: Add @page OM to css3-page, exact OM API TBD.
- Discussed editorship of GCPM
- Discussed fallback behavior with variables
- RESOLVED: Publish WD of Variables with Simon Sapin's issues noted
====== Full minutes below ======
Present:
Glenn Adams
Tab Atkins
Rossen Atanassov
David Baron
Bert Bos
John Daggett
James Dovey (Rakuten)
Arron Eicholz
Elika Etemad
Simon Fraser
Daniel Glazman
Rebecca Hauck
Molly Holzschlag
Dael Jackson
Dean Jackson
John Jansen
Peter Linss
Edward O'Connor
Florian Rivoal
Simon Sapin
Dirk Schulze
Alan Stearns
Leif Arne Storset
Nick Van den Bleeken
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2013/02/27-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Feb/0696.html
Scribe: fantasai
Administrative
--------------
plinss: Extra topics?
glazou: One related to css3-page / paged media in general
glazou: Would like to add Simon as extra editor for GCPM
<SimonSapin> not really css3-page if it's GCPM
jdaggett: Would like to talk about last call push for CSS Variables
plinss: Another thing wrt variables fantasai mentioned, too
<glazou> agreed but falling in same basket SimonSapin
plinss: First topic. Notice we have Dael Jackson on the call.
plinss: She's agreed to be a dedicated scribe. Waiting for funding to
go through.
plinss asks if this sounds good to everyone
* molly thinks poor dael has no idea what you signed up for
Florian: Scribing requires not just fast typing, but also deep understanding
of what we're talking about. Going to be a challenge.
RESOLVED: Add Dael to CSSWG
Font Resource Handling
----------------------
<jdaggett> http://lists.w3.org/Archives/Public/www-style/2013Feb/0432.html
jdaggett: Not sure we need to discuss... I proposed change to wording
to one section
jdaggett: No one really responded
jdaggett: Propose taking this change
plinss: Any objections?
RESOLVED: Accept jdaggett's proposal above
CSS3 Page Issues
----------------
SimonSapin: Have few small issues to resolve on
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0214.html
http://lists.w3.org/Archives/Public/www-style/2013Feb/0096.html
SimonSapin: Currently spec says that MQ resolve on default page size,
do not consider any size property
SimonSapin: Issue that maybe some size properties should be considered
SimonSapin: Would be nice to have
SimonSapin: But think current wording is consistent with MQ, resolve
against default page size
SimonSapin: Propose no change, just remove the issue
SimonSapin: Any objections to that?
Florian: No objection, but comment
florian: Another spec not entirely dissimilar, device adaptation
florian: MQ react to device adaptation
florian: When you set a different viewport, MQ can react to the size of
this viewport
florian: This is different from @page
florian: The resolution you propose is fine, and consistent with MQ
florian: But I'm wondering if we're happy with this inconsistency
florian: If you set @page size, they don't react; but if you set @viewport,
they do
SimonSapin: It's a good point, but what happens with @viewport inside
@media with an MQ?
florian: There's an algorithm in the spec
florian: It doesn't have to be particularly elegant, it just has to
break the cycle
SimonSapin: Ok, I will look at this and come back next week
florian: I'm uncomfortable with the two different directions
fantasai: There are very good use cases for having MQ respond to page
size or viewport size
fantasai: paged-media says what it says because we had to resolve the
conflict between setting a size and querying it
http://lists.w3.org/Archives/Public/www-style/2013Feb/0097.html
SimonSapin: There is some text in spec to ignore size declarations if
qualified by MQ
glazou: yes was resolved during a past ftf
SimonSapin: My proposal was to remove that part of the spec *if* MQ is
based on default size
SimonSapin: Because it's not necessary in that case
[ but need to resolve the previous issue first ]
SimonSapin: Next issue - named pages
http://lists.w3.org/Archives/Public/www-style/2013Feb/0640.html
SimonSapin: Definition of named pages didn't allow first page to be named
SimonSapin: So changed algorithm to work that way
leif: Without this change, would it mean there would be a blank page
at the beginning?
SimonSapin: Only get a page break when value of page property changes
SimonSapin: I think this change is more in spirit of the property.
I think this was implemented behavior, never written down.
plinss: So if you had an element saying it should be on page named "foo",
and it's the first item, it would force a page break. Now it
doesn't
SimonSapin: Basically still has page names work even when there is no
content before that element
leif: ok, great
* fantasai in favor of fixing this
RESOLVED: Accept Simon's fix to page names so they work on first page
of document
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0652.html
SimonSapin: z-index property is optional on page-margin boxes. Don't know
why, so propose making it non-optional
SimonSapin: If a UA supports it on elements, it must support it on
page-margin boxes
glazou: What would be the effect on page-margin boxes?
SimonSapin: If they happen to overlap, you can choose which are on top
with z-index
dbaron: z-index only applies to positioned elements
SimonSapin: Wording in spec that says z-index always applies
dbaron: ok
TabAtkins: Already applies automatically to flex items
Rossen: and grid items
glazou: When you flow an element into a margin box (via GCPM), does this
affect that?
SimonSapin: Wouldn't affect flow, only stacking
glazou: Would like some time to look at this more closely
florian: In theory what you're saying makes sense [...]
* florian gave up speaking, muted, and types instead
<florian> Simon makes sense, but I wonder if we could dig out why it was
marked optional in the first place
+bradk
fantasai: The reason it was marked optional was that, at the time, it
was not implemented, and we were trying only to clean the spec
up, not to add new features
fantasai: We didn't see a reason to forbid z-index, so made it optional.
plinss: Ok, let's come back next week. If someone wants to write tests
and see if anyone implements it
SimonSapin: WeasyPrint doesn't implement it, but think it would be good
to have it, and would implement it if it's in the spec
SimonSapin: Next issue
<SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Feb/0653.html
SimonSapin: The default order of page-margin boxes is not specified,
because we didn't have a good answer
SimonSapin: Suggest picking something arbitrary
SimonSapin: e.g. start at top-left and go clockwise
glazou: That would be a problem for rtl pages
SimonSapin: z-index would allow changing the order
SimonSapin: Also, only matters when there's overlap with the boxes,
which we try not to do in the layout algorithm
plinss: Do we have other cases where rotation depends on writing mode?
glazou: My concern is rtl pages will forget to fix
SimonSapin: Hopefully they will not overlap at all
<SteveZ> Why not define starting at the start-before edge
<SteveZ> Then go in the inline direction followed by the block direction
* bradk likes the idea of re-imagining margin boxes and page box as grid.
fantasai: I would like to know what Antenna House does, and if they
thought about this problem. Because if they thought about it,
they probably have a sensible answer
SimonSapin: Could discuss particular order, but what about not leaving
it undefined?
Bert: It seems very rare to have overlapping, so probably need to use
z-index anyway
Bert: Don't think it's necessary to do anything complicated, just need
some answer
<florian> I am with Bert on this.
glazou: Ok, I withdraw my objection, I agree with proposal. But relies
on previous issue's resolution so give me a few days
szilles: One advantage of undef is that ppl will always use z-index b/c
doesn't know how it works
plinss: Only if they test in multiple implementations
szilles: Defining it fixed way, disadvantages some other languages
<florian> Ask Antenna house, if they have an answer, use that, otherwise,
define whatever
SimonSapin: Still in favor of defining something.
SimonSapin: One last issue, but will take a lot more time, so suggest
deferring to after WD
SimonSapin: wrt viewport units and ICB
glazou: I have one issue
glazou: My issue is simple, related to OM of page rule, as defined in
CSS3 Page
glazou: Paged Media L3 introduces new @rules inside @page rule
glazou: OM currently unable to fix that. Would like to see at least a
proposal or start of something about this new @page rule
glazou: Noticed ConditionalRules introduces GroupingRule
glazou: Might make sense to inherit from that.
glazou: That would allow editors like mine to deal with declarations
and @margin boxes inside @page rule. Otherwise not editable
for me.
TabAtkins: That's maybe not doable as written
TabAtkins: GroupRule is used for things that contain declarations only
TabAtkins: Might need a different interface, with slightly different API
SimonSapin: Doesn't insertRule reject inappropriate things anyway?
florian: declaration vs. rule
SimonSapin: 2 ways to do this
SimonSapin: Either have separate list of rules, same as at-media, and
separately had style attribute, same as currently exist
SimonSapin: But this does not preserve relative order of at-rules and
declarations
glazou: Preserving the order is IMO not an issue
fantasai: I agree. The relative order here has no meaning.
fantasai: Just need to preserve relative order of at-rules amongst
themselves
SimonSapin: Will this be the case in the future?
TabAtkins: Think so
TabAtkins: Actually...
TabAtkins: I can see things in the future where relative order of
declarations and at-rules might be important, e.g. mixins
like SASS.
SimonSapin: If we do want to preserve order, then it's much more
complicated.
glazou: It's a very complex discussion, suggest we don't go into that
right now.
-> mailing list
SimonSapin: Does this belong in CSSOM or CSS3 Page?
glazou asks Glenn
<glenn> thinking
<glenn> i'd say OM
glazou: New specs like animations have their own OM
<glenn> i'm open... if it is general that can be used elsewhere, then
probably OM
glazou: CSSOM deals with everything else
florian: Think CSSOM spec still has plenty of work to do for legacy thing.
florian: For new things, should just define them in that spec
florian: Force both editors and implementers deal with OM as they go
<glenn> we have effectively moved the CSSFontRule out to the font spec,
so could move CSSPageRule out as well...
glazou: Implementers will have to implement something anyway, so
<stearns> +1 to OM in each module
plinss: Keep CSSOM spec scoped to past behavior
<glenn> yes to what peter said
RESOLVED: Add @page OM to css3-page
GCPM Editorship
---------------
* leif1 has to leave early, sorry. Just wanted to explicitly not object
to SimonSapin editing css3-gcpm together with howcome, as was mentioned
at the beginning of the call. (Though I have not consulted with howcome.)
glazou: GCPM spec is bad shape, really old, some things in contradiction
with charter
glazou: Suggest new editor, Simon Sapin, to become 2nd editor on the spec
jdaggett: howcome still an editor?
glazou: Yes
jdaggett: Is he ok with it?
glazou: Not yet, we'll have to ask.
glazou: But problem is changes we requested in the past multiple times
were not made.
jdaggett: I'd like to hear how howcome feels about that.
glazou: We will anyway! We won't resolve w/o pinging him.
plinss: Worth getting feedback from him before adopting formally
florian: Seems to me different kinds of things in GCPM, some that
should be there and go to REC there, and things that should
go in another spec
florian: From pov of migrating things to different specs, e.g. generate
paged media based on overflow, this could be in dbaron's spec
florian: Don't need extra editor to GCPM for that
florian: just edit it elsewhere
glazou: Sounds like action on chairs to get howcome's opinion
SimonSapin: I think we'll need to have that discussion for each part
of GCPM
SimonSapin: Leave it there, or shift it elsewhere
Florian: Agree with that.
Florian: But GCPM really is a special spec, it's howcome's spec, hard
to discuss without him.
Variables
---------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0213.html
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Feb/0632.html
SimonSapin: Issue is that this prevents usual mechanism of using cascade
to find fallback values
SimonSapin: It's pretty fundamental mechanism in CSS
SimonSapin: Think we should preserve that
SimonSapin: One way to solve is to keep around cascaded list
SimonSapin: Keep around last declaration that's valid
SimonSapin: After I raised this issue, Tab said it was rejected b/c
implementations didn't want to remember multiple cascaded
values
TabAtkins: Implementations want to keep current optimization, where
don't need to keep around all those values
florian: Wondering if there's some kind of middle ground
florian: Just remember two, one declaration variables, and one without
variables.
florian: Less memorizing. Doesn't give you full cascade
florian: But maybe it's more confusing to have part cascade rather than
full
TabAtkins: Seen as weird to ignore declaration with variables that would
have worked as a fallback
TabAtkins: I do have some proposals to type-check variables early on,
figure out whether invalid ahead of time
TabAtkins: Not addressing in this level
TabAtkins: Addresses a lot of fallback issues
TabAtkins: Not as good as keeping full cascade, but fills in many holes
SimonSapin: Would your proposal mean that validation of some declarations
that use variables is done after the cascade, and some are
done before?
TabAtkins: Typing proposal makes variable itself to go invalid early.
Fallback happens at variable level
TabAtkins: rather than killing the property declaration
TabAtkins: would then use fallback [...]?
SimonSapin: Different fallback than what we already have
florian: Keeping around cascade, as an implementer, much preferred Tab's
proposal.
TabAtkins: Variables are pretty memory-heavy, this would make it worse
<bradk> You could keep the cascade list for each var-foo, and use
earlier declarations of var-foo when later ones don't work.
SimonSapin: I don't think it means keeping entire cascade around
SimonSapin: Would only keep around up to first declaration that doesn't
include variables
SimonSapin: Most cases, this is only one declaration.
SimonSapin: Cases with variables, usually pretty short anyway
SimonSapin: Don't need to preserve anything before a declaration that
does not use the var() function.
SimonSapin: If this has been rejected before, I understand, but would
like to hear from different impl what they think
TabAtkins: I think this is not functionally different
TabAtkins: Data structs still need to change, etc.
glazou: Suppose you have multiple declarations for same properties in
a block. Editor changes one to use variables, behavior then
changes.
TabAtkins: No, would match it
<florian> I don't think Daniel's worry is warranted.
glazou: If your variable is invalid
TabAtkins: Simon's proposal gives same behavior as if the declaration
was invalid
glazou: I understand the rendering will be exactly the same, but it
changes the way the declaration block is used, parsed, dealt
with, inside the implementation. And that is not coherent.
florian: I think Tab's changes it more.
jdaggett: Could we talk about WD issue?
jdaggett: As I look over spec, I realized we haven't published WD since
April 2012. Would prefer if we publish WD and then publish LC
after polishing
jdaggett: Know we resolved LC, but think it's better to publish WD first
and get more eyes on it. Some people don't follow
day-to-day-changes in editor's draft
jdaggett: And there are significant things that changed since last WD
TabAtkins: I don't think anything significant has changed, but have no
objection to publishing a WD
jdaggett: Works for me
<fantasai> sounds good to me
<molly> fine by me
<SimonSapin> +1 for a WD
<SimonSapin> or any publication, really
RESOLVED: Publish WD of Variables
<molly> I agree it will get more eyes
TabAtkins: I'm doing some corrections based on jdaggett's feedback, so
will verify with him and then ask for publication
fantasai: suggest marking Simon's issues in the spec, so that people
notice and give feedback
* fantasai notes there's more than one
Meeting closed.
Received on Friday, 1 March 2013 00:29:16 UTC