Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Mozilla To Add Support For XForms, World Yawns

By fd in Internet
Thu Aug 12, 2004 at 07:58:31 PM EST
Tags: Internet (all tags)
Internet

It's ironic that Microsoft could help further cement its dominance in the browser market by joining its largest rival in an effort to support web standards.  At the same time, that act would go a long way towards improving the web in general for developers and users alike.


Mozilla announced that they are working on implementing XForms with Novell and IBM.  XForms is a recommendation from the W3C Forms Working Group that, if widely adopted, is poised to make creating and entering data into forms online and elsewhere a much nicer, richer experience for most people.  For instance, XForms allows one to check data values while they are being typed, indicate that some fields are required, and constrain values to ranges, all without scripting.  That's fantastic.  Unfortunately, it probably can't be successful as long as most of the world is using Microsoft's Internet Explorer (IE) and IE doesn't support XForms.

Think about what would happen.  Imagine that XForms is implemented in Mozilla, a browser with a paltry 3-5 percent of the world-wide browser market.  The rest of the world uses IE.  A developer has a choice to make.  Is he going to support XForms and Mozilla?  Is he going to support IE only?  Or is he going to support both, either by using legacy HTML forms or by going to the herculean effort to support XForms and Microsoft's solution (InfoPath, ASP.Net forms)?  XForms plugins already exist for IE, but who wants to require an obscure plugin download for visitors to use their website?  Take the SVG plugin, for example.  SVG is a great technology, the plugin is a separate download, and no one uses SVG.  It's unrealistic to think (and history has shown) that anyone but the smallest group of developers will support XForms if it isn't bundled in some form with IE.

Part of the trouble is that most typical users don't even know Firefox and Mozilla exist.  And of those that do, how many of them even remotely care that Mozilla plans on supporting XForms or web standards in general?  Most (corporate) developers don't or can't care that Mozilla exists because of IE's browser dominance.

Here's a far-fetched and crazy idea.  Microsoft joins Novell, IBM, and Mozilla to support XForms.  This would be a win for everyone.  With IE market-share slowly eroding (very slowly, granted) to Firefox and Mozilla (TechWeb News, InternetWeek, Google), standards-compliance could go a long way towards keeping developers and users on Microsoft's platform.  The goodwill generated alone would certainly benefit Microsoft's reputation among developers.  If IE makes standards-compliance a priorty and adds good features like popup blocking (available in the new service pack) and tabbed browsing (rumored feature for the next release), then why would anyone switch if it came pre-installed?  The main reason people switch now is because IE doesn't have all the great features that the Mozilla products have.  (I don't include those people who like software because it is free as in liberty -- the perception that IE is free (as in beer) is, unfortunately, good enough for most Windows users.)

Your typical web developer would love this too.  Who likes coding two versions of their CSS or Javascript or HTML just to support quirks in IE?  Who wants to code a data input form two different ways?  What company can afford to have its developers spend extra time to support a browser with such a small market share?  It would be a boon to the entire web development community, and consequently to users in general, if IE had more respect for standards.  If the only argument anyone could level against IE is that it isn't free (and really, who could begrudge a corporation trying to earn a little honest money), Microsoft would probably stop losing users and developers to Mozilla.  And Microsoft could begin to achieve that by joining the Mozilla foundation with XForms support and incorporating the best features of Mozilla into IE.

Of course, I don't hold out much hope that Microsoft would actually do this given their history -- but I do have a little.  The recently created IEBlog shows that the IE team is interested in hearing what people want.  And I believe the fact that the team has shown so much activity lately is (at least partly) a sign of Microsoft's belief that Mozilla has the potential to become a serious threat.  The IE team has written that they want to make Internet Explorer "the best way for browsing the web."  Here's hoping they're serious.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Google
o Mozilla announced that they are working on implementing XForms
o XForms
o TechWeb News, InternetWeek
o Google [2]
o IEBlog
o Also by fd


Display: Sort:
Mozilla To Add Support For XForms, World Yawns | 137 comments (119 topical, 18 editorial, 1 hidden)
flash.. (3.00 / 9) (#2)
by Suppafly on Wed Aug 11, 2004 at 06:24:38 PM EST

Flash requires plugins for IE and that unfortunately hasn't made people avoid using it.
---
Playstation Sucks.
well, duh (none / 0) (#21)
by cbraga on Thu Aug 12, 2004 at 08:53:39 AM EST

flash comes installed with windows and IE.

ESC[78;89;13p ESC[110;121;13p
[ Parent ]
the version that comes with windows.. (none / 0) (#32)
by Suppafly on Thu Aug 12, 2004 at 12:22:53 PM EST

is too old to view most websites so you have to upgrade anyway.
---
Playstation Sucks.
[ Parent ]
Re: the version that comes with windows.. (none / 1) (#37)
by FattMattP on Thu Aug 12, 2004 at 01:24:25 PM EST

Yet if you need a newer version it prompts and asks if you want to upgrade. Upgrading is just a matter of clicking the OK button and waiting for a few moments. You don't even have to restart your browser. Would a plug-in for SVG or XForms be just as seamless?

[ Parent ]
XP SP 2 (none / 1) (#52)
by ender81b on Thu Aug 12, 2004 at 06:17:50 PM EST

Wait until sp2 starts getting deployed. If they were to click on "ok" without readying anything it would not install it.

[ Parent ]
Yes. (none / 0) (#126)
by John Asscroft on Tue Aug 17, 2004 at 01:41:39 PM EST

It's just a simple Javascript applet. Do a View Source on any page that displays such a request and you, too, can see how to make it prompt for a plugin.
We must destroy freedom to save it from the terrorists who want to destroy freedom. Else the terrorists have won.
[ Parent ]
Intranet (2.75 / 8) (#7)
by Doktor on Wed Aug 11, 2004 at 08:40:28 PM EST

Nuff said.

Your assumptions are off (none / 0) (#10)
by driptray on Wed Aug 11, 2004 at 09:32:31 PM EST

With IE market-share slowly eroding to Firefox and Mozilla, standards-compliance could go a long way towards keeping developers and users on Microsoft's platform.

It's not clear that IE's market share is eroding, slowly or otherwise. I'd say that in the absence of widespread Mozilla/Firefox pre-installs on new computers there's little chance that IE's market share will drop significantly in the foreseeable future.

So why would MS want to support XForms? It's a lot of effort for not much reward (some goodwill, as you say). In general, open standards level the playing field, and that's not something a dominant player like MS is interested in.
--
We brought the disasters. The alcohol. We committed the murders. - Paul Keating

Yes. (3.00 / 2) (#12)
by bakuretsu on Wed Aug 11, 2004 at 10:14:08 PM EST

Novice users commonly refer to Internet Explorer as "the internet" because they really don't even know that there is a difference.

Way to name the view for the window.

-- Airborne
    aka Bakuretsu
    The Bailiwick -- DESIGNHUB 2004
[ Parent ]

Only novices don't have a choice. (none / 0) (#13)
by Herding Cats on Wed Aug 11, 2004 at 10:24:34 PM EST

They end up stuck using IE because, as you said, it's named My Internet on the desktop. Nasty ogres, those MS coders are...

But by the time you have even 6 months experience of surfing, you know there are other browsers out there. Then, it becomes a matter of a) someone being a perpetual novice and not caring about differences in programs because they only look up recipes (housewife syndrome), b) looking at other programs, but deciding that IE is best for them (my roommate does this, which is why I hate using roommie's laptop), or c) going through the list of what's available and deciding from there.

Myself? I'm a Netscape user, especially since 7.0 came out. Tabbed windows are the greatest benefit to my research since I dropped my free ISP years and years ago.

I hate facts. I always say the chief end of man is to form general propositions -- adding that no general proposition is worth a damn.

---Oliver Wendell Holmes, Jr.
[ Parent ]

netscape!? (3.00 / 5) (#14)
by reklaw on Wed Aug 11, 2004 at 10:37:30 PM EST

Whatever does Netscape have that Mozilla doesn't (that anyone actually wants)? "Free AOL" icons?
-
[ Parent ]
Whoa, dude (3.00 / 2) (#17)
by Verbophobe on Wed Aug 11, 2004 at 11:52:25 PM EST

6 months of experience for someone who is technically inclined, perhaps.  The other 90% could go for aeons without even knowing that their browser is called Internet Explorer.

Proud member of the Canadian Broadcorping Castration
[ Parent ]
i think you are too quick to judge (none / 1) (#18)
by the77x42 on Thu Aug 12, 2004 at 02:17:00 AM EST

people know there's a difference between word and notepad. mac users know there's a difference between safari and IE. i think most internet users (novice or not) know about netscape.

the reasons people use IE:

  • it's fast (booting up)
  • it takes too much effort to install something else for little or no gain
Firefox is good, I loved tabbed browsing, but it doesn't start up as fast as IE. Netscape is a pig. Really, I mean really IE isn't THAT bad. Sure the standards compliance is a little lacking, and no download manager or tabbed browsing makes it a little less 'fancy' than other browsers, but it is pretty stable and fast. Add the google toolbar for popup blocking and it does a good job. I think the rest is just being elitest.

Having said that, IE for mac is scores ahead of IE for windows. It has a download manager, auction tracker, appearance editor, all those bells and whistles.

For average users though, what's not to like about IE?


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

[ Parent ]

Startup speed (2.50 / 2) (#19)
by CaptainZapp on Thu Aug 12, 2004 at 04:42:31 AM EST

Firefox is good, I loved tabbed browsing, but it doesn't start up as fast as IE.

Sure IE starts up really fast. No wonder when it's initially loaded upon system boot.

From a systems efficiency perspective it isn't really a good idea to have a huge blob of software in memory which you don't really need.

In addition: Even though I can't really avoid having IE running when I boot Windows I can avoid running the browser and thus avoid a great deal of huge security headaches.

[ Parent ]

Quick Launch (none / 1) (#107)
by ensignyu on Sun Aug 15, 2004 at 12:15:52 AM EST

Mozilla has a preloading thingy called Quick Launch for people who do want that. At least Mozilla's loading can be disabled if you wanted to use a competing product.

[ Parent ]
What's the logic in that? (none / 0) (#136)
by Pkchukiss on Mon Sep 13, 2004 at 06:53:50 AM EST

Mozilla is the competing product!

________________
Ignorant no more
My blog
[ Parent ]
Bullshit (3.00 / 2) (#29)
by duffbeer703 on Thu Aug 12, 2004 at 11:33:10 AM EST

The speed issue is completely irrevelant. You're just a freak about performance.

The average joe has dozens of spyware apps installed on their computer. They use browser buddies and think that Gator and Weatherbug are great programs. They are ignorant of performance.

Microsoft has succeeded is establishing for most users that Internet Explorer == Internet.

Microsoft's ultimate goal with regard to browser dominance was to be THE player for web applications, particularly in the corporate environment.

The security hoops that the IE team must leap through has made that dominance pretty irrelevant. All of the client-side technologies that MS wanted to push on the browser have proven to be security nightmares.


[ Parent ]

I think you overestimate the newbie (none / 1) (#48)
by skim123 on Thu Aug 12, 2004 at 05:48:54 PM EST

A friend of mine recently signed up with AOL. His comment to me: "Hey, did you hear? I got the Internet installed on my computer." I had always wondered what the fine folks at AOL were sending out on those CDs. I guess the entire Internet.

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


[ Parent ]
well (1.16 / 6) (#50)
by the77x42 on Thu Aug 12, 2004 at 05:56:53 PM EST

If he's on AOL then I assume he's american. nuff said.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

[ Parent ]
web standards (none / 1) (#11)
by the77x42 on Wed Aug 11, 2004 at 09:54:55 PM EST

I am running on two assumptions here:
  1. Microsoft is never going to change and IE will forever have its quirks
  2. Developers actually want to be standards compliant as it saves a lot of headache for updating obscure code, or code that won't work with the next release of browser x
That being said, I think Dreamweaver is the biggest standards culprit of them all. Design a page that looks perfect in Firefox and IE and in DreamWeaver it will look like SHIT. Tables are all over the place and css placement tags get ignored or placed way out of proporation just to name a few.

Here's a novel idea, in Dreamweaver, have the option to view what the page will look like on Opera, Safari, IE, Netscape, Mozilla, Knoqueror, etc. right in the application without having to install every damn one (especially hard if you don't have Linux or a Mac).

As it stands now, I'm only using Dreamweaver for PHP syntax colouring and the odd template design. I can use notepad or free software for basically the same purpose. For $400USD, I think they could at least attempt to show me the goods, rather than tell me Netscape 6 doesn't support the xml:lang tag in the header. Gimme a break.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

Better idea (3.00 / 6) (#54)
by mcgrew on Thu Aug 12, 2004 at 06:48:12 PM EST

Don't use Dreamweaver.

"The entire neocon movement is dedicated to revoking mcgrew's posting priviliges. This is why we went to war with Iraq." -LilDebbie
[ Parent ]

Right on, brother! (none / 0) (#71)
by am3nhot3p on Fri Aug 13, 2004 at 08:51:44 AM EST

Dreamweaver has never produced a good page in its sordid life.

Dreamweaver-produced code is overweight and slow to transfer and display, a nightmare to edit, and generally useless in every respect.

[ Parent ]

it is getting better... (none / 0) (#85)
by the77x42 on Fri Aug 13, 2004 at 05:47:55 PM EST

mx solved many workflow problems with previous versions, but there is much room for improvement... still, i've found it to be the best template editor out there.

oh, i don't use dreamweaver to write my database code for me... that'd be stupid... i'm talking strictly design asthetic issues here.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

[ Parent ]

Dreamweaver... (none / 0) (#106)
by ubernostrum on Sat Aug 14, 2004 at 11:55:43 PM EST

...is actually getting a lot better. You mostly have the Web Standards Project's Dreamweaver Task Force to thank for that, and they're still campaigning for it.

That said, there are articles out there on how to get Dreamweaver to produce better code. Now if only people would read up...




--
You cooin' with my bird?
[ Parent ]
R.E. Plugin installation: (2.33 / 3) (#16)
by topynate on Wed Aug 11, 2004 at 11:10:15 PM EST

Flash. Java. Shockwave.


"...identifying authors with their works is a feckless game. Simply to go by their books, Agatha Christie is a mass murderess, while William Buckley is a practicing Christian." --Gore Vidal
Wack, rather than good. (1.72 / 11) (#20)
by TheOnlyCoolTim on Thu Aug 12, 2004 at 06:25:01 AM EST

  1. It is XML, which I am wholeheartedly against.
  2. Worse, it doesn't really remove any work. Today you can check the user's input with JavaScript before submission, if you want, and then you must check it server-side after submission. All this is is another option instead of JavaScript, since it does nothing to prevent someone from typing the URL http://www.example.com/site.php?somethingimportant=badshit and fucking everything up.
It also looks to me like writing forms in this thing would be a mild pain in the ass.

Tim
"We are trapped in the belly of this horrible machine, and the machine is bleeding to death."

Just curious (3.00 / 2) (#30)
by rodoke3 on Thu Aug 12, 2004 at 11:50:04 AM EST

  1. As I only know the bare essentials of it, what is there to hate about XML?  I think it would be nice to have that capability on forms without enabling the "Pandora's box" of Javascript.
  2. To tell you the truth, I only turn on JavaScript unless I absloutely need to and I'm sure others feel the same.  If not for security reasons, to just avoid the more annoying aspects of over-engineered sites.  

I take umbrage with such statments and am induced to pull out archaic and over pompous words to refute such insipid vitriol. -- kerinsky


[ Parent ]
Why? (none / 1) (#31)
by revscat on Thu Aug 12, 2004 at 12:10:05 PM EST

It is XML, which I am wholeheartedly against.

Why wholeheartedly? XML is a markup language, and markup languages have their place in most -- if not all -- software projects. Eventually non-Turning complete components are necessary, whether HTML-like presentation languages or configuration files or whatever, and XML fills that need quite nicely. Can it be overused and has it been overhyped? Yes to both. But it's far from useless.

Worse, it doesn't really remove any work. Today you can check the user's input with JavaScript before submission, if you want, and then you must check it server-side after submission.

First off, you will always want to check data coming in over an HTTP socket on both the client and the server side. Always. Checking it on the client side is a first-pass, and saves you some processor clicks once it gets to the server.

Second, data validation is only one part in the whole picture of XForms. Rather, the purpose is to provide for data entry flow, form pre-population based upon optional external entities (static XML files, SOAP calls, etc.), native support for internationalized forms, and other common requirements that have up until now required each development effort to implement their own solution.

XForms addresses many shortcomings in the forms model currently familiar to those who deal with HTML. There will be a learning curve, but not a steep one, and I believe the benefits are worth it.

I at least hope that we can agree that anything that reduces the amount of JavaScript in a page is a good thing.

- Rev.
Libertarianism is like communism: both look great on paper.
[ Parent ]

XML (none / 1) (#35)
by TheOnlyCoolTim on Thu Aug 12, 2004 at 01:08:23 PM EST

In general when I look at XML files at best they have a bit of extraneous crap and at worse they are just flat-out retarded, with crap like:

<parameter>
<name>
<string>
Thename
</string>
</name>
<value>
<integer>
1
</integer>
</value>
</parameter>

That is so much simpler and better than writing "Thename=1". Rarely have I seen XML files used to mark things up in a useful way.

Tim
"We are trapped in the belly of this horrible machine, and the machine is bleeding to death."
[ Parent ]

well (3.00 / 2) (#41)
by reklaw on Thu Aug 12, 2004 at 03:34:12 PM EST

Even in XML as stupid as that, at least it's a standard. The main idea of XML is to have a format that's interoperable (hence the extreme verbosity). "Thename=1" might be nice, but what when you have one format that puts "Thename:1", one format that with "STR Thename INT 1", and so forth. You can see how XML would make it easier if you ever wanted to use those files together.

Also, something more like this XML would be way better:

<parameter name="thename">
<value type="integer">1</value>
</parameter>

Only someone who only uses XML for buzzword-value would use it in the way you describe.
-
[ Parent ]

Well (none / 0) (#44)
by TheOnlyCoolTim on Thu Aug 12, 2004 at 04:00:29 PM EST

I exagerrated a bit but thats how I had to do the config files for Tomcat...

Tim
"We are trapped in the belly of this horrible machine, and the machine is bleeding to death."
[ Parent ]

heh (none / 1) (#47)
by reklaw on Thu Aug 12, 2004 at 05:15:52 PM EST

With anything Java-related, buzzword implementations come as standard.
-
[ Parent ]
what's wrong with s-exps? (none / 0) (#58)
by Delirium on Thu Aug 12, 2004 at 09:07:44 PM EST

LISP's had s-expressions since the 1950s, which are basically isomorphic to HTML. And they're less verbose, since they don't restate the tag name again, which is unnecessary for a computer, which doesn't need it, and also for a programmer, who can take care of nesting depth with indentation, like a sane person.

For example, XML:

<blah>
 <foo>
  2
  <sux>
   lolz
  </sux>
 </foo>
</blah>

versus s-exps:

(blah (foo 2 (sux lolz)))

[or indented however you'd like]

[ Parent ]

well yeah (none / 0) (#60)
by reklaw on Thu Aug 12, 2004 at 10:16:49 PM EST

XML is just a standard, not necessarily the very best standard that could exist. Am I correct in thinking that the original XML example would map to s-exps like this?:

(parameter
    (name
        (string
            Thename
        )
    )
    (value
        (integer
            1
            )
    )
)

If so, the only real advantage I see with (non-pointlessly-over-complicated) XML is readability -- without indentation, that s-exp is very hard to read, unless you program in C every day or something. The original is a bit easier, and my better XML example is much easier. There's also the factor that XML wasn't selected entirely on merit: a lot of people already knew a bit of HTML, and XML was able to take advantage of that to build a better universal data-interchange format.
-
[ Parent ]

actually, to be fair (none / 0) (#61)
by reklaw on Thu Aug 12, 2004 at 10:22:50 PM EST

This way of indenting it...

(parameter
(name (string Thename) )
(value (integer 1) )
)

...is quite readable (not as C-curly-braces-nightmare-ish), and roughly equivalent to the best-case in XML. I don't think s-exps are a format that could be used for anything very complex, though. Explicit closing in XML might be a waste of bandwidth, but it improves readability for humans -- can you imagine the havoc that'd be caused if you misplaced a bracket somewhere in that?
-
[ Parent ]

Missing brackets (none / 0) (#84)
by Eccles on Fri Aug 13, 2004 at 05:38:44 PM EST

I wonder why I've never seen an editor that color-matched matching parentheses, curly braces, etc. Admittedly in C/C++, macros can make it a challenge, but in lisp, etc. it seems like a natural.

[ Parent ]
bracket-matching (none / 0) (#94)
by Delirium on Sat Aug 14, 2004 at 01:23:55 AM EST

I haven't seen color-matching, but the emacs text editor briefly highlights the correponding opening bracket (or parenthesis) when you type the closing one, so you can see if you're at the nesting depth you think you're at.

[ Parent ]
S-Expressions (none / 0) (#69)
by SigmaEpsilonChi on Fri Aug 13, 2004 at 05:44:41 AM EST

No one indents sexps like that. Presumably if you were going to write sexps instead of XML, you would use a text editor capable of parenthesis matching and idiomatic lisp indentation. That may or may not appear to be readable, but that can have as much to do with what one is already used to as anything else.

If you can tolerate obnoxious wiki babble you might find this interesting.

[ Parent ]
I don't see how xml has helped (none / 1) (#73)
by speek on Fri Aug 13, 2004 at 09:52:27 AM EST

thename=1 is entirely better than the xml. If someone writes it Thename:1, it would take me about 5 minutes to implement a new reader that extracted the same data from it. Contrast that with xml where there are a million ways one can arrange 'thename' and '1' into values and attributes and tags, as you've just demonstrated, and the same problem arises. XML as a standard doesn't mean your particular schema is standard. And if you end up using a standard schema, guess what, your XML is going to look more like:

<stdscheme:parameter namespace="http://scheme.standard.server.com"> <stdscheme:parametername namespace="http://scheme.standard.server.com" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">thename</stdscheme:parametername> <stdscheme:value namespace="http://scheme.standard.server.com" use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" type="impl:integer">1</stdscheme:value> </stdscheme:parameter>

So, now you have a "standard". Of course, only a machine can write and read it now, and for anyone else to read it they have to include about 2MB of jar files, but hey, it's standard!

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

That's very true (none / 1) (#114)
by revscat on Mon Aug 16, 2004 at 10:25:30 AM EST

thename=1 is entirely better than the xml.

And if your requirements are a simple list of name-value pairs, then you can certainly (and by all means should) make due with just that structure. Why introduce the overhead of DOM/SAX/etc. into the mix if you don't need it?

But that isn't always an appropriate solution. Frequently, data needs to be stored in a more structured fashion that name-value pairs just cannot handle. What if your value is a list of items, and each one of the entries in that list can themselves be a list? You could store it in a DB, but that is frequently overkill for system configuration.

Using the right tool for the right problem is always a good thing. Your example certainly proves that.

- Rev.
Libertarianism is like communism: both look great on paper.
[ Parent ]

alternatives abound (none / 0) (#119)
by speek on Mon Aug 16, 2004 at 06:59:20 PM EST

Off the top of my head:

thename=1
name2={
prop1=value
prop2=value
prop3={
prop4=value
prop5=value
}
}
name3=value
etc.

Proper indententation would make it more readable, but K5 rejects <pre> tags.

XML remains very useful for document type data, where large blocks of text are "marked up" with relatively infrequent tags and where values need to be mixed content. The vast majority of configuration data is not like this and benefits from a simpler, less verbose approach.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Congratulations! (none / 1) (#127)
by revscat on Tue Aug 17, 2004 at 01:46:15 PM EST

You just reinvented XML, only without attributes! You're markup is different and more compact, but structurally your example is identical, and would be stored in memory in a similar fashion. But the philosophical differences between this:

thename=1
name2={
prop1=value
prop2=value
}

and this:

<thename value="1" />
<name2>
<prop1>value</prop1>
<prop2>value</prop2>
</name2>

is exactly nothing. IMO, XML is still better, though, because of the simple reason that you have a clear end of field marker for the value section: the closing tag. Yours is dependant upon the EOL character, and that won't work for data sections that themselves have multiple lines of data.

"Then just use name/value pairs for simple properties files!" To which I say: I agree. Right tool, right job, and all that. But XML is a universal solution for storing hierarchical data in a human readable form and attempts to avoid special cases, and does quite a good job at it.

- Rev.
Libertarianism is like communism: both look great on paper.
[ Parent ]

that was the point (none / 0) (#129)
by speek on Tue Aug 17, 2004 at 03:10:06 PM EST

As a universal standard, XML is vastly better. But, 99% of the time, I don't need a universal standard. All I need is an easily describable, learnable, readable syntax. I'm not looking for philosophical differences (except perhaps to say that having "standards" is not always such a great thing). I'm looking at practical differences here.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

What the hell? (none / 1) (#33)
by Run4YourLives on Thu Aug 12, 2004 at 12:33:44 PM EST

First, what's wrong with XML? It's perfectly good when used in the correct context. XHTML is a form of  XML and the benefits of using it over HTML are astounding.

Second, what kind of bloated apps are you writing that validate user input twice? If you're validating on the server side, why write all that javascript, it's fundamentally useless.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]

App (none / 0) (#34)
by TheOnlyCoolTim on Thu Aug 12, 2004 at 12:50:19 PM EST

The app I am currently writing only validates on the server side. I just mentioned the JavaScript because it is the way I have seen client side validation done. I can imagine situations in which it would make sense, e.g. validating is expensive and the server is heavily loaded - it would make it easier since it would only validate good data or reject people trying to screw with you.

Tim
"We are trapped in the belly of this horrible machine, and the machine is bleeding to death."
[ Parent ]

um.. (none / 1) (#76)
by Run4YourLives on Fri Aug 13, 2004 at 12:45:08 PM EST

I can imagine situations in which it would make sense, e.g. validating is expensive and the server is heavily loaded

Yikes! Word of advice: Don't ever, ever, ever remove validation from the server side. Period. No Exceptions.

If the server is too heavily loaded to check the data, you need another server.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]

re: What the hell? (none / 0) (#65)
by vdvo on Fri Aug 13, 2004 at 12:29:34 AM EST

Second, what kind of bloated apps are you writing that validate user input twice? If you're validating on the server side, why write all that javascript, it's fundamentally useless.

User-friendly apps. And no, actually it's not completely useless.

You absolutely need to validate input on the server side, because you have to assume someone will feed you invalid data, whether out of malice or incompetence. And, if you want your web application to be user friendly, you will usually do at least some basic validation already on the client, too, because users will hate you if you just let them enter anything and then feed them an error message after they submit the form and wait for the response.



[ Parent ]
I have a tough time buying that. (none / 1) (#75)
by Run4YourLives on Fri Aug 13, 2004 at 12:42:28 PM EST

because users will hate you if you just let them enter anything and then feed them an error message after they submit the form and wait for the response.

Perhaps the response is so long because of all that extra validation?

I'm a little biased, but I don't see the need to ever use javascript for validation.

Users can turn it off, certain pop-up blockers will block alert boxes, and your validation code is visible to the world, from which a devious entity may be able to gain some usful information. Add to all that the increased development time. All that just so a user doesn't have to wait an extra second?

I suppose that JS doesn't work in all browsers either... how user friendly is that?

In any user study I've done, I've never heard a user complain about where the error messages are shown, provided they give enough information to correct all the errors in one shot and continue on.

I'm actually very interested in seeing an example of one of your applications.

You may have a case here, but I just don't see it.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]

Um. (none / 0) (#104)
by ubernostrum on Sat Aug 14, 2004 at 04:49:14 PM EST

XHTML is a form of XML and the benefits of using it over HTML are astounding.

Um. No, not really. There are only three major advertised advantages of XHTML over SGML-based HTML:

  1. Validity and well-formedness is enforced.
  2. Content from other XML languages can be embedded via namespaces.
  3. Content can be transformed into other XML languages via XSLT.

(1) really only works as advertised in Mozilla and only when the content is served as application/xhtml+xml.

(2) is interesting, but there really aren't any other XML languages which get used with any kind of regularity; the canonical example is MathML, and that's literally only used by a narrow academic population. And nobody does SVG. If you have another XML language which you must embed and a user-agent which will support it, then and only then will this come in handy.

And (3) is irrelevant because SGML tools can perform the same kinds of transformations on already-existing HTML.

Now add to this the fact that switching to true XHTML involves a different DOM and different CSS behaviors than SGML-based HTML, the fact that XHTML served as text/html is interpreted as "tag soup" by all current browsers, the fact that XHTML served to a user-agent which was truly HTML4 compliant would show numerous unexpected rendering anomalies (hello, SHORTTAG minimization), the fact that... well, I think you get the point.

XHTML should be used only after careful consideration of the advantages and disadvantages; for many common applications, HTML 4.01 is still perfectly fine, and to be recommended.




--
You cooin' with my bird?
[ Parent ]
You forgot the biggest advantage. (none / 0) (#118)
by Run4YourLives on Mon Aug 16, 2004 at 12:48:07 PM EST

Seperating Content from Presentation.

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]
Um. (none / 0) (#121)
by ubernostrum on Mon Aug 16, 2004 at 09:14:07 PM EST

How does a language which is element-for-element identical to HTML 4.01 (namely, XHTML 1.0) somehow magically enforce a style/content separation which HTML 4.01 does not?

You seem to be thinking of CSS, not XML/XHTML...




--
You cooin' with my bird?
[ Parent ]
oops... (none / 0) (#123)
by Run4YourLives on Tue Aug 17, 2004 at 12:22:48 AM EST

Yeah, I guess most of the work would go to CSS... when you use the two (XHTML and CSS) together a lot, it's hard to image one without the other. :-)

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]
Meh. (none / 0) (#105)
by ubernostrum on Sat Aug 14, 2004 at 05:26:24 PM EST

It is XML, which I am wholeheartedly against.

XML has good applications and bad applications. If people would actually use it for interoperable data formats, it'd have a chance of doing some real good; being able to say "here's my data, here's But as a replacement for HTML it can blow chunks; you have to wade through about 5.3x105 pages of specs before you can begin to properly use XHTML+XForms, for example.




--
You cooin' with my bird?
[ Parent ]
I think that it makes sense (none / 0) (#128)
by gregholmes on Tue Aug 17, 2004 at 02:34:52 PM EST

Worse, it doesn't really remove any work. Today you can check the user's input with JavaScript before submission, if you want, and then you must check it server-side after submission. All this is is another option instead of JavaScript, since it does nothing to prevent someone from typing the URL http://www.example.com/site.php?somethingimportant=badshit and fucking everything up.

Well, of course you'll still have to validate server-side. Nothing will change that.

What I like about the idea of XForms is that you get to describe the actual behavior you want, and let the browser handle it, instead of having to reinvent the wheel all the time. There are some very common behaviors that you want in forms (like, say, validating input to be a date) - not for security, obviously, but to get the normal user to fill out the form completely and correctly.

The funny thing is that ASP.net, of all things, lets you use a similar concept in your markup; it just does it all server side and spits out auto-generated Javascript (if you use client side validation).



[ Parent ]
Who cares (none / 1) (#25)
by exotron on Thu Aug 12, 2004 at 10:13:35 AM EST

I for one am glad IE isn't supporting XForms. It's a useless and bloated extension which does nothing to eliminate the (non-existant) problems with current forms. Who gives a shit.

Link: (none / 1) (#26)
by exotron on Thu Aug 12, 2004 at 10:15:34 AM EST

http://article.gmane.org/gmane.comp.mozilla.devel.layout/1347

[ Parent ]
I voted +1 sp for the article (none / 0) (#39)
by phred on Thu Aug 12, 2004 at 01:51:47 PM EST

it was good, technically interesting, and if it'll go to section, it'll include the link in the parent post.

[ Parent ]
Browser wars are irrelevant (none / 1) (#28)
by duffbeer703 on Thu Aug 12, 2004 at 11:21:35 AM EST

Browsing the web is Microsoft's domain now and will be for the forseeable future.

The real goal that Mozilla should be shooting for is to be a universal client platform. With the XML based technologies like XUL and XForms, a stripped down Mozilla can become the front end of your new payroll app or auction management software.

Look at how extensions for apps like Eclipse and Firefox have proliferated... Users and other vendors are coming up with all sorts of crazy extensions to their application platforms that vendors would never have been able to ship.

The applications are what matter.... and web browsers aren't applications anymore.

The other question (none / 0) (#38)
by pauldamer on Thu Aug 12, 2004 at 01:32:42 PM EST

Why do people stay with IE.

Currently for two main reasons:

  1. They don't know of any alternatives
  2. Their favorite websites are dependant on IE
If IE becames standards compliant it wouldn't change the first reason at all. But all those people who would change if only their sites worked with other browsers would immediately switch. The non-compliance is what keeps otherwise educated users from changing to a non-MS browser.

No need. (1.90 / 10) (#42)
by fyngyrz on Thu Aug 12, 2004 at 03:35:49 PM EST

Argh. There is no need for anything beyond standard HTML and standard FORMS in a browser.

There is no need for client-side document processing (I'm not talking about video or sound here, I'm talking about still images, basic GIF animation and text.)

Web site authors: JAVA, plugins, activex, flash CSS - what this stuff does is create a class of people who can't see your page or are inconvenienced by your page, separate from those who can see your page. I am repelled by that. Some people are more than repelled, they are shut out. That sucks.

Use HTML and use FORMS and server side processing; then every browser on the planet can use your site - even text browsers - you can "check input ranges" and ensure that required fields are filled just fine using the currently available tools. Make note on the form of what you need, and if you don't get it, re-invoke with little remarks indicating the problem fields. It's trivial to do. Likewise, you can create beautiful, creative, dynamic, window-size-flexible and highly effective web pages using straight HTML that comes out of a CGI application. I do it all the time. Well, maybe not all that beautiful - but that's my limitation, not a limitation of the technology. :)

You even gain the choice of what language you prefer on the server side instead of being shoehorned into the latest fad / script kiddie / gee-wow-gosh thing of the hour. Like Python? Use it. Like Perl? Use it. C? Use it. Wrote your own language? Use it. Don't worry about what browser the user has - instead, make sure it doesn't matter what browser the user has. For instance, on the server side, I use Python and have a super easy to use stylesheet based system that builds dynamic content without requiring features from the web browser other than HTML and FORMS. Works great, I like it, my productivity is high.

Another thing. HTML and FORMS are very easily learned. I believe that's one of the key issues that fueled the original creative burst of WWW activity (before commercial interests and the high cost of maintaining websites shut down a large chunk of the non-profit ones.) The more you load up with the technology of the week, "standard" or not, the more you shut out the average person. HTML is one thing. CSS, XML and JAVA (just a few of many equally culpable examples) are entirely another.

I'm not a Luddite. I know it sounds like I am - but really, I'm not. I write code in lots of languages, I'm competant in lots of WWW technologies. I own bleeding edge hardware (not just computer hardware - bleeding edge audio and automobile hardware as well) and I've been an early adopter of many things - mindiscs, cds, dvds, laserdiscs, the Amiga, SACD, Linux, stereo LCD shutter glasses, Gamecube, PS1/2, XBox, etc. Sometimes the technologies worked out, sometimes not. But there is a difference here. What motivates me to write the above commentary is what I consider to be the sad state of interoperability of our supposedly "available to everyone" WWW - I can hardly visit a web site without some dialog telling me I need to download something (which probably won't work anyway, as I don't use IE) and CSS seems to be primarily used to prevent me from using my desktop space to expand or shrink the document to a more usable configuration. Somewhere, web site authors seem to have almost completely lost sight of the (I thought obvious) clue that when the user changes the size of the browser, they are almost certainly hoping that the web page will flex with it. Otherwise, why do it instead of minimize it or close it entirely? Duh!

I know I'm a feeble voice in the wind, but when I saw this article making hay over YAPT (Yet Another Pointless Twist), I just had to write about it. Thanks for reading.


Blog, Photos.

CSS allows HTML to be more accessible (3.00 / 2) (#45)
by MrLarch on Thu Aug 12, 2004 at 04:09:32 PM EST

by taking the presentational garbage out of it. CSS is exceptionally easy. Even IE's CSS 1 support is enough to make the whole document (structure and presentation) simpler. Don't confuse it with the likes of shitty plugins, worse standard DOM support, and half-assed frameworks.

You have a point, but the reason is accessibility. Simpler code, more user control, and less of "let's trade the ability for 10% of our users to view the information for these little sparkly things" is what makes the web good.

[ Parent ]

Same in simple words (none / 1) (#64)
by anothertom on Thu Aug 12, 2004 at 11:37:08 PM EST

CSS allows to separate content and layout - to let the user agent (i.e. browser) decide how to render it - which is exactly the opposite of what plugins are doing.

[ Parent ]
valid points (none / 1) (#51)
by the77x42 on Thu Aug 12, 2004 at 06:05:16 PM EST

my initial html coding experience came from html-based chatrooms where you need to change colour with the font tag and bold with the b tag, etc.

Ultimately, anyone should be able to design a decent webpage. css makes this a lot easier. activex, flash, etc. are all things that are used when people don't have good design sense or just don't care they are shutting out a world of people.

xhtml is just starting out, i'm not too sure of the benefits yet, but who knows; there are only minor changes that need to be made and it at least standardizes html tag nesting, etc. it's your basic html just in a better-specified form.

But for all the flash and crap that people spill out, and of all the for and against standards arguments, people should focus on the most important standards of all: accessibility standards.

You want to build something that shows off your cheap internet trick of the day skillz, go ahead, just build a parallel website that the rest of us can access. keep it simple.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

[ Parent ]

You're completely missing the point. (2.71 / 7) (#57)
by it certainly is on Thu Aug 12, 2004 at 08:29:29 PM EST

I use the Internet to look for stuff, too. Everyone does that. It would be great if all information on the Internet was accurate, plain text in static retrieval systems. But we're not talking about the internet, we're talking about BUSINESS APPS.

Have you ever worked in a company where you get a computer at your desk? That computer is for doing work. You're bound to have used some kind of INTERNAL APPLICATION, be it a case tracking tool, a reporting tool, accounting software, or whatever. Usually, it's a bunch of FORMS on top of a database.

Do you remember Netscape? It was created because of the potential of FORMS. No more Visual Basic apps. No more stranglehold on the desktop environment. No matter what OS you ran, you could buy Netscape and Netscape server and build easy GUIs and access your intranet applications, over the network! It's the same for Java / Enterprise Java / Super Enterprise Java. Sun want you to make your business apps in a standard language that runs in every web browser, no matter what OS.

What are these new forms for? Stupid fucking question. Business apps! You need high-speed interactivity! Plain HTML back-and-forth with the CGI server is not good enough! Frames are not good enough! A robust, reliable, business application markup language is what is needed. And that's what these new forms are all about. The Internet need not apply.

kur0shin.org -- it certainly is

Godwin's law [...] is impossible to violate except with an infinitely long thread that doesn't mention nazis.
[ Parent ]

No. I didn't miss the point. I just sharpened it. (2.00 / 3) (#66)
by fyngyrz on Fri Aug 13, 2004 at 04:02:57 AM EST

I write business apps, database applications and all - for the web. I don't need anything more than HTML and FORMS. As for your comments, if you're not interacting via the web, you don't need a browser - hence, no need to be mucking about with browsing technologies. Write a database client in whatever you want and don't be foisting off the technology du jour on the Internet community, that's all.


Blog, Photos.
[ Parent ]

You need to think from a business POV (2.75 / 4) (#67)
by djkitsch on Fri Aug 13, 2004 at 04:42:40 AM EST

"if you're not interacting via the web, you don't need a browser"

Of course you don't NEED a browser. And when I'm going on vacation, I don't NEED to fly - i could swim, take a hot air balloon, etc.

An example: say you're a Fortune 500 company and you've got 2000 call-center staff. You want to roll out new software to all of them. Do you:

a) Write bespoke software in the language of your preference, debug, stabilize, and then spend resources managing mass rollout of new versions, DLLs etc etc (yes, I know there are ways, but they are not as simple as this:)

b) Write a web app in any one of half a dozen mature scripting languages, debug in half the time and then roll out to everyone simultaneously with easy updates and any one of half a dozen decent bits of client software that we know just works (I'm referring to Mozilla, of course ;-) IE can go screw itself).

Do you see my point? I did exactly this for a client last month. It took us 5 weeks to develop, test and roll out the HTML/forms-based system. Thier last project, a bespoke C++ app to do much the same thing, took 6 months and was scrapped just before it was done.

The virtues of HTML for rapid application development cannot be overstated.

-------------------------
sig:- (wit >= sarcasm)
[ Parent ]

I see your point - but (3.00 / 3) (#80)
by fyngyrz on Fri Aug 13, 2004 at 02:22:15 PM EST

If you've got a 2000 person call center staff, then you can set up servers on the lan(s) that can handle everything, and there should be zero speed issues. Problem solved. This situation is not the Internet, and the only reason for speed problems in the situation you postulate here is lack of infrastructure. That's solvable without farting around with new browser technology. Get some switches, some cable, and attach to a big server farm. You should have that anyway if you've got 2000 people in a call center. Heck, I've got it and my largest operation is under two hundred people.

BTW, I do indeed think from a business perspective. I own a graphics software company, a literary agency, and several other businesses. Most of them have web presences, and all of them have lots and lots of IT one way or another. I have written custom web based software (collaborative to-do systems, specialized databases, web sites, start-to-finish e-commerce systems, upgrade analysis tools, web boards, wiki stuff, 6 very busy websites, and another 14 that aren't very busy by the standards you'd see here) as well as having been the one of the primary software and documentation (all done in HTML) authors of our grapics products. My intent is to keep technology "gosh" from overwhelming the "get stuff done" objective. I'm pretty good at it; at least, a large bunch of people have been doing very well on my particular approach to IT, web and business in general. So have I.

Our web sites never force someone to download a plugin, they never require a particular browser or limited-support technology (for instance, Mozilla works just fine, as does Firefox, my particular preference these days) and there are lots and lots of customer back and forth from online ordering to data collection and even several entertainment sites I run for fun. I have utterly failed to run into any need to client side script, to use DHTML, to require a plug-in, or to specify any browser over another browser.

I'm definitely speaking from my own experiences.

Blog, Photos.
[ Parent ]

Having written my fair share of web-hosted apps (none / 1) (#68)
by xL on Fri Aug 13, 2004 at 04:50:03 AM EST

I can only say that I have had a beef with HTML forms for about as long as they exist. Note how there haven't been any useful changes in this department since the dawn of time. Some of the issues with forms that I have to work around time and again:

  • The <textarea> form element is hard to get right. If you want to control its dimensions, the resulting layout will vary hugely from browser to browser. Control over wordwrapping and margins is minimal.
  • Comboboxes (text inputs with a dropdown menu for default values) must be done with severe DHTML trickery
  • No table widgets (for selecting one or more elements from a variable list of multi-columnar data)

It's certainly not impossible to create web-hosted application without more luxuries, but my life would be much easier if I could effortlessly use at least the complete basic collection of GUI widgets inside HTML forms that I have at my disposal when writing GUI code proper.

I took a look at XForms, though, and it strikes me as an overengineered standard going much further than what I'd desire. If W3C had just recommended a small collection of extra form-related input elements, it would have been a sure winner. As it is now, I fail to be impressed.

[ Parent ]

Points (none / 1) (#79)
by fyngyrz on Fri Aug 13, 2004 at 02:05:35 PM EST

The <textarea> form element is hard to get right. If you want to control its dimensions, the resulting layout will vary hugely from browser to browser. Control over wordwrapping and margins is minimal.

This is a reason to push for better support of standard forms in the current browsers. Not new languages and technologies. Yes?

Comboboxes (text inputs with a dropdown menu for default values) must be done with severe DHTML trickery

Just use a text box with a menu next to it. If the user enters text AND selects a menu item, tell 'em no, sorry, one or the other. I mean, sure - it'd be nice if they'd given us a more complete set of widgets, but the set we have is fully capable of almost getting info you can imagine into any CGI system, and being arrange reasonably to do so. We usually have trouble when the user isn't smart enough to read directions. I think that problem is just about unsolvable - no matter how fabulous your widget set is. We have people who enter the wrong street address, typo their email addresses, get the credit card expiration date wrong. Widgets won't save those people. A new data system - like an id number into a national database with built in checking (like credit cards) where the id contains all the info for the person. Not that I expect this to ever happen, or even think it's a good thing - but its about the only thing I can imagine that would get the info right every time (and I'm only talking about entering your address!)

No table widgets (for selecting one or more elements from a variable list of multi-columnar data)

I guess I don't understand exactly what you want here. I keep having this image of bullets next to items in a table. I must not get it. Could you describe an example?

Blog, Photos.
[ Parent ]

Table widgets (none / 0) (#82)
by xL on Fri Aug 13, 2004 at 03:50:57 PM EST

I mean any selection widget that uses tabular data in multiple columns. Like the messages in a mailbox, the files in a directory, the bugs in a bug database, etc. etc.

As stated before, there are ways to get the effects I want. Or ways to at least get the interaction I want. They're all either sub-optimal (creating a less pleasurable application to work with) or tremendous hacks of DTML/javascript.

[ Parent ]

ever thought of using check boxes? (none / 0) (#83)
by Run4YourLives on Fri Aug 13, 2004 at 04:03:17 PM EST

like gmail?

It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
[ Parent ]
Me no rikee [nt] (none / 0) (#86)
by xL on Fri Aug 13, 2004 at 07:15:01 PM EST



[ Parent ]
More specifically (none / 0) (#87)
by xL on Fri Aug 13, 2004 at 07:17:36 PM EST

It is stupid to only have an area 0.25cm in size to click on for a selection of a row. It's also annoying that you cannot drag-select checkboxes. It works, but it's lot less pleasurable to work with than a GUI mailer. With a proper table widget available in HTML forms, it would probably still be less pleasurable than having a full GUI, but much closer to home.

[ Parent ]
You mean (none / 0) (#91)
by omrib on Fri Aug 13, 2004 at 08:25:17 PM EST

it's possible to do everything with an input field - you have to type what you want to do, and that's it:

"delete all mail"
"delete message 15"
...

but we like a better interface, and the closer it is to our mental picture of what we're trying to manipulate, the better. A table is more than a bunch of rows, and an interactive form doesn't require submitting it. You can do without - command line with a smart parser will do, but most users (hmmm... those who weren't bourne again with shell) today don't think that's a usable interface.


[ Parent ]

Exactly (3.00 / 2) (#98)
by xL on Sat Aug 14, 2004 at 07:42:32 AM EST

Why even use forms? If people want to input their name, you can use CGI/PHP to offer a page with a row of alphanumeric characters represented as links. If you want to send mail to jdoe@aol.com, you click on "j", wait for the next page, then you click on "d", wait for the next page, click on "o", ... Forms are overrated really.

[ Parent ]
Are you aware of the LABEL tag? (none / 0) (#101)
by Kenoubi on Sat Aug 14, 2004 at 09:38:01 AM EST

It is stupid to only have an area 0.25cm in size to click on for a selection of a row.

http://www.w3.org/TR/html4/interact/forms.html#edef-LABEL



[ Parent ]
That's exactly what I had in mind, a list of email (none / 0) (#88)
by fyngyrz on Fri Aug 13, 2004 at 07:18:33 PM EST

So for that kind of thing, I'd just drop out a table on the right with the column(s) required, and to the left, either a radio button (if one item can be selected) or checkboxes if multiple items can be selected on a per-table line basis. Maybe even start range and end range checkboxes to select (a) group(s). You could do quite a bit with this idea, easily understood and easy to use, with the available tools without ever stepping outside of straight HTML and forms.


Blog, Photos.
[ Parent ]

I never said there is _no_ solution (none / 1) (#97)
by xL on Sat Aug 14, 2004 at 07:34:32 AM EST

But the one you give has bigger usability problems than the one offered by your standard email applications. If checkboxes next to the row were the most userfriendly, surely Evolution and Mozilla would do away with the regular table widget. The point is, having it makes it more pleasurable for the users to work with it. It's not complex to create GUI code that makes such a widget. If you want it in HTML, you either have to strip it bare like you propose (shifting the problem to the users) or whip out smartass code that uses DHTML/javascript to get equivalent functionality (and take weeks debugging it on different browsers).

I don't understand why I'm rubbing against people's hairs when I mention this. I'm saying I prefer bricks & mortar and I see people falling over me telling me I can build my houses with straw so I shouldn't complain? What if my users want a chimney? Oh, just build a bonfire outside the house, it works for gmail! :).

[ Parent ]

The WHAT WG (none / 0) (#100)
by reftel on Sat Aug 14, 2004 at 08:29:12 AM EST

I took a look at XForms, though, and it strikes me as an overengineered standard going much further than what I'd desire. If W3C had just recommended a small collection of extra form-related input elements, it would have been a sure winner. As it is now, I fail to be impressed.
In case you've missed it, this is exactly what the WHAT WG (a collaboration among most browser developers that matter (except the IE folks, of course :-( )) is doing. Take a look at the web forms 2.0 spec - they seem to already have what you want from the textarea, and the mailing list is open, so you can always post your suggestions for other controlls there.

[ Parent ]
Thanks! (nt) (none / 0) (#102)
by xL on Sat Aug 14, 2004 at 01:44:57 PM EST



[ Parent ]
Interesting tech... (none / 1) (#72)
by RadiantMatrix on Fri Aug 13, 2004 at 09:49:36 AM EST

I've been an early adopter of many things... PS1/2

I wasn't aware there was a PS 1/2! Was it smaller than the original PS? :P

"In any sufficiently large group of people, most are idiots" - Kaa's Law

[ Parent ]

I think you've got this one backwards... (3.00 / 4) (#90)
by curunir on Fri Aug 13, 2004 at 08:12:50 PM EST

Web site authors: JAVA, plugins, activex, flash CSS - what this stuff does is create a class of people who can't see your page or are inconvenienced by your page, separate from those who can see your page. I am repelled by that. Some people are more than repelled, they are shut out. That sucks.

You're right about Java, plugins, ActiveX, Flash and the like...they can create more hassle than they're worth, particularly when the site has to be available to a diverse group of client environments (read: browsers.) But you err when you include CSS and XForms in the same group.

Ask yourself, why do HTML forms work so well? It's because they were standardized and every implementation has been given time to conform to them well. CSS and XForms are very similar. They aren't implementations like ActiveX, Java, Flash, etc. They are specifications. This is an important distinction that should result in a greater ability to present an application that works in all client environments.

Use HTML and use FORMS and server side processing; then every browser on the planet can use your site - even text browsers - you can "check input ranges" and ensure that required fields are filled just fine using the currently available tools. Make note on the form of what you need, and if you don't get it, re-invoke with little remarks indicating the problem fields. It's trivial to do.

And indicates a 1999 understanding of what makes a good user interface. But UI design has advanced beyond this point. On the web, it's usually implemented with some ugly javascript hack or with some proprietary (Java, Flash, etc) plug-in. Non-browser applications use widget libraries that offer far more flexibility still. But in both cases, it improves the user experience when the proper client environment exists. The problem, as you've pointed out, is that the proper client environment doesn't exist a lot of the time.

And that's where standards come in. We need to give developers standardized ways of doing all the things they've become accustomed to doing in non-standardized ways. I imagine that xL's comment about table widgets has something to do with this. He's probably used some widget library while creating a non-webapp and seen how useful a sensible table widget can be. So, when it comes time to implement a webapp, it's annoying to have to hack something together. The fact that we know that HTML forms offer an incomplete toolset should indicate that we need something very similar to HTML forms that does offer a complete toolset. That would be where XForms comes in.

Obviously, developers won't start adopting it en masse until the majority of client environments adopt it and we can test that our applications will function well in enough environments, but that doesn't change the fact that the new standard is needed and it is a good thing one of the major browsers has stepped forward to say that they're implementing the standard.

[ Parent ]
To your salient points (none / 0) (#93)
by fyngyrz on Sat Aug 14, 2004 at 12:35:36 AM EST

Ask yourself, why do HTML forms work so well?

Ok: Self, Why? (Self answers) Because they've been in place since very, very early in the game. Basic HTML has even differed over browsers at various times (blink, level of table support, tables cell fill, table height options, marqee, etc.) Those things are to be avoided, because they weren't uniform early (or even now in some cases), and those browsers are still in use. Some people - mostly Linux people, I think - still use text browsers. It's not because HTML is standardized - because it's not, specified most certainly does != standardized - and it's not because "everyone conforms", because they most certainly don't. It's strictly because all the incompatable, browser specific gee-gosh stuff is ignored by good HTML writers.

It's because they were standardized and every implementation has been given time to conform to them well.

As I detailed above, not really. Every implementation conformed pretty much right out of the gate, discounting the really primitive days.

CSS and XForms are very similar. They aren't implementations like ActiveX, Java, Flash, etc. They are specifications. This is an important distinction that should result in a greater ability to present an application that works in all client environments.

They should, eh? Like PNG did? That was a specification. A decent one, too. Useful. Timely. Great (and immediately useful) example implementation. I would have loved to be able to use it... real alpha is a web page artist's dream. We supported it very early. So did other graphics companies. Free technology, even. Could hardly have been any better (unless it supported animation, but that's another rant.) Fell flat on its face. By which I mean, if you use it on a web page, very few people will be able to see it as you meant them to. (cue wet splattering sound)

What makes something useful is:

Usefulness. Universiality.

Not specs. Not implementations. Not free code. Not hope. Not even shiny, cute as heck little icons.

And indicates a 1999 understanding of what makes a good user interface.

Why, thank you. :) I'll bet you thought that was a putdown. I'm delighted that you intuitively understood that I have ZERO respect for the Interface Nazi Party. I'm mainly interested in functionality. Turns out, my customers are too. What can I do with this? What can they do with this? It's my little business secret. There are a whole bunch of people out there who want graphics software written in something that goes fast rather than some object-oriented pile of slow as molasses, bug-infested building blocks. Who don't care what the icons look like, or if the window is some bizzarre shape, or has "skins." What they actually want is speed, power and the ability so that they can make nice graphics. So my secret is out. I'm not worried, though. The only, and I mean only, two companies that have anything that remotely competes with our stuff are both hopelessly stuck in the "You'll need a faster processor to run that, sir or madame" loop, and I couldn't be more pleased about it. :)

But UI design has advanced beyond this point.

This is one of those perspective things. You see advances. I see major applications getting slower and slower. On the web, I see plug-in stop and go-ism. If you visit one of our web sites after you upgrade to a faster computer, or if you run our software after you upgrade to a faster computer, what you'll get is faster browsing and faster application response. It's a freaky thing, I know - when other companies keep burying themselves in the latest "use-every-cpu-cycle-tech", we keep writing tighter, more efficient code, so sometimes it is true... we're not linearly faster with your new machine - we're even faster than that. That, my 2004-interface favoring correspondent, is way cool. And even better than being cool, it sells. :)

The problem, as you've pointed out, is that the proper client environment doesn't exist a lot of the time.

Agreed. If it's not part of the base standard, I say, don't use it. Period. If you want something new, then start something new: Create a new web system that is not HTML at all. Create a new browser that can surf it that is not an HTML browser. Make sure all the stuff you want is in place, then launch the thing to the public. Don't subject the not-very-intrepid user base to creeping featureitis until nothing, anywhere you go, works precisely the same way. If you've got something useful and can get it universal, you'll be an honored person - instead of the poor sot who every user curses when their browsing experience gets shot in the arse because they don't have a plugin, an activex (I call activex "bug-ins", but that's just me), JAVA, visual freaking basic, Flash, or what-else-have-you-not.

And that's where standards come in. We need to give developers standardized ways of doing all the things they've become accustomed to doing in non-standardized ways.

Ok, fine. Just don't put it on the HTML web and continue to screw up the user's browsing experience. Start a new web or something else, and make a new app to browse it. Thanks.

I imagine that xL's comment about table widgets has something to do with this. He's probably used some widget library while creating a non-webapp and seen how useful a sensible table widget can be. So, when it comes time to implement a webapp, it's annoying to have to hack something together.

Yup. Absolutely. So it sure is a good thing that there is no reason in the world to have to hack anything to address these kind of interface issues in standard HTML/forms, or I'd have to be annoyed right along with the rest of you. But I'm not. It's not even a slight challenge. I'm not saying you can't find something that's hard to interface for business data; you probably can. But this sure isn't it. I can think of multiple solutions, and so can tons of other people, witness the very nice pure HTML email interfaces around the net.

There's another major benefit, too. If you do server-side processing, and there is a problem, you can fix it. Immediately. At 3 am with almost no setup, maybe even before another user ever sees the problem. If you do client side processing with (insert tech like Java or Flash here), and there's a problem - security, UI bug, memory leak - you generally cannot fix it, because you can't fix, or get at, the user's plugged-in-engine. When you use server side smarts and basic browser functionality (and by extension, when you write your own application code instead of using other people's building blocks), you can fix things when they break. You don't end up with an uncontrollable, sticky situation where some of your clients have broken stuff, and others have working stuff. You can fix it, you can solve their problems, and you can be the hero instead of the sod.

Anyway, I do appreciate the response, and the opportunity to speak my mind on these issues to you and the few others who have shown interest in the thread.

Blog, Photos.
[ Parent ]

Some counter points... (3.00 / 2) (#95)
by curunir on Sat Aug 14, 2004 at 06:06:48 AM EST

  • I use lynx (the main text browser of all of us crazy Linux users.) When I do so, I appreciate when a site uses CSS/P instead of tables to layout their data. Lynx struggles with traditional HTML table layout compared to a CSS/HTML page which usually degrades quite nicely. The point being that newer standards don't necessarily mean shutting out older implementations.
  • PNG is/was a great standard. It was essentially killed by a combination of poor implementations by Adobe (Photoshop which produced files that were an order of magnitude too large) and Microsoft (IE which couldn't do transparency correctly.) Developers rightly chose to continue using gifs for web graphics. This doesn't make correct implementations on the part of non-IE browsers a bad thing.
  • I'm not an interface nazi. But I do believe in empowering the developer to create a better UI for their users. Believe it or not, increased availability to new widgets from libraries results in an increase in efficiency since developers aren't forced to hack together complex widgets from their component simple widgets (as they are forced to do with HTML forms.)

    I think you fundamentally do not understand my point or the point of the author of this story. No one is advocating that web developers go out and start using XForms today. You've correctly pointed out that the client support just isn't there and if developers were do use XForms, their sites would basically be useless to a large percentage of their audience. What is being said is:
  • HTML forms are too limited and result in hacks to achieve functionality that should be built in. As a webapp developer this may not be apparent to you, but to anyone who has experience developing regular applications with a widget library (win32, GTK, Carbon, etc), it should be.
  • A w3c standard that addresses this concern is being implemented by Mozilla. This is a good thing. Microsoft should follow suit and implement XForms in IE. Then, and only then, should developers consider using XForms. One can argue the merits of XForms (I have my own issues with the spec), but that's not what you're saying.

    You seem to be falling back to the same position based on practicality. But saying that implementations aren't compatible enough or that non-standardized ways of doing things create problems isn't an argument against pushing new standards. If anything, it's an argument that we should push new standards so that it might help erode Microsoft's browser share to the point where they actually make efforts towards standards compliance. But what you seem to be saying is that HTML is good enough and we should stop pushing new standards since current standards aren't implemented correctly. This is a bleak outlook that I'm not ready to share.

    If XForms fails to be implemented by enough client platforms to become useful to developers, it won't impact you at all. You can continue to use HTML forms to your heart's content and Mozilla will continue to render them as it currently does, probably better since they fix bugs. But the possibility that it could be implemented across client platforms is enough of a reason to support Mozilla's implementation.

    [ Parent ]
  • New isn't always bad (none / 0) (#110)
    by Jim Dabell on Sun Aug 15, 2004 at 07:45:17 PM EST

    Basic HTML has even differed over browsers at various times (blink, level of table support, tables cell fill, table height options, marqee, etc.) Those things are to be avoided, because they weren't uniform early (or even now in some cases), and those browsers are still in use.

    Just because browsers don't support something in exactly the same way, it doesn't mean that it should never be used. HTML was designed to render differently, and if there are browsers that don't support a certain technology, then you just need to take care that they can still render the website usefully. CSS was designed to be compatible with older user-agents; those that don't support it will see the basic HTML underneath.

    It's not because HTML is standardized - because it's not

    Yes it is.

    If it's not part of the base standard, I say, don't use it. Period. If you want something new, then start something new: Create a new web system that is not HTML at all.

    That's a ridiculous attitude. If browser developers had that attitude, they'd throw away all their previous work when they wanted to incorporate JPEG. They'd throw away all their previous work when they wanted to implement HTTP 1.1. They'd throw away all their previous work when they wanted to implement your beloved forms. It's an irrational position to take.

    If HTML is useful, then extending it to do new stuff will almost certainly result in something that is more useful.

    You see advances. I see major applications getting slower and slower.

    But how can you argue against CSS if that is your position? The bottleneck on the web isn't the CPU, it's the network connection. CSS helps reduce the amount of data to transfer quite substantially. This kind of contradiction is what suggests you are a luddite, not the fact that you question new technologies (which is a good thing, of course).



    [ Parent ]
    css, html standardization (none / 0) (#112)
    by fyngyrz on Mon Aug 16, 2004 at 01:06:41 AM EST

    My primary objection to CSS is it seems to be used to wreck the user's ability to change the document by resizing the window, picking fonts, etc. I run into this all the time. I thought I mentioned this; I may not have, or may have been unclear about it. Sorry.

    There are 2 basic schools of thought; one is, the user should control the formatting - fonts, wrap, colors, etc. I like that - it's how I think, how I want to browse, and something I want to give to the clients of my web pages. The other is, the author should control the formatting. I don't have any sympathy with that outlook. As long as CSS is "in" all the browsers, then by all means, use it. Just don't use it to wreck the browsing experience, please.

    Now me - I don't use CSS. I generally use these and their closings as required:

    p, i, b, blockquote, table, tr, th, td, ul, ol, li, br, font, (with relative sizing) h1 and siblings, hr, html, body, title, head, and img. Now... I'm not under the impression that CSS will help me reduce my document size (essentially the cost to both user and I of bandwidth) appreciably; but I'm interested to hear why it will, if you think it will.

    HTML and standardization: No, actually, it's not standardized. It's specified, which is something else entirely, unless everyone adheres to the spec, which they certainly don't. I can show you perfectly legel tables, for one example, that will render entirely differently, visually speaking, in IE and netscape. To the point of being completely unusable. I can show you images that will render one way in one browser, and another elsewhere. Ditto GIF animations, entire slashdot pages, etc, etc.


    Blog, Photos.
    [ Parent ]

    CSS isn't what you think (none / 1) (#113)
    by Jim Dabell on Mon Aug 16, 2004 at 09:34:30 AM EST

    My primary objection to CSS is it seems to be used to wreck the user's ability to change the document by resizing the window, picking fonts, etc.

    CSS can't resize the window. It was also designed to take into account the user's wishes, so if you don't want it to change the font, it won't. And from an author's perspective, if you don't want to change the font, then don't.

    There are 2 basic schools of thought; one is, the user should control the formatting - fonts, wrap, colors, etc. I like that - it's how I think, how I want to browse, and something I want to give to the clients of my web pages. The other is, the author should control the formatting. I don't have any sympathy with that outlook.

    CSS is firmly in the first category; a stylesheet is nothing more than a set of suggestions.

    I generally use these and their closings as required:

    p, i, b, blockquote, table, tr, th, td, ul, ol, li, br, font, (with relative sizing) h1 and siblings, hr, html, body, title, head, and img.

    Hang on, if you are so set against the author supplying formatting, why are you using the <font> element type?

    Now... I'm not under the impression that CSS will help me reduce my document size (essentially the cost to both user and I of bandwidth) appreciably; but I'm interested to hear why it will, if you think it will.

    It depends on the website, but it will reduce bandwidth use for most non-trivial sites. The main benefit is that you can specify styling once per website instead of once per page, and the stylesheet is usually much more cachable than the individual pages, so in most cases, you won't actually need to transmit the styles at all.

    There have been various "makeovers" from traditional designs with <font> elements scattered everywhere to designs using CSS. I believe the ESPN redesign saved a lot of bandwidth. There have been demonstrations of what could be achieved with microsoft.com and slashdot.org as well - keeping the exact same design, but moving the styles into a stylesheet, and the bandwidth savings were very impressive there as well.

    HTML and standardization: No, actually, it's not standardized.

    The International Organization for Standardization disagrees with you. I believe ISO.

    It's specified, which is something else entirely, unless everyone adheres to the spec, which they certainly don't.

    By your logic, there's no such thing as a standard, as anybody can produce a non-conformant implementation of a standard and thus invalidate the standard. You are using the word "standard" in an inappropriate way. A standard is not dependent upon all implementations being perfect.

    I can show you perfectly legel tables, for one example, that will render entirely differently, visually speaking, in IE and netscape. To the point of being completely unusable. I can show you images that will render one way in one browser, and another elsewhere. Ditto GIF animations, entire slashdot pages, etc, etc.

    HTML isn't a language that does something, it is a language that describes something. Renderings can vary, they should vary, HTML was designed so that they would vary. HTML certainly doesn't require consistent renderings, so you can't use inconsistent renderings to try and "disprove" the standard.



    [ Parent ]
    Counterpoints (none / 0) (#115)
    by fyngyrz on Mon Aug 16, 2004 at 11:02:23 AM EST

    I didn't mean that CSS could resize the window. I meant that I keep encountering pages that will not resize and have fonts that won't resize, either (until I started running firefox, which can force fonts to resize no matter what, it seems.) When I ran into them, they were CSS. Don't know why it was happening, but it was happening. To look at this another way, you could pull the corner of your window and the text would not reflow. Is that clearer? All I can tell you was it was very annoying. Perhaps I am mistaken and the problem mechanism wasn't CSS. You can cause failure to reflow with hard-coded numeric specification of table widths, too, but mostly people don't seem to do that. They much more reasonably use percentage based tables, which is much more friendly.

    I use font +3 or etc. as a relative sizing mechanism. It is faster and smaller than multiple instances of big and small. It is friendly to the user, but allows me a means of inline size emphasis without forcing a new paragraph. I'm not against the author supplying formatting - I'm against the author locking down the font size, the page width, the page height, the page colors, text reflow, that kind of thing. Things that prevent the page from being as usuable and/or legible in an environment that is dissimilar from the authors. Sight-impaired people's computers, windows that have been resized to be narrow but tall - that kind of thing.

    I think that by your definition, my pages are all "trivial", aside from the fact that they are often large. My page formatting isn't that complex, aside from tables sometimes. So CSS might not do me or my customers a lot of good.

    I disagree about my definition of standard. A standard pipe fitting fits ALL the pipes designed to the specification. All the pipes are designed to MEET the specification, which makes them standardized. You don't need to worry about the pipe, because it is "the same." HTML markup to the specification can produce a great table, or a completely unreadable table, and I utterly disagree that this is "ok" or standard adherence to a specification. It's not just "different" - it goes from fabulous to unusable.


    Blog, Photos.
    [ Parent ]

    I don't understand CSS haters. (none / 0) (#120)
    by handslikesnakes on Mon Aug 16, 2004 at 07:58:34 PM EST

    I meant that I keep encountering pages that will not resize and have fonts that won't resize, either (until I started running firefox, which can force fonts to resize no matter what, it seems.)

    That's not CSS's fault, that's a combination of IE being shitty and site designers not knowing what they're doing. Non-IE browsers don't have this problem and IE doesn't have it if the site doesn't use px for text sizing.

    I'm against the author locking down the font size, the page width, the page height, the page colors, text reflow, that kind of thing.

    All of which are as easy (if not easier) to lock down without CSS than with. If I say td { width:10000px; } or .notice { color:#F00; } you adjust your user stylesheet. If I say <td width="10000"> or <font color="#FF0000"> there's not much you can do.

    My page formatting isn't that complex, aside from tables sometimes. So CSS might not do me or my customers a lot of good.

    Are you responsible for http://www.thighhighstudios.com/? Taking a look at its HTML I can guarantee savings in bandwidth by switching to CSS, with zero loss of functionality. If it doesn't get much traffic it might not be worth the trouble to redo it, but for new sites why would you do a 28K page when you could have a 14K one?
    And that's not even taking into account the other benefits of CSS — ease of restyling, accessibility, cleanliness of HTML, not having web geeks making fun of you.

    A standard pipe fitting fits ALL the pipes designed to the specification. All the pipes are designed to MEET the specification, which makes them standardized.

    And then you come along and claim that no standard of pipes exists because somebody makes his 2mm too wide.

    Ad hominem ahead: and it certainly doesn't make you look good when you claim you're not a Luddite but you don't know the first thing about CSS, your pages use HTML 3.2 and look like something from 1996.



    [ Parent ]
    Mostly great reply, thanks (none / 0) (#122)
    by fyngyrz on Mon Aug 16, 2004 at 11:55:25 PM EST

    Are you responsible for http://www.thighhighstudios.com/?

    Yes.

    Taking a look at its HTML I can guarantee savings in bandwidth by switching to CSS, with zero loss of functionality. If it doesn't get much traffic it might not be worth the trouble to redo it

    It is quite busy. In fact, it is one of the busiest sites I run. I would be willing to spend quite a few hours streamlining it. So what page(s) are we talking about here? Front? Or the CGI pages? Both?

    As for the troll part of your reply, I've experimented with stylesheets, way back when. I wasn't particularly moved by them. Also, on my various Wikis, stylesheets are integral through no action of mine, so, I've futzed with those extensively. And admittedly, never wrecked the resizability of a page doing do. On the other hand, I wasn't looking at stylesheets as a way to decrease bandwidth, so I'll take that part of the hit with good grace. :) As for the look of the site, it performs excellently (speaking in a commercial sense) so I'm not too sensitive about the looks. If you think it looks dated... well, then you think so, and more power to you. You probably wouldn't like the software I write, either; I pretty much ignore the UI "style of the day", being much more interested in something that works and doesn't take a huge amount of time away from programming in functionality. Anyway, I'm very interested in your claim of cutting page bandwidth in half. Especially since most of the bandwidth use on the site is image load. So fire away!


    Blog, Photos.
    [ Parent ]

    Oh dear, here I go again. (none / 0) (#130)
    by handslikesnakes on Wed Aug 18, 2004 at 12:36:09 AM EST

    I was a bit overzealous in my condemnation of you and your HTML work — sorry. CSS has more than its fair share of detractors (none of whom know what they're talking about, in my experience) and I get very defensive of it because I think it's a pretty good system.

    Obviously the size of the thumbnails involved dwarfs that of the HTML, which is why I never claimed anything about "cutting page bandwidth in half". I must admit that my claim of halving page size was a gross overestimation; there are countless sites where this is possible, but your HTML is relatively clean (if dated), for which I commend you. If you're really interested in cutting down on bandwidth you should ditch those absolute URLs. Every http://www.thighhighstudios.com/cgi-bin/ is a waste of 41 perfectly good bytes.

    Out of sheer boredom (and procrastination) I redid your main page and one of your CGI pages. The result?

    index.html
    Orig: 2899 B
    New:  2416 B

    shopping.html
    Orig: 29124 B
    New:  25824 B

    With the added CSS in style.css (1263 B) it works out to about an extra KB initially and then several KB saved on every subsequent page since the stylesheet is reused; nothing spectacular but these pages are mostly content anyhow. The biggest savings come on sites where styles and layout are consistent between pages and pages that are more markup than text. My pages aren't identical to yours, but they easily could be. There's lots of room for improvement in my CSS too - I didn't replace your abuse of tables for layout, for example.

    The point of this drawn out exercise is to disabuse you of the notion that CSS inconveniences anybody and hopefully stop you from repeating claims like that in the future. CSS lets you design your site in a very flexible way and change that design very easily (which I guess doesn't interest you much); take a look at the CSS Zen Garden if you don't believe me. If I as a user don't like your design I can turn it off or completely modify it. The only inconvenience involved is the initial cost of moving a site to CSS (which is much more of a pain than simply doing it in the first place).

    My attack on the appearance of your site was needless, particularly as it didn't get a rise out of you or evoke the feeling of superiority I usually get from belittling strangers. Next time I'll just question your manhood (I think the fact that you run an erotic lingerie store speaks for itself).
    It has a lot more to do with professionalism than a "style of the day". I'm pretty minimalist in my design tastes, but that tiled background is very Geocities-esque (and I bet I'm not the only one thinking it). When I see a web store that looks like that it immediately reminds me of the fake porn site I set up to trap credit card numbers in my younger days. Of course, as you say, it's purely a matter of taste and if you like it the way it is, more power to you.

    In the end though, unless you get a lot of visitors using Netscape 3 or you're like that guy in Memento who can't form new memories you've got no reason to be using things like <font> tags. If we can finally get rid of them we'll be on our way to a bigger and brighter future for the web.



    [ Parent ]
    Thanks a bunch (none / 0) (#131)
    by fyngyrz on Wed Aug 18, 2004 at 11:03:17 AM EST

    I very much appreciate the effort you went to. Thank you.

    I do have one question which seems to be key to me.

    What happens to the formatting when an older browser, one that doesn't support CSS, hits that page? Does the formatting just collapse? Looking at the underlying code, it seems to me that the formatting would be lost and the page would be pretty wrecked, but perhaps I just don't understand CSS well enough.

    The absolute URL's are there for two reasons. First, the pages activate the SITE CGI even when run on the local filesystem of a PC (not a Linux machine, unlike the host) where they are backed up. Without the absolute URLs, the CGI is fetched from the PC when run locally, which doesn't test it properly when I'm working on it at the PC. So if I edit them out, I have to do it at the last moment, and from then on, the pages don't work except when they're resident on the server. Or else I have to do all my editing on the site, and I don't like to do that - I prefer to get everything formatted completely and then upload. The second reason is that thighhighstudios has a sister site, "thighbaby.com" which has somewhat of a different look (thighbaby is primarily marketed to men, thighbaby is primarily marketed to the ladies.) Thighbaby uses quite a bit of the CGI on thighhighstudios and so requires the specific URLs to link over (not all the thighhighstudios CGI, or I'd just use an Apache alias.) So the thighbaby version has to have explicit URLs; the thighhighstudios version is somewhat common code, so the explicit URLs are there because I copy and paste between them.

    On the site's visual design. I'm a poor artist. Unfortunately, because I can do all the other facets just fine (html, application code, database, cgi, system administration, etc.) and because I uniformly hire technical people rather than artists, I often find myself in the position of "designing" the art for the sites. Now, I appreciate your comments about the tiled backdrop, I really do - as you say it, I see it as you describe - but I am bereft of ideas as to how to replace that look. It has to survive resize (tiling inherently does this) so that most any rational browser resize by the user will not ruin the look and feel of the site; and it would need to give a similar feel, one that I can only describe as compatible with the sigil on the front page. Maybe calling it boutiqe-like is in the zone somewhere. I am certainly open to suggestions. Feel free, if you have some. Otherwise, all I can really do in response to your art-centric criticism is nod and shrug.


    Blog, Photos.
    [ Parent ]

    No problem, I like to fiddle. (none / 0) (#133)
    by handslikesnakes on Wed Aug 18, 2004 at 05:13:21 PM EST

    What happens to the formatting when an older browser, one that doesn't support CSS, hits that page? Does the formatting just collapse? Looking at the underlying code, it seems to me that the formatting would be lost and the page would be pretty wrecked, but perhaps I just don't understand CSS well enough.

    All the formatting disappears, which is an advantage in most cases. If a user agent doesn't support CSS it's usually for a good reason. Search engine spiders and text-to-speech browsers don't care about your visual styles. Lynx doesn't do CSS, but it doesn't do much formatting anyways. As for graphical browsers, I would be awfully surprised to see somebody browsing with something pre-CSS — even IE3 and NN4 do the most important stuff.

    As long as yor page is sanely marked up, with <h >s for headings and <p>s for paragraphs and <em> for emphasis then it will display acceptably, if blandly. The only time I can really see this happening is when somebody deliberately turns off stylesheets though.

    PS. I forgot to mention that the redoes I did would validate if the &s in URLs were properly escaped (&)

    [ Parent ]

    I had no idea... (none / 0) (#134)
    by fyngyrz on Thu Aug 19, 2004 at 03:58:52 PM EST

    ...you had to escape ampersands. I've never noticed an escaped ampersand in a CGI URL; but reading the spec the validator pointed to, I see that I've been doing it outright wrong. Whoops.

    Going to take some time to fix all those... but I will. :)

    Thanks!

    Blog, Photos.
    [ Parent ]

    CSS bad? And you still use it. (none / 0) (#99)
    by blight on Sat Aug 14, 2004 at 08:13:23 AM EST

    I see you complaining about CSS (which stands for Cascading Style Sheets) and yet you mention having a stylesheet based system that builds web content. Could you clarify on exactly why do you use CSS even though you're telling us not to?


    [ Parent ]
    Stylesheets > CSS (none / 0) (#109)
    by Jim Dabell on Sun Aug 15, 2004 at 07:20:50 PM EST

    Just because he uses stylesheets, it doesn't mean he uses CSS. For instance, he could be using XSL.

    [ Parent ]
    XSL seems to be CSS2 with some extensions. (none / 0) (#132)
    by blight on Wed Aug 18, 2004 at 01:31:19 PM EST

    Since XSL looks like it's extended from CSS2 with new syntax, I believe fyngyrz would not see much of a difference.

    I didn't know of it's existence though. Thank you for pointing it out. I might even read the specification properly someday (instead of just doing a fast scan to get an idea of what it is).

    [ Parent ]

    No. It's not. (nt) (none / 0) (#135)
    by ubernostrum on Sun Sep 05, 2004 at 11:07:51 PM EST




    --
    You cooin' with my bird?
    [ Parent ]
    How many IT programs have you written? (none / 0) (#125)
    by John Asscroft on Tue Aug 17, 2004 at 11:52:19 AM EST

    The biggest use for web browsers in a corporate setting is as a front end for corporate databases, basically the replacement for dumb terminals. The problem is that, right now, HTML is *DUMB*. So our web pages end up being as much client-side JavaScript to do input processing as HTML. This is *required* to reduce the # of mouse clicks/submits, remember, we have a whole five-story building covering 5 acres of land that is nothing but thousands of ladies keypunching data, hitting the SUBMIT button hundreds of times per second. We can NOT double that SUBMIT volume by not doing input processing (and yes, it WOULD double the SUBMIT volume, because if these ladies had brains, they wouldn't be working in our keypunch center... we must make the computer think for them, or it's a fiasco). We'd have to double the size of our internal web server farm to do that, and double the number of queries to our DBMS, which in turn would require beefier hardware. *EXPENSIVE* hardware. So right now JavaScript cludges are the order of the day.

    Frankly, I couldn't give a flip about the World Wide Web when it comes to a new forms standard. The WWW works fine with old forms. But for corporate data processing, xforms is going to be the niftiest new thing since the 3270 terminal, *finally* giving us the data entry capabilities with a web browser that we had back in the dumb terminal days. And yes, I would consider it useful enough to order its rollout into the keypunch center as part of the rollout of the next generation of the keypunch software. Remember, corporate environments are not the WWW. Rolling out a browser plugin to a keypunch center is a big deal, but not THAT big a deal, given that those computers are already running monitoring and control software (for making sure that the ladies are keypunching and not gossiping) and thus we can control them remotely in an automated fashion.

    -- The A.G.'s Inner Frenchman
    We must destroy freedom to save it from the terrorists who want to destroy freedom. Else the terrorists have won.
    [ Parent ]

    How to get people to switch to Mozilla (3.00 / 3) (#43)
    by MichaelCrawford on Thu Aug 12, 2004 at 03:48:20 PM EST

    Have the head of the corporate IT department meet with the president of the company and explain that the reason they have so much downtime due to viruses, spyware, worms and the like is because IE is so full of security holes, with more appearing all the time.

    Then explain these all can be avoided if the company desktop were to standardize on Mozilla.

    Further, require that the company's supplier's websites have to work well with Mozilla, or else they won't be on the approved vendors list.

    Government agencies should require this too. Imagine if the NSA told the DOD that they shouldn't be using IE, and that the DOD then told all the defense contractors that they had to make their websites work well for Mozilla.

    Somewhere in the bowels of bugzilla.mozilla.org is an evangelism bug I filed that said the Supreme Court's website didn't work with Mozilla. It turned out that the website was designed by the US government printing office. Somebody with a clue got through to the printing office, and now SCOTUS' website works just fine with Mozilla.

    No, you're not going to reach many users with promises of free-as-in-freedom software. But if you reach corporate and government decision makers with the news that they can save millions of dollars each year in employee downtime by using more secure software, then you'll be achieving world domination thirty thousand employees at a time.

    Yes, I realize security holes are sometimes found in Mozilla too, but history has proven it is orders of magnitude less expensive to use than IE.


    --

    Live your fucking life. Sue someone on the Internet. Write a fucking music player. Like the great man Michael David Crawford has shown us all: Hard work, a strong will to stalk, and a few fries short of a happy meal goes a long way. -- bride of spidy


    The Canadian government... (none / 0) (#49)
    by the77x42 on Thu Aug 12, 2004 at 05:51:26 PM EST

    Well at least the BC government is forbidden to use internet explorer. All browsing is done on netscape. In fact, there are a few government websites that won't work on IE (well at least didn't when I had to deal with them).

    Does this change anything? No. It's still a huge pain in the ass having to code for many different browsers's idiosyncracies.


    "We're not here to educate. We're here to point and laugh." - creature
    "You have some pretty stupid ideas." - indubitable ‮

    [ Parent ]

    once a movement is started (none / 0) (#77)
    by Run4YourLives on Fri Aug 13, 2004 at 01:01:30 PM EST

    You don't have to code for anything but standards.

    Screw the old guys.

    Once a movement starts...

    It's slightly Japanese, but without all of that fanatical devotion to the workplace. - CheeseburgerBrown
    [ Parent ]

    Yeah, but... (2.50 / 2) (#81)
    by skyknight on Fri Aug 13, 2004 at 02:40:49 PM EST

    as Mozilla gains widespread use, it will become an increasingly attractive vector for attackers to break into machines. Right now it's got security through obscurity going for it. If you're a cracker, and you can use one vector to hit 97% of machines, and another vector to hit 3% of the machines, that disparity alone is probably enough to tip your decision regardless of the security hardening of either of the vectors. What happens when it's a 50/50 split? Well, then you'll see a great deal of assault on both. At least with the present split, knowing people such as ourselves can use Mozilla and evade the catastrophes that are a daily affair for other people.

    It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
    [ Parent ]
    True and Proven, but... (2.33 / 3) (#92)
    by ph317 on Fri Aug 13, 2004 at 11:58:58 PM EST


    We've seen that this is true, as we've seen a spate of recent security problems in the latest Firefox/Thunderbird releases due to the increasing exposure the platforms are getting.  But still, I firmly hold that Mozilla-based products will have a lower incidence of security issues than their Microsoft counterparts, that the issues won't be as severe on average, and that they'll have fixes released sooner*.  All of this I claim, just because it's open source software and because the programmers' collective primary goal is a good, safe browsing environment, as opposed to world domination (can we say default activex scripting in outlook? how many users did that benefit, and why was it left in there if not to push microsoft's agenda instead of the conflicting user agenda?)

    * Footnote against Mozilla products and released security updates - they might quickly release new point releases of the browser/mailclient, but to date they have yet to adopt an auto-update type solution, so they're still relying on vigilant end-users to do upgrades on their own, which we know they don't do.  I seem to remember someone (or some collective someones) at Mozilla are actually against having a bundled update tool that auto-checks and optionally auto-updates, which seems pretty ludicrous.  I'm hoping this situation reverses itself as the Mozilla suite becomes more mainstream and they finally realize how clueless everyone is.

    [ Parent ]

    FWIW... (none / 1) (#103)
    by ubernostrum on Sat Aug 14, 2004 at 04:12:04 PM EST

    If you found out your car's stereo had a manufacturing defect, you could get a new stereo for, at most, a couple hundred dollars probably. What if there's a manufacturing defect in the transmission, though?

    The potential security risks of an application which is not an integral part of the operating system are, by definition, lower than the potential security risks of an application which is.




    --
    You cooin' with my bird?
    [ Parent ]
    Well, sure... (3.00 / 2) (#111)
    by skyknight on Sun Aug 15, 2004 at 11:09:17 PM EST

    which is why Microsoft's claims of IIS being faster than Apache are quite dubious. Indeed it is faster, but only because they tied it directly into the operating system, so when there is a security violation the whole system comes crashing down around you.

    It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
    [ Parent ]
    No choice needed (3.00 / 2) (#59)
    by scott reynen on Thu Aug 12, 2004 at 09:51:58 PM EST

    "A developer has a choice to make."

    This is untrue. X-Forms can be added to existing HTML documents, and browsers that don't support X-Forms won't show anything but standard HTML forms. This is how every extension of HTML has happened. If X-Forms prove to be something users want, users will switch to browsers that support X-Forms, making this a lengthy article suggesting an unlikely "solution" to a problem that doesn't exist.

    Re: No choice needed (none / 1) (#62)
    by fd on Thu Aug 12, 2004 at 10:23:00 PM EST

    Have you seen the examples here?

    http://www.w3.org/MarkUp/Forms/2003/xforms-for-html-authors.html

    I don't think a single one of those will show anything at all like a legacy form in a browser that doesn't grok XForms.  If you're talking about adding XForms to a page and keeping the legacy form (something like the old object..embed paradigm) then how is that not supporting two standards at once and wasting time?

    [ Parent ]

    wasting time (none / 0) (#63)
    by scott reynen on Thu Aug 12, 2004 at 11:20:12 PM EST

    "then how is that not supporting two standards at once and wasting time?"

    that's exactly what i'm talking about, and it might be wasting time, but 1) you said a choice is needed, but a choice isn't needed - it's possible to implement both even if you don't want to, and 2) this is no different than how every other extension to HTML has been implemented, so there's nothing here to suggest some major change worthy of an article.

    [ Parent ]

    You still misunderstand the choice (none / 0) (#137)
    by p3d0 on Thu Dec 16, 2004 at 12:11:05 AM EST

    "Support both" was one of the options.
    --
    Patrick Doyle
    My comments do not reflect the opinions of my employer.
    [ Parent ]
    Read the very next sentence (none / 0) (#117)
    by p3d0 on Mon Aug 16, 2004 at 12:36:59 PM EST

    And I quote: "Is he going to support XForms and Mozilla? Is he going to support IE only? Or is he going to support both, either by using legacy HTML forms or by going to the herculean effort to support XForms and Microsoft's solution (InfoPath, ASP.Net forms)?"
    --
    Patrick Doyle
    My comments do not reflect the opinions of my employer.
    [ Parent ]
    XForms isn't the issue (none / 0) (#74)
    by gidds on Fri Aug 13, 2004 at 11:13:22 AM EST

    You're looking at this the wrong way. XForms isn't the issue here; browser monopoly is.

    If M$ supports XForms, then they'll keep their browser monopoly, everyone will continue to use IE, and we'll all be stuffed when we want to implement the next great feature.

    Whereas if we break the monopoly -- not getting rid of IE, just getting to the point where it's not an automatic choice -- then we'll be free to use XForms or whatever else, safe in the knowledge that people will choose to use it if they think it's any good.

    So for this reason, I hope that IE doesn't get XForms, pop-up blocking, tabs, whatever. It'll be painful for a while, but worth it in the long run.

    Andy/

    World Yawns? Maybe, but not me! (3.00 / 3) (#78)
    by ivancruz on Fri Aug 13, 2004 at 02:01:15 PM EST

    Every single website I build nowadays have two "sides": a user side and a administrative side.

    The user side is usualy easy to code, have a very few pages, very simple forms and lotsa joe-user accessing.

    By other side, the administrative portion have plenty of very complex forms and normally are hard to code, but have only a handfull of administrative users.

    When Mozilla XForms make a debut I will start building the administrative pages with XForms while mantaining the users side in plain old html 4. To turn my administrative users to Mozilla or at last make them install a second browser, is not that dificult.

    ______________________________________
    Eu vou, eu vou vender a minha vă, Eu vou vender a minha vă, A minha vă filosofia.(Zeca Baleiro)

    Why wouldn't the same argument hold for XUL? [nt] (none / 1) (#96)
    by reftel on Sat Aug 14, 2004 at 07:20:26 AM EST



    [ Parent ]
    Strategic errors (none / 0) (#116)
    by ivancruz on Mon Aug 16, 2004 at 12:34:26 PM EST

    In a war, a strategical withdrawal is as important as an successful attack.

    Using XUL I would place myself in a situation without withdrawal possibility. I would be stuck in the case some partner prohibit a Mozilla instalation. Choosing XForms I can offer plugins for the IE, as an option.

    Anyway you have a good point here.

    Almost two years ago, when I started using Mozilla, I ruled out XUL as a plataform because anybody else was using it. It changed a lot in the meantime. Today, in our company, nobody is using Outlook and many fellows have Mozilla as the default browser. Maybe its time to give XUL a try.

    ______________________________________
    Eu vou, eu vou vender a minha vă, Eu vou vender a minha vă, A minha vă filosofia.(Zeca Baleiro)
    [ Parent ]

    Huh? (none / 0) (#108)
    by doormat on Sun Aug 15, 2004 at 03:08:19 AM EST

    The logic doesnt seem right to me...

    If MS doesnt add X-Forms and people dont want to bother with a plug-in, they pretty much never get adopted.

    If MS doesnt add X-Forms and people do bother with a plug-in, then MS doesnt do any effort and they're adopted.

    If MS does add X-Forms it just cost them money, and maybe it will be adopted (its highly likely but not 100% sure).

    So why dont they just not exert themselves? They are trying to cut expenses ya know...

    |\
    |/oormat

    Another possibility... (none / 0) (#124)
    by Elendale on Tue Aug 17, 2004 at 02:43:39 AM EST

    Microsoft doesn't add XForms and eventually IE is drowned like a baby in a bathtub.

    Sure, it's not likely to happen today, but every standard that Firefox and other browsers support that Internet Explorer does not is one more reason to not use Internet Explorer. Eventually the benefits of running Firefox or some other browser will outweigh the costs of having to download and install it for general users. Eventually, Microsoft must catch up. Now, that doesn't mean they have to add XForms- but there has to be some movement. They are no longer the torch bearers- even if few have noticed.


    ---

    When free speech is outlawed, only criminals will complain.


    [ Parent ]
    Mozilla To Add Support For XForms, World Yawns | 137 comments (119 topical, 18 editorial, 1 hidden)
    Display: Sort:

    kuro5hin.org

    [XML]
    All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!