Other sections:

Find me at:

Entries for label: html

Found 5 entries.

I Love GitHub But...

...sometimes it can only go so far.

The fantastic people at GitHub have released yet another feature to their already impressive hosting service. They are now offering downloads for which I initially became very happy.

Until I read the fine print.

See their blog entry about it and let me know what you think (and yes, you may have already spotted the comment I left there).

It's a fantastic service, GitHub rolls updates out very frequently, I've only ever seen it problematic once and I've consistently been impressed with how much they're doing for the open source community.

So why in the world would you use flash? I quote:

If you’re still one of the holdouts, do yourself a favor and install Flash ... [snip]

I'm afraid it's not going to happen. Not only am I adverse to proprietary software I think it also smells of a closed web, something which I'm sure the GitHub guys are also adverse to.

Also, the only reason they're doing it is so that uploads can bypass their own servers ... something to do with going straight into S3 I presume. Ok, that may be so, but really?

What next?

Having to install Silverlight to perform an upload to a server. Correct me if I'm wrong but I'm sure a pretty early version of HTML allowed uploads of files to servers many, many years ago.

Labels: no-flash, html, planet-catalyst, github

Inserted: 2009-02-11 21:05 (3 years ago)

Client Editing of HTML should be Banned

It is well known that the large majority of HTML pages out there are invalid HTML, use custom tags and have layout information mixed in with semantic information.

The real surprise though is that a lot of these pages have been crafted by professional designers and developers over the years. People who are actually being paid to create these things. Properly you might think. But no, not even close.

So if the people who are being paid to create the HTML can't create it correctly, what hope does that leave someone who isn't trained in it at all?

The answer is (of course) none. No hope whatsoever. Even assuming they have had minimal training in HTML, it just isn't enough.

But why is that whenever we have a new client and they say "And we want a WYSIWYG to be able to edit everything" we say without hesitation "Of course". In my view, the customer is not always right and it is wrong to give them that option.

I'm of the opinion that WYSIWYG editors are bad for clients to use especially because most editors generate HTML. The client moves on from wanting some minor formatting buttons and quickly on to "we want to edit all the HTML in the world directly".

This just causes problems. Not just immediate ones but long term ones too.

Firstly the client starts creating weird and wonderful effects (as shown today on Contented). Soon enough they start creating invalid, inconsistent and badly formatted HTML. It gets even worse when <font>, color="#bbb" and unclosed tags start appearing. Don't even get me started about embedding JavaScript in tags to popup a video window - it's not nice and it ain't pretty.

(Aside: I tried to explain unobtrusive JavaScript to a client once but I'm not sure I was explaining it on the right level even if there is such a level as a correct one.)

Even ignoring the actual edited HTML it also leaves the rest of the nicely groomed and well maintained site at the whim of someone who knows nothing about the web let alone the subtleties of HTML.

This practice is incorrect and this function should never be given to the client. It's in their best interests not to be able edit HTML and this practice should be changed.

Instead, clients should be given one of two options:

1) a a semantic markup language they can use which is relevant to their site. Anything to do with styles, layout and formatting is no concern of theirs. Instead they should know what a heading is, a paragraph, some emphasised text and what a link looks like. If you want to give them higher abstractions, how about an external link or a popup one. What about an embedded picture from a local store or from Flickr, or even a YouTube video. This is easy from your point of view and simpler from theirs (no more HTML cheat sheets for the editors).

2) or give them proper editing screens in the CMS which lets them edit only the content of the site. Whenever something should look different it should be because it is different not because someone says it should look different. The Content Management System should be for editing content and content only. It is not a Content, layout, formatting and stylesheet Management System. (And no, I don't believe they should be able to move blocks around in the CMS either but that's a different story.)

Let me give you an example of what happens now and what really should be happening. Let's say you have blog entries on the site each of which has a headline but depending on what type of blog entry it is (technical, opinion, guest), the sub-heading should look slightly different.

What happens now is the following. The editor says to himself:

"Hmm, this blog entry is an opinion piece so the subheading should be blue and bold, but this one is a newsflash, so the subheading should be red and flashing!"

This is bad. Bad, bad, bad.

To fix this you need to do some research on how many different types of blog entry there are. It's not so hard really.

You just quiz the client on how many blog entry types there are and arrange for the appropriate tickboxes, drop-downs or select boxes to appear in the CMS. This way the styles for every blog entry type are correct, consistent and don't look terrible. Furthermore, they are semantically defined rather than syntactically defined. (You have heard of the semantic web, haven't you?)

And finally, if those advantages weren't enough this last one really drums it home. When the site's design is changed in 2 or 3 years time and the blog entries have to look consistent with the new design, showing the sub-headings with the new correct styling is trivial.

Try doing that when your subheading has invalid, unknown and inconsistent HTML in it. Furthermore, if you think sub-headings are a problem, just wait until you get onto the blog entry itself, spotted and pitmarked with nasty HTML all over the place.

All I can say is, good luck to you or the poor person who has taken over on the project. That's going to one beast to untangle.

Labels: web, html, cms, planet-geek, planet-catalyst, content

Inserted: 2008-04-15 22:08 (3 years, 10 months ago)

On Fire

After three attempts last week and failing miserably, I finally added multi-level lists to Phliky. I'm on fire!

It's Sunday night, I've been hacking and ripping the rest of my CD collection all day (minus the tip trip and the face food stuffing) and I'm finally ready to go to bed in peace...

The reason why is that I finally added multi-level lists to Phliky. I have numerous automated tests to try it all out and my previous efforts were all failing on the 2nd half. This time, I added some code and ran the tests ... it was perfect.

I even added one more which was a little weird and it still worked. I'm not going to release it onto this website yet since I'll probably make a v0.2 for it and I'll try it out another time.

Now I need sleep but can rest happy I've cracked it.

Labels: phliky, html, wiki

Inserted: 2006-10-01 23:32 (5 years, 4 months ago)

Google Code and Phliky

After finding out about Google Code today, I decided to put one of my projects on there - Phliky.

So far, it's going well. I've created the project (\[p]{Phliky|http://code.google.com/p/phliky/}) and organised my repository. In true Google style, it has a very clear interface and is also easy to navigate.

Saying that, the interface is quite sparse at the moment though, but I think that it will be filled out as time goes on. As an example, when you click 'Settings' in the top right corner (to change your Subversion password), there are no links to get back to the 'Project Home' and the other 3 main tabbed pages.

There is an \[p]{Issue Tracker|http://code.google.com/p/phliky/issues/list} and they do mention in the \[p]{FAQ|http://code.google.com/hosting/faq.html} that they created it to be minimal but configurable. Looking at the configuration for the Issue Tracker, it makes perfect sense that you can add your own Open and Closed Status values and Issue Labels (which I guess is the same as tagging an entry). This way, you can make the tracker work exactly how you work, though they do already provide a decent set of defaults.

One great thing about \[p]{browsing the repository|http://phliky.googlecode.com/svn/} is that, as soon as you have commited a check-in, it is already updated with the latest Subversion Revision - no waiting round for the web accessible source to update.

One slight problem I had with the repository though was when I checked it out using the URL I found, I didn't realise that it was already the trunk - serves me right for not looking close enough. I'm used to checking out the whole repository - trunk, branches, tags and all - so I ended up making trunk/ (again), branches/ (again) and tags/ (again)! Bugger. A bit of tidy-up later and I was good - am so glad it uses Subversion as opposed to CVS.

Overall then, I'm quote impressed and think that I'll like it even more in the future.

Labels: phliky, html, planet-catalyst

Inserted: 2006-08-10 22:22 (5 years, 6 months ago)

New Thinking for a CSS Approach

Having played with CSS using other people's styles, those of my own and those already existing, I had a thought the other day about how I would try it next time.

Even though CSS is supposed to stop us from putting layout details into the HTML, it has it's own layout v style problem. Take, as an example, the following CSS:

 div.content {
    margin-top: 3px;
    color: #333333;
 }

This, in my opinion, actually contains both a style (the color) and a layout (the margin-top). I know that CSS is supposed to be all styles, which is why it is in the accronym, but sometimes it gets in the way too.

As an example, on a rather large site I have been working on, there are quite a few different pages which share some generic styles but can vary greatly in the layout. It is a very data driven site rather than a content site, therefore, there are lots of finicky bits to help certain data stand out. The above class only contains 2 styles, but for some of these screens there are many, many more styles.

Recently, I've been thinking of a new approach to this problem. On a smaller website I recently completed, in a lot of cases I was assigning 2 or more classes to each of the HTML elements. Sometimes these were each of style and layout, but in some cases, it was two styles and in others, it was two layouts. As an example:

 .bg-shaded    { background-color: black }
 .bg-highlight { background-color: white }
 .bg           { background-color: gray }
 .fg-heading   { color: #FFF; }
 .em           { text-decoration: italic; }
 .right        { text-align: right; }
 .spaceit      { margin-top: 3px; }
 .padit        { padding: 0px 12px; }

Then in the HTML:

 <div class="bg-shaded fg-heading em right spaceit padit">This is extreme</div>

I know there are various ways to help with this, especially leveraging the power of the 'cascading' part of the standard. Also, the use of <h#> and <p> and the rest can help, but as I said, the site is very data driven and therefore most things end up in <div>s.

So the thought is that there is a generic.css stylesheet, in which go the standard styles used across the whole site. Then there is a styles.css stylesheet in which go the various text, font, colour, padding and border styles - it is these which can proliferate. But the main thing which became the hardest thing to cope with was the layout for each page since they were all very different, therefore, each page has it's own layout.css stylesheet.

As a small example, here are some stylesheets:

 file: generic.css
 
 * {
    padding: 0px;
    margin: 0px;
    font-size: 10px;
    font-family: Arial, Helvetiva, sans-serif;
 }

 file: styles.css
 
 .hdr   { color: #ffffff; background-color: #006d1b; }
 .sub   { color: #ffd96b; background-color: #108d18; }
 .em    { text-style: italic; }
 .upper { text-transform: uppercase }

 file: layout.css
 
 .rounded-hdr { width: 400px; background: url(rounded_hdr.jpg) no-repeat top; }
 .rounded-sub { width: 400px; background: url(rounded_sub.jpg) no-repeat bottom; }
 .squared-hdr { width: 400px; background: url(squared_hdr.jpg) no-repeat top; }
 .aquared-sub { width: 400px; background: url(squared_sub.jpg) no-repeat bottom; }

As an example then, you can choose a heading and subheading with rounded or squared corners:

 <div class="hdr rounded-hdr">A Heading</div>
 <div class="hdr rounded-hdr">A sub-Heading</div>

 <div class="hdr squared-hdr upper">A Heading</div>
 <div class="hdr squared-hdr">A sub-Heading</div>

(I know a div of class 'hdr' or 'sub' could have been used around the whole thing and then the internal classes choose the images, but this was just an example. It also retains a great deal of flexibility.)

You can assume that the number of styles, layout CSS and generic CSS is greatly increased on a much larger project.

I might not have convinced you, but I am planning to try this out next time I run across a site with a large number of page layouts.

Labels: css, html

Inserted: 2006-08-03 15:56 (5 years, 6 months ago)