Re: Colloquial Tidbits

On Friday, 16 September 2011 at 20:02, Noah Slater wrote:
>  
> On 16 Sep 2011, at 13:34, Dave Pawson wrote:
>  
> > Which always seems to produce a grey area where such users want more
> > from the simpler system?
>  
> Yeah. I wrote a book for O'Reilly with some friends last year, and we decided to use a "plain text" version of DocBook called AsciiDoc. Unfortunately, the "plain text" aspect of it was a complete façade. Beyond marking up the titles and paragraphs for you, the only real difference was that you only had access to a subset of DocBook's features, which had themselves been re-implemented in new and confusing syntax. So, we lacked the usual SGML-aware tools to edit with, AND we had to learn the idiosyncrasies of an unfamiliar language.
This also happens with WordPress too… any slight customisation leads to you having to know either CSS, HTML, or PHP… and sometimes JS. From my personal experience, I have to go and help fix up the CSS for my girlfriend's website every time Wordpress puts out an update (as it overwrites the CSS template, and she likes some particular elements bigger than the template provides). As I'm not always around, she has had to learn some CSS herself, as she doesn't like bothering me with it.  

It's the same if you have done any Ruby on Rails… lets just say the "Rails" start breaking down real quick if you want to do anything slightly clever (i.e., jumping off the rails leads to much much pain, and sometimes one does not have an option).  

Anyway, the point is: stuff on top of other stuff a lot of time breaks down… but not always, e..g, JQuery, while not bug free, is rarely something I need to go and look at under the hood… but when something does go wrong, it really sucks.  
> I think this must be a fairly common problem with all "plain text" mark-up replacements as they go beyond titles and paragraphs and lists. Even the syntax for marking up (and it will always be a process of marking up, no matter what syntax you use) hyperlinks differs vastly between them. Unless you're a regular contributor to a wiki or a project, you almost always have to look up what the syntax for even this, the most basic element.
>  
> After we got the DocBook back, we converted it to simple HTML, and we edit that directly now.
>  
> cf. http://guide.couchdb.org/editions/1/en/why.html
>  
> > Making that leap is quite a challenge and I'd guess quite frustrating.
>  
> > I'm wondering how a dom inspector achieves any sort of validation Noah?
>  
> Well, the DOM inspector is part-and-parcel with a JavaScript console, and other tools. So I get warnings about parse errors, or security issues and such like. But other than that, I don't suppose it does. I guess what I'm saying is that I don't care about validation in the traditional sense. The way I "validate" my work is to load it up in a browser and poke at it to see if it looks and functions as I expect it to.
Me too :)  
>  When it doesn't, I will dip in to the DOM inspector to check that the serialisation of the document looks correct, and to see what CSS rules are being applied to what elements.
 So it's "human as validator": given you know have a model in your head about how it works, and you can visually see when it's "non-conforming" to your mental specification of the DOM and how it gets rendered.

Received on Saturday, 17 September 2011 07:44:23 UTC