Tag Archives: Web

"off-left" convention is bad news for RTL

[This post presents a web designers technical problem, in which a hack for improved accessibility damages RTLability]

This weekend I tried to debug an annoying problem in Drupal's Acquia Marina theme on RTL mode, in which a horizontal scroll bar appears with no good reason (layout doesn't scale horizontally).

I turned to monkey HTML debugging, a term I just invented for removing element-by-element until getting to a super simple HTML file which reproduces the bug.

Eventually the one to blame was an element placed at "left: -999em" absolute position,聽 a far place horizontally, and triggered the scroll bar to appear (on FF and IE, not on Chrome). When on LTR mode, it didn't, and things work perfectly. This setting aims to simply hide the drop-down menu when mouse is not hovering above it.

Q: Why don't they use CSS display:none, which seems to make more sense than hiding things off the screen?

A: looks like it has to do with screen readers (as this article suggests), which are apparently not aware of display:none text but are aware of off-screen text. A little puzzling. I suspect that it's too old info, for it seems to be written on 2003. I wonder if new screen readers have this problems as well, and whether the reason for using off-left is not just an ancient myth.

The problem with RTL

When placing things off-left (e.g. left: -999px) on LTR mode, all browsers do NOT widen the page horizontally. It makes sense - the page goes from left to right, not from left to even-more left.

However, when on RTL mode, left: -999px does widen the page horizontally to the right (and the off-left element is actually visible when scrolling there), which is a very unwanted effects.

Here's a related drupal discussion about the problem and possible solutions.聽 The problem seems broader than just acquia marina .

Continue reading

Browser Wars: we win!

Due to Windows 7 release, many people indirectly upgrade from IE6 -> IE8 these days. You can see this here and here.

With IE7, IE8, FF, Chrome, Safari & Opera - the web would look much better. PPK's forecast -聽 that adding IE6 support would cost more money to the business - is becoming real.

This basically means that web is getting more standard than it used to, and "sites the work only in IE" should become rare even in the short term. Amen.

(Also, these days IE8 is starting to overcome IE7)

Choosing a CMS: any reason NOT to choose Drupal?

While researching the current free CMS software options, I realized that Drupal wins in almost any category: it's intensively developed, has a wide community, lots of plugins, amazing taxonomy extension, etc.

I recommended an organization I volunteer at to swtich to Drupal (they need a major upgrade anyway). After I've said all the good things to convice them, they asked me: "what are the disadvantages of Drupal". Smart question. I wasn't sure what to say. In many Drupal vs. Joomla comparisons, the only Joomla advantage (more or less) was Joomla considered easier to use. From my little experience, it's not true (maybe it was, in earlier versions). A user can easily create content when using FCKEditor and IMCE plugins, and administration is also pretty straightforward.

The ease-of-use issue matters in my particular case, for it's possible that the next admin will be less technology oriented.

What do you think, is Drupal really more difficult to administer? Other reasons to choose something else?

* WordPress is really cool for personal blogs, I believe it's less cool for a more complex organization website.

Weird CSS tricks

I was quite surprised to find out these two interesting css "tricks":

  • Data urls: putting the data inside the CSS (inline).
  • CSS sprites: instead of loading many small images (one per item), it's possible to load one big image that contains them all.. then play with the offsets to get the right image.

Radio Buttons: a bad design?

Just a thought: once a user clicks on some radio button, it'll be selected, but the user will have no standard way to remove/undo this selection. The only possibility is to switch to another radio button on the same radio button group. As far as I know*, this behavior occurs on all popular GUIs, including web, windows forms, qt and gtk, and probably others.

It's been like that for so many years, isn't it time to add a "deselect radio button" standard? Just like a checkbox, a single click would be a simple enough way to undo a selection. For special cases, a "ForceSelection" property may indicate that this radio button group cannot be deselected, to preserve the current behavior.

* I merely researched this topic, it's a just-a-thought kind of post and might be inaccurate.

HTML "name" attribute, Firefox misbehaves

It's been a long time since I wrote something about web-dev, that's because I code less web-stuff recently 馃檪

"id" vs. "name" attributes

so far, I thought that "id" should be used for unique IDs, and "name" can be used for non-unique names, i.e. multiple HTML tags with the same name. I've been using document.getElementsByName(str) to get an array of elements with the same name.

Today I've figured out that it's only partially legal: the name attribute can be used only for specific elements (such as INPUT), but cannot be used on many elements (such as DIV). For some reason, Firefox accepts the name tag for any HTML element, while IE follows HTML 4.01 and doesn't accept name tags for "illegal" HTML tags.

Proof of concept

The next piece of JS/HTML code, gives different results on both browsers:

<div name="foo">bla</div>
<script type="text/javascript">
alert(document.getElementsByName("foo").length)
</script>

Results:

  • Firefox 3: 1
  • IE 7: 0

Here is a nice explanation with a full list of "name"-allowed HTML tags.

Playing with Drupal

I've been looking for a FOSS CMS, and chose Drupal (v6.5) due to the good feedback.

I'll try to sum up the experiment shortly:

Disclaimer: I'm a new Drupal user and I might've missed many important features or misunderstood some. Please comment if you disagree with stuff I wrote below. Also, I'm not familiar with other CMS other than MediaWiki and WordPress.

The good

  • Flexibility:
    • a very flexible menus system; easily create "boxes" and set their location.
    • With some web development skills there are hardly any limits: raw html+javscript can be used in pages!
      and, of course, everything (themes + modules + core) is open source and can be modified as a last resort.
  • Modules: lots of modules that do anything and integrate drupal with other software (i.e. the gallery module). Drupal is very modular and even basic things are actually modules.
  • User roles, access: a mature user-access system. Admin can fine-tune users' permissions.
  • Integrated right to left: enabling the "Hebrew" language quickly loads an "rtl" CSS file (if supported by the theme; popular themes have it), thus enabling a fully RTL CMS.
  • Community: many answers to questions are available on the net.

The bad

  • Ease of use: installation was quick. Using the system for simple stuff (write pages, create menus) was really simple. But some other tasks were more complicated for first use, such as the Taxonomy (tagging) system, user roles system, protecting specific pages from anonymous users.
  • Modules: many modules haven't been ported to v6.x yet.
  • Rich text editor: by default Drupal has only a boring textarea as an editor. Some RTE modules are available out there. I tried TinyMCE which didn't work well with v6.x (still beta), and FCKEditor which is a bit too simple, but it works. Maybe I've missed some amazing editor?
  • Drupal as a blogging platform: after installing the right modules ("blogging" + some rich text editor) Drupal can be a fine blogging platform. Still, I find WordPress much more suited for blogging.

As a conclusion, I truly recommend Drupal for creating general purpose websites: both for simple and complex ones. For blogging-only needs, I find WordPress better and easier. Anyway, writing websites from scratch belongs to the past. I figured that out a bit late 馃檪

Beware: Flash Cookies

If you read it on Slashdot, you can skip this post 馃檪

Some guy writes about a flash web privacy thing with high importance, that I believe many people (incl. me) have never heard about.

Bottom line: the browser options "delete all cookies" or "clear all private data" are not doing 100% of the job. Flash local data can be deleted from here (on Macromedia.com)[1].

Also, you're using flashblock, right? 馃檪

[1] I wonder how they secure that thing: after all it's a flash app with privileges for messing with the client's settings!

诪砖驻专讬诐 讗转 讛讜讜讘 讛讬砖专讗诇讬

诇讗 诪讗转诪讜诇 讗谞讬 诪转诇讜谞谉 (讘注讬拽专 诇注爪诪讬) 注诇 讛专诪讛 讛谞诪讜讻讛 砖诇 讗转专 讛讜讜讘 讛讬砖专讗诇讬 讛诪诪讜爪注. 讘"专诪讛 谞诪讜讻讛" 讗谞讬 诪讻诇讬诇 转讗讬诪讜转 诇转拽谉 讜讘驻专讟 转诪讬讻讛 讘讚驻讚驻谞讬诐 谞驻讜爪讬诐, 讗讘诇 讙诐 谞讙讬砖讜转, 砖讬诪讜砖讬讜转 讜讝诪讬谞讜转.

诇讛专讙砖转讬: 讛诪爪讘 讘讗专抓 谞诪讜讱 诪讛诪爪讘 讘讗讬专讜驻讛 讜讗专讛"讘, 砖讻谉 讗转专讬诐 砖诇 讞讘专讜转 注谞拽 讻诪讜 讞讘专讜转 讛住诇讜诇专, 讛讘谞拽讬诐, 砖诇讗 诇讚讘专 注诇 讗转专讬 讛诪诪砖诇讛, 住讜讘诇讬诐 诪讘注讬讜转 专讘讜转 讜讟专讬讜讜讬讗诇讬讜转.

讻砖讗谞讬 诪住转讻诇 讘诪讘讟 专讞讘 讬讜转专, 讗谞讬 专讜讗讛 砖转讬 讛砖驻注讜转 讞砖讜讘讜转 砖讬砖 诇诪爪讘 讛讝讛:

  • 注讬讻讜讘 讗讬诪讜抓 转讜讻谞讛 讞讜驻砖讬转 讜诇讬谞讜拽住 讘驻专讟; 讻讬讜诐 讗讞转 讛住讬讘讜转 诇专转讬注讛 诪驻讬讬专驻讜拽住 讜讗驻讬诇讜 诪诇讬谞讜拽住 讘讻诇诇, 讛讬讗 诪住' 讗转专讬诐 讬砖专讗诇讬讬诐 讞砖讜讘讬诐 砖驻砖讜讟 讚讜专砖讬诐 讜讜讬谞讚讜住 讜讗拽住驻诇讜专专.
  • 讞讜住专 讛注专讻讛 诇诪驻转讞讬 讜讜讘 讟讜讘讬诐, 讗砖专 讙讜专诐 诇讗谞砖讬诐 讘专诪讛 讙讘讜讛讛 诇讛转专讞拽 诪讛转讞讜诐 讛讝讛.

讜讗讝 注诇讛 专注讬讜谉: 诇驻转讜讞 讘诇讜讙 砖讬注住讜拽 讘讘讬拽讜专讜转 注诇 讛讜讜讘 讛讬砖专讗诇讬. 诇驻谞讬 驻专住讜诐 讻诇 讘讬拽讜专转 谞驻谞讛 诇拽讘诇转 转讙讜讘讛 诪讛讙讜祝 讛专诇讜讜谞讟讬 (砖转驻讜专住诐 讗祝 讛讬讗).

讛讘讬拽讜专讜转 讬讻讬诇讜 诇讗 专拽 专砖讬诪讛 砖诇 "诪讬 诇讗 转讜诪讱 讘驻讬讬专驻讜拽住" (砖讙诐 讛讬讗 讞砖讜讘讛 诪讗讜讚) 讗诇讗 讻讗诪讜专, 讘讬拽讜专转 注诇 谞讙讬砖讜转, 砖讬诪讜砖讬讜转 讜讝诪讬谞讜转.

讗砖诪讞 诇驻讬讚讘拽讬诐 (讗讜诇讬 讝讛 讻讘专 拽讬讬诐?) 讜专注讬讜谞讜转, 讜讘讛诪砖讱 讙诐 诇讘讬拽讜专讜转讬讻诐.

注讚讻讜谞讬诐 讘拽专讜讘.