- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 13 Nov 2012 22:33:31 -0800
- To: "www-style@w3.org" <www-style@w3.org>
CSS Collision
-------------
- Florian requested feedback
Exclusions
----------
- RESOLVED: bug 15085 closed, keep the wrap-through property
http://www.w3.org/Bugs/Public/show_bug.cgi?id=15085
- RESOLVED: bug 15087 closed, interaction of floats and exclusions
is explained in the spec section 3.6
http://www.w3.org/Bugs/Public/show_bug.cgi?id=15087
- Discussed bug 15089, making e.g. circle fit content
http://www.w3.org/Bugs/Public/show_bug.cgi?id=15089
- RESOLVED: bug 15083 closed as processing model is now described
http://www.w3.org/Bugs/Public/show_bug.cgi?id=15083
Still some concerns remaining wrt allowing an implementation to
calculate correct results.
Line Layout Module
------------------
- Steve reviewed progress on line layout module
====== Full minutes below ======
CSS Collision
-------------
florian: There's a link to the spec at the bottom of the wiki.
<stearns> http://lists.w3.org/Archives/Public/www-archive/2012Oct/att-0120/Overview.html
florian: At the last f2f, we discussed a possible CSS property that
would help deal with colliding thigns.
florian: I've had limited time, but I've started a spec.
florian: Basic idea is that you have a property 'collision' that can
take "overlap" or "avoid". If two elements have "avoid",
and they collide the one later in document order moves out
of the way. The spec defines what "collide" means, and how
they move.
florian: So please review and give me feedback or ideas for things
not yet defined.
florian: This is not yet ready for FPWD. I'm not sure if it's ready
for ED on dev.
* fantasai defers to dbaron on this
TabAtkins: I'm fine with ED. You can add the "not-yet-ready" notice
that I've put on a few specs this morning.
TabAtkins: My opinion is that I simply can't find anything that's not
on dev.w3.org.
szilles: Agree with Tab. I've got some specs there as well that are
similarly not-yet-ready.
* TabAtkins BIG RED NOTICE: http://dev.w3.org/csswg/css3-hierarchies/
dbaron: I'm not too excited about this draft, but with a big warning,
I'm okay.
florian: So with a big warning, we're okay with publishing an ED?
Rossen: I think I'm interested in co-editing as well.
szilles: Is this intended to cover floats?
florian: yes, but perhaps by reference.
<br type="lunch"/>
Exclusions Open Issues
----------------------
Scribe: ChrisL
<stearns> http://dev.w3.org/csswg/css3-exclusions/
Rossen: we have several issues, first is 15085
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15085
<stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-through-property
Rossen: do we need it? we think yes
Rossen: helpful for implementations using exclusions, easy and natural
way to prevent them affecting content
Rossen: magazine-like effects, see examples on wiki
Rossen: want to close the issue
<stearns> http://wiki.csswg.org/ideas/css3-exclusions-print-use-cases
stearns: near the end there is an example with overlays of exclusions,
some affect content and not others for layered effects.
needs wrap-through
Rossen: also exclusions overlapping other exclusions. Collision
avoid/allow is different, this allows collision but does not
affect the content
Rossen: can maybe move this into the new property
florian: how does this differ
Rossen: allows collision but content is not affected. Different, and
needed. Want to resolve issue as 'yes we need the property'
(no objections)
RESOLVED: bug 15085 closed, keep the wrap-through property
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16437
<stearns> http://dev.w3.org/csswg/css3-exclusions/#wrap-flow-property
Rossen: this was already resolved but relates to top and bottom definition
TabAtkins: its clearly not right
TabAtkins at very least add before and after
Rossen: ok
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15087
<stearns> http://dev.w3.org/csswg/css3-exclusions/#floats-and-exclusions
Rossen: Interaction of floats and exclusions
Rossen: section on exclusions and floats, 3.6 covers this
Rossen: discussed at previous f2f and mailing list, no feedback. Can
leave open, while people review the proposed solution
stearns: Or we could close it, and re-open if more specific issues arise
Rossen: changed a year ago
glazou: close it
RESOLVED: bug 15087 closed, it is explained in the spec section 3.6
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15089
stearns: shrink-to-fit circle with shape, not content outside a shape
Rossen: came up in Santa Clara, Bert or Howcome raised it, exploring
shrink to fit inside a circle
stearns: it was fantasai
Rossen: have come up with *a* solution, not one that gives us exact
content fitting in arbitrary shapes
Rossen: still do shrink to fit, apply min max sizing to original content
box per 2.1
Rossen: then we apply the shape and resolve shape percentages against
that box
Rossen: not perfect, circle will give overflow
Rossen: better than no shrink to fit at all
Rossen: more elaborate solution which approximates tightly fitting
content in arbitrary shapes is difficult to compute
Rossen: especially when the shapes are different inside and outside.
Its NP-complete.
Rossen: so do shrink to fit on box, [....]
Rossen: author is asking for auto layout, and result is not optimal
ChrisL: would like to see an example where it gives a reasonable result
szilles: would prefer to see underflow rather than overflow, can grow
the box for the second iteration
florian: so repeat and increase
szilles: increase enough
dbaron: sometimes increasing width increases height too eg images
stearns: could evaluate percentage you get when applying the shape,
as a first approximation
Rossen: opposite is when there is a shape that extends out of the
content box, will get underflow by default. Do you squeeze it?
szilles: no
Rossen: can look into adding one extra resize
Rossen: any additional reservations
Bert: some module has the 'change the fontsize' property
aaron: text-size-adjust
Bert: was discussed in context of justifying last line of a paragraph,
it's the same problem
Rossen: in those cases people will not rely on shrink to fit
Rossen: if both are dependent on resizing we need to cut the dependency.
its ok with only one extra layout
Bert: how does author express this?
arronei: text-size-adjust
Rossen: its not just text, it can be images
stearns: needs additional steps for content fitting
szilles: also for tables and line grid
szilles: keeping the lines aligned inside tables
szilles: so don't change the line heights
stearns: assume we will get to content fitting in a later spec
Bert: maybe it was removed
Rossen: ok so keep it open and add the solution we just agreed on,
resolve it later
arronei: original issue is resolved
stearns: want the algo resolved and in the spec
ChrisL: so keeping it open while spec text is proposed?
Rossen: yes
florian: could compare relative percentage coverage of box and shape
to get estimate for second iteration
Rossen: yes but putting triangles inside squares, its harder
<stearns> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15083
Concerns over Error accumulation vs. performance
Rossen: processing model was not in th spec when this was raised.
Spec was updated Dec 2011
Rossen: believe issue is currently resolved. Exclusions positioned
out of flow require the extra layout pass
Rossen: in terms of performance, that is the best we can do
Rossen: there are cases where the position does not depend on the
content so only one pass, as described in the spec
Rossen: issue open a long time, spec updated to address it a long
time ago, want to close it
* fantasai defers to dbaron on this one too :)
RESOLVED: bug 15083 closed as processing model is now described
Rossen: if there are more specific issues, then raise them
Bert: two passes is the minimum?
Rossen: no it's the maximum
stearns: we need specific cases cited where two passes does not work
stearns: if those cases are important enough to address
florian: could add a 'take as long as you want' option, off by default
Bert: not clear what the second pass is
Rossen: it's specified in the spec
* fantasai notes that column-balancing is multi-pass until it stabilizes
Rossen: That is a different part of the spec. These are separate problems.
Rossen: error accumulation is the issue here, as exclusions accumulate
it becomes significant
Rossen: so we favoured a more performant approach with a single pass
that computes all the positions, then position all the exclusions,
and then you are done
Rossen: if exclusions have predefined positions you don't need the first
pass which is the case here
florian: shrink to fit first and position later does not give extra
iterations unless content of exclusion is generated using
regions
florian: then the position and size of the exclusion change the content
of the exclusion
Rossen: this is nothing new
florian: multicol has same issue
Rossen: done with issues, just brainstorming stuff
Bert: worried we close the door on future improvements
* fantasai agrees with Bert
Rossen: no, we closed the door on 'there is no processing model defined'.
It favours a performant model
Rossen: we can add other models later, but we tried and did not come up
with one
stearns: Bert wants to ensure improvements are not disallowed. We can
add text to the spec to clarify that.
florian: how do you rest between a refinement and a random non-conforming
change
Bert: needs a lot of effort for shapes
szilles: already have a bunch of properties to control that
Bert: its not line by line
SteveZ: can't define as 'always seek optimum', its a default algorithm
florian: if we say 'must do at least as good as this' we need a measure
of goodness
stearns: place where content is laid out and shape should match. so it
is reducing drift
SteveZ: optimal is no underflow and no overflow
TabAtkins: let's wait until a better algorithm is proposed and tested
Bert: no single objective. Different products can have different objectives
Bert: can use Tex algorithm, different weighting factors. people choose
the best product for their needs
Bert: like differing opinions on line breaking. same for balancing
multicolumns
florian: if there is a single possible way to define best, its ok. But
if now, we can't say 'at least as good as' because it can't
be tested or measured
SteveZ: let's see what we get with the current algorithms, we need experience
Line Module
===========
<stearns> http://dev.w3.org/csswg/css3-linebox/
SteveZ: http://dev.w3.org/csswg/css3-linebox/#inline1
SteveZ: in bad need of a complete restructuring make it understandable
<fantasai> +1 to that
SteveZ: want to make it have a processing model, definitions, then details
SteveZ: some parts are not related to the line - text height and
line-box-contain. mainly concerned with size of the content area
that text takes up
SteveZ: em-box or max ascender/descender. for background
dbaron: is this about line height
dbaron: text does not have backgrounds. inline boxes do
SteveZ: everyone is using ascender/descender so the black background
actually covers the white text
SteveZ: moz, ie safari and chrome all use ascender+descender
dbaron: spec requires that
SteveZ: not, it requires either that or em-box. So there is less need
for the property as everyone uses the same in practice
SteveZ: text-height is the easy one
SteveZ: will say explicitly that ascender+descender is picked
Bert: think you are saying the one people implemented is the one I don't
like
Bert: backgrounds will differ if multiple fonts used on one line
(several) yes
SteveZ: we don't need it for version 3, can put it back in if I am wrong.
will copy the note from 2.1 but give the default that is used
in practice
bert: I agree
bert: but would rather the default was 1em
SteveZ: went in neutral but all the implementations picked one of the
two allowable ways
florian: a default that is different from what everyone implements is
no use
SteveZ: vendors are not clamouring for a new property. want to focus
on what it implemented now and get it done
SteveZ: so, line-box-contain
http://dev.w3.org/csswg/css3-linebox/#LineStacking
SteveZ: non-replaced and replaced elements work differently, these were
suboptimal choices so this property lets you specify different
things in the computation
SteveZ: eg use font size rather than line-height
dbaron: its the ascender+descender size
SteveZ: did not see a resolution
dbaron: hyatt did this in webkit with a prefix
dbaron: it was my proposal as an alternative to line stacking strategy
dbaron: browsers all need this internally to handle quirks mode rendering
SteveZ: so looking for confirmation that this needs to remain in the
level 3 standard
dbaron: was never super keen on it as i dislike mode selector properties
dbaron: but don't see an alternative here
fantasai: could apply to inline level elements
dbaron: Definitely applies to blocks. Question is whether it applies
to both inlines and blocks
dbaron: Have gone back and forth on this. Not a problem from implementation
perspective, just from "what controls do we want to provide"
perspective
SteveZ: will look in line-stacking-strategy for reusable bits but it
may be we are already committed
SteveZ: we have the general problem, related to line grid
bert: doesn't line grid solve all the problems?
SteveZ: for ruby its assumed the line spacing is enough that the ruby
will fit
TabAtkins: (editorial comment)
(various) dude this text is mostly from like 2001
koji: found a webkit bug on this
(scribe missed bug number)
<hober> https://bugs.webkit.org/show_bug.cgi?id=56388
<Koji> webkit bug for line-box-contain
<br/>
Received on Wednesday, 14 November 2012 06:36:34 UTC