Na navigaci | Klávesové zkratky

Rubrika Web

How to Effectively Type on a Keyboard

typing on a keyboard

Learning to type using all ten fingers and mastering the correct finger placement is undoubtedly a great skill. But between us, I've spent my entire life “pecking” at the keyboard with two fingers, and when typing, I place far greater importance on something else. And that is the layout of the keyboard.

Webmasters, programmers, or copywriters encounter the problem that many frequently used characters are either completely missing or less accessible on the Czech keyboard. Typographic characters suffer the most, like Czech quotation marks „ “, ellipsis …, multiplication sign ×, copyright ©, etc. Typically, this is resolved by switching between two keyboards, Czech and English, and memorizing a million Alt-number shortcuts to substitute for the missing characters. Either way, it greatly hinders creativity. Could there be a better way?

Custom Keyboard Layout

The solution is to create your own keyboard layout. I perfected mine about ten years ago, and it's suitable for programmers, web designers, and copywriters, containing all the essential typographic tricks like dash, double and single quotation marks, etc., intuitively placed. Of course, you can customize the layout further, as described below.

All typographic characters are accessible via the right Alt, or AltGr. The layout is intuitive:

  • Czech double quotation marks „“ AltGr-< AltGr->
  • Czech single quotation marks ‚‘ AltGr-Shift-< AltGr-Shift->
  • non-breaking space AltGr-spacebar
  • multiplication sign × AltGr-X
  • ellipsis … AltGr-D (dot)
  • en dash – AltGr-hyphen
  • em dash — AltGr-Shift-hyphen
  • copyright © AltGr-C
  • trademark ™ AltGr-T
  • AltGr-E
  • ø AltGr-O

And so on, you can view the entire layout on the images.

Download: klávesnice dg v5 (for Windows)

How to Create Your Own Keyboard Layout?

It's easy and fun. Directly from Microsoft, download the magical and well-hidden program Microsoft Keyboard Layout Creator (requires .NET Framework to run).

Upon launching, you'll see an “empty” keyboard, meaning no layout is defined yet. Starting from scratch isn't ideal, so find the Load existing keyboard command in the menu and load one of the standard layouts (like the classic Czech keyboard).

Microsoft Keyboard Layout Creator

For each key, you can define the character that is typed when the key is pressed alone and also when combined with modifiers (i.e., Shift, Ctrl+Alt (right Alt), right Alt +Shift, Caps Lock, and Shift+Caps Lock). You can also designate a key as a dead key, meaning the character is typed only after pressing another key. This is how accents like háček and čárka function on the Czech keyboard.

The real gem is exporting the finished keyboard layout. The result is a full-fledged keyboard driver, including an installation program. So, you can upload your keyboard to the internet and install it on other computers.

10 years ago v rubrice Web

SASS, LESS, Stylus or pure CSS? (3)

Journey into the heart of the three most known CSS preprocessors continues, though not in the way I originally planned.

CSS preprocessor is a tool that take code written in their own syntax and generates the CSS for the browser. The most popular preprocessors are SASS, LESS and Stylus. We have talked about installation and syntax + mixins. All three preprocessors have a fundamentally different way of mixins conception.

Each of them have gallery of finished mixins: For SASS there is a comprehensive Compass, the LESS has framework Twitter Bootstrap or small Elements a Stylus NIB.

… this was opening sentences of article I started write year and quarter ago and never finished. I came to the conclusion that all three preprocessors are useless. They required to do so many compromises that potential benefits seemed insignificant. Today I will explain it.


Will Rails Discover Dependency Injection?

Few are as keen to emphasize their perceived superiority as Rails developers. Don't get me wrong, it's a solid marketing strategy. What's problematic is when you succumb to it to the extent that you see the rest of the world as mere copycats without a chance to ever catch up. But the world isn't like that.

Take Dependency Injection, for example. While people in the PHP and JavaScript communities discovered DI later, Ruby on Rails remains untouched by it. I was puzzled why a framework with such a progressive image was lagging behind, and after some digging, I found an answer from various sources on Google and karmiq, which states:

Ruby is such a good language that it doesn't need Dependency Injection.

This fascinating argument, moreover, is self-affirming in an elitist environment. But is it really true? Or is it just blindness caused by pride, the same blindness that recently led to much-discussed security vulnerabilities in Rails?

I wondered if perhaps I knew so little about Ruby that I missed some key aspect, and that it truly is a language that doesn’t need DI. However, the primary purpose of Dependency Injection is to clearly pass dependencies so that the code is understandable and predictable (and thus better testable). But when I look at the Rails documentation on the “blog in a few minutes” tutorial, I see something like:

def index
  @posts = Post.all

Here, to obtain blog posts, they use the static method Post.all, which retrieves a list of articles from somewhere (!). From a database? From a file? Conjured up? I don’t know because DI isn’t used here. Instead, it’s some kind of static hell. Ruby is undoubtedly a clever language, but it doesn’t replace DI.

In Ruby, you can override methods at runtime (Monkey patch; similar to JavaScript), which is a form of Inversion of Control (IoC) that allows for substituting a different implementation of the static method Post.all for testing purposes. However, this does not replace DI, and it certainly doesn't make the code clearer, rather the opposite.

Incidentally, I was also struck by the Post class in that it represents both a single blog post and functions as a repository (the all method), which violates the Single Responsibility Principle to the letter.

The justification often cited for why Ruby doesn't need DI refers to the article LEGOs, Play-Doh, and Programming. I read it thoroughly, noting how the author occasionally confuses “DI” with a “DI framework” (akin to confusing “Ruby” with “Ruby on Rails”) and ultimately found that it doesn’t conclude that Ruby doesn’t need Dependency Injection. It says that it doesn’t need DI frameworks like those known from Java.

One misinterpreted conclusion, if flattering, can completely bewilder a huge group of intelligent people. After all, the myth that spinach contains an extraordinary amount of iron has been persistent since 1870.

Ruby is a very interesting language, and like in any other, it pays to use DI. There are even DI frameworks available for it. Rails is an intriguing framework that has yet to discover DI. When it does, it will be a major topic for some of its future versions.

(After attempting to discuss DI with Karmiq, whom I consider the most intelligent Railist, I am keeping the comments closed, apologies.)

12 years ago v rubrice Web

Are these URLs the same?

A question that many webmasters ask: do search engines perceive these URLs as the same? How should they be treated?


The short answer would be: “URLs are different.” However, a more detailed analysis is needed.

From a user's perspective, these addresses differ only in minor details which they generally disregard. Thus, they perceive them as the same, although technically, they are different addresses. Let's call them similar addresses. For the sake of “user experience”, two principles should be adhered to:

  1. Do not allow different content on similar addresses. As I will show soon, this would not only confuse users but also search engines.
  2. Allow users access through similar addresses.

If the addresses differ in protocol http / https or with www domain or without, search engines consider them different. Not so for users. It would be a fatal mistake to place different content on such similar addresses. However, it would also be a mistake to prevent access through a similar address. The address with www and without www must both function, with SEO recommending sticking to one variant and redirecting the others to it using a 301 HTTP code. This can be managed for the www subdomain with a .htaccess file:

# redirection to the non-www variant
RewriteCond %{HTTP_HOST} ^www\.
RewriteRule ^.*$$0  [R=301,NE,L]

# redirection to the www variant
RewriteCond %{HTTP_HOST} !^www\.
RewriteRule ^.*$$0  [R=301,NE,L]

Immediately test whether your servers redirect, including the full address and correct parameter passing. Don't forget variants like Because some browsers can bypass missing redirections, try a low-level service like Web-Sniffer.

URLs are case-sensitive except for the scheme and domain. However, users do not differentiate and therefore, it is unfortunate to offer different content on addresses differing only by letter case. A poor example can be seen in Wikipedia:

Bing amusingly suffers from an error, returning the same URL whether you search for acid or a database (although the textual description is correct). Google and Yahoo do not have this issue.

Bing does not differentiate between acid and database

Some services (webmails, ICQ) convert uppercase letters in URLs to lowercase, which are all reasons to avoid distinguishing letter size, even in parameters. Better adhere to the convention that all letters in URLs should be lowercase.

Distinguishing some similar addresses is also a challenge for search engines. I conducted an experiment by placing different content on URLs differing in details like the presence of a trailing slash or parameter order. Only Google was able to index them as different. Other search engines could always handle only one of the variants.

Only Google can index these pages as different

As for trailing slashes, the web server usually redirects to the canonical form for you; if you access a directory without a trailing slash, it adds one and redirects. Of course, this does not apply when you manage URIs on your own (Cool URIs, etc.)

Finally: does the order of parameters really matter? There should be no difference between article?a=1&b=2 and article?b=2&a=1. However, there are situations where this is not the case, especially when passing complex structures such as arrays. For instance, ?sort[]=name&sort[]=city might be different from ?sort[]=city&sort[]=name. Nevertheless, redirecting if parameters are not in the specified order would be considered unnecessary overcorrection.

p.s. Nette Framework automatically handles redirection to canonical URLs on its own.

14 years ago v rubrice Web

Finally, the Truth About XHTML and HTML

I recently participated in a discussion that reminded me (again) of the deeply entrenched myths regarding the differences between HTML and XHTML. The campaign for the formats with the letter “X” was accompanied by great emotions, which usually do not go hand in hand with a clear head. Although the enthusiasm has long since faded, a significant part of the professional community and authors still believe a number of misconceptions.

In this article, I will attempt to bury the biggest of these myths in the following way. This article will contain only facts. I will save my opinions and your comments for a second article.

In the text below, by HTML I mean the version HTML 4.01, and by XHTML I mean the version XHTML 1.0 Second Edition. For completeness, I add that HTML is an application of the SGML language, while XHTML is an application of the XML language.

Myth: HTML allows tag crossing

Not at all. Tag crossing is directly prohibited in SGML, and consequently in HTML. This fact is mentioned, for example, in the W3C recommendation: “…overlapping is illegal in SGML…”. All these markup languages perceive the document as a tree structure, and therefore it is not possible to cross tags.

I am also responding to a reformulation of the myth: “The advantage of XHTML is the prohibition of crossing tags.” This is not the case; tags cannot be crossed in any existing version of HTML or XHTML.

Myth: XHTML banned presentation elements and introduced CSS

Not at all. XHTML contains the same sort of elements as HTML 4.01. This is mentioned right in the first paragraph of the XHTML specification: “The meaning of elements and their attributes is defined in the W3C recommendation for HTML 4.” From this perspective, there is no difference between XHTML and HTML.

Some elements and attributes were deprecated already in HTML 4.01. Presentation elements are forbidden in favor of CSS, which also answers the second part of the myth: the arrival of cascading styles with XHTML is unrelated, having occurred earlier.

Myth: HTML parser must guess tag endings

Not at all. In HTML, for a defined group of elements, the ending or starting tag can optionally be omitted. This is for elements where omitting the tag cannot cause ambiguity. As an example, take the ending tag for the p element. Since the standard states that a paragraph cannot be inside another paragraph, it is clear by writing…


…that by opening the second paragraph, the first must close. Therefore, stating the ending tag is redundant. However, for example, the div element can be nested within itself, so both the starting and ending tags are required.

Myth: HTML attribute notation is ambiguous

Not at all. XHTML always requires enclosing attribute values in quotes or apostrophes. HTML also requires this, except if the value consists of an alphanumeric string. For completeness, I add that even in these cases, the specification recommends using quotes.

Thus, in HTML it is permissible to write <textarea cols=20 rows=30>, which is formally as unambiguous as <textarea cols="20" rows="30">. If the value contained multiple words, HTML insists on using quotes.

Myth: HTML document is ambiguous

Not at all. The reasons given for ambiguity are either the possibility of crossing tags, ambiguity in writing attributes without quotes, which are already debunked myths, or also the possibility of omitting some tags. Here I repeat that the group of elements where tags can be omitted is chosen so as to omit only redundant information.

Thus, an HTML document is always unambiguously determined.

Myth: Only in XHTML is the ‘&’ character written as ‘&’

Not at all – it must also be written that way in HTML. For both languages, the characters < and & have a specific meaning. The first opens a tag and the second an entity. To prevent them from being understood in their meta-meaning, they must be written as an entity. Thus also in HTML, as stated by the specification.

Myth: HTML allows ‘messes’ that would not pass in XHTML

Not at all. This view is rooted in a series of myths that I have already refuted above. I haven't yet mentioned that XHTML, unlike HTML, is case sensitive for element and attribute names. However, this is a completely legitimate feature of the language. In this way, Visual Basic differs from C#, and it cannot objectively be said that one or the other approach is worse. HTML code can be made confusing by inappropriately mixing upper and lower case (<tAbLe>), XML code can also be confusing by using strings like id, ID, Id for different attributes.

The clarity of the notation in no way relates to the choice of one language over the other.

Myth: Parsing XHTML is much easier

Not at all. Comparing them would be subjective and therefore has no place in this article, but objectively, there is no reason why one parser should have a significantly easier time. Each has its own set of challenges.

Parsing HTML is conditioned by the fact that the parser must know the document type definition. The first reason is the existence of optional tags. Although their addition is unambiguous (see above) and algorithmically easy to handle, the parser must know the respective definition. The second reason concerns empty elements. That an element is empty is known to the parser only from the definition.

Parsing XHTML is complicated by the fact that the document can (unlike HTML) contain an internal subset DTD with the definition of its own entities (see example). I add that an “entity” does not have to represent a single character, but any lengthy segment of XHTML code (possibly containing further entities). Without processing the DTD and verifying its correctness, we cannot talk about parsing XHTML. Furthermore, syntactically, DTD is essentially the opposite of XML language.

In summary: both HTML and XHTML parsers must know the document type definition. The XHTML parser additionally must be able to read it in DTD language.

Myth: Parsing XHTML is much faster

In terms of the syntactic similarity of both languages, the speed of parsing is only determined by the skill of the programmers of the individual parsers. The time required for machine processing of a typical web page (whether HTML or XHTML) on a regular computer is imperceptible to human perception.

Myth: HTML parser must always cope

Not at all. The HTML specification does not dictate how an application should behave in case of processing an erroneous document. Due to competitive pressures in the real world, browsers have become completely tolerant of faulty HTML documents.

It is different in the case of XHTML. The specification, by referring to XML dictates that the parser must not continue processing the logical structure of the document in case of an error. Again, due to competitive pressures in the real world, RSS readers have become tolerant of faulty XML documents (RSS is an application of XML, just like XHTML).

If we were to deduce something negative about HTML from the tolerance of web browsers, then we must necessarily deduce something negative about XML from the tolerance of RSS readers. Objectively, the draconian approach of XML to errors in documents is utopian.


If your mind is no longer burdened by any of the myths mentioned above, you can better perceive the difference between HTML and XHTML. Or rather, you can better perceive that there is no difference. The real difference occurs a level higher: it is the departure from SGML and the transition to the new XML.

Unfortunately, it cannot be said that XML only solves the problems of SGML and adds no new ones. I have encountered two in this article alone. One of them is the draconian processing of errors in XML, which is not in line with practice, and the other is the existence of a different DTD language inside XML, which complicates parsing and the understandability of XML documents. Moreover, the expressive capability of this language is so small that it cannot formally cover even XHTML itself, so some features must be defined separately. For a language not bound by historical shackles, this is a sad and striking finding. However, criticism of XML is a topic for a separate article.

(If I encounter more myths, I will gradually update the article. If you want to refer to them, you can take advantage of the fact that each headline has its own ID)

16 years ago v rubrice Web

The stretched buttons problem in IE

As you might know, web forms have to by styled with care, since their native look often is the best you can achieve.

That said, sometimes even default look has its bugs. A truly flagrant mistake concerns buttons in Internet Explorer (including version 7) in Windows XP. If the button's caption is too long, the browser produces such a nasty thing:


The magic with conditional comments

This articles is actually an answer to e-mail by Honza Bien, who was asking me about the manipulations I was doing with conditional coments. Say, generally accepted idea is, that one kind of a comments (downlevel-hidden) is valid and the other (downlevel-revealed) is not. I tried to adapt those invalid comments the way that they would be valid. I'll explain the whole sequence.


18 years ago v rubrice Web

phpFashion © 2004, 2024 David Grudl | o blogu

Ukázky zdrojových kódů smíte používat s uvedením autora a URL tohoto webu bez dalších omezení.