Sublime Forum

**mark.stewart** · January 13, 2016, 9:08am

Sublime is losing the ability to format the HTML and CSS code.
PACKAGE IO has lots of CSS and HTML packages, but they lack or are fast losing the ability to keyboard enter default W3C formatting for web code.
Example: how standard CSS code is formatted, and PLEASE note the spaces and punctuation, and note that Sublime almost had it right in 2013.

selector { declaration }
   /* general data compartments */
selector { property: value; property: value; }
   /* style tag and style sheet */
<element style="property: value; property: value;">
   <!-- style inline -->

Here’s what Sublime 2 and 3 are doing today, 2015.

selectorproperty:value and sometimes selectorpropertyvalue

Machines can’t even read what Sublime is outputting today: everything has to be manually formatted.
I tried to request this by posting in some GitHub hell and was nuked by some nerd who stated “doesn’t match atom”, or something bizarre like that.
It seems counter productive and non-intuitive to design Sublime to ignore DOM standards to benefit nukes.
Pushed off to look for some package (s) support (s) somewhere to fix foundation DOM code in Sublime.
What I am getting at is Sublime NATIVE CODE FORMAT THAT IS PROPERLY MAINTAINED - not nuked!

Also critical, Sublime fails when it comes to full support for the three code document locations where CSS data is always stored for DOM:
INLINE html, INTERNAL style tag, EXTERNAL file.
Package support is biased for external style, while inline and internal style are toss-ups.
Only external CSS files seem to be fully supported, which is cool only for SOME finished work but sucks for development, if you know anything about style weighting and introduction of new technologies to the DOM.

Please don’t send me back to Git Hub - I am a designer, not a programmer!
Please help the programmers and scripters build better DOM friendly packages by at least providing Sublime with basic standard DOM code formatting.
Then coders can save lots of time, wasted manually coding just about everything out of box.
What we would all like to see is STANDARDS BASED native Sublime support for HTML and CSS all versions for style inline, style tag and style sheet.

Perhaps an additional format group CSS/HTML is needed to accommodate the three locations for foundation DOM CSS code around foundation DOM HTML?
Packages Format LP, CSS Format, and CSSFormat are interesting modifiers, but none of these provide consistent DOM data entry format compliance as laid out by W3C.
CSS Extended Attributes is also interesting, but it also provides only partial keyboard support for data entry.
I think it would be a lot easier for packagers and for users if Sublime supported the DOM format for basic HTML and CSS code entry, see cool sample above.
Then packages could format various instances related to all users (script and so on), hash outs for 3 LP’s and so on…
I really don’t like the idea of no DOM support and leaving it all to packages, because as an and user all I pick up is incomplete DOM web code.
Also, because for package builders it looks impossible to include all data entry for proper DOM format for CSS and HTML.
Sublime DOM data entry formatting sucks, even using the correct document language type selection.
Which is conflicted anyway, using DOM HTML and DOM CSS vis a vis INTERNAL STYLE!
Which is especially CRITICAL for the introduction of new DOM technologies and cross browser inter-OS management, by the way.

Also, but I am not certain about this, the correctly isolated and formatted DOM streams may impact for Windows a fifth-Registry bug that screws HKU.
In other words, Sublime is missing as far as DOM compliance is concerned: lose the nukes (old war pangs poking through again).

**mark.stewart** · February 10, 2016, 2:53pm

Build 3103 Changelog
Release date: 9 Feb 2016
"A second pattern has been added to the main context that matches a double quote character (note that ‘"’ is used for this, as a standalone quote would be a YAML syntax error), and pushes a new context, string, onto the context stack."
https://www.sublimetext.com/docs/3/syntax.html
This finally fixes Sublime’s built-in destruction of HTML-CSS “code” formatting for style-declarations (compare PY “script”). CSS-HTML Package producers may still have to update their products to match Sublime’s sudden correction of prior aberrant focus. Not sure about that because I am not a programmer in any sense, just a web coder.

Natively, Sublime 3103 seems to auto-insert into Style declaration correctly, but still not completely. Prior edits of Sublime-keymap that fixed Sublime coding mess (for a year and a half, up to late Sep-2016, when all effort failed) is now partly restored to Sublime’s coder heydays, early 2014. Actually, Sublime is usable again - as usual, addictively so. Almost!

Now, no intention here to lambast what was wasted elsewhere. Are we finally ready to adapt? If in doubt, read (contributor) Patrick Griffiths notes on chapter 3 of XHTML and CSS (if you can find them). Let’s look at a looming (ignored) problem that is going to make a mess again. Sublime now leaves the user to insert space-character after selector (good idea, since we could then insert comma, attribute bridging, and so on - then after user inserts opening curly bracket, Sublime correctly inserts a space, drops in the cursor where it blinks, followed by another space, and then closing curly bracket. Coder can begin entering the first style declaration.

Unfortunately, when user closes declaration with a semicolon; there is no auto-insertion of a space. We all know where this omission comes from. Suck it in, people. Space omission occurs because programmers are confusing W3C confirmed, formalized and established space insertion with an a-standard adaptation of LTR Hierarchy “accepted temporarily” by W3C as CSS2 was formalized. In spite of that temp occlusion of sanity (that spawned an entire generation of witless coders who must be destined to be Attribute-dummies) ALWAYS follow the semicolon with a space. What went wrong? How did Sublime lose its space-footing? Some cryptic programmer who must have been a newbie daddy at home decided it would be easier to understand words if each word (CSS LOGICAL STATEMENT) was placed on its own line, out-of-context with logical LTR data flow. Honestly, Sublime Text, there are no “infantile” CSS coders out there any more. We all get it about a-word-has-meaning. No, Patrick is not to blame either. Someone else standardized the LTR hi-jack.

So the only problem with Sublime for coders now is mishandling of space-character after auto-insert and/or auto-recognition of semi-colon. Spaces would be very nice after every CSS and HTML-CSS semicolon! Perhaps Sublime’s producers think it should be up to CSS and HTML Package producers, to accommodate standards using the new Sublime 3103 foundation? Not good, and if you care to read on, you will know exactly why. No happiness pill here.

Influence (s) of Sublime update on existing App and El Capitan 10.11.3 unknown - operation-cost constraints preclude Sublime removal prior to launching inline in situ Sublime 3103 update from the sanctioned App update popup on the Mac Desktop Display.

**In any case, Sublime is no longer totally fouling attempts to enter clean code. As stated above, a somewhat improvement did occur with 3103. This is how Sublime auto adjusts coding now, for any known property.
IMPORTANT: do not assume this marginal Sublime mess-for-coders is compatible with standard code interpretation by the browser. Sublime enforced code is NOT compatible code when performing most advanced CSS-HTML styling (especially for attribute handling). Failure to insert spacing is often a literal translate to display, which most often erases or sometimes distorts code output. Sublime must ‘sense’ code problems, since occasionally as it attempts to read advanced Attribute coding it will trash pages full of open files, rendering code unreadable. Always work with backups! But thsi is not a huge problem, in Sublime’s programming. Just one (1) feature is missing, a space.

Restraining obvious fury, here is our native Sublime effort:
selector{ property: value;property: value; } <div style="property: value;property: value;">
However, this is what CSS stylesheet code compatible with standards should look like:
selector { property: value; property: value; }
<div style="property: value; property: value;">

Semi-colon spacing and curly bracket-spacing are obviously difficult for the Sublime developers to include. Anyone who manages to get their attention in GitHub will be insulted in writing and have their post swatted into the Trash can. Though its typically greedy development team is more interested in grabbing $100 for their half-what effort to date, sadly if coding is your need, Sublime remains for three years running a very risky investment.

For any Sublime developer (s) who can suck in their pride and find time and energy to fix what’s wrong, solution involves a simple correction of an historical abomination that was inflicted on the coding community by none other than one of the W3C family members, Adobe (or perhaps, one of Adobe’s notable programmers who deftly pushed things around to satisfy some sadistic urge, whatever- you senior programmers will nkow exactly what and who I refer to)… Some clux came up with the idea that (for “infantile” CSS coders who “must be lost” when CSS arrived to beef-up HTML for the masses who truly were having Attribute troubles) there was a need to “konck” CSS out of the usual left-to-right hierarchy and line up each selector separately along the left margin. Now, anyone who prefers compressed code or writes ltr CSS intelligently, without “infantile” line breaks, knows there is a reason the W3C standards stipulate that style selector and declaration format is issued the way that it is issued!
selector { property: value; property: value; }

`
Programmers building Sublime ace only one tricky bit. Inline space has to be automatically added everywhere following the semicolon, for both CSS and HTML. However, the closing double quote that closes the inline style tag (or inline style statement) has to initiate an auto backspace. Currently, there is only one problematic Attribute relationship where the inline style tag-statement conflicts with a proxy CSS Head or Stylesheet assembly, but that has retroactively been pushed by Microsoft early 2015 into the nth forever, so it is no longer an excuse to refuse code performance.

Until now, it has evidently been too much for the nuts and bolts of Sublime Text to observe code standards. Sublime is a scripting tool, not a coding tool. If the product’s human component was honest, it would state on the Sublime home page, what the product is for, not what inherited stupefaction wished it was for. Yet… perhaps that long overdue admission is not what is required.

Keep in mind that it is by no fault of Sublime that teething W3C did it’s “infantile” upchuck all over the HTML-CSS population. They knew their “infantile” solution was going to make a mess, and even stated so. The barfaholic who initiated that big boo-boo should be kept out of the resolution snapshot… and “snapshot” is all that is required. Convert Sublime break-break-break dependency to Trash and give back to HTML-CSS languages the LTR default it so richly requires to code any web page correctly. Good luck (mom and dad).

Fyi, there was even a big argument in W3C about how to spell “Konk, konk”, so dictionary? Anyway, just clean up your HTML CSS, and no more useless GitHub referrals. Avoid W3C spelling like the plague.

**tito** · February 10, 2016, 2:25pm

I tried hard to understand your problem read your post like three times, the second time I was reading automatically was edited and more walls of text appeared. Seems to me you kinda ranting because ST may not follow some evangelized standards in some situations. Tell you what, the web tech is the most non-sense and disorganized thing I have seen in my life. Standards are crap, everything is a complicated mess. Some “complicated” layouts I did in minutes with Dreamweaver and some tables 10 years ago are a headache today and takes days if not weeks that I should be enjoying under the sun in the ocean or somewhere else, not in front of a computer with a bunch of text and names that are all inconsistent between them. So lets concentrate.

Can you please directly to the point describe what is the problem you have? I can help you, something like this will help:

I write <tr style="padding:10px;"
when what I expect is <tr style="padding: 10px;"

See? looks easy to understand to me.

**mark.stewart** · February 10, 2016, 3:09pm

Sorry no not ranting. Worried about being polite. I remember and was a teeny part of the original performance fork that hit CSS turn of the century… This is not Sublimes’ fault. But it does have to absorb fall-out. I think I have outlined the correct path to resolution… as polite as possible

btw, problems arise where multiple declarations accompany one selector,
so your twerky demo is irrelevant… sorry

“looks easy” is also an irrelevant human complexion
in schema assembly the term is “combine [noun] transform” but let’s don’t go there
Sublime application programmers may know how to fix… or not have time and money
depending on where in Sublime that ancient CSS LTR boo-boo is festering

Who’da thunk it was a simple cr-literal, but go ask Adobe festering-billions later.
DW is finally surfacing for a gasp of air… real air!

**tito** · February 10, 2016, 3:07pm

[quote=“mark.stewart, post:4, topic:15765”]
problems arise where multiple declarations accompany one selector[/quote]

Ok, thank you can you please give an example? In 1 or 2 sentences.

**mark.stewart** · February 10, 2016, 3:13pm

For the Attribute that did total a dozen open pages and three web sites, kindly visit suitably boyish

http://riverleaf.net/moccasins/index.html

warning, peeps afraid of things that growl, please stay away

**tito** · February 10, 2016, 3:17pm

I didn’t understand.

**mark.stewart** · February 10, 2016, 3:49pm

gen tito, even sublime got took - You too? He-he-he-he-he
i was adding mocassins link to ‘top’ in menu above ‘kwe’
CRASH
inspect element > click on link… S=0 (for all links)
machine browser interpolates html hierarchy, display tech sees no link, secure link transform (combine transform, 2002SEP-infinity bug) display dont see nada
play dat page boy, see dem get deres distappear
think of it is Sublime, A machine class data brewster got wasted
truth… post-fork snr micro says, “anything attribute needs aw ascii programming only”

**tito** · February 10, 2016, 3:50pm

I appreciate if you don’t speak english and are doing an effort, but I dont understand and you are failing my Turing test.

**mark.stewart** · February 10, 2016, 3:57pm

It would be fun to play around with this linked disassociated attribute stream in dark web.
It is like bank-ready secure, and behind 2048 unbreakable.
Server busy on this one and anything but raw ascii would fail.
Screw ‘cloudy’ dark web access. CLOUD is a parasitic global infection.
Don’t need to watch Mr Robot to know that, do we. :-o

**tito** · February 10, 2016, 3:58pm

Absolutely

**mark.stewart** · February 10, 2016, 4:02pm

code’s a Bear, don’t go there… or there… or there…

**jps** · February 11, 2016, 12:18am

HTML and CSS - DOM data entry format