All users were logged out of Bugzilla on October 13th, 2018

[GC]content: in :before isn't rendered for tables.

RESOLVED WORKSFORME

Status

()

P4
normal
RESOLVED WORKSFORME
16 years ago
7 years ago

People

(Reporter: leijon, Unassigned)

Tracking

({css2})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020724
BuildID:    2002072408

The URL demonstrates the problem. When building a Stylesheet for my XML-document
it seems like the :before pseudo-class doesn't work for classes with
display:table. I cannot find a reason in the CSS2-spec for this, so I don't
think this is expected behaviour. 
See also http://www.ludd.luth.se/~leijon/cv/demo/demo.css for the stylesheet used.

That is the content: tag doesn't seem to work as expected.

Reproducible: Always
Steps to Reproduce:
Surfing to the URL provided.

Actual Results:  For the "aheadline" the :before clause worked as expected, but
not for the table.

Expected Results:  I would expect the :before class to be rendered for tables as
well. In the example I would expect to see the text "This is the before-text for
table: " before the table.
Like all :before and :after content, the :before and :after of a table should be
the first child or last child of the table.  Around this content we should
generated an anonymous row and an anonymous cell.

I thought we had another bug on this.
(This would be a lot easier to fix if the frame construction code was
implemented in terms of filters of some sort (accessible through enumerators,
perhaps), so that we could put the table generated content filters on top of the
:before/:after filters and everything would work.  Something like that would
also make it much easier to fix bug 68489.)
Summary: content: in :before isn't rendered for tables. → [GC]content: in :before isn't rendered for tables.
(Reporter)

Comment 3

16 years ago
Well, I am not sure that I would expect it to end up inside the table, I would
expect to be able to use it to put a margin-note before each table of a specific
type for instance. From this point of view it the content should be generated
before the table is started, and shouldn't be too different from generating the
content for "normal" blocks. But then, I am not an expert on what the standard
really demands.

I couldn't find another bug for this when I searched bugzilla.

Comment 4

16 years ago
related to bug 3247, which also talks about mozilla's non-support of before and
after in general.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: css2
This is not related to bug 3247, since bug 3247 is about *counters*.

Comment 6

16 years ago
-> All/All

this effects some bookmarklets I'm working on as well (and was also the only bug
I noticed on the topic)
OS: Windows 2000 → All
Hardware: PC → All

Comment 7

16 years ago
First off, on the part of creating anonymous block boxes:

Section 17.2.1 of CSS2 states:

[Quote]Any table element will automatically generate necessary anonymous table
objects around itself, consisting of at least three nested objects corresponding
to a ’table’/’inline-table’ element, a ’table-row’ element, and a ’table-cell’
element.[/Quote]

However, generated content in my opinion cannot be seen as a table element,
since it is not an element at all, let alone a table element.

This alone seems to guarantee the type of use Victor wants. Furthermore, there's
also the part of general consistency. Let me explain what I mean:

According to CSS2 spec 5.12.3, the content generated should appear before the
content of the element. In the case of a table-element this would generate HTML:

<table>
Generated content by :before element
<tr><td>table cell content</td></tr>
Generated content by :after element
</table>

However, when a table such as this is created by an author in HTML, it seems to
create a document tree:

Generated content by :before element
Generated content by :after element
<table>
  <tr>
     <td>
        table cell content
     </td>
  </tr>
</table>

This makes the entire usage of before and after a little strange in the case of
a table, but it does seem to guarantee the type of use Victor wants. 
In CSS2 I think you can assume that generated content doesn't do anything on
table elements. In CSS3, generated content is pretty much a first-class citizen
and therefore there is no difference between:

   <table>
     <block> </block>
     <table-row>
       <table-cell> </table-cell>
     </table-row>
   </table>

...and:

   table::before { display: block; }

   <table>
     <table-row>
       <table-cell> </table-cell>
     </table-row>
   </table>

Both generate an anonymous table cell around the block, and an anonymous table
row around the anonymous cell, so that you end up with a two row table each with
one cell.
(Reporter)

Comment 9

16 years ago
My understanding of the spec is far from complete. But I read section 12.1 from 
CSS2 stating:
[Quote]
Authors specify the style and location of generated content with the :before and 
:after pseudo-elements. As their names indicate, the :before and :after 
pseudo-elements specify the location of content before and after an element's 
document tree content. The 'content' property, in conjunction with these 
pseudo-elements, specifies what is inserted. 
[/Quote]

The sentence "content before and after an element's document tree content" makes 
me expect the result
  :before
  <table>
    ....
  </table>
  :after
I'd expect the before and after blocks to have the same parent node as the table 
does. I would not expect them to be part of the table's document tree. 
Given:

   <foo>
    <bar/>
   </foo>

If the element is foo, then the "element's document tree content" is some
whitespace and the empty bar element. Therefore "content before and after an
element's document tree content" would be before and after the bar element, as in:

   <foo><foo::before/>
    <bar/>
   <foo::after/></foo>

The same applies to tables.

(Slightly more accurate names for these pseudo-elements would be "just inside"
and "just before the end", rather than "before" and "after". But the latter two
roll off the tongue a bit better.)
*** Bug 281370 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
QA Contact: ian → style-system
Duplicate of this bug: 385594

Comment 13

10 years ago
It also doesn't work with IMG elements.
Look at this:(copy and paste it to your browser)

data:text/html,<html><style type="text/css">img:before{content:attr(alt)}</style><body><img src="http://i201.photobucket.com/albums/aa124/SpaceMan454624573/jirachibanner.png" alt="image" /></body></html>

and the alt is shown on Opera 9
(1) It's not supposed to work for img elements

(2) there are other bugs on that topic (search for ones that are RESOLVED-INVALID or RESOLVED-WONTFIX); please don't comment further about it here.
Component: Style System (CSS) → Layout: Tables
Priority: -- → P4
QA Contact: style-system → layout.tables
This worksforme as far as I can tell.  Please reopen if you have a failing testcase, though!
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.