Re: CSS aims

On Jan 24, 2014 8:34 AM, "Simon St.Laurent" <simonstl@simonstl.com> wrote:
>
> 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.
>
We're going around in circles on prose: how about providing specific,
concrete counter examples?  You are positing that there is an error in my
simple example, it seems, but you don't say where.  I have witnessed cases
just like this regularly.  It happens.

> 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.
>
Again, can you provide some specific examples/rationale?  I don't like
cruft, but it seems that in my example upshot is that a simple decision in
my js to remove a listener means that i go back and change markup and CSS -
that sounds like NOT decoupling to me - and that is the whole point of the
example.  Don't extract that to the obscene and think i am saying all
presentation belongs in HTML, its not.  Its showing the many roles of the
DOM and how difficult it would be to create a -totally- pure separation.
But Simon, I'm very happy to be shown the error of my ways with real
examples.

> The separation of concerns you deride as purist has enabled workflows you
don't seem to value.
Again, examples please.  I think you are over reading me here-my
expectation is that you will find much agreement on this if you provide
examples.

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.
>
I'm not arguing otherwise - i want more of that, not less... I'm merely
demonstrating that there is a point of diminishing return because of the
role of the DOM that any proposed solution must account for - and until
they do (and are widely used) what is the alternative? Stay with what we
have now, or offer moderate improvements?

> 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.
>
Please give me an example of where you get this from?  My example is very
small and focused and the result of that tiny element existing is that it
actually empowers CSS authors, JS developers and is benign to search
engines or any other level person in the community.  I feel like you are
extrapolating that into "font tags are awesome" which would be the opposite
extreme - not my point at all.  Extremism in all forms is bad.

> 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.
>
Again, my example is focused and it does just that.  Not just skin to skin,
but potentially new decorated behaviors too.  What is gained in this
specific example by changes at one level to require changes at the other
levels?

> 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.
>
I'm not entirely sure where this comment comes from, but yes, Web
Components do offer both encapsulation and the ability for users to tinker
with the look and feel and they use all of the same technologies.

> 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 have suffered much pain in my longer than average career, please give me
examples demonstrating both the lesson you think I am ignoring and a
solution that you think doesn't.

>> 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.
>
Because DOM is at the center of it all? If so, we might have struck upon my
point.

>> 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.
>
Estimate it for me in my example so I can understand.

>> 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.
>
It's a true distinction you make, DOM is neutral to it's serialization in
theory, but HTML is -A- serialization of the DOM and its the big one.

> 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.
>
So provide the clear distinction.  The thing that started this thread was
this - i agree with and am supportive of the desire to further efforts -
I've not seen proposals that go nearly as far as some would like which
don't add dubious complexity and high level indirections by ignoring the
existing roles played by each part of the platform in favor of introducing
new, unproven and unaccepted magic that lacks explanation.  I'd -love- to
get there, show me how.

>> 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,

This could hardly be more untrue.  I'm not going to drag on about that,
because it does little to advance the conversation, but ... Its far far
from the truth.

but XSL-FO is definitely not "pure" by any means.

Over interpreting one word in the sequence.  The entire XML stack was full
of attempts at forms of separation to supplant the perceived errors.  All
of them have largely been popularly rejected.  This is my intended meaning,
don't read far into my inclusion of FO.  FO was one attempt to answer some
of these questions in a model in which the original document was "pure"
which was a very different.  It too unsurprisingly failed.

My experiences with FO are a lot of why I find the Regions spec poisonous.

Can you expand on that? I'm not trying to merely challenge you here - if i
wasn't interested in exactly this I wouldn't have shared the original
question here... Particularly if you could share with an eye toward what
the better solution is and how: a) it makes the current situation worse
instead of better until (if) we get there b) how this new magic really fits
into the platform nicely and will be adopted.



>
>> 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.
>
Nor am I.  I'm merely suggesting that we all agree that it is currently
necessary and somehow we get by.  How do we get from here to there - and
how far is the ultimate "there" we are trying to get to and what new magic
and explanations do we require?

> Please reconsider the values you are applying to this conversation.
>
> Thanks,
>
> --
> Simon St.Laurent
> http://simonstl.com/
>