Linked by snydeq on Tue 16th Aug 2011 16:46 UTC
Web 2.0 InfoWorld's Peter Wayner discusses the 11 hard truths Web developers must accept in making the most of HTML5 -- especially those who are looking to leverage HTML5 in hopes of unseating native apps. 'The truth is, despite its powerful capabilities, HTML5 isn't the solution for every problem. Its additional features are compelling and will help make Web apps formidable competitors for native apps, but security issues, limitations of local data storage, synchonization challenges, and politics should have us all scaling back our expectations for the spec.'
Thread beginning with comment 485702
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[7]: HTML 5 == Pointless Bloat
by galvanash on Thu 18th Aug 2011 05:44 UTC in reply to "RE[6]: HTML 5 == Pointless Bloat"
galvanash
Member since:
2006-01-25

So you're suggesting that CSS means things like WML don't have a reason to exist now?


Other than for the oddball feature phone that is 3+ years old? Yes, no reason at all. It is dead as a door nail going forward. No one is building WML devices anymore...

The model I want is where raw content comes from where-ever (e.g. database), something like HTML is used to present that content to visual users, some sort of "Aural Markup Language" is used to present that content to aural users, something like WML is used to present that content to small devices, something else is used to present the content to search engines, etc. Basically, markup languages designed for specific purposes, rather than a horrid mess that tries to cope with everything imaginable at once.


And you just illustrated why WML died... You really have some crazy notions, I gotta give you credit for not being shy with them. You are literally the only person I have ever seen describe markup soup as something they actually want.

Reply Parent Score: 2

Brendan Member since:
2005-11-16

Hi,

Other than for the oddball feature phone that is 3+ years old? Yes, no reason at all. It is dead as a door nail going forward. No one is building WML devices anymore...


That's sad - the idea of delivering one file that represents many (small) pages seemed important. I also severely doubt that you'll ever be able to have one HTML file, with one CSS file that lays that HTML out as "one big page for normal users" plus another CSS file that lays that same HTML out as "many smaller pages for mobile users".

"The model I want is where raw content comes from where-ever (e.g. database), something like HTML is used to present that content to visual users, some sort of "Aural Markup Language" is used to present that content to aural users, something like WML is used to present that content to small devices, something else is used to present the content to search engines, etc. Basically, markup languages designed for specific purposes, rather than a horrid mess that tries to cope with everything imaginable at once.


And you just illustrated why WML died... You really have some crazy notions, I gotta give you credit for not being shy with them. You are literally the only person I have ever seen describe markup soup as something they actually want.
"

I've got an idea. Rather than having lots of different vehicles (planes, cars, trucks, wheelchairs, skateboards), lets attempt to create a silver bullet that completely sucks for everything.

Different markup languages designed for different purposes is better than "10 variations of HTML plus 5 variations of XHTML plus 3 variations of CSS plus javascript plus DOM plus java plus flash plus 10 server side scripting languages plus at 15 different toolkits and frameworks to try to make it bearable for web developers plus browser incompatibilities because nothing helps make it bearable for browser developers" all sugar-coated in a layer of hype.

It's the old "Do one thing and do it well" idea.

- Brendan

Reply Parent Score: 2

galvanash Member since:
2006-01-25

That's sad - the idea of delivering one file that represents many (small) pages seemed important. I also severely doubt that you'll ever be able to have one HTML file, with one CSS file that lays that HTML out as "one big page for normal users" plus another CSS file that lays that same HTML out as "many smaller pages for mobile users".


Depending on how complex it was... You could do something fairly trivial (i.e. equivalent to WML cards) with just HTML+CSS. You could even add transition effects to it and do a lot of neat stuff that WML cannot do - the card and stack metaphor is not really very complex to recreate.

However, if you wanted to keep the navigation history intact you would need a bit of javascript, at which point you would probably be better off just going all the way and using ajax to implement this as it adds a lot more flexibility vs. pure HTML+CSS.

Is it easier to do it this way than to use WML? No, not initially - but it isn't rocket science either. Once you got the initial CSS/javascript bits working properly the markup is exactly the same as it would be for a regular HTML page, and you could even apply the card metaphor in the desktop browsers if you wanted to. It isn't easier, but it is much more flexible and anything that supports HTML would understand it.

I've got an idea. Rather than having lots of different vehicles (planes, cars, trucks, wheelchairs, skateboards), lets attempt to create a silver bullet that completely sucks for everything.


(HTML + CSS + Javascript) = infinite(MARKUP LANGUAGES)

...as long as the thing you are marking up fits the mental model of a generalized document. HTML is not a good way to describe everything, but as long as what you are describing is conceptually a document, you really do not need anything else. Ever.

I'll try saying it this way... Any markup language you come up with will, BY DEFINITION, be severely limited in what you can do with it until you add 2 things to it:

1. The ability to define/redefine what the markup actually does (this is what CSS does).

2. The ability to add procedural, non-declarative, state-maintaining logic to it (this is what Javascript does).

That isn't opinion - it is simply fact. Anything short of being able to do both of these and you end up with an inflexible waste of time that you will hit the proverbial wall with rather quickly.

HTML already has both of these, and by having them both it is inherently adaptable to pretty much any presentational device - a visual browser, a screen reader, something that generates brail, something that carves stone tablets... Doesn't matter. You might need to come up with a new type of stylesheet to handle it (like aural), but you do not need to redefine HTML itself.

You could, if you wanted to, turn HTML into a procedural markup language. You would make each tag accept every possible attribute that can possibly affect it's presentation (which in reality would be 1 attribute for every possible CSS property in existence - there are about 100 or so). You would have something like a sort of "megatag" under the hood that logically maps to a big function that can work with all the parameters known - all of your normal tags would simply be sane defaults for initializing the function so that say your font tag expects all the properties relevant to fonts, the big tag has a large default for font-size, etc. etc. It would still look and work like HTML, but the functionality would essentially be frozen into the schema of the markup language.

Then you would have to do it all again for screen readers, because they are fundamentally different....

Every time you wanted to add a new styling ability, you would have to release a new schema for the markup language, so that editors could deal with it, browsers could add the ability to parse the new properties and implement them, and users would know what their new options were. So you would have many distinct markups languages for each type of presentation device, mostly identical to each other with the exception of presentational attributes.

This is exactly what CSS does, with 4 important differences:

1. It adds a different language with a syntax optimized for defining presentation attributes in a much more concise and logical way than what can be described purely as attribute values. Markup is a horribly inefficient way to define things, because a definition is something that stands on its own - markup is for describing things - and the thing it is describing it what is contained inside the markup.

2. It adds the ability to map these presentation definitions to markup tags in a way that allows you to reuse the definition over and over again (inheritance). In effect you are defining your own tags when you do this.

3. It gives you the ability to inline the presentation properties within a single attribute (the style attribute) when you want to simply inline them and do not need inheritence. This gives you exactly the same capabilities as a procedural presentation tag language would, but is flexible - the capabilities are not frozen into the language schema anymore. Which leads to...

4. The absolutely most important part: you can add things to CSS without requiring any changes at all to the markup language itself. It exists separately. You can even define entirely new dialects of CSS for other purposes (like aural). The presentational capabilities of HTML 4 have increased immensely in the last few years, all without anyone having to come up with any new version of HTML.

It's the old "Do one thing and do it well" idea.


Yes. EXACTLY!!! Markup does one thing very well - it describes things (i.e. "this is a paragraph"). CSS does a different thing very well, it defines things (i.e. a "paragraph" is a block element which indents the first line by 3em and has a top and bottom margin of 1en").

The "do one thing and do it well" mantra is pretty much the reason that there is a fundamental distinctions between HTML and CSS - one language cannot do both well without being inherently cumbersome.

If you cannot see the inherent logic in this argument I don't know what else to tell you...

Reply Parent Score: 2