Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Webby mess

 
Saloon Keeper
Posts: 12165
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Original topic: click]

At the risk of going off-topic on a tangent I find "webby" stuff difficult to get into. Whatever new I try, it seems I first have to spend a week to find out about all the available frameworks, and every so often a new kid comes in town who says it's going to make everything easier.

Computer science has always been a fast area, but it's hard to keep up with web development specifically. I'm currently learning Laravel, because I hate PHP spaghetti.
 
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:At the risk of going off-topic on a tangent I find "webby" stuff difficult to get into. Whatever new I try, it seems I first have to spend a week to find out about all the available frameworks, and every so often a new kid comes in town who says it's going to make everything easier.


I certainly sympathise. My first exposure to markup languages was with IBM GML, which was for producing "pretty output" on printers, and I didn't like it even for that; so imagine my surprise when it morphed into a system for producing "web content".

I suppose there are superficial similarities, and there's no doubt that, even in the old days of "curses"-type screens, "GUI" code has always been verbose, fiddly, complex, and laden with boilerplate; but I'm definitely not convinced that the current mish-mash of markup, style sheets, "action" tags and URLs, client-side scripts, and clunky messaging (powered, in the main, by markup) represents a real "solution" to the problem.

I also reckon that one major problem is that we still have to deal with HTML. Surely, after 20 years, we could have browsers that have htmltidy built into them, so that we KNOW that any code we receive back from a page is well-formed?

And don't get me started on XML standardization...

Winston
 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:I'm definitely not convinced that the current mish-mash of markup, style sheets, "action" tags and URLs, client-side scripts, and clunky messaging (powered, in the main, by markup) represents a real "solution" to the problem.



Me either. CSS is a fine example of attempting to graft some kind of fix onto something that needs to be replaced.
 
Stephan van Hulst
Saloon Keeper
Posts: 12165
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston, like you said, GUIs are intrinsically messy. In that regard I actually have to say that HTML/CSS/JavaScript have done quite well in regards to "keeping it tidy". Relatively so, of course. It's a good thing that there's such a strong separation between concerns like content, style, and scripting.

HTML is going in the right direction. It's becoming more semantic, which I like. I just wish it wasn't so heavily based on XML. CSS on the other hand... whoo boy. It seems CSS is getting more and more cluttered with browser-specific-pseudo-whatever. I wish we had layout managers instead of CSS

As for JavaScript... There are many things I don't like about JavaScript. I never embraced a framework as fast as I've embraced jQuery. To me, that says more about JavaScript than jQuery. Messaging, if done right, isn't completely terrible. I don't mind JSON all that much. I would have preferred YAML, but oh well.

I think the big problem of the web was that at the beginning, it was too easy for the average person to put something together that looked like it worked. You could do everything in your text editor and display it immediately. Browsers were lenient, people didn't care to close their tags. Everything was open to interpretation. Now we're stuck with the mess. Also, every other person has an idea for how things can be better, and they come up with a new language or framework. I'm really happy right now that the server I'm deploying my current project on is a simple Apache/PHP/MySQL stack, so at least I don't have much choice in the language. To be fair, this is not limited to webby stuff. The amount of frameworks out there for Java is staggering.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:HTML is going in the right direction. It's becoming more semantic, which I like. I just wish it wasn't so heavily based on XML.


My main complaint about markup as a presentation-layer spec (let's leave messaging/data transfer out of it for the moment) is that everything is a string. This means that:
(a) For even the most rudimentary of data typing you need some sort of "background mechanics".
(b) Security is pretty much non-existent.
(c) Arrays (or "tables") are phenomenally clunky. Is there yet a spec for inputting array (let alone grid) -based data?
It's kind of like having a bunch of Java modules linked together via Strings and Scanners.

Even in the old days, frameworks like IMS/DC and CICS/BMS recognised that there was a difference between a display and the information provided to or returned from it (the "map"). They were connected, but not the same. This, for example, allowed the return map to make a distinction between "blank" and "un-entered".

Personally, I don't particularly mind having to use HTML (or XHTML) for the display part, but I do mind having to parse the "?" portion of a URL in order to work out what someone did.

Now of course, displays in those days were much more static and "local", but it does seem that we've lost quite a bit of structure in our quest for ever-"busier" and more dynamic interaction.

On the other hand, there are aspects about browsers that even an old fart like me can appreciate:
1. Parallel loading.
2. Automated image processing/resizing.
3. Hyperlinks.
4. Certificates.

I just wish all that "interactive glue" was a bit easier to follow.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 12165
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not quire sure I follow. What do data typing, security and arrays have to do with the presentation layer? All HTML does is lay out a structure for your page. I don't see how you would need data types for that. Arguably, tags represent types themselves, e.g.:
  • <div>   -> JPanel,
  • <table> -> JTable,
  • <ul>    -> JList,
  • <body>  -> JFrame.

How is security needed in HTML? It doesn't actually do anything?
 
Stephan van Hulst
Saloon Keeper
Posts: 12165
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As for tables... Yes, tables are horrible. I think YAML would have been much nicer for tables:versus
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I'm not quire sure I follow. What do data typing, security and arrays have to do with the presentation layer? All HTML does is lay out a structure for your page.


I'm not so sure it does. It specifies content, not layout. Indeed, I'm quite sure that many forms designers wish that it actually specified more layout stuff (like simple indenting for example; how about a <tab> tag?).

And as for security, I'm not saying that HTML (and don't forget that we're talking about the combination of HTML and browser here) should necessarily provide a complete security layer; I'm saying that I ought to be able to enter a simple thing like a password without it appearing in plain text in a URL (or on my screen).

I don't see how you would need data types for that. Arguably, tags represent types themselves


And again, I say that they represent visual content types, not data types.

Example:
I want to type a birthdate into a web page, and I want it to be <= today and within 100 years of today. Why should I have to go to a server, or write some 'orrible embedded script - which, given the textual nature of HTML, I'll almost certainly end up cutting and pasting - to do that?

As I say, even I can appreciate some of the things that browsers offer; but the business of straightforward, normalized, type-based "data entry"-type stuff is still a work-in-progress from what I can see.

But please, prove me wrong. I freely admit that I'm a bit of a "webby Luddite".

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 12165
258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:I'm not so sure it does. It specifies content, not layout.


You are correct of course. I had a bit of a mental moment.

I'm saying that I ought to be able to enter a simple thing like a password without it appearing in plain text in a URL (or on my screen).


Maybe I'm misunderstanding again. I don't see what's wrong with <input type="password"/> ? On submit it gets posted rather than sent as query argument. You'd have to make sure to use https though. I wouldn't call this a deficiency of HTML, although maybe it should be a browser's responsibility to warn the user when password fields are being posted without encryption. What I do really hate about HTML is that there's no easy way for me to POST anything without using a <form> or ajax.

I don't see how you would need data types for that. Arguably, tags represent types themselves


And again, I say that they represent visual content types, not data types.

[...]

As I say, even I can appreciate some of the things that browsers offer; but the business of straightforward, normalized, type-based "data entry"-type stuff is still a work-in-progress from what I can see.


I see what you mean now. The problem is that you're still stuck with the data transfer. Any application can send anything over HTTP, and it's *always* going to be the server's responsibility to normalize. You can do input checking in JavaScript, but only for user-friendliness, never to verify input for the web application. This is intrinsic to server-client communication, unless you have a protocol that only lets certified client software establish a connection.

HTML5 has <input type="date"/> and <input type="number"/>, the latter of which can be limited in what values it accepts. This is actually *better* than what we have with standard Java, AFAIK. In Java, I still need to do Integer.parseInt(field.getText()) in my listeners, which I consider closer to controllers than the presentation layer.

I freely admit that I'm a bit of a "webby Luddite".


I wouldn't go so far as to say I'm a Luddite, but I definitely could have more experience in the field. I'm thoroughly enjoying the discussion though.
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:I see what you mean now. The problem is that you're still stuck with the data transfer. Any application can send anything over HTTP, and it's *always* going to be the server's responsibility to normalize.


Is it? I thought that's where client-side scripting came about.

You can do input checking in JavaScript, but only for user-friendliness, never to verify input for the web application. This is intrinsic to server-client communication, unless you have a protocol that only lets certified client software establish a connection.


No. The transmission protocol doesn't enter into it (at least I'm pretty sure it doesn't). I understand that there are two 'T's in HTTP, at least one of which stands for "text" .

What I think I'm looking for is some inbuilt "smarts" at the client end - either built directly into the browser, or easily addable as a "plug-in", that translates (or verifies) the "text" that's entered on a screen into "text" (or encoded CDATA) that I KNOW represents a specific datatype in my application or language.

At it's most basic, I don't think it needs to be wildly complex: string is the default; and int, double (specifically, IEEE-754 double) and boolean are supported by most languages. Dates are a bit more complex, but I can't believe it's beyond the wit of man to translate a string to a Unix time (or date) value - by format if necessary.

Obviously, any business-related verification needs to be done by the server, but I'm talking about basic type/value checking, and I think that you ought to be able to enter types, and optional literals (including things like "today") for range checking without having to resort to scripts or server-side verification. What about:
<input type="date", name="dob", format="d/m/y", high="today", low="today-100y"/>
<input type="double", name="temp-C", low="-273.15"/>

Does that make my "gripe" any clearer?

Winston
 
author
Posts: 297
5
Android Firefox Browser Fedora
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:
I just wish it wasn't so heavily based on XML.


Actually it's very explicitly not based on XML. The W3C wanted to base the next generation of HTML on XML but no-one who makes browsers wanted to support a markup language which was not backwards compatible with existing web content; that is how we ended up with the WHATWG and HTML5. The WHATWG has been quite adamant about rejecting any XML-like features whenever they've been proposed (eg. namespaces, RDFa).

Stephan van Hulst wrote:
It seems CSS is getting more and more cluttered with browser-specific-pseudo-whatever.


CSS has no browser-specific-pseudo-whatever. The CSS implementations in several browsers have various custom or experimental CSS features, you are not forced to use them and you shouldn't use them if you don't understand why we have them. Most browsers are moving to feature flags instead of prefixes for their experimental implementations (both in CSS and HTML5).

Stephan van Hulst wrote:
I think the big problem of the web was that at the beginning, it was too easy for the average person to put something together that looked like it worked.


I don't think that's the big problem, I think that's the main reason the web became so popular in the first place.

Winston Gutkowski wrote:
but I do mind having to parse the "?" portion of a URL in order to work out what someone did


Then use POST instead of GET?

Winston Gutkowski wrote:
<input type="date", name="dob", format="d/m/y", high="today", low="today-100y"/>


I'm not sure what all the commas are for, but the date input type is already in the HTML spec. So far only Chrome and Opera have implemented it:

The submit format is fixed (ISO compatible) but the presentation format should conform to the user's locale.

Winston Gutkowski wrote:
<input type="double", name="temp-C", low="-273.15"/>


Likewise there is number input, the type is a JavaScript float:
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rob Crowther wrote:I'm not sure what all the commas are for...


Simply unfamiliarity with HTML. Haven't written any in a long time.

Attributes are actually another of my gripes with the "language". There simply don't seem to be any standards as to how and when to use them, and I have to admit to a slight preference for not using them at all; or only for mandatory values that cannot be given a default, viz:More verbose, but a lot simpler and more flexible I suspect.

Likewise there is number input, the type is a JavaScript float...


Thanks for that Rob. Very informative post.

Winston
 
Winston Gutkowski
Bartender
Posts: 10777
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rob Crowther wrote:Actually it's very explicitly not based on XML..


Actually Rob, you seem to be very knowledgeable about this, so I have a question: Why is "well-formedness" so important?

It seems to me that markups (XML included) could have been made far less verbose and finicky with the simple expedient of a generic terminator tag, perhaps something like:
  • </> - close the last opened tag.
  • <//> - close all open tags in hierarchical sequence.

  • Then, to make markup "well-formed", all you'd have to do is add a '<//>' at the end of a file; and you could do it without turning the browser's parser into a "syntax-checker".

    Winston
     
    Rob Crowther
    author
    Posts: 297
    5
    Android Firefox Browser Fedora
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well in HTML5 it's not a requirement, you can leave off all the closing tags if you want to. I wouldn't recommend doing it because then, unless you understand in detail how the DOM gets created, you're going to see some pretty surprising results from relatively small changes.

    It's also the case that it takes fewer CPU cycles to parse valid markup than it does to parse invalid markup and less CPU=more battery life.

    I'm not sure what the original rationale for not having generic closing tags is but I personally prefer it that way, I'd much rather if an obvious parsing warning because I'd got the nesting wrong than have no idea there was any problem just because I happen to have the correct number of closing tags.
     
    Stephan van Hulst
    Saloon Keeper
    Posts: 12165
    258
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for the enlightening discussion, Rob and Winston. I will have something to mull over for a bit
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:It's also the case that it takes fewer CPU cycles to parse valid markup than it does to parse invalid markup and less CPU=more battery life.


    Hmmm. Extra recursive calls vs. reading more characters from an I/O device or a network card? Maybe back when W3C was in its infancy, but I highly doubt it now.

    I'm not sure what the original rationale for not having generic closing tags is but I personally prefer it that way, I'd much rather if an obvious parsing warning because I'd got the nesting wrong than have no idea there was any problem just because I happen to have the correct number of closing tags.


    So, does it give you a decent message? My understanding was that the only requirement for a browser was to reject it, but I'm glad to hear I'm out of date in that case.
    And I certainly understand that generic tags might be open to abuse, but a few well-publicized "guidelines" could probably minimise that (eg, not using '</>' in "stacks", or for closing tags that are miles away). After all, one would hope that you're dealing with people with a modicum of intelligence.

    I also understand that they wouldn't deal with the problem of overlapping tags, but again, htmltidy's been around for 15 years...

    Winston
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:Thanks for the enlightening discussion, Rob and Winston. I will have something to mull over for a bit


    Hey, it's Rob that's enlightening; I'm just griping ... and punting ...

    Winston
     
    Rob Crowther
    author
    Posts: 297
    5
    Android Firefox Browser Fedora
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:
    Hmmm. Extra recursive calls vs. reading more characters from an I/O device or a network card? Maybe back when W3C was in its infancy, but I highly doubt it now.


    No, I mean the algorithm for deciding what to do with invalid markup is a lot more complex than what has to be done if the markup is well formed. The algorithm is laid out step by step in the spec if you want to check it out.

    Winston Gutkowski wrote:
    So, does it give you a decent message?


    Depends what you mean by 'it' Certainly the W3C Validator will generally give you useful messages and most modern browsers have sophisticated developer tool suites which are a big help.

    Winston Gutkowski wrote:
    My understanding was that the only requirement for a browser was to reject it, but I'm glad to hear I'm out of date in that case.


    No, that's XML parsing, and that's the main reason why no-one really wanted to implement it.

    Winston Gutkowski wrote:
    After all, one would hope that you're dealing with people with a modicum of intelligence.


    Spend a few years trying to help out web developers on forums and websites and you may find that hope a bit dented
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:No, I mean the algorithm for deciding what to do with invalid markup is a lot more complex than what has to be done if the markup is well formed. The algorithm is laid out step by step in the spec if you want to check it out.


    And this is where I get confused.

    Htmltidy (sorry to keep banging on about it) has been around for yonks. It's blisteringly fast, was written by a chap at the W3C, and I've used it on an industrial scale (thousands of pages at a time, dozens of times a day), and I have never once had it crap out on me, nor fail to produce output that wasn't the EXACT visual equivalent of its input (assuming one understands that it has a specific way of dealing with overlapping tags).

    Therefore: Why is there any need to handle "invalid markup" at all? Bash the input through Tidy, and parse the result. The browser can deal with any invalid usage, but it doesn't (necessarily) have to deal with stuff that isn't well-formed.

    Maybe I'm over-simplifying the problem, but it also seems to me that the specs might be over-complicating it.

    Winston
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:The algorithm is laid out step by step in the spec if you want to check it out.


    Ooof. I did.

    And it looks to me like a classic spec for a piece of C code if I ever saw it: centralized, flag-and-state based, and procedural. Not one whiff of WHAT; all about HOW.

    Has noone at CERN ever heard of Object-Orientation?

    Winston
     
    Rob Crowther
    author
    Posts: 297
    5
    Android Firefox Browser Fedora
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:assuming one understands that it has a specific way of dealing with overlapping tags



    Well there you have the start of the problem - please specify, in enough detail that competing implementations can be implemented (so that we can have two interoperable implementations), the specific way it has of dealing with overlapping tags. Then specify exactly how it handles everything else; then see if it's still simpler than the current spec.

    If it makes you feel any better, the (Java) parser which is the basis of the W3C's validator is also, after automatic conversion to C++, the parser used in Firefox.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:Well there you have the start of the problem - please specify, in enough detail that competing implementations can be implemented (so that we can have two interoperable implementations), the specific way it has of dealing with overlapping tags.


    Hey, I'm not interested enough to submit a formal proposal but, as I recall, Tidy's methodology was pretty simple:
    At the point where an overlap is discovered (closure of an open tag that precedes other open ones): close all tags opened since the one being closed in hierarchical sequence, close the "overlap" tag, then reopen the remaining ones in their encountered order. Possibly verbose, but pretty straightforward.

    I can imagine that might cause some problem with things like tables, and TBH I have no idea how Tidy worked out those, or whether it simply rejects the page; all I can say is that it never did with our stuff.

    Then specify exactly how it handles everything else...


    Nah. As I say, the guy that wrote it worked at the W3C, so I can't imagine they don't know about it.

    I reckon I'll stick to toolmaking and let others sweat the "webby" stuff.

    Winston
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:If it makes you feel any better, the (Java) parser which is the basis of the W3C's validator is also, after automatic conversion to C++, the parser used in Firefox.


    Actually, it does; if only because it might get some "objective" thinking into the process.

    Parsers are quite close to my heart, because they gave me my MomentOfClarity when it comes to Object-Orientation, and I suspect that they are uncommonly aligned with the way that objects work.

    To me, an "HTML parser" shouldn't be some monolithic entity, it should be tons of parsers working in cooperation:
    Tag encountered? Pass its contents off to some parser "subset" that deals with it.

    That's why I have a major problem with the spec that you linked: it's all about HOW - do this, do that, set this flag... - and I don't see any overall rationale to the process.

    What are the duties of an HTML parser? (Or maybe more specifically - a browser's parser?) What does it need to achieve? What are its possible inputs? Write those down. In detail. Don't blind me with procedure.

    Let me say that I'm not griping at you, Rob; you've been very enlightening...and patient.

    I do think, however - and have for a long time - that there's an air of complexity and "myticism" around web-based architecture that simply isn't warranted. I've got some data I want to show someone, or send someone, and I want to be able to process their response to it - how difficult is that?

    I'm not writing GoogleMaps (now that is mystic to me ).

    Winston
     
    Rob Crowther
    author
    Posts: 297
    5
    Android Firefox Browser Fedora
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote:That's why I have a major problem with the spec that you linked: it's all about HOW - do this, do that, set this flag... - and I don't see any overall rationale to the process.

    What are the duties of an HTML parser? (Or maybe more specifically - a browser's parser?) What does it need to achieve? What are its possible inputs? Write those down. In detail. Don't blind me with procedure.



    The problem is, that's what previous versions of the spec did (or they punted the whole thing to 'use an SGML parser'). What we ended up with as a result is a collection of browsers which all parsed HTML slightly differently, with those differences tending towards the subtle/annoying end of the spectrum if you were trying to write JavaScript to manipulate things.

    Expressing everything as an algorithm is a response to that experience, part of the effort to make everything less ambiguous and therefore end up with better compatibility. The focus for compatibility in HTML5 is actually the DOM rather than the algorithm - if your parser produces the same DOM for the same markup as the algorithm in the spec, then your parser is compatible (and as part of the spec work there is a test suite so you can verify that, which should also help with your "What are the possible inputs?" question). The goal of the spec is to enable anyone to write a compatible browser (ie. the audience for the spec is browser implementers and, if it comes to it, they should be landed with the complexity rather than web authors or web users).
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Rob Crowther wrote:The problem is, that's what previous versions of the spec did (or they punted the whole thing to 'use an SGML parser'). What we ended up with as a result is a collection of browsers which all parsed HTML slightly differently, with those differences tending towards the subtle/annoying end of the spectrum if you were trying to write JavaScript to manipulate things.


    Wow. I find that very surprising. Although, I have to admit, I've never been at the sharp end of something as complex as "the Web".

    Isn't there a danger of becoming preoccupied with the procedure though? A sort of "sorry, you didn't fill in page 37, subsection 2, paragraph 4, line7 correctly; your benefits are cancelled" attitude? Losing sight of the tree because of the branches?

    If you're dealing with browser companies with vast resources at their disposal, they can probably afford to ensure that every 'i' is dotted and every 't' crossed, but it sounds to me like you could be stifling innovation as a result.

    But maybe there's been enough innovation for the last few decades. I could certainly handle a few billion fewer "smart"phones in the world.

    Winston
     
    Marshal
    Posts: 67430
    173
    Mac Mac OS X IntelliJ IDE jQuery Java
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Winston Gutkowski wrote: Losing sight of the tree because of the branches? ,,, but it sounds to me like you could be stifling innovation as a result.



    Depends what you mean by "innovation". In the past, Microsoft took it to mean "let's add proprietary shit to our browser to create lock-in", versus "let's make the web easier to program for".

    I think the spec leads us along the latter path, so yeah, that's the tree, not the branches.
     
    Winston Gutkowski
    Bartender
    Posts: 10777
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Bear Bibeault wrote:Depends what you mean by "innovation". In the past, Microsoft took it to mean "let's add proprietary shit to our browser to create lock-in", versus "let's make the web easier to program for".
    I think the spec leads us along the latter path, so yeah, that's the tree, not the branches.


    Good old Microsoft; the bete-noir of ... well, pretty much anything you care to name really.

    But I see your point. I wonder what it is about HTML that makes a procedural spec so much better than a functional one? Is it simply abuse? I certainly hope it doesn't indicate a general trend...

    Winston
     
    If you have a bad day in October, have a slice of banana cream pie. And this tiny ad:
    Thread Boost feature
    https://coderanch.com/t/674455/Thread-Boost-feature
      Bookmark Topic Watch Topic
    • New Topic