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

> I think you are getting too hung up on the word "content"
> and letting it drive a ideological argument against a
> convenient and familiar way to generate boxes in CSS, just
> because those boxes are not also generating text or pictures.

No, I'm 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:35:52 UTC