[SVN] r8628 (CSS)

[Thomas Aylott - subtleGradient]

Here's a bullet-pointed summary of what I see as the main issues here.

* Only a few core languages currently "include" syntaxes from other  
bundles. EG: HTML including Ruby
* The current unofficial standard for reusing syntax code in more than  
one language is to copy it.
* More and more bundles are needing to copy more and more code.
* The code that is being copied is being improved and updated by  
different developers than the ones developing the syntaxes that it's  
being copied into.
* Maintenance is becoming and will become a major issue as more and  
more syntaxes and unofficial bundles branch different versions of the  
code.
* Bug fixes can not easily be tracked and updated across all these  
languages.

Thus, a solution to these and other issues was devised by Allan in the  
form of a unified central bundle repository, from which multiple  
languages can include code.
Then the code that would be shared would become standardized and be  
able to be updated and maintained separately from each individual  
bundle.

The official timeline for release of this update is "there is no ETA   
[…] put TM 2.0 up there with Duke Nukem Forever and be positively  
surprised the day it is released".
Therefore, since the official release schedule is effectively never,  
life must continue under that assumption that we must use what we  
currently have available.

So, the logical compromise to solving all these issues is threefold:
	1) Split up the code inside the syntaxes as much as possible so that  
they can more easily be moved into a central repository once it's  
available.
	2) Duplicate the few small repository items across the multiple  
syntaxes that need them.
	3) Split up syntaxes into separate layers of functionality.  
Effectively creating 2 or more syntaxes for a single language.

#1 & #2 go hand in hand and will help to keep syntaxes structured well  
internally in the short term.
#3 Is not an ideal solution in the short term, but is the only  
possibly way to get the results that we need with the current state of  
TM1.x


That, that brings us to the practical application of all this where  
the rubber hits the road.
	What updates are currently planned for existing bundles?
	What new bundles are being created?
	What old bundles are being replaced?
	Who will actually be doing this work?
	Who will be responsible for maintenance?

Personally, my interests lie with HTML, CSS, Javascript and its  
various libraries.

* With javascript there is only really 1 possible way to embed  
javascript inside one syntax while still allowing it to be wrapped  
with another syntax. That conversation is happening on another thread.

* With HTML, there is really no perfect solution with the current  
state of TM1.x. HTML can potentially embed and be embedded by dozens  
of different languages. And there are various different dialects of  
HTML. Personally, I'm using a modified version of the current core  
HTML syntax for all my personal development.

* CSS is very unique across all "languages". CSS cleanly divides up  
into 3 distinct parts. CSS Selectors, CSS Rules & the actual CSS  
language that .css files use and that is embedded in STYLE tags in html.
	CSS Selectors are currently used in both the "CSS" syntax and the  
"jQuery" syntax. The ladder having copied an old version of the  
selector code from the former and branched it slightly. I'm currently  
working on including CSS Selectors into MooTools Javascript and then  
potentially jQuery, YUI, & Prototype.
	CSS Rules are currently only used in the CSS syntax. I have plans to  
improve the CSS Rules syntax and embed "CSS rules" into all HTML  
syntaxes. I already have a version of the HTML syntax on my local that  
does include CSS Rules.

So, the question is, what option should we choose for the very unique  
situation of the CSS syntax?
	If TM2 were out right now, it would be obvious. Modularize it and put  
it into a global repository.
But with the current state of TM1:
	Should it be modularized (#1) and then branched and copied across all  
6-10 syntaxes that use it (#2)?
	Or should it be modularized (#1) and then split into 3 syntaxes for  
including into the 6-10 syntaxes that use it (#3)?

Before making this decision, let's think of the ramifications of the  
decision.
	Who is the one developing these syntaxes?
	Whose time will be wasted by duplicating and maintaining code across  
6-10 syntaxes?
	Who will handle the bugtracking and support from 6-10 branches of  
this code?

As the bundle maintainer responsible for 4 of the 6-10 potentially  
relevant bundles:
	JavaScript Prototype & Script_aculo_us
	JavaScript MooTools (Review)
	JavaScript
	CSS

I vote that "we" follow Allan's original intent of a unified bundle  
repo and choose option #3 with the CSS syntax.
The only potential side effect is extra "junk" in the Languages list  
that can be easily ignored or hidden.



---


On Dec 9, 2007, at 11:33 PM, Michael Sheets wrote:
> On Dec 9, 2007, at 3:00 AM, Thomas Aylott - subtleGradient wrote:
>
>> CSS doesn't have a monopoly on CSS Selectors.
>> They're also used in almost all Javascript libraries.
>> They can get rather complex and it's certainly something that needs  
>> to be DRY.
>>
>> CSS Rules aren't unique to CSS either,
>> they're also used in various versions of HTML in the style attribute.
>> They are also used in a number of Ruby libraries for generating CSS.
>
> I can relate to the fact that duplication is a bad thing, it's been  
> done very poorly in various HTML related bundles.

This is not the same issue as PHP & HTML. That is a separate and  
distinct issue that doesn't relate to the matter at hand. I know  
people have been confused in the past because they chose the "PHP"  
language when editing php files. That has nothing to do with this issue.

> However something like CSS selectors isn't really a moving target, I  
> think we can work out a solid grammar for them and not have it  
> change much. What I'd recommend is a repository item that can be  
> duplicated as needed, and since it's a single 'item' it can be kept  
> updated easily.


Ideally what we need is a "global repository" as I hear is coming in  
TM2. So what we really need to figure out is a stopgap between the  
current state of duplication and the perfect solution of the "global  
repository".

I also have to goal of supporting the E-texteditor and friends as much  
as possible. I'm a bundle developer, not an application developer. I  
have no idea what their plans are for TM2 level features.

Is disagree that duplicating a "CSS Selectors" repository across  
multiple languages would have a low maintenance impact. People don't  
always stay up to date with non-core bundles. While they update core  
bundles at least as often as they update the application itself.  
Keeping the "CSS Selectors" rules separate and in a core bundle would  
require much less work on the part of the developers (EG: me), the  
support crew (EG: you) and the user.

While a "CSS Selectors" syntax shouldn't be a moving target, I will  
probably be updating it soon and it may take a while for me to get it  
all done. With all these new browsers coming out, and all these new js  
libraries supporting all this new stuff, it's worth the effort to get  
it updated and included properly across all 6-10 bundles.

> It's not a clean solution no, but I think we should attempt to hide  
> the imperfections from everyday use as much as possible.

"hid[ing] the imperfections…" is the business of the app, not the  
bundle developers. If there is a weakness in the app, then it should  
be handled by the application developer that is getting paid to sell  
that app. Whether that be InType, E-texteditor or TextMate.

However, what you suggested for js (to rename the syntax to have them  
sorted separately) would help keep people from making the wrong  
choice. No matter how amazingly unlikely and inconsequential that  
mistake may be. (this is not the PHP / HTML issue, remember)

> Keeping it inside the grammars makes it only visible to the much  
> smaller percentage that try and change/extend the grammars.

There are only 3 ways to use at a language:
	1) Open a file and the correct type is automatically chosen.
	2) Embedded into another language. The language chooses what to  
embed, no user choice available.
	3) Manually selected from the languages dropdown.

#3 is the only area where confusion could possibly arise.

If there are three "languages" that say "CSS" in them, people will  
choose "CSS" first and be happy. If they choose "CSS Selectors" or  
"CSS Rules" incorrectly, it'll be immediately obvious that they made  
the wrong choice and they need to select something else. This is not  
the same issue as the PHP/HTML issue.

>> As for the reasoning that having multiple "languages" in the list  
>> is confusing to people, simply enable the option to hide languages  
>> as you can currently do with all other bundle items. Most people  
>> don;t bother selecting a language since the right thing is used  
>> when embedded and is auto-matched to the filetype when opening files.
>
> Might be nice but until that's possible it's a reason against, not  
> for. ;)

My point above stands. The amount of potential confusion people might  
hypothetically get when choosing between these "languages" is  
infinitesimal versus the amount of actual development, maintenance and  
"other horrible side-effects" that duplication of code can, will and  
have caused to real developers (EG: me and maybe you). DRY [1] SoC[2]

>> The alternative is to duplicate all the rules and selectors stuff  
>> in all HTML lang[uag]es, CSS, All Javascript Libraries, etc...
>
> For the selectors I recommend the single repository item idea above,  
> for the rules I think it would be possible to have a top-level rule  
> that can tell we are in a css attribute and activate the rules  
> repository item. Should work for most cases.


How to break the syntax up and duplicate it as a repository item in  
each language isn't the issue. If you can include it, then you can  
include it, not matter if you're including from the repository or  
another syntax.

[1] http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
[2] http://en.wikipedia.org/wiki/Separation_of_concerns



—Thomas Aylott – subtleGradient—