- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 16 Jan 2013 18:28:21 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed F2F logistics; need more topics for agenda
- Discussed interaction of viewport units and scrollbars, and avoiding
relayout in 'overflow: auto' case. Need use cases for deciding
whether 'auto' should be laid out as 'hidden' or 'scroll'.
- Discussed issues with Pointer Events spec
http://lists.w3.org/Archives/Public/www-style/2013Jan/0182.html
Specific concerns include:
- Spec seems to confuse people as currently-written
- The touch-action property might be overly-specific to touch interfaces
- Discussed whether touch-action property is necessary.
- Spec should show examples of how 'touch-action' is used in an
all-declarative use case. (If it is only useful when JS is invoked,
maybe its behavior should likewise be handled by JS, not by
introducing a declarative property that's only useful when mixed
with JS.)
- Discussed CSS Masking, progress to LC. Issues raised include:
- duplication of prose from CSS3 Backgrounds and Borders
- interaction with 'overflow' property
- clarifying behavior of 'no-clip' value
====== Full minutes below ======
Present:
David Baron
Bert Bos
Tantek Çelik
Elika Etemad
Simon Fraserp
Sylvain Galineau
Daniel Glazman
Brad Kemper
Rebecca Hauck
Molly Holzschlag
Koji Ishii
John Jansen
Peter Linss
Alexis Menard
Edward O'Connor
Anton Prowse
Simon Sapin
Dirk Schulze
Alan Stearns
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jan/0193.html
Scribe: fantasai
[ See Appendix A for pre-meeting IRC comments ]
Administrative
--------------
plinss: Any other items? I saw dbaron's email. No?
topic: F2F
molly: Wanted to make sure we have everything in order for F2F, since
I might not be available for next 2 meetings... available only
via email
molly: good shape w/ rooms
molly: Only have a problem solving with koji, will take care of that
molly: Meetings held at U of AZ on campus
molly: They'll take care of catering
molly: Only thing is, Wed night we have to leave the room by 5pm
molly: Seems like it will be ok, is it a problem with anybody?
molly: We'll be on a university campus, lots of resources
molly: working on right now is social events
molly: Daniel suggested a meetup
molly: figure out which night is best, and who would like to do 5-7
minute presentation?
molly: related to CSS, CSS and community, design-oriented, W3C topic,
whatever
molly: Wondering if Tuesday is best night
molly: Sunday make sure we have dinner for ppl arriving, from 8-10
molly: I imagine a lot of ppl will be tired Monday night
molly: so thinking Tuesday?
molly: Let me know by end of day
molly: Would like to know who's interested in topic and which night
is better
molly: That's it
glazou asks about weather
molly: We have had historic lows
molly: 7-8 days under freezing at night
molly: beautiful -- sun shining, sky clear -- but cold
molly: Looks like it's warming up
molly: don't need winter coats, but bring heavy sweater
molly: will keep you posted
<dbaron> http://en.wikipedia.org/wiki/Tucson#Climate
<dbaron> FWIW, I find doing a meetup after 9 hours of meeting to be
rather exhausting...
[discussion of concerns wrt which day]
<glazou> hey come on, he won't even change of TZ :-)
molly: will aim for Tuesday then
SimonSapin: I could give a presentation on CSS for printing
plinss: call it Tues unless objection
plinss: Please put topics on the F2F agenda!
Viewport Units
--------------
<dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JanMar/0051.html
<dbaron> http://lists.w3.org/Archives/Public/www-style/2012Dec/thread.html#msg47
<dbaron> http://lists.w3.org/Archives/Public/www-style/2013Jan/thread.html#msg200
<dbaron> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19737
dbaron: There are multiple implementations of viewport units, but major
issue that prevents them from working right
dbaron: Don't interact with scrollbars the way we want them to
dbaron: Can't decide today, but next week.
dbaron: We're pretty close to shipping, but can pull back if needed
dbaron: Please look this thread over so we can decide next week
dbaron: Tab and I are both thinking that if scrollbars on viewport are
overflow: scroll/auto, you do subtract scrollbars. If hidden,
then you don't
dbaron: So subtract scrollbar even if in overflow: auto case where no
scrollbars
smfr: Trying to avoid relayout after trying the first time?
SimonSapin: So you will have cases that 100vw won't match the size of
the ICB?
dbaron: This would cause that to be the case.
dbaron: 100vw could be smaller than ICB by width of potential scrollbar
in 'auto' case
Rossen: One downside to this proposal, in default case where overflow
is auto, always subtracting scrollbars
Rossen: For layouts that are designed to fit within viewport, will have
a gap
Rossen: I see your reasoning for why you're subtracting the scrollbar
Rossen: But I think we're shortcutting the implementation here.
Rossen: Cases e.g. want to fill a canvas to screen
Rossen: For us might not be a huge deal, since we're overlay scrollbars
regardless for viewport
Rossen: But I think we should think it through a bit more.
dbaron: It's more than just circularity, but also layering problem.
dbaron: Don't want computed values to be a function of layout
dbaron: But do we make them so they behave like 'scroll' or so they
behave like 'hidden' for 'auto' case.
Rossen: Need to decide which case we're optimizing for
Rossen: want to reinforce that what I've seen for most case is
people building layouts that usually fit without scrolling
Rossen: Maybe we can poll some public input
dbaron: A bunch of cases where you could use viewport units, you
could use 100%
dbaron: Wondering what are solid use cases for viewport units where
you can't use 100%
dbaron: Not entirely obvious to me what those cases are
Rossen: viewport unit to size pages
Rossen: laid out side-by-side, or one-page view
Rossen: always fit in the viewport
Rossen: usually no scrollbar there
Rossen: in our case we use overlay scrollbars for viewport
Rossen: probably not make that much difference
Rossen: want for us to not make this decision lightly without more
input from users, and looking at real cases
dbaron: If you have examples you can post, that would be great
* fantasai suggests molly ask for use cases, examples
dbaron: A use case I have is a slide deck in HTML
dbaron: Most of the time they don't have scrollbars
dbaron: But sometimes you wind up on a display that's different size
than you designed for
dbaron: When that happens, don't want to get cut off, want to scroll
and have that work
* fantasai thinks it's better to fill by default than gap by default
for that case
Rossen: Not sure if it's up to us to decide, or poll more opinions here
fantasai: Could also revisit decision to make viewport units compute
to an absolute length, treat more like percentages.
dbaron: We'd pull our implementation then, b/c too expensive a feature
to be worth implementing
plinss: Come back to this next week.
<sylvaing> I'm answering Tab's question right now
<sylvaing> on www-style
<sylvaing> Let me see if I can call in
Pointer Events
--------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2013Jan/0182.html
plinss: Pointer Events WG is asking for feedback
plinss: Please review
dbaron: Tab and I both sent email to their list
<dbaron> Tab sent http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0017.html
I sent http://lists.w3.org/Archives/Public/public-pointer-events/2013JanMar/0018.html
smfr: Don't really understand why this is necessary since ? does these
things based on whether nodes have touch event handlers
smfr: So I'd like to see more justification for the touch-action property
hober: i don't think we need touch-action when we already have preventDefault
sylvaing: What kind of justification looking for?
smfr: Think it's possible to get the behavior by registering touch events
sylvaing: More productive for developers to do declaratively.
smfr: Seems like use case here is ... default panning/zooming behavior
of UA
smfr: Authors want to do that when want to create their own handlers
sylvaing: Idea is you want to be able to put your finger anywhere on
the page, and have document follow your finger
sylvaing: or pinch and have it zoom
sylvaing: or in an overflow: scroll box, have panning/zooming only
affect content inside that box
sylvaing: Idea is for author to say that panning and zooming applies to
a particular subtree
sylvaing: Things inside it zoom out and pan together, but not things
outside it
sylvaing: Much easier to do that way than writing events
dbaron: So what you said about how it works is not at all how I read
the spec as saying
dbaron: in that what it seems to say to me was
dbaron: There's a set of things that can handle these events
dbaron: Not entirely clear to me what those are, but sounded that if
you had another one that could potentially do that inside your
map, then the fact that you set 'none' value on an ancestor of
the map, doesn't prevent the inner thing from handling the event
sylvaing: So map has none, everything inside has auto,
sylvaing: you have another none container in there?
dbaron: For the map thing you were talking about, what do you put the
none on?
sylvaing: thing that contains the map
dbaron: The parent of the thing that handles the touch stuff?
dbaron: or element that handles the touch stuff?
sylvaing: You guys referring to connection between property and ...
sylvaing: Not sure I follow the problem
dbaron: Maybe discuss this later, but spec should be clearer about what
it's saying
dbaron: though maybe feedback I sent was based on completely
misunderstanding what the spec was saying
sylvaing: ok, will try to check your email and see what it says
smfr: For example, is it the UA doing panning/zooming inside the thing,
or the page using pointer events?
sylvaing: can do both, can intercept the events
sylvaing: touch-action: none turns off UA behavior
sylvaing: it's a way of saying elements that don't do special handling,
event passes up; this says whether to stop at some intermediate
ancestor
smfr: Still sounds exactly what you can do with event handlers
sylvaing: Can of course do with JS, but much easier to do with CSS
sylvaing: It's syntactic sugar for a use case that's very common
plinss: Making declarative rather than script makes sense
plinss: Bothered a little bit if we're defining feature at too low a
level, when concerned about a higher-level concept.
plinss: If the issue is panning/zooming, should that be a touch event?
Or work for other pointer inputs?
* BradK would like a declarative approach that handled scroll wheel
events too.
smfr: Tendency of this spec to [...] pointer-events , which is different
from pointer-events property, which is confusing
plinss: My issue is, instead of touch-action, shouldn't this be
panning-and-zooming?
sylvaing: Yeah, naming is confusing, even values 'auto' / 'none'
are confusing
<smfr> There's a dependency from the CSS pointer-events spec on the
DOM "pointer events" proposal
<smfr> <http://www.w3.org/Submission/pointer-events/>
plinss: Any feedback on this?
plinss: Any group response?
fantasai: I guess group response is, this is confusing? :)
sylvaing: Interaction with actual events isn't clear
sylvaing: And feedback wrt naming being inappropriate
tantek: Example you mentioned with maps... that requires JS to make
the maps work
tantek: While I agree with having declarative shorthands
tantek: But if you're going to have an example of how declarative-only
feature is useful
tantek: Should be an example that doesn't require JS for the rest of
the example to work
tantek: whatever the example is, should be declarative only, rather
than depend on JS
* fantasai agrees with tantek
tantek: otherwise echo Simon's concern -- if you're doing things with
JS anyway, have to handle details there anyway
sylvaing: Could be picture, not a map
tantek: Not saying declarative-only can't exist, just asking that they
be used as examples
* Bert agrees with tantek, too: the only reason to stop default actions
is if there is some event handler that defines different actions.
So the presence of that handler seems enough to stop the default
actions.
<sylvaing> Bert, no, you may want to stop a default action from propagating
higher up without needed a custom handler. It's perfectly
reasonable to want the content of an element to pan and zoom
without affecting the document outside that container.
fantasai: Happy to take 3 points here as feedback: naming is unclear,
example should be declarative, spec is confusing
plinss asks for volunteers
CSS Masking
-----------
<smfr> https://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
krit: I would like to go to LC, but first would like a review of it
krit: also got email from dbaron today
<dbaron> http://lists.w3.org/Archives/Public/public-fx/2013JanMar/0017.html
was my post that dirk's responding to
krit: he suggested that we share more text between CSS Backgrounds and
CSS Masking
krit: But feel that context of property defs is different from Backgrounds
krit: Also worried about reading 2 specs instead of one
dbaron: Flip side is that for ppl reading both specs, if it were shared,
only read once
dbaron: If not shared, have to read twice and figure out the differences.
krit: but they are different
dbaron: Different that applying to mask image instead of bg image, but
would hope it's possible to encapsulate that in a small chunk
of prose
krit: If someone is interested in both specs, CSS Masking and CSS
Background, then a lot of stuff is very familiar for him
krit: But on the other hand, for someone who isn't interested in BG
krit: needs to read two specs to understand one
fantasai: One problem with duplicating the prose is that error-fixes
have to go into both specs, which is a maintainability issue
fantasai: Replicating prose also hides any differences; have to find
the differences, then decide whether was editorial, was
missing error fix, or was substantive intentional difference
BradK: Any reason why we can't have a bg property that turns the current
layer of the bg into a mask? Then don't have to recreate all
other properties as mask properties
krit: Intention was to specify behavior of webkit masking, combine with
svg masking
krit: Reuse bg property, then cannot use bg property itself
fantasai: Really want those two to cascade independently.
fantasai: Two completely different concepts, would want to set/reset
independently
BradK: ...
BradK: Also in many cases might want to use a bg image as a mask;
this way have to set properties twice
krit: Comment to that... currently masking masks the whole element
krit: was a suggestion to be able to mask different parts of a box
krit: not the whole thing
krit: compositing and blending has a new property for that
krit: and it allows to explicitly say blend this element, or blend this
part of the element
krit: I think this is a good idea to add to filter effects / masking,
but is a different topic
krit: Don't agree that masking can be combined with background the
right way
BradK: That it can't or that not right solution
krit: Both.
BradK: Seems easier to use that way, already know how to use all the
bg properties
krit: Masking is not just masking the background, so why would we use
background properties for it?
BradK: Not saying that bg property would only mask bg, ..
fantasai: wouldn't it be confusing for a background property to be
masking the foreground?
BradK: Already defining images associated with element
fantasai: It's not an "images associated with the element" property,
it's a background property.
smfr: ... not just content in this element, but also descendants
krit: This would actually revert a previous decision of the WG to use
a mask property, and is beyond what I want to discuss with this
spec at the moment
krit: Would like to avoid reverting that decision
plinss: Seems like a bad idea to overload bg props with something that
isn't about backgrounds. Seems like a hack to me
<tpod> Seems like a bad idea to collapse with bg props
<tpod> Agreed with krit
<tpod> We have other similar but different properties eg border and outline
<tpod> Defaults are different, collapsing is different. Etc.
<tpod> Yet they share a lot
krit: Fine with referencing text from bg as much as possible, but still
need property definitions in the masking spec
dbaron: Agree for that, but also page of prose that looks like it's
copied from bg spec, and unclear what the differences are
krit: So, refernece text if not different, copy if diffeerent, OK.
BradK: Define how it interacts with overflow?
BradK: not quite clear on that
...
krit: clip property from CSS2, copied over
krit: Ok, so CSS Masking needs to define how it interacts with overflow
plinss: Anything else on Masking?
smfr: Do we have enough input from vendors other than WebKit to take
this to LC?
krit: New mask property just implemented by webkit
krit: Would vendors be generally interested in following WebKit? Did
not start an implementation yet
dbaron: I haven't really looked at the spec closely
dbaron: I can try and poke roc about it, better reveiwer for it
fantasai: I would like a week to review
dbaron: It's painful to review right now, due to copied prose from Background
dbaron: And what I'm interested in is what's different
smfr: Sounds like we want some editing before we say LC
fantasai: So how about you make the edits so that the differences from
BG become clear, then we all review it, and if it's good,
send to LC
BradK: Question about no-clip
BradK: What if you have a repeating image? Does it repeat across the
whole viewport?
dbaron: This was removed from css3-bg
krit: This is because by default, masks will clip everything to border box
krit: no-clip avoids clipping to border box
krit: Allows to show content outside border box
krit: It could mask whole viewport; but content itself doesn't flood
whole viewport
BradK: Should specify that explicitly, because alternate interpretation
is to clip to tiles that fit within border box
krit: Could you send mail to public-fx? Thanks
<dbaron> I think no-clip does make sense as a masking difference fro
css3-background, though.
Meeting closed.
Appendix A
----------
<liam> ...
<liam> your mail about running headers, and about translating from docx etc
<glazou> of course, I will have to fight howcome on that but I'm not here
for that, I really think PM and GCPM are faaaar too weak
<molly> I think there's an intriguing publishing model for print
there, but perhaps outside the focus we need in the group
<liam> we need to get to the point where it's being addressed (somewhere
in W3C) fairly soon, for sure this year.
<glazou> molly: if browser vendors don't implement it, it is dead
<glazou> as are currently dead PM and GCPM
<liam> ebooks are changing people's expectation of the platform
<glazou> only batch processors implement it
<glazou> nobody cares
<molly> I think Opera put out one lab version last year or a
year ago
<glazou> liam: exactly !
<liam> people will go into a kiosk in an airport and say, "make me a print
copy of this book while I check in to my flight".
<glazou> print-on-demand
<glazou> yes
<glazou> no more stocks in bookstores
<glazou> one demo book only
<glazou> want it ? we print it
<liam> I have seen this for google books
<glazou> with a micro-cameron press
<glazou> one book printed in 10 seconds
* liam has to go
<glazou> bye liam
<SimonSapin> glazou: page-margin boxes are weak, but I don’t see existing
implementations removing them any time soon even with a
better altenative
<SimonSapin> compat issues with existing content are the same as on the
web, even though at a smaller scale
<glazou> SimonSapin: existing implems are batch and I don't see browsers
implement it any soon either...
<SimonSapin> glazou: so what?
<glazou> SimonSapin: epub readers and browsers are not batch !
<glazou> they need better than current PM/GCPM
<SimonSapin> glazou: should we remove a feature from the spec if only
some implementations have it?
<glazou> yeah
<glazou> who said remove ?
<glazou> I said better
<glazou> better is L4
<SimonSapin> so better in addition to the current features?
...
<stearns> mmm - balanced text polyfill just posted: https://github.com/adobe-webplatform/balance-text
Received on Thursday, 17 January 2013 02:28:50 UTC