Re: [css4-pseudo] The need for more powerful pseudo elements

// You made me confused ^_^ I obviously meant:

No, I'm NOT against anonymous boxes or boxes that do not generate content.
However, as soon as you're using mutliple boxes to generate styling boxes
and use no name or self-explanatory convention, your code become
unmaintainable.

You know that ::after(4)::after(1), ::after(4)::after(2) and ::after(5) are
parts of your speech bubble, but the next people which will edit your
stylesheet won't. Don't say you'll use comments because even if you do, a
lot of people won't. And even if you're using them, not using self-contained
modules will make a WYSIWYG editor unable to understand what you're doing
and merge the pseudo-elements that work toegether as a cohesive group. If
you use decorators, everything is self-explanatory, self-contained and
reusable. I will never need to copy my code to another site and change the
index of the pseudo-element-counters to accomodate the fact that on some
other site I maintain, the ::after(4) was already used for something else,
or that I want the speech bubble element to go after the ::after(10) box of
the site. I'll just use my decorator at the right location in the
'decorator' property and get the work done.

    - Clear naming conventions
    - Code is fully self-contained
    - Reusable on multiple elements/site without copy/paste

I think the case of the decorator pattern is made. Developers can willingly
decide to follow design patterns, but those are made for a reason. When
language designers have way to make the best solutions the most convenient
ones, they should. Adding "convenient and familiar" ways of doing things is
only good if the code being generated that way is also good. I maintain that
codes using nested indexed pseudo-elements do not respect the basic best
practices of good styling (ie: functional name & independance).



> > I invite you to read the CSS Generated Content [1]'s
> > abstract, introduction and table of contents:
> A working draft, that hasn't advanced in ten years, full
> of features that have mostly not been implemented. OK.

Complaining that a working draft has unimplemented features is the very
wrong way of saying that even the newly added features do not cover your use
cases. If you want a REC version, go look
http://www.w3.org/TR/CSS2/generate.html and stop complaining about the new
features. That will not change the fact that even in new revisions the
features that are considered are not the ones you said the spec did.



> > CSS Generated content was created with only this in mind.
> And that proves that generated content is not to ever be used for other 
> types of styling? I'd say that's absurd.

No. My point is that the reverse isn't true either. It's not because people
used ::after & ::before to create speech bubble effects that they represent
the optimal solution to the speech bubble problem.



> So it was just an accident or side effect that ::before and ::after 
> pseudo-elements with generated content, even when the content was an empty 
> string, allowed for full styling as boxes, and people only noticed that 
> later?

It's not an accident. There are valid use cases the specification did aim
that may require complex styling. For example if you want to use 'absolute
positioning' or 'float' to put the Chapter section number to the right of
the line while keeping the line on the left.

If you want my opinion, authors are free to do anything they want as long as
it's valid. That doesn't mean we should extend features in a certain way to
fit use cases that are better solved by another mean, even if there's some
learning curve involved.




> When the 'content' property was designed and spec'ed, it could have 
> contained a stipulation that empty string content was prohibited, and that 
> there must be some glyphs or pictures in order to work.

Why would editors go in so much trouble back then? That didn't feel worth.

Received on Thursday, 2 May 2013 17:48:19 UTC