Re: CSS aims

I'll reply here, because it seems easier to get traction here than in 
either broad philosophy or in code.

I would recommend, however, reading this message with an assumption of 
disagreement.  Don't assume that I agree with Brian on anything, and 
perhaps it will be easier to figure out what is happening.

On 1/23/14 11:47 PM, Brian Kardell wrote:
> Now imagine that we hit this line and introduce an element (likely today
> this would be a div or span (maybe a link or button) with class or meta
> info and maybe some text content which is really only there so that we
> can provide a simple element we can physically interact with in today's
> DOM. OK, seems fine to me.  clearly you'd hang your icon styles off this
> new element.  It's a somewhat arbitrary line, but we know it and we're
> pretty adept at it.
>
> Two weeks later, we decide maybe that functionality isn't necessary and
> so we remove the listeners. The element now no longer necessarily serves
> some self evident purpose on its own.  We already said if it wasn't for
> that we wouldn't have added it. So now, even in this -very- simple
> example, we have an example where some would argue that this is tag
> abuse: an unnecessary element which serves no purpose but to hang a
> style off of.

Yes.  It's cruft.  While it's true that markup routinely accumulates 
cruft, your encouragement of this practice accelerate the cruft.

The problem with cruft isn't the first encounter you describe here. 
Programmers routinely ignore markup cruft.  The problem with cruft is 
that it makes it more difficult to maintain the documents and templates 
that contain it.  Even when (perhaps especially when) it's generated 
cruft, it can create unwanted surprises.

The separation of concerns you deride as purist has enabled workflows 
you don't seem to value.  Markup can be the realm of people who 
understand content creation.  Style can be the realm of people who 
understand design structure.  Behavior can be the realm of people who 
understand programming.

What I hear you saying through this is that you want your program to 
work, and you don't mind the costs this approach imposes on other people 
at other layers of the Web community.

The Web bears the scars of generations of programmers who wanted to 
created something that "just works as specified" without spending much 
effort on minimizing the long-term costs of maintenance.  A 
well-designed site or application with clean markup can move from skin 
to skin or CMS to CMS with minimal pain.  A badly-built site is often a 
throwaway, with some fishing around to save what content is valuable.

It is perhaps especially easy to think that these rules shouldn't apply 
to creators of Web Components and the like because... encapsulation! 
The reality, though, is that designers and other developers are going to 
want to tinker with the look and feel of the components.  Worse than 
that, components that rely on multiple pieces of markup are going to be 
fragile in this complex world.

This is not a matter of "academically best" or "purism".  This is a 
matter of paying attention to well-known and painfully experienced 
long-term costs.

> I am trying to show that at _some level_ this becomes impossibly
> arbitrary and maybe even wrong.  In fact, we've illustrated that there
> is potential utility to current practice in helping to decouple: having
> this extra element of structure actually enables more possible variants
> of script and CSS without touching the HTML and it is mostly benign to
> the semantics.

There is always some degree of arbitrariness, though I think it tends to 
lurk more on the dividing line between presentation and behavior 
(CSS/JavaScript) than in the structure.

> I won't go so far as to say that this is always the case or that we
> can't do better on some measures because i absolutely think we could -
> I'm just saying that I'm not -as- worried about the fact that I need
> this extra element in the markup as some.  I don't think it is necessary
> - in fact - I'm saying it may be harmful to strive for über separation
> that create significant "visual structures" via CSS.  If it is necessary
> to adorn things via CSS it should consciously  recognize that the DOM is
> important for many purposes and

And I'm saying that you're grossly underestimating the impact and costs 
of what seems to you like a small change.

> HTML is the language of serialization for the DOM.

This is utterly false.  The DOM is an object model for HTML.  This is 
probably the root of your "it's just an extra element, whatever" 
bias/mistake.

Thank you for giving me a new discussion to which I can point as I work 
toward a much longer discussion of this fallacy, its costs, and its 
impact on web standards conversations.

> Anything beyond seems to me new magic that requires explanation of its
> existing natural relationship with DOM.
>
> NOT to keep bringing up Regions, but Regions both explains and strides
> this line pretty nicely in the sense that you can simply say "this
> elements visual representation flows into that one and then that one."

You see happy line-straddling.  I see wobbling and the invention of 
brand new ways to dump cruft into markup and code.

> This is actually the quality about it that some don't like.  It isn't
> "pure".  I am saying:  please...someone...anyone....show me "pure" that
> isn't hopelessly complex.  We've seen attempts like that (xml,xsl,xsl
> fo, etc) and we've rejected it.  I'm not convinced it is possible nor
> desirable.

Worse is better, whatever.  It doesn't sound like you've spent much time 
in XML, but XSL-FO is definitely not "pure" by any means.  My 
experiences with FO are a lot of why I find the Regions spec poisonous.

> The Regions draft seems like so much more than it is on its own because
> it attempts to explain the magic of, and provide a primitive for so many
> other proposals in the process IMO. On it's own, its utility is simple
> and uses elements/explains the relationships.

I'm completely fine with creating new elements.  I'm excited about a 
model where people can drop <calendar> into a document and get a useful 
result.

I'm not all excited at the prospect of adding markup to documents that 
is meant to add dummy elements as hooks for activity that isn't clear 
from the markup itself.

Please reconsider the values you are applying to this conversation.

Thanks,
-- 
Simon St.Laurent
http://simonstl.com/

Received on Friday, 24 January 2014 13:34:23 UTC