- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 27 Aug 2012 22:21:40 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Pseudo-elements
---------------
Discussed Adobe's proposal for indexed ::before/::after pseudo-elements.
Several concerns were raised wrt
- separation of content and style
- accessibility and internationalization
- appropriateness of this solution to the presented use cases
- cascading multiple sources of style
RESOLVED: Make editor's draft with these issues clearly listed as concerns.
No consensus for FPWD.
Overflow as Regions and Pages
-----------------------------
dbaron drafted a spec for the ideas laid out at the Hamburg F2F:
http://lists.w3.org/Archives/Public/www-style/2012May/0531.html
http://dev.w3.org/csswg/css3-overflow/
The WG reviewed the draft together, made some suggestions for improvement,
and raised some issues for further investigation, particularly wrt the
interaction of overflow-x and overflow-y with these new overflow values.
====== Full minutes ======
Pseudo-elements
---------------
Scribe: Bert
<stearns> http://adobe.github.com/css-pseudo-elements/docs/css4-pseudoelements.html
<arronei_> topic::pseudo-elements I think is more correct.
Alan: [explains the idea: multiple pseudo-elements on same selector]
Alan: Not just for regions.
Alan: Generated content also. Presentational effects.
Alan: Multiple ::before's avoids having to add elements.
fantasai: Good to see somebody working on defining pseudo-elements, but
fantasai: cascade doesn't work well like this.
fantasai: Imagine somebody trying to override he style of a :before,
but it is actually the 15th :before...
Alan: It has a :nth-pseudo shortcut.
Alan: That selects all pseudos at one.
Alan: But we can put in an issue.
glazou: Ordinals, if interleaved :after and :before.
dbaron: If content is not 'none' on the 5th :before,the 5th before gets
generated.
Alan: If there is nothing in the 1st four, than the 5th is actually
the first.
peterl: it doesn't create, only select.
fantasai: What another use cases?
alan: Example is if you have pseudo for a quote that matches [???]
alan: If you have two :afters, you can have two styles for those two parts,
dbaron: That doesn't sound a case that generated content is for.
[See Mark Twain example in spec]
dbaron: That's bad practice because if you take the style sheet away,
the content disappears. I don't think we should encourage that,
and I absolutely don't think we should have that example in
the spec
glazou: But it is existing practice.
plinss: Difference between encouraging and allowing it.
dbaron: Don't think it should be allowed to drive the design of features.
TabAtkins: Multiple cases where you run out of pseudo elements.
alan: Valid use case. Different styles for different added blocks.
plinss: It can come from attributes or just four different strings.
dbaron: This is way beyond what people should use generated content for.
fantasai: Might also want to turn some of those into links, e.g.
<molly> Generated content's a serious issue for a11y as well - we're
trying to discourage the issue dbaron describes - it's difficult.
* fantasai thinks this is a use case for XSLT or STTS
<bert> q+ to suggest templates instead
TabAtkins: You run out of elements to attach style to.
fantasai: image borders can do that example.
fantasai: shouldn't need to know which pseudo style.
Tab: want to do speech bubble and quotation marks
TabAtkins: There are well established patterns for using pseduos for
styling.
dbaron: well, ignoring that the whole business of doing quotation marks
with pseudo elements is a disaster...
fantasai: Everytime [scribe forgot the rest]
tantek: We had :outside:inside at some point.
fantasai: [missed]
<tantek> ::outside and ::inside - but yeah
alan: multiple style sheets with their own pseudos that *don't* cascade
is another use case.
ted: So you have to know how many pseudos an element has?
florian: If you want two icons, e.g.
<fantasai> e.g. external link, or PDF link
<fantasai> or both
ted: numbering the pseudos is not so good for avoiding clashes between
styles sheets.
tantek: There are use cases, but indexing mechanism will lead to competition
(war) between designs.
Bert: Hixie came up with multiple pseudos a long time ago -- doesn't
cascade.
Bert: That's the most important reason for template idea -- template
doesn't have numbers, they have names.
?: how are they ordered
Bert: visual layout
glazou: Writing ::before(n) is very easy for authors to write and modify
glazou: all solutions, including templates, are more difficult for
authors than multiple :befores.
* fantasai disagrees with that
tab: Template cannot create something that allows line breaks between
the pseudos.
<TabAtkins> Template forces us into, at best, something like inline-block.
<glazou> http://css-tricks.com/use-cases-for-multiple-pseudo-elements/
<TabAtkins> Having a link with an external and type badges afterwards,
we'd be unable to have the link break across lines like a
normal inline element.
glazou: This is somebody who is in favor
fantasai: It works fine in simple cases where you don't have interactions
among multiple sources of styles
glazou: How do you select a created box, or a collection of boxes.
We can currently.
glazou: It is in the proposal: :nth-pseudo
ted: How about pseudos in other modules?
ted: E.g., overflow regions, as proposed by dbaron.
ted: Don't know how many regions, cannot selects the last-but-one.
Alan: You can selects from the end, :nth-last
TabAtkins: Fine if there is a fixed number, not if the style can
generate more.
alan: could even apply nth-pseudo to regions, to select the nth region,
using 'region' as the type.
florian: allows nth line?
glazou: Probably left over from older verison of spec. Not supposed to
work.
florian: different properties apply to different pseudos. Do also to
nth-pseudo?
glazou: Absolutely,
florian: Sounds like nth-after and nth-before might be better, you'll
know which properties apply.
glazou: we thought about extending later. We saw a few requests from
users.
glazou: typically mutliple decorations, borders around an element.
glazou: Need multiple paddings between the multiple borders, e.g.
Bert: I think you should distinguish between what people are trying
to do, and what they are requesting.
Bert: E.g. people want multiple borders, but they request multiple pseudos.
Rossen: Can you point us to actual examples of this?
* fantasai does not think that we should be trying to reinvent SVG
using ::before syntax
* Bert thinks we'll soon have XSLT in CSS :-)
* fantasai >__<
alan: users asking for multiple generated content. Not sure if pseudos
is always the best way to draw pictures
TabAtkins: Many things that are cool to have, later.
Rossen: As soon as you extend structure into this, it's trying to
reinvent HTML in CSS
rossen: adding complexity into the solution, adding structure, sounds
like implementing HTML inside CSS.
rossen: Why not use HTML?
fantasai: XBL was also supposed to solve this.
TabAtkins: But nobody implemented that.
glazou: We have a way to present all attributes with the same style,
but not with different styles.
fantasai: So that is a use case.
fantasa: But can also make it appear as an element, able to be styled.
fantasai: We're also trying tos olve the multiple border case,
multiple icons case, etc.
fantasai: We should try to solve these in a better way.
fantasai: This proposal is awkward for all of them.
alan: I think it is the easiest possible solution.,
<sylvaing> ... and then developers will want pseudos to have read/write
OM properties, then attributes to make them drop zones, give
them ARIA roles or attach event handlers to them, then there'll
be APIs to create, move and delete these pseudos. And then we
have recreated the DOM except without a static document language...
until someone writes a JS library to generate them from such
markup.
<dbaron> I think including :before and :after in CSS was a mistake.
glazou: Selecting columns, is other exmaple.
florian: There is a pseudo in GCPM for that.
ted: [missed]
vincent: Can already have collision with current single :before pseduo.
* fantasai thinks if the problem is turning attributes into elements,
we should solve that directly.
* fantasai also agrees 100% with sylvaing
steve: The comments on columns are relevant: consider replacing style
on a group or on individual parts of the group.
ted: Descendant of the :before?
Steve: ::before becomes a shorthand for the collection of all the ::before(n)
alan: Other section in spec is object model for pseudos.
sylvaing: drop zones, all things that a node can be, we're rewriting
the DOM... pseudos are like nodes in all cases, except you
cannot instantiate them from a static markup
glazou: You can access them, even if not instantiate.
sylvaing: No, you cannot currently. How attach event handlers.
<arronei> we should stop this pseudo madness ::before it gets out of hand.
glazou: The day we have stuff on the right hand side, don't you think
people will want :hover there, too?
sylvaing: Not sure what problem we're solving anymore.
* fantasai thinks we have a solution in search of use cases, and it's
finding lots of them that it handles not-very-well
TabAtkins: Problem is just with OM?
sylvaing: All the things we're adding make pseudos act like elements.
glazou: Yes, all specs do the same.
sylvaing: So we're creating elements, except there is no DOM for them.
dbaron: We're creating new structure, rather than slots into which to
pour structure.
dbaron: Most other pseudos are about styling ranges of what already exists.
dbaron: The other pseduos other than :before/after are about things that
already exist (first-line, first -letter, column).
dbaron: Before after make new content.
dbaron: I think :before/:after were a mistake.
florian: Without the DOM, this solution feels incomplete.
TabAtkins: People should not expect that a pseudo can be a drop zone.
glazou: We've been asked for this for 14 years.
glazou: Our customers ask for this.
glazou: They know what they need.
plinss: Whether to have pseudo-elements is no longer a question.
dbaron: But this is a different question. What about accessibility, e.g,
plinss: We had pseudos for scrollbar parts, that's why we added double
colon, to make it extensible.
plinss: We're already adding extra structure.
dbaron: Separating content and presentation. Most of the examples here
are mixing them back up.
plinss: That is not black and white. Sometims text is presentational,
sometimes images are content.
dbaron: There are guidelines from i18n, a11y, etc.
dbaron: Text presented to user should not be in attribute, e.g.
glazou: Wikipedia has content in attributes
glazou: They said it was too complex too fix.
dbaron: They used that solution because the tool was available. Now it
is is too difficult to fix. It wasn't when that started doing it.
glazou: EPUB is full of attributes with text.
glazou: You *have* to render those attributes.
fantasai: A simple transformation language will be a simpler way to
solve this.
glazou: a transformation language will NOT be dynamic ; if you want a
batch one, I have built STTS 15 years ago and browsers did not
adopt it
alan: The last use case in the draft is not about generated content.
alan: It creates regions by means of pseudos.
vincent: I'm sensitive to accessibility argument.
vincent: This case doesn't have text in attributes.
dbaron: I think the example can, and ought, to be done in other ways.
dbaron: Styling existing content and making content is different.
dbaron: Here you are styling, but using a tool that is creating content.
alan: This is about redirecting content that already exist,
alan: Last region as auto height, so displays all content. But could
use overflow regions as well. Or a different way to use fixed
number of regions.
plinss: I have no objection to creating arbitrary regions. Not sure I
like this proposal, though.
plinss: Seems hacky.
Alan: It is meant to avoid having empty elements in the mark-up.
plinss: Yes, agreed, but :before/:after seems a hack for this.
TabAtkins: Looks hacky, but can be written differently.
plinss: I think we like what it is trying to do, not how it does it.
vincent. OK, but how do we go from there?
plinss: I tried to write it up, never finished. I think I should go back
to that and try to write it up.
glazou: Another type of pseudo?
glazou: We need multiple :before/after, But I understand you don't want
to use that for all use cases.
glazou: We decided to restrict ourselves to :before/after for immediate
needs.
glazou: Web authors are expressing need for more.
plinss: I want to try and get something better,
glazou: Adobe's prototype is real fun to play with. Can do things
couldn't do before.
glazou: It makes sense to separate selectors and pseudos and extends pseudos.
plinss: OK to make an ED.
plinss: Not currently ready for FPWD though.
vincent: peter, want to be co-editor?
plinss: Want to be involved, will see about co-editor.
fantasai: Not OK with FPWD, but defer to others for editor's draft,
florian: Even without multiple :before/:after, the rest is still useful.
florian: I want to work on it.
[discussion about people implementing too soon]
plinss: Fine as an editor's draft.
fantasai: We should point out to people that we have no consensus.
glazou: An editor's draft is a proposal.
tantek: List issues explicitly in the document.
glazou: Sure.
[discussing issues that say "we don't really want this"]
dbaron: Should mention a11y and i18n issues.
dbaron: And ask whether this is more power than we want in CSS.
fantasai: And it should mention the trouble with cascading.
RESOLVED: make editor's draft with these issues clearly listed.
Overflow as Regions and Pages
-----------------------------
See also Hamburg F2F minutes wrt 'overflow: repeat':
http://lists.w3.org/Archives/Public/www-style/2012May/0531.html
<Rossen> http://lists.w3.org/Archives/Public/www-style/2012May/1197.html
<florian> http://lists.w3.org/Archives/Public/www-archive/2012Aug/att-0005/Overview.html
dbaron: When an element has overflow,
dbaron: if it were paginated, it would break here,
dbaron: we say we make another box as a sibling of the first box.
dbaron: That one may also be broken, until we have all content.
dbaron: With auto height, it doesn't do anything.
dbaron: But if you set fixed height, you'll get multiple boxes.
dbaron: Interesting question is to style the different boxes.
florian: Multicol has behavior to add columns to the side.
florian: At least you can see them, not always the best way to style it.
florian: Might instead want to add another multicol box below it.
dbaron: [looking at example 1]
dbaron: In example 2, you can style the regions separately.
dbaron: Let's look at the examples. Inherit style from regions into
the content.
dbaron: E.g.. a larger font for the first region.
dbaron: Example 4 has different :visited styles in the diff. regions.
glazou: This is much better than @rules.
steve: Which @rules?
glazou: Like regions.
dbaron: Which props you can use in the regions is a bit complicated.
dbaron: Example 5 is maybe more realistic use case.
dbaron: I added a property 'max-lines'
dbaron: You want pagination after a certain # of lines.
jdaggett: What if height is set?
dbaron: Depends on whether height constrains more than max-lines.
glazou: You can make the same argument about cascading here as with
multilple psuedos.
dbaron: But you can kill this with a single 'overflow' property.
fantasai: The ability to reset the whole thing is important.
glazou: Both proposals have that.
dbaron: I'd like to use the same name in the overflow and in the name
of the pseudo.
dbaron: That's why i don't like "repeat".
dbaron: I came up with "piece" and "part"
fantasai: How about "copy"?
glazou: They are not copies.
steve: The words don't have the same function in the two places.
dbaron: Fine to use noun in both places
fantasai: Fragment can be both a noun and a verb :-)
SteveZ: "Fragment" can, yes.
alan: We can put an issue that we don't know the name yet.
vincent: I think we change the name before we publicize it more, though.
dbaron: prefer part over fragment, but OK with fragment.
glazou: content property applies only if region exist?
dbaron: Probably 'content' doesn't apply.
TabAtkins: About stuff to the right of the pseudo-elt.
TabAtkins: Make the '::' a combinator?
TabAtkins: There are few current pseudos that you'd need to special case.
TabAtkins: But they already have spacial case in that they allow a
single ':'
fantasai: a ::before vs a::before
fantasai: if '::' becomes a combinator, then they would be the same.
plinss: Or treat the whole pseudo-elt as a kind of combinator.
glazou: Yes, allowing the space needs a lot of changes to the specs.
steve: rathole?
vincent: 'max-line' is like 'max-width'?
vincent: limiting the size and the overflow are different things.
florian: Yes, it is in this spec just because it needs a host.
dbaron: It is not processed the same way as height, it is processed
when you determine breaks.
steve: yes, cannot set a height of that kind today, but we could have
a height value that could do that thing.
ted: 'min-lines'?
dbaron: Why would you want that?
steve: problem with giving height a value in lines maybe that it
depends on layout?
dbaron: A little scared, but it might work...
plinss: And 'max-width: 3lines'?
TabAtkins: Would be meaningless in horizontal writing modes.
plinss: having a unit I like, but scary.
* Rossen likes line-count instead of max-lines
fantasai: Pseudo element is normally a piece of an element, and properties
on it win over the properties on the element itself.
fantasai: but here, they refer to the same thing.
fantasai: 'foo#f1' is more specific than 'foo::nth-region'
so shouldn't it win?
steve: Did we have a similar issue with region styling
dbaron: ...
dbaron: I'd want some specificity for these, same as pseudo-class, maybe.
florian: Other issue is related to multicol, does this apply to columns?
dbaron: I think nth-region applies to columns.
dbaron: It would apply anywhere where you do breaking.
dbaron: No, actually, it would not be put on the multicol element itself
plinss: Doesn't matter why something breaks.
rossen: Any restrictions on what it applies to? Can break anything?
dbaron: table parts may be problematic.
rossen: Create extra table cells... create extra rows... awkward.
fantasai: "you get what you asked for"? :-)
Rossen: At least something to consider.
dbaron: People suggested this should become an overflow module.
dbaron: overflow-x/y in this context also need to be specified.
florian: Yes, they interact poorly currently,
fantasai: good reason to address them all together in the same place
alan: does 'break-before' apply?
steve: 'break: always (or 'all') would do it.
florian: Does 'break-*: region' apply?
fantasai: I think I'm OK with using the same keyword.
steve: Example is multiple columns, which contain regions.
glazou: we have several proposals for nth-*. So I think nth-pseudo(type)
is better.
dbaron: Don't think the word "pseudo" should be in the name.
glazou: We can glue all proposals together.
<arronei> I agree with dbaron I don't think "pseudo" should be in
the name either
fantasai: But what does it gain us? The name of the thing you take
the nth of has to be in there anyway.
dbaron: I'm reminded of first gradient proposal, with different arguments
depending on type argument.
[discussion confused about whether it is about the word "pseudo" or
about the concept of "nth" with a param]
* hober function(attr, "href") isn't better than attr("href")
steve: it's the same thing every time: the nth of a type.
florian: Not exactly the same meaning on all cases.
fantasai: but you can put the type after a dash, why put it in parentheses?
steve: gradients had different params in different types. This is just
one param.
Tab: Yes, but for future extensions safer to prevent possibility of
different params.
florian: nth-region is also shorter, that's enough of a reason.
plinss: *:before:nth(3)
plinss: ::before:hover
plinss: Why invent a mechanism. We already have pseudo-classes.
glazou: ::first-letter is ::letter:nth(1) ?
steve: Cannot necessarily apply it to everything.
plinss: :first-line would just be an alias.
florian: You cannot apply 'overflow' to the pseudo, dbaron said, but
I think it useful to apply it to the last region.
dbaron: Can set height: auto.
florian: Not quite the same thing.
dbaron: My worry is about the first fragment.
dbaron: You only use the fragment styles *if* the element is fragmented.
dbaron: If you turn off overflow on the first fragment, suddenly you
don't have overflow anymore...
TabAtkins: Or don't start counting until the second fragment.
dbaron: Doubles the cost of selector matching.
dbaron: So either don't match selectors unless you have the special
overflow value, or
dbaron: don't apply frgament styles until you reach the second.
plinss: 'overflow: fragment' and it doesn't create fragments, do the
properties apply?
plinss: As soon as you set 'overflow: fragment' all styles apply,
whether or not you have more than one fragment.
plinss: All of the boxes of an element are considered fragments, if it
fragments for any reason.
dbaron: That was not how I specced it.
dbaron: Mine was only if you also specify 'overflow: fragment'
fantasai: Say you want a fragment of a given height.
fantasai: [draws on white board]
fantasai: and now imagine I want borders on all fragments.
fantasai: I wind up breaking one fragment across pages, you say that
each piece has to be assigned the fixed height? But that
doesn't fit (or we wouldn't be breaking it).
dbaron: I had to write fancier selectors, like :nth-region(n+2) for
paginated mode.
fantasai: A fragment that is itself broken over two pages should not
increase the number of fragments as seen by the pseudo-elt
selector.
plinss: Same issue in multicol.
steve: If a multicol element overflows in a paged environment, where
does the next column go?
fantasai: If you have fixed height on the multicol elt, the overflow
will be on the side and will just be cut off if you print
the page.
steve: Now I set 'overflow: fragment'
florian: It should create repetitions.
florian: Current wording in multicol and in this proposal doesn't do
that, but it should.
florian: Current does work if
florian: elt has 'columns' and 'overflow fragment'
florian: I think the 'overflow-style: paged-*' should be pulled into
this spec, too.
florian: you can style the pages, but more limited; cannot position
them, e.g.
dbaron: Some things you might want to apply to paginated overflow do
not make sense here.
dbaron: E.g., scroll two pages at once.
plinss: When you print, does it degrade well?
fantasai: Stack of pages?
dbaron: 'overflow:scroll' not defined well for print either.
plinss: Dynamic presentation vs static presentation.
plinss: Define how it degrades. Common model.
fantasai: One example of overflow 'paged' when printed [draws picture
of a fancy decoration/navigation area around a paginated
content area],
fantasai: might want the "chrome" here to replicated on each printed
page with the content of the next 'overflow: paged' page.
dbaron: but what if the inside page is bigger than the outside page?
and how to tell which content gets repeated around the inside
pages and which goes on outside pages before/after them?
SteveZ: Better done with media queries?
dbaron: *If* the author provides media queries, yes.
plinss: If you haven't anticipated a certain environment, it should
still behave reasonably.
plinss: browsers should do something rational even if author didn't
provide media query.
steve: This is auto-generation for a single stream.
steve: Doesn't handle merging two streams.
steve: Page templates are about that.
steve: They do this, but do other things as well.
steve: They allow to select the next container based on what content
to position.
steve: So this doesn't replace page templates.
florian: I think alan convinced me of that.
alan: region chain, with different sizes: probably need to replicate
quite a bit of the behavior of that from the regions spec to here.
dbaron: I thought fragmentation spec would do that.
fantasai: Fragmentation covers how you break the flow across fragmentainers.
Doesn't say how you size them.
alan: e.g., two regions in the same row, and one region has a forced break.
vincent: first pass to figure out what goes into the boxes. Maybe smaller
font size in one region means more content goes into that. Need
to work out recursive dependencies.
vincent: Either dependencies or allow gaps.
vincent: No need to resolve all that now. Just keep it in mind.
Rossen: dbaron, are certain properties going to be restricted to regions?
Passing styles down from region to content is tricky. Restricting
the set of properties makes it easier.
dbaron: The set of properties is restricted. More restricted in what
applies to content than what applies to the region itself.
fantasai: Maybe want to change display-outside on a fragment, but don't
think so for display-inside
florian: Say we have a flexbox for first few fragments and then the overflow
is displayed differently.
vincent: difficult to implement when size depends on content, e.g.,
when diff. font size in diff. regions. Need 2nd pass.
vincent: I don't remember all the cases, but there were interferences.
vincent: It seems the same applies to 'overflow: fragment'
florian: Can we discuss 'overflow-x/y' and why it is a problem in
combination with this?
florian: We implemented to ignore overflow-x if o- says 'paged-*'
and vice-versa.
Bert: I tried to overflow-x/y up and never managed to, for much the
same reasons.
dbaron: We had a discussion maybe 8 or 9 years ago.
dbaron: We concluded that all combinations mixed, except 'visible'
rossen: I think we had it specced, and IE9 implemented that, I think.
florian: overflow is a shorthand, one question is what the longhand is
for some of the values.
florian: I may want to overflow pages only in vertical direction.
Rossen: I remember looking at some code for marquee with that question.
florian: I think we should make overflow-x/overflow-y be logical so -y
is always in block direction and fragment etc. only apply in y
direction
florian: overflow-x/y is really messed up
fantasai: Should we make background-repeat: repeat-x/y match that, then?
florian: And then add writing modes... it just doesn't make sense.
florian: I think there is a link saying all that somwhere.
<florian> http://lists.w3.org/Archives/Public/www-style/2012May/1197.html
florian: When we have reworked overflow, we don't actually need
'overflow-style' anymore.
tantek: We worked it all out and the result made less sense with logical
directions, at least in UIs.
florian: Some edge cases are not elegant.
tantek: Edge cases are often not elegant.
florian: We had to do strange things with overflow-x/y outside the cascade.
florian: So I'd like to see if we can't make something better.
tantek: The simple answer is if you set 'paged' on one, then the other
is also paged.
florian: If you put overflow-x: paged; overflow-y: fragment; what happens?
Rossen: We did what most other did. Visible trumped all.
<fantasai> no, that's wrong
<fantasai> Rosen: if either was not-visible, visible became set to 'auto'
dbaron: We do 'hidden'
Rossen: Have to figure out which one wins.
Rossen: With fragmentation added, specs needs to call it out.
dbaron: we turn some values into hidden, and others into auto
dbaron: We turn some into hidden and some into auto.
rossen: We did some analysis and most implementations were similar.
rossen: It makes sense to have 'visible' in one direction and hidden
in the other and that shouldn't turn into auto.
<dbaron> really we're just turning visible into auto
<dbaron> we're turning the pre-2004 overflow:hidden into hidden
dbaron: Essentially we are turning 'visible' into 'auto'.
florian: The (prefixed) marquee in webkit doesn't use overflow-style,
but overflow.
florian: if that is the only implementation, as it seems to be, maybe
we can forget what the marquee spec said and redefine overflow.
fantasai: Maybe the value in the block direction should always win?
dbaron: That's reasonable, but we do something different for 'visible'
currently.
florian: It is not exactly that. Example: [draws]
Vincent asks about what we do with dbaron's draft
vincent: did we agree to publish dbaron's draft?
dbaron: Yes, as editor's draft. I want to name it css3-overflow.
florian: [drawing]
florian: last line on page has an image sticking out below. In paged mode,
that overflow is just hidden.
fantasai: We add pages for abs pos elements.
fantasai: you have to; some websites abspos the entire page
Rossen: The exception in our implementation is with mixed directions.
Rossen: Fragment in orthogonal direction, to not lose any content.
fantasai: [draws horizontal mode page with long vertical-mode block
sticking out on the left]
fantasai: If the height is 'auto', we automatically trigger multicol
to display that overflowing text. [CSS3-WRITING-MODE]
Day 1 closed.
Received on Tuesday, 28 August 2012 05:22:10 UTC